这是我参与「第四届青训营 」笔记创作活动的第10天
1.适用场景
介绍HBase的设计理念、数据模型、适用场景、业界典型用例
①什么是HBase
HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一
参考Google Big Table的设计，对稀疏表提供更高的存储空间使用率和读写效率
采用存储计算分离架构
- 存储层基于HDFS存储数据，提供容错机制和高可靠性
- 计算曾提供灵活快速的水平扩展、负载均衡和故障恢复能力
提供强一致语义，在CAP理论中属于CP系统
- Consistency、Availability、Partition Tolerance
②HBase和关系型数据库区别
③HBase数据模型
HBase是半结构化数据模型，HBase以列族组织数据，以行键索引数据
- 列族需要在使用前预先创建，列名不需要预先声明，因此支持半结构化数据模型
- 支持保留多个版本的数据，（行键+列族+列名+版本号）定位一个具体的值
逻辑结构
-
通过非关系型视图理解HBase数据模型
- 适合稀疏数据，缺省列不占用存储空间
- 通过（行键+列族+列名+版本号）唯一指定一个具体的值
- 允许批量读取多行的部分列族/列数据
物理结构
-
物理数据结构最小单元是KeyValue结构
-
每个版本的数据都携带全部行列信息（所以有一定程度上的数据冗余）
-
同一行，同一列族的数据物理上连续有序存储
-
同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列
-
不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
-
同列族下不同物理文件间不保证数据全局有序
-
仅单个物理文件内有序
- 首先4B标记key的长度，绿色部分全是key（key type：数据类型，Put/Delete，HBase删除数据并不是立即删除，而是写入一条记录，带上delete标记）
- 然后是value的长度（4B）以及value的值
④使用场景
适用场景
- “近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上
- 写密集型、高吞吐应用，可接受一定程度的时延抖动
- 字典序主键索引、批量顺序扫描多行数据的场景
- Hadoop大数据生态友好兼容
- 半结构化数据模型，行列稀疏的数据分布，动态增减列名
- 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
典型应用
- 电商订单数据：查询最新/待处理订单进度
- 搜索推荐引擎：存储原始数据、排列推荐结果
- 广告数据流：触达、点击、转化风事件流
- 用户交互数据：IM、Email、点赞、搜索
- 时序数据引 擎：日志、监控（OpenTSDB）
- 图存储引擎：JanusGraph
- 大数据生态：高度融入Hadoop生态
2.架构设计
介绍HBase的整体架构设计、主要模块设计
①HBase架构设计
主要组件
- HMaster：元数据管理，集群调度、保活。可以感知集群内是否有其他组件宕机，及时调度确保集群可用性
- RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
- ThriftServer：提供Thrift API读写的代理层
依赖组件
- Zookeeper：分布式一致性共识协作管理，如：HMaster选主、任务分发、元数据变更管理等
- HDFS：分布式文件系统，HBase数据存储底座
②HMaster主要职责
- 管理RegionServer实例生命周期，保证服务可用性
- 协调RegionServer数据故障恢复，保证数据正确性
- 集中管理集群元数据，执行负载均衡等维护集群稳定性
- 定期巡检元数据，调整数据分布，清理废弃数据等
- 处理用户主动发起的元数据操作如建表、删表等
主要组件（其实是对HMaster不同职责的封装）
- ActiveMasterManager：管理HMaster的active/backup状态（HMaster自身基于Zookeeper进行多实例之间的选主）
- ServerManager：管理集群内RegionServer的状态
- AssignmentManager：管理数据分片（region）的状态
- SplitWalManager：负责故障数据恢复的WAL拆分工作
- LoadBalancer：定期巡检、调整集群负载状态
- RegionNormalizer：定期巡检并拆分热点、整合碎片
- CatalogJanitor：定期巡检、清楚元数据
- Cleaners：定期清理废弃的HFile/WAL文件
- MasterFileSystem：封装访问HDFS的客户端SDK
③RegionServer主要职责
- 提供部分rowkey区间数据的读写服务
- 如果负责meta表，向客户端SDK提供rowkey位置信息
- 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
- 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等
主要组件
- MemStore：基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
- Write-Ahead_Log：顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据（数据不会直接写到磁盘上，而是先写到WAL，而后写到MemStore）
- StoreFile：（物理上的存储在磁盘上的文件）即HFile，表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列（MemStore中存储的数据达到一定的量会刷写到StoreFile中）
- BlockCache：HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取
④Zookeeper主要职责
HMaster登记信息，对active/backup分工达成共识
RegionServer登记信息，失联时HMaster保活处理
登记meta表位置信息，供SDK查询读写位置信息
供HMaster和RegionServer协作处理分布式任务
⑤ThriftServer主要职责
实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
用户可根据IDL自行生成客户端实现
独立于RegionServer水平扩展用户可访问任意ThriftServer实例（scan操作较特殊，需要同实例维护scan状态）
3.大数据支撑
介绍HBase针对海量数据场景所做的设计优化，包括水平扩展能力、负载均衡策略、故障恢复机制
①HBase在大数据生态的定位
- 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务
- 支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据
- 存储大规模任务（如MapReduce，Spark，Flink）的中间/最终计算结果
- 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问
- 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费
②水平扩展能力
增加RegionServer实例，分配部分region到新实例
扩展过程平滑，无需搬迁实际数据（只是将HDFS的file分属到不同的RegionServer去调度）
可用性影响时间很短，用户基本无感知
③Region热点切分
- 当某个region数据量过多，切分成两个独立的子region分摊负载
- RegionServer在特定时机（flush、compaction）检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition
- 不搬迁实际数据，切分产生的新的region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新的region的上/下半部分的数据（在切分点临时生成一个.splits文件，然后生成真正切分文件，并且根据切分文件可以找到原始文件）
切分点选取
-
HBase原生提供的多种切分策略使用相同的切分点选择策略
-
目标：优先把最大的数据文件均匀切分
-
切分点选择步骤
-
找到该表中哪个region的数据大小最大
-
找到该region中哪个column family的数据大小最大
-
找到column family中哪个HFile的数据大小最大
-
找到HFile中处于最中间位置的Data Block
-
用这个Data Block的第一条KeyValue的Rowkey作为切分点
-
切分过程
-
所有Column Family都按照统一的切分点来切分数据
-
目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分
-
HFile 1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region的rowkey区间
-
切分出的新的region分别负责rowkey区间[2000,2500)和[2500,4000)
-
每个region分别负责原region的上/下半部分rowkey区间的数据
-
在compaction执行前不实际切分文件（只是概念上的切分），新region下的文件通过reference file指向源文件读取实际数据
-
而后HMaster将两个新的region调度到不同的server上，就实现了热点的一分为二
流程设计（代码层面）
- AssignmentManager检查cluster、table、region的状态后，创建SplitTableRegionProcedure通过状态机实现执行切分过程
④Region碎片整合
- 当某些region数据量过小、碎片化，合并相邻region整合优化数据分布
- AssignmentManager创建MergeTableRegionsProcedure执行整合操作
- 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据
- 注意：只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定
流程设计
- 类似于region切分，不立刻处理实际数据文件，而是通过创建reference files引用到原文件，然后原子地更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠CatalogJanitor异步巡检元数据处理遗留数据
⑤Region负载均衡
定期巡检各RegionServer上的region数量，保持region的数量均匀分布在各个RegionServer上
SimpleLoadBalancer具体步骤
-
根据总region数量和ReginoServer数量计算平均region数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region数为5，负载均衡的RS上region数量应该在[4,6]区间内
-
将RegionServer按照region数量降序排列，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序
-
选取出region数量低于下限的RegionServer列表，round-robin（因为相邻的region可能热点集中，便于分摊热点）分配步骤2选取的regions，尽量使每个RS的region数量都不低于下限
-
处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近
⑥故障恢复机制-HMaster
HMaster通过多实例基于Zookeeper选主实现高可用性
-
所有实例尝试向Zookeeper的hbase/active-master临时节点CAS地写入自身信息
-
写入成功表示成为主实例，失败即为从实例，通过watch监听hbase/active-master节点的变动
-
主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主
HMaster恢复流程
-
HMaster自身回复流程
- 监听到hbase/active-master临时节点被删除的事件，触发选主逻辑
- 选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures从之前状态继续执行
- 故障HMaster实例恢复后发现主节点已存在，继续监听hbase/active-master
-
调度RegionServer的故障恢复流程
- AssignmentManager从procedure列表中找出Region-In-Transitino状态的region继续调度过程
- RegionServerTracker从Zookeeper梳理online状态的RegionServer列表，结合ServerCrashProcedure列表、HDFS中WAL目录里alive/splitting状态的RegionServer记录，获取掉线RegionServer列表，分别创建ServerCrashProcedure执行恢复流程
⑦故障恢复机制-RegionServer
⑧Distributed 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 splits任务完成，调度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回放数据恢复完成
4.最佳实践
分享HBase实战经验总结与最佳实践
