ToB企服应用市场:ToB评测及商务社交产业平台

标题: 大数据之路 读书条记 Day8 数据存储 [打印本页]

---

作者: 来自云龙湖轮廓分明的月亮    时间: 2024-8-12 11:38
标题: 大数据之路 读书条记 Day8 数据存储
回顾：
大数据之路 读书条记 Day7 实时技术 简介及流式技术架构
大数据之路 读书条记 Day6 离线数据开发之数据开发平台
  数据存储

1 数据范例

实时使命在运行过程中，会盘算很多维度和指标，这些数据需要放在一个存储系统中作为恢复大概关联使用。其中会涉及三种范例的数据：

• 中间盘算结果——在实时应用处理过程中，会有一些状态的保存（比如去重指标的明细数据），用于在发生故障时，使用数据库中的数据恢复内存现场。
  
• 终极结果数据——指的是通过 ETL 处理后的实时结果数据，这些数据是实时更新的，写的频率非常高，可以被卑鄙直接使用。
  
• 维表数据——在离线盘算系统中，通过同步工具导入到在线存储系统中，供实时使命来关联实时流数据。
  

   维表数据在实时数据处理使掷中扮演着关键脚色，尤其是在构建实时数据仓库或实时分析系统时。维表，即Dimension Tables，是数据仓库架构中的紧张组成部门，它们包罗了形貌性的信息，用来给究竟表中的数据提供上下文。在实时使掷中，维表数据的使用主要体现在以下几个方面：
  

• 上下文丰富：
  维表提供了对究竟数据的详细形貌，如产物类别、客户信息、地理位置等，这些都是在究竟表中通过外键引用的。当实时流数据到达时，通过与维表的关联，可以增长数据的维度，从而让数据更加丰富和有意义。
  
• 实时关联：
  实时使命需要快速地将流数据与维表数据举行关联，以提供即时的分析结果。这通常涉及到高效的关联算法和存储布局，如内存中的哈希表，以减少耽误并提高处理速度。
  
• 数据更新：
  维表数据可能随时间变化，如产物分类调整、客户地址变更等。实时使命必须能够及时反映这些更新，以确保分析结果的准确性。这通常要求维表具有良好的更新机制，如增量更新或全量更新策略。
  
• 存储选择：
  为了满足实时关联的需求，维表数据每每存储在高性能的存储系统中，如内存数据库（如Redis）、列式存储数据库（如Druid）或关系型数据库（如MySQL）。选择符合的存储系统对于保证实时性能至关紧张。
  
• 资源管理：
  如果维表数据量较大，全量加载到内存可能不现实，这时可能需要接纳部门加载、缓存策略或按需从后端存储系统查询数据的方法。
  
• 容错性：
  实时使掷中维表数据的使用还需要考虑系统的容错性，即在数据源不可用或数据损坏时，如何保证数据处理的连续性和正确性。
  

  总之，维表数据在实时使掷中提供了须要的上下文信息，使数据更具可解释性，并且需要通过高效的计划和实施策略来确保实时性和准确性。
  2 数据库范例

数据库包括关系数据库、列式数据库、文档数据库等，在选择实时使命所用的数据库时，应该注意哪些特征呢？
前面的文章中提到过实时使命是多线程处理的，意味着使用的数据存储系统必须能较好的执行多并发读写，并且延时需要在毫秒级别。
实践中用得较多的有HBase\Tair\MongoDB等列式存储系统，它们基本满足需求。
   列式存储系统是一种专门计划用于优化数据分析工作负载的数据存储技术。与传统的行式存储不同，列式存储将数据按照列（属性）举行构造和存储，而不是按照行（记录）。这种存储方式尤其实用于数据仓库和大数据分析场景，因为在这种场景中，查询每每针对特定的列执行聚合或筛选操作，而不需要访问整行数据。
以下是列式存储的一些关键优势：
  

• 压缩效率高：
  列式存储可以更有效地举行数据压缩，因为雷同范例的数值存储在一起，压缩算法能更好地辨认和消除冗余，从而节省存储空间。
  
• 查询性能：
  在分析型查询中，由于只需要读取感兴趣的列，列式存储可以明显减少磁盘I/O操作，提高查询速度。比方，在盘算所有效户的平均年龄时，只需要读取“年龄”这一列，而无需读取其他列的数据。
  
• 支持并发读取：
  列式存储计划通常支持并发读取，这意味着多个查询可以同时运行而不会互相壅闭，提高了系统的吞吐量。
  
• 聚合和过滤操作优化：
  对于常见的聚合和过滤操作，列式存储可以只处理相关的列，而忽略其他列，从而加速处理速度。
  
• 适合大数据处理：
  列式存储系统，如Apache Parquet、Google BigQuery、Amazon Redshift等，专为大规模数据集计划，可以高效地处理PB级数据。
  

  然而，列式存储也存在一些缺点：
  

• 写入操作本钱高：
  更新或插入操作可能需要重写整个列，因此写入性能可能不如行式存储。
  
• 不适合随机行访问：
  如果应用步伐需要频仍随机访问单个行，则列式存储可能不是最佳选择，因为这会涉及读取所有列才气重组一行数据。
  
