分享

HBase 原理 | HBase Compaction Offload 功能的实现与应用

本帖最后由 Mirinda 于 2021-8-23 13:32 编辑



问题导读:
1.是否熟悉Compaction 的现有逻辑?
2.Compaction Offload 有哪些功能?
3.Compaction 未来有哪些规划?


导读

本文介绍了HBase Compaction Offload功能的设计与实现,以及在小米的应用。HBase Compaction操作会造成读写服务响应毛刺,我们通过引入CompactionServer组件,将Compaction任务剥离到CompactionServer上执行,避免与RegionServer产生资源竞争,优化读写毛刺。同时Compaction Offload功能加强存储计算分离,CompactionServer可以独立于RegionServer进行扩缩容,便于云原生容器化部署。

背景
HBase是基于LSM-Tree架构的分布式数据库,对于数据写入不会原地更新,而是在内存(Memtable)中创建更新键的新值,然后定期将内存中的数据刷新为只读的存储文件(HFile),读取数据就需要遍历多个文件找到该键所对应的正确值。随着存储文件不断增加,读性能会因为需要读取的文件数增多而下降(如图.1所示)。HBase会执行Compaction操作将多个文件合并,使文件个数基本稳定,进而使读取IO的次数趋于稳定,将延迟控制在一定范围内(图.2)。在现有HBase架构中,Compaction操作在RegionServer上执行,合并文件会带来很大的带宽以及IO压力,同时也会消耗CPU和内存资源,造成读取响应延迟增大,出现毛刺。

a1.png


图.1 读取延时随数据写入时间增加而不断增加

a2.png

图.2 开启Compaction情况下读取延迟随写入时间变化



1、Compaction 现有逻辑



目前Compaction相关逻辑都是在RegionServer中执行的,如图.3所示。


a3.png
图.3 Compaction执行流程

Compaction的执行流程可以分解为多个子流程:
1、触发条件:Flush、Open Region、CompactionCheckerChore、Admin操作
2、执行Compaction
  • 根据Compaction策略选择要合并的文件
  • 选择合适的线程池,执行Compact

3、完成Compaction
  • 将Compact产生的新文件从tmp目录移动到Region相应目录,并加载新文件
  • 将参与Compact的输入文件标记为Compacted
  • CompactedHFilesDischarger线程定期扫描并删除Compacted文件

Compaction Offload功能将步骤2中的部分从RegionServer中移出,在CompactionServer上执行。

2、Compaction Offload 功能实现
整体架构变化

引入新的组件CompactionServer(以下简写为CS),将Compaction任务从RegionServer中剥离出来。新的HBase架构包含组件为:Master、RegionServer、CompactionServer。同时为了管理CS,在Master中增加CompactionServer Manager(以下简写为CS Manager)模块,如图.4 所示。

a4.png
图.4 HBase新整体架构

CompactionServer可以代替RegionServer执行Compaction操作,它使用HDFS Client与HDFS进行交互,从HDFS中读取需要执行Compaction文件的内容,并将Compaction产生的新文件写入HDFS。CompactionServer是无状态的,易于扩展。CS Manager管理CS并维护Region到CS的映射,使每个CS执行某些Regoin的Compaction操作,这类似于Master将Region分配给RegionServer提供读写服务。
在实现CS和CS Manager的过程中,我们复用了RegionServer和RegionServerManager的代码,例如从HDFS中Scan Storefile以及对这些文件执行Compaction并写回HDFS,同时对于Compaction的核心—Compaction策略,我们将其视为黑盒,保持原先的执行逻辑,不做修改。
新的架构可以带来如下好处:
1、CompactionServer可以部署在独立机器上,不与RegionServer产生资源竞争,优化读写毛刺。
2、加强存储计算资源分离,将RegionServer计算任务进一步分离到多个Server上,CS可以独立于RegionServer进行扩缩容,便于容器化部署。
3、有了中心化的CS Manager, Master可以对Compaction任务进行整体限速。



Compaction逻辑的变化


a5.png
图.5 CompactionOffload模块交互图

增加CompactionServer后,执行Compaction时各模块功能发生变化:
1、RegionServer
  • 需要执行Compaction时,发送Request Compaction请求到Master,请求中携带Region、Family等信息(图.5中①)。
  • 接受CS的CompactionComplete请求(图.5中③),然后进行原先的逻辑(Compaction现有逻辑中3)。

2、Master
  • 新增类CompactionServerManager,用来管理CS以及转发Compaction请求。
  • 接受RegionServer的Request Compaction请求,并转发给相应CS,这里同一个Region的请求会转发到同一个CS(图.5中②)。
  • 响应CS的心跳请求,返回对CS的限速信息(图.5中⑤)。
  • 页面展示CS列表以及Compaction Task汇总信息。

