在当今的数据驱动时代，数据作为关键生产要素之一，其在商业活动中的战略价值愈加凸显，京东也不例外。

作为国内领先的电商平台，京东在数据基础设施上的投入极为巨大，涵盖数万台服务器、数 EB 级存储、数百万个数据模型及数以百万计的任务执行。每年成本上的投入高达两位数个小目标，而且还在持续增长，成本压力比较大。

面对这样的成本压力，治理是一个必然的选择，并且不能是运动式、救火式的，而应该是持续的，需要一个规模化、常态化的治理体系。为了实现这一目标，就要应对治理中的诸多挑战。首先，场景复杂，平台建设是个长期过程，管控规则在不断迭代，历史原因导致平台有部分作业的访问方式跳过数据表直接访问底层 HDFS 文件，或者绕过平台的推数工具，直接在 MapReduce 或 Spark 里面写入数据，导致审计和血缘追踪困难，给治理带来了很大风险。此外，平台用户较多，成本意识很难拉齐，且大家工作繁忙，主动治理的意愿较低。而且人工治理不仅成本高，风险也高，如果人工判断不准，就会造成生产事故。

为了解决这些问题，我们首先设计了健康分和货币化账单，用来量化治理的收益，帮助用户直观感受治理的变化。再就是打造自动化治理平台，自动发现问题，及时通知用户，一键执行，并通过量化指标来判断收益，提高治理人效。

具体治理从以下几个角度一起考虑：

当前整个治理系统已经涵盖了成本、稳定性、安全、质量等四个方向一共几十个治理项。例如成本治理中表的生命周期，不仅仅按照人工设定时间定期删除数据，还可以根据数据实际被访问的周期推荐更合理的生命周期数值。在稳定性中的“依赖缺失”治理，防止任务执行时，上游数据还未产出，导致任务失败。在安全方面，平台能及时发现对安全等级打标不准，质量方向的元数据缺失，元数据标注不准以及数据质量异常等治理项，及时发现，及时处理。

接下来介绍一下治理平台使用的关键技术。

审计日志记录了用户在何时何地因何原因访问了哪些数据及访问方式，这是安全治理的基础。

以无效任务为例（有产出，但是产出的数据没有下游访问），自身作业还在运行，一定有日志产生，那如何来判断有没有下游呢，就需要排除掉自身任务的访问，审计当中就必须要有“任务 ID”这个属性。另外，治理需要明确的责任人，单单靠大家主动去维护表的负责人，一定会存在错漏的问题，所以审计一定要能识别到具体哪个人在操作，再加上数据的反算策略，来补充和校准负责人信息，确保数据一定有人负责。

原生的大数据系统，并没有这么丰富的信息，所以需要定制化改造：

首先介绍一下图中的一些术语，JDQ：是京东基于 kafka 进行二开的消息队列；JRC：京东实时数据加工平台，主要是用的 FLink 技术；DTS：数据集成工具；Plumber in、out：数据的导入导出。

上图展示的是正常的数据流转过程。从生产到数仓，再到数据应用或服务的全过程来看，已经不单单在大数据平台，要进行数据治理，如果不能掌握上下游关系，很容易出现问题。比如数仓将数据推到了应用系统，后续访问都在大数据平台外，如果把表的加工任务当成无效任务禁用后，就会影响业务正常运行。

除治理外，还可以利用血缘对全链路进行影响分析，链路优化等（比如一个表在任务加工链路上属于第 10 层，而他所依赖的所有数据都在第 3 层，那中间的几层依赖即为无效的，直接依赖第 3 层的加工任务来缩短链路，就可以更快完成数据加工）。

在不同阶段会用到不同的技术，比如生产侧主要用到的是调用链，在大数据侧主要使用审计和执行计划的解析，在数据应用与服务侧主要是运用审计的能力。将各阶段的数据进行整合，就可以得到全链路的血缘。

血缘的粒度如果只到表一级，还是存在一些局限性，在分析的时候，影响容易被放大。比如下游的表仅仅使用上游表做关联查询条件，他的结果当中就不会保存上游表的数据内容，在前面提到的影响分析场景，就应该排除掉。要做到这一点，就需要实现算子级血缘。

