其他分享
首页 > 其他分享> > Hbase问题小结(一)

Hbase问题小结(一)

作者:互联网

1. Hbase读写优化

SKIP_WAL:只写缓存,不写HLog日志。这种方式因为只写内存,因此可以极大的提升写入性能,但是数据有丢失的风险。在实际应用过程中并不建议设置此等级,除非确认不要求数据的可靠性。
ASYNC_WAL:异步将数据写入HLog日志中。
SYNC_WAL:同步将数据写入日志文件中,需要注意的是数据只是被写入文件系统中,并没有真正落盘,默认。
FSYNC_WAL:同步将数据写入日志文件并强制落盘。最严格的日志写入等级,可以保证数据不会丢失,但是性能相对比较差。


2. bulkload入库的hfile是否有限制,可以怎么调整参数

最大文件大小。
如果一个区域的HFiles的大小之和超过了这个值,那么该区域将被一分为二。
该选项的工作方式有两种选择,
第一种是当任何store的大小超过阈值时,然后分割,
另一种是整个区域的大小超过阈值,然后分割,它可以通过hbase.hregion.split.overallfiles进行配置。

当检查到分裂时,我们是否应该合计整个区域的文件大小。

允许的hfile的最大个数,但是在bulkload中默认为32,可以调整这个参数进行修改


3. rowkey设计原则

解决热点问题:
Reverse反转:(典型:手机号码);
Salt加盐:将每一个Rowkey加一个前缀,前缀使用一些随机字符,使得数据分散在多个不同的Region,达到Region负载均衡的目标。前缀是随机的,读这些数据时需要耗费更多的时间,所以Salt增加了写操作的吞吐量,不过缺点是同时增加了读操作的开销。(当然这个缺点在很多情况下也是可以解决的,比如根据rowkey计算固定的Salt);
Hash散列或者Mod:用Hash散列来替代随机Salt前缀的好处是能让一个给定的行有相同的前缀;


4. 简单介绍Compaction

HBase是基于一种LSM-Tree(Log-Structured Merge Tree)存储模型设计的,写入过程如下

类型 作用 删除的内容
Minor Compaction 选取一些小的、相邻的HFile将合并成一个大的HFile 1. 默认删除选取HFile中的TTL过期数据
Major Compaction 将一个Store中所有的HFile合并成一个HFile 1.被删除的数据(打了Delete标记的数据)
2.TTL过期数据
3.版本号超过设定版本号的数据
触发条件 header 2
memstore flush compaction的根源就在于flush,
memstore达到一定条件就会触发flush生成HFile,
compact的根本目的是控制HFile的数量。
所以每次flush之后,都会判断是否要进行compaction
后台线程周期性检查 后台线程 CompactionChecker 会定期检查是否需要执行compaction
hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier
手动触发 HBase Shell、Master UI界面或者HBase API
header 1 header 2
hbase.hregion.majorcompaction Major compaction周期性时间间隔,默认值604800000,单位ms
major compaction耗时、耗资源,一般禁用
hbase.hregion.majorcompaction.jitter 抖动参数,默认值0.5
避免major compaction同时在各个regionserver上同时发生
major compaction就会在+\- 两者乘积的时间范围内随机发生
hbase.hstore.compaction.min 一次minor compaction最少合并的HFile数量,默认值 3
hbase.hstore.compaction.max 一次minor compaction最多合并的HFile数量,默认值 10
hbase.hstore.compaction.min.size filesize < 该参数值的为适合进行minor compaction文件,
默认值 128M(memstore flush size)
hbase.hstore.compaction.max.size filesize > 该参数值的不会加入minor compaction
默认值Long.MAX_VALUE,表示没有什么限制
hbase.hstore.compaction.ratio 判断filesize > hbase.hstore.compaction.min.size
的HFile是否也是适合进行minor compaction,默认值1.2。
hbase.hstore.compaction.ratio.offpeak 在非高峰时段是包含更大的StoreFiles压缩比例
默认5.0,需要配合hbase.offpeak.start.hour
hbase.offpeak.end.hour使用
hbase.regionserver.thread.compaction.throttle compaction线程的选择,默认2.5G(按官网应该是1.25G)
如果compaction大于此阈值,则将其放入largeCompactions,
否则放入smallCompaction
hbase.hstore.compaction.max * hbase.hregion.memstore.flush.size
hbase.regionserver.thread.compaction.large
hbase.regionserver.thread.compaction.small
largeCompactions与smallCompactions的线程池大小
hbase.hstore.blockingStoreFiles 每次刷新MemStore都会写入一个StoreFile
在任何一个Store中存在超过这个数量的StoreFile,
该region的更新就会被阻塞,直到compaction完成,
或者超过hbase.hstore.blockingWaitTime
默认:16
hbase.hstore.blockingWaitTime 在达到hbase.hstore.blockingStoreFiles定义的StoreFile限制后,
该region将阻塞更新一段时间。
在这段时间过后,即使compaction没有完成,该region也将停止阻塞更新。
默认9000,15min

这里的minor compaction、major compactionlargeCompactions、smallCompactions并不是对应的。参考上面参数说明

标签:hstore,问题,Compaction,compaction,Rowkey,hbase,小结,Hbase,HFile
来源: https://www.cnblogs.com/lillcol/p/14760377.html