一、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天）