风控特征中心数据质量建设的思考

本文来自12月份对于风控的数据质量建设的一些思考和规划。由于业务战略的变化调整，不再继续建设，也无法通过实践来验证。不过，一些大数据指标方面的质量保障建设体系思考，我觉得还是有价值的，算是抛砖引玉了。

一、背景

在风控整体架构体系中，主要涉及平台能力和特征数据。平台能力，主要关注，规则引擎、处置审核等，风控策略运营都是基于这些平台能力来对所有风险事件进行决策、拦截、处罚、事后追偿等，是风控对外的能力提现。而对于特征数据，则是需要给能力平台的各个关键节点提供数据支撑，如果数据质量出现问题，则同样会影响整个风控最终结果的质量。

对于平台能力的质量测试，和业务测试无差别，因此，其有着丰富的理论经验和实践工具支撑。但是，和能力平台测试不同，关于数据指标的测试，首先存在实践经验的不丰富，之前的测试主要重点在于业务流程测试，对于大数据的测试理论和实践比较缺失；其次，大数据理论本身发展也非常快，同时大数据体系也比较新，每个公司、每个业务对于大数据的建设都存在多少的不一致，进而影响外部分享的数据质量测试方法在风控数据内部的落地；再次，大数据的指标测试由于数据大，可能涉及的依赖数据表较多，并且大多数表都来自各个业务方，需要从上到下去构造数据测试，成本非常大，得不偿失；最后，也是最重要的，风控特征中心是业务中的大数据，其对于大数据的指标生产和使用场景的特殊性，决定了数据质量建设的复杂性。

随着，风控业务的不断发展，对数据指标的需求也不断增多，指标的重要性也不断凸显。在长期对数据指标生产的测试迭代，运行过程中的问题发现和解决，的进程中，会有各种各样基于各个点的思考、梳理和经验产出，但是，还是缺少一些体系化的方法论总结，使得，始终无法总览数据质量治理全局。

因此，本文期望可以对于数据质量的测试和建设，进行体系化的去思考梳理，能够产出一个包含全链路的数据质量治理方法论。

二、数据质量定义

当我们将如何做数据质量建设之前，我们需要首先明确什么是数据质量。

所谓质量，在ISO8402中对于质量的定义：反映实体满足明确或隐含需要能力的特性总和。那么数据质量，就是在定义中的实体，这里特指为数据。

那么，一个指标数据需要具备的能力特性，具备哪些？最基础的: 及时性、完整性、准确性。对数据测试的系统性思考：“做好大数据测试，我是认真的！”

2.1 数据质量之基础特性

2.1.1 数据及时性

所谓数据及时性，就是数据要按时产出，或者说在预期时间内产出。不管是实时指标，还是离线指标，都存在时效性，错过了指标的预定时效，则可能会直接影响业务，或者数据本身已经没有意义。

2.1.2 数据完整性

数据完整性，就是最终产出的数据，不能少，也不能多。和数据及时性不同，数据完整性关注的是数据的记录是否足够，每条数据的信息是否完整；而，数据及时性，更多是关注某个指标是否任务执行完成，对于任务产出的数据条数是否是满足的数量，并不care。

因此，我们对数据及时性，关注在数据产生的任务上；数据的完整性，在产出指标数据的表上。

2.1.3 数据准确性

数据准确性，顾名思义，就是数据值是正确的，其主要包括，正常的业务逻辑下的计算结果正确性，还包括当数据异常或者缺失情况下，执行结果也是符合预期的。

数据准确性的测试，是最简单，也是最难的。简单是因为，理论上我们根据输入数据可以推算出正确的结果，然后去匹配比较，就可以发现任务执行的是否准备；困难是因为，输入数据的量太大，对所有正常和异常情形下的输入样本数据进行枚举测试，难度太大，基本上无法落地。

2.2 数据质量之高级特性

在基础特性中，主要关注数据本身的质量。高级特性，主要关注数据整体质量的建设。

在特征中心中，存在大量的不同指标数据，这些指标从时效性、应用场景、降级策略等维度看，都存在的不同，在有限的资源里，这些不同维度，同样会影响数据质量。

因此，我们梳理出数据质量的高级特性：数据的易用性；数据的可靠性；数据的可维护性。

2.2.1 数据易用性

数据易用性，作为数据质量的一个特性，是因为数据本身是作为一个产品，要被使用。此外，指标的定义如果不容易清晰理解，那么在使用的时候，可能由于理解不正确，导致被错误添加到规则引擎的具体策略中，最终影响业务。