• 复杂性：
  列式存储系统的实现和管理可能比行式存储系统更复杂，特殊是在需要支持多种数据范例和复杂查询的情况下。
  总体而言，列式存储非常适合那些需要大量读取和分析操作的场景，而对写入操作的要求相对较低。
  

  但是这些系统也有明显的缺点，以HBase为例，一张表必须有rowkey。rowkey是按照ASCII码来排序的，这种规则限制了数据读取的方式，如果业务方需要接纳其他方式读取数据则需要重新输出rowkey,从这个角度看HBase乃至没有关系型数据库方便，但HBase一张表能存几到几十TB，而关系型数据库需要接纳分库分表的处理（Day5讲过）才气做到。因此，对于海量数据的实时盘算，一般会接纳非关系型数据库，以应对大量的多并发读写。
   HBase 是一个分布式、版本化的 NoSQL 数据库，它基于 Google 的 Bigtable 论文计划，主要用于处理海量的半布局化或非布局化数据。在 HBase 中，数据是以表格的形式存储的，每个表由一系列的行组成，而每一行都由一个唯一的行键（RowKey）来标识。
  RowKey 的概念

  RowKey 在 HBase 中起着至关紧张的作用，它是数据的主键，用于唯一标识表中的每一条记录。HBase 不提供传统的 SQL 式的索引，以是所有的数据检索和查询都直接或间接依赖于 RowKey。
  RowKey 的特点

  

• 唯一性：每个 RowKey 必须是唯一的，以便区分表中的不偕行。
  
• 排序：RowKey 是按字典次序排序的，这意味着 HBase 可以高效地举行范围查询，即查找介于两个 RowKey 值之间的所有行。
  
• 长度：RowKey 的最大长度可以达到 64KB，但实际上，为了性能考虑，RowKey 应该只管短小。
  
• 二进制格式：RowKey 是以二进制格式存储的，这意味着它可以是任何二进制数据，包括数字、字符串大概更复杂的组合。
  

  RowKey 的计划原则

  计划 RowKey 时，应考虑到以下几点：
  

• 查询模式：RowKey 应该反映最常见的查询模式，以优化查询性能。
  
• 分布性：RowKey 的计划应该尽可能均匀分布，避免热门问题，确保数据在集群中均匀分布。
  
• 时间戳：偶然，RowKey 包罗时间戳，这样可以方便地按照时间次序检索数据。
  
• 复合 RowKey：RowKey 可以由多个字段组成，称为复合 RowKey，以包罗更多的信息和优化查询。
  

  RowKey 的示例

  假设有一个用户运动日记表，常见的查询是根据用户 ID 和日期来获取数据，那么 RowKey 可能计划为 <UserID>:<Date> 的形式，比方 12345:20230101。
  总结

  RowKey 是 HBase 中最紧张的概念之一，它的计划直接影响到数据的存储效率和查询性能。合理计划 RowKey 可以帮助最大化 HBase 的性能，满足特定的应用需求。
  3 表名计划和rowkey计划

表名计划示例

计划规则：汇总层标识+数据域+主维度+时间维度
比方： dws_trd_slr_dtr
表现：汇总层生意业务数据，根据卖家（slr）主维度+0点截至当日（dtr）举行统计汇总
这样做的好处：

• 减少表数量：将具有雷同主维度的数据放在同一张物理表中，可以有效减少表的数量，使得数据库布局更加简洁，易于维护。
  
• 直观易懂：通过表名可以直接看出存储的是什么范例的数据内容，这对于排查问题非常有帮助，因为开发者不需要耗费太多的时间去理解表的布局和用途。
  

rowkey计划

计划规则：MD5 + 主维度 + 维度标识 + 子维度 1 + 时间维度 + 子维度 2
比方：卖家 ID 的 MD5 前四位 + 卖家 ID + app + 一级类目 ID + ddd + 二级类目 ID。
以 MD5 的前四位作为 rowkey 的第一部门，可以把数据散列，让服务器团体负载是均衡的，避免热门问题。在上面的例子中，卖家 ID 属于主维度，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在rowkey上做区分。
   

• MD5: 这里指的是MD5哈希算法，它会将任意长度的数据转换成一个固定长度（通常是128位）的哈希值。MD5的前四位（通常是指哈希值的前几位字符）被用作rowkey的一部门，目的是为了散列数据，使得数据均匀地分布在多个服务器上，从而避免数据热门（即某些服务器上的数据访问远高于其他服务器）。
  
• 主维度: 指的是数据中的主要分类或最紧张的属性，比如这里的“卖家ID”。主维度在查询数据时通常是必填项，意味着大部门查询操作会基于这个维度举行。
  
• 维度标识: 是对不同统计维度的标记，用于区分不同的统计数据范例或来源，确保纵然主维度雷同，不同的数据范例也能通过不同的维度标识举行区分。
  
• 子维度: 子维度是对主维度的进一步细分，这里提到了“子维度1”和“子维度2”，比方“app”（应用步伐）和“类目ID”（产物类别），它们可以提供更详细的分类信息。
  
• 时间维度: 指的是与时间相关的部门，这可以是日期、时间戳大概特定的时间周期，比方“ddd”可能代表某一天大概某一时间段，这样可以方便举行时间范围内的数据查询。
  

  按照上述规则计划的rowkey示例：“卖家ID的MD5前四位+卖家ID+app+一级类目ID+ddd+二级类目ID”。
  这种计划的好处在于：
  

• 数据分散: MD5的前四位确保数据均匀分布在存储集群中，防止单点过载。
  
• 查询优化: 主维度和其他维度的组合可以帮助快速定位和检索特定的数据记录。
  
• 机动性: 计划允许根据不同的查询需求举行扩展，同时保持数据的构造性和可读性。
  

  总之，rowkey的计划应该考虑到数据的分布、查询模式以及可能的扩展需求，以确保数据库系统的高效运行。
  

---

本日的分享到这里就竣事啦，点赞关注收藏，获取更多专业知识~

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4