一、HBase 的TTL 应用的需求
全链路的持久化为HBase的一个应用场景，主要实现的场景描述如下：
-
- 公司所有的业务系统的每一次调用过程称之为一次链路 例如： 用户的每次开启充电，从app端的开始调用，到最后充电桩开始将能量输送到车上，这是一个链路
- 监控系统会将每次链路经过的服务名、服务的参数、响应时间等过程中的信息从每个服务节点采集后，存储到消息队列，消息队列的数据一部分用于链路分析，同时会将原始数据持久化到hbase
- 针对有问题的预警，监控系统会将对应的链路地址以预警的方式推送到开发人员
- 开发人员收到预警消息之后，会查询这次链路过程中的原始数据。
业务处理流程如下：
- 目前上述场景，每天的写入数据量为2.5T左右，数据条数为15亿左右.由于集群规模不大，并且多个业务公用一套集群，集群的写入和查询压力都比较大，大数据表的读写对集群要求较高，很容易造成集群的不稳定，并且大数据表带来的存储成本也是非常之高的
- 通过对业务的仅一步分析：
- 目前hbase保留的业务数据，实际上保留周期7天，就可以满足业务要求，因此hbase中的数据不需要长久保存。基于此，需要开始研究HBase的ttl 验证
二、TTL技术验证
目前网上关于TTL的验证，版本较多，有一个比较大的问题是，使用TTL之后，数据是否可以自动删除
集群信息如下：
集群一：
HBase: 1.1.2
存储: HDFS
参数：hbase.hregion.majorcompaction 值：0
集群二：
HBase: 1.1.2
存储：Azure WASB
参数：hbase.hregion.majorcompaction 值：0
验证过程：
1.创建表
2.开启TTL
3.开启数据写入，经过验证发现
数据可以自动删除
表目录和删除的临时目录均可以自动删除
/apps/hbase/data/data/default/TTraceTest
/apps/hbase/data/archive
总结：
1.1.1.2 版本的hbase 的表开启ttl之后，数据可以自动删除， 目前在小表上进行了2个小时的验证，下一步将在大表写入上开启较长时间的验证（比如TTL 保留7天）
