深入浅出 HBase 实战 ｜ 青训营笔记
这是我参与「第四届青训营」笔记创作活动的的第8天。
1. HBase适用场景和数据模型
HBase的设计理念、数据模型、适用场景、业界用例
1.1 什么是HBase
- HBase是一个开源的NoSQL分布式数据库
- 参考Google BigTable
- 对稀疏表提供更高存储空间使用率和读写效率
- 采用存储计算分离架构
- 存储层基于HDFS存储数据，提供容错机制和高可靠性
- 计算层提供灵活快速水平扩展，负载均衡和故障恢复能力
- 提供强一致语义，CP系统（consistency，partition tolerance） availability无
1.2 HBase和关系型数据库区别
| HBase | Relational DB | |
|---|---|---|
| 数据结构 | 半结构化无数据类型；按列族稀疏存储，缺省数据不占用存储空间；支持多版本数据 | 结构化，数据类型丰富；按完整行存储，缺省列需要存储占位符；不支持多版本数据 |
| 读写模式 | 支持按需读取部分列 | 必须整行读取 |
| 事务支持 | 仅支持单行内原子性 | 支持完整的事务语义 |
| 数据规模 | 适用于TBPB级海量数据，水平扩展快速平滑 | 仅适用于GB，小量TB级，扩展复杂 |
| 索引支持 | 仅支持rowKey主键索引 | 支持二级索引 |
1.3 HBase数据模型
HBase以列族组织数据，以行键索引数据
-
列族需要在使用前预先创建，列名不需要预先声明，因此支持半结构化数据模型
-
支持保留多个版本数据，（行键+列族+列名+版本号）定位一个具体的值
-
概念名称
- 行键rowkey：用于唯一索引一行数据的主键，以字典序组织；一行可以包含多个列族
- 列族column family：用于组织一系列列名，一个列族可以包含任意多个列名，每个列族的数据物理意义上相互独立存储，以支持按列读取部分数据
- 列名column qualifier：用于定义到一个具体的列，一个列名可以包含多个版本的数据，不需要预先定义列名，以支持半结构化的数据模型
- 版本号version：用于标示一个列内多个版本的数据，每个版本号对应一个值
- 值value：存储的一个具体值
1.4 逻辑结构
- 通过非关系型视图理解HBase数据模型
- 适合稀疏数据，缺省列不占用存储空间
1.5 物理结构
- 物理数据结构的最小单元是KeyValue结构
- 每个版本的数据都携带全部行列信息
- 同一行同一列族的数据物理上连续有序存储
- 同列族内eyValue按rowKey字典序升序，column qualifier升序，version降序排列
- 不同列族数据存储在相互独立的物理文件，列族间不保证数据全局有序
- 同列族下不同物理文件见不保证数据全局有序，仅单个物理文件内有序
1.6 适用场景
- 近在线的海量分布式KV/宽表存储，数据量级可达到PB以上
- 写密集型、高吞吐应用，可接受一定程度的时延抖动
- 字典序主键索引，批量顺序扫描多行
- Hadoop大数据生态友好兼容
- 半结构化数据模型，行列稀疏的数据分布，动态增减列名
- 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
1.7 典型应用
- 电商订单数据
- 推荐搜索引擎
- 广告数据流
- 用户交互数据
- 时序数据引擎
- 图存储引擎
- 大数据生态：融合Hadoop
1.8 HBase数据模型的优缺点
- 优势
- 稀疏表友好，不存储缺省列，支持动态新增列类型
- 支持保存多版本数据
- 支持只读取部分column family数据，避免读取不必要的数据
- 支持的数据规模相比传统关系型数据库更高，更易水平扩展
- 支持rowkey字典序批量扫描数据
- 缺点
- 每条数据都要冗余存储行列信息
- 不支持二级索引，只能通过rowkey索引，查询效率依赖rowkey设计
- column family数量较多时可能引发性能衰退
- 不支持数据类型，一律按字节数组存储
- 仅支持单行内的原子性操作，无跨行事务保障
2. HBase整体架构和模块设计
2.1 HBase架构设计
- 主要组件包括
- HMaster：元数据管理，集群调度，保活
- RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的rowKey区间内的数据
- ThriftServer，提供Thrift API读写代理层
- 依赖组件
- Zookeeper：分布式一致性共识协作管理，HMaster选主、任务分发、元数据变更管理
- HDFS：分布式文件系统、存储底座
2.2 HMaster
-
职责
- 管理RegionServer实例生命周期，保证服务可用性
- 协调RS数据故障恢复，保证数据正确
- 集中管理集群元数据，执行负载均衡维护集群稳定性
- 定期巡检元数据，调整数据分布，清理废弃数据等
-
主要组件
- ActiveMasterManager：管理HMaster的active/backup状态
- ServerManager：管理集群内RegionServer的状态
- AssignmentManager：管理数据分片region的状态
- SplitWalManager：负载故障数据恢复的WAL拆分工作
- LoadBalancer：定期巡检
- RegionNormalizer：定期巡检
- CatalogJanitor：定期巡检清理
- Cleaners
- masterFileSystem
2.3 RegionServer
-
主要职责
- 提供部分rowkey区间数据读写
- 如果负责meta表，向客户端SDK提供rowkey位置信息
- 认领HMaster发布的故障恢复任务，帮助加速数据恢复流程
- 处理HMaster下达的元数据操作，如region打开关闭分裂合并等
-
主要组件
- memStore：基于skiplist数据结构实现内存态存储，定期批量写入硬盘
- write-ahead-log：顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
- storeFile：HFile，表示HBase在HDFS存储数据的文件格式
2.4 ZooKeeper
- 主要职责
- HMaster登记信息，对active/backup达成共识
- regionserver登记信息，失联时HMaster保活处理
- 登记meta表位置信息
- 供HMaster和RegionServer协作处理分布式任务
2.5 thriftServer主要职责
- 实现HBase定义的ThriftAPI 作为代理层向用户提供RPC读写服务
- 用户可根据IDL自行生成客户端实现
- 独立于RegionServer水平扩展，用户可访问任意ThriftServer实例
- scan较特殊，需要同实例维护scan状态
3. 大数据场景HBase的解决方案
- 水平扩展能力
- 负载均衡策略
- 故障恢复机制
3.1 HBase在大数据生态的定位
- 对海量数据支持强一致、近实时读写性能，支持快速ad-hoc分析查询任务
- 支持字典序批量扫描大量数据、支持只读取部分列族数据、灵魂支持不同查询模式
- 存储大规模任务的中间、最终计算结果
- 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模并发访问
- 精细化资源成本控制，计算存储层分别按需扩展
3.2 水平扩展能力
- 增加RegionServer实例，分配部分region到新实例
- 扩展过程平滑，无需搬迁实际数据（仅改变了分片）
- 可用性影响时间很短，用户基本无感知
3.3 Region热点切分
- 当某region数据量过多，切分成两个独立的子region分摊负载
- regionServer在特定时机（flush、compaction）检查region是否应该切分，计算切分点并RPC上报HMaster，由AsssignmentManager负责执行RegionStateTransition
- 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上下半部分的数据
- 切分点选取
- HBase原生提供多种切分策略使用相同的切分点选择策略
- 目标：优先把最大的数据文件均匀切分
- 步骤
- 找到最大的region
- 找到该region内最大的column family
- 找到该column family里最大的HFile
- 找到HFile里处于最中间位置的dataBlock
- 用这个DataBlock的第一条keyValue的rowKey作为切分点：startRowKey找的快
- 过程
- 所有column family都按照统一的切分点切分数据
- 目的是优先均分最大的文件，不保证所有的column family的所有文件被均分
- 切分出的新region分别负责两段rowkey
- 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据
- 流程设计：AssignmentManager检查cluster、table、region的状态后，创建SplitTableRegionProcedure通过状态机来执行切分过程
- 状态名和操作
- SPLIT_TABLE_REGION_PREPARE检查是否满足切分条件
- SPLIT_TABLE_REGION_PRE_OPERATION调用相关coprocessor方法，检查quota
- SPLIT_TABLE_REGION_CLOSE_PARENT_REGION关闭待切分region并确认执行成功
3.4 Region碎片整合
- 当某些region数据过小、碎片化，合并相邻region整合优化数据分布
- AssignmentManager创建MergeTableRegionsProcedure执行整合
- 不搬迁实际数据，通过reference file定位原region，直到下次compaction时实际处理数据
- 只允许合并相邻region，否则会打破rowkey空间连续不重合约定
3.5 region负载均衡
- 定期巡检各regionServer上region数量，保持region分布相对平均
- SimpleLoadBalancer具体步骤
- 根据总region数量和regionServer数量计算平均region数，设定弹性上下界避免不必要操作
- 将RS按照region数降序排序，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序
- 选取出region数量低于下限的regionServer列表，round-robin分配选取的region，尽量使每个RS的region数量不低于下限
- 处理边界情况，无法满足所有RS的region数都合理时，尽量平均分配
- StochasticLoadBalancer
- 随机尝试不同region放置策略，通过cost function计算策略排名
- cost参考region负载、表负载、数据本地性、memstore大小、HFile大小
- 根据配置加权计算最终cost
- FavoredNodeLoadBalancer
- 充分利用本地读写HDFS文件来优化读写性能
- 每个region指定优选3个RS地址，告知HDFS这些优选节点上放置region数据
- 即使第一节点故障，HBase可以提升第二节点为第一节点，保证稳定读时延
3.6 故障恢复机制
- HMaster
- 通过多实例基于zookeeper选主实现高可用
- 所有实例尝试向ative-master写入CAS自身信息
- 成功即为主、失败为从
- 主实例不可用时临时节点被删除，重新触发
- RegionServer
- 每个RS启动时向zookeeper创建临时节点
- HMaster监听RS在zookeeper节点状态，监控可用性
- RS故障恢复需要将内存中丢失的数据从WAL中恢复
3.7 Distributed Log Split
-
写入HBase的数据首先顺序持久化写入write-ahead-log，然后写入内存态memstore，不立即写盘
-
实现原理
- RS故障 zookeeper监测到RS故障，删除对应临时节点¥
-
优化：distributed Log Replay
- HM先将故障RS上所有Region以recovering状态调度分配到正常RS上
- 进行WAL日志按region维度划分
- 切分后不写入HDFS而是直接回放，通过SDK写流程将WAL记录写到对应的新RS
- Recovering状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成
4. HBase大规模实战
4.1 rowkey设计策略
- 不需要顺序批量扫描rowkey
- 原始rowkey进行hashing作为真实rowkey前缀
- 取适当长度子串节省空间
- 顺序扫描批量连续rowkey
- 首先用groupID/appId/userId前缀避免数据热点，加上定义顺序信息（时间戳等）
- ID前缀建议MD5 hashing避免非预期热点
- rowkey长度尽量保持较短
- 冗余存储到每个KV中
- 避免用时间戳直接作为rowkey前缀，会导致最新数据始终集中在单个RS上造成热点瓶颈且无法通过水平扩容缓解
4.2 column family设计策略
- 数量过多影响性能，尽量少，不超过5个
- 需要同时读取尽量放在相同列族，反之放在不同；避免读取不必要数据
- 列族名称尽量短，会冗余存储到KV中
4.3 参数调优经验
三、实践使用例
- 字节推荐中台基于HBase提供近在线读写推荐候选数据集
- 查询模式：批量查询指定tenantId租户指定的ChannelID频道下的推荐候选集，例如rowKey 对应数据等
- 商家订单系统使用HBase管理买家、卖家的订单操作信息
- 查询指定orderID订单最近新增、待处理的操作记录
- rowKey：e1cb：orderID1， column family：‘customer’
- Facebook使用HBase存储用户互动，包括电子邮件、即时消息、短信等
- 查询指定userID用户包含给定词语word的最近N条信息
- 写密集型的高吞吐场景
- 时序存储引擎，典型场景是日志、监控数据存储 例OpenTSDB
- 查询指定metric_uid指标在指定时间段的所有数据
- ByteTable
- 存储层基于字节分布式存储底座
- 采用C++编写，杜绝GC带来的性能抖动
- 架构设计上支持更细粒度，更灵活数据分片组织，激活更多优化空间
- 元数据设计提供更好的故障域控制，避免多租户相互影响
- 更短故障恢复时间，对在线场景高可用性支持更好
四、个人总结
本节课我们学习了HBase的相关内容。HBase不同于之前所接触的存储系统，是基于列存实现的NoSQL文件存储系统，其使用逻辑和调整与SQL数据库有很大不同，这也是我需要在今后进一步进行学习的。
