实时系统HBase读写优化--大量写入无障碍
2013-03-11 18:14
190 查看
在使用hbase过程中发现在写入hbase的数据量很大时,经常发生写不进去的情况。而我们基于hbase的应用是对实时性要求很高的,一旦hbase不能读写则会大大影响系统的使用。下面将记录hbase写优化的过程。
1.禁止Major Compaction
在hbase进行Major Compaction时,该region将合并所有的storefile,因此整个region都不可读,所有对此region的查询都会block。HBase默认一天左右执行一次Major Compaction。我们将Major Compaction禁掉并用Cron脚本每天在系统空闲时对所有表执行major compaction。
Major Compaction的配置:
默认是1天,每个region会在创建时以当前时间初始化regionMajorCompactionTime,并将下一次的major compaction时间设为1+-0.2天。配置中将此值设为0禁止major compaction。
major_compaction的脚本:取出所有table,一一执行major_compact:
hbase通过split region实现水平的sharding,但在split的过程中旧的region会下线,新region还会做compaction,中间有一段时间大量的数据不能被读写,这对于我们这种online系统是不能忍受的。我们同样禁掉自动的split,而在晚上系统空闲时执行我们的splittool手动的split。
禁止split的配置:
splittool的逻辑比较简单。遍历所有region的信息,如果region大小大于某值(比如1G)则split该region,这样为一轮split,如果一轮后没有大于某值的region则结束,如果还有大于某个值的region则继续新一轮split,直到没有region大于某个阈值为止。这里提一下判断split完成的方法:通过检查hdfs上旧region的文件夹是否被清除来判断split是否结束。
3.设置blockingStoreFiles
这个参数的重要性是在我们的性能测试中发现的。我们禁掉major_compaction和split后理论上写入应该无障碍了,但在测试中发现写入单个region速度大于10M/s时还是会出现长时间无法写入的情况。通过查看log,我们发现了这行log“Waited 90314ms on a compaction to clean up 'too many store files'”,通过查看代码发现原来是blockingStoreFiles这个参数在作怪。
在flushRegion时会检测当前store中hfile的数量是否大于此值,如果大于则会block数据的写入,等待其他线程将hfile compact掉。这样,如果写入速度超过compact的速度,hbase就会阻止该region的数据写入。
我们将此值设为很大的值,使得此问题不会block我们的写入。
1.禁止Major Compaction
在hbase进行Major Compaction时,该region将合并所有的storefile,因此整个region都不可读,所有对此region的查询都会block。HBase默认一天左右执行一次Major Compaction。我们将Major Compaction禁掉并用Cron脚本每天在系统空闲时对所有表执行major compaction。
Major Compaction的配置:
<property> <name>hbase.hregion.majorcompaction</name> <value>0</value> </property>
默认是1天,每个region会在创建时以当前时间初始化regionMajorCompactionTime,并将下一次的major compaction时间设为1+-0.2天。配置中将此值设为0禁止major compaction。
major_compaction的脚本:取出所有table,一一执行major_compact:
TMP_FILE=tmp_tables TABLES_FILE=tables.txt echo "list" | hbase shell > tmp_tables sleep 2 sed '1,6d' $TMP_FILE | tac | sed '1,2d' | tac > $TABLES_FILE sleep 2 for table in $(cat $TABLES_FILE); do echo "major_compact '$table'" | hbase shell sleep 10 done2.禁掉split
hbase通过split region实现水平的sharding,但在split的过程中旧的region会下线,新region还会做compaction,中间有一段时间大量的数据不能被读写,这对于我们这种online系统是不能忍受的。我们同样禁掉自动的split,而在晚上系统空闲时执行我们的splittool手动的split。
禁止split的配置:
<property> <name>hbase.hregion.max.filesize</name> <value>536870912000</value> </property>配置项的含义是当region的大小大于设定值后hbase就会开始split,我们将此值设为500G,我们认为在白天系统繁忙时一个region不会超过此大小,在晚上时运行splittool将region分割开。
splittool的逻辑比较简单。遍历所有region的信息,如果region大小大于某值(比如1G)则split该region,这样为一轮split,如果一轮后没有大于某值的region则结束,如果还有大于某个值的region则继续新一轮split,直到没有region大于某个阈值为止。这里提一下判断split完成的方法:通过检查hdfs上旧region的文件夹是否被清除来判断split是否结束。
3.设置blockingStoreFiles
这个参数的重要性是在我们的性能测试中发现的。我们禁掉major_compaction和split后理论上写入应该无障碍了,但在测试中发现写入单个region速度大于10M/s时还是会出现长时间无法写入的情况。通过查看log,我们发现了这行log“Waited 90314ms on a compaction to clean up 'too many store files'”,通过查看代码发现原来是blockingStoreFiles这个参数在作怪。
在flushRegion时会检测当前store中hfile的数量是否大于此值,如果大于则会block数据的写入,等待其他线程将hfile compact掉。这样,如果写入速度超过compact的速度,hbase就会阻止该region的数据写入。
private boolean flushRegion(final FlushRegionEntry fqe) { HRegion region = fqe.region; if (!fqe.region.getRegionInfo().isMetaRegion() && isTooManyStoreFiles(region)) { if (fqe.isMaximumWait(this.blockingWaitTime)) { LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) + "ms on a compaction to clean up 'too many store files'; waited " + "long enough... proceeding with flush of " + region.getRegionNameAsString()); }默认值为7
this.blockingStoreFilesNumber = conf.getInt("hbase.hstore.blockingStoreFiles", 7); if (this.blockingStoreFilesNumber == -1) { this.blockingStoreFilesNumber = 1 + conf.getInt("hbase.hstore.compactionThreshold", 3); }
我们将此值设为很大的值,使得此问题不会block我们的写入。
<property> <name>hbase.hstore.blockingStoreFiles</name> <value>2100000000</value> </property>
相关文章推荐
- 实时系统HBase读写优化--大量写入无障碍
- 实时系统HBase读写优化--大量写入无障碍
- 实时系统HBase读写优化--大量写入无障碍
- 实时系统HBase读写优化--大量写入无障碍
- 实时系统HBase读写优化--大量写入无障碍
- innodb大量写入优化
- innodb大量写入优化魏
- innodb大量写入优化掳
- android 大量数据写入数据库的优化
- MyISAM读写并发优化
- Android性能优化(二)- 丝般顺滑地加载大量图片
- 权限迁移_涉及到大量数据插入的优化手段
- Android Bitmap大量使用不产生OOM之“加载大图片资源优化”
- hbase 缓存优化,提高读写效率
- java 用jxl以及poi对excel的读写以及性能的优化
- Sqlite3插入大量数据性能优化
- python中 对文件的读写操作 以及如何边写入 边保存flush()
- fwrite读写大量数据出现的错误
- 查询大量数据写入文件
- 【阿里云产品公测】利用PTS服务优化网站数据库读写性能