HBase 压缩策略DateTieredCompactionPo

        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还是抽取的速度都有很好的提升。