Tuning Of Hbase

cuiyaonan2000

已于 2023-07-03 17:27:36 修改

阅读量535

点赞数

分类专栏： Big Data Storage 文章标签： Hbase

于 2023-07-03 17:24:31 首次发布

本文链接：https://blog.csdn.net/cuiyaonan2000/article/details/131518564

版权

Big Data Storage 专栏收录该内容

37 篇文章 6 订阅

订阅专栏

序言

持续整理cuiyaonan2000@163.com

参考资料:

hbase的调优_hbase调优_AllenGd的博客-CSDN博客

历史数据

因为:

Hbase的所有操作都是追加插入操作（故此hbase有历史版本的概念存在）。它可以往数据里面insert，也可以update一些数据，但update的实际上也是insert，只是插入一个新的时间戳的一行。Delete数据，也是insert，只是insert一行带有delete标记的一行。

所以有必要进行历史数据的删除,否则Region的数量会越来越大.

创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。

Compact

在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。---由此可见minor的合并是将内存中的数据实例化到hdfs中cuiyaonan2000@163.com

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。-----------major compact是针对一个Region下的所有StroreFile进行合并和拆分 ,所以比较消耗资源.另针对的是相同的key为id进行合并,不是随便合并cuiyaonan2000@163.com

由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。

实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。

hbase为了防止小文件（被刷到磁盘的menstore）过多，以保证保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的store file，这个过程就称之为compaction。在hbase中，主要存在两种类型的compaction：minor compaction和major compaction。

Minor Compact

　　Minor Compact是指少量HFile文件按照Minor Compact规则进行合并；它的正常流程是这样的，探测到有新的文件刷进来（比如因为memstore的flush，当然可以直接写入HFile而跳过memstore，比如Bulk写入），此时Region Server只要发现同一个列簇有3个及以上的文件，将会扫描文件列表，然后将符合合并规则文件纳入到list中，并且list中文件数>1，则将会进行compact；其中规则如下：

hbase.hstore.compaction.min :默认值为 3，表示至少需要三个满足条件的store file时，minor compaction才会启动
hbase.hstore.compaction.max 默认值为10，表示一次minor compaction中最多选取10个store file
hbase.hstore.compaction.min.size 表示文件大小小于该值的store file 一定会加入到minor compaction的store file中
hbase.hstore.compaction.max.size 表示文件大小大于该值的store file 一定会被minor compaction排除
hbase.hstore.compaction.ratio 将store file 按照文件年龄排序（older to younger），minor compaction总是从older store file开始选择

　　所以看到minor的规则稍微有点复杂，原则是减少合并（文件合并要门当户对），避免形成大文件（达到一定程度之后就不在合并）。
　

Major Compact

　　数据清理的工作，都是在Major Compact里面去做，Major操作是无差别的将所有的同一个column family的所有文件进行合并；在合并的过程中将会对数据进行清理，那些需要删除掉的，过期的数据都会在Major Compact里面去做，当然也包括整合数据排序（HBase的数据排序是字段顺序）。所以Major Compact在数据层面做的事情还是挺多的，但是因为他产生的IO消耗同样非常巨大，所以一般都会禁用自动major compact，而是会手工进行数据合并。