算子级血缘描述的是字段间存在的具体关系，比如是直接引用的原字段，还是做了加减乘除等转换，是结果存储还是仅作为关联条件，为精细化数据治理提供支撑。比如相似表计算和重复存储识别就需要算子级血缘来帮助判断。我们的算子血缘实现的方案集成在了逻辑执行计划优化的阶段，和优化之后的 Hive Hook 的方式相比，可以拿到更原汁原味的血缘关系，对用户来说更容易理解。下面就是利用血缘关系，进行主动元数据治理的一个案例。

用户开发时，经常要去找依赖的数据在哪里，有的是直接找表，而更多的时候是找字段，比如我想要知道订单优惠后的金额在哪，他的加工口径是什么，这样单纯的按表来检索就非常低效。所以我们设计了标准字段的概念，他是字段的抽象，在标准字段上可以维护更多的元数据信息，比如加工口径，使用说明等。当标准字段和表的实体字段关联上之后，就可以通过它来寻找字段和表。

但是如果需要大家一个个的维护关联关系，也是个巨大的成本，在这里就可以通过算子血缘来进行提效，用户仅需要将字段的源头做好关联，那么根据算子血缘关系，就可以直接算出有哪些直接引用的下游。

当然，我们这个标准字段也不仅仅是用于找数的提效，在字段元数据上维护好枚举值、取值范围、格式规范等信息，我们在后台会自动检测真实数据是否和定义匹配，异常及时触达用户，让用户做治理。这个检测不需要提前配置，完全是系统自动行为。

前面介绍的内容更多是如何推动业务主动治理，其目的主要是“节流”，减少不必要的占用。另一方面，我们也在寻求“开源”的手段，在不增加成本的情况下，使资源得到更充分的利用。这里主要列举三种手段：资源混部、任务错峰，以及跨机房的任务编排。

京东有两大消耗大户，分别是大数据和在线服务，基数大，而且资源缺口也大。拿在线服务来说，在双十一、618 等促销节点，资源非常紧缺。而离线是常年高负荷运行，利用率都达百分之七八十。当在线服务在大促峰值过后，需求就会降得很低，就可以借给离线使用。离线虽然常年是高负载的情况，但每天晚上八点后相对比较空，在大促时就可以进行在线的支援。因此资源混部的价值是很大的。

资源池化，可以根据业务特点和等级进行资源分配，进行统一调度。此外也可以进行按需分配，当大促时，离线只需要借用几个小时不会对整体造成影响，离线可借用的空间就会很大。

资源池化落地有几个关键点。

前面讲的是空间的挪移，而任务错峰则是时间上的挪移。平台上跑的上百万的作业，涉及很多开发人员，靠人工设定的运行规则，不是很合理。从数据表现来看，在凌晨 3-5 点集中了 30% 的任务，导致资源抢占和高峰拥堵。还有就是父任务的结束时间和当前任务的开始时间存在大量的 gap，如果父任务结束之后的空档期，资源负载较低的话，可以把任务做提前的编排，不光可以提高资源的利用率，也可以提升运行的时效。对整个过程中每个队列的资源使用情况，以及任务的运行时长进行预测，并根据这个预测结果结合任务的重要度来去动态调整任务的可执行时间，即可实现削峰填谷。

第三个手段就是跨机房的任务搬迁。对于大公司来说，单个机房很难完全满足需求，因为很少有机房能放数十万台服务器。另外也很难做到高可用，从安全角度来讲，一般是要做到两地三中心的架构，不同机房间的系统负载就很难相同，一定有的机房相对繁忙，另外一边相对空闲。如果能对任务进行动态调整，把任务尽量分在空闲的一边，就一定能跑得更快。这里比前面两个手段要多出一项对存储的考量，因为计算和存储是跨机房的访问，势必就会带来两机房之间专线的额外占用。如果调度不当，就会导致专线堵塞。而且跨机房的存储调拨，也会带来一些更高的存储需求。这个过程需要平衡存储和计算的成本。

以上三个方面如果能够做到极致，利用率就会接近一条直线，仅在均线上下小幅波动，采购就会大幅减少，甚至零采购，从而降低成本。

未来的治理将在以下几个方向继续推进：