7.8 数据质量与可观测性

概述与动机

数据质量指的是“适用性”：数据在多大程度上能够服务于依赖它的各项决策、产品和报告。一个数据集本身并无绝对的好坏之分，它要么足以满足某个目的，要么不能。一个对营销统计来说没问题的客户地址，用在法律通知上可能就不合格。这样的框定很重要，因为它把讨论的重点从“我们的数据是否完美”（永远不可能）转变为“我们的数据是否适合接下来要做的事”（这个问题是可以回答、也可以测试的）。数据质量的经典维度包括准确性、完整性、一致性、及时性、有效性和唯一性，绝大多数实际问题都可以归结为其中之一。

对大型团队而言，有一个令人不安的真相：糟糕的数据比没有数据更糟糕。当你没有数据时，你清楚这一点，因此会保持适当的谨慎。而当你拥有看起来正确、实则错误的数据时，你会带着错误的自信采取行动。糟糕的数据会悄无声息地侵蚀一切。它会流入某位高管信任的仪表盘，流入用它来训练、从而把错误固化进模型的机器学习模型，也会流入那些没有人想到要质疑的决策（）因为那个数字就明明白白地显示在屏幕上。这种损害是弥散的、滞后的，而这正是它代价高昂的原因所在。等到有人注意到时，这个错误的数字可能早已被引用进董事会材料、监管申报文件，或一项公开统计数据之中。

数据可观测性是一门在数据的消费者发现问题之前就先一步捕获问题的学科。它直接对应着软件可观测性与遥测（第 9.2 章）：让你去监控请求延迟和错误率的那种本能，同样也应该让你去监控数据的新鲜度、数据量、模式（schema）和分布情况。本章建立在数据战略与治理（第 7.1 章）和数据工程（第 7.2 章）的基础之上，并为数据建模与语义层（第 7.7 章）以及负责任且可信赖的人工智能（第 6.5 章）提供支撑。对于需要核对众多源系统数据的企业，以及需要发布法定统计数据的政府机构而言，把数据可靠性当作一个有明确归属人和服务水平的工程问题来对待，正是信任与一场极其公开的更正声明之间的分野所在。

关键原则

数据质量是适用性，而非完美性；要依据用途来定义它。
糟糕的数据比没有数据更糟糕，因为它会悄无声息地侵蚀决策。
像测试代码一样测试数据：在流水线中加入断言、预期和模式检查。
生产者与消费者之间的契约，让彼此的预期变得明确且可强制执行。
像观测服务一样，观测数据的新鲜度、数据量、模式和分布。
血缘关系能把“出了点问题”变成“这里是坏掉的地方，以及它影响了什么”。
像对待生产事件一样对待数据事件，明确归属、严重程度和服务水平。
在问题进入系统的入口处就发现它，而不是等到三层之外的某个仪表盘上才发现。

建议

按维度定义质量，并加以度量

含糊的质量目标只会产生含糊的结果。要把质量拆解成可衡量的维度，并为每一个维度附加具体的检查项。准确性问的是数值是否反映了现实（记录的营收是否与源账本一致）。完整性问的是预期的记录和字段是否齐全（是否缺失了某些天的数据，必填列是否存在空值）。一致性问的是同一个事实在不同系统之间是否一致（财务部门的客户数是否与数据仓库中的数字一致）。及时性问的是数据是否在有用的时间窗口内到达（昨天的数据是否在晨报生成之前就绪）。有效性问的是数值是否符合规则和格式（所有货币代码是否真实存在，日期是否在合理范围内）。唯一性问的是每个实体是否只出现一次（是否存在重复订单虚增了总数）。为每个数据集选取真正重要的维度，设定阈值，并随时间追踪它们。你没有度量过的质量，就是你在靠猜测的质量。

用断言和预期来测试流水线