因此，数据易用性，主要关注，指标数据容易被使用，被理解。使用和理解，对于特征中心而言，主要在对外暴露的产品上。

2.2.2 数据可靠性

数据可靠性，主要针对的是异常场景下，如何去保证数据的稳定性输出。比如，上游某个任务产出比较晚的情况下，如何最小化特征中心受影响的指标范围；再比如，执行指标产出的某个任务出现非预期故障，如何做好对应指标的降级策略等。

数据可靠性，主要是在数据稳定性方面的质量保证。

2.2.3 数据可维护性

特征中心，本身作为一个系统，就需要考虑新数据指标需求如何去快速支持。业务系统的质量建设，需要关注系统的可扩展，架构的灵活性，针对数据系统，同样需要具备这些特性。

数据的可维护性，主要是数据生产前的设计阶段，需要有清晰灵活的架构设计和模型设计。比如，数据模型分层设计，新指标的可视化配置，等，提升数据生产效率和数据复用。

2.3 总结

从数据质量的定义出发，梳理数据质量包括的一些特性，除了基础的数据本身的功能准确性之外，对于一个完整的数据系统，还需要关注全体指标的整体性质量建设。因此，我们从数据系统作为一个系统本身而言，应该具备的质量特性出发，介绍了数据易用性，可靠性和可维护性 三个质量特征。

下面，我们从数据生命周期出现，立足以上的质量特性，思考特征中心数据质量的建设。

三、特征中心数据质量建设

单独去介绍以上数据质量特性，以及对应的实施手段，这种描述方式并不是很体系化。因此，和业务风险脉络主线类似，我们对数据按照生命周期来分阶段讲述对应手段。

对于业务风险，或者业务稳定性建设，主要分为三个阶段，因此我们对于数据质量建设，也梳理出对应的三个阶段：事前指标测试，事中质量监控，事后故障恢复。

下面，主要从这三个阶段来总结数据质量建设全链路的治理手段。

3.1 事前指标测试

在指标上线服务之前，我们需要对于数据指标进行设计，开发和测试。而这些节点，都多多少少涉及到数据质量的相关特征，因此，都需要去重点思考和执行相关动作。

3.1.1 指标设计&开发节点

指标设计和开发节点，参与者都是开发同学，而且，由于最终目标都是按照需求生产出指定口径的指标数据，因此，这里放在一起讨论。

指标设计和开发的主要流程是，先去调研之前的指标表是否存在相同或者相似的指标；如果需要生产，选择历史DP任务或者新建DP任务，按照指标口径开发SQL，构建基础原子指标（可能数仓协助开发，自己开发则需要进行Code Review）；配置新指标相关属性和口径描述等，选择虚拟任务，测试指标数据；开发完成。

针对上面的主要流程，按照数据治理的特征，可以总结出来，在设计和开发节点，我们可以针对 数据准确性，数据易用性，数据可靠性，数据可维护性。

3.1.1.1 数据准确性

指标开发过程中，最核心的最基础的，就是准确性。在设计和开发节点，准确性可以通过自测和Code Review来保证。

关于Code Review。
SQL 的 Code Review ，主要是看选择的原始数据表是否合理，sql语句是否符合指标口径，原始表字段的计量单位是否需要额外处理，数据计算的时候异常值是否考虑；等。需要特别说明：SQL的Code Review，按目前设计不应该很多，大部分需要写SQL的指标都是DWS/DWA的指标，这些应该交给数仓同学开发。通过配置生成的SQL，稳定的功能可以不需要review，对于配置生成的sql语句有优化疑问的，应该去改进特征中心配置功能。

关于自测。
由于测试环境的数据存在各种缺失和错误，导致开发自测需要在生产环境进行，这同时也对自测有了更多的约束。其次，大数据的最大特点就是数据量大，开发在自测的时候，需要考虑怎样去选择测试样本来完成正确性测试，不可能去看所有最终指标数据，也不应该去跑所有指标数据来浪费资源和成本，并且效率也低。
因此，关于自测，我们需要关注两个点，自测基于指标维度来选择样本，减少资源使用和时间消耗；自测产出数据和真实数据表进行隔离，避免错误影响线上业务。

对于自测样本，建立基于测试维度的各个维度样本库。样本选择，需要考虑，数据值范围正确、数据值类型丰富、数据量均衡等。
对于自测环境隔离，对于数据测试阶段，使用最终产出的测试标，在配置后生成的sql目标表为xxx_test，最终写入测试独立的hbase表。

