数据降本利器：无用数据下线自动化
点击关注“有赞coder”
获取更多技术干货哦～
部门：数据中台
一、前言
有赞在数据成本治理方面，做了很多探索和实践。感兴趣的可以关注历史文章：
关于数据成本与治理：《从量化到优化，详解有赞离线数据降本之路》
关于成本账单&运营：《数据成本知多少？全域账单解烦恼》
降本的领域很多，今天的内容，我们主要聚焦在“离线数据和任务”的成本优化。
二、背景
当前，成本观念已经深入人心，有很多小伙伴主动参与到日常降本的工作当中，节省了大量成本。
不过成本治理不是一锤子买卖，新阶段，我们面临着新问题，
那就是：成本治理的ROI低下。什么意思呢？展开说说。
在降本的初期，治理方很自然地会先“抓典型”。
挑成本大户重点缩减、优化，可以立竿见影，快速见效。集中处理，可能在一天半天内，省下上万成本，ROI极高。此时，业务方的积极性也很高，不用多说，自觉主动。
但到了中后期，“巨头”们都被消灭了，留下的都是零零散散的小数据、小任务。如果人工去判断和处理，需要投入大量的精力，ROI很低。可谓食之无味，弃之可惜。
虽然每个任务占用资源都不多，但是数量庞大，整体的成本不低。如何高效地优化，便是我们要解决的问题。
其他公司或许面临同样的问题，希望本文内容对大家有所帮助。
三、现状
基于上面的背景，我们意识到：不计成本的成本治理，是在耍流氓，自动化下线，势在必行。当然，在开展这项工作之初，我们还是很严谨地分析了现状、问题，并且评估了预期的收益。
当前我们已经将每个数据、任务的成本量化，并且做了初级的使用情况分析，提供了下线建议。比如：无下游任务、过去n天未被使用、任务长期失败等。
但是真实的下线动作，还是需要每个owner去触发。
这里边有两个不便利的点：
下线建议的参考数据准确率低。需要业务方根据经验去判断和确认，比较费时并且风险高；
无法批量操作。成百上千的琐碎数据，我们自己也不好意思推动业务关注。
对下线的判断是否准确，依赖几个关键点：
数据owner归属准确性（谁负责），有人负责，才能放心对其操作，出现异常及时补救；
数据血缘完备性（数据由谁产出，又被哪个任务使用），目前我们的研发平台支持SQL，数据导入导出、脚本等类型的任务，每个任务使用或者产出了什么数据，都需要被解析；
数据行为日志的完整性（表什么时候被谁使用了），所有的数据查询，需要统一收口，并保留审计日志，便于分析使用情况。
解决了准确性问题（比如99%准确率），再结合一些防御策略（比如数据备份等），就可以考虑做自动下线（要支持快速定位问题&恢复），提升降本的效率。
那么可自动下线数据（后边我们称之为：降本池子）成本有多少呢？
我们统计过，根据当前的规则，大概有5000张表和任务可被下线，成本约70万/年。降本池子的余额增速约5%，年增速约为70%。综合看，自动化降本的收益约为120万/年。
如果按平均1张表需要1小时的投入算，需要2人年的人力投入，ROI确实不高。但是如果实现自动化，剔除一次性的投入之外，收益可观。
四、方案设计
整体的方案如下图所示：
为方便说明，先简单介绍下图里涉及的系统：
数据研发平台（下文简称DP），一站式大数据管理与应用开发平台
数据资产平台（下文简称Meta），数据资产管理、治理平台
BI系统，有赞自研的可视化数据分析系统
RDS，有赞自研的数据库服务平台
图中橘黄色为自动化下线系统的后端和前端。
其中后端负责实际的下线、运维动作，定时执行。主要能力是：
读取RDS里待下线资产信息（该信息在离线加工后，通过DataX导入RDS），根据规则做通知、下线等操作，并记录过程和结果；
执行下线逻辑，需要和Hive、DP对接，以实现数据的删除、恢复，还有任务的暂停和重启；
下线逻辑必要的配置，在Apollo里；
通过飞书发送下线预告、结果信息；
BI系统，用于分析待下线数据、下线进展、状态等；
提供用户交互操作接口。
为了实现自动化下线，我们需要知道每个数据的流转过程和使用情况，然后制定合理的规则挖掘待下线数据，再配合一定的流程去做实际的下线动作。这个过程，可以抽象出三个重要环节：数据准备、下线挖掘、自动下线，下面我们分别介绍。
5.1 数据准备
在数据准备方面，我们会去采集到数据、任务的状态、血缘关系、使用情况等信息。并保证较高的的准确率，才能安全地做自动下线。
主要工作：
从各个系统（Hive、Hbase、DP、BI等）采集完备的元数据信息，并做好准确的owner归属；
根据SQL、任务配置、实体关系等，解析血缘关系，确保较高的血缘覆盖率；
采集审计日志，解析每个行为用到的数据（所有离线数据都统一收口了），并保证准确率；
采集加工DP任务依赖、BI看板使用情况。
最终在Hive里，有DP任务依赖、数据和任务血缘、元数据信息、数据使用记录、看板使用情况这几份数据，供下一步加工分析。
5.2 下线挖掘
哪些数据可以下线呢？这就是下线挖掘要做的事情。根据依赖、血缘、使用记录等数据，分析出无用的数据和任务。
根据我们的经验，归纳出以下几种情况：
长期执行失败任务：这类任务不产出准确数据，一直在浪费计算资源，可以被暂停。根据任务的调度频率，判定标准有所差异：
季级任务从6个月前的1号开始调度天数全部失败，且调度次数大于等于2次
月级任务从3个月前的1号开始调度天数全部失败，且调度次数大于等于3次
周级任务从6周前的周一开始调度天数全部失败，且调度次数大于等于6次
天级任务从15天前开始调度天数全部失败，且调度次数大于等于15次
小时级任务从3天前开始调度天数全部失败，且调度次数大于等于72次
无任务无下游表：这类数据既找不到对应的产出任务，也没有被其他任务使用。
有任务无下游表：这类数据有对应的产出任务，也在定期更新，但是没有下游使用。
有下游，但是下游长期无访问 ：比如某个数据的下游是BI看板，虽然被引用了，但是看板长期无访问，也可以理解为该数据无用。
下线挖掘的过程可以抽象为：候选池-过滤池=预下线池>下线池。如下图所示：
首先根据以上几种类型，计算出满足下线基本条件的“候选池”。
满足某些条件的数据，不应该被下线，进入“过滤池”。除了无产出表长期执行失败任务外，其他类型都需要通过过滤池筛选一下。过滤池的数据有以下情况：
表作为其他任务的依赖
表对应的任务作为其他任务的依赖
近90天有临时使用。说明有在分析场景被使用。
表对应的任务产出多张表。此时不应该有多张表的情况，决定任务是否可下线。
创建时间小于30天。比如某任务近期才创建，可能项目开发中，失败是正常情况。
候选池剔除过滤池，得到“预下线池”
在“预下线池”一定时间后，进入“下线池”
以上过程，涉及到很多“阈值”，比如多久算长期、预下线池连续多久后进入下线池等，可以根据实际的业务情况制定。
为了保证整个链路的稳定性和准确性，我们对血缘、审计日志、下线池数据量等进行监控。任意一个指标出现异常，将中断整个下线链路。
现阶段主要的中断指标包含以下几个：
审计日志解析成功率低于99%
某些情况的血缘缺失超过1%
无配置依赖任务占比大于1%
无产出表任务占比大于1%
下线表数量每天减少量或增加量超过1000
5.3 自动下线
对自动化下线，我们分析有以下需求：
下线预知
用户可以查询资产状态（访问频率等），可以查看待下线列表
下线感知
哪些数据，因为什么原因，将在什么时候被下线
提供链接去查看明细，做一些操作
自动下线前N天，通知到用户
自动下线当天，通知用户和管理员操作结果，并提供链接去查看明细
支持已下线列表查询
下线决策
支持白名单，以防止特殊场景的数据或者任务被清理
支持下线回滚操作（限定时间内）
运维能力
下线异常，人工干预
下线进展、状态监控
支持人工下线、回滚操作
结合以上需求，设计下线流程：
获取待下线表，判断是否在白名单里。如果在的话，直接记录下线执行结果。否则进行下一步判断；
判断owner是否有效（离职情况，这种要离线表处理好，或者说治理好）。如果无效，直接记录下线执行结果，否则进行下一步判断；
判断该表的状态，决定是否提前通知即将下线（5、3、1天）。
如果还没达到通知次数，继续通知，然后更新下线执行结果
如果达到了，执行下线操作。下线成功的话，通知其owner；下线失败的话，通知管理员
存储下线执行结果
对于预告和执行结果的通知，我们会根据owner合并，避免过多的消息干扰用户判断。
除此之外，为了尽量降低用户判断成本和运维精力，每日自动下线的数量也做了一定控制。
配套下线流程，也有回滚流程，逻辑比较简单，这里不展开介绍了。
5.4 防护措施
由于各种原因，可能存在误下线的情况。为了避免影响业务，我们也做了一些防护措施：
设定下线缓冲期。下线表备份一定时间，过期后再清理。期间如果发现异常，支持快速回滚；
数据准确性监控。对血缘覆盖率、SQL解析成功率等指标进行监控，发现异常阻断下线流程；
支持自动化下线开关，并可以设置下线数据的owner范围，在该范围内充分试用后再逐步推广。
六、后期规划
采集更丰富的血缘和使用信息，扩大Hive表待下线池子。比如某个Hive表虽然被导出到ES（意味着有下游），但是该ES索引已经弃用，那么对应的Hive表和导出任务均可下线；
探索自动化下线在实时计算领域的可行性，针对Kafka、ES、HBase等数据资产，提供有效的下线建议；
自动化下线功能推行到其他环境中，现阶段我们主要在主战环境下进行，例如金融云环境有相同的诉求。
文末彩蛋
数据开发工程师请戳👇
了解更多职位请戳👇