数据理应得到与应用代码同等严谨的测试。要在每一个阶段使用数据验证：基于断言的测试，在某项不变量被违反时使流水线失败；基于预期的测试，声明某张表的“正常”状态应该是什么样子，并标记出偏差。断言主键唯一且非空、外键可以正确解析、分类列只包含被接受的值、数值列落在合理的取值范围内，以及行数落在预期区间内。添加模式检查，在上游某一列被新增、删除、重命名或改变类型时明确报错。在持续集成中运行这些检查，让一次糟糕的转换在合并之前就被发现；再在生产环境中对实时数据重新运行这些检查，让一个糟糕的数据源在到达消费者之前就被发现。目标是尽早、显著地失败，因为一条明显损坏的流水线，远比一条悄悄出错的流水线更安全。

在生产者与消费者之间建立数据契约

大多数数据质量事件都始于上游：某个生产数据的团队变更了某个模式、某个语义含义，或某种取值约定，却不知道有谁依赖着它。数据契约通过让接口变得明确来解决这个问题：模式、每个字段的语义、允许的取值、新鲜度保证，以及变更流程。生产者对契约做出承诺，消费者依据契约进行构建，一次破坏性变更需要经过版本化和事先通知，而不是在某个周一悄然带来意外。在能做到的地方，机械化地强制执行契约：在边界处依据契约验证传入的数据，并拒绝或隔离违反契约的数据。契约把一种隐性的、脆弱的依赖关系，转变成了一种显性的、经过协商的关系。它们同时也让归属变得可见（）而这正是大规模场景下成败的关键一半。

监控数据可观测性的四个信号

数据可观测性监视四个信号，这与你监视一个正在运行的服务（第 9.2 章）的方式直接对应。新鲜度：数据是否如预期般新鲜，还是流水线已经停滞。数据量：行数是否落在预期区间内，还是某张表到达时数据量只有一半，或者被重复加载了两遍。模式：结构是否发生了意外变化。分布：数值本身是否发生了漂移，以至于一个原本只有 2% 为空值的列突然变成了 40% 为空，或者某个平均值发生了预示上游存在缺陷的偏移。为你重要的表设置这些信号的监测，了解它们的正常模式，并在出现偏离时发出告警。这正是你如何把“某位高管发现仪表盘看起来不对劲”，转变为“归属团队在故障发生的那一刻就收到了寻呼”。检测数据问题最糟糕的方式，就是依赖一个信任这个数字的下游人类。

加入异常检测，但要针对告警疲劳进行调优

静态阈值能够捕捉到明显的故障。对于更细微的漂移，可以叠加一层异常检测，让它学习每项指标的正常季节性模式，并标记出统计意义上的异常偏差，这样你就能在缓慢的泄漏演变成洪流之前把它捕捉到。在这件事上要保持纪律性。嘈杂的异常告警会训练人们去忽略告警，而这比根本没有告警还要糟糕。从你最高价值的表开始，只对那些值得人采取行动的事情发出告警，把每一条告警路由给一位具名的归属人，并毫不留情地进行调优。一条没有人采取行动的告警，是你监控系统中的一个缺陷，而不是一项功能。

追踪血缘关系，用于影响分析和根因定位

当出现故障时，有两个问题会立刻变得至关重要：是什么导致了它，以及它影响了什么。数据血缘通过映射数据如何从源头经过每一次转换、流向每一张下游表、每一个仪表盘和每一个模型，来回答这两个问题。要定位根因，你需要把一个错误的数字向上游追溯到引入它的那次转换或那个数据源。要做影响分析，你需要向下游追溯，找出每一个受到某次糟糕加载影响的消费者，这样你就可以在损害扩散之前通知他们并隔离损害。要从你的转换和编排工具中自动捕获血缘关系，而不是靠人工维护一张图表，因为一张手绘的图表在你画完的第二天就已经过时了。在拥有众多数据源的企业中，要把血缘关系发布到数据目录中，让任何消费者都能看到某个字段来自哪里，并据此判断是否可以信任它。

