hbase集群表在线调整(TTL/compression)

今天发现hbase集群的hdfs使用量已经接近80%，检查发现一个表数据量特别巨大，该表会记录用户每天的一次活动属性，按照4亿用户*197天，有800亿条的数据存放在表中——4TB，对于一个表来说过于大了。有两个问题：1、未开启压缩；2、没设置TTL

经过和业务方讨论，只保留最近93天（3个月）的数据，然后开启LZO压缩。

理论上所有的表都应该开启压缩，但是早期使用时没对业务方进行限制，导致现在有些表没开启压缩，而数据量又特别大，所以考虑在线开启压缩和TTL。

那么就需要考虑几点问题：

1、在线修改表属性是否稳定，0.92版本引入后作者也不保证100%成功，慎用

2、修改后是否生效，在哪一步生效

3、能否手动使其生效

考虑hbase写模型，压缩发生在HFile文件需要写HDFS的过程，这个过程有3种，第一：flush、第二：split、第三：compact。而对于已经存在的数据，应该只能在compact阶段进行。compact的原理是读region中已有的HFile，然后写新HFile，理论上应该能保证新HFile写的时候是压缩的。

查看代码：compact过程分为普通compact和majorcompact，普通compact就是N个文件合一个，N可以设置；majorcompact就是region下所有的文件合1个。先读取原有文件，然后写新HFile：

对旧文件的scan：

scanner = new StoreScanner(this, scan, scanners,majorCompaction ? ScanType.MAJOR_COMPACT : ScanType.MINOR_COMPACT,smallestReadPoint, earliestPutTs);

这个scanner会把表的ttl参数传递进去，所以会根据TTL来过滤不要的数据

writer = createWriterInTmp(maxKeyCount, this.compactionCompression,true)，写入的时候传入了压缩参数，ok。就是说在compact的时候TTL和Compression都能生效。

稳定性需要实际测试，在测试集群进行测试。

第三个问题，手动生效。compact有几个触发方式，1、代码HBasdAdmin.compact，2、hbase页面中点击compact，3、hbase shell中调用compact命令。经测试1不生效，报connection reset by peer错误；2方法集群无反应；3方法中compact集群无反应，major_compact后开始compact过程。

由于表中region开启了每天的compact，所以一个region最多2个文件，无法达到min_compact的最小size，系统就忽略了compact请求。这点和split不太一样，一旦发出split命令会强制split一个region而不做检查。而major_compact是无视该限制，将region中所有文件合成一个。

最后，再评估一下操作对线上集群的影响：

1、修改表参数，只是对表的2个参数进行了修改，不对实际数据产生影响

2、compact过程是hbase自身的过程，将压缩和TTL放到compact过程中进行，不影响hbase使用，对读写都不影响。