HBase 压缩策略DateTieredCompactionPolicy

        HBase是采用Log-Structured Merge Tree的架构,随着Flush阶段的不断触发,生成许多的HFile(默认128M),而不管是对于HDFS还是现有的HDD磁盘,大量的文件都会产生许多的问题:

1、增加HDFS NameNode的负载

2、查询数据会增加磁盘寻址次数,增加io

        但是随着SDD磁盘的成本下降,磁盘寻址的问题也将不是影响性能的主要因素,同时hdfs小文件利器Ozone的提出,未来HBase是否会考虑废弃Compaction,采用更加优雅的方式来完成过期/被删除 数据的清除,这些都将会是社区会讨论的问题。

        Compaction根据合并的规模,分为了Minor Compaction和Major Compaction:

1、Major Compaction,是将一个Store下的所有StoreFile合并成一个StoreFile,同时清理无效数据:被删除的数据、过期的数据、超过Version设置的数据。对于Major Compaction的优化就是选择在合适的时间触发,并避免过于占用集群io资源。许多的大佬都建议关闭自动定期的Major Compaction,而采用手动在集群业务低峰期触发,但是当集群未存在明显的业务低峰期时,可保留自动触发,同时设置限流,目前笔者是这样实现。

2、Minor Compaction,是根据特定的策略选取一些符合策略的StoreFile进行合并。

HBase提供了很多Minor Compaction的StoreFile选取策略,包括:StripeCompactionPolicy、RatioBasedCompactionPolicy、ExploringCompactionPolicy、FIFOCompactionPolicy、以及本文主角DateTieredCompactionPolicy。其他的压缩策略可参照范神的两篇博客:HBase Compaction身世之旅、HBase Compaction改造之路。需要根据业务的特定选择合适的压缩策略,本文介绍日期分层压测策略DateTieredCompactionPolicy,并介绍笔者的业务场景。

业务特点

        本司主营业务为IOT智能家居,HBase中主要存储智能设备采集上来的数据。

数据及业务特点:

    1、跟时间强相关

    2、没有删除操作

    3、最近两天的数据被查询的概率非常高

    4、查询大多根据TimeRange和

        由于上面的特点,在Compaction时,希望:

    1、较为古老的StoreFile不参与到压缩中来增加不必要的IO

    2、Scan时可以根据TimeRange过滤掉更多不存在目标数据的StoreFile

    3、同时由于设置了TTL,对于老的StoreFile可以实现整个文件直接删除

由于使用的HBase1.2.0-cdh5.7.2并不存在日期分层压缩策略,需要打入对应的patch: HBASE-15181

DateTieredCompactionPolicy

        DateTieredCompactionPolicy采用时间窗口的概念,时间窗口越来越大,先介绍主要的配置参数:

    1、hbase.hstore.compaction.date.tiered.base.window.millis 

        初始窗口大小,默认为6h。最近6h生成的HFile会在一个Window中,这里的最近6小时是指:[now/6h, (now/6h) + 1),相当于UTC时间的每日[0,6),[6,12),[12,18),[18,24)。并不是真正意义上的最近的6小时。

    2、hbase.hstore.compaction.date.tiered.windows.per.tier

        窗口增加倍数,假如为2,那么窗口的大小依次为:6h,12h,24h以此类推。当一个窗口中StoreFile的数量达到设置的文件数后会就会压缩成一个。同一个窗口内默认采用ExploringCompactionPolicy压缩策略。

    3、hbase.hstore.compaction.date.tiered.max.tier.age.millis

        最老的窗口,超过这个时间的StoreFile将不会进行Minor Compaction,默认为Long.MAX_VALUE。

    那如何判断一个StoreFile在不在一个Window中呢?

        在hbase1.2中每一个HStore维护了一个TimeRangeTracker,这会记录写到当前MemStore的Cell的timestamp的范围。客户端构建Put时,可以指定当前Put的timeStamp,默认当Server的当前系统时间(ms)。在TimeRangeTracker中存在minimumTimestamp和maximumTimestamp两个字段,用来表示当前Memstore的TimeRange,当触发Flush时,这将写到HFile中,用来标识HFile的TimeRange。如果HFile的maximumTimestamp<窗口的开始时间时,当前HFile肯定不属于当前窗口。

       应用DateTieredCompactionPolicy,也是因为笔者还存在另外一层业务。需要每日凌晨将昨天所有设备产生的数据拉取到hive中,为统计分析业务提供数据。起初使用Spark on HBase SnapshotScan时,由于无法通过设置TimeRange过滤掉更多无用的HFile,导致数据抽取项目对集群的IO影响非常大,在应用了该压缩策略后,数据抽取时,不论是集群的IO还是抽取的速度都有很好的提升。

你可能感兴趣的:(HBase 压缩策略DateTieredCompactionPolicy)