记一次hbase的TTL功能不生效问题
最近接手了一个的hbase和hadoop的小集群，被告知hbase有TTL不生效的问题（磁盘未释放），做个记录
hbase版本1.2.7
hdfs版本2.7.5
问题描述：
hbase中所有的表都配置了TTL，然而hdfs使用量依然不断增加，直至磁盘打满，datanode全挂。
解决过程：
1、在我负责接手这部分服务后，了解到之前伙伴的处理方式简直简单粗暴，每次出现问题，直接rm -rf datanode数据目录下的 BP-XXXXX目录。。。终于知道hdfs为什么会有9000+个corrupt block了。
2、二话不说，先fsck，清理掉这些坏块。另外看到namenode ui还有这么个东西
1月3日开始的一个Rolling upgrade。。。现在已经是6月份了，本着既然正常用着就不随便变更的原则，对于Rolling upgrade咱们经验也不丰富，暂时先不管。
3、从hbase原理上来看看待TTL这个问题，hbase的TTL本质是先对数据打一个墓碑标记，真正删除的时候是在major compaction的时候生效（有那么点类似于JVM复制算法）；另外一个是MIN_VERSION要为0，否则无论如何TTL都不会生效。
了解当前hbase的情况，使用默认配置7天一次major compaction，但是当前场景是数据4天会写满集群，数据保存1天就够用，那么正常来说集群空间使用应该不超过50%。所以major compaction的频率也应该是1天一次比较合适。
4、按照正规流程。做好变更的准备工作（具体怎么变更，怎么回退），周知业务，变更hbase。
5、发现问题依然存在，具体表现为，从hdfs的层面看使用的空间很小，当前约为10%，但是具体每个datanode的空间使用率居然为50%，经过仔细核对，发现datanode数据目录有一个trash目录。
如图，datanode的数据目录大部分是被trash目录占据，这个目录是做什么用的呢？
对比datanode日志中的Deleted XXX的日志如
2020-06-30 13:22:09,295 INFO org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetAsyncDiskService: Deleted BP-647811859-192.168.167.251-1578019624533 blk_1074596977_857176 file /data/data/hadoop/current/BP-647811859-192.168.167.251-1578019624533/current/finalized/subdir13/subdir12/blk_1074596977
和trash目录中的文件，可以确认所谓的“Deleted” 就是移动到了trash目录。
6、我们都知道hdfs有trash机制，即hdfs删除的数据，会被移动到/user/XXX/.Trash中
但是从来没听说过，datanode也有类似这个机制的机制。 这种细节，又得翻源码了。
7、从日志提供的类为入手点，找到如下代码和注释
注释写的很清楚了。。。 所谓的trash，其实是一种backup。表面上hbase TTL和“hadoop滚动升级”就像完全不相干的两件事，经过钻研发现有着千丝万缕的联系。
8、至于Rolling upgrade这个坑怎么填，下次再聊