确保数据监控解决方案有效的十个步骤

在本文中，我们将介绍十个可行的步骤，以减少假阳性和假阴性的警报，以及减轻出现误报时的的影响。

触发或未触发数据警报，无非以下四种结果。

理想情况下，收到的第个警报都应关乎于你关心的真正的数据质量问题 (真阳性)。如果没有你关心的问题，就不应发出警告 (真阴性)。

然而在现实世界中，大多数数据质量监控解决方案远远没有这么完美。它们会发送一些无效的警报 (误报)。这些问题分散了数据团队的注意力，削弱了对监控解决方案的信心。

亦或，监控工具遗漏了真实的数据质量问题 (假阴性)。这样会对你的业务决策和数据产品造成损害，对数据的可信度产生质疑。

在本文中，我们将介绍十个可行的步骤，以减少假阳性和假阴性的警报，以及减轻出现误报时的的影响。

1 使用动态数据测试策略

大多数数据测试策略都是从简单的规则开始的，例如:

• x 列永不为空

• y 表的行数在 1,000,000 到 2,000,000 之间

如果你希望确切地了解运行数据，这些规则可完美契合。

同时，它们也有几个缺点:

• 任何违反规则的行为，无论程度大小，都会产生警报。

• 需要由数据主题专家花费时间来设立这些规则。

• 随着时间的推移，它们可能需要经常维护，因为你的数据已经产生了变化。

通过使用动态数据测试策略，可以减少误报和误报。

这是一种可预测的范围检测，它利用了时间序列模型，在无需任何手动配置或维护的情况下，有效地识别为空百分比的峰值。

动态检测使用时间序列模型 (或其他机器学习技术) 去适应你的数据，并只在突然产生有意义的变化时发出警报。这样的检测在设置和增加测试覆盖率上的工作量投入更少，同时减少了由于配置失误或随着时间的推移而导致的误报。

2 默认情况下只检查最新数据

默认情况下，你的平台应该只检查表中最近的数据。

应该允许用户可以轻松关闭是否检查最新数据这一默认选项。

只检查最新数据可以节省数据仓库的成本，并可减少源自历史数据的误报，这些历史数据往往是不需要再修复的。针对那些不仅仅是追加数据的表，用户应该很容易禁用此功能。还可以让检查跟踪其运行历史，仅在遇到表中出现新问题时发送通知。

3 支持无代码配置变更

数据质量规则难免总会出现一些假阳性警报。在这些情况下，用户应该能够轻松地调整他们的检查。如果用户必须编辑代码或更改复杂的 YAML 配置文件，他们将会产生一些抵触。

用户经常会做以下几类变更：

• 扩大数据结果的预期区间

• 使用 where 条件 SQL 子句缩小规则的范围

• 等待已更新的数据到达之后再应用规则

• 改变机器学习警报的阈值

调整关键指标或数据验证规则的高级选项，可降低假阳性和假阴性警报的风险。

进行变更的 UI 应可一键避免警报。它应该易于理解并有充分的文档。最后，应该具有变更的审计跟踪，以便在需要的时候进行简单的回溯。

4 为数据质量规则制定优先级

并不是所有的数据质量规则都同等重要。在某些情况下，用户可能正在试用这个平台，并不收到警报。在其他情况下，规则可能就非常重要了，任何偏离预期行为的行为都应该发出尖锐的警报。

除了更改警报行为外，优先级级别还可以根据失败警报的严重程度更改仪表板中警报或表格的显示方式。

第一个表格中有两个失败警报——其中一个是高优先级。第二个表格中有一个失败警报。而第三和第四个表格中有低优先级的警报，第五个表没有任何问题。

5 在流水线中使用 API 去运行高优先级规则

如果你非常确信某些数据验证发现的任何问题都是真实存在的，且会产生严重不良后果，那么就有必要在流水线中运行这些警报。

示例：如何在管道中运行数据质量检查，以隔离和避免发布坏数据。

例如，在 Apache Airflow 中，你可以使用 API 对转换后的数据执行数据质量检查，然后轮询检查结果，若没有失败就发布数据。

如果检查失败了，你可以运行自动任务来修复这些坏数据，中止 DAG 的其余部分 (有时，没有数据比坏数据更好)，或使用 API 中生成的 SQL 隔离坏记录，以备分别查询好数据和坏数据。