像对待生产事件一样对待数据事件

那些让服务保持可靠的实践，同样直接适用于数据。为每一个重要的数据集指定一位归属人。为“数据宕机”（即数据缺失、错误或延迟的时段）定义严重程度等级。设定服务水平：新鲜度目标、可接受的错误预算，以及检测和解决的目标时长。在最关键的流水线背后设立数据值班轮换制度，撰写操作手册，并在事件发生后开展无责事后总结，避免同样的故障再次发生。当一张支付表延迟到达，或一项公开指标出错时，这就是一起事件，理应得到与一次服务中断同等的重视。正是这种文化层面的转变，才让所有的工具投入真正获得回报。

持续进行数据剖析与核对

数据剖析意味着定期检查数据的形态：取值分布、空值率、基数、最小值和最大值，以及格式模式。它能够揭示出你从未想过要断言的问题，也能告诉你“正常”应该是什么样子，从而帮助你设定合理的预期。数据核对意味着检查各个独立来源是否一致：数据仓库中的总数是否与作为记录源头的系统一致，各部分之和是否等于整体。要在关键系统之间自动化地进行核对，并在出现分歧时发出告警，因为核对出现偏差，往往是上游出了问题的最早、也最明确的信号。

权衡：优缺点对比

方法	优点	缺点	最适用场景
断言测试（硬失败）	彻底拦截坏数据，不变量清晰	可能因为小问题而阻塞流水线	关键主键、引用完整性
预期测试（软标记）	能捕捉漂移，不那么脆弱	需要调优，可能被忽视	分布情况、数据量区间
数据契约	防止上游意外，归属清晰	存在协调和治理开销	跨团队的生产者/消费者边界
异常检测	能捕捉细微、未曾预见的漂移	存在告警疲劳、误报问题	高价值表、具有季节性的指标
人工抽查	启动成本低，无需工具	无法扩展，会漏掉无声的错误	仅适用于非常早期的阶段
完整的可观测性平台	覆盖面广，具备血缘和告警能力	成本高、需要搭建、多了一个要运维的系统	数据源众多、受监管的报告场景

其中核心的张力在于覆盖面与噪声之间的取舍。什么都不监测，问题就会先到达你的消费者那里，这会摧毁信任。而给一切都装上触发灵敏的告警，则会让你的团队被大量误报淹没，直到他们把告警渠道静音为止（）这同样会让问题到达消费者那里。解决之道是按爆炸半径对你的数据进行排序。那些支撑董事会指标、面向客户的产品、监管报告和机器学习模型的表，应该得到全套待遇：契约、硬性断言、可观测性和值班归属。而那一长串探索性的表，则只需要轻度的数据剖析。把你的可靠性预算花在错误数据最伤人的地方，在其他所有地方则有意保持克制。

与团队讨论的问题

