大数据业务系统，在运行过程中会产生大量历史数据，这些历史数据日积月累下来，除了增加集群的存储成本，也会影响大数据集群之上的应用系统的运行效率（因为整个大数据集群的hdfs, hive, hbase等存储引擎随着负担越来越大，其响应效率会有所降低）。
所以数据治理会强调对数据进行全生命周期的管理，既要考虑数据的采集获取，也要考虑数据的备份归档。我们不能因为大数据集群本身具有可横向扩展，容量大，单位存储成本低这些特点，就对数据 “只进不出”。因为缺少了治理的数据集合，再多也不能称为“数据湖泊”，而是“数据沼泽”，是不利于数据价值的分析挖掘的。
在大数据业界，对于数据的生命周期管理，普遍的做法是，根据业务特点，分析数据使用状况，将数据分为冷数据与热数据（更细致的还有温数据），然后对冷热数据采取不同的管理策略。常见的数据管理策略有：
- 利用云对象存储的力量：将热数据保存在当前大数据集群中支撑当前的业务系统，而将冷数据备份到云对象存储如oss, s3上；
- 冷热数据分集群存储：将热数据保存在当前大数据集群中支撑当前的业务系统，并搭建专门的冷数据集群，将冷数据转存到冷集群中；（冷集群更侧重存储能力，热集群更侧重计算能力，在集群底层服务器选型上各有侧重，从而均衡成本）；
- 利用hdfs本身提供的分级存储的策略：hdfs新版本本身（其实也不新了，从3.0开始就逐步完善这块了，详情见jira hdfs-2832,）也是支持tiered storage即分级存储的，可以对不同的目录，根据其数据冷热程度不同，动态配置不同的存储策略，从而存储到不同的底层存储介质上。可以使用的存储类型 storage types 有 archive, disk, ssd 和 ram_disk，可以配置的存储策略 storage policies 有 hot, warm, cold, All_SSD, One_SSD, Lazy_Persist and Provided。
- 直接删除冷数据：当前的大数据集群只保存业务需要的数据，而将业务不需要的历史数据，定期通过脚本进行删除。这种方式，因为需要删除数据，所有只有在业务方确认数据确实不需要了，而且公司真个成本又有限的情况下，才会使用。
在某大数据系统的案例中，在跟客户充分沟通后，出于成本的考量，他们采用了第四条，即直接删除冷数据的方案（当然还有部分易操作性的考量）。
该方案的实现其实只是几条ddl语句，其调用方式和核心内容如下：
beeline -u jdbc:hive2://ip:10000 -hivevar hs_cic_db=${hs_cic} -hivevar clear_date=${clear_date} -f xxx.sql
xxx.sql 脚本内容如下：use ${hs_cic_db}; alter table xx drop if exists partition(part_date < ${clear_date});
进一步技术细节，可以参考：
