数据降本利器：无用数据下线自动化

作者：见风、梦姣

部门：数据中台

一、前言

有赞在数据成本治理方面，做了很多探索和实践。感兴趣的可以关注历史文章：

• 关于数据成本与治理：《从量化到优化，详解有赞离线数据降本之路》
• 关于成本账单&运营：《数据成本知多少？全域账单解烦恼》

降本的领域很多，今天的内容，我们主要聚焦在“离线数据和任务”的成本优化。

二、背景

当前，成本观念已经深入人心，有很多小伙伴主动参与到日常降本的工作当中，节省了大量成本。

不过成本治理不是一锤子买卖，新阶段，我们面临着新问题，

那就是：成本治理的ROI低下。什么意思呢？展开说说。

在降本的初期，治理方很自然地会先“抓典型”。

挑成本大户重点缩减、优化，可以立竿见影，快速见效。集中处理，可能在一天半天内，省下上万成本，ROI极高。此时，业务方的积极性也很高，不用多说，自觉主动。

但到了中后期，“巨头”们都被消灭了，留下的都是零零散散的小数据、小任务。如果人工去判断和处理，需要投入大量的精力，ROI很低。可谓食之无味，弃之可惜。

虽然每个任务占用资源都不多，但是数量庞大，整体的成本不低。如何高效地优化，便是我们要解决的问题。

其他公司或许面临同样的问题，希望本文内容对大家有所帮助。

三、现状

基于上面的背景，我们意识到：不计成本的成本治理，是在耍流氓，自动化下线，势在必行。当然，在开展这项工作之初，我们还是很严谨地分析了现状、问题，并且评估了预期的收益。

当前我们已经将每个数据、任务的成本量化，并且做了初级的使用情况分析，提供了下线建议。比如：无下游任务、过去n天未被使用、任务长期失败等。

但是真实的下线动作，还是需要每个owner去触发。

这里边有两个不便利的点：

1. 下线建议的参考数据准确率低。需要业务方根据经验去判断和确认，比较费时并且风险高；
2. 无法批量操作。成百上千的琐碎数据，我们自己也不好意思推动业务关注。

对下线的判断是否准确，依赖几个关键点：

1. 数据owner归属准确性（谁负责），有人负责，才能放心对其操作，出现异常及时补救；
2. 数据血缘完备性（数据由谁产出，又被哪个任务使用），目前我们的研发平台支持SQL，数据导入导出、脚本等类型的任务，每个任务使用或者产出了什么数据，都需要被解析；
3. 数据行为日志的完整性（表什么时候被谁使用了），所有的数据查询，需要统一收口，并保留审计日志，便于分析使用情况。

解决了准确性问题（比如99%准确率），再结合一些防御策略（比如数据备份等），就可以考虑做自动下线（要支持快速定位问题&恢复），提升降本的效率。

那么可自动下线数据（后边我们称之为：降本池子）成本有多少呢？

我们统计过，根据当前的规则，大概有5000张表和任务可被下线，成本约70万/年。降本池子的余额增速约5%，年增速约为70%。综合看，自动化降本的收益约为120万/年。

如果按平均1张表需要1小时的投入算，需要2人年的人力投入，ROI确实不高。但是如果实现自动化，剔除一次性的投入之外，收益可观。

四、方案设计

自动化下线的潜力很大，心动不如行动。

整体的方案如下图所示：

为方便说明，先简单介绍下图里涉及的系统：

• 数据研发平台（下文简称DP），一站式大数据管理与应用开发平台
• 数据资产平台（下文简称Meta），数据资产管理、治理平台
• BI系统，有赞自研的可视化数据分析系统
• RDS，有赞自研的数据库服务平台

图中橘黄色为自动化下线系统的后端和前端。

其中后端负责实际的下线、运维动作，定时执行。主要能力是：

1. 读取RDS里待下线资产信息（该信息在离线加工后，通过DataX导入RDS），根据规则做通知、下线等操作，并记录过程和结果；
2. 执行下线逻辑，需要和Hive、DP对接，以实现数据的删除、恢复，还有任务的暂停和重启；
3. 下线逻辑必要的配置，在Apollo里；
4. 通过飞书发送下线预告、结果信息；
5. BI系统，用于分析待下线数据、下线进展、状态等；
6. 提供用户交互操作接口。

为了实现自动化下线，我们需要知道每个数据的流转过程和使用情况，然后制定合理的规则挖掘待下线数据，再配合一定的流程去做实际的下线动作。这个过程，可以抽象出三个重要环节：数据准备、下线挖掘、自动下线，下面我们分别介绍。

五、系统实现

5.1 数据准备

在数据准备方面，我们会去采集到数据、任务的状态、血缘关系、使用情况等信息。并保证较高的的准确率，才能安全地做自动下线。

主要工作：

1. 从各个系统（Hive、Hbase、DP、BI等）采集完备的元数据信息，并做好准确的owner归属；
2. 根据SQL、任务配置、实体关系等，解析血缘关系，确保较高的血缘覆盖率；
3. 采集审计日志，解析每个行为用到的数据（所有离线数据都统一收口了），并保证准确率；
4. 采集加工DP任务依赖、BI看板使用情况。

最终在Hive里，有DP任务依赖、数据和任务血缘、元数据信息、数据使用记录、看板使用情况这几份数据，供下一步加工分析。

