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

冕临
55 阅读19分钟

深入浅出HBase实战

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

1.HBase概述

1.HBase简介

HBase是一个开源的NoSQL分布式数据库，是Apache软件基金会顶级项目之一

  • HBase 是存储计算分离架构，以 HDFS 作为分布式存储底座。数据实际存储在 HDFS。
  • HBase 依赖 Zookeeper 实现元数据管理和服务发现。Client 通过 Zookeeper 配置连接到 HBase集群
  • Log-Structured Merge Tree 了解 LSM tree 的基本结构和特性。 采用存储计算分离架构
  • 存储层基于HDFS存储数据，提供容错机制和高可靠性;
  • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力; 提供强一致语义，在CAP理论中属于CP系统。

2.HBase和关系型数据库的区别

image.png

3.HBase数据模型

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

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

1.逻辑结构

HBase是半结构化数据模型。以列族(column family)为单位存储数据，以行键(rowkey) 索引数据。

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

通过非关系型视图理解HBase数据模型:

  1. 适合稀疏数据，缺省列不占用存储空间。
  2. 通过(rowkey, column family, column qualifier, version)
  3. 唯一指定一个具体的值。
  4. 允许批量读取多行的部分列族/列数据。

2.物理结构

物理数据结构最小单元是KeyValue结构:

  1. 每个版本的数据都携带全部行列信息。
  2. 同一行，同一列族的数据物理.上连续有序存储。
  3. 同列族内的KeyValue按rowkey字典序升序，column qualifier升序，version 降序排列。
  4. 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序。
  5. 同列族下不同物理文件间不保证数据全局有序。
  6. 仅单个物理文件内有序。

4.适用场景

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

5.HBase读写流程

1.HBase写流程

  • 数据先写入 WAL 持久化，用于宕机时恢复内存里丢失的数据
  • 再写入内存态 MemStore，以一种跳表（SkipList）数据结构提供有序的数据和高效的随机读写
  • 当满足特定条件时（比如内存中数据过多，或间隔时间过长），MemStore 数据以 HFile 格式写入 HDFS

2.HBase读流程

  • 首次读某个 rowkey 时，client 需要从 Zookeeper 获取 hbase:meta 表位于哪个 RegionServer上
  • 然后访问该 RegionServer 查询 hbase:meta 表该 rowkey 对应 region 所在的 RegionServer B
  • Client 缓存该位置信息，去 RegionServer B 读取 rowkey
  • 基于该region内可能存在该 rowkey 的 HFile 和 MemStore 构建一个最小堆，用以全局有序地 scan 数据（具体实现可搜索参考 LSM tree 设计原理）

6.Compaction

  • HBase 基于策略和定期整理 HFile 文件集合，将多个有序小文件合并成若干个有序的大文件。
  • HBase 提供两种 compaction 类型：
    • Minor compaction： 指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。
    • Major compaction： 指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。
  • Compaction 触发条件：
    • memstore flush：可以说compaction的根源就在于flush，memstore 达到一定阈值或其他条件时就会触发flush刷写到磁盘生成HFile文件，正是因为HFile文件越来越多才需要compact。HBase每次flush之后，都会判断是否要进行compaction，一旦满足minor compaction或major compaction的条件便会触发执行。
    • 后台线程周期性检查： 后台线程 CompactionChecker 会定期检查是否需要执行compaction，检查周期为hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier，这里主要考虑的是一段时间内没有写入请求仍然需要做compact检查。其中参数 hbase.server.thread.wakefrequency 默认值 10000 即 10s，是HBase服务端线程唤醒时间间隔，用于log roller、memstore flusher等操作周期性检查；参数 hbase.server.compactchecker.interval.multiplier 默认值1000，是compaction操作周期性检查乘数因子。10 * 1000 s 时间上约等于2hrs, 46mins, 40sec。
    • 手动触发：是指通过HBase Shell、Master UI界面或者HBase API等任一种方式 执行 compact、major_compact等命令。

