数据质量监控策略与自动化的角色

数据质量监控有许多不同的方法。在评估选项之前，先思考成功的标志是什么会有所帮助。在本章中，我们将定义成功的要求。然后我们将逐步介绍传统策略------手动检查、基于规则的测试和指标监控------并看看它们如何衡量。

接下来，我们将探讨自动化数据质量监控的想法。我们将解释无监督机器学习如何帮助我们满足成功标准中的一些缺失方面，将监控扩展到大量数据同时减少警报疲劳。

最后，我们将介绍本书中提倡的数据质量监控策略：一个结合了数据可观测性、基于规则的测试、指标监控和无监督机器学习的四柱方法。正如我们将展示的那样，这种方法有许多优点。它允许专业领域专家（SME）强制执行重要约束并跟踪重要表的关键绩效指标（KPI）------同时为大量多样化的数据提供基本监控，无需服务器农场或大量分析师。

监控要求

为了解决第一章中概述的广泛问题，成功的数据质量监控策略必须在四个方面（如图2-1所示）具备：

• 首先，它必须检测到所有重要数据中的质量问题，以便您可以确信没有问题被忽略------无论这些问题是在表、列还是单个行的级别上出现的。

• 第二，它必须及时向正确的人员发出警报，当出现真正的问题时，而不会因通知人们非问题而导致警报疲劳。

• 第三，它必须帮助您快速有效地解决问题。（有关这些问题的完整列表，请参见附录。）

• 最后，它必须能够扩展到全企业范围内监控数据的健康状态。

数据可观测性：必要但不充分

在谈论数据质量监控方法之前，让我们简要谈一下数据可观测性。它是任何全面的数据质量策略的关键部分，有一个重要区别，即数据可观测性监视有关您的表的元数据，而不是数据本身的内容。

数据可观测性类似于基础设施或网络可观测性，但应用于数据仓库中的数据。换句话说，它是关于回答以下问题的：

• 这个表还存在吗？

• 表的模式有没有发生任何不良变化？

• 表最近有没有更新？

• 表中的数据量是否与我的预期一致？

当确定是否可以信任您的数据时，这些都是重要问题，您会注意到附录中的一些数据问题仅凭观测性就可以检测到。

那么，数据可观测性是如何工作的呢？幸运的是，它使用的元数据可以从大多数现代数据仓库中收集，而无需查询表。通常有一个提供此类数据的 API，或者可以查询的系统视图，以保持这些数据的最新状态。所需的数据包括表级别的统计信息，例如：

• 表

• 最后更新时间

• 行数（或字节大小）

以及列级别的信息，例如：

• 表

• 列名

• 列类型

平台只需要定期（比如每小时）捕获可观测性元数据，然后就可以回答关于元数据随时间如何变化的问题。

例如，在 Snowflake 中，您可以使用以下查询检索表级元数据：

SELECT

 TABLE_NAME,
 ROW_COUNT,
 BYTES,
 LAST_ALTERED

FROM INFORMATION_SCHEMA."TABLES"

在"表最近有没有更新？"方面，系统需要做出一个艰难的决定："最近"是什么意思，什么时候延迟变得显著？有些表使用流式数据不断更新。其他表每小时更新一次。还有些表可能每天更新多次，或者仅每周（或每月、每年）多次。时间序列模型（如第31页的侧边栏"时间序列度量监控"中讨论的）在这里是一个强大的工具------它们可以使用更新历史来预测下一个更新到达的预期上限。

这是否意味着您已解决了数据质量问题？当然不是！数据可观测性检查仅涉及数据在您的仓库中的流动。它们不解决数据内容是否具有高质量的问题。仅使用数据可观测性就好比在运营一个水处理厂，您唯一的质量控制是提供的水压，而不关心这些水是否适合饮用！

	数据可观测性	数据质量监控
回答的问题	数据是否及时通过我的数据仓库流动？	数据仓库产生的数据是否高质量？
工作原理	目录元数据 作业监控 数据血缘	查询数据 需要专家或机器学习 关键是可解释性
为什么需要它	捕获数据移动失败	对数据值进行深入监控
主要缺点	忽略数据内容	扩展困难

传统的数据质量方法

许多团队发现实施整个数据仓库的数据可观测性相对容易，但在扩展其数据质量监控方面却很困难。历史上，团队通常处理数据质量监控的最常见方法是通过手动检测、基于规则的测试和指标监控。虽然我们在这里将这些策略分开介绍，但组织通常同时采用所有三种。每种策略都有其价值，但在规模上也存在显著的缺点。

