这是我参与「第四届青训营 」笔记创作活动的第4天
适用场景
1.什么是HBase
HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一。
参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。
采用存储计算分离架构
- 存储层基于HDFS存储数据，提供容错机制和高可靠性
- 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
提供强一致语义，在CAP理论中属于CP系统
2.HBase和关系型数据库的区别
3.HBase数据模型
HBase以列族（column family）为单位存储数据，以行键（rowkey）索引数据。
- 列族需要在使用前预先创建，列名（column qualifier）不需要预先声明，因此支持半结构化数据模型
- 支持保留多个版本的数据，（行键+列族+列名+版本号）定位一个具体的值
逻辑结构
HBase特点
- 适合稀疏数据，缺省列不占用存储空间
- 通过（rowkey，column family，column qualifier，version）唯一指定一个具体的值
- 允许批量读取多行的部分列族/列数据
物理结构
物理数据结构最小单位是key-value结构
- 每个版本的数据都携带全部列信息
- 同一行，同一列族的数据物理上连续有序存储
- 同列族内的Key-value按rowkey字典序升序，column qualifier升序，version降序排列
- 不同列族的数据存储在相互独立的物理文件，列族间不保证全局有序
- 同列族下不同物理文件间不保证数据全局有序
- 仅单个物理文件内有序
4.使用场景
适用场景
- 近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上
- 写密集型、高吞吐应用，可接受一定程度的时延抖动
- 字典序主键索引、批量顺序扫描多行数据的场景
- Hadoop大数据生态友好兼容
- 半结构化数据模型，行列稀疏的数据分布，动态增减列名
- 动敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
典型应用
- 心电商订单数据:查询最新/待处理订单进度
- 搜索推荐引擎:存储原始数据、排序推荐结果
- 广告数据流:触达、点击、转化等事件流
- 用户交互数据:IM、Email、点赞、搜索
- 时序数据引擎:日志、监控(OpenTSDB)
- 图存储引擎:JanusGraph
- 大数据生态:高度融入Hadoop生态
5.HBase数据模型的优缺点
架构设计
1.HBase架构设计
主要组件包括：
- HMaster:元数据管理，集群调度、保活。
- RegionServer:提供数据读写服务，每个实例 负责若干个互不重叠的rowkey区间内的数据。
- ThriftServer:提供Thrift API读写的代理层。
依赖组件包括：
- Zookeeper:分布式一致性共识协作管理，例如HMaster 选主、任务分发、元数据变更管理等。
- HDFS:分布式文件系统，HBase数据存储底座。
2.HMaster
主要职责
- 管理RegionServer 实例生命周期，保证服务可用性
- 协调RegionServer 数据故障恢复，保证数据正确性
- 集中管理集群元数据，执行负载均衡等维护集群稳定性
- 定期巡检元数据，调整数据分布，清理废弃数据等
- 处理用户主动发起的元数据操作如建表、删表等
主要组件
- ActiveMasterManager:管理HMaster的active/backup 状态
- ServerManager:管理集群内RegionServer的状态
- AssignmentManager:管理数据分片(region)的状态
- SplitWalManager:负责故障数据恢复的WAL拆分工作
- LoadBalancer:定期巡检、调整集群负载状态
- RegionNormalizer:定期巡检并拆分热点、整合碎片
- CatalogJanitor:定期巡检、清理元数据
- Cleaners:定期清理废弃的 HFile / WAL等文件
- MasterFileSystem:封装访问HDFS的客户端 SDK
3.RegionServer
主要职责
- 提供部分rowkey 区间数据的读写服务
- 如果负责meta表，向客户端 SDK提供 rowkey位置信息
- 认领HMaster 发布的故障恢复任务，帮助加速数据恢复过程
- 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等
主要组件
- MemStore:基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
- Write-Ahead-Log:顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
- Store:对应一个Column Family在一个region下的数据集合，通常包含多个文件
- StoreFile:即 HFile，表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
- BlockCache: HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取
4.ZooKeeper主要职责
- HMaster登记信息，对active/backup 分工达成共识
- RegionServer 登记信息，失联时HMaster保活处理
- 登记meta表位置信息，供 SDK查询读写位置信息
- 供HMaster 和RegionServer协作处理分布式任务
ThriftServer主要职责
- 实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
- 用户可根据IDL自行生成客户端实现
- 动独立于RegionServer 水平扩展，用户可访问任意ThriftServer 实例(scan操作较特殊，需要同实例维护scan状态)
大数据支撑
1.HBase在大数据生态的定位
- 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务;
- 支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据;
- 存储大规模任务（例如MapReduce，Spark，Flink)的中间/最终计算结果;
- 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问;
- 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。
2.水平扩展能力
- 增加RegionServer 实例，分配部分region 到新实例。
- 扩展过程平滑，无需搬迁实际数据。
- 可用性影响时间很短，用户基本无感知。
3.Region热点切分
- 当某个region 数据量过多，切分成两个独立的子region分摊负载。
- RegionServer在特定时机（flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition。
- 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。
切分点选取
HBase原生提供的多种切分策略使用相同的切分点选择策略
切分点选取目标是优先把最大的数据文件均匀切分
切分点选择步骤：
- 找到该表中哪个region的数据最大
2. 找到该region内哪个column family的数据最大
3. 找到column family内哪个HFile的数据最大
4. 找到HFile里处于最中间位置的DataBlock
5. 用这个Data Block的第一条Key Value的rowkey作为切分点
切分过程
- 所有Column Family都按照统一的切分点来切分数据。
- 目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。
- 每个新region分别负责原region 的上/下半部分rowkey 区间的数据。
- 在compaction执行前不实际切分文件，新 region下的文件通过reference file 指向原文件读取实际数据。
4.Region整合
- 当某些region数据量过小、碎片化，合并相邻 region 整合优化数据分布。
- AssignmentManager创建MergeTableRegionsProcedure执行整合操作。
- 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据。
- *注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。
5.负载均衡
定期巡检各RegionServer 上的 region 数量，保持region的数量均匀分布在各个RegionServer 上。
SimpleLoadBalancer 具体步骤:
- 根据总region数量和RegionServer 数量计算平均region 数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region 数为5，负载均衡的RS 上region 数量应该在[4,6]区间内。
- 将RegionServer按照region数量降序排序，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序;
- 选取出region数量低于下限的RegionServer列表，round-robin分配步骤⒉选取的regions,尽量使每个RS的region数量都不低于下限;
- 处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近。
StochasticLoadBalancer
- 随机尝试不同的 region放置策略，根据提供的cost function计算不同策略的分值排名(0为最优策略，1为最差策略);
- cost计算将卜列指标纳入统计:region负载、表负载、数据本地性(本地访问HDFS)、 Memstore大小、HFile大小。
- 根据配置加权计算最终cost，选择最优方案进行负载均衡;
FavoredNodeLoadBalancer
- 用于充分利用本地读写 HDFS文件来优化读写性能。
- 每个region 会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region 的数据;即使第一节点出现故障，HBase 也可以将第二节点提升为第一节点，保证稳定的读时延;
6.故障恢复机制
启动流程:
- 启动时去Zookeeper 登记自身信息，告知主HMaster实例有新RS实例接入集群
- 接收和执行来自HMaster的region调度命令
- 打开region前先从 HDFS读取该region的recovered.edits目录下的WAL记录，回放恢复数据
- 恢复完成，认领Zookeeper上发布的分布式任务（如WAL切分）帮助其他数据恢复
Distribute Log Split原理
背景:
- 写入HBase 的数据首先顺序持久化到Write-Ahead-Log，然后写入内存态的MemStore即完成，不立即写盘，RegionServer故障会导致内存中的数据丢失，需要回放WAL来恢复;
- 同RegionServer的所有region复用WAL，因此不同region的数据交错穿插，RegionServer故障后重新分配 region前需要先按region维度拆分WAL
实现原理：
- RegionServer故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端
- active HMaster监听到RS 临时节点删除事件，从 HDFS梳理出该RS负责的WAL文件列表
- HMaster为每个WAL文件发布一个log split task到ZK
- 其他在线的RS监听到新任务，分别认领
- 将WAL entries按region拆分，分别写入HDFS上该region的recovered.edits目录
- HMaster 监听到 log split任务完成，调度region到其他 RS
- RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region恢复读写服务
进—步优化: Distributed Log Replay
- HMaster先将故障RegionServer上的所有region以Recovering状态调度分配到其他正常RS上;
- 再进行类似Distributed Log Split的WAL日志按region维度切分;
- 切分后不写入HDFS,而是直接回放，通过SDK写流程将WAL记录写到对应的新RS;
- Recovering 状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成。
最佳实践
1.rowkey设计策略
场景分类
1.不需要顺序扫描批量连续rowkey
对原始rowkey 做哈希（如MD5)，作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。
2.需要顺序扫描批量连续rowkey
首先用grouplDlapplD/userID前缀避免数据热点，然后加上定义顺序的信息（如时间戳等)ID前缀也建议哈希处理，避免非预期的热点。 e.g.MD5(groupID):grouplD:timestamp:...
3.rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。
避免用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RegionServer 上，造成热点瓶颈，且无法通过水平扩容缓解。
2.lumn family设计策略
1.Column family数量过多容易影响性能，建议尽量少，不超过5个。
2.需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，
读取时尽量只读取必需的列族，避免读不必要的列族。
3.列族（以及column qualifier）名称尽量短，因为会冗余存储到每个KeyValue 中。