3、CompactionServer
  • 接受Master转发来的Request Compaction请求,执行选择文件和Compact逻辑(Compaction现有逻辑中2)。
  • 发送CompleteCompaction请求给相应的Regionserver,请求参数包括参与执行Compaction的文件列表和Compaction生成文件列表(图.5中③)。
  • 给Master发送心跳并汇报Compaction Task信息(图.5中④)。
  • 获取Master的汇报答复,其中包含限速信息,对Compaction任务进行限速调整。



Compaction Offload功能开关
集群级别:在HBase Shell中执行enable_compaction_offload/disable_compaction_offload命令开启或关闭整集群Compaction Offload功能。
表级别:创建/修改表时设置表的COMPACTION_OFFLOAD_ENABLED的属性为true或false。
只有集群和表级别开关同时开启,才会执行Compaction Offload逻辑。



Compaction Offload功能Failover
1、Master宕机RegionServer请求Master失败,会回退到原先的本地执行Compaction方式。
对于已经在CS执行完毕的Compaction任务,会直接请求RegionServer(图.5中③),不会受到Master不可用的影响。
2、CompactionServer宕机CS宕机后,CS Manager会将请求发送到其他可用的CS,若全部CS都不可用,RegionServer会回退到本地执行Compaction的方式。
3、RegionServer宕机或Region移动在CS执行完Compaction并请求RegionServer时(图.5中③),若发生RegionServer宕机或Region移动,我们会等待Region重新Online,从Master中获取Region最新所在RegionServer,然后重试Compaction Complete请求。



Compaction Offload功能兼容性
1、FavoredNodes/Locality若某个Region开启了FavoredNodes特性,CompactionOffload功能会进行兼容,在文件写回HDFS时使用FavoredNodes特性,保证Compaction生成的文件副本在指定DataNode列表上。
若未开启FavoredNodes特性,会将发送RequestCompaction请求的RegionServer地址设置为HStore的FavoredNodes,在写回HDFS时写入RegionServer所在机器的DataNode,保证Locality。若RegionServer所在机器未部署DataNode,则会随机选择DataNode进行写入。
2、MOBCompactionServer在执行Compaction时会创建HStore对象,复用Compaction逻辑。若RequestCompaction请求中Family是开启MOB特性的,我们会创建HMobStore,从而兼容MOB Compaction。
3、RegionCoprocessorHBase用户通过定制Coprocessor可以在Compaction操作过程中执行自定义逻辑,Compaction Offload功能需要兼容Coprocessor保证Compaction的语义正确。我们引入RegionCoprocessorService接口,使Region可以在CompactionServer上打开时挂载Compaction相关的Coprocessor。

3、Compaction Offload 功能应用
YCSB测试
RegionServer:Num = 2、 MaxHeap = 25g、MaxDirectMem = 25g、HDD
CompactionServer:Num = 1、MaxHeap = 25g、HDD
5M Records and Operations

Wordload A
a6.png

Wordload B
a7.png
YCSB测试表明,开启Compaction Offload对吞吐和P99延迟有10%左右提升。


上线效果
小米推送集群:60个RegionServer节点,单节点128G内存、10T SSD。单机读/写QPS均值:40k/2.5k;单机读/写QPS峰值:90k/10k。
我们在该集群上线Compaction Offload功能,将5个RegionServer服务器替换为部署CS,每个服务器部署4个CS。上线时间为7月18日,我们分别截取了服务端和客户端对访问延时的监控如图6、7、8所示。发现开启Compaction Offload功能可以显著降低P99延时,但是对于平均延迟和P999优化效果不明显。
a8.png
图.6 HBase服务侧监控:请求排队时间(P99)

a9.png
图.7 HBase服务侧监控:请求处理时间(P99)

a10.png
图.8 业务侧监控:Get请求HBase集群耗时(P99)

4、未来规划
Compaction Offload功能同步到社区
目前Compaction Offload功能在小米内部分支开发完毕,正在同步到社区,参考HBASE-25714。

支持异构Compaction Offload功能
目前Compaction Offload功能只能在CS上执行,后续可以考虑将Compaction提交到YARN上执行,获得更高的资源利用率。由于Minor Compaction对实时性有较高要求,可以使用Spark Streaming或者Flink计算框架对Compaction任务进行处理。

CompactionServer支持BlockCache
图.2 Compaction任务造成读写毛刺不仅仅是因为其与RegionServer产生资源竞争,另一个原因是Compaction结束时替换文件造成RegionServer BlockCache失效,这时需要重新从HDFS读取文件并加载到BlockCache,Compaction Offload功能目前只能解决Compaction任务与RegionServer资源竞争的问题。我们计划在CS中引入BlockCache,在Compaction执行过程中缓存需要的HFile Block,当Compaction任务结束替换文件后,RegionServer可以从CS的BlockCache中读取相应Block,减轻读文件造成的延时毛刺。

参考
  • https://issues.apache.org/jira/browse/HBASE-25714
  • http://www.vldb.org/pvldb/vol8/p850-ahmad.pdf
  • https://hbase.apache.org/book.html
  • 《HBase原理与实践》

最新经典文章,欢迎关注公众号






没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条