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

serendipity__
83 阅读10分钟

这是我参与「第四届青训营 」笔记创作活动的第九天

深入浅出 HBase 实战

一、HBase适用场景

1.1什么是HBase

HBase 是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一。HBase 是存储计算分离架构，以 HDFS 作为分布式存储底座。数据实际存储在 HDFS。

  • HBase 依赖 Zookeeper 实现元数据管理和服务发现。Client 通过 Zookeeper 配置连接到 HBase集群

  • 提供强一致语义，在CAP理论中数据CP系统

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

image.png

1.3 HBase数据模型

1.3.1 逻辑结构

HBase 以列族（column family）为单位存储数据，以行键（rowkey）索引数据。

  • 列族需要在使用前预先创建，列名（column qualifier）不需要预先声明，因此支持半结构化数据模型。
  • 支持保留多个版本的数据，（行键+列族+列名+版本号）定位一个具体的值。

image.png

1.3.2 物理结构

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

1.4 使用场景

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

1.4.1 典型应用

  • 电商订单数据:查询最新/待处理订单进度
  • 搜索推荐引擎:存储原始数据、排序推荐结果
  • 广告数据流:触达、点击、转化等事件流
  • 用户交互数据: IM、Email、 点赞、搜索
  • 时序数据引擎:日志、监控(OpenTSDB)
  • 图存储引擎: JanusGraph
  • 大数据生态:高度融入Hadoop生态

image.png

1.5 HBase数据模型的优缺点

image.png

二、HBase架构设计

2.1 HBase架构设计

➢主要组件包括:

  • HMaster: 元数据管理，集群调度、保活。
  • RegionServer:提供数据读写服务，每个实例负责若千个互不重曼的rowkey区间内的数据。
  • ThriftServer:提供Thrift API读写的代理层。 ➢依赖组件包括:
  • Zookeeper:分布式一致性共识协作管理， 例如HMaster选主、任务分发、元数据变更管理等。
  • HDFS:分布式文件系统，HBase 数据存储底座。

image.png

2.2 Hmaster

2.2.1 Hmaster主要职责

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

image.png

2.2.2 HMaster主要组件

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

2.3 RegionServer

image.png

2.3.1 RegionServer主要职责

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

2.3.2 RegionServer主要组件

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

2.4 ZooKeeper 主要职责

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

2.5 ThriftServer主要职责

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

image.png

三、大数据支撑

3.1 HBase在大数据生态的定位

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

3.2 水平扩展能力

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

image.png

3.3 Region热点切分

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

3.3.1 切分点的选取

HBase原生提供的多钟分切策略使用相同的切分点选择策略

目标：优先把最大的数据文件均分切分

  1. 找到该表中最大的哪个region的数据大小最大 image.png

  2. 找到该region内哪个column family的数据大小最大

image.png 3. 找到column family 内哪个HFile的数据大小最大

image.png 4. 找到HFile里处于最中间位置的Data Block

  1. 用这个Data Block的第一条KeyValue的Rowkey最为切分点

image.png

3.3.2 Region热点切分 —— 流程设计

image.png

3.4 Region碎片整合

类似于region切分，不立刻处理实际数据文件，而是通过创建reference files引用到原文件，然后原子地更新元数据来完成碎片整合，后续靠compaction整合数据文件，靠CatalogJanitor异步巡检元数据处理遗留数据。 image.png

3.5 Region负载均衡

3.5.1 SimpleL oadBalancer具体步骤:

  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数量相近。

3.6 故障恢复机制

HMaster通过多实例基于ZooKeeper选主实现高可用性

3.6.1 HMaster恢复流程

一、HMaster自身恢复流程

  1. 监听到/hbase/active master临时节点被删除的事件，触发选主逻辑:
  2. 选主成功后执行HMaster启动流程，从持久化存储读取未完成的procedures从之前状态继续执行;
  3. 故障HMaster实例恢复后发现主节点已存在，继续监听/hbase/active master。

二、调度RegionServer的故障恢复流程

  1. AssignmentManager 从procedure列表中找出Region- In-Transition状态的region 继续调度过程:
  2. RegionServerTracker 从Zookeeper梳理online 状态的RegionServer列表，结合ServerCrashProcedure列表、HDFS中WAL目录里alive I plitting状态的RegionServer记录，获取掉线RegionServer的列表，分别创建ServerCrashProcedure执行恢复流程。

3.6.2 RegionServer

启动流程:

  1. 启动时去Zookeeper登记自身信息，告知主HMaster实例有新RS实例接入集群
  2. 接收和执行来自HMaster的region调庶命令
  3. 打开region前先从HDFS读取该region 的recovered.edits目录下的WAL记录，回放恢复数据
  4. 恢复完成，认领Zookeeper.上发布的分布式任务(如WAL切分)帮助其他数据恢复

3.7 Disteibuted Log Split

image.png 背景:

  • 1.写入HBase的数据首先顺序持久化到Write -Ahead-Log,然后写入内存态的MemStore即完成，不立即写盘，RegionServer 故障会导致内存中的数据丢失，需要回放WAL来恢复;
  • 2.同RegionServer的所有region复用WAL,因此不同region的数据交错穿插，RegionServer 故障后重新分配region前需要先按reaion维度拆分WAL。 实现原理:
  • RegionServer 故障，Zookeeper 检测到心跳超时或连接断开，删除对应的临时节点并通知监听该节点的客户端
  • active HMaster监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表
  • HMaster为每个WAL文件发布一 个log split task到ZK
  • 其他在线的RS监听至新任务，分别认领
  • 将WAL entries按region拆分，分别写入HDFS上该 region的recovered.edits目录
  • HMaster监听到log split任务完成，调度region到其他RS
  • RS打开region前在HDFS找到先回放recovered.edits目录下的WAL文件将数据恢复到Memstore里，再打开region恢复读写服务

四、最佳实践分享

4.1rowkey设计

  • 最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes。key在保证功能的前提下建议越短越好，因为key是冗余到每个cell存储的，过长的key会占用更多存储、缓存空间。

  • 设计Key时，要充分利用排序存储这个特性，将经常一起读取的行存储到一起。HBase以HFile文件块为单位从HDFS读取数据，一次性读出相邻相关数据可以达到随机读变成顺序读的效果。

但同时要防止出现热key聚焦打爆region server实例。

反例：以时间戳作rowkey前缀，一段时间的请求会全部打到同一regionserver。

4.2 Column family数量

过多的cf会影响HBase性能，建议不超过3个。

4.3 参数优化经验

image.png

avatar
文章
阅读
粉丝