这是我参与「第四届青训营 」笔记创作活动的的第10天
深入浅出 HBase 实战
介绍 HBase 的适用场景和数据模型
分析 HBase 的整体架构和模块设计
针对大数据场景 HBase 的解决方案
分享 HBase 大规模实战的最佳实践
HBase基于HDFS实现存储计算分离架构的分布式表格存储服务
适用场景
HBase定义
-
HBase是一个开源的NoSQL分布式数据库,对稀疏表提供更高的存储空间使用率和读写效率
-
采用存储计算分离架构
HBase与关系型数据库对比
HBase数据模型
HBase是半结构化数据类型,以列族(column family)为单位存储数据,以行键(rowkey)索引数据
- 列族需要在使用前预先创建,列名(column qualifier)不需要预先声明,因此支持半结构化数据模型。
- 支持保留多个版本的数据,(行键+列族+列名+版本号)定位一个具体的值
逻辑结构
通过非关系型视图理解HBase数据模型:
- 适合稀疏数据,缺省列不占用存储空间
- 通过(rowkey, column family, column qualifier, version)唯一指定一个具体的值
- 允许批量读取多行的部分列族/列数据
物理结构
物理数据结构最小单元是KeyValue结构:
- 每个版本的数据都携带全部行列信息。
- 同一行,同一列族的数据物理上连续有序存储。
- 同列族内的KeyValue按rowkey字典序升序,column qualifier升序,version降序排列。
- 不同列族的数据存储在相互独立的物理文件,列族间不保证数据全局有序。
- 同列族下不同物理文件间不保证数据全局有序。
- 仅单个物理文件内有序
使用场景
- “近在线”的海量分布式KV/宽表存储,数据量级可达到PB级以上
- 写密集型、高吞吐应用,可接受一定程度的时延抖动
- 字典序主键索引、批量顺序扫描多行数据的场景
- Hadoop大数据生态友好兼容
- 半结构化数据模型,行列稀疏的数据分布,动态增减列名
- 敏捷平滑的水平扩展能力,快速响应数据体量、流量变化
典型应用:
- 电商订单数据:查询最新/待处理订单进度(“近在线”的海量分布式KV/宽表存储)
- 搜索推荐引擎:存储原始数据、排序推荐结果
- 广告数据流:触达,点击、转化等事件流
- 用户交互数据:IM、Email、点赞、搜索
- 时序数据引擎:日志、监控(OpenTSDB)(写密集型、高吞吐应用)
- 图存储引擎:JanusGraph
- 大数据生态:高度融入 Hadoop生态
HBase数据模型的优缺点
架构设计
HBase整体架构
-
主要组件包括:
- HMaster:元数据管理,集群调度、保活。
- RegionServer:提供数据读写服务,每个实例负责若千个互不重叠的rowkey区间内的数据。
- ThriftServer:提供Thrift API读写的代理层。
-
依赖组件:
- Zookeeper:分布式一致性共识协作管理,例如HMaster选主、任务分发、元数据变更管理等。
- HDFS:分布式文件系统,HBase数据存储底座
HMaster主要职责
- 管理RegionServer 实例生命周期,保证服务可用性。
- 协调RegionServer数据故障恢复,保证数据正确性。
- 集中管理集群元数据,执行负载均衡等维护集群稳定性。
- 定期巡检元数据,调整数据分布,清理废弃数据等。
- 处理用户主动发起的元数据操作如建表、删表等
HMaster主要组件
- 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打开/关闭/分裂/合并操作等
RegionServer主要组件
- MemStore:基于 SkipList 数据结构实现的内存态存储,定期批量写入硬盘
- Write-Ahead-Loa:顺序记录写请求到持久化存储,用干故障恢复内存中丢失的数据
- 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状态)
大数据支撑
水平扩展能力
- 增加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 作为切分点
最佳实战
Rowkey设计策略
场景分类:
-
不需要顺序扫描批量连续rowkey:对原始rowkey做哈希(如MD5),作为真实rowkey的前缀。建议取适当长度的子串,避免过多占用存储空间。
-
需要顺序扫描批量连续rowkey: 首先用groupID/applD/uSerID前缀也建议哈希处理,避免非预期的热点。
-
rowkey长度尽量保持较短,因为会冗余存储到每个KeyValue中。
避免用时间戳直接作为rowkey前缀,会导致最新的数据始终集中在单个RegionServer上,造成热点瓶颈,且无法通过水平扩容缓解。
Column Family设计策略
- Column family数量过多容易影响性能,建议尽量少,不超过5个。
- 需要同时读取的数据尽量放在相同列族,反之尽量放在不同列族,读取时尽量只读取必需的列族,避免读不必要的列族。
- 列族((以及column qualifier)名称尽量短,因为会冗余存储到每个KeyValue 中
参数调优经验