2.HBase 架构设计

1.HBase组件

主要组件包括:

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

2.Hmaster主要职责

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

3.HMaster - 主要组件

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

4.RegionServer 主要职责

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

5.RegionServer - 主要组件

image.png

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

6.ZooKeeper主要职责

image.png

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

7.ThriftServer主要职责

image.png

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

3.大数据支撑

1.HBase在大数据生态的定位

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

2.水平扩展能力

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

3.Region热点切分

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

1.切分点选取

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

目标:优先把最大的数据文件均匀切分。

切分点选择步骤:

  1. 找到该表中哪个region的数据大小最大
  2. 找到该region内哪个column family的数据大小最大
  3. 找到 column family 内哪个 HFile的数据大小最大
  4. 找到HFile里处于最中间位置的Data Block;
  5. 用这个Data Block的第一条KeyValue的Rowkey作为切分点。

2.切分过程

所有Column Family都按照统一的切分点来切分数据。

目的是优先均分最大的文件，不保证所有Column Family的所有文件都被均分。

  1. HFile 1作为最大的文件被均分，其他文件也必须以相同的rowkey切分以保证对齐新region的rowkey区间。
  2. 切分出的新region分别负责rowkey区间[2000, 2500)和[2500, 4000)。
  3. 每个新region分别负责原region的，上/下半部分rowkey区间的数据。
  4. 在compaction执行前不实际切分文件，新region下的文件通过reference file指向原文件读取实际数据。

3.流程设计

AssignmentManager检查cluster、table、 region 的状态后，创建SplitT ableRegionProcedure通过状态机实现执行切分过程。 image.png

4.Region碎片整合

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

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

5.Region负载均衡

1.调度策略

定期巡检各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分配步骤2选取的regions,尽量使每个RS的region数量都不低于下限;
  4. 处理边界情况，无法满足所有RS的region数量都在合理范围内时，尽量保持region数量相近。

2.其他策略

StochasticL oadBalancer

  1. 随机尝试不同的region放置策略，根据提供的cost function计算不同策略的分值排名(0 为最优策略，1 为最差策略)
  2. cost计算将下列指标纳入统计:region负载、表负载、数据本地性(本地访问 HDFS)、Memstore 大小、HFile 大小
  3. 根据配置加权计算最终cost,选择最优方案进行负载均衡 FavoredNodel oadBalancer
  4. 用于充分利用本地读写HDFS文件来优化读写性能
  5. 每个region会指定优选的3个RegionServer地址，同时会告知HDFS在这些优选节点上放置该region的数据
  6. 即使第一节点出现故障， HBase也可以将第二节点提升为第一节点，保证稳定的读时延

6.故障恢复机制- HMaster

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

  • 所有实例尝试向Zookeeper的/hbase/active-master临时节点CAS地写入自身信息，
  • 写入成功表示成为主实例，失败即为从实例，通过watch监听/hbase/active- master节点的变动
  • 主实例不可用时临时节点被删除，此时触发其他从实例重新尝试选主。 恢复流程：
  • 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 / splitting状态的RegionServer记录，获取掉线RegionServer的列表，分别创建ServerCrashProcedure执行恢复流程

7.故障恢复机制- RegionServer

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

8.Distributed Log Split原理

1.背景

image.png

  1. 写入HBase的数据首先顺序持久化到Write-Ahead-Log，然后写入内存态的MemStore即完成，不立即写盘，RegionServer 故障会导致内存中的数据丢失，需要回放WAL来恢复
  2. 同RegionServer的所有region复用WAL, 因此不同region的数据交错穿插，RegionServer故障后重新分配region前需要先按region维度拆分WAL

2.具体流程

image.png

  1. RegionServer故障，Zookeeper检测到心跳超时或连接断开，删除对应的临时 节点并通知监听该节点的客户端
  2. active HMaster监听到RS临时节点删除事件，从HDFS梳理出该RS负责的WAL文件列表
  3. HMaster为每个WAL文件发布一个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.优化空间

