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后的SotreFileMajor 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等命令。
参考 点点点点点我