前言
又是一个周末,学习脚步不歇,今天给大家推荐的是关于HBase MOB特性的介绍,希望能帮助大家,之前作者有翻译过这篇文章,有社区同学提出文章有些地方翻译不当,小编重新进行了二次翻译与推敲,若有不当地方大家可以指出,希望能够共同进步。
介绍
HBase MOB特性是在HBASE-11339中引入,这一特性改善了对中等大小值的低延迟读写(基于我们的测试结果理想状态是100K到10M),这使得可以更好的存储文本,图片和一些其他的中等对象[1],HBase MOB特性通过将引用文件和MOB对象的IO路径分离来实现这一改进,对MOB使用不同的压缩策略并因此减少了因为HBase压缩所导致的写放大问题。若一个表的MOB文件存储在MOB区域(MOB region)中,则意味着该区域中将存在大量的MOB文件。请参阅下图中的MOB体系结构。
MOB体系结构
最初,MOB文件相对较小(少于1或2个HDFS块)。为了提高HDFS的效率,MOB文件通过称为MOB压缩方式,周期性地合并成较大的文件,该操作独立于正常的压缩过程。 MOB压缩的初始版本将当天的多个MOB文件重写为较大的MOB文件。通过下面示例我们可以更清楚了解这一过程。表t1有两个分区(r1,r2),一个列族f1,并且该表启用了MOB属性。你可以看到如下两个前缀:
D279186428a75016b17e4df5ea43d080 对应分区r1中startkey的散列值
D41d8cd98f00b204e9800998ecf8427e 对应分区r2中startkey的散列值
r1分区在2016.1.1和2016.1.2各有两个MOB文件,r2分区在2016.1.1有三个MOB文件,通过下面命令我们可以查看到上述文件
>ls /hbase/data/mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/f1
D279186428a75016b17e4df5ea43d08020160101f9d9713ab2fb4a8b825485f6a8acfcd5
D279186428a75016b17e4df5ea43d08020160101af7713ab2fbf4a8abc5135f6a8467ca8
D279186428a75016b17e4df5ea43d080201601029013ab2fceda8b825485f6a8acfcd515
D279186428a75016b17e4df5ea43d080201601029a7978013ab2fceda8b825485f6a8acf
D41d8cd98f00b204e9800998ecf8427e20160101fc94af623c2345f1b241887721e32a48
D41d8cd98f00b204e9800998ecf8427e20160101d0954af623c2345f1b241887721e3259
D41d8cd98f00b204e9800998ecf8427e20160101439adf4af623c2345f1b241887721e32
通过MOB压缩之后,r1中20161.1和20161.2两天的MOB文件每天被压缩成一个文件,r2中2016.1.1的三个MOB文件被压缩成一个文件,结果如下:
D279186428a75016b17e4df5ea43d08020160101f49a9d9713ab2fb4a8b825485f6a8acf
D279186428a75016b17e4df5ea43d08020160102bc9176d09424e49a9d9065caf9713ab2
D41d8cd98f00b204e9800998ecf8427e20160101d9cb0954af623c2345f1b241887721e3
由于只有在同一区并且为同一天的MOB文件才可压缩在一起,因此在一个MOB区域中的目录下,一年产生的MOB文件数为365乘以分区数目。若有1000个分区通过MOB压缩,10年后将会有365 x 1000 x 10,3.65(百万)个文件产生并且文件数量会持续增长。但是,由于HDFS中一个目录的文件数目受内存限制[2],若MOB文件数超过HDFS限制后,MOB表将不再可写入文件。HDFS在一个目录下默认的最大文件数为100万,那么对于1000个分区来说,文件数量将在3年左右达到这个极限值。所以分区越多,文件数量将会会越快达到这个极限值。
从HBASE-16981开始引入按周和月的MOB压缩分区聚合策略后,MOB文件存放比例相应提高了7%和30%。
HBASE-16981基本思路是将一周或者一个月的MOB文件压缩合并为更大的文件。根据ISO8601定义的周(起始为周一结束为周日),若采用周策略进行MOB压缩后,则每个分区每周会产生一个文件,同理,用按月MOB压缩后,每月会生成一个文件,最终在一个MOB区域目录下的文件数分别为52 乘以分区数和12乘以分区数。这样就大大减少了压缩后MOB文件的数量。
最初的方法
当MOB压缩发生时,HMaster会在一个日历月或一个日历周内将MOB文件合并到更大的文件中。根据MOB压缩发生的频率,文件可能多次被压缩。例如,若MOB采用每天压缩及每月聚合的策略,那么,第1天所有的MOB文件会被压缩为一个文件,第2天将第1天和第2天产生的MOB文件被压缩为一个新的文件,第3天将前两天产生的文件压缩为一个新文件,以此类推,一个月后,第1天的文件压缩会超过30次,因此也就将写的IO数量放大了30倍以上。
HBase MOB的设计目标是为了减少由MOB压缩而导致的写入放大。上述的这种方法没能达到设计目标。
最终的方法
为了克服最初方案的不足,在HBASE-16981中采用了新的按周和月分阶段压缩策略。图2展示了如何按月压缩策略,同时按周压缩策略与此类似。
图2 按月MOB压缩策略
图2所示的MOB压缩发生在2016.11.15。根据配置的MOB阈值,日分区压缩当前日历周中的文件,上图中11.14和11.15的两天的文件各自压缩。当前月份(11月)中的文件基于周阈值(MOB阈值 x 7)分区压缩过去几个日历周中的文件,如11.1-11.6和11.7-11.13的文件分别压缩。11月之前的文件按月进行压缩,例如10.1-10.31文件压缩在一起。需要注意的是11月的第1个日历周是从10.31-11.6结束。由于10.31是10月的最后一天,因此当天的文件压缩是按照月分区进行压缩,这样11月的第一周压缩的天数只剩下6天(11.1-11.6),如果MOB压缩阈值和压缩大小设置合理,那么第一周会有5个压缩文件。
通过这种设计模式,MOB文件可以通过2个阶段或3个阶段完成压缩。在每个阶段,日、周、月分区都会随着MOB压缩阈值的增加而变化。通常情况下,MOB文件每月最多3次压缩,每周最多压缩2次。具体的设计细节可以参考[3]。
用法
在默认情况下,MOB压缩分区策略是每日一次。若要用周或月策略,可以在MOB列族中添加了一个新属性字段:MOB_COMPACT_PARTITION_POLICY。用户可通过HBase shell在创建表时设置该属性。例如:
>create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly’}
同时也可以改变该属性字段值,,命令如下:
>alter 't1', {NAME => 'f1', MOB_COMPACT_PARTITION_POLICY => 'monthly'}
如果压缩策略从每日改为每周或每月,或从每周改为每月,则下一个MOB压缩将重新压缩之前压缩的MOB文件。如果策略从每月或每周改为每日或每月更新,则对已使用先前策略压缩的MOB文件将不会与新策略再次执行压缩。
结束语
HBASE-16981解决了文件数大量增加的问题,并在Apache HBase 2.0.0版本中使用。CDH的CDH5.4.0+及以后的版本开始使用HBase MOB特性,其中从5.11.0开始使用HBASE-16981修复的版本。
本文虽多次斟酌,但由于译者水平有限,有翻译不当之处还请大家多多指出,互相学习。
参考
[1]https://blog.cloudera.com/blog/2015/06/inside-apache-hbases-new-support-for-MOBs/
[2] https://blog.cloudera.com/blog/2009/02/the-small-files-problem/
[3] https://issues.apache.org/jira/browse/HBASE-16981
猜你喜欢
#大数据和云计算机技术社区#博客精选(2017)
NoSQL 还是 SQL ?这一篇讲清楚
阿里的OceanBase解密
#大数据和云计算技术#: "四有"社区介绍
大数据和云计算技术周报(第38期):NoSQL特辑
大数据和云计算技术周报(第39期)
新数仓系列:Hbase周边生态梳理(1)
《大数据架构详解》第2次修订说明
简单梳理跨数据中心数据库
云观察系列:漫谈运营商公有云发展史
云观察系列:百度云的一波三折
云观察系列:阿里云战略观察
超融合方案分析系列(7)思科超融合方案分析
加入技术讨论群
《大数据和云计算技术》社区群人数已经3000+,欢迎大家加下面助手微信,拉大家进群,自由交流。
喜欢QQ群的,可以扫描下面二维码:
欢迎大家通过二维码打赏支持技术社区(英雄请留名,社区感谢您,打赏次数超过108+):