深入浅出HBase 实战 | 青训营笔记

张鱼哥z
84 阅读10分钟

这是我参与「第四届青训营」笔记创作活动的的第10天，以下是我的课堂笔记。 本次课程主要分为四个大板块：
1.适用场景
2.架构设计
3.大数据支撑
4.最佳实践

1. 适用场景

1.1什么是 HBase ?

HBase是一个开源的NoSQL分布式数据库，是 Apache软件基金会顶级项目之一。
参考Google BigTable的设计，对稀疏表提供更高的存储空间使用率和读写效率。

采用存储计算分离架构，

  • 存储层基于HDFS存储数据，提供容错机制和高可靠性;
  • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力;

提供强─致语义，在CAP理论中属于CP系统。 *Consistency,Availability，Partition,Tolerance

1.2 HBase和关系型数据库的区别

image.png

1.3 HBase数据模型

HBase以列族(column family)为单位存储数据，以行键(rowkey)索引数据。
√列族需要在使用前预先创建，列名(column qualifier)不需要预先声明，因此支持半结构化数据模型
√支持保留多个版本的数据，(行键＋列族＋列名＋版本号）定位一个具体的值。

image.png

1.3 HBase数据模型–逻辑结构

HBase是半结构化数据模型。以列族(column family)为单位存储数据，以行键(rowkey)）索引数据。
√列族需要在使用前预先创建，列名(column qualifier）不需要预先声明，因此支持半结构化数据模型。
√支持保留多个版本的数据，(行键＋列族＋列名＋版本号)定位一个具体值。

image.png

1.3 HBase数据模型-逻辑结构

通过非关系型视图理解HBase数据模型:
√适合稀疏数据，缺省列不占用存储空间。
√通过(rowkey, column family,column qualifier, version)
√唯一指定一个具体的值。
√允许批量读取多行的部分列族/咧数据。

1.3 HBase数据模型–物理结构

物理数据结构最小单元是KeyValue结构:
√每个版本的数据都携带全部行列信息。
√同一行，同一列族的数据物理上连续有序存储。
√同列族内的KeyValue按rowkey字典序升 序，column qualifier升序，version降序排列。
√不同列族的数据存储在相互独立的物理文件，列族间 不保证数据全局有序。
√同列族下不同物理文件间不保证数据全局有序。
√仅单个物理文件内有序。

image.png

image.png

1.4使用场景

适用场景:

  • “近在线”的海量分布式KV/宽表存储，数据量级可达到PB级以上
  • 写密集型、高吞吐应用，可接受一定程度的时延抖动
  • 字典序主键索引、批量顺序扫描多行数据的场景
  • Hadoop大数据生态友好兼容
  • 半结构化数据模型，行列稀疏的数据分布，动态增减列名
  • 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化

1.5 HBase数据模型的优缺点

image.png

2. HBase架构设计

2.1 HBase架构设计

主要组件包括:

  • HMaster:元数据管理，集群调度、保活。
  • RegionServer:提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据。
  • ThriftServer:提供Thrift API读写的代理层。

依赖组件包括:

  • zookeeper:分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等。
  • HDFS:分布式文件系统，HBase数据存储底座。

image.png

2.2 Hmaster主要职责

  • 管理RegionServer 实例生命周期，保证服务可用性
  • 协调RegionServer数据故障恢复，保证数据正确性
  • 集中管理集群元数据，执行负载均衡等维护集群稳定性
  • 定期巡检元数据，调整数据分布，清理废弃数据等
  • 处理用户主动发起的元数据操作如建表、删表等

image.png

  • ActiveMasterManager:管理HMaster 的active/backup状态
  • ServerManager:管理集群内RegionServer的状态
  • AssignmentManager:管理数据分片(region)的状态
  • SplitWalManager:负责故障数据恢复的WAL拆分工作
  • LoadBalancer:定期巡检、调整集群负载状态
  • RegionNormalizer:定期巡检并拆分热点、整合碎片
  • CatalogJanitor:定期巡检、清理元数据
  • Cleaners:定期清理废弃的HFile / WAL等文件
  • MasterFileSystem:封装访问HDFS的客户端 SDK

2.3 RegionServer主要职责

  • 提供部分rowkey区间数据的读写服务
  • 如果负责meta表，向客户端SDK提供rowkey位置信息
  • 认领 HMaster发布的故障恢复任务，帮助加速数据恢复过程
  • 处理HMaster下达的元数据操作，如region打开/关闭/分裂/合并操作等

image.png

2.3 RegionServer -主要组件

  • MemStore:基于SkipList数据结构实现的内存态存储，定期批量写入硬盘
  • Write-Ahead-Log:顺序记录写请求到持久化存储，用于故障恢复内存中丢失的数据
  • Store:对应一个Column Family在一个
  • region下的数据集合，通常包含多个文件
  • StoreFile:即 HFile，表示HBase在HDFS存储数据的文件格式，其内数据按rowkey字典序有序排列
  • BlockCache: HBase以数据块为单位读取数据 并缓存在内存中以加速重复数据的读取

image.png

2.4 ZooKeeper主要职责

  • HMaster 登记信息，对active/backup 分工达成共识
  • RegionServer登记信息，失联时HMaster保活处理
  • 登记meta表位置信息，供SDK查询读写位置信息
  • 供 HMaster和RegionServer协作处理分布式任务 image.png

2.5 ThriftServer主要职责

  • 实现HBase定义的Thrift API，作为代理层向用户提供 RPC读写服务
  • 用户可根据IDL自行生成客户端实现独立于RegionServer 水平扩展，用户可访问任意ThriftServer 实例 (scan操作较特殊，需要同实例维护scan状态)

image.png

3.大数据支撑

3.1 HBase在大数据生态的定位

  • 对TB、PB级海量数据支持强一致、近实时的读写性能，支持快速的ad-hoc分析查询任务;
  • 支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据;
  • 存储大规模任务（例如MapReduce，Spark，Flink)的中间/最终计算结果;
  • 平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问;
  • 精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。

3.2水平扩展能力

√增加RegionServer 实例，分配部分region到新实例。
√扩展过程平滑，无需搬迁实际数据。
√ 可用性影响时间很短，用户基本无感知。

image.png

3.3 Region 热点切分

√当某个region数据量过多，切分成两个独立的子region分摊负载。
√ RegionServer在特定时机(flush、compaction）检查 region是否应该切分，计算切分点并RPC上报HMaster，由 AssignmentManager负责执行RegionStateTransition。
√不搬迁实际数据，切分产生的新 region 数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的 rowkey，以及标识新region是上/下半部分的数据。

image.png

3.3 Region 热点切分–切分点选取

HBase原生提供的多种切分策略使用相同的切分点选择策略。目标:优先把最大的数据文件均匀切分。
切分点选择步骤:
1.找到该表中哪个region的数据大小最大
2.找到该region 内哪个column family的数据大小最大
3.找到column family内哪个HFile的数据大小最大
4.找到HFile里处于最中间位置的 Data Block;
5.用这个Data Block的第一条KeyValue的Rowkey 作为切分点。

image.png image.png image.png image.png

3.4 Region碎片整合

  • 当某些region数据量过小、碎片化，合并相邻 region整合优化数据分布。
  • AssignmentManager创建MergeTableRegionsProcedure执行整合操作。
  • 不搬迁实际数据，通过reference file定位原 region的文件，直到下次compaction时实际处理数据。
  • *注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。

3.5 Region负载均衡

定期巡检各 RegionServer 上的 region 数量，保持region的数量均匀分布在各个RegionServer 上。
SimpleLoadBalancer具体步骤:
1.根据总region数量和RegionServer数量计算 平均region数，设定弹性上下界避免不必要的操作。例如默认slop为0.2，平均region数为5， 负载均衡的RS 上region 数量应该在[4,6]区间内。
2.将RegionServer 按照 region数量降序排序， 对region数量超出上限的选取要迁出的region并按创建时间从新到老排序;
3.选取出region数量低于下限的RegionServer列表，round-robin 分配步骤⒉选取的regions, 尽量使每个RS 的region数量都不低于下限;
4.处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近。 image.png

3.6故障恢复机制–HMaster

HMaster通过多实例基于Zookeeper选主实现高可用性。
所有实例尝试向Zookeeper的 /hbaselactive-master 临时节点CAS地写入自身信息，写入成功表示成为主实例，失败即为从实例， 通过watch 监听/hbaselactive-master节点的变动。主实例不可用时临时节点被删除， 此时触发其他从实例重新尝试选主。

image.png

3.7故障恢复机制- RegionServer

  • 每个 RegionServer实例启动时都会往Zookeeper的/hbase/rs路径下创建对应的临时节点。
  • HMaster通过监听RegionServer在Zookeeper的临时节点状态，监控数据读写服务的可用性，及时调度恢 的regions。
  • RegionServer的故障恢复需要将内存中丢失的数据从WAL中恢复，HMaster利用Zookeeper配合所有 RegionServer实例，分布式地处理WAL数据，提升恢复速度。 image.png 启动流程:
    1.启动时去Zookeeper 登记自身信息，告知主HMaster实例有新RS实例接入集群
    2.接收和执行来自HMaster 的region调度命令
    3.打开region前先从HDFS读取该region的recovered.edits目录下的WAL记录，回放恢复数据
    4.恢复完成，认领Zookeeper上发布的分布式任务(如WAL 切分）帮助其他数据恢复

4.最佳实践分享

4.1 Rowkey设计策略

1.不需要顺序扫描批量连续rowkey
对原始rowkey做哈希（如MD5)，作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。
2.需要顺序扫描批量连续rowkey
首先用groupIDlapplDluserID前缀避免数据热点，然后加上定义顺序的信息（如时间戳等)ID前缀也建议哈希处理，避免非预期的热点。 e.g.MD5(groupID):groupID:timestamp:...
3.rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。

**避免用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通过水平扩容缓解。 **

4.2 Column Family 设计策略

1.Column family 数量过多容易影响性能，建议尽量少，不超过5个。
2.需要同时读取的数据尽量放在相同列族，反之尽量放在不同列族，读取时尽量只读取必需的列族，避免读不必要的列族。
3.列族（以及column qualifier)名称尽量短，因为会冗余存储到每个KeyValue 中。

4.3参数调优经验

image.png

4.4 ByteTable-字节跳动自研分布式表格存储系统

优势:
1.存储层基于字节跳动自研分布式存储底座，从设计上充分支持在线场景的性能、功能需求;
2.采用C++编写构建，杜绝了Garbage Collection在Stop-The-World阶段带来的性能抖动;
3.架构设计上支持更细粒度、更灵活的数据分片组织方式，激活更多优化空间;
4．元数据设计提供更好的故障域控制，避免多租户相互影响;
5．更短的故障恢复时间，对在线场景的高可用性支持更好;
...

avatar
文章
阅读
粉丝