手动数据质量检测

自数字数据问世以来，人类一直有可能（但越来越困难）手动检查数据并发现潜在问题。 在一些企业，存在着有意识的手动数据质量审查流程，无论是通过抽查、查看摘要还是查看可视化方式。这通常不足以监控数据质量。当数据足够小且简单，以至于人类可以查看电子表格并快速发现潜在问题时，手动检查可能会奏效（顺便说一句，各种研究报告称，近90%的电子表格中存在错误！）。但在规模上并不有效。此外，手动过程本质上是主观的。将同一个复杂数据集交给10个不同的分析师，你会得到关于他们评估的数据质量的大量不同结论。 手动数据质量检测还以非常不同的方式发生：偶然。某人正在处理数据，他们"偶然发现"了一个数据质量问题。以下是一些例子：

计算汇总统计数据并将其与已知数字或其他参考数据点进行比较

例如，数据科学家可能会发现聚合数据集中的客户数量比另一个已知来源高出50%，这表明可能存在数据质量问题。

创建总结数据的可视化方式，清晰地显示存在数据质量问题

例如，对缺失值随时间变化的可视化可能会显示最近几周急剧增加。

从分析或模型的询问中得出结论，这些结论表明某些是可以被证明为不真实的事情

分析人员可能发现欧洲最近三周的新账户增长率超过了1000%，但这是不可能的。或者，一个机器学习模型可能会建议预测用户流失最重要的特征是用户的出生日期，但仔细检查后发现，这是因为大部分用户都出生在1970年1月1日（Unix纪元的开始），这表明存在数据问题。

依赖分析师和数据科学家在工作中发现数据质量问题也不是一个成功的策略。从业者只会周期性地检查数据，并且具有非常具体的目的。他们很可能会在数据质量问题发生后很久才发现，并且几乎肯定会错过超出其项目范围的数据质量问题。

这种边进行决策边解决问题的方法实际上是非常有害的。在我们合作的一些组织中，超过50%的分析人员的时间都用于调查和解决数据质量问题。这种手动工作不仅会使团队的效率减半，而且随着时间的推移，会对士气造成巨大影响。

尽管如此，分析人员和数据科学家无疑希望能够了解他们处理的数据，并且根据情况，手动审查可能会增加价值。人类能够将不同的数据源和背景知识汇集在一起，并以算法无法自动化的方式得出结论。而且，当在分析或机器学习模型的环境中发现数据质量问题时，它们根据定义就是"重要的"数据质量问题，需要解决 - 不存在误报的风险。

最终，无论你选择什么样的监控方法，都应该减少手动工作量，并且使监控数据规模化成为可能。但是，它仍然应该让人类能够轻松地分析其数据并手动发现问题，并且您可以通过生成汇总统计数据和可视化来帮助这个过程。

基于规则的测试

在测试软件时，工程师编写单元测试来调用组件，测量所采取的操作，并对这些测量应用确定性规则，以验证软件是否按预期工作。例如，电子商务应用程序可能会有一种计算税率的方法。一个单元测试可以为这种方法提供各种商品篮子和商店位置，并确保它产生正确的答案。

将适用于测试软件的方法（编写大量单元测试）应用于数据是很自然的。我们将这种方法称为基于规则的测试。常见的基于规则的测试工具包括Great Expectations和dbt。基于规则的测试是一种可以应用于特定来源数据的确定性测试。数据要么通过测试，要么失败测试；中间没有灰色地带。

基于规则的测试的示例包括：

• 表ticket_sales中的列number_of_tickets从不为空。
• 列listing_time中没有来自未来的值。
• 列price_per_ticket的平均值每天都在50到100之间。
• 方程式number_of_tickets * price_per_ticket *（1 + tax_rate）的结果对于表ticket_sales中的每一行总是等于total_price。

每个规则都可以被认为具有范围、类型和（通常）一些约束条件：

范围

规则适用于哪些数据？哪个数据存储？哪个表或视图？哪些列？在什么时间范围内？针对哪些特定行？ 值得注意的是，在大多数情况下，可以为给定数据集的每一行评估基于规则的测试，这使您可以清晰地将"良好"的行与"不良"的行分开。但是规则也可以应用于从数据中计算出的统计数据（例如，0 <= sum(column_x) <= 50）。总的来说，我们将规则视为独立应用于数据的每一行。将规则应用于统计量的特殊情况可以被视为首先计算聚合数据集（可能是由某些实体，如客户，或时间单位，如日期，或完全不分组）的结果，然后将基于行的规则应用于该聚合结果。