当坏数据到达生产环境时，谁会最先发现？又是怎么发现的？ 这是关于你的数据可靠性最能说明问题的一个问题，因为诚实的答案通常是“某个消费者偶然发现的”。如果分析师、高管或客户是你的检测系统，那你的平均检测时间就是以天为单位计算的，而且每一次都会损害你的可信度。另一种做法是，在故障发生的那一刻就给归属团队发送寻呼的监测系统，在坏数字扩散之前就发现问题。找出真实数字：你最近十次数据事件中，有多少是被监控发现的，又有多少是由下游人员报告的？每一次未被发现的时间又持续了多久？这个答案会告诉你，你拥有的到底是可观测性，还是仅仅是侥幸，也应当直接指导你优先在新鲜度、数据量、模式和分布检查上进行投入的顺序。
哪些数据集有归属人、有契约、有服务水平？哪些是孤儿数据集？ 在大规模场景下，大多数数据质量故障都可以追溯到一个无人负责的接口：某个生产数据的团队改动了某个东西，却完全不知道谁依赖着它，因为没有任何契约明确说明这一点。归属关系是让契约、告警路由和事件响应得以实现的基础，而孤儿数据集正是无声腐坏滋生的地方。逐一梳理你最重要的表，并对每一张表都问：谁对它负责，生产者做出了什么承诺，消费者被承诺了怎样的新鲜度和准确度。拿出你的血缘关系图：下游爆炸半径最大的那些表，往往最需要这些保障，却也往往恰恰是缺失这些保障的表。“重要”与“有归属”之间的差距，就是你下个季度的优先级清单。
一次数据质量事件对我们而言实际代价是多少？我们对待它的方式是否与这个代价相称？ 团队之所以对数据质量投入不足，是因为坏数据的代价是弥散、滞后的，因此它永远不会作为一个明确的成本项出现，而构建质量工具的成本却是具体、即时的。要重新构建这个问题，把一次真实事件端到端地计算成本：错误的决策、返工、在没有血缘关系可用的情况下工程师追查根因所耗费的工时、被侵蚀的信任导致人们悄悄重建自己的影子数据集，以及在受监管或面向公众的场景下，更正声明本身及其带来的声誉损害。找出去年的一个具体例子，诚实地把成本加总起来。如果一次支付流水线或公开统计流水线中悄无声息的故障，其代价可能超过一整年可观测性工具的投入，那么商业论证就不言自明了，讨论的重点也会从“是否要投入”转变为“该投在哪里”。
我们是否已经按爆炸半径对数据集进行了排序？我们的监控投入是否真的遵循了这个排序？ 大规模场景下最核心的失败模式，就是把可靠性投入平均分摊，导致那张没有人信任的探索性表，和那张支撑董事会指标的表得到同等的关注，而一条针对低价值表的触发灵敏的告警，会训练人们去静音那个同时承载着关键寻呼的渠道。你无法在不被噪声淹没的情况下监测一切，也无法在不让问题先到达消费者那里的情况下什么都不监测，因此真正需要做出的决定，是哪些地方需要全套待遇（契约、硬性断言、可观测性和值班归属），哪些地方轻度剖析就足够了。拿出你的表清单，并按依赖它们的对象打上标签：董事会指标、面向客户的产品、监管报告和机器学习模型，然后把这个排序与你今天检查和告警实际所在的位置做对比。对于需要核对众多数据源的企业，或者需要发布法定数据的政府机构而言，具有法律或公众曝光风险的表应当排在清单最前面，而“一旦出错最伤人”与“被监控得最多”之间的任何差距，都是一个需要立刻纠正的优先级错误。
哪些机器学习模型和分析结果正在依据我们从未验证过的数据做决策？它们可能悄悄固化了哪些错误？ 一个仪表盘向一个人展示一个错误数字，这个人也许还会质疑它；而一个模型在错误的特征上训练，就会把这些错误固化进它做出的每一个预测之中，其规模和不透明程度都使损害更难被发现或撤销。与之相互竞争的压力是速度：数据科学团队希望在新特征上快速推进，在每一路数据输入上都加上验证、契约和新鲜度保证，在某个模型因为上游某一列发生漂移而悄悄退化之前，感觉起来就像是一种阻力。拿出你生产环境中模型和分析结果的清单，列出每一个所消费的数据集，并诚实地标记出哪些数据输入有测试、契约和可观测性保障，哪些完全没有把关。在一个模型会影响信贷、福利或执法决策的企业或政府场景中，未经验证的训练数据不仅是一项质量风险，还会成为审计和公平性方面的责任隐患，因此“哪些数据输入应当作为模型发布的把关条件”这个问题，应当有一位明确的归属人和一份有文档记录的答案（第 6.5 章）。
当一个质量缺陷在数周之后才浮出水面时，我们是否真的能够重新处理并核对数据，还是我们早已丢弃了所需要的东西？ 许多质量故障在加载时是不可见的，只有在之后某次核对出现偏差，或某个可疑趋势促使有人去查看时，才会变得清晰，而到那时，能否干净利落地修复它，取决于你更早之前做出的一些选择：你是否保留了不可变的原始记录，独立数据源是否可以互相核对，血缘关系是否能让你把那个错误数字追溯到它的源头。这里的张力在于成本和简洁性与可重现性之间的权衡，因为保留原始数据并在系统之间持续运行核对并非没有成本，而一旦转换后的表看起来没问题，人们就很容易想要删除原始输入。拿出你针对原始数据的留存和不可变性策略、你自动核对的关键系统对清单，以及一个你曾经能够、或曾经无法通过重新处理来摆脱困境的真实缺陷案例。对于负有法定义务、必须把任何已发布数字追溯到源记录的政府机构，或者面临监管重述要求的企业而言，不可变的原始数据和自动化核对不是可有可无的卫生习惯，而是让一次更正站得住脚的机制本身。

