9000字详解阿里数据质量管理方法

这篇文章比较体系化的介绍了阿里的数据质量管理体系，主要从数据资产等级的确定、数据加工环节的控制、数据运行环节的监控再到数据质量的评估四个方面来依次说明：虽然文章的排版比价乱，但读来还是很有启发，特别是其强调数据质量的源头管理，强调SQLSCAN、DQC、摩萨德等工具的使用，强调各个环节的协同配合，都是值得借鉴的。

1、消费场景知晓数据资产等级决定了数据质量的保障等级，阿里给出了数据资产等级确定方法，即根据数据产品和应用的影响程度，给数据产品和应用划分资产等级，并打标处理；然后根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，然后以生意参谋为例进行了说明。

2、数据加工过程卡点校验

在线业务系统的变更如果不及时通知离线仓库，就可能影响数据准确性和一致性，阿里给出了二个策略，第一，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式，告诉在线业务开发人员，使其意识到数据的重要性，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，第二，发送库表变更通知到离线数据仓库。

离线仓库系统为了确保数据开发质量，在加工过程中也给出了三个策略，第一，在代码提交需要通过SQLSCAN进行校验，第二，上线前进行Code Review 和回归测试，第三，在线上做 Dry Run 测试或者真是环境运行测试。

3、数据运行风险点监控针对在线业务系统的监控，主要依托于实时业务检测平台（BCP）配置校验规则来发现业务系统数据的异常。针对离线数仓系统的监控，用摩萨德来进行智能监控报警，确保任务及时生成，同时用DQC（Data Quality Center，数据质量中心）设置数据质量校验规则并进行数据质量方面的监控。文章干货很多，值得仔细读一读。

01数据质量保障原则

如何评估数据质量的好坏，业界有不同的标准，阿里主要从 4 个方面进行评估：完整性、准确性、一致性、及时性；

1、完整性

数据完整性是数据最基础的保障；

完整性：指数据的记录和信息是否完整，是否存在缺失的情况；

数据缺失：主要包括记录的缺失和记录中某个字段信息的缺失；

记录的丢失：如，交易中每天只发订单数都在 100 万笔左右，如果某天支付订单突然下降到 1 万笔，很可能是记录丢失了；

记录中字段的丢失：如，订单的商品 ID、卖家 ID 都是必然存在的，这些字段的空值个数肯定是 0，一旦大于 0 就违背了完整性约束；

2、准确性

准确性：指数据汇总记录的信息和数据是否准确，是否存在异常或者错误的信息；

准确：数据表中记录的信息与业务过程中真实发生的事实要一致；

如何判断是否准确：卡点监控 —— 制定相应规则，根据根校验数据，符合规则的数据则认为是准确的；

如，一笔订单如果出现确认收货金额为负值，或者下单时间在公司成立之前，或者订单没有买家信息等，这些必然是有问题的；

3、一致性

一致性：一般体现在跨度很大的数据仓库体系中，如阿里的数据仓库，内部有很多业务数据仓库分支，对于同一份数据，必须保证一致性；

所以，在阿里建设数据仓库时，才有了公共层的加工，以确保数据的一致性；

一致：也就是指多个业务数据仓库间的公共数据，必须在各个数据仓库中保持一致；

如，用户 ID，从在线业务库加工到数据仓库，再到各个消费节点，必须都是同一种类型，长度也需要保持一致；

4、及时性

及时性：指数据要能及时产出；

主要体现在数据应用上，要及时产出给到需求方；

一般决策支持分析师希望当天就能看到前一天的数据，而不是等三五天才能看到某一个数据分析结果；否则就已失去了数据及时性的价值；

如，阿里 “双 11” 的交易大屏数据，就要做到秒级；

02数据质量方法概述 阿里的数据质量建设体系：

消费场景知晓

根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，以及在各个加工环节上根据资产等级的不同所采取不同的处理方式；

确定数据资产等级：根据应用的影响程度，确定数据资产的等级；

功能：分析解决消费场景知晓的问题；

方法：通过数据资产等级和基于元数据的应用链路，来分析解决消费场景知晓的问题；

过程：

数据生产加工各个环节卡点校验

在线系统生产加工各环节卡点校验：