6 将类似的问题聚集到单个警报中

数据质量问题经常会同时影响多个列或段的数据。如果这些情况影响到相同的数据行，则应该将它们关联到一个警报中。

在同一组记录中，有三列增加了 NULL 值，因此在此警报中聚到了一起。

在上面的 (打码处) 警报中，其实共有 88 列异常增加了 NULL 值。把它们聚集起来减少了团队必须查看的警报数量，并有助于识别底层问题。

7 扫描原始数据行的样本，以发现任何意外的变化

对于许多重要的源表 (每个表包含数百个数据列)，为每个源表和列手动指定和管理数据质量规则是不现实的。反之，可以使用无监督数据监视来扫描源表中的随机样本行，以发现显著异常。

上图是 BigQuery 公共 COVID 数据集中表异常的时间序列视图。纵轴为表格的列，横轴为时间。圆圈的大小代表异常的强度。

可以定期检查如上所述的概要信息，以快速识别未来需要明确处理和监控的意外和相关变化。

8 将通知传递给具有所有权和责任的团队

许多公司一开始都是将所有数据质量警报发送到 Slack 或微软团队中的一个频道。然而，该频道的用户将不得不忽略许多他们可能不感兴趣的提醒。单一频道还可以减少处理单个警报的责任，因为它们很容易丢失在茫茫噪声之中。最佳实践与之相反，是为单个团队建立独立的频道。

在每个团队频道中，你可以把那些依赖或维护该频道中涉及到的表的用户加进来。当警报到来时，他们可以使用表情符号来表示他们对警报的反应。

示例：在 Slack 或微软团队中，用来表示对警告常见反应的表情符号。

常见的反应包括：

• ✅问题已解决

• 🔥重要警告

• 🛠️正在进行修复

• 🆗预期行为，没有必要理会

• 👀正在审查

或者用户可以 @同事来诊断和解决底层的问题。

9 为问题提供有效的上下文以便快速归类

当警报发生时，收到这样的信息很令人无奈：

column user_id in table fact_table has NULL values

这个警告应该让用户回答以下问题：

• 为什么这个警报很重要?

• 什么受 user_id 的影响，会受到多大程度的影响?

• 在最近看来，这个警报失败了多少次?

• 谁配置了这个警报，为什么配置它?

• 哪些仪表板或 ML 模型依赖于 fact_table?

• 将 user_id 贡献到 fact_table 的原始数据源是什么?

通知应该直接包含这些信息，或者链接到相应的数据目录平台。除此之外，通知还应该包含一些能够突出好坏值特征的原始数据样本：

比较好行和坏行 (时间戳值为空)。

高级的统计方法可以分析底层数据并产生根本原因分析，从而准确地识别问题发生的位置。

上图是一个识别数据段 (在本例中是 venuestate = ’ NY ') 的根因分析示例，它清楚地标识出底层数据质量问题发生在何处。

10 收集用户反馈并从中学习

无论如何，你的数据质量解决方案难免会发出一些无用的警报。在这些情况下，收集反馈就很重要了。

一个用于提供警告反馈的按钮示例。

随着时间的推移，可以使用机器学习调整数据质量监控解决方案，以废止用户认为无用的警报。为了有效地监控数据，你的系统应该产生全面、有针对性和准确的警报。

总结

首先，确保最小化假阳性警报。将静态测试转换为更智能的动态测试，以适应你的数据。确保用户可以调整警报优先级，订阅他们关心的通知。默认情况下只检查最新数据，并使规则易于修改。

其次，应减少误报带给用户的负担。将类似的问题聚集在一起，并提供准确的警报。使用 API 集成来防止坏数据继续通过管道传递。然后确保你的系统能够根据用户的反馈进行调整。

最后，使你的测试策略尽可能全面，这样你就不会错过真正的数据质量问题 (假阴性)。使用动态测试和用户友好的界面使用户很容易就能配置警报。利用行级无监督监视来扫描其他警报遗漏的问题。

综合这些解决方案，可以确保警报的质量、用户的工作效率和参与性，日积月累，你所依赖的数据质量会不断提高。

原文链接：

https://blog.anomalo.com/effective-data-monitoring-8bce3ddf87b4

译者简介：

冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。