摘要
本文系统阐述了数据质量在数据治理中的重要性。随着企业数字化转型，数据成为核心资产，数据质量直接影响业务决策、运营和合规。数据质量问题常见于准确性、一致性、完整性、及时性、唯一性和可解释性方面。这些问题若不重视，将导致决策失误、业务风险和合规问题，因此企业必须重视数据质量管理，以发挥数据的真正价值。
1. 数据质量背景概述
在数据仓库和大数据治理中，“数据质量”是一个基础但至关重要的概念。下面从背景的角度，为你系统说明数据质量为什么重要，以及其在当前数字化浪潮下扮演的角色。
1.1. ✅ 数据质量背景概述
| 维度 | 内容 |
|---|---|
| 技术演进背景 | 随着企业数字化转型的推进，从 IT（信息技术）向 DT（数据技术）过渡，数据逐渐成为核心资产。数据驱动运营、智能决策、精细化管理都依赖于高质量的数据支撑。 |
| 业务诉求提升 | 企业的报表分析、风控策略、用户画像、算法模型等都高度依赖于数据的准确性和一致性。一旦数据存在错误，将直接影响业务判断，甚至引发决策风险。 |
| 数据复杂度提升 | 企业面临多源数据（如 CRM、ERP、交易、行为等）汇聚问题，数据口径不一、标准不一、更新频率不同，数据质量问题易暴露。 |
| 合规与监管要求 | 金融、医疗、电商等行业面临数据合规、审计与数据安全压力，数据质量已成为合规治理中的一环，如金融机构必须确保账实相符。 |
| 行业竞争压力 | 在强调“数据驱动”的竞争环境中，高质量数据成为构建竞争壁垒的关键，数据质量不高意味着难以发挥数据真正价值。 |
1.2. ✅ 数据质量问题常见表现
| 问题类型 | 表现示例 |
|---|---|
| 准确性问题 | 数据错误、值错乱、金额计算不一致等 |
| 一致性问题 | 同一个指标在不同系统或表中口径不一致 |
| 完整性问题 | 关键字段为空、维度缺失、关联关系断裂 |
| 及时性问题 | 数据延迟、批次失败、时效滞后 |
| 唯一性问题 | 主键重复、事实重复、维度去重失败 |
| 可解释性差 | 数据来源不明确、血缘不清、指标口径不透明 |
1.3. ✅ 为什么必须重视数据质量？
| 影响方面 | 影响描述 |
|---|---|
| 影响决策准确性 | 基于错误数据做出的判断可能导致重大经营风险 |
| 影响用户信任 | 下游分析、算法、管理层对数据失去信心 |
| 影响系统稳定性 | 数据质量差可能引发报表异常、数据口径争议、接口失败 |
| 影响数据资产化进程 | 质量不过关的数据无法被归集、复用、共享 |
| 增加运营成本 | 出错后的人工返工、补数、修复、沟通消耗大量人力成本 |
总结一句话：数据质量是数据可用性、可信性、可复用性的根基，没有高质量的数据，所有的数据产品、数据分析、智能算法都将是“空中楼阁”。
2. 数据质量保障原则
在大数据或数据仓库建设中，数据质量保障原则是确保数据可靠、可信和可用的核心准则。以下是常见且被诸如阿里巴巴等大型企业实践验证的数据质量保障原则：
2.1. ✅ 数据质量保障的核心原则汇总表
| 原则名称 | 原则说明 | 目的与价值 |
|---|---|---|
| 1. 准确性原则 | 数据必须真实反映业务事实，不能出现计算错误或人为干预的失真。 | 保证分析结果、报表输出具备决策参考价值。 |
| 2. 一致性原则 | 同一指标在不同系统、不同时间、不同主题下口径必须一致。 | 避免因数据口径不同引发的争议与混乱。 |
| 3. 完整性原则 | 所需的数据字段、记录不能缺失，维度与事实要齐全。 | 确保模型完整、分析维度不缺失。 |
| 4. 唯一性原则 | 数据主键唯一，无重复记录，维度表中同一实体不能重复存在。 | 保证数据合并、汇总、关联时的正确性。 |
| 5. 及时性原则 | 数据在指定时间内完成采集、计算、入库，符合业务时效要求。 | 保障业务实时性、避免决策延迟。 |
| 6. 可追溯性原则（血缘性） | 每条数据可追溯其来源、处理逻辑、变换路径。 | 支撑审计、数据回溯、问题定位。 |
| 7. 可解释性原则 | 数据字段、指标应有清晰含义和定义，能被业务用户理解。 | 降低沟通成本，提升数据可用性。 |
| 8. 稳定性原则 | 同样的逻辑与输入应产生稳定一致的输出结果。 | 防止因程序波动或数据漂移引起误解。 |
| 9. 安全性与合规性原则 | 数据必须遵循权限、安全与行业法规要求（如数据脱敏）。 | 防止泄露风险，保障合规运营。 |
| 10. 可维护性原则 | 数据质量规则、校验逻辑应标准化、可配置、易维护。 | 降低后续维护与修复成本。 |
2.2. 🏢 企业应用示例（如阿里巴巴）
阿里巴巴在数据质量治理中，还强调：
- 构建“质量度量体系”，用指标量化数据质量（如空值率、重复率、校验失败率等）；
- 设立“质量保障平台”，对生产数据进行自动校验、监控、报警；
- 实施“质量责任制”，把数据质量责任落实到具体数据开发或业务负责人。
总结一句话：数据质量保障原则的核心目标是：让每一条数据都“可依赖、可解释、可追溯” ，最终服务于企业的准确分析、可靠决策与高效运营。
3. 数据质量方法
在阿里巴巴数据仓库建设过程中，经过不断的实践，慢慢摸索出一套适合大数据的数据质量方法，在满足以上四个原则的基础上，为阿里巴巴数据做基础保障。
阿里巴巴业务复杂，种类繁多的产品每天产生数以亿计的数据，每天的数据量都在PB级以上，而数据消费端的应用又层出不穷，各类数据产品如雨后春笋般出现。为了不断满足这些数据应用的需要，数据仓库的规模在不断膨胀，同时数据质量的保障也越来越复杂。基于这些背景，我们提出了一套数据质量建设方法，这套方法主要包括如下几个方面。
3.1. 消费场景知晓
消费场景知晓部分主要通过数据资产等级和基于元数据的应用链路分析解决消费场景知晓的问题。根据应用的影响程度，确定资产等级；根据数据链路血缘，将资产等级上推至各数据生产加工的各个环节，确定链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同所采取的不同处理方式。
3.1.1. 数据资产等级定义
什么是数据资产等级？针对阿里巴巴庞大的数据仓库，数据的规模已经达到EB级别，对于这么大的数据量，如果一概而论势必会造成精力无法集中、保障无法精确，因此给数据划分等级势在必行。经过不断地地讨论和研究，最终将数据分为五个等级，即毁灭性质、全局性质、局部性质、一般性质和未知性质，不同性质的重要性依次降低，具体定义如下。
- 毁灭性质，即数据一旦出错，将会引起重大资产损失，面临重大收益损失，造成重大公关风险。
- 全局性质，即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响用户在阿里系网站的行为等。
- 局部性质，即数据直接或间接用于内部一般数据产品或者运营/产品报告，如果出现问题会给事业部或业务线造成影响，或者造成工作效率损失。
- 一般性质，即数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或者带来的影响极小。
- 未知性质，不能明确说出数据的应用场景，则标注为未知。
对于不同的数据资产等级使用英文Asst进行标记，毁灭性质标记为A1等级，全局性质标记为A2等级，局部性质标记为A3等级，一般性质标记为A4等级，未知性质则标记为Ax等级。在重要程度上，A1>A2>A3>A4>Ax。另外，如果一份数据出现在多个应用场景中，则遵循就高原则。
3.1.2. 数据资产等级落地方法
前面已经给出了数据资产等级的定义，但是对于如此庞大的数据量，如何给母一份数据都打上一个等级标签呢？这里首先介绍数据的简单流转过程。
数据是从业务系统中产生的，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现的，其流转过程如图所示。
同步到数据仓库（对应到阿里巴巴就是MaxCompute平台）中的都是业务数据库的原始表，这些表主要用于承载业务需求，往往不能直接用在数据产品中，在数据产品中使用的都是经过数据仓库加工后的产出表。
有了数据产品或者数据应用的概念，同时也知道了哪些表是为哪个数据产品或者应用服务的，就可以借助强大的元数据知道整个数据仓库中的哪些表服务于这个数据产品，因此通过给不同的数据产品或者应用划分数据资产等级，再依托元数据的上下游血缘，就可以将整个消费链路打上某一类数据资产的标签，这样就可以将数以亿计的数据进行分类了。
3.2. 数据生产加工各个环节卡点校验
数据生产加工各个环节卡点校验部分主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。其中在线系统指OLTP(On-LineTransaction Processing,联机事务处理)系统；离线系统指OLAP(On-LineAnalytical Processing,联机分析处理)系统。
在线系统生产加工各环节卡点校验主要包括两个方面：根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；对于高资产等级的业务，当出现新业务数据时，是否纳入统计中，需要卡点审批。
离线系统生产加工各环节卡点校验主要包括代码开发、测试、发布和历史或错误数据回刷等环节的卡点校验，针对数据资产等级的不同，对校验的要求有所不同。
3.2.1. 在线系统卡点校验
在线系统数据加工过程卡点校验，主要是指在在线业务系统的数据生成过程中进行的卡点校验。阿里巴巴的OLTP系统比较丰富，也比较复杂，比如交易、会员、商品、营销、评价、退款、客服等，这些服务于用户购物的在线业务系统，既满足了用户日常需求，也是数据仓库的数据来源，因此既要保障数据的准确性，同时也要保障和离线数据的一致性。
在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。
基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，阿里巴巴在使用数据仓库的不断摸索中总结出两个行之有效的方法：工具和人员双管齐下。既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。
工具，首先是发布平台。在业务进行重大变更时，订阅这个发布过程，然后给到离线开发人员，使其知晓此次变更的内容。业务系统繁杂，日常发布变更数不胜数，如果每一次变更都要知会离线业务，那势必会造成不必要的浪费，同时会影响在线业务迭代的效率。因此这里充分发挥了数据资产等级的作用，针对全集团重要的高等级数据资产，整理出哪些变更会影响数据的加工。比如财报，这个自然是A1等级的资产，如果业务系统的改造会影响财报的计算，如约定好的计算口径被业务系统发布变更修改了，那么务必要告知离线业务，作为离线开发人员也必须主动关注这类发布变更信息。所以发布平台集成了通知功能，针对重要的场景发布会进行卡点，确认通知后才能完成发布。
其次是数据库表的变化感知。无论是随着业务发展而做的数据库扩容还是表的DDL变化，都需要主动通知到离线开发人员。数据仓库在进行数据抽取时，采用的是DataX工具，可能限制了某个数据库表，如果发生数据库扩容或者迁移，DataX工具是感知不到的，结果可能就会导致数据抽取错漏，影响一系列的下游应用。对此，阿里巴巴是通过数据库平台进行库表变更通知发送的。
有了好的工具的辅助，而操作工具的开发人员更是核心。数据资产等级的上下游打通，同样也要将这个过程给到在线开发人员，使其知晓哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用。要提高在线开发人员的意识，通过培训，将离线数据的诉求、离线数据的加工过程、数据产品的应用方式告诉在线业务开发人员，使其意识到数据的重要性，了解数据的价值，同时也告知出错后果，使在线开发人员在完成业务目标时，也要注重数据的目标，做到业务端和数据端一致。
阿里巴巴的数据仓库通过这种机制，在很大程度上保障了第一手数据的准确性。但是业务、技术都在不断快速地发展着，我们也在不断地摸索更高效、更准确的在线业务保障方案，为在线数据质量保驾护航。
3.2.2. 离线系统卡点校验
数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加工过程中的质量，是离线数据仓库保障数据质量的一个重要环节。
首先是代码提交时的卡点校验。数据研发人员素质不同，代码能力也有差异，代码质量也就难以得到高效保障。在此背景下，我们上线了代码扫描工具SQLSCAN,针对每一次提交上线的代码进行扫描，将风险点提示出来。
其次是任务发布上线时的卡点校验。为了保障线上数据的准确性，每一次变更都需要线下完成测试后再发布到线上环境中，线上测试通过后才算发布成功。发布上线前的测试主要包括Code Review和回归测试，对于资产等级较高的任务变更发布，则采取强阻塞的形式，必须通过在彼岸完成回归测试之后才允许发布。回归测试一方面要保证新逻辑的正确；另一方面要保证不影响非此次变更的逻辑。发布上线后可以在线上做Dry Run测试或真实环境运行测试，其中Dry Run测试，不执行代码，仅运行执行计划，避免线上和线下环境不一致导致语法错误；真实环境的运行测试，则使用真实数据进行测试。
最后是节点变更或数据重刷前的变更通知。一般建议使用通知中心的将变更原因、变更逻辑、变更测试报告和变更时间等自动通知下游，下游对此次变更没有异议后，再按照约定时间执行发布变更，将变更对下游的影响降至最低。
3.3. 风险点监控
风险点监控部分主要是针对在数据日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两个方面。在线数据的风险点监控主要是针对在线系统日常运行产出的数据进行业务规则的校验，以保证数据质量，其主要使用实时业务检测平台BCP(Biz Check Platform);离线数据的风险点监控主要是针对离线系统日常运行产出的数据进行数据质量监控和时效性监控，其中数据质量监控主要使用DQC,时效性监控主要使用摩萨德。
3.3.1. 在线数据风险点监控
在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。阿里巴巴主要采用实时业务检测平台BCP，用于保障在线系统的数据质量。
BCP针对数据库表的记录进行规则校验。在每一个业务系统中，当完成业务过程进行数据落库时，BCP同时订阅一份相同的数据，在BCP系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来给到规则订阅人，以完成数据的校对。所以，采用BCP进行校验的过程是，首先，用户在BCP平台进行数据源订阅，以获取需要校验的数据源，然后，针对所订阅的数据源进行规则的编写，即校验的逻辑，这些规则是至关重要的，也是校验的核心，只要这些规则通过了，即认为这条记录是对的；最后，配置告警，针对不同的规则配置不同的告警形式。有了这样一套流程，就能够在第一时间发现脏数据并通知到订阅人，既减少了用户数据错误的投诉，也减少了离线数据错误的回滚。BCP在很大程度上减少了脏数据，为数据的准确性把了第一道关。比如交易系统配置的一些监控规则，如订单拍下时间、订单完结时间、订单支付金额、订单状态流转等都配置了校验规则。订单拍下时间肯定不会大于当天时间，也不会小于淘宝创立时间，一旦出现异常的订单创建时间，就会立刻报警，同时报警给到多人。通过这种机制，可以及时发现并解决问题。BCP的配置和运行成本较高，主要根据数据资产等级进行监控。
3.3.2. 离线数据风险点监控
离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。
- 数据准确性：
数据准确性是数据质量的关键，因此数据准确成为数据质量的重中之重，是所有离线系统加工时的第一保障要素。阿里巴巴主要使用DQC来保障数据的准确性，DQC检查其实也是运行SQL任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能，因此还是依赖数据资产等级来确定规则的配置情况。比如A1、A2类数据监控率要达到90%以上，规则类型需要三种及以上，而不重要的数据资产则不强制要求。类似的规则都是由离线开发人员进行配置来确保数据准确性的。当然不同的业务还是会有业务规则的约束，这些规则来源于数据产品或者说消费的业务需求，由消费节点进行配置，然后上推到离线系统的起点进行监控，做到规则影响最小化。
- 数据及时性
在确保数据准确性的前提下，需要进一步让数据能够及时地提供服务；否则数据的价值将大幅度降低，甚至没有价值，所以确保数据及时性也是保障数据质量重中之重的一环。
对于阿里巴巴大部分离线任务，一般是以天作为时间间隔的。对于天任务，数据产品或者管理层决策报表一般都要求在每天9：00甚至更早的时间产出。为确保前一天的数据完整，天任务是从零点开始运行的。由于计算加工的任务都是在夜里运行的，而要确保每天的数据能够按时产出，则需要进行一系列的报警和优先级设置，使得重要的任务优先且正确产出。这里的重要性即前面所述的数据资产等级，资产等级高的业务必定优先保障。
- 任务优先级。如何确保重要任务获得高优先级，是调度平台需要重点考虑的问题。如前文所述，调度是一个树形结构，当配置了叶子节点的优先级后，这个优先级会传递到所有上游节点，所以优先级的设置都是给到叶子节点，而叶子节点往往就是服务业务的消费节点。因此在优先级的设置上，首先是确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出。
- 任务报警。任务报警和优先级类似，也是通过叶子节点传递。任务在运行过程中难免会出错，因此要确保任务能够高效、平稳地执行，需要有一个监控报警系统，对于高优先级的任务，一旦发现任务出错或者可能出现产出延迟，就要报警给到任务和业务Owner。阿里巴巴使用自主开发的监控报警系统一摩萨德来监控任务的实时运行状况，若发现异常则执行不同等级的报警，根据不同的资产等级执行强保障或弱保障。高资产等级的业务才会获得强保障，任务出错或可能延迟则执行电话报警；一般业务只会做到短信或者邮件告警。
- 摩萨德。摩萨德是离线任务的监控报警系统，它会根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁等。摩萨德经过几年的发展，目前已经比较成熟，是数据运维不可或缺的保障工具。摩萨德提供了两个最主要的功能：强保障监控和自定义告警。
强保障监控是摩萨德的核心功能，也是紧紧围绕运维目标即业务保障而设计的，只要在业务的预警时间受到威胁，摩萨德就一定会告警出来给到相关人员。强保障监控主要包括：
- 监控范围：设置了强保障业务的任务及其上游所有的任务都会被监控
- 监控的异常：一任务出错、任务变慢、预警业务延迟。
- 告警对象：默认是任务Owner,也可以设置值班表到某一个人。
- 何时告警：根据业务设置的预警时间判断何时告警。
- 告警方式一根据任务的重要紧急程度，支持电话、短信、旺旺、邮件告警。
除了针对业务的强保障监控，还有自定义监控。自定义监控是摩萨德比较轻量的监控功能，用户可以根据自己的需要进行配置，主要包括：
- 出错告警：可根据应用、业务、任务三个监控对象进行出错告警配置，监控对象出错即告警给到人/Owner/值班表。
- 完成告警：可根据应用、业务、任务三个监控对象进行完成情况告警配置，监控对象完成即告警给到人/Owner/值班表。
- 未完成告警：可根据应用、业务、任务三个监控对象进行未完成情况告警配置，监控对象未完成即告警给到人/Owner/.值班表。
- 周期性告警：一针对某个周期的小时任务，如果在某个时间未完成，即告警给到人/Owner/值班表。
- 超时告警：根据任务运行时长进行超时告警配置，任务运行超过指定时间即告警给到人/Owner/值班表。
3.4. 质量衡量
对质量的衡量既有事前的衡量，如DQC覆盖率；又有事后的衡量，主要用于跟进质量问题，确定质量问题原因、责任人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生。根据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前和事后的衡量数据进行打分。
3.4.1. 数据质量起夜率
数据产品或者管理层决策日报一般都要求在上午9：00之前提供，数据仓库的作业任务都是在凌晨运行的，一旦数据出现问题就需要开发人员起夜进行处理。因此，每个月的起夜次数将是衡量数据质量建设完善度的一个关键指标。如果频繁起夜，则说明数据质量的建设不够完善，所以在阿里巴巴数据仓库数据质量度量体系里，起夜率是一个首先要考虑的指标。对于数据质量本身，将通过数据质量事件和数据质量故障来衡量。
3.4.2. 数据质量事件
针对每一个数据质量问题，都记录一个数据质量事件。数据质量事件，首先，用来跟进数据质量问题的处理过程；其次，用来归纳分析数据质量原因；第三，根据数据质量原因来查缺补漏，既要找到数据出现问题的原因，也要针对类似问题给出后续预防方案。因此，数据质量事件既用来衡量数据本身的质量，也用来衡量数据链路上下游的质量，是数据质量的一个重要度量指针。
3.4.3. 数据质量故障体系
对于严重的数据质量事件，将升级为故障。故障，是指问题造成的影响比较严重，已经给公司带来资产损失或者公关风险。比如财报计算错误、卖家结算数据错误、微贷信用数据错误、高管报表错误或者延迟等都将带来恶劣的影响。此类数据质量问题，已经不仅仅是一个事件，而是升级为故障。当然，数据质量故障对于开发人员和部门来讲，都是一个重要考核点，因此也是数据质量度量最严的一个指标。
数据从采集到最后的消费，整个链路要经过几十个系统，任何一个环节出现问题，都会影响数据的产出，因此需要一种机制，能够将各团队绑在一起，目标一致，形成合力，故障体系在这个背景下应运而生。一旦出现故障，就会通过故障体系，要求相关团队第一时间跟进解决问题，消除影响。
- 故障定义
首先识别出重要的业务数据，并注册到系统中，填写相关的业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等，完成后，会将这部分数据的任务挂到平台基线上，一旦延迟或错误即自动生成故障单，形成故障。
- 故障等级
故障发生后，会根据一定的标准判断故障等级，如故障时长、客户投诉量、资金损失等，将故障按pl~p4定级，各团队会有故障分的概念，到年底会根据故障分情况来判断本年度的运维效果。
- 故障处理
故障发生后，需要快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中，会尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响。
- 故障Review
对于故障会进行Review,即分析故障的原因、处理过程的复盘、形成后续解决的Action,并且都会以文字的形式详细记录，对故障的责任进行归属，一般会到具体的责任人。注意，对故障责任的判定，不是为了惩罚个人，而是通过对故障的复盘形成解决方案，避免问题再次发生。
3.5. 质量配套工具
针对数据质量的各个方面，都有相关的工具进行保证，以提高效能。接下来将对数据质量保障的各个方面进行介绍。
博文参考
《阿巴巴大数据实战》