类型

将应用的规则的类型是什么？例如，对于适用于给定列的规则，您可以从各种类型中进行选择：列是唯一的，列从不包含NULL值，列的字符串值在指定的集合内等。规则类型可以扩展到单个列之外，覆盖有关表的元数据（上次更新时间，总行数），表的架构（特定列名称、类型和顺序）等。规则可以涉及多个列及其彼此之间的关系，或者表与其他表之间的关系通过连接语义（例如，基于给定主键的1：1连接）。

最复杂的规则类型通常表示为SQL查询，可能包含联接、子查询和查找条件的复杂语句，这些条件在表中"永远不会出现"。例如："每个已完成结账并且没有随后取消、作废或完成的订单的客户应在customers_with_active_orders表中有一条记录。"这可以在SQL中表示为：

SELECT COUNT(DISTINCT customer_id) as num_missing
FROM orders
WHERE checked_out
AND order_status NOT IN ('canceled', 'voided', 'completed')
AND customer_id NOT IN 
 (SELECT customer_id FROM customers_with_active_orders)

约束

选择了范围和类型之后，通常需要为规则提供一些常量约束条件。例如，在规则"price_per_ticket始终在50和100之间"中，50和100的值是常量约束条件。在某些情况下，这些约束条件是不必要的（"column X是唯一的"不需要约束条件）或者它们与规则类型重复（"column从不为空"等同于"NULL计数等于0"，其中0是常数）。

规则是任何数据质量监控策略的重要组成部分。与人工分析相比，规则运行起来成本低且不会出错。规则也是清晰和确定性的。每一行要么通过，要么不通过。一旦完全理解了规则，您还将了解为什么基于规则的测试会失败，以及为了使该行通过测试，需要满足什么条件。当基于规则的测试失败时，您可以相信它确实失败了 - 不可能存在数据良好但规则说它是不好的（当然，除非规则本身不正确；我们稍后会解决这个问题）。

此外，规则是识别历史数据质量问题的最可靠方法之一，这些问题从数据集开始就存在，或者在历史上从未被发现和解决。为什么呢？规则允许专业人士表达他们对给定数据集的要求，这些要求基于他们对生成数据的系统或收集数据的业务背景的了解。专业人士可以编写一条规则，规定某一列在数据的过去、现在或未来都不应该为空。与从数据历史中学习的方法（例如使用指标或无监督的机器学习来检测意外变化，我们将在稍后讨论）相比，这些方法本质上是在寻找数据的突然变化，而这些变化从定义上来说是新的而不是历史性的数据质量问题。这样的方法无法确定数据是否一直存在问题。

规则还擅长找到大海捞针。如果你正在处理一个拥有数十亿行的表格，那么规则通常是发现是否有少数记录违反给定条件的最可靠方法。（请注意，如果您不关心每一条记录，这可能是个问题，因为您将不得不找到排除过去不再关心但违反规则的数据质量"痕迹"的方法。）

然而，仅仅依赖基于规则的测试是错误的。首先，指定高质量规则存在很大的错误空间：

• 范围可能被过于狭窄地指定（WHERE SQL子句太紧），导致规则错过数据质量问题（例如，该规则仅应用于表的X段，但它也应该适用于段Y）。
• 范围可能过于广泛地指定（WHERE SQL子句太宽泛），导致规则错误地标记有效数据为无效（例如，对于某些记录，此列实际上应该为空）。
• 规则的约束可能被错误地指定。这在为列值或统计信息设置范围时非常常见。范围可能过于宽泛（因此错过真实的数据质量问题），或者过于狭窄（因此在数据变化时非常嘈杂）。
• 可能选择了错误类型的规则。测试可能无法捕获用户的真正意图，或者生成的通知可能没有意义，因为测试是不合适的（该列始终打算具有NULL值，但仍然应用了"从不为空"的规则）。

此外，使用高质量规则覆盖现代企业的所有数据是一项艰巨的任务。考虑以下现实的假设性例子，其中一个组织需要监控用于数据质量问题的 10,000 张表：

