数据质量监控

现场级别的深度数据监控

第一种“深度”数据监控器是 机器学习来生成预先配置的数据质量规则来验证表中的数据。当知道特定表中的一组字段很重要时，最好部署它们，但我们不确定它会如何中断。此类数据监视器可有效检测 当字段中的单个值为空、重复、格式错误或以其他方式损坏时发生的异常情况。它还可以识别指标偏离其正常模式的情况。

我们无需为这些类型的监控器预先配置规则和阈值——大多数监控解决方案将根据数据的历史趋势提供建议。但是，因为我们正在查询数据，所以它是计算密集型的。这使得在整个管道中扩展的成本高得令人望而却步，使它们最适合在高风险表上“深入”。

第二种监视器，用户定义的监视器在数据未通过指定逻辑时触发警报。用户定义的、机器学习驱动的监视器最好使用定义最明确、易于理解的逻辑来部署，以捕获频繁或严重的异常。它通常通过 SQL 语句表示。

换言之，这些数据监控器跟踪数据准确性、数据完整性以及对业务规则的总体遵守情况。例如，我们可能有一个永远不会为负数或 null 的指标，如发货时间，或者永远不会超过 100% 的关键表中的字段。它甚至可以帮助跟踪存储在一个表中的数据是否与存储在另一个表中的数据相匹配，或者我们的指标在多个细分和计算中是否一致。 

表级别的深度数据监控

在表级别，基于 ML 的数据监视器可以检测异常，例如新鲜度（该表是否在应该更新的时候更新？）和容量（行太多或太少？）。 

但同样，这种方法的成本太高，无法在所有管道中大规模部署，这使得这些监视器最好保留给一些关键资产。

窄而深的数据监控的局限性

当我们仅在最重要的表上部署用户定义和机器学习监视器时： 

• 我们错过或延迟检测和解决上游更明显的异常。 
• 在关键表上发出警报，通常会从根本原因中删除数十个处理步骤，这将涉及错误的人员，并且不会让他们了解问题的根源或如何解决问题。
• 如果不了解系统中的依赖关系，我们的团队将浪费时间试图确定将监控注意力集中在哪里。随着环境和数据消费模式的变化，保持这一点也可能很乏味且容易出错。

跨企业数据仓库的广泛元数据监控 

“广泛的”元数据监视器可以经济高效地跨环境中的每个表进行扩展，并且非常有效地检测新鲜度和容量 异常以及由 模式更改导致的异常（数据的组织方式是否发生了变化？）。

通过撒下更大的网，我们不仅可以捕捉到所有有影响的异常，还可以通过在更靠近事件源的地方捕捉它们来缩短检测和解决它们的时间。将异常追溯到上游的几层和人员，进行必要的回填，以及以其他方式解决事件，都是耗费时间和资源的。  

训练有素的模型、动态警报分组和精细警报路由确保警报疲劳不会成为问题。

跨堆栈的端到端集成和日志分析 

广泛的覆盖范围还需要端到端集成。如果不分析堆栈中每个组件的日志，我们就会对一个系统中的更改如何导致另一个系统中的异常视而不见。 

在装配线上，特斯拉不仅在 Model X 准备好向客户发货时实施质量控制。他们在沿途的每一步检查电池、发动机部件和车身。 

我们不应该在每个故障点检查我们的数据管道吗？这包括自动分析管道的 SQL 日志以了解代码和逻辑中的任何最新更改；气流日志以了解故障和延迟；和 dbt 日志以了解错误、延迟和测试失败。

经济高效且大规模地做到这一点的唯一方法是分析堆栈中的日志。这种方法既涵盖了我的所有故障点，又提供了额外的上下文来帮助我们防止未来的异常 

例如，在 BI 层分析日志可以识别下游用户和数据消费模式，帮助我们更有效地部署深度监视器。识别企业数据仓库中的日志可以自动评估数据健康的关键组成部分，例如恶化的查询或断开连接的表。 

监控的未来是端到端的数据可观察性

在一天结束时（或者更确切地说，管道的尽头），将深度监控与广泛的覆盖范围相结合，可为我们提供两全其美的优势：对数据环境的端到端可见性以及快速解决任何问题所需的工具确实出现了。