行业视角

初创企业。 速度和信任比覆盖面更重要。在你的转换工具中加入少量轻量级测试（对主键做唯一性和非空检查，对承载含义的列做取值校验，为每个数据源设置行数区间），并且只在少数几张支撑公司核心指标的表上添加新鲜度和数据量监控。把每一条告警路由到一个由一名工程师负责的渠道，在你拥有足够多的表或团队来证明其合理性之前，不要急于购买一套可观测性平台。目标是在某个被标错的字段被创始人引用之前就发现它，而不是把一切都装上仪表。

小型企业。 在没有数据工程师、预算又紧张的情况下，要依靠你付费使用的数据仓库、BI 工具或 SaaS 平台中已经内置的质量功能，而不是自己搭建一套独立的技术栈。把精力集中在真正驱动决策的少数几个数字上（营收、销售管道、库存），定期用一个独立来源对它们进行合理性核查，如果供应商提供了新鲜度和模式告警，就认为它已经够用了。购买那些已经内嵌在你正在使用的工具中的质量功能，胜过自建一条无人维护的流水线。

企业。 问题在于要跨越众多团队和成千上万张表实现可靠性，因此要把接口标准化：在每一个生产者边界处建立数据契约，用一个可观测性平台监视新鲜度、数据量、模式和分布，并把血缘关系发布到一个目录中以便进行影响分析。按爆炸半径对数据集排序，为高价值数据集配备异常检测和值班归属，并让数据事件走与服务中断相同的严重程度和事后总结流程。为支撑监管报告和高管仪表盘的流水线设定服务水平，能把数据可靠性从一种美好愿望，转变为一项有度量、有治理的承诺。

政府。 法定的准确性要求和公共问责制设定了标准：落地不可变的原始调查和行政记录，分层、经过测试地进行转换，并在每一步都与源头总数进行核对。要保留完整的血缘关系，让任何已发布的数字都能被追溯到源记录以供审计，并且每一次发布都要经过针对有效性、完整性和与既往时期一致性的验证把关。工具的采购应当要求具备透明度和数据可移植性，而一个错误的公开统计数字，必须被当作一起严重事件来处理，其严肃程度应与公众对官方数据的信任程度相称。

示例

初创企业。 一家二十人规模的公司，依靠一个由产品事件和支付服务商数据供给的数据仓库来运营其市场推广业务。早期，一个被标错的货币字段悄悄虚增了两周的报告营收，才被人发现，这动摇了团队对每一个仪表盘的信任。他们的应对方式是在转换工具中加入一套轻量级测试：对主键做唯一性和非空检查，对货币和状态列做取值校验，并为每个数据源设置行数区间。他们在支撑公司核心指标的少数几张表上，添加了基础的新鲜度和数据量监控，并将其路由到一个由一名工程师负责的 Slack 频道。这套方案并不宏大，但它能捕捉到真正重要的故障，创始人们也重新信任起这些数字。