• 10 张表是至关重要的事实表，整个公司都依赖这些表（董事会的关键统计数据来自这些表）。
• 90 张表包含每天在整个公司内做出业务和运营决策所使用的关键数据。
• 900 张表对个别团队或倡议至关重要，产品经理、机器学习工程师、分析师、数据科学家或其他精通数据的专业人员每周都会使用这些表。
• 剩下的 9,000 张表可能存在着数据质量问题，这些问题以在其他 1,000 张表中表现出微妙、难以检测的方式为特征。

这些表中的每一张可能会有数十、数百，甚至数千列。例如，事实表通常会将关于给定类型实体的各种信息聚合到一个非常广泛的表中，从而启动许多分析和用例。某些表还可能有数百或数千个不同行为的分段（行组）。例如，Web 事件表通常会捕获大量结构化数据（设备、IP 地址、URL、用户、时间等）和半结构化数据（JSON 负载），用于记录用户可以执行的数百甚至数千种不同的事件或操作。

每张表的每一列或段可能都需要 5 到 10 条规则来覆盖对该数据的最重要约束。因此，要使用基于规则的测试监控其最重要的表，一个组织可能最终会编写 1,000 张表 * 每张表 50 列 * 每列 5 条规则 = 250,000 条规则。而这还没有涵盖半结构化数据、段变化或其他 9,000 个潜在重要的表！

除了创建基于规则的测试之外，您还必须维护这些测试，这比维护单元测试要困难得多。代码的单元测试应该在每次运行时都产生相同的结果，直到软件更新破坏了预期的行为，无论是有意还是无意。但与代码不同，数据不断变化，且变化方式难以预测------例如，随着新产品的推出、宏观环境的变化或用户行为的改变等。因此，基于规则的测试可能非常脆弱。为了确保它们的定义，特别是它们的约束保持准确，规则需要随着产品和数据的演进而不断更新。在最开始时放宽约束可能会节省一些时间，但这会冒着忽视真正问题的风险。

总之，基于规则的测试并不是在现代企业监控数据的可扩展解决方案。然而，规则是SME表达和执行对数据的期望的强大工具。例如，来自Airbnb数据质量战略报告的图2-3给出了SME定义规则的实际示例，这些规则强制执行列表数据的一致性。理想的数据质量解决方案应该能够让广泛的SME群体轻松创建、编辑和分析规则。

指标监控

下一个数据质量监控方法也受到软件工程的启发。大多数软件系统通过跟踪基础设施的指标来进行监控，并在突然出现不利变化时进行通知。这些统计数据可以是关于硬件本身（CPU利用率、内存等）、网络活动（丢包等）或正在运行的个别服务（队列长度、平均延迟等）。类似地，您可以监控有关数据的统计信息，并设置阈值，以便在数据突然超出或低于预期时提醒系统。挑战在于，对于数据质量而言，要监控的指标范围庞大。为了确保适当的覆盖范围，您需要针对可能关心的每个列、段和统计信息设置指标，例如NULL值的百分比、重复值的百分比、均值、最小/最大值等。

除了可扩展性问题之外，数据质量的指标监控还存在其他问题。首先，由于它在统计聚合级别测试数据，因此可能会忽略只影响少部分记录的数据质量问题。此外，大多数指标监控的实现并不会识别导致指标变化的具体记录，这使得很难理解指标变化的原因以及变化是否有效（例如外部趋势）或由于数据质量问题。

指标监控还可能错过随时间潜入数据的问题。例如，想象一下，数据质量问题的源头是一个代码更改，该更改位于一个特性标志后面。如果该功能逐渐向客户段推出，数据将逐渐变化。对指标的任何变化也会很慢，并且可能永远不会达到警报的阈值。

尽管如此，当您想要密切关注数据的一个非常特定的片段时，指标监控是必不可少的。例如，图3-1显示了Airbnb选择优先考虑的一些指标，例如活跃列表数、新活跃列表、重新激活和停用。这些重要指标通常受到整体数据集的一小部分的影响，其中的任何趋势可能不会被其他将数据视为整体的监控方法捕捉到。

类似地，当数据针对某些预期百分比的记录而受损时，指标监控可以帮助用户避免该百分比显著增加。例如，可能会有20%的时间，用户记录由于用户记录的创建方式而没有有效地址。如果该百分比显著增加，则可能存在数据质量问题，导致比预期更多的用户的地址信息受损或被删除。

鉴于这些优缺点，一个成功的数据质量监控策略应该让用户设置关键指标的监控，并且理想情况下，使用时间序列模型来设置适当的阈值。但仅依靠指标监控还不够。