对于自测方法。有了自测样本和自测环境之后，可以直接执行开发的sql脚本，看最终产出指标数据。根据不同指标，可以采用去业务后台看业务统计数据和指标数据进行对比；也可以通过查看原始ods表，针对样本，写一个简单sql看指标数据是否符合预期；或者都很难的情况下，通过正确有效数值范围来评估指标是否合理。等等。

3.1.1.2 数据易用性

数据易用性，在设计和开发的过程中，主要体现在前期针对需求的技术设计阶段，能否通过可视化来决定哪些指标需要加工，需要修改调整；开发过程中通过配置的方式，如何选择/修改到最佳的任务级别；在开发完成之后，如何查询某个指标是否存在问题。等等。

因此，数据易用性，在设计开发阶段，体现为，指标评估和配置。

关于指标评估。
对于指标评估，其实是指标开发前很重要的一个过程。首先需要知道，指标是否已经生产，当前存在的指标是否和需求口径一致；其次，对于存在的指标，需要评估当前的指标产出时间是否满足需求？指标出现问题后，对应的降级策略是否满足新业务需求？同时，如果评估需要调整时，需要知道哪些业务使用了该指标，评估修改后的影响是否可控？

基于以上，为了易用性，我们需要可视化的获取指标信息，模糊查询，清晰的加工口径和加工配置。此外，还需要知道该指标通用的降级策略，以及指标对应任务的属性：优先级、任务完成时间趋势，任务监控告警策略等。此外，我们还需要通过目标指标，上钻获取上层使用业务策略。

关于指标配置
对于指标配置，主要是根据需求和评估，之前不存在对应口径指标，则需要配置新增。由于指标任务的质量建设，需要考虑对应指标生产归属到哪个虚拟任务上，最终使用什么级别的DP任务来执行？此外，指标的降级策略如何抉择？这些需要通过最简单的方式来支持配置，列出DP任务信息，可选降级策略信息等。

此外，指标配置最重要的一块，是生成执行的hive sql。目前的配置和生成都比较复杂，很多单表操作，一些异常值判断等，都缺失，需要人肉修改sql，需要逐步优化生成算法。

基于以上，为了易用性，我们需要优化算法、异常兼容考虑、单表操作规避join等。侧重于能力上的优化，来提升性能以及sql的稳健性，最终提升sql执行质量。

3.1.1.3 数据可靠性

数据可靠性，在设计和开发过程中去考虑，在事中监控和事后恢复中被使用。这里，具体说聊数据可靠性需要开发做哪些事情？后面阶段，侧重于发现和执行。

数据可靠性，开发关注的，应该是异常情况下的合理策略来最小化影响。在设计和开发节点，我们需要考虑指标有哪些异常场景？异常场景下，对应的处理方案有哪些？如果异常场景下，需要人参与，则如何快速评估影响，处理异常？

因此，数据可靠性，在设计开发阶段，体现为，指标异常梳理和异常预案制定。

指标异常梳理
对于指标异常场景，大部分指标其实都是相似的。比如，任务在预定时间内，没有执行完成，导致指标没有产出，怎么处理（挂在任务上统一处理？？）？指标在线查询，大量异常数据（例如空数据、非预期数据值），怎么处理？等等。

我们发现，绝大部分指标的异常场景，是可以枚举的。这就意味着，完全可以在指标生产配置的时候，列出异常场景项，指标开发者，根据这些异常场景来决定可靠性方案。

异常预案制定
对于异常预案，其对应的是异常场景。我们发现数据指标异常后，自动或者手动来执行对应预案。对于简单的异常场景，也就是我们可以系统化归因的异常，基本上可以系统自动化执行预案；但是，对于一些异常场景，没办法简单归因的，需要人工分析，然后执行预案。

比如，异常数据场景，首先我们不知道什么情况才能说是大量异常数据？大量是一个模糊的词语，系统无法正确量化判断；其次，背后的原因是因为数据源有问题，还是任务sql有问题，或者系统代码的问题，等等无法归因，因此，也就无法自动执行预案。但是，如果我们人工分析之后，可以按照约定，执行预案。

因此，基于以上，我们可以在指标生产的时候，通过给出的枚举异常场景，给出具体的预案，并标记为自动化，或者 手动执行。此外，我们需要支持根据业务场景，来支持不同的自动化预案。比如，指标没有及时产出，业务A可以使用昨天的数据；任务B则需要报错，或者不提供数据返回等。