5.2 下线挖掘

哪些数据可以下线呢？这就是下线挖掘要做的事情。根据依赖、血缘、使用记录等数据，分析出无用的数据和任务。

根据我们的经验，归纳出以下几种情况：

1. 长期执行失败任务：这类任务不产出准确数据，一直在浪费计算资源，可以被暂停。根据任务的调度频率，判定标准有所差异：
   1. 季级任务从6个月前的1号开始调度天数全部失败，且调度次数大于等于2次
   2. 月级任务从3个月前的1号开始调度天数全部失败，且调度次数大于等于3次
   3. 周级任务从6周前的周一开始调度天数全部失败，且调度次数大于等于6次
   4. 天级任务从15天前开始调度天数全部失败，且调度次数大于等于15次
   5. 小时级任务从3天前开始调度天数全部失败，且调度次数大于等于72次
2. 无任务无下游表：这类数据既找不到对应的产出任务，也没有被其他任务使用。
3. 有任务无下游表：这类数据有对应的产出任务，也在定期更新，但是没有下游使用。
4. 有下游，但是下游长期无访问 ：比如某个数据的下游是BI看板，虽然被引用了，但是看板长期无访问，也可以理解为该数据无用。

下线挖掘的过程可以抽象为：候选池-过滤池=预下线池>下线池。如下图所示：

1. 首先根据以上几种类型，计算出满足下线基本条件的“候选池”。
2. 满足某些条件的数据，不应该被下线，进入“过滤池”。除了无产出表长期执行失败任务外，其他类型都需要通过过滤池筛选一下。过滤池的数据有以下情况：
   1. 表作为其他任务的依赖
   2. 表对应的任务作为其他任务的依赖
   3. 近90天有临时使用。说明有在分析场景被使用。
   4. 表对应的任务产出多张表。此时不应该有多张表的情况，决定任务是否可下线。
   5. 创建时间小于30天。比如某任务近期才创建，可能项目开发中，失败是正常情况。
3. 候选池剔除过滤池，得到“预下线池”
4. 在“预下线池”一定时间后，进入“下线池”

以上过程，涉及到很多“阈值”，比如多久算长期、预下线池连续多久后进入下线池等，可以根据实际的业务情况制定。

为了保证整个链路的稳定性和准确性，我们对血缘、审计日志、下线池数据量等进行监控。任意一个指标出现异常，将中断整个下线链路。

现阶段主要的中断指标包含以下几个：

1. 审计日志解析成功率低于99%
2. 某些情况的血缘缺失超过1%
3. 无配置依赖任务占比大于1%
4. 无产出表任务占比大于1%
5. 下线表数量每天减少量或增加量超过1000

5.3 自动下线

对自动化下线，我们分析有以下需求：

1. 下线预知
   1. 用户可以查询资产状态（访问频率等），可以查看待下线列表
2. 下线感知
   1. 哪些数据，因为什么原因，将在什么时候被下线
   2. 提供链接去查看明细，做一些操作
   3. 自动下线前N天，通知到用户
   4. 自动下线当天，通知用户和管理员操作结果，并提供链接去查看明细
   5. 支持已下线列表查询
3. 下线决策
   1. 支持白名单，以防止特殊场景的数据或者任务被清理
   2. 支持下线回滚操作（限定时间内）
4. 运维能力
   1. 下线异常，人工干预
   2. 下线进展、状态监控
   3. 支持人工下线、回滚操作

结合以上需求，设计下线流程：

1. 获取待下线表，判断是否在白名单里。如果在的话，直接记录下线执行结果。否则进行下一步判断；
2. 判断owner是否有效（离职情况，这种要离线表处理好，或者说治理好）。如果无效，直接记录下线执行结果，否则进行下一步判断；
3. 判断该表的状态，决定是否提前通知即将下线（5、3、1天）。
   1. 如果还没达到通知次数，继续通知，然后更新下线执行结果
   2. 如果达到了，执行下线操作。下线成功的话，通知其owner；下线失败的话，通知管理员
   3. 存储下线执行结果

对于预告和执行结果的通知，我们会根据owner合并，避免过多的消息干扰用户判断。

除此之外，为了尽量降低用户判断成本和运维精力，每日自动下线的数量也做了一定控制。

配套下线流程，也有回滚流程，逻辑比较简单，这里不展开介绍了。

5.4 防护措施

由于各种原因，可能存在误下线的情况。为了避免影响业务，我们也做了一些防护措施：

1. 设定下线缓冲期。下线表备份一定时间，过期后再清理。期间如果发现异常，支持快速回滚；
2. 数据准确性监控。对血缘覆盖率、SQL解析成功率等指标进行监控，发现异常阻断下线流程；
3. 支持自动化下线开关，并可以设置下线数据的owner范围，在该范围内充分试用后再逐步推广。

六、后期规划

1. 采集更丰富的血缘和使用信息，扩大Hive表待下线池子。比如某个Hive表虽然被导出到ES（意味着有下游），但是该ES索引已经弃用，那么对应的Hive表和导出任务均可下线；
2. 探索自动化下线在实时计算领域的可行性，针对Kafka、ES、HBase等数据资产，提供有效的下线建议；
3. 自动化下线功能推行到其他环境中，现阶段我们主要在主战环境下进行，例如金融云环境有相同的诉求。