企业。 一家跨国银行把来自数十个源系统的客户和交易数据核对整合进一个受治理的数据仓库中，为监管报告、风险模型和高管仪表盘提供数据支撑。它在每一个生产者边界处运行数据契约，因此一次上游模式变更会被版本化并加以协商，而不是让消费者措手不及。一个可观测性平台监视着成千上万张表的新鲜度、数据量、模式和分布，对高价值的表还配备了异常检测，并把血缘关系发布到数据目录中用于影响分析。数据事件遵循与服务中断相同的严重程度和值班流程，支撑监管申报的流水线还设有服务水平。当某个源系统发生漂移时，归属团队会收到寻呼，受影响的下游报告在几分钟内就能明确，而不是等到被监管机构发现。

政府。 某国家统计机构发布着被市场、政策制定者和公众视为权威的经济指标，因此准确性是一项法定义务，每一个已发布的数字都必须可供审计。它的流水线先落地不可变的原始调查和行政记录，然后分层、经过测试地进行转换，并在每一步都与源头总数进行核对。完整的血缘关系让分析人员能够把任何已发布的数字追溯到源记录，这既是一项质量工具，也是一项法律要求。在发布之前，数字要通过针对有效性、完整性以及与既往时期一致性的验证关卡，任何异常都要经过调查和记录，而不是直接发布。一个错误的公开统计数字是一起严重事件，因此该机构以与公众信任所要求的相称的严肃程度来对待数据宕机问题。

商业论证：动机、投资回报率与总拥有成本

数据质量与可观测性的回报来自于信任的维系、事件持续时间的缩短，以及错误决策的避免。可信赖的数据是让分析、商业智能和人工智能领域一切下游投入真正获得回报的基础，因为一个模型或仪表盘的好坏，完全取决于其背后的数据质量。当质量检查在边界处拦截一次糟糕的加载时，你避免的是一个错误数字到达某项决策、某位客户或某份申报文件所带来的远为巨大的代价。血缘关系把根因调查从数天的人工追查压缩到几分钟，这是实实在在被挽回的工程时间。可观测性把平均检测时间从“等消费者投诉的时候”缩短到“流水线故障的那一刻”，而这正是大部分信任损害得以避免的地方。

总拥有成本包括测试、可观测性和编目工具的费用，加上为流水线加装监测所需的工程时间，以及指定归属人和撰写契约所需的组织性工作。这些成本是实实在在的，但要把它与不这样做的代价加以权衡：被高管发现的无声数据腐坏、在坏特征上训练、从而在大规模上固化错误的机器学习模型、分析人员因为不再信任官方数据集而悄悄重建影子数据集，以及在受监管或面向公众的场景中，会损害多年信誉的更正声明。对领导层而言，应当把数据质量框定为组织所做每一项数据驱动决策的保险。这份保费不高，而且可预测。而不投保所要承受的损失（）一个引发轩然大波的错误数字（）则既不小，也不可预测。

反模式与常见陷阱

把数据质量当作一次性的清理项目，而不是一项持续进行的工程实践。
依靠下游消费者、而不是故障发生点的监控来发现故障。
没有数据集归属，因此出问题时无人负责，也无人收到寻呼。
生产者在没有契约的情况下变更模式或语义，悄悄破坏了每一个消费者。
异常告警噪声过大，团队因此把渠道静音，错过了真正的事件。
把未经验证的数据直接输入机器学习模型，在大规模上固化错误（第 6.5 章）。
把血缘关系维护成一张手绘图表，画完第二天就已经过时。
试图在所有地方都追求完美的数据，而不是在真正重要的表上追求“适用”的质量。
删除原始数据，导致质量缺陷在之后浮出水面时无法重新处理或核对。

成熟度模型