3.1.1.4 数据可维护性

数据可维护性，和业务可维护性一样，需要在设计和开发阶段考虑，从而让后续其他需求得以复用公共底层模型指标，最终提升效率。

在指标建设中，主要是数据建模。指标设计和开发过程中，通过特征中心配置化来生成指标，如果不能配置完成，需要考虑是否应该在DWS/DWA相关模型表中建立几个原子指标，然后通过新建立的指标来配置生产最终的业务衍生DM指标。

这里，主要通过对设计阶段的方案进行review，或者对于所有通过sql完成的指标加工，进行强制增加原因和严格code review。此外，hive sql 去生产原子指标的任务，尽量交给数仓的同学完成。

3.1.2 指标测试节点

指标测试节点，主要是测试同学执行。目前，测试节点使用的测试手段，和开发阶段的自测手段基本一致，这里不单独说明。

3.1.3 指标上线运行节点

在指标测试完成之后，就可以执行上线，发布到生产环境。

我们先来看看一个离线指标，在运行过程中的流程：依赖DP任务执行 –> 指标DP任务执行 –> 任务执行完成，数据回写hbase表 –> 特征中心查询hbase新数据。需要说明的是，DP任务的执行需要使用大量资源，因此任务优先级会影响任务的执行时间，也就是指标的及时性。此外，数据回写hbase的过程，也很影响最终指标的及时性。

因此，在指标上线运行节点，针对质量特征而言，我们主要侧重于数据及时性。

在上线运行节点，影响数据及时性，主要是两个方面，一个是任务本身的效率，一个是任务优先级。

3.1.3.1 数据及时性-任务执行效率

特征中心存在大量的指标，这些指标依赖的任务完成时间不同，指标的优先级不同，指标使用的表不同，导致最终指标的完成时间不可预测。或者说，单独优化指标本身的sql，很多时候，并没有提前指标加工完成时间。因此，优化任务及时性，就需要对指标任务进行治理。

梳理一下指标执行的流程，可以发现影响指标效率的，主要是：依赖表完成时间，写在线hbase表时间。任务本身的效率，这里暂不考虑（在设计review和开发code review时，应该考虑）。

输入依赖表影响
指标的生产都是依赖原子指标，或者详情数据源，如果这些数据产出完了，就会影响整个任务的产出，最终影响指标的生产时间。由于，我们没法决定上游数据源的最终完成时间，那么，我们就需要做到不同指标依赖的隔离，降低最小影响。

指标，是任务执行后的产物，在DP平台，最小执行单元是任务，因此，我们需要整理任务内的指标，来做到指标影响的隔离。

例如，指标A和指标B，都在任务T中，任务T自身执行需要1个小时。指标A依赖上游任务U1的指标X；指标B依赖上游任务U2的指标Y。那么，假设任务U1 早上8点完成，任务U2早上10点完成；则，任务T需要在早上10才能开始执行，产出指标A和B的时候，都是11点。如果，我们将指标A和指标B分拆到不同的任务，假设执行时间也都是1小时，则产出指标A的时间是9点，指标B的时候是11点。

因此，我们需要按照数据源，对不同的指标归属到哪个任务，进行细粒度管理。

划分的方式有很多，这里简单的原则，就是按照相同数据源进行组合，划分到同一个虚拟任务组，然后根据虚拟任务组依赖的表特性，将一些虚拟任务，划到具体的DP任务中。

以上，肯定有其他更优方式，可以一起讨论深究其他更优任务分配策略。比如，过多的虚拟任务划到同一个DP任务，则会导致DP任务自身执行时间过长，可以话说对这个DP任务横向拆分优化等。

输出hbase影响
大量数据写hbase，也会带来大的性能损耗。同样，我们可以针对hbase进行拆表处理，降低单表并发写表压力，提升最终指标产出效率。

回写hbase，需要按照DP任务来设置hbase。DP任务对应哪个hbase表对于任务完成写数据没有影响，但是，对于特征中心查询指标时，会有影响，因为查询需要路由到具体的表名。这就意味着，我们的指标特征中，需要维护虚拟任务 – DP任务 – hbase表 关系。

3.1.3.2 数据及时性-任务优先级

