这是我参与「第四届青训营 」笔记创作活动的第7天！
一、HBase适用场景。
1.什么是Hbase？
HBase 一个开源的NOSQL分布式数据库，是Apache 软件基金会顶级项目之一。
参考Google BigTable 的设计，对稀疏表提供更高的存储空间使用率和读写效率。
采用存储计算分离架构
- -存储层基于HDFS 存储数据，提供容错机制和高可靠性；
- -计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力；
提供强一致语义,在CAP理论中属于CP系统。
- Consistency, Availability， Partition Tolerance
2.Hbase和关系型数据库的区别：
3.HBase数据模型：
HBase 以列族(column family )组织数据，以行键(rowkey)索引数据。
- 列族需要在使用前预先创建，列名(column qualfer ) 不需要预先声明，因此支持半结构化数据模型。
- 支持保留多个版本的数据，(行键+列族+列名+版本号)定位一个具体的值。
3.1 HBase数据模-逻辑结构：
通过非关系型视图理解HBase 数据模型：
- 适合稀疏数据，缺省列不占用存储空间。
- 通过(rowkey, column family, column qualfier, version）
- 唯一指定一个具体的值
- 允许批量读取多行的部分列族/列数据,
3.2 HBase数据模-物理结构：
- 物理数据结构最小单元是KeyValue 结构:
- 每个版本的数据都携带全部行列信息
- 同一行,同一列族的数据物理上连续有序存储。
- 同列族内的KeyValue 按rowkey字典序升序column qualifier 升序 version 降序排列。
- 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序。
- 同列族下不同物理文件间不保证数据全局有序。
- 仅单个物理文件内有序。
4.使用场景：
适用场景:
- 近在线”的海量分布式 KV/宽表存储，数据量级可达到PB级以上
- 写密集型、高吞吐应用 可接受一定程度的时延抖动
- 字典序主键索引、批量顺序扫描多行数据的场景
- Hadoop 大数据生态友好兼容
- 半结构化数据模型,行列稀疏的数据分布，动态增减列名
- 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
典型应用：
- 电商订单数据:查询最新/待处理订单进度
- 搜索推荐引擎:存储原始数据、 排序推荐结果
- 广告数据流:触达、点击、转化等事件流
- 用户交互数据:IM、Emaill.点赞、搜索
- 时序数据引擎：日志、监控(OpenTSDB)
- 图存储引擎:JanusGraph
- 大数据生态:高度融入Hadoop 生态
4.1 半结构化/字典序有序索引的数据
典型用例:
- 字节跳动推荐中台基于HBase 提供“近在线”读写的推荐候选数据集
数据格式：
查询模式:
批量查询指定tenantID 租户的指定channellD 频道下的推荐候选集。例如:
- start rowkey: "part1:tenant1:channel1",
- end rowkey："part1:tenant1:channel2",
对应数据：
- value: "features (e.g. sport, basketball,...)"
- columns: "additional labels (e.g. region=CN,...)"
4.2 “近在线” 海量分布式 KV/宽表存储
典型用例:
- 商家订单系统使用 HBase 管理买家、卖家的订单操作信息
数据格式：
查询模式:
查询指定orderID订单最近新增/特处理的操作记录。 例如:
rowkey: "e1cb:orderlD1",column family: "customer"
对应多个column的数据:
- column1: actionType1 actionlD1, value1:"{timestamp-21,action='...}",
- column2: actionType2 actionlD2，value2:"{timestamp-26, action='...}",
- column3: checkpoint, value: “timestamp=23”
典型用例:
- Facebook 在2010年开始使用HBase存储用户的互动消息，包括电子邮件、 即时消息、短信等
数据格式：
查询模式:
查询指定userID用户包含给定词语 word的最近N条消息的messagelD. 例如：
rowkey:"userlD1"，column:"cf.hello"对应多个版本的数据:
- value1:"offset-23",version: "messagelD=1234"
- value2:“offset=12" ,version:"messagelD=1134"
- value3:“offset=41" ,version: "messagelD=1034"
4.3写密集型的高吞吐场景：
典型用例:
- 时序存储引摩，典型场录日志、 监控政存储， 例如 OpenTSDB（ Open Time Series Database )
数据格式：
查询模式:
查询指定metric uid 指标在指定时间段的所有数据。例如:
start rowkey:"[hash]metric1:1655386954",
end rowkey:"[hash]metric1:1665386954",
column family:"dp",
查询1655386954到1665386954时间内该监控的所有数据点。
*rowkey和column 通过编码尽量简短，减少空间用量。
5.HBase数据模型的优缺点：
二、Hbase架构设计。
1.Hbase架构设计。
主要组件包括:
- HMaster:元数据管理，集群调度、保活。
- RegionServer :提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据.
- ThriftServer :提供 Thrit API 读写的代理层。
依赖组件包括:
- Zookeeper :分布式一致性共识协作管理，例如HMaster选主、任务分发、 元数据变更管理等。
- HDFS :分布式文件系统,HBase 数据存储底座。
2.HMaster 主要职责：
- 管理RegionServer 实例生命周期，保证服务可用性
- 协调RegionServer 数据故障恢复，保证数据正确性
- 集中管理集群元数据，执行负载均街等维护集群稳定性
- 定期巡检元数据，调整数据分布，清理度弃数据等
- 处理用户主动发起的元数据操作如建表、删表等
主要组件：
- ActiveMasterManager:管理 HMaster的 active/backup 状态
- ServerManager :管理集群内 RegionServer 的状态
- AssignmentManager:管理数据分片(region)的状态
- SplitWalManager :负责故障数据恢复的WAL拆分工作
- LoadBalancer :定期巡检、 调整集群负载状态
- RegionNormalizer:定期巡检并拆分热点、整合碎片
- CatalogJanitor :定期巡检、 清理元数据
- Cleaners :定期清理废弃的HFle/WAL 等文件
- MasterFileSystem:封装访问HDFS 的客户端SDK
3.RegionServer 主要职责：
- 提供部分 rowkey 区间数据的读写服务
- 如果负责meta表，向客户端SDK提供rowkey 位置信息
- 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
- 处理 HMaster 下达的元数据操作，如reglon打开/关闭分製/合井操作等
主要组件：
- MemStore :基于 SkipList数据结构实现的内存态存储，定期批量写入硬盘
- Wite-Ahead-Log:顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
- StoreFile:即HFile，表示HBase在HDFS 存储数据的文件格式，其内数据按 rowkey 字典序有序排列
- BlockCache:HBase 以以数据块为单位读取数据并缓存在内存中以加速重复数据的读取
4.ZooKeeper主要职责：
- HMaster 登记信息，对 activelbackup 分工达成共识
- RegionServer登记信息，失联时HMaster 保活处理
- 登记 meta表位置信息，供SDK查询读写位置信息
- 供HMaster和RegionServer 协作处理分布式任务
5.ThriftServer 主要职责：
- 实现HBase 定义的Thrit API，作为代理层向用户提供RPC读写服务
- 用户可根据IDL自行生成客户端实现
- 独立于RegionServer水平扩展，用户可访问任意 ThritServer 实例(scan 操作较特殊，需要同实例雌护scan 状态)
三、大数据支撑。
1.HBase在大数据生态的定位：
- 对TB、PB 级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务；
- 支持字典序批量扫描大量数据，支持只读取部分列族的数据灵活支持不同查询模式，避免读取不必要的数据；
- 存储大规模任务(例如 MapReduce, Spark, Flink)的中间/最终计算结果；
- 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问；
- 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。
2.水平扩展能力：
- 增加RegionServer 实例,分配部分region 到新实例。
- 扩展过程平滑，无需搬迁实际数据。
- 可用性影响时间很短，用户基本无感知。
3.Region热点切分：
- 当某个region 数据量过多，切分成两个独立的子 region 分摊负载。
- RegionServer在特定时机(fush compaction )检查 reg lon 是否应该切分，计算切分点并RPC 上报HMaster,由AssignmentManager 负责执行 RegionState Transition.
- 不搬迁实际数据，切分产生的新 region 数据目录下生成一 个以原rogion 文件信息命名的文件，内容是切分点对应的rowkey,以及标识新 region 是上门半分的数据。
3.1 Region热点切分-切分点选取：
HBase 原生提供的多种切分策略使用相同的切分点选择策略。
目标:优先把最大的数据文件均匀切分。
切分点选择步骤：
1.找到该表中哪个region 的数据大小最大
2.找到该region内哪个 column family的数据大小最大。
3.找到 column family 内哪个HFile的数据大小最大。
4.找到HFile里处于最中间位置的 Data Block；
5.用这个Data Block的第一条 KeyValue 的Row可以作为切分点。
3.2Region热点切分-切分过程：
- 所有Column Family 都按照统一的切分点来切分数据。
- 目的是优先均分最大的文件，不保证所有 Column Family的所有文件都被均分
- HFile 1 作为最大的文件被均分，其他文件也必须以相 司的 rowkey 切分以保证对齐新 region 的 rowkey 区间。
- 切分出的新 region 分别负责 rowkey 区间(2000.2500)和（2500.4000)
- 每个新rogion分别负责原rogjon的上/下半部分wkey区间的数器。
- 在compaction 执行前不实标切分文件,新region下 的文件通过relerence fle 指向原文件读取实际数据。
3.3流程设计：
AssignmentManager 检查 cluster, table. reglon 的状态 ，创建SpltTableRegionProcedure 通过状态机实现执行切分过程。
4.碎片整合：
- 当某些region 数据量过小、碎片化，合并相邻region 整合优化数据分布。
- AssignmentManager 创建 MergeTableRegionsProcedure 执行整合操作。
- 不搬迁实际数据,通过reference flle 定位原regi on 的文件，直到下次 compaction 时实际处理数据.
- 注意：只允许合并相部reglon 百则会打啵 rowkey空间连续且不重合的约定。
4.1 Region碎片整合-流程设计：
类似于region 切分，不立刻处理实际数据文件，而是通过创 建 reference files 引用到原文件，然后原子地更新元数据来完成碎片整合，后续靠 compaction 整合数据文件, 靠 CatalogJanitor 异步巡检元数据处理进留数据。
5.Region 负载均衡。
定期巡检各RegionServer 上的region 数量，保持 region 的数最均匀分布在各个RagionServer 上。
SimpleLoadBalancer具体步骤：（调度策略）
1.根据总region 数量和RegionServer 数量计算平均 region数，设定弹性上下界避免不必要的操作。例如默认 slop为0.2，平均region数为5,负载均衡的RS 上 region数量应该在[4,6]区间内。
2.将RegionServer 按照 region 数量降序排序，对region数量超出上限的选取要迁出的region并按创建时间从新到老排序;
3.选取出region 数量低于下限的RegionServer列表，round-robin 分配步骤2选取的regions 尽量使每个RS的region 数量都不低于下限；
4.处理边界情况，无法满足所有RS的 region 数量都在合理范围内时，尽量保持region 数量相近。
其他策略：
- StochasticLoadBalancer
- 随机尝试不同的 region 放置策略，根据提供的 cost function 计算不同策略的分值排名(0为最优策略，1为最差策略)；
- cost 计算将下列指标纳入统计: region 负表负载、数据本地性（本地讨 间HDFS)、Momstore 大小、HFile 大小。
- 根据配置加权计算最终 cost,选择最优方案进行负载均衡；
- FavoredNodeLoadBalancer
- 用于充分利用本地读写HDFS 文件来优化读写性能
- 每个region 会指定优选的3个RegionServer 地址，同时会告知HDFS在这些优选节点上放置该region的数据；
- 即使第一节点出现故障，HBase也可以将第二节点提升为第一节点,保证稳定的读时延；
6.故障恢复机制-HMaster：
HMaster通过多次实例基于ZooKeeper选主实现高可用性。
- 所有实例尝试向 Zookeeper的/hbase/active-master 临时节点 CAS 地写入自身信息，
- 写入成功表示成为主实例，失败即为从实例通过 watch 监听/base/active-master 节点的变动。
- 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主。
HMaster恢复流程：
1.HMaster自身恢复流程：
- 监听到 /hbase/active-master 临时节点被删除的事件，触发选主逻辑；
- 选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures从之前状态继续执行；
- 故障HMaster实例恢复后发现主节点已存在，继续监听 /hbase/active-master.
2.调度 RegionServer 的故障恢复流程：
- AssignmentManager 从 procedure 列表中找出R egion-ln-Transition 状态的 region 继续调度过程；
- RegionServerTracker 从 Zookeeper 梳理online 状态的 RegionServer 列表，结合 ServerCrashProcedure 列表HDFS 中 WAL 目录里 aive/ spliting 状态的 RegionServer记录，获取掉线 RegionServer的列表，分别创建 ServerCrashProcedure 执行恢复流程。
7.故障恢复机制-RegionServer：
- 每个RegionServer实例启动时都会往 Zookee per的 hbase/rs 路径下创建对应的临时节点。
- HMaster 通过监听ReglonServer 在 Zookeeper的临时节 点状态，监控数据读写服务的可用性，及时调度恢复不可用的 regions.
- RegionServer 的故障恢复需要将内存中丢失的数掘# 人WAL 中恢复，HMaster 利用 Zookeeper配合所有RegionServer 实例，分布式地处理 WAL 数据，提升恢复速度。
7.1恢复流程：
启动流程：
- 启动时去 Zookeeper 登记自身信息，告知主HMaster 实例有新RS 实例接入集群
- 接收和执行来自HMaster的 region 调度命令
- 打开 region 前先从HDFS 读取该region 的 recc wered.edits 目录下的 WAL 记录，回放恢复数据
- 恢复完成，认领Zookeeper 上发布的分布 式任务（如WAL 切分）帮助其他数据恢复
8.Distributed Log Split 原理：
背景:
- 写入HBase 的数据首先顺序持久化到 Write-Ahead-Log,然后 写入内存态的MermSlore 即完成，不立即写盘,RegionServer故障会导致内存中的数据丢失，需要回放WAL 来饮复；
- 同ReglonServer 的所有region复用WAL，因此不间region 的 文据交始穿插，RegionServer故障后重新分配region 前需要先按region 维度拆分 WAL.
8.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 监听到log splt 任务完成，调度region 到其他RS
7.RS 打开reglon 前在 HDFS 找到先回放recovered.edits 目录下的WAL 文件将数据恢复到 Memstore里，再打开region 恢复读写服务
8.2优化空间：
进一步优化:Distributed Log Replay
- HMaster 先将故障 RegionServer 上的所有regior 以Recovering 状态调度分配到其他正常RS上;
- 再进行类似 Distrbuted Log Splt 的 WAL 日志按 region 维度切分;
- 切分后不写入HDFS，而是直接回放,通过 SDK 写流程将 WAL 记录写到对应的新RS:
- Recovering 状态的region 接受写请求但不 是供读服务，直到 WAL 回放数据恢复完成。
四、最佳实践分享。
1.Rowkey设计策略：
场景分类：
1.不需要顺序扫描批量连续rowkey
- 对原始rowkey做哈希(如 MD5) 作为真实 rowkey的前缀。
- 建议取适当长度的子串，避免过多占用存储空间。
2.需要顺序扫描批量连续rowkey
- 首先用grouplDlappIDuserlD 前级避免数据热点，然后加上定义顺序的信息(如时间#等)ID前级也建议哈希处理，避免非预期的热点。
- e.g.MD5(grouplD):grouplD:timestamp:
3.rowkey 长度尽量保持较短，因为会冗余存储到每个KeyValue中。
避免用时间戰直接作为rowkey前级，会导致最 的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通过水平扩容缓解。
2.Column Family 设计策略：
1.Column family 数量过多容易影响性能，建议尽量少，不超过5个。
2.需要同时读取的数据尽量放在相同列族,反之尽量放在不同列族读取时尽量只读取必需的列族，避免读不必要的列族。
3.列族(以及column qualifer)名称尽量短，因为会冗余存储到每个 KeyValue 中。
3.参数调优经验：
4.ByteTable-字节跳动自研分布式表格存储系统
优势:
- 存储层基于字节跳动自研分布式存储底座，从设计上充分支持在线场景的性能、功能需求；
- 采用C++编写构建，杜绝了 Garbage Collection 在 Stop-The-World 阶段带来的性能抖动；
- 架构设计上支持更细粒度、 更灵活的数据分片组织方式，激活更多优化空间；
- 元数据设计提供更好的故障域控制，避免多租户相互影响；
- 更短的故障恢复时间，对在线场景的高可用性支持更好；
总结
经过本次学习，我了解了HBase是通过HMaster管理员数据、调度保活；RegionServer提供数据读写；以来ZooKeeper协调调度、组件探活；基于HDFS存储底座实现存储计算分离架构的。可见HBase是多方共同协调来运行的。热点切分可以避免数据分布倾斜带来的性能瓶颈等。