主要包括：代码开发、测试、发布、历史或错误数据回刷等环节的卡点校验；

代码开发阶段、发布前的测试阶段

针对数据资产等级的不同，对校验的要求有所不同；

离线系统生产加工各环节卡点校验：

主要对两部分的数据卡点校验：在线系统和离线系统数据生产加工各个环节的卡点校验；

在线系统：OLTP（On - Line Transaction Processing，联机事务处理）系统；

离线系统：OLAP（On - Line Analytical Processing，联机分析处理）系统；

根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；

对于高资产等级的业务，当出现新业务数据时，是否纳入统计中，需要卡掉审批；

风险点监控

主要针对在线系统日常运行产出的数据进行业务规则的校验；

主要使用 “实时业务检测平台 BCP（Biz Check Platform）”；

主要是针对离线系统日常运行产出的数据，进行数据质量监控和时效性监控；

DQC：监控数据质量；

摩萨德：监控数据时效性；

风险点监控：主要针对在数据运行过程中可能出现的数据质量和时效等问题进行监控；

主要对两个方面进行风险点监控：

在线数据的风险点监控：

离线数据的风险点监控：

质量衡量

质量分：综合事前和事后的衡量数据进行打分；

对质量的衡量：

事前的衡量：如 DQC 覆盖率；

事后的衡量：

跟进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生；

根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障；

质量配套工具

针对数据质量的各个方面，都有相关的工具进行保证，以提高效能；

2/1）消费场景知晓

消费场景知晓的问题：

数据研发工程师难以确认几百 PB 的数据是否都是重要的？是否都要进行保障？是否有一些数据已经过期了？是否所有需要都要精确的进行质量保障？

解决方案：数据资产等级方案；

产出：

根据数据产品和应用的影响程度，给数据产品和应用划分资产等级，并打标处理；

根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所有涉及数据的资产等级，情打标处理；（等级标签与对应的数据产品 / 应用一致）

数据资产等级定义

如果一份数据出现在多个应用场景中，遵循就高原则；

即，数据一旦出错，将会引起重大资产损失，面临重大受益损失，造成重大公共风险；

即，数据直接或间接用于集团业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等；

即，数据直接或间接用于内部一般数据产品或者运营 / 产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失；

即，数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者影响很小；

不能明确说出数据的应用场景，则标注为未知；

背景：针对阿里庞大的数据仓库，数据的规模已经达到 EB 级，对于这么大的数据量，如果一概而论势必会造成精力无法集中、保障无法精确；

毁灭性质：A1 等级；

全局性质：A2 等级；

局部性质：A3 等级；

一般性质：A4 等级；

未知性质：A5 等级；

毁灭性质

全局性质

局部性质

一般性质

未知性质

五个数据等级，不同性质的重要性一次降低： 对于不同的数据资产等级，使用英文 Asset 进行标记： 重要程度：A1 > A2 > A3 > A4 > A5； 数据资产等级落地方法

数据从业务系统到数据仓库再到数据产品，都是以表的形式体现的，流转过程如下图：

同步到数据仓库（对应到阿里就是 MaxCompute 平台）中的都是业务数据库的原始表，主要用于承载业务需求，往往不能直接用于数据产品；（一般是 ODS 层的全量数据）

在数据产品中使用的都是经过数据仓库加工后的产出表；（根据需求 / 报表进行加工）

链路：指数据从业务系统到数据产品的流转过程；

生意参谋：一款为商家提供服务的数据类产品，完全依托数据，为商家进行决策支持；

如，生意参谋为 A2 等级的业务，那么对应这个导出表的资产等级就是 A2，所有加工这个表的上游链路上的所有表都将会打上 A2 资产等级的标签；同时会标注为生意参谋产品使用；

如下图：

每天零点开始同步，计算前一天的数据，8:00 给到商家，提供服务；

产品的每一个页面的每个一模块基本都是通过数据表输出展现的，不同模块数据的重要等级决定了相关表的重要等级，决定了这个导出表的重要等级；

例，以阿里 “生意参谋” 产品为例，介绍数据资产等级打标过程；

需要解决的问题：对于如此庞大的数据量，如何给每一份数据都打上一个等级标签？