自动化无监督机器学习的数据质量监控

在介绍传统（非自动化）监控方法之后，现在是时候引入一种新策略了：无监督机器学习。数据质量与许多其他领域并无二致，曾经完全手动的流程，如欺诈检测、核保和产品推荐，现在都可以由机器学习算法处理。这些算法提高了效率，并能以一致的节奏运行，从而推动更好的业务结果。

虽然我们将在第4章和第5章中更详细地探讨无监督机器学习，但我们将在这里概述一下，并解释其在规模化自动化数据质量监控中发挥的关键作用。

什么是无监督机器学习？

广义上，机器学习算法可以分为有监督和无监督两类。在有监督学习中，模型用于学习的数据是由人类标记的。图像分类器通常使用有监督学习，人类向模型展示了数千张标记为树、猫等的图像，然后模型学会识别新图像中的类似对象。在无监督学习中，模型没有人类标签，它只有数据，其中包含所有数据固有的模式和关系。模型从数据本身学习，并根据其迄今为止观察到的一切来解释新的输入。

有监督学习作为一种数据监控策略是不合理的，因为它要求人类收集和标记大量多样的训练数据，这些数据代表模型需要可靠检测的真实世界数据质量问题。考虑到数据从一个表到另一个表之间，甚至从一个公司到另一个公司之间的差异，收集足够的标记数据使有监督机器学习运行良好将是困难的。这使得无监督学习更适合监控数据质量。

假设您已经开发了一个工作良好的模型，它可以在没有任何初始设置的情况下开始监控一个数据集，并随着数据的变化而继续学习和适应。这些算法可以调整以检测数据中的深层次、复杂的问题，例如：

• 一组列中NULL值的百分比已经增加。

• 特定的数据段（例如一个国家）已经消失，或者到达的记录少于预期。

• 列中的分布发生了显著变化（例如，信用评分的分布远高于预期）。

• 多列之间的关系发生了变化（例如，这些列过去相加应该相等，但现在对于一些记录不再相等）。

无监督机器学习最强大的一个方面之一是它旨在理解整个表中数据关系的变化。这一点很重要，因为表中的数据通常高度相关。

图2-4中显示的信用卡数据集是一个很好的现实世界的例子。每一列出现在垂直和水平轴上，圆圈的颜色基于列之间的phi-K相关性而变化。 这揭示了数据集中列之间的关系。通过观察靠近对角线的黑色圆圈的聚类，您可以看到所有的pay_N、bill_amt_N和pay_amt_N列都彼此相关。还有更令人惊讶的关系。例如，年龄与limit_balance和marital_status强相关。但是marital_status与limit_balance只有微弱的相关性。

在监控数据质量时，我们倾向于过于简化事物，仅考虑列中的值、分布或摘要统计，并创建规则或指标来单独监控列。但在实践中，现实世界的数据具有我们在这个信用卡数据集中看到的丰富复杂的相关结构。这对监控有两个重要的影响：

• 如果我们使用指标或验证规则单独监控该数据集的每一列，那么我们的监控器也将高度相关。如果列之间的相关性与某些数据或过程有因果联系，那么底层机制的变化可能会导致许多依赖性指标同时发生变化，并导致验证失败。因此，我们可能会收到数十个或更多的警报，而不只是一个警报。

• 如果我们单独评估每一列的数据质量，那么我们将忽略大量的背景信息，这些信息对于数据质量可能非常重要。在信用卡的例子中，如果我们突然发现年龄和limit_balance的相关性减弱，那么这可能表示其中一列经历了突然的数据质量冲击。

为了充分利用现实世界数据集的丰富结构，在相关问题上避免发送大量警报，并成功地实现规模化的自动化数据质量监控，我们需要一种能够对整个表中的数据进行操作而不是单独对每一列进行操作的监控方法。

这正是无监督机器学习算法的设计目标。与更狭窄范围的指标或验证规则相比，一个好的模型将发现更广泛的数据质量问题，包括人类没有考虑到的未知未知数。它将自动抑制重复异常；当问题再次出现时，它将能够将第一天作为"新正常"基线。影响多个列的问题可以被聚类在一起，并作为一个单独的问题呈现出来；它们在一次无监督算法的通过中被检测到，并相应地分配给适当的列和行。

一个类比：车道偏离警告

