这是我参与「第四届青训营 」笔记创作活动的的第10天。
本节课程主要分为 4 个方面：
1.使用场景
2.架构设计
3.大数据支持
4.最佳实践
一.使用场景
1.1.什么是HBase？
HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一
采用存储计算分离架构：
■ 存储层基于HDFS存储数据，提供容错机制和高可靠性；
■ 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力。
1.2.HBase和关系型数据库的区别
✔ 数据结构：
□ HBase：半结构化，无数据类型；按列族稀疏存储，缺省数据不占用存储空间；支持多版本数据。
□ Relational DB：结构化，数据类型丰富；按完整行存储，缺省的列需要存储占位符；不支持多版本数据。
✔ 读写模式
□ HBase：支持按需读写部分列
□ Relational DB：必须整行读取
✔ 事务支持
□ HBase：仅支持单行内原子性
□ Relational DB：支持完整的事务语义
✔ 数据规模
□ HBase：只用于TB、PB级海量数据，水平扩展快速平滑
□ Relational DB：仅适用于GB、小量TB级，扩展过程较复杂
✔ 索引支持
□ HBase：仅支持rowkey主键索引
□ Relational DB：支持二级索引
1.3.HBase数据模型
HBase以列族(Column Family)为单位存储数据，以行键(rowkey)索引数据。
✔ 列族需要在使用前预先创建，列行(column qualifier)不需要预先声明，因此支持半结构化数据模型。
✔ 支持保留多个版本的数据，(行键+列族+列名+版本号)定位一个具体的值。
1.3.1.逻辑结构
✔ 适合稀疏数据，缺省列不占用存储空间
✔ 通过(rowkey,column family,column qualifier,version)唯一指定一个具体的值
✔ 允许批量读取多行的部分列族/列数据
1.3.2.物理结构
✔ 每个版本的数据都携带全部行列信息。
✔ 同一行，同一列族的数据物理上连续有序存储。
✔同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列。
✔ 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
✔ 同列族下不同物理文件间不保证数据全局有序。
✔ 仅单个物理文件有序。
1.4.使用场景
○ “近在线”的海量分布式KV/宽表存储，数据量级达到百TB级以上
○ 写密集型应用，高吞吐，可接受一定的时延抖动
○ 需要按行顺序扫描的能力
○ 接入Hadoop大数据生态
○ 结构化、半结构化数据，可以经常新增/更新列属性
○ 平滑的水平扩展
1.4.1.典型应用
○ 电商订单数据：查询最新/待定订单进度
○ 搜索推荐引擎：存储原始数据、排序推荐结果
○ 广告数据流：触达、点击、转化等事件流
○ 大数据生态：高度融入Hadoop生态
1.5.HBase数据模型的优缺点
优点：1).稀疏表友好，不存储缺省列，支持动态新增列类型
2).支持保存多版本数据
3).支持只读取部分column family的数据，避免读取不必要的数据
4).支持的数据规模相比传统关系型数据库更高，更易水平扩展
5).支持rowkey字典序批量扫描数据
缺点：1).每条数据都要冗余存储行列信息
2).不支持二级索引，只能通过rowkey索引，查询效率依赖rowkey设计
3).column family数量较多时可能引发性能衰退
4).不支持数据类型，一律按字节数组存储
5).仅支持单行内的原子性操作，无跨行事务保障
二.架构设计
2.1.HBase架构设计
主要组件包括：HMaster、RegionServer、ThriftServer
依赖组件包括：Zookeeper、HDFS
2.2.HMaster主要职责
◌ 管理RegionServer实例生命周期，保证服务可用性
◌ 协调RegionServer数据故障恢复，保证数据准确性
◌ 集中管理集群元数据，执行负载均衡等维护集群稳定性
◌ 定期巡检元数据，调整数据分布，清理废弃数据等
◌ 处理用户主动发起的元数据操作如建表、删表等
2.2.1.HMaster-主要组件
◌ CatalogJanitor：定期扫描元数据hbase:meta的变化，回收无用的region(仅当没有region-in-transition时)。
◌ AssignmentManager：管理region分配，processAssignQueue方法每当pendingAssignQueue放满RegionStateNode时批量处理。单独启动daemon线程循环处理。
2.3.RegionServer主要职责
● 提供部分rowkey区间数据的读写服务
● 如果负责meta表，向客户端SDK提供rowkey位置信息
● 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
● 处理HMaster下达的元数据操作。
2.3.1.RegionServer-组要组件
●MemStore ● Store
2.4.Zookeeper主要职责
◆ HMaster登记信息，对active/backup分工达成共识
◆ RegionServer登记信息，失联时HMaster保活处理
◆ 登记meta表位置信息，供SDK查询读写位置信息
◆ 供HMaster和RegionServer协作处理分布式任务
2.5.ThriftServer主要职责
◇ 实现HBase定义的Thrift API，作为代理层向用户提供RPC读写服务
◇ 用户可根据IDL自行生成客户端实现
◇ 独立于RegionServer水平扩展，用户可访问任意ThriftServer实例。
三.大数据支撑
3.2.水平扩展能力
✔ 增加RegionServer实例，分配部分region到新实例。
✔ 扩展过程平滑，无需搬迁实际数据。
✔ 可用性影响时间很短，用户基本无感知
3.3.Region热点切分
○ 当某个region数据量过多，切分成两个独立的子region分摊负载。
○ RegionServer在特定时机(flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition。
○ 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。
3.3.1.Region热点切分-切分点选取
HBase原生提供的多种切分策略使用相同的切分点选择策略
切分点选择步骤：
1).找到该表中哪个region的数据大小最大；
2).找到该region内哪个column family的数据大小最大；
3).找到column family内哪个HFile的数据大小最大；
4).找到HFile里处于最中间位置的Data Block；
5).用这个Data Block的第一条KeyValue的Rowkey作为切分点。
3.3.2.Region热点切分-切分过程
1).所有Column Family都按照统一的切分点来切分数据；
2).目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分；
3).每个新region分别负责原region的上/下半部分rowkey区间的数据；
4).在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。
3.3.3.Region热点切分-流程设计
AssignmentManager检查cluster、table、region的状态后，创建SplitTableRegionProcedure通过状态机实现执行切分过程。
3.4.Region碎片整合
◌ 当某些region数据量过小、碎片化，合并相邻region整合优化数据分布；
◌ AssignmentManager创建MergeTableRegionProcedure执行整合操作；
◌ 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据。
注：只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。
3.4.1.Region碎片整合-流程设计
类似于region切分，不立刻处理实际数据文件，而是通过创建reference file引用原子地更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠CatalogJanitor异步巡检元数据处理遗留数据。
3.5.Region负载均衡
定期巡检各RegionServer上地region数量，保持region地数量均匀分布在各个RegionServer上。
▷ SimpleLoadBalancer
3.5.1.Region负载均衡-其他策略
▷ StochasticLoadBalancer
▷ FavoredNodeLoadBalancer
3.6.故障恢复机制-HMaster
HMaster通过多实例基于Zookeeper选主高可用性
3.6.1.故障恢复机制-HMaster恢复流程
一.HMaster自身恢复流程：
▶ 监听到/hbase/active-master临时节点被删除地事件，触发选主逻辑；
▶ 选主成功后执行HMaster启动流程，从持久化存储读取未完成地procedures从之前状态继续执行；
▶ 故障HMaster实例恢复后发现主节点已存在，继续监听/hbase/active-master。
二.调度RegionServer地故障恢复流程：
▶ AssignmentManager从procedure列表中找出Region-In-Transition状态地region继续调度过程；
▶ RegionServerTracker从Zookeeper梳理online状态地RegionServer列表，结合ServerCrashProcedure列表、HDFS中WAL目录里ailve/splitting状态地RegionServer记录，获取掉线RegionServer地列表，分别创建ServerCrashProcedure执行恢复流程。
3.7.故障恢复机制-RegionServer
✔ 每个RegionServer实例启动时都会往Zookeeper地/hbase/rs路径下创建对应地临时节点；
✔ HMaster通过监听RegionServer在Zookeeper地临时节点状态，监控数据读写服务地可用性，及时调度恢复不可用的region；
✔ RegionServer的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster利用Zookeeper配合所有RegionServer实例，分布式地处理WAL数据，提升恢复速度。
3.7.1.故障恢复机制-RegionServer恢复流程
◈ 启动时去Zookeeper登记自身信息，告知主HMaster实例有新RS实例接入集群；
◈ 接受和执行来自HMaster地region调度命令；
◈ 打开region前先从HDFS读取region的recovered。edits目录下的WAL记录，回放恢复数据；
◈ 恢复完成，认领Zookeeper上发布的分布式任务(如WAL切分)帮助其他数据恢复。
3.8.Distributed Log Split原理-具体流程
1).RegionServer故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端；
2).active HMater监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表；
3).HMaster为每个WAlk文件发布一个log split task到ZK；
4).其他在线的RS监听到新任务，分别认领；
5).将WAL entries按region拆分，分别写入HDFS上该region的recovered.edits目录；
6).HMaster监听到log split任务完成，调度region到其他RS；
7).RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region恢复读写服务。
3.8.1.Distributed Log Split原理-优化空间
□ HMaster先将故障RegionServer上的所有region以Recovering状态调度分配到其他正常RS上；
□ 再进行类似Distributed Log Split的WAL日志按region维度切分；
□ 切分后不写入HDFS，而是直接回放，通过SDK写流程将WAL记录写到对应的新RS；
□ Recovering状态的region接受写请求但不提供读服务，直接WAL回放数据恢复完成。
四.最佳实践
4.1.Rowkey设计策略
◆ 最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes。key在保证功能的前提下建议越短越好，因为key是冗余到每个cell存储的，过长的key会占用更多存储、缓存空间。
◆ 设计Key时，要充分利用排序存储这个特性，将经常一起读取的行存储到一起。HBase以HFile文件块为单位从HDFS读取数据，一次性读出相邻相关数据可以达到随机读变成顺序读的效果。 但同时要防止出现热key聚焦打爆region server实例。
反例：以时间戳作rowkey前缀，一段时间的请求会全部打到同一regionserver。
4.2.Column Family设计策略
1).Column family数量过多容易影响性能，建议尽量少，不超过5个；
2).需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必须的列族，避免读不必要的列族；
3).列族(以及column qualifier)名称尽量短，因为会冗余存储到每个KeyValue中。
4.3.参数调优经验
◇ client参数调优：
◎ nodelay设置true；
◎ 读较多的应用中gc的新生代不能设置太小；
◎ 数据版本尽可能少来增加有效缓存容量，提升命中率；
◎ 避免一次scan过多的row，尽量拆分为多次小规模scan作分页查询。
