HBase的Compaction设计综述

HBase使用的存储结构为LSM树,它的优势是能大大提升写效率。同时由于这种特性在HBase中,它的存储会形成一个个的小文件HFile。当HFile文件数过多的时候,会导致读取效率降低,为了解决这个问题,HBase中引入了Compaction设计。(其实凡是使用LSM树作为存储结构的数据库基本都引入了类似功能)

Compaction的分类

Compaction分为Minor CompactionMajor Compaction,Minor Compaction是指选取部分小的、相邻的HFile,将它们合并成一个更大的HFile。Major Compaction是指将一个Store中所有的HFile合并成一个HFile,并且会清除其中的一些过期数据。
相比而言,Major Compaction持续时间会比较长。消耗的集群资源也比较大。

如下图所示,当集群写数据逐渐增多时候,读延迟也会随之增加。


数据量增加延时

如下图所示,经过Compaction后,延迟有如下变化。


Compaction后的延迟

Compaction的另一个重要作用是把数据都放在本地节点。也就是同一个Region的数据,尽量合并在同一个RegionServer上,减少读请求时,网络传输带来的性能损失。

Compaction的基本工作原理

合并的基本原理是先从要合并的文件中读取所有的K-V数据,然后把这些数据进行排序,再把结果写进一个新的HFile文件中,合并完成之后,将有新的HFile文件对外提供服务。

对于Compaction的工作流程可以分为以下四个步骤

  • 触发
  • 选取HFile
  • 执行合并

触发

触发有三种情况,MemStore的Flush、后台线程周期性检查以及手动触发。

  • MemStore的Flush:每次执行完f lush操作之后,都会对当前Store中的文件数进行判断,一旦Store中总文件数大于hbase.hstore.compactionThreshold,就会触发Compaction。
  • 后台线程周期性检查: 总文件数大于hbase.hstore.compactionThreshold,一旦大于就会触发Compaction。
  • 手动触发:手动触发的动机基本实在业务低峰期进行手动触发。

选取HFile

选取HFile进行合并,是整个Compaction流程的核心。通常有多种选取算法主要有两种Minor Compaction文件选择策略,一种是RatioBasedCompactionPolicy,另一种是ExploringCompactionPolicy

  • RatioCompactionPolicy
    设置Ratio,在高峰期ratio为1.2,非高峰期ratio为5。从老到新扫描所有候选文件,计算当前扫描到的文件大小,以及比它新的文件的所有文件总大小乘以ratio。如果前者小于后者,就进行选取。
  • ExploringCompactionPolicy
    该策略思路基本和RatioBasedCompactionPolicy相同,Ratio策略在找到一个合适的文件集合之后就停止扫描了,而Exploring策略会记录所有合适的文件集合,并在这些文件集合中寻找最优解。具体可参照文章.
  • StripeCompactionPolicy
  • 用户自定义Policy
    用户也可以通过特定接口实现自己的Compaction策略

执行合并

HBase实现中有一个专门的类CompactSplitThead负责接收Compaction请求和split请求,而且为了能够独立处理这些请求,这个类内部构造了多个线程池:largeCompactions、smallCompactions以及splits等。
选出待合并的HFile集合,再选出合适的处理线程,接下来执行合并流程。合并流程主要分为如下几步:

  • 分别读出待合并HFile文件的KeyValue,进行归并排序处理,之后写到./tmp目录下的临时文件中。
  • 将临时文件移动到对应Store的数据目录。
  • 将Compaction的输入文件路径和输出文件路径封装为KV写入HLog日志,并打上Compaction标记,最后强制执行sync。
  • 将对应Store数据目录下的Compaction输入文件全部删除。

优势和劣势

Compaction操作重写文件会带来很大的带宽压力以及短时间IO压力。它的核心操作是批量将大量小文件合并成大文件用以提高读取性能。
通常可以通过设置吞吐量下限参数hbase.hstore.compaction.throughput. lower.bound和上限参数hbase.hstore.compaction.throughput.higher.bound来自动调节系统的Compaction吞吐量。
也可以使用compactBwLimitnumOfFilesDisableCompactLimit来限制带宽,保证不会影响集群其他业务正常运行。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容