当我们考虑到数据质量监控如何通过机器学习实现自动化时，就想到了一个类比：驾驶是如何从完全手动的操作逐渐转变为由机器学习算法辅助的过程。这些算法之所以如此宝贵，是因为它们能够考虑到大量的背景信息，这些信息可能对于人类来说太隐蔽或太复杂，无法通过硬编码、规则和阈值逻辑来捕捉。

考虑驾驶的一个方面：确保您的车辆保持在车道内并进行安全变道。如果我们将我们讨论过的数据质量方法应用于这个问题，我们会得到如下情况：

完全手动的方法

驾驶员只需注意车道标线，不会分心或在驾驶时不小心睡着。这是我们一直以来确保车辆保持在车道内的方式。驾驶员需要极大的注意力和专注力，但我们仍然会发生与车道偏离相关的事故。

基于规则和指标的系统

想象一种依赖规则和指标的方法，思考一下如何使用车载摄像头和一些基本统计数据来检测道路上的车道线。如果摄像头接收到的一定比例的像素是黄色的（实质上是一个度量阈值），那么车辆将触发警告。这将是灾难性的，因为许多车道标线不是黄色的，也不是实线或足够大，以触发这个阈值。此外，有许多情况下，驾驶员应该越过车道线，比如在左转或变道以绕过交通或避开障碍物时。在实践中，这种过于简化的系统可能会导致太多干扰性、无用的通知，使驾驶员禁用车辆中的警报机制，回到没有通知的默认状态。

机器学习方法

机器学习方法对于是否发送通知会更加智能。它将使用车辆的上下文信息，如果转向灯打开，或者如果物体检测系统注意到车辆前方有障碍物，并且车辆应该偏离车道，那么就不会发送通知。它还可以优先通知用户，只有在跨越车道时存在与其他车辆或障碍物相遇的高风险时才会触发通知。这种方法的好处在于它的噪音要远低于朴素的车道通知系统，因此用户更有可能听从。这大大提高了车辆的安全性和用户在驾驶时的满意度。

自动化的局限性

重要的是要仔细考虑使用机器学习进行自动化的用例。设计不良的自动化往往比不自动化更糟糕。这就是为什么我们在本书的很大部分内容中致力于开发一个在真实世界数据上表现良好，并避免用警报淹没用户的模型。

正如图2-5所示，一旦自动化达到一定水平，就会出现收益递减。即使您已经建立了一个强大的模型，也会有一些问题是无监督机器学习无法解决的。首先，因为它在对数据进行采样，所以永远无法像验证规则一样找到大海捞针。例如，如果您说三个列之间必须始终存在某种关系，那么即使只有一个记录违反了该约束，验证规则也会找到它------而在无监督学习中，它可能根本不会被采样或被认为是不重要的。

其次，无监督模型从本质上来说是在寻找数据中的新变化，并且永远不会发现在历史上一直存在的问题。例如，想象一下，如果代表客户拥有的车辆数量的列在初始时被错误地编码，以至于缺失值被编码为0而不是NULL。这将导致下游系统认为拥有零辆车的客户比实际情况多得多，而实际上，这些客户的数据只是尚未收集。无监督模型或时间序列度量监视器不会捕获此问题，因为数据中的关系随时间并未发生变化。

第三，无监督模型将每个列和每个行视为同等重要------因此可能不会像直接定义在数据上的度量那样密切关注数据的某个切片。例如，如果您正在监视某列等于某个值的百分比，则这些记录对于度量结果的影响要比它们对于无监督监视方法的影响大得多，后者将查看整个表格。

自动化规则和度量的创建

关于自动化的一个自然问题是是否可以使用算法自动创建规则和度量。虽然自动规则和度量监视是可能的，但它的成本很高，并且会导致假阳性和假阴性（未检测到的问题）。

规则。假设您想要自动为数据质量监控系统创建规则，而不是要求SME手动指定规则。您可以首先预定义常见类型的规则（唯一性、NULL值、正则表达式模式等）。然后，您可以对一些历史数据进行采样以进行分析。对于您预先定义的每个规则，您可以检查表中的每个列，以确定该规则是否满足样本数据。然后，您还需要检查所有历史数据以确保规则继续通过。最后，您可以将所有历史数据上通过的规则投入生产。太棒了，对吧？嗯，并不完全是这样的。

