大数据之路读书笔记-15数据质量

大数据之路读书笔记-15数据质量

随着 IT向DT 时代的转变，数据的重要性不言而喻，数据的应用也日趋繁茂，数据正扮演着一个极其重要的角色。而对于被日益重视的数据，如何保障其质量也是间里巴巴乃至业界都普遍关注的一个话题。本章将介绍阿里巴巴如何保障数据仓库的数据质量。

数据质量是数据分析结论有效性和准确性的基础，也是这一切的前提。如何保障数据质量，确保数据可用性是阿里巴巴数据仓库建设不容忽视的环节。接下来将通过数据质量原则逐一展开介绍阿里巴巴对数据仓库数据质量建设的方法。

---

15.1 数据质量保障原则

如何评估数据质量的好坏，业界有不同的标准，而阿里巴巴对数据仓库主要从四个方面进行评估，即完整性、准确性、一致性和及时性，如图 15.1 所示。

1.完整性
完整性是指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。比如交易中每天支付订单数都在 100 万笔左右，如果某天支付订单数突然下降到1万笔，那么很可能就是记录缺失了。对于记录中某个字段信息的缺失，比如订单的商品 ID 、卖家 ID 都是必然存在的，这些字段的空值个数肯定是0，一旦大于0就必然违背了完整性约束。

2. 准确性
准确性是指数据中记录的信息和数据是否准确，是否 在异常或者错误的信息。比如一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息 ，这些必然都是有问题的如何确保记录的准确性，也是保障数据质量必不可少的一个原则
3. 一致性
一致性一般体现在跨度很大的数据仓库体系中，比如阿里巴巴数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性。例如用户 ID ，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致。所以，在建设阿里巴巴数据仓库时，才有了公共层的加工，以确保数据的一致性。
4.及时性
在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。一般决策支持分析师都希望当天就能够看到前一天的数据，而不是等五天才能看到某一个数据分析结果 ：否则就已经失去了数据及时性的价值，分析工作变得毫无意义。现在对时间要求更高了，越来越多的应用都希望数据是小时级别或者实时级别的。比如阿里巴巴“双11”的交易大屏数据，就做到了秒级，及时性同样是保障数据质量的一个重要原则。

15.2 数据质量方法概述

在间里巴巴数据仓库建设过程中，经过不断的实践，慢慢摸索出一套适合大数据的数据质量方法，在满足以上四个原则的基础上，为阿里巴巴数据做基础保障。

阿里巴巴业务复杂，种类繁多的产品每天产生数以亿计的数据，每天的数据量都在 PB 级以上，而数据消费端的应用又层出不穷，各类数据产品如雨后春笋般出现。为了不断满足这些数据应用的需要，数据仓库的规模在不断膨胀，同时数据质量的保障也越来越复杂。基于这些背景，我们提出了一套数据质量建设方法，如图15.2 所示。

这套方法主要包括如下几个方面。
1.消费场景知晓
消费场景知晓部分主要通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题。根据应用的影响程度 确定资产等级；根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同所采取的不同处理方式。