进一步优化: Distributed Log Replay

  1. HMaster 先将故障RegionServer上的所有region以Recovering状态调度分配到其他正常RS上
  2. 再进行类似Distributed Log Split的WAL日志按region维度切分
  3. 切分后不写入HDFS，而是直接回放，通过SDK写流程将WAL记录写到对应的新RS
  4. Recovering 状态的region接受写请求但不提供读服务，直到WAL回放数据恢复完成

4.最佳实践分享

1.Rowkey设计策略

场景分类

  • 不需要顺序扫描批量连续rowkey 对原始rowkey做哈希(如 MD5)，作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。
  • 需要顺序扫描批量连续rowkey 首先用grouplD/applD/userlD前缀避免数据热点，然后加上定义顺序的信息(如时间戳等)ID前缀也建议哈希处理，避免非预期的热点。e.g. MD5(grouplD):grouplD:timestamp...
  • rowkey长度尽量保持较短，因为会冗余存储到每个KeyValue中。 避免用时间戳直接作为rowkey前缀，会导致最新的数据始终集中在单个RegionServer上，造成热点瓶颈，且无法通过水平扩容缓解。

2.Column Family设计策略

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

3.参数调优经验

image.png

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

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

5.生态

通过在 HBase之上引入各种组件可以使HBase应用场景得到极大扩展，例如监控、车联网、风控、实时推荐、人工智能等场景的需求。

  1. Phoenix 主要提供SQL的方式来查询HBase里面的数据。一般能够在毫秒级别返回，比较适合OLTP以及操作性分析等场景，支持构建二级索引。

  2. Spark 很多企业使用HBase存储海量数据，一种常见的需求就是对这些数据进行离线分析，我们可以使用Spark(Spark SQL) 来实现海量数据的离线分析需求。同时，Spark还支持实时流计算，我们可以使用 HBase+Spark Streaming 解决实时广告推荐等需求。

  3. HGraphDB 分布式图数据库，可以使用其进行图 OLTP查询，同时结合 Spark GraphFrames 可实现图分析需求，帮助金融机构有效识别隐藏在网络中的黑色信息，在团伙欺诈、黑中介识别等。

  4. GeoMesa 目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。提供高效时空索引，支持点、线、面等空间要素存储，百亿级数据实现毫秒(ms)级响应;提供轨迹查询、区域分布统计、区域查询、密度分析、聚合、OD 分析等常用的时空分析功能;提供基于Spark SQL、REST、GeoJSON、OGC服务等多种操作方式，方便地理信息互操作。

  5. OpenTSDB 基于HBase的分布式的，可伸缩的时间序列数据库，适合做监控系统；比如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储，查询。

  6. Solr 原生的HBase只提供了Rowkey单主键，仅支持对Rowkey进行索引查找。可以使用 Solr来建立二级索引/全文索引来扩展更多查询场景的支持。

6.功能

  1. Bulkload 大批量向HBase导入数据的功能。使用MapReduce任务直接生成底层存储的HFile文件，并直接移动到HBase存储目录下，节省HBase写路径的开销从而提高写入效率。

  2. Coprocessor 提供一套接口框架，给HBase原生接口添加类似lifecycle hook函数的能力，用来执行用户自定义的功能来扩展HBase的能力，例如二级索引、Observer等功能。

  3. Filter 将用户的过滤逻辑下推到HBase服务端，避免无用数据传输处理开销来提高查询效率。

  4. MOB Medium Object Storage解决HBase对中等大小对象（10-100MB）的低延迟读写支持，拓宽HBase适用场景。

  5. Snapshot 数据备份功能，将某一时刻的数据以及元数据备份，用于数据恢复、快照读、复制表等功能。

  6. Replication 将一个HBase集群中的数据复制到目标HBase集群，使用WAL将变更记录同步到其他集群。

avatar
文章
阅读
粉丝