这是我参与「第五届青训营 」伴学笔记创作活动的第 26 天
这里主要是HBase相关内容的介绍，本节课程作为 HBase 实战课程的开篇，首先是从整体上对 HBase 的基础概念有基本的了解，在对定义解读的基础上，讲解在 HBase 上，数据的建模和具体的使用方法，而后通过具体的案例分享，帮助同学加深对 HBase 的适用场景和数据模型的认知。
适用场景
什么是HBase
HBase是一个开源的NoSQL分布式数据库,是Apache软件基金会顶级项目之-.
- 参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。
- 采用存储计算分离架构：
- 存储层基于HDFS存储数据，提供容错机制和高可靠性;
- 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力;
- 提供强一致语义,在CAP理论中属于CP系统：
- Consistency , Availability，Partition Tolerance
HBase vs 关系型数据库
HBase的数据模型
逻辑结构
- HBase以列族( column family )为单位存储数据，以行键( rowkey )索引数据。
- 列族需要在使用前预先创建，列名( column qualifier )不需要预先声明，因此支持半结构化数据模型。
- 支持保留多个版本的数据，(行键+列族+列名+版本号)定位一个具体的值。
物理结构
- 物理数据结构最小单元是KeyValue结构:
- 每个版本的数据都携带全部行列信息。
- 同一行，同- -列族的数据物理上连续有序存储。
- 同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version降序排列。
- 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序。
- 同列族下不同物理文件间不保证数据全局有序。
- 仅单个物理文件内有序。
使用场景
-
适用场景:
- “近在线”的海量分布式KV /宽表存储，数据量级可达到PB级以上
- 写密集型、高吞吐应用,可接受一定程度的时延抖动
- 字典序主键索引、批量顺序扫描多行数据的场景
- Hadoop 大数据生态友好兼容
- 半结构化数据模型，行列稀疏的数据分布，动态增减列名
- 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化
-
典型应用:
- 电商订单数据:查询最新/待处理订单进度
- 搜索推荐引擎:存储原始数据、排序推荐结果
- 广告数据流:触达、点击、转化等事件流
- 用户交互数据: IM、 Email、点赞、搜索
- 时序数据引擎:日志、监控( OpenTSDB )
- 图存储引擎: JanusGraph
- 大数据生态:高度融入Hadoop生态
典型案例
- 半结构化/字典序有序索引的数据
HBase支持前缀索引昂！
- “近在线”海量分布式KV / 宽表存储
- 写密集型的高吞吐场景
优缺点
架构设计
HBase 架构设计
HBase的整体架构设计、主要模块设计
- 主要组件包括:
- HMaster：元数据管理，集群调度、保活。
- RegionServer：提供数据读写服务，每个实例 负责若千个互不重叠的rowkey区间内的数据。
- ThriftServer：提供Thrift API读写的代理层。
- 依赖组件包括:
- Zookeeper：分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等。
- HDFS：分布式文件系统, HBase数据存储底座。
HMaster
主要职责
- 管理RegionServer实例生命周期,保证服务可用性
- 协调RegionServer数据故障恢复，保证数据正确性
- 集中管理集群元数据,执行负载均衡等维护集群稳定性
- 定期巡检元数据，调整数据分布，清理废弃数据等
- 处理用户主动发起的元数据操作如建表、删表等
主要组件
- ActiveMasterManager :管理HMaster的active/backup状态
- ServerManager :管理集群内RegionServer的状态
- AssignmentManager :管理数据分片( region )的状态
- SplitWalManager :负责故障数据恢复的WAL拆分工作
- LoadBalancer :定期巡检、调整集群负载状态
- RegionNormalizer :定期巡检并拆分热点、整合碎片
- CatalogJanitor :定期巡检、清理元数据
- Cleaners :定期清理废弃的HFile / WAL等文件
- MasterFileSystem :封装访问HDFS的客户端SDK
RegionServer
主要职责
- 提供部分rowkey区间数据的读写服务
- 如果负责meta表，向客户端SDK提供rowkey位置信息
- 认领HMaster发布的故障恢复任务, 帮助加速数据恢复过程
- 处理HMaster下达的元数据操作, 如region打开/关闭/分裂/合并操作等
主要组件
- MemStore :基于SkipL ist数据结构实现的内存态存储，定期批量写入硬盘
- Write -Ahead-Log :顺序记录写请求到持久化存储,用于故障恢复内存中丢失的数据
- Store :对应一个Column Family在一个region下的数据集合，通常包含多个文件
- StoreFile :即HFile ,表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
- BlockCache : HBase以数据块为单位读取数据并缓存在内存中以加速重复数据的读取
ZooKeeper
主要职责
- HMaster登记信息，对active/backup分工达成共识
- RegionServer登记信息,失联时HMaster保活处理
- 登记meta表位置信息，供SDK查询读写位置信息
- 供HMaster和RegionServer协作处理分布式任务
ThriftServer
主要职责
- 实现HBase定义的Thrift API ，作为代理层向用户提供RPC读写服务
- 用户可根据IDL自行生成客户端实现
- 独立于RegionServer水平扩展, 用户可访问任意ThriftServer实例（scan操作较特殊，需要同实例维护scan状态）
大数据支撑
HBase在大数据生态的定位
- 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务;
- 支持字典序批量扫描大量数据,支持只读取部分列族的数据，灵活支持不同查询模式,避免读取不必要的数据;
- 存储大规模任务(例如MapReduce , Spark，Flink )的中间/最终计算结果;
- 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问;
- 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。
水平拓展能力
- 增加RegionServer实例,分配部分region到新实例。
- 扩展过程平滑,无需搬迁实际数据。
- 可用性影响时间很短,用户基本无感知。
Region热点切分
- 当某个region数据量过多, 切分成两个独立的子region分摊负载。
- RegionServer在特定时机( flush、compaction )检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition.
- 不搬迁实际数据，切分产生的新region数据目录下生成个以原region文件信息命名的文件，内容是切分点对应的rowkey ,以及标识新region是上下半部分的数据。
切分点选取
-
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分别负责原region的上下半部分rowkey区间的数据。
- 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。
流程设计
- 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数量和RegionServer数量计算平均region数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region数为5，负载均衡的RS.上region数量应该在[4, 6]区间内。
- 将RegionServer按照region数量降序排序，对region数量超出，上限的选取要迁出的region，并按创建时间从新到老排序;
- 选取出region数量低于下限的RegionServer列表round-robin分配步骤2选取的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也可以将第二节点提升为第一节点 ，保证稳定的读时延;
故障恢复机制
HMaster
HMaster通过多实例基于Zookeeper选主实现高可用性。
- 所有实例尝试向Zookeeper的/hbase/active master临时节点CAS地写入自身信息，
- 写入成功表示成为主实例，失败即为从实例，通过watch监听/hbase/active-master节点的变动。
- 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主。
一、HMaster 自身恢复流程:
- 监听到/hbase/active-master临时节点被删除的事件,触发选主逻辑;
- 选主成功后执行HMaster启动流程,从持久化存储读取未完成procedures从之前状态继续执行;
- 故障HMaster实例恢复后发现主节点已存在，继续监听/hbase/active-master.
二、调度RegionServer的故障恢复流程:
- AssignmentManager 从 procedure 列表中找出 Region-In-Transition 状态的region继续调度过程。
- RegionServer Tracker 从 Zookeeper 梳理 online 状态的 RegionServer 列表 , 结合 ServerCrashProcedure 列表。HDFS 中WAL目录里 alive / splitting 状态的 RegionServer 记录 , 获取掉线的 RegionServer 的列表 , 分别创建 ServerCrashProcedure 执行恢复流程/
RegionServer
- 每个RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点。
- HMaster 通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢复不可用的regions.
- RegionServer 的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster 利用Zookeeper配合所有RegionServer实例，分布式地处理WAL数据,提升恢复速度。
启动流程:
- 启动时去Zookeeper登记自身信息，告知主HMaster实例有新RS实例接入集群
- 接收和执行来自HMaster的region 调度命令
- 打开region前先从HDFS读取该region的recovered.edits目录下的WAL记录，回放恢复数据
- 恢复完成,认领Zookeeper .上发布的分布式任务(如WAL切分)帮助其他数据恢复
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上该regior的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回放数据恢复完成。
最佳实践
Rowkey设计策略
场景分类
-
不需要顺序扫描批量连续rowkey对原始rowkey做哈希(如MD5) , 作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。
-
需要顺序扫描批量连续rowkey首先用grouplD/applD/userlD前缀避免数据热点，然后加上定义顺序的信息(如时间戳等)ID前缀也建议哈希处理，避免非预期的热点。e.g. MD5(grouplD):grouplD:timestamp...
-
rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。
*避免用时间戳直接作为rowkey前缀,会导致最新的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通 过水平扩容缓解。
Column Family的设计
- Column family 数量过多容易影响性能，建议尽量少,不超过5个。
- 需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族,避免读不必要的列族。
- 列族(以及column qualfier)名称尽量短，因为会冗余存储到每个KeyValue中。
参数调优经验