在划分DP任务的时候，还有一个因子需要考虑，那就是执行生产的DP任务优先级。不同的优先级DP任务，在资源竞争的情况下，分配资源的数量，时机都是不同的。

因此，在考虑指标分配给哪个DP任务执行时，需要考虑指标本身对于完成时间的要求。

因此，在上文的任务分配策略里面，还需要考虑指标的优先级，指标的优先级依赖使用指标的业务，所以最终需要根据优化的优先级，去选择对应优先级的DP任务。

3.1.3.3 数据及时性-总结

任务及时性，重点在于任务的执行效率，以及指标的合理分配。

在执行过程中，需要关注指标的业务诉求，以及指标加工依赖的任务情况，来进行合理的虚拟任务选择/创建，最终选择相对适合的DP任务。

3.2 事中质量监控

在指标测试完成之后，就可以执行上线，发布到生产环境。接下来，质量治理环节，就走到了事中监控监控领域。

事中监控，主要关注指标的健康度，以及执行指标的DP任务健康度。所谓质量监控，就是对数据质量的基础特征进行监控。数据质量的高级特性，本质上是用来保证数据的基础特性。而，事中监控，是用来及时发现线上数据质量的基础特性是否出现异常，及时进行恢复和降级操作。

3.2.1 数据及时性监控

数据及时性监控，主要是对数据的最小执行单元，任务进行监控。
目前的保障策略是依赖于dp平台的监控告警，若数据未产出，则会有企微、电话等告警形式，通知到相应的人员。

3.2.2 数据完整性监控

目前只能根据表来做完整性监控，完整性主要关注数据的多少。同比，环比比较，看数据是否符合预期数据量变更趋势。如果hive表数据都是同纬度下的相同过滤规则，则基于表和基于指标，达到的预期是一致的。

3.2.3 数据准确性监控

最后，我们看数据准确性监控。准确性，是指标数据的准确，所以监控纬度在指标上，也就是表的字段上。

3.3 事后故障恢复

对于监控发现的问题，有些仅仅是预警作用，需要关注；有些就是故障预警，需要采取对应预案。因此，首先我们需要梳理出，有哪些故障，然后是研究应该使用什么预案来及时止损。

3.3.1 故障/异常枚举

在前面设计开发节点介绍数据可靠性的时候，对数据异常情况简单的介绍。由于，我们是基于监控发现问题，然后去做故障恢复；而监控的侧重点，在数据准确性，完整性和及时性。

那么，故障的类型，按照监控分类，就是准确性故障、完整性故障、及时性故障。

3.3.1.1 故障归因分析

故障看到的很多时候，只是对外的表现。我们需要对故障/异常进行细分，找到最终根因，这个过程就是故障归因分析。

有个异常/故障的发生根因之后，才可以针对根因去恢复故障，解决异常。不过，对于故障过程中，如果对根因进行分析后，发现需要较长的时间才能恢复，这个时候就需要根据指标应用的业务场景诉求进行降级。

总结一下，我们首先需要针对故障的外在表现，进行下钻找到发送问题的根因，然后继续修复；同时对故障影响的任务/指标进行上钻，根据业务，进行降级和其他相应处理。

3.3.1.2 准确性故障

针对准确性故障，一般通过数据平台监控后的表现，就是数据范围不满足，数据唯一性不满足，数据可枚举出现问题，空值趋势不符合预期等。

一般这种情况的原因两种：1，外部依赖数据源存在问题；2，业务数据出现调整，hive sql处理异常，出现一些逻辑的漏洞。

准确性异常问题，需要人工去check具体问题点，此外，因为涉及到外部数据源或者业务的正确性确认，在故障的根因分析上的耗时，是比较不确定的。

3.3.1.3 完整性故障

针对完整性故障，一般通过数据平台监控后的表现，就是数据量的趋势，不满足预期变化区间。

一般出现这种情况的原因三种：1，外部依赖数据源存在问题；2，业务数据出现调整，hive sql处理异常，出现一些逻辑的漏洞；3，业务战略或者市场调整。

和准确性故障根因一样。不过针对第2点，可能是由于业务方对一些计算的过滤字段进行了调整，导致最终计算数据量出现大的偏差。

针对第3点，很多时候会忽略，比如针对某平台的商品被逐步全面下架，导致该平台维度下的指标数据量出现大幅度的调整，同时也会导致其他比例指标出现大的调整，这些都需要去考虑。其实，这种case，在准确性上也是一个根因。

3.3.1.4 及时性故障