数据资产等级落地的方法 / 步骤：

数据流转过程 划分数据资产等级 实例介绍数据资产等级打标过程

数据从业务系统中产生，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算；

通过同步工具输出到数据产品中进行消费；

根据数据流转过程，建立元数据，记录数据表与数据产品或者应用的对应关系；

根据影响程度，给数据产品和应用划分数据资产等级；

打标：依托元数据的上下游血缘，将整个消费链路打上某一类数据资产标签（也就是对消费链路数据打标）；

生意参谋打上了 A2 的标记；

直接服务于生意参谋的表Table1、Table2、Table3 进行 A2 - 生意参谋标记；

根据血缘上溯，这 3 个表的上游都将打上 A2 的标记，一直标记到前台业务系统，将血缘贯通；

总结：

通过上述步骤，就完成了数据资产等级的确认，给不同的数据定义了不同的重要程度，需要用到元数据的支撑；

2/2）数据加工过程卡点校验

目的：保障数据准确性、保障与离线数据的一致性；

在线业务系统卡点校验（数据产出环节）

工具和人工双管齐下：既要在工具上自动捕捉每一次业务的变化，同时也要求自动进行业务变更通知；

数据资产等级的上下游打通，同样也要将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用；

要提高在线开发人员的意识，通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式，告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端一致；

发布平台：发送重大变更的通知；

数据库平台：发送库表变更通知；

通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；

如，财报，这个自然是 A1 等级的资产，如果业务系统的改造会影响财报的计算，如约定好的计算口径被业务系统发布变更修改了，那么务必要告知离线业务，作为离线开发人员也必须主动关注这类发布变更信息；

注：业务系统繁忙，日常发布变更数不胜数，并不是每一次业务变更都要知会离线业务，那样会造成不必要的浪费，而且影响在线业务迭代的效率；

功能：在业务进行重大变更时，订阅发布过程，然后给到离线开发人员，使其知晓此次变更的内容；

订阅内容：针对全集团重要的高等级数据资产，整理出哪些变化会影响数据的加工，则订阅这些内容；

卡点：发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布；