第 1 级，启动： 质量不是任何人的职责。问题由消费者发现，通常是在错误的数字进入某份报告之后。没有测试、没有监控、没有归属。修复靠人工救火，同样的故障反复出现。
第 2 级，发展： 一些团队在自己关键的表上添加了基础测试（主键、空值、被接受的取值），并对自己最关心的数据集做了一点新鲜度和数据量监控。这些实践在存在的地方是有效的，但覆盖面和严谨程度因团队而异，没有任何统一标准，事件依然是被动响应式处理。
第 3 级，标准化： 质量维度已被定义并设有阈值，相同的预期适用于所有团队，而不取决于谁搭建了某条流水线。数据契约管控着关键的生产者边界，可观测性覆盖了重要表的新鲜度、数据量、模式和分布，血缘关系支持影响分析。每一个重要的数据集都有具名归属人，数据事件遵循全组织统一、有文档记录的严重程度和响应流程。
第 4 级，管理： 质量和可靠性依据基线进行度量和管控。数据宕机被真实的指标追踪：平均检测时间、平均解决时间、相对于既定服务水平的新鲜度和准确度，以及一个数据集在触发行动之前可以消耗的错误预算。核对偏差率、测试通过率和异常误报率被作为趋势随时间追踪，告警依据这些数字而非猜测来调优，一次数据发布是否放行的决定，依据的是相对基线的、经过度量的质量，而不是一厢情愿。
第 5 级，协同： 质量和可观测性是无处不在、自动化且具适应性的。异常检测能捕捉细微的漂移，契约被机械化地强制执行，血缘关系被自动捕获并发布到目录中。数据像生产服务一样拥有服务水平和值班归属，核对持续不断地运行，无责事后总结持续推动数据宕机时间稳步下降。质量与数据治理、机器学习和业务规划相互集成，组织随着数据版图的变化不断重新调整阈值、覆盖面和归属安排。

讨论思路

如果你的哪些表在一周内悄悄出错，会造成最大的损害？这些表是否正是你监控得最多的那些？
一份数据契约本可以在什么地方防止你上一次由上游引发的事件？为什么当时没有这份契约？
今天，一次典型的根因调查通常要耗费多少工程时间？自动化的血缘关系又能节省多少？
你的机器学习模型中，有没有正在使用未经验证的数据进行训练的？它们可能正在固化哪些错误？
你的告警调优是否足够精细，让人们对每一条告警都会采取行动？还是已经有人把渠道静音了？
你最重要的消费者，实际上愿意签署怎样的新鲜度和准确度服务水平？你今天能达到这些水平吗？

要点总结

数据质量是跨越准确性、完整性、一致性、及时性、有效性和唯一性的适用性。
糟糕的数据比没有数据更糟糕，因为它会悄无声息地侵蚀决策和模型。
像测试代码一样测试数据：在 CI 和生产环境中都运行断言测试、预期测试和模式检查。
使用数据契约，让生产者与消费者之间的预期变得明确且可强制执行。
观测新鲜度、数据量、模式和分布，与软件可观测性（第 9.2 章）相互对应。
捕获血缘关系，以支持快速的根因定位和影响分析，并将其发布给消费者。
像对待生产事件一样对待数据事件，明确归属、严重程度和服务水平。
在错误数据最伤人的地方投入监测；追求适用的质量，而不是处处追求完美。

参考文献与延伸阅读

Barr Moses、Lior Gavish 和 Molly Vorwerck 合著，“Data Quality Fundamentals”
Jacek Majchrzak、Sven Balnojan 和 Marian Siwiak 合著，“Data Contracts”
Danette McGilvray 著，“Executing Data Quality Projects”
Thomas C. Redman 著，“Data Driven: Profiting from Your Most Important Business Asset”
Laura Sebastian-Coleman 著，“Measuring Data Quality for Ongoing Improvement”
Joe Reis 和 Matt Housley 合著，“Fundamentals of Data Engineering”
DAMA International 编，“DAMA-DMBOK: Data Management Body of Knowledge”
ISO/IEC 25012，“Data quality model”