Hbase - Compaction合并机制

Hbase

Hbase - Compaction

当MemStore达到给定的大小时(hbase.hregion.memstore.flush.size),将其数据flush到一个StoreFile中,存储的StoreFile数量会随着时间的推移而增加(数据源源不断的来)。Compactions是通过将StoreFile Merging(合并)在一起来减少存储的StoreFile数量,从而提高读操作的性能。执行Compactions可能会占用大量的资源,多种因素下,可能会提高或者阻碍性能,(因为执行Compactions会进行大量IO操作)。

Compactions分为两类: Minor(小合并)和Major(大合并)。Minor和Major的Compactions区别。

Minor Compactions : 通常会选择少量较小的相邻StoreFile,然后将它们重写为单个StoreFile。但是Minor Compactions并不会删除(filter out)或过期的版本。Minor Compactions最终结果是Store中的StoreFiles数更少,StoreFiles会更大。
Major Compactions : 最终结果是每个Store只有一个StoreFile。Major Compactions还处理标记为删除(Hbase中的删除并不是删除,而是标记为delete)和超出设定版本号的数据。

Compaction and Deletions

在HBase中发生显式删除时,实际上并不会删除数据。而是写一个tombstone标记(标记为需要删除,墓碑都立好了)。逻辑上的删除可防止查询请求,给出返回结果。在Major Compactions期间,会将数据真正的删除,将删除StoreFile中有标记的数据。如果由于TTL过期而导致删除的,则不会创建tombstone 标记。相反,过期的数据将被过滤掉,并且不会写回到压缩的StoreFile中。

Compaction and Versions

在创建列族(Column Family)时,可以指定要保留的最大版本数HColumnDescriptor.setMaxVersions(int versions)默认值为3,如果存在的版本数大于指定的数量,则会过滤掉多余的保本,并且不会被写入到compact后的SotreFile

Major Compactions可能会影响查询结果
在某些情况下,如果显示的删除了新版本,则可能会无意中恢复旧的版本。这种情况只可能发生在Compactions完成之前。

理论上讲,Major Compactions可以提高性能。但在高负载的系统上,Major Compactions可能需要不适当数量的资源,并对性能产生不利影响。在默认配置中,Major Compactions将每7天运行一次。但有时这不适用于生产中的系统。可以进行手动配置(修改hbase-site.xml文件的 hbase.hregion.majorcompaction参数 一般情况下在线上都设置为0 即关闭 Major compact)
(Compactions 不执行 region merges)

触发条件

Memstore flush
由于memSotre会不断的将数据flush磁盘生成StoreFile,因此StoreFile会越来越多,所以需要对SotreFile进行合并,在每次flush的时候会对当前的Store的StoreFile进行判断,一旦满足Minor CompactionS或Major Compactions的条件便会触发执行合并操作

定期Compaction

后台启动一个线程,定期触发Sotre是否需要执行Compaction,检查Store中的StoreFile是否大于阈值

手动触发

通过HBase Shell、Master UI界面或者HBase API等任一种方式 执行 compact、major_compact等命令。

参考 点点点点点我

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容