2.数据生产加工各个环节卡点校验
数据生产加工各个环节卡点校验部分主要包括在线系统和离线统数据生产加工各个环节的卡点校验。其中在线系统指 OLTP (On-Line Transaction rocessi ，联机事务处理）系统；离线系统指 OLAP(On-LineAnalytical Processing ，联机分析处理）系统。

在线系统生产加工各环节卡点校验主要包括两个方面 ：根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；对于高资产等级的业务， 当出现新业务数据时，是否纳入统计中，需要卡点审批。

离线系统生产加工各环节卡点校验主要包括代码开发、测试、发布和历史或错误数据回刷等环节的卡点校验，针对数据资产等级的不同，对校验的要求有所不同。

3.风险点监控
风险点监控部分主要是针对在数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两个方面。在线数据的风险点监控主要是针对在线系统日常运行产出的数据进行业务规则的校验 ，以保证数据质量，其主要使用实时业务检测平台 BCP (Biz Check Platform ）； 离线数据的风险点监控主要是针对离线系统日常运行产出的数据进行数据质量监控和时效性监控，其中数据质量监控主要使用 DQC 时效性监控主要使用摩萨德。

4. 质量衡量
对质量的衡量既有事前的衡量，如 DQC 覆盖率；又有事后的衡量，主要用于跟进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生。根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前和事后的衡量数据进行打分。

5.质量配套工具
针对数据质量的各个方面，都有相关的工具进行保证，以提高效能。接下来将对数据质量保障的各个方面进行介绍。

15.2.1 消费场景知晓

在数据快速增长的情况下，数据类产品和日常决策支持系统也应运而生，且层出不穷，而对于数据不断增加的需求，数据仓库已经应接不暇，数据研发工程师已经难以确认几百 PB 的数据到底是否都是重要的，是否都要进行保障 是否有一些数据已经过期了，是否所有需要都要精确地进行质量保障，上述数据质量保障的四个原则是否还适用于所有的数据……这些疑问伴随着每一个数据开发人员。数据规模的膨胀考验数据质量的原则，同时也是对数据加工的考验。基于不断膨胀的数据和对数据类的应用，阿里巴巴内部提出了数据资产等级的方案，旨在解决消费场景知晓的问题。

1 .数据资产等级定义
什么是数据资产等级？针对阿里巴巴庞大的数据仓库，数据的规模已经达到EB级别，对于这么大的数据量，如果一概而论势必会造成精力无法集中、保障无法精确，因此给数据划分等级势在必行。经过不断地地讨论和研究，最终将数据分为五个等级，即毁灭性质、全局性质、局部性质、一般性质和未知性质，不同性质的重要性依次降低，具体定义如下。

● 毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关风险。
● 全局性质，即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等。
● 局部性质，即数据直接或间接用于内部一般数据产品或者运营／产品报告，如果出现问题会给事业部或业务线造成影响，或者造
成工作效率损失。
● 一般性质，即数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者带来的影响极小。
● 未知性质，不能明确说出数据的应用场景，则标注为未知。
对于不同的数据资产等级使用英文 Asset 进行标记，毁灭性质标记为A1等级，全局性质标记为 A2 等级，局部性质标记为 A3 等级，一般性质标记为A4等级，未知性质则标记为 Ax 等级。在重要程度上，A A2>A3>A4>Ax 。另外，如果一份数据出现在多个应用场景中，则遵循就高原则。

2. 数据资产等级落地方法
前面已经给出了数据资产等级的定义，但是对于如此庞大的数据量， 如何给每一份数据都打上一个等级标签呢？这里首先介绍数据的简单流转过程。
数据是从业务系统中产生的，经过同步工具进入数据仓库系统中在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现的，其流转过程如图 15.3所示。
同步到数据仓库（对应到阿里巴巴就是 MaxCompute 平台）中的都是业务数据库的原始表，这些表主要用于承载业务需求，往往不能直接用在数据产品中，在数据产品中使用的都是经过数据仓库加工后的产出表。

有了数据产品或者数据应用的概念，同时也知道了哪些表是为哪个数据产品或者用服务的，就可以借助强大的元数据知道整个数据仓库中的哪些表服务于这个数据产品，因此通过给不同的数据产品或者应用划分数据资产等级，再依托元数据的上下游血缘，就可以将整个消费链路打上某一类数据资产的标签 ，这样就可以将数以亿计的数据进行分类了。关于元数据的加工计算详见第 12 章“元数据”。

这里以阿里巴巴生意参谋产品（见“数据应用篇 ”介绍）为例，简单介绍数据资产等级打标的过程。生意参谋是一款为商家提供服务的数据类产品，完全依托数据，为商家进行决策支持。 它每天零点开始同步，计算前一天的数据，8:00 给到商家，提供服务。产品每一个页面的每一个模块基本上都是通过数据表输出展现的，不同模块数据的重要等级也就决定了相关表的重要等级，决定了这个导出表的重要等级。比如生意参谋为 A2 等级的业务，那么对应这个导出表的资产等级就是 A2 ，所有加工这个表的上游链路上的所有表都将会打上 A2 资产等级的标签，同时会标注为生意参谋产品使用。如图 15.4 所示，生意参谋打上了 A2的标记 直接服务于生意参谋的表 Tabl el Table2 Table3 进行 A2-生意参谋标记，根据血缘上溯，这 个表的上游都将打上 A2 的标记，一直标记到前台业务系统，将血缘贯通。
通过如上步骤，就完成了数据资产等级的确认，给不同的数据定义了不同的重要程度，当然这里是需要元数据支撑的。

解决了消费场景知晓的问题，就知道了数据的重要等级，针对不同的等级也将采取不同的保障措施。接下来将介绍阿里巴巴在数据仓库中针对不同资产等级的数据的保障方法。

15.2.2 数据加工过程卡点校验

1 .在线系统卡点校验
在线系统数据加工过程卡点校验，主要是指在在线业务系统的数据生成过程中进行的卡点校验。阿里巴巴OLTP 系统比较丰富，也比较复杂， 比如交易、会员、商品、营销、评价、 退款、客服等，这些服务于用户购物的在线业务系统，既满足了用户日常需求，也是数据仓库的数据来源，因此既要保障数据的准确性 ，同时也要保障和离线数据的致性。

关于对数据准确性的保障 ，主要以数据监控为主，在 15 2.3 节“风险点监控”中进行介绍。本节主要介绍在线数据和离线数据一致性的保障问题。

在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，阿里巴巴在使用数据仓库的不断摸索中总结出两个行之有效的方法：工具和人员双管齐下。既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。

工具，首先是发布平台。在业务进行重大变更时，订阅这个发布过程，然后给到离线开发人员，使其知晓此次变更的内容。业务系统繁杂，日常发布变更数不胜数，如果每一次变更都要知会离线业务，那势必会造成不必要的浪费 ，同时会影响在线业务迭代的效率。因此这里充分发挥了数据资产等级的作用，针对全集团重要的高等级数据资产，整理出哪些变更会影响数据的加工。比如财报，这个自然是 Al 等级的资产，如果业务系统的改造会影响财报的计算，如约定好的计算口径被业务系统发布变更修改了 ，那么务必要告知离线业务，作为离线开发人员也必须主动关注这类发布变更信息。所以发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布。

其次是数据库表的变化感知。无论是随着业务发展而做的数据库扩容还是表的 DDL 变化，都需要主动通知到离线开发人员。数据仓库在进行数据抽取时，采用的是 DataX 工具，可能限制了某个数据库表，如果发生数据库扩容或者迁移， DataX 工具是感知不到的，结果可能就会导致数据抽取错漏，影响一系列的下游应用。对此，阿里巴巴是通过数据库平台进行库表变更通知发送的。

有了好的工具的辅助，而操作工具的开发人员更是核心。数据资产等级的上下游打通，同样也要将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用要提高在线开发人员的意识，通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端。

阿里巴巴的数据仓库通过这种机制，在很大程度上保障了第一手数据的准确性。但是业务、技术都在不断快速地发展着，我们也在不断地摸索更高效、更准确的在线业务保障方案，为在线数据质量保驾护航。
2.离线系统卡点校验
前文己有介绍，数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加过程中的质量，是离线数据仓库保障数据质量的一个重要环节。

首先是代码提交时的卡点校验。数据研发人员素质不同，代码能力也有差异，代码质量也就难以得到高效保障。在此背景下，我们上线了代码扫描工具SQLSCAN，针对每一次提交上线的代码进行扫描，将风险点提示出来。具体规则已经在第4章“离线数据开发”中进行了介绍。

其次是任务发布上线时的卡点校验。为了保障线上数据的准确性，每一次变更都需要线下完成测试后再发布到线上环境中，线上测试通过后才算发布成功。发布上线前的测试主要包括 Co Review 和回归测试，对于资产等级较高的任务变更发布，则采取强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布。回归测试一方面要保证新逻辑的正确：另一方面要保证不影响非此次变更的逻辑。发布上线后可以在线上做 DryRun 测试或真实环境运行测试，其中 DryRun 测试，不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；实环境的运行测试，则使用真实数据进行测试。

最后是节点变更或数据重刷前的变更通知。一般建议使用通知中心的将变更原因、变更逻辑、变更测试报告和变更时间等自动通知下游，下游对此次变更没有异议后 ，再按照约定时间执行发布变更，将变更对下游的影响降至最低。

15 2.3 风险点监控

风险点监控主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制，主要包括在线数据和离线数据运行风险点监控。
1. 在线数据风险点监控
在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。阿里巴巴主要采用实时业务检测平台 BCP ，用于保障在线系统的数据质量。

BCP 针对数据库表的记录进行规则校验。在每一个业务系统中，当完成业务过程进行数据落库时， BCP 同时订阅 份相同的数据，在 BCP系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来给到规则订阅人，以完成数据的校对。所以，采用 BCP 进行校验的过程是，首先，用户在 BCP 平台进行数据源订阅，以获取需要校验的数据源：然后 ，针对所订阅的数据源进行规则的编写，即校验的逻辑，这些规则是至关重要的，也是校验的核心，只要这些规则通过了，即认为这条记录是对的 ：最后，配置告警，针对不同的规则配置不同的告警形式。有了这样一套流程，就能够在第一时间发现脏数据并通知到订阅人，既减少了用户数据错误的投诉，也减少了离线数据错误的回滚。 BCP 在很大程度上减少了脏数据，为数据的准确性把了第一道关。

比如交易系统配置的一些监控规则，如订单拍下时间、订单完结时间、订单支付金额、订单状态流转等都配置了校验规则。订单拍下时间肯定不会大于当天时间，也不会小于淘宝创立时间，一旦出现异常的订单创建时间，就会立刻报警，同时报警给到多人。通过这种机制，可以及时发现并解决问题。 BCP 的配置和运行成本较高主要根据数据资产等级进行监控。
2. 离线数据风险点监控
离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。
(1 ）数据准确性
数据准确性是数据质量的关键，因此数据准确成为数据质量的重中之重，是所有离线系统加工时的第一保障要素。阿里巴巴主要使用 DQC来保障数据的准确性，其具体功能说明和规则配置可以参考第4章“离线数据开发”中的内容。
DQC 查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能，因此还是依赖数据资产等级来确定规则的配置情况。比如 Al、A2 类数据监控率要达到 90%以上，规则类型需要三种及以上，而不重要的数据资产则不强制要求。

类似的规则都是由离线开发人员进行配置来确保数据准确性的。当然不同的业务还是会有业务规则的约束，这些规则来源于数据产品或者说消费的业务需求，由消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化。
(2 ）数据及时’性
在确保数据准确性的前提下，需要进一步让数据能够及时地提供服否则数据的价值将大幅度降低，甚至没有价值，所以确保数据及时性也是保障数据质量重中之重的一环。

对于阿里巴巴大部分离线任务，一般是以天作为时间间隔的 。对于天任务，数据产品或者管理层决策报表一般都要求在每天 9:00 至更早的时间产出。为确保前一天的数据完整，天任务是从零点开始运行的由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，则需要进行一系列的报警和优先级设置，使得重要的任务优先且正确产出。这里的重要性即前面所述的数据资产等级，资产等级高的业务必定优先保障。

①任务优先级。如何确保重要任务获得高优先级，是调度平台需要重点考虑的问题。如前文所述，调度是一个树形结构，当配置了叶子节点的优先级后，这个优先级会传递到所有上游节点，所以优先级的设置都是给到叶子节点，而叶子节点往往就是服务业务的消费节点。因此在优先级的设置上，首先是确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出。

①任务报警。任务报警和优先级类似，也是通过叶子节点传递。任务在运行过程中难免会出错，因此要确保任务能够高效、平稳地执行，需要一个监控报警系统，对于高优先级的任务，一旦发现任务出错或者可能出现产出延迟，就要报警给到任务和业务 Owner。阿里巴巴使用自主开发的监控报警系统一一摩萨德来监控任务的实时运行状况，若发现异常则执行不同等级的报警 ，根据不同的资产等级执行强保障或弱保障。高资产等级的业务才会获得强保障 ，任务出错或可能延迟则执行电话报警 般业务只会做到短信或者邮件告警。

③摩萨德。摩萨德是离线任务的监控报警系统，它会根据离线任务的运行情况实时决策是否告警、 何时告警、告警方式、告警给谁等。摩萨德经过几年的发展，目前已经比较成熟，是数据运维不可或缺的保障工具。摩萨德提供了两个最主要的功能：强保障监控和自定义告警。

强保障监控是摩萨德的核心功能，也是紧紧围绕运维目标即业务保障而设计的，只要在业务的预警时间受到威胁，摩萨德就一定会告警出来给到相关人员。强保障监控主要包括

● 监控范围一一设置了强保障业务的任务及其上游所有的任务都会被监控。
● 监控的异常一一任务出错、任务变慢、预警业务延迟。
● 告警对象一一默认是任务 Owner ，也可以设置值班表到某一个人。
● 何时告警一一根据业务设置的预警时间判断何时告警。
● 告警方式一一根据任务的重要紧急程度，支持电话、短信、旺旺、邮件告警。

比如生意参谋业务，定义的数据资产等级是 A2 ，要求早上 9:00产出数据给到商家，因此我们给生意参谋业务定义一个强保障监控，业务产出时间是 9:00 ，业务预警时间是 7:00 。这里的预警时间是指一旦摩萨德监控到当前业务的产出时间超出预警时间时就会打电话给到值班人员进行预警，比如摩萨德推测生意参谋的产出时间要到 7:30 ，那么电话告警就出来了，由值班人员来判断如何加速产出。那么是怎样判断当前执行会超过预警时间的呢？摩萨德是根据当前业务上所有任务最近7天运行的平均时间来推算的，虽然有误判的可能性，但是总体还是非常准的，可以接受。这个是预警判断，也就是产出延迟判断。

另外还有出错报警，当重要业务比如生意参谋产出路径上有个任务运行出错了，此时摩萨德依然会根据预警时间判断要不要马上报警给到值班人员。这里注意，出错报警的时机也是根据产出预警时间来判断的，对于生意参谋而言，夜里一旦任务出错肯定是要立即报警的，因为产出要求早，容不得推迟：而对于不重要的业务即资产等级低的业务或者产出时间要求晚的业务，摩萨德则会根据预警时间来判断合适的报警时间点，比如算法类的业务需求，可能当天产出即可，那么摩萨德会根据预警时间，将出错报警时间推迟到 9:00 以后，即上班了再报警，以减轻值班人员的夜里负担。

除了针对业务的强保障监控，还有自定义监控。自定义监控是摩萨德比较轻量的监控功能，用户可以根据自己的需要进行配置，主要包括：

● 出错告警一一可根据应用、业务、任务三个监控对象进行出错告警配置，监控对象出错即告警给到人／Owner／值班表。
● 完成告警一一可根据应用、业务、任务三个监控对象进行完成情况告警配置，监控对象完成即告警给到 Owner／值班表。
● 未完成告警一一可根据应用、业务、任务三个监控对象进行未完成情况告警配置，监控对象未完成即告警给到人／Owner／值班衰。
● 周期性告警一一针对某个周期的小时任务，如果在某个时间未完成，即告警给到人／Owner 值班表。
● 超时告警一 根据任务运行时长进行超时告警配置，任务运行超过指定时间即告警给到人 Owner／值班表。

有时候是非重要业务的某个任务，但任务 Owner 还是想看一下产出情况，此时就可以设置自定义告警。比如生意参谋业务，因为预警时间都是定在业务上的，如果其中某个表 Owner 希望每天都能监控产出时间，此时就可以自定义一个监控，监控这个任务的产出时间，当然如Owner 认为这个表一定要 2:00 产出，2:00 没有产出则电话告警，也是可以的，灵活性比较大。

另外，摩萨德提供了甘特图的服务，针对业务的运行情况，摩萨德会提供一条关键路径 ，即完成业务的最慢任务链路图。因为每个业务上游可能有成千上万个任务，所以这条关键路径对于业务链路优化来说非常重要。

通过这一系列的报警监控机制，摩萨德能够很好地服务于业务产出，保障业务产出的及时性。

15.2.4 质量衡量

前面章节中已经给出了阿里巴巴对保障数据仓库数据质量的各种方案 ，但是如何评价这些方案的优劣，需要一套度量指标。
1.数据质量起夜率
前文在介绍数据及时性时已经提到，数据产品或者管理层决策日报一般都要求在上午 9:00 之前提供，数据仓库的作业任务都是在凌晨运行的 一旦数据出现问题就需要开发人员起夜进行处理。因此，每个月的起夜次数将是衡量数据质量建设完善度的一个关键指标。如果频繁起夜， 则说明数据质量的建设不够完善，所以在阿里巴巴数据仓库数据质量度量体系里 ，起夜率是一个首先要考虑的指标。

对于数据质量本身，将通过数据质量事件和数据质量故障来衡量。
2.数据质量事件
针对每一个数据质量问题，都记录一个数据质量事件。
数据质量事件，首先，用来跟进数据质量问题的处理过程；其次，用来归纳分析数据质量原因 第三，根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案。
因此，数据质量事件既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指针。
3.数据质量故障体系
对于严重的数据质量事件，将升级为故障。故障，是指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险。比如财报计算错误、卖家结算数据错误、微贷信用数据错误、高管报表错误或者延迟等都将带来恶劣的影响。此类数据质量问题 ，已经不仅仅是一个事件，而是升级为故障。当然，数据质量故障对于开发人员和部门来讲，都是一个重要考核点，因此也是数据质量度量最严的一个指标。

数据从采集到最后的消费，整个链路要经过几十个系统，任何环节出现问题，都会影响数据的产出，因此需要一种机制，能够将各团队绑在一起，目标一致，形成合力，故障体系在这个背景下应运而生。一旦出现故障，就会通过故障体系，要求相关团队第一时间跟进解决问题，消除影响。

( 1) 故障定义
首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误即自动生成故障单，形成故障。

(2 ）故障等级
故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按 p1-p4 定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果。

(3 ）故障处理
故障发生后，需要快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中会尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响。

(4 ）故障 Review
对于故障会进行 Review ，即分析故障的原因、处理过程的复盘、形成后续解决的 Action ，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会到具体的责任人。注意，对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生。