深入浅出HBase实战|青训营笔记

苦瓜不浮夸233
229 阅读6分钟

这是我参与「第四届青训营」笔记创作活动的第10天，学习内容为《深入浅出HBase实战》，内容包括 HBase适用场景、HBase架构设计、大数据场景HBase的解决方案、HBase大规模实战的最佳实践。

思维导图如下：

10.深入浅出HBase实战.png

HBase适用场景

  1. HBase和关系型数据库的区别

image.png

  1. HBase数据模型

image.png

  1. 列族为单位存储数据，行族为单位索引数据
  2. 列族使用前预先创建，列名不需要预先声明，因此支持半结构化数据模型
  3. 行键+列族+列名+版本号定位一个具体值
  4. 适合稀疏数据，缺省列不占用存储空间
  5. 允许批量读取多行列的部分列族/列数据
  1. HBase物理结构

image.png

  1. key-val
  2. 每个版本的数据都携带全部行列信息
  3. 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
  4. 同列族下不同物理文件间不保证数据全局有序，仅单个物理文件内有序
  1. 使用场景：见学习资料
  2. HBase数据模型优缺点

image.png

HBase架构设计

  1. HBase的系统架构

image.png

image.png

  1. HMaster：元信息管理组件，以及集群调度、保活等功能。通常部署一个主节点和一到多个备节点，通过Zookeeper选主。

image.png

  1. RegionServer：提供数据读写服务，每个实例负责一段不重叠的连续rowkey范围内的数据。

image.png

  1. ThriftServer：提供一层以Thrift协议访问数据的代理层。

image.png

  1. Zookeeper

image.png

大数据场景HBase的解决方案

HBase在大数据生态的定位

  1. 对海量级数据支持强一致、近实时的读写性能
  2. 支持字典序批量扫描大量数据，只读取部分列族数据，灵活支持不同查询模式
  3. 存储大规模任务的中间/最终计算结果
  4. 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问
  5. 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费

水平扩展能力

  1. 增加Region Server实例，分配部分region到新实例
  2. 扩展过程平滑，无需搬迁实际数据
  3. 可用性影响时间很短，用户基本无感知

热点切分

  1. 当某个region数据量过多，切分成两个独立的子region分摊负载
  2. RegionServer在特定时机检测region是否应该切分，计算切分点并上报给HMaster
  3. 不搬迁实际数据，新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey以及标识新regions是上/下半部分的数据
  4. 切分点选取
  1. 目标：优先把最大的数据文件均匀切分
  2. 步骤
  3. 找到表中哪个region的数据大小最大
  4. 找到该region哪个列族的数据大小最大
  5. 找到该列族内哪个HFile的数据大小最大
  6. 找到HFile中处于最中间位置的Data Block
  7. 用这个DataBlock的第一条KeyValue的Rowkey作为切分点（第一条最快，block相对于整个很小，因此可以不用选中间的块为切分点）
  1. 切分过程
  1. 所有列族都按照统一的切分点来切分数据
  2. 不保证所有列族的所有文件都被均分
  3. 切分出的新region分别负责rowkey区间的2000-2500，2500-4000左闭右开
  4. 每个新region分别负责原region的上/下半部分rowkey区间的数据
  5. 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据

碎片整合

  1. 某些region数据量过小、碎片化，合并相邻region整合优化数据分布
  2. 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据
  3. 只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定

负载均衡策略

  1. 定期巡检各RegionServer上的region数量，保持region的数量均匀分布在各个RegionServer上
  2. SimpleLoadBalancer
  1. 计算平均region数，设定弹性上下界
  2. 降序排序RegionServer，超出上限的迁出，并按照创建时间从新到老排序（最新的可能很热，要分开放）
  3. 选取region数量低于下限的RegionServer列表，按照round-bin分配上一步的regions（轮流发牌，避免热区域集中在一个RegionServer中）
  4. 处理边界情况，无法满足所有RS的region数量都在合理范围内，尽量保持region数量接近
  1. StochasticLoadBalancer：随机尝试不同region放置策略，根据提供的cost function计算不同策略的分值排名
  2. FavoredNodeLoadBalancer:充分利用本地读写HDFS文件来优化读写性能，每个region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region的数据；即使第一节点出现故障，HBase也可以将第二节点提升第一节点，保证稳定的读时延

故障恢复机制

HMaster

  1. HMaster：HMaster通过多实例基于Zookeeper选主实现高可用性
  2. 自身恢复流程：主节点挂了触发选主流程，选主成功后执行HMaster启动流程，并继续之前未完成的作业，故障native节点恢复后变成从节点；
  3. 调度RS故障恢复流程

RegionServer

  1. ReginoServer启动流程：见学习资料
  2. 数据恢复：Distributed Log Split

image.png

HBase大规模实战的最佳实践

Rowkey设计策略

  1. 不需要顺序扫描批量连续rowkey：对原始rowkey做哈希（MD5），取适当长度的子串
  2. 需要顺序扫描批量连续rowkey：用聚合ID前缀避免数据热点，然后加上定义顺序的信息（如时间戳），ID前缀也建议哈希处理，避免非预期的热点
  3. rowkey长度尽量保持较短，因为会冗余存储到每个keyvalue中，避免用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RS上，造成热点瓶颈，且无法通过水平扩容缓解

Column Family设计策略

  1. 建议尽量少，不超过5个；数量过多容易影响性能
  2. 需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必须的列族
  3. 列族名称尽量短，因为会冗余存储到每个keyvalue中

总结：本节课重点学习了HBase的总体架构和大数据场景下HBase的解决方案。作为开源的NoSQL分布式数据库，HBase采用存储计算分离架构，提供强一致性语义，具有高可靠、高效能、面向列、可伸缩等特征，主要用来存储半结构化和非结构化数据。

avatar
文章
阅读
粉丝