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

LimeRanceLan
334 阅读9分钟

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

这是我参与「第四届青训营 -大数据场」笔记创作活动的第15天

三、大数据支撑

1. HBase 在大数据生态的定位

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

2. 水平扩展能力

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

image.png

3. Region Split 热点切分

  • 当某个region数据量过多，切分成两个独立的子region分摊负载。
  • RegionServer在特定时机(flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition。
  • 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。
3.1 切分点选取
  • 1.找到该表中的最大region

image.png

  • 2.找到该region中最大的column family

image.png

  • 3.找到column family中最大的 HFile

image.png

  • 4.找到 HFile 里处于最中间位置的Data Block，用这个Data Block的第一条Keyvalue的Rowkey作为切分点

image.png

3.2 切分过程
  • 所有ColumnFamily都按照统一的切分点来切分数据。
  • 目的是优先均分 最大的文件，不保证所有Column Family的所有文件都被均分。
  • HFile1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region的rowkey区间。

image.png

  • 切分出的新region分别负责rowkey区间[2000,2500)和[2500,4000)。

image.png

  • 每个新region分别负责原region的上/下半部分rowkey区间的数据。
  • 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

image.png

3.3 流程设计

AssignmentManager 检查cluster、table、region 的状态后，创建 SplitTableRegionProcedure 通过状态机实现执行切分过程。

image.png

4. Region 碎片整合

  • 当某些region 数据量过小、碎片化，合并相邻region 整合优化数据分布。
  • AssignmentManager创建MergeTableRegionsProcedure执行整合操作。
  • 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据
  • *注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。
4.1 流程设计

类似于region切分，不立刻处理实际数据文件，而是通过创建reference files引用到原文件，然后原子地更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠 CatalogJanitor异步巡检元数据处理遗留数据。

image.png

5. Region 负载均衡

定期巡检各 RegionServer 上的 region 数量，region 的数量均匀分布在各个 RegionServer 上。

  • SimpleLoadBalancer 具体步骤：

    • 1.根据总region数量和RegionServer数量计算平均region数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region数为5，负载均衡的RS（regionserver）上region数量应该在[4,6]区间内。
    • 2.将RegionServer按照region数量降序排序，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序;
    • 3.选取出region 数量低于下限的RegionServer列表，round-robin分配步骤2选取的regions,尽量使每个RS的region数量都不低于下限;
    • 4.处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近。

image.png

image.png

5.1 其他策略
5.1.1 StochasticLoadBalancer
  • 随机尝试不同的region放置策略，根据提供的costfunction计算不同策略的分值排名(0为最优策略，1为最差策略)
  • cost计算将下列指标纳入统计：region负载、表负载、数据本地性( 本地访问HDFS)、Memstore 大小、HFile 大小
  • 根据配置加权计算最终cost,选择最优方案进行负载均衡;D根据配置加权计算最终cost,选择最优方案进行负载均衡
5.1.2 FavoredNodeLoadBalancer
  • 用于充分利用本地读写HDFS文件来优化读写性能
  • 每个region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region的数据
  • 即使第一节点出现故障，HBase也可以将第二节点提升为第一节点，保证稳定的读时延

6. 故障恢复机制

6.1 HMaster

  • HMaster通过多实例基于Zookeeper选主实现高可用性。

    • 所有实例尝试向Zookeeper的/hbaselactive-master l临时节点CAS地写入自身信息，
    • 写入成功表示成为主实例，失败即为从实例，通过watch 监听/hbaselactive-master节点的变动。
    • 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主。

image.png

6.2 HMaster 恢复流程
6.2.1 HMaster 自身恢复流程
  • 1.监听到/hbaselactive-master 临时节点被删除的事件，触发选主逻辑;
  • 2.选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures 从之前状态继续执行;
  • 3.故障HMaster实例恢复后发现主节点已存在，继续监听 /hbaselactive-master。
6.2.2 调度 RegionServer 的故障恢复流程
  • 1.AssignmentManager 从procedure列表中找出Region-In-Transition状态的region继续调度过程;
  • 2.RegionServerTracker 从Zookeeper梳理 online状态的RegionServer列表，结合ServerCrashProcedure列表、HDFS 中 WAL目录alive / splitting状态的RegionServer记录，获取掉线RegionServer的列表,分别创建ServerCrashProcedure执行恢复流程。

7. 故障恢复机制

7.1 RegionServer
  • 每个RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点。
  • HMaster通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions。
  • RegionServer的故障恢复需要将内存中丢失的数据从WAL 中恢复，HMaster利用Zookeeper配合所有RegionServer 实例，分布式地处理WAL数据，提升恢复速度。

image.png

7.2 RegionServer 恢复流程
  • 1.启动时去Zookeeper登记自身信息，告知主 HMaster实例有新RS实例接入集群
  • 2.接收和执行来自HMaster的region调度命令
  • 3.打开region前先从HDFS读取该region 的recovered.edits目录下的WAL记录，回放恢复数据
  • 4.恢复完成，认领Zookeeper上发布的分布式任务（如WAL 切分）帮助其他数据恢复

8. Distributed Log Split 原理

8.1 背景
  • 1.写入HBase的数据首先顺序持久化到Write Ahead-Log,然后写入内存态的MemStore即完成，不立即写盘，障会导致内存中的数据丢失，需要回放WAL来恢复;
  • 2.同RegionServer的所有region复用WAL，因此不同region的数据交错穿插，RegionServer 故障后重新分配region前需要先region维度拆分WAL。

image.png

8.2 具体流程
8.2.1 实现原理
  • 1.RegionServer 故障，Zookeeper 检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端
  • 2.active HMaster监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表
  • 3.HMaster为每个WAL文件发布一个log split task到ZK
  • 4.其他在线的RS监听到新任务，分别认领
  • 5.将WAL entries按region 拆分，分别写入HDFS . 上该region的recovered.edits目录
  • 6.HMaster监听到logsplit任务完成，调度region到其他RS
  • 7.RS打开region 前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region恢复读写服务。
8.2.2 完整流程示意图

image.png

8.3 优化空间

进一步优化：Distributed Log Replay

  • HMaster 先将故障RegionServer 上的所有region以Recovering状态调度分配到其他正常RS上;
  • 再进行类似DistributedLogSplit的WAL日志按region维度切分;
  • 切分后不写入HDFS，而是直接回放，通过SDK写流程将WAL记录写到对应的新RS;
  • Recovering状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成。

四、最佳实践分享

1. rowkey 设计

  • 最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes。key在保证功能的前提下建议越短越好，因为key是冗余到每个cell存储的，过长的key会占用更多存储、缓存空间。
  • 设计Key时，要充分利用排序存储这个特性，将经常一起读取的行存储到一起。HBase以HFile文件块为单位从HDFS读取数据，一次性读出相邻相关数据可以达到随机读变成顺序读的效果。
  • 同时要防止出现热key聚焦打爆region server实例。

2. Column Family 数量

  • Column family 数量过多容易影响性能，建议尽量少，不超过5个。
  • 需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族。
  • 列族(以及column qualifier）名称尽量短，因为会冗余存储到每个KeyValue 中。

3. 参数调优经验

image.png

4. ByteTable - 字节跳动自研分布式表格存储系统

优势:

  • 1.存储层基于字节跳动自研分布式存储底座，从设计上充分支持在线场景的性能、功能需求;
  • 2.采用C++编写构建，杜绝了Garbage Collection在Stop-The-World 阶段带来的性能抖动;
  • 3.架构设计上支持更细粒度、更灵活的数据分片组织方式，激活更多优化空间;
  • 4.元数据设计提供更好的故障域控制，避免多租户相互影响;
  • 5.更短的故障恢复时间，对在线场景的高可用性支持更好;
  • ...
avatar
文章
阅读
粉丝