DDL（(Data Definition Language）：数据库模式定义语言；用于描述数据库中要存储的现实世界实体的语言。

DML（Data Manipulation Language）：数据操纵语言命令；使用户能够查询数据库以及操作已有数据库中的数据。

DDL 数据库模式定义语言是 SQL 语言（结构化查询语言）的组成部分；

例：CREATE DATABASE（创建数据库）、CREATE TABLE（创建表）；

例： insert、delete、update、select  等都是 DML ；

无论是随着业务发展而做的数据库扩容还是表的 DDL 变化，都需要通知到离线开发人员；

背景 / 问题：数据仓库在进行数据抽取时，采用的是 DataX 工具，可能限制了某个数据库表，如果发生数据库扩容或者迁移，DataX 工具是感知不到的，结果可能会导致数据抽取错漏，影响一系列的下游应用；

解决方法：通过数据库平台发送库表变更通知；

在线系统数据加工过程卡点校验，主要指在在线系统的数据生产过程中进行的卡点校验；

目的：保障与离线数据的一致性；

背景 / 问题：在线业务复杂多变，总是在不断变更，每一次变更都会带来数据的变化，因此需要做到两点：

阿里解决上述两个问题的方法： 发布平台 数据库表的变化感知 工具 开发人员

数据仓库需要适应着多变的业务发展，及时做到数据的准确性；

需要高效的将在线业务的变更通知到离线数据仓库；

离线系统卡点校验（数据离线加工环节）

背景 / 原因：数据研发人员素质不同，代码能力也有差异，代码质量难以得到高效保障；

解决方法：开发代码扫描工具 SQLSCAN，针对每一次提交上线的代码进行扫描，将风险点提取出来；

卡点方式：使用代码扫描工具 SQLSCAN，扫描代码提取风险点；

Code Review：是一种通过复查代码提高代码质量的过程；

回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误；

回归测试的目的：

注：对于资产等级较高的任务变更发布，采用强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布；

使用真实数据进行测试；

不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；

为了保障线上数据的准确性，每一次变更都需要线下完成测试后在发布到线上环境中，线上测试通过后才算发布成功；

卡点方式：分别对任务（指变更的业务）发布上线前和上线后进行测试；

使用通知中心，将变更原因、变更逻辑、变更测试报告、变更时间等自动通知下游，下游对此次变更没有异议后，再按照约定时间执行发布变更，将变更对下游的影响降低至最低；

通知内容：变更原因、变更逻辑、变更测试报告、变更时间等；

过程：

背景 / 问题：数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工；正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设；如何保障数据加工过程中的质量，是离线数据仓库保障数据质量的一个重要环节；

目的：保障数据加工过程中的质量（主要指数据的准确性）；

在两个环节进行卡点校验： 代码提交时的卡点校验 任务发布上线时的卡点校验 节点变更或数据重刷新前的变更通知

发布上线前的测试：主要包括 Code Review 和回归测试；

发布上线后的测试：在线上做 Dry Run 测试或者真是环境运行测试；

保障新逻辑的正确；

保证不影响非此次变更的逻辑；

Dry Run 测试：

真实环境的运行测试：

2/3）风险点监控

风险点监控：主要指针对数据在日常运行过程中容易出现的风险进行监控，并设置报警机制；

主要包括在线数据和离线数据运行风险点监控；

目的：保障数据的准确性；

在线数据风险点监控

如，针对 “订单拍下时间” 进行校验；逻辑：订单的拍下时间肯定不会大于当天的时间，也不会小于淘宝创立的时间；

规则 / 逻辑：是至关重要的，是校验的核心，只有通过了这些规则，才认定该条记录是对的；

另外，减少用户错误信息的投诉，也减少了离线数据错误的回滚；

目的：减少了在线业务系统产生的脏数据，为数据准确性把第一道关；

BCP：阿里的实时业务检测平台；

思路 / 监控过程：在每一个业务系统中，当完成业务过程进行数据落库时，BCP 订阅一份相同的数据，根据提前设定好的业务规则，在 BCP 系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来，给到规则订阅人，以完成数据的校对；

BCP 的校验过程：

注：由于 BCP 的配置和运行成本较高，主要根据数据资产等级进行监控；

获取数据源：用户在 BCP 平台订阅数据源，获取需要校验的数据源；

编写规则：针对所订阅的数据源进行规则的编写，即校验的逻辑；

配置告警：针对不同的规则配置不同的告警形式；

离线数据风险点监控

在确保数据准确性的基础上，需要进一步让数据能够及时的提供服务；否则数据的价值将大幅度降低，甚至没有价值；

阿里的大部分离线任务：

摩萨德：离线任务的监控报警系统；是数据运维不可或缺的保障工具；

两个主要功能：强保障监控、自定义告警；

摩萨德甘特图的服务

根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁等；

自定义监控是摩萨德比较轻量级的监控功能，用户可以根据自己的需求进行配置，主要包括：

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

强保障监控主要包括：

例：生意参谋业务（预警业务延迟）

业务延迟预警和出错报警，都是根据 “产出预警时间“ 来判断的；

产出预警时间：摩萨德根据当前业务上所有任务最近 7 天运行的平均时间来推算当前业务所用的大概时间，来作为产出预警时间；

这里的预警时间是指，一旦摩萨德监控到当前业务的产出时间超出预警时间时，就会打电话给值班人员进行预警；

如，摩萨德推测生意参谋的产出时间要到 7:30，那么电话告警就出来了，由值班人员来判断如何加速产出；

产出时间推算（预警判断，也就是产出延迟判断）：摩萨德是根据当前业务上所有任务最近 7 天运行的平均时间来推算的；虽然有误判的可能性，但是总体还是非常准确的，可以接受；

资产等级及需求：定义的资产等级是 A2，要求早上 9:00 产出数据给到上架；

设置：给生意参谋业务定义一个强保障监控，业务产出时间是 9:00，业务预警时间是 7:00；

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

任务报警和优先级类似，也是通过叶子节点传递；

任务在运行过程中难免会出错，因此要确保任务能够高效、平稳的执行，需要有一个监控报警系统，对于高优先级的任务，一旦发现任务出错或者可能出现产出延迟，就要报警给到任务和业务 Owner；

摩萨德：阿里自主开发的监控报警系统；

对于 Map 任务和 Reduce 任务，调度是一个树形结构（RelNode 树），当配置了叶子节点（RelNode 节点）的优先级后，这个优先级会传递到所有上游节点，所以优先级的设置都是给到叶子节点，而叶子节点往往就是服务业务的消费节点；

设置优先级：首先确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出；

重要的任务：资产等级较高的业务；

一般以天为时间间隔，称为 “天任务”，对于天任务，数据产品或者数据决策报表一般都要求在每天 9:00 甚至更早的时间产出；

为了确保前一天的数据完整，天任务是从零点开始运行的，由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，需要进行一系列的报警和优先级设置，使得重要的任务优先且正确的产出；

数据准确性是数据质量的关键，因此数据准确成为数据质量的重中之重，是所有离线系统加工时的第一保障要素；

方法：通过 DQC 进行数据准确性监控；

DQC（Data Quality Center，数据质量中心）：主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控；

DQC 检查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能；因此还是依赖数据资产等级来确定规则的配置情况；

将任务置为失败状态，其下游任务将不会被执行；

常见的 DQC 监控规则：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等；

注：监控数据质量并报警，其本身不对数据产出进行处理，需要报警接收人判断并决定如何处理；

监控方式：通过配置数据质量检验规则，自动在数据处理任务过程中进行监控；

监控规则：

规则配置：依赖数据资产等级确定监控规则；

注：不同的业务会有业务规则的约束，这些规则来源于数据产品或者说消费的业务需求，有消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化；

离线数据风险点监控主要包括对数据准确性和数据产出的及时性进行监控；

出错告警：可根据应用、业务、任务三个监控对象进行出错告警配置，监控对象出错即告警给到人 / Owner / 值班表；

完成告警：可根据应用、业务、任务三个监控对象进行完成情况告警配置，监控对象完成即告警给到人 / Owner / 值班表；

未完成告警：可根据应用、业务、任务三个监控对象进行未完成情况告警配置，监控对象未完成即告警给到人 / Owner / 值班表；

周期性告警：针对某个周期的小时任务，如果在某个时间未完成，即告警给到人 / Owner / 值班表；

超时告警：根据任务运行时长进行超时告警配置，任务运行超过指定时间即告警给到人 / Owner / 值班表；

监控范围：设置强保障业务的任务及其上游所有的任务都会被监控；

监控的异常：任务出错、任务变慢、预警业务延迟；

告警对象：默认是任务 Owner，也可以设置值班表到某一个人；

何时告警：根据业务设置的预警时间判断何时告警；

告警方式：根据业务的重要紧急程度，支持电话、短信、旺旺、邮件告警；

强保障监控 自定义监控 任务优先级 任务报警 摩萨德

强规则：会阻断任务的执行；

弱规则：只告警而不会阻断任务的执行；

数据准确性监控 数据及时性

2/4）质量衡量

保障数据仓库的数据质量，有很多方案，评价这些方案的优劣，需要一套度量指标：

数据质量起夜率

一般数据仓库的作业任务都是在夜晚进行，一旦出现问题就需要值班人员起夜进行处理；

起夜率：用每个月的起夜次数，作为衡量数据质量建设完善度的一个指标；

数据质量事件

针对每一个数据质量问题，都记录一个数据质量事件：

数据质量事件：记录每一次数据质量的问题；

功能：既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指标；

用来跟进数据质量问题的处理过程；

用来归纳分析数据质量原因；

根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案；

数据质量故障体系

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

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

故障发生后，需要快速的识别故障原因，并迅速解决，消除影响；

在处理故障的过程中，会尽量将故障的处理进度通知到相关方，尽可能减少对业务的影响；

故障 Review：即分析故障的原因、处理过程的复盘、形成后续解决的 Action，并且都会以文字的形式详细记录，对故障的责任进行归属，一般会责任到人；

注：对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生；

对于严重的数据质量事件，将升级为故障；

故障：指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险；

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

故障体系中，一旦出现故障，就会通过故障体系，要求相关团队在第一时间跟进解决问题，消除影响；

故障定义

故障等级

故障处理

故障 Review

<END>