针对及时性故障，出现的概率最大，一般都是在设置的预期截止时间内任务都没有执行完成，从而导致数据最终产出及时性。

及时性故障，最大的原因，就是上游依赖任务执行时间延迟太久，甚至在截止时间到达前都没有执行完成；其次，任务优先级设置不合理，在资源紧张的时候，没有足够资源执行指标生产任务，最终导致执行时间超过预期。

此外，任务本身的执行时间，在突发的大数据量情况下，本身的执行时间超过预期，导致及时性受损，不过这种case一般很少出现，首先，我们的计算逻辑比较简单；其次，我们一般会预留足够的时间给任务，截止时间的预警一般不太会触发的到。

3.3.2 故障预案

这里关于故障预案，而不是故障恢复。

对于大数据任务，尤其是针对特征中心产出的这种DM层指标数据，出现故障的根因，基本上都是依赖的数据出现问题，资源不够，或者业务数据出现调整，这些点的定位、修复、重跑，都是非常消耗时间，所以故障恢复是一个长时间的过程。

因此，我们需要针对这些case，做故障降级预案。通过降级，来避免影响在线实时业务。

分析故障根因，使用下钻；对于故障预案，则需要针对数据指标进行上钻。

故障预案，最大的目标，是最小化业务损失。业务对于指标数据都是通过查询请求，而查询的数据返回对于接口而言，一种是异常报错；一种是降级历史数据。

3.3.2.1 数据异常处理

数据异常处理，就是直接返回错误信息给到业务方，业务方根据错误信息，停止一些业务处理。因此，这里可以在特征中心，对数据正确性故障、完整性故障、及时性故障分别有自己的错误码，根据错误码觉得具体的执行策略。

比如，及时性故障的时候，数据产出存在出现问题，这个时候，业务根据具体错误码，暂停业务后续业务执行，等待故障恢复。

3.3.2.2 降级历史数据

降级历史数据，在风控业务里面，比较常见，毕竟对于一个用户/商家的好坏预测，使用非最新鲜数据，影响相对较少，可以接收。

降级历史数据，有一个点需要注意，由于一些涉及比例计算，如果分子和分母不是使用同一批次数据，则计算可能出现非预期。因此，最简单的方式，就是比例变量也作为一个指标，由特征中心来计算。

四、特征中心数据质量能力建设

针对上面总结的数据质量建设，我们需要抽象出特征中心针对质量治理，需要建设的能力。

4.1 指标地图

指标地图。
指标地图，包括指标的基础信息，口径信息，维度，时间周期等；指标使用情况，哪些业务在使用这个指标，也就是指标上钻；指标加工依赖，这个指标在哪个任务执行调度，任务优先级，指标依赖的表等，也就是指标下钻。

和当前特征中心指标信息相比，我们需要额外建立特征/指标的上钻，业务展示；下钻，DP任务。

4.2 指标任务管理

为了支持上面的指标地图，需要对指标任务进行管理，最终按照指标的特点和使用场景，分配合理的任务执行。

指标管理，主要体现的是，指标和虚拟任务和实体DP任务的分配关系展示。

4.3 异常预案管理

异常预案，对于特征中心而言，就是根据业务属性，使用不同的返回，降级或者异常。默认，使用降级，如果有特殊需求可以通过配置异常返回。

对于异常，为了方便后续业务可能需要人肉手动去执行一些预案。因此，这些自定义的预案，可以通过接口触发的方式，或者简单些，通过文本描述预案处理方案。

五、总结

当前针对经常出现的问题，对于指标地图的上钻下钻诉求，其实是非常紧迫的。通过上钻下钻，可以通过DP任务，以及数据平台的数据地图，可以快速发现哪些指标收到影响，最后查看哪些业务收到影响。

通过上下钻，可以快速评估异常/故障影响面，指定对应的异常/故障预案，减少故障损失，控制影响面。

此外，当前对于指标生产过程中的任务管理，基本上是混乱的，没有具体的规则和规范，比较随意。对于下游依赖的任务和表出现问题之后，会导致整体影响面不好控制。比如一些本不受故障表影响的指标，由于绑定到某个任务上，导致必须等待故障表执行完成之后，才能随着大的dp任务执行完成而可用。

因此，对于质量治理能力建设，优先建设指标地图上下钻能力；其次，预案进行规整，对当前不能使用默认降级数据的事件，前期制定文档预案，后期系统化。最后，再进行任务的管理和统一分配策略和规范。