对于数据量大的表，这种方法可能非常昂贵，因为最终需要评估每条历史记录上的每个规则，以避免在未来出现规则频繁失败的情况。对于数据量小的表，规则将非常脆弱------许多规则可能仅仅是由于偶然性而通过的。并且每当数据发生变化时，您都需要编辑规则或重新运行自动设置过程。最后，大多数用户想要的真正重要的规则都需要使用SQL进行定制，以便可以将其应用于表中的一部分记录，或者表达列或表之间的复杂关系。而这些定制内容极不可能是系统中预定义规则类的一部分。

在实践中，我们没有看到这种方法在实际情况中起作用。我们建议您让最终用户能够轻松地自愿添加规则，使用他们自己的首要原则判断，在需要数据完美时。这有两个优点。首先，只创建真正重要的规则，减少了假阳性和随时间需要维护的规则数量。其次，如果新规则在历史数据上失败，那么这将是一个学习机会。最终用户可能会发现并解决历史数据质量问题，或者在发现规则失败的原因时了解数据结构的新内容。

度量。自动化指标的创建意味着系统会自动计算和监视每个表和列的一组度量，而不是要求用户手动选择他们想要监视的特定度量。

这很容易实现。您可以决定您认为大多数用户会关心的开箱即用度量。对于表，这可能是每天的记录数和表上次更新时间。对于列，这可能是NULL、零、空白或唯一记录的百分比。更加复杂的是，您可以将每个度量配置为仅查找不利事件------行数减少，NULL值增加等。提前定义一些度量来自动监视有助于用户立即开始了解其表的数据质量，这是我们在Anomalo中使用的策略。但是，请注意，即使是少量的度量，这种解决方案也可能非常昂贵，因为您需要为每个需要监视的表和列进行大量计算。除非您有抑制假阳性的策略，否则它也可能导致警报疲劳------单个基础数据质量变化可能会导致10个列的NULL值增加，这将呈现为10个单独的警报，用户需要对其进行分析。

虽然一些指标可以自动化，但我们认为让用户能够定义自定义指标至关重要。这确保了不会错过重要的部分，其中可能有微小但关键的更改需要跟踪。并且它让您捕获了对用户最重要的指标------这些指标通常涉及计算用例特定的统计数据，如满足多列约束的记录百分比，这些数据将被排除在完全自动化的方法之外。

数据质量监控的四支柱方法

在本章中，我们涵盖了各种监控策略。简要概括一下，以下是组织可能采取的不同方法：

• 什么都不做（天哪！）。

• 为您的数据仓库实施数据可观察性（必备条件，但您实际上根本没有监控数据质量）。

• 使用手工制定的规则或度量监控数据的一个小子集。这会忽略未知的未知问题（您不知道需要检查的问题），并且只覆盖了数据的一小部分。

• 使用手工制定的规则和度量监控所有数据。这在设置和维护时间上非常昂贵，导致警报噪音很大，而且还会错过未知的未知问题。

• 使用规则自动进行监控。这非常昂贵，非常脆弱，仍然会忽略大量的分布和相关性问题。

• 使用度量自动进行监控。这也非常昂贵，非常嘈杂，仍然会忽略大量的记录级问题。

• 仅使用无监督监控自动化。虽然这提供了良好的覆盖范围，但它无法捕获所有问题，并且不会像手工制定的规则和度量那样密切关注关键数据。

•（我们的建议）采用四支柱方法。您可以以较低的成本在整个仓库中实施数据可观察性。同时，对于数据质量，自动化的无监督机器学习可以提供对明显问题和未知的未知问题的基本覆盖。您的平台应该使SME能够通过低代码验证规则和时间序列度量监视来增强自动化监控，以监控最重要的数据和关系。

数据可观察性、基于规则的测试、度量监控和无监督机器学习可以结合使用，以实现先前所述的检测、警报、解决和扩展的目标。这种策略可以在最大程度减少假阳性和警报疲劳的同时，为您提供高覆盖率的真实数据质量风险，而无需专门为此问题投入大量分析师。

图2-6解释了此策略的四个组成部分如何平衡彼此的优势和劣势。

图2-7用一些基本示例数据说明了规则、度量和机器学习的能力。

本书的其余部分是指南，教你如何根据我们在此处描述的四支柱方法来自动化您组织的数据质量监控。我们将首先确保这种方法适合您的组织，并且投资回报率（ROI）对您和您的数据团队是有意义的。然后，我们将介绍建模策略和权衡，然后再介绍关键功能，例如通知和集成。最后，我们将分享如何在您的组织发展过程中继续维护和增强数据健康。