追求高数据质量的经验教训：一篇反思性文章

Source: Dev.to

封面照片作者 Claudio Schwarz 于 Unsplash

介绍

在深入探讨之前，让我们先讨论一下数据质量的含义。IBM 对此的阐述非常到位：

数据质量衡量数据集在准确性、完整性、有效性、一致性、唯一性、及时性以及适用性方面满足标准的程度，它对组织内所有数据治理计划至关重要。

数据质量不仅关注数据是否洁净，还关注其是否适用于预期的用途——这意味着数据质量是具有情境性的。数据收集和使用的领域与其他检查同样重要。在许多情况下，它为定义准确性、有效性、一致性、及时性和唯一性的检查提供了基础。此外，数据质量可以在团队内部建立或破坏信任。

这是一篇反思性的文章，概括了我在制定保持高质量数据的路线图时的经验。以前有人问及数据质量的强制执行和实现，我总是回答“我们可以使用某个工具或技术来实现”。实际操作中，我猛然意识到这种回答的局限性。

为了提供更好的背景，设想这样一种情形：一组技术娴熟的数据分析师和科学家被要求在给定的时间窗口（月份、周、天等）内为同一产品计算相同的指标。结果是每个人得出了不同的数值。这些不一致削弱了信任，而任何数据过程的输出都依赖于可信度。这一点很重要，因为如果人们对同一指标得到不同的数字，那么问题就变成了：“收集的数据质量好吗？我们在处理过程中引入错误了吗？”

正是在这一点上，我意识到数据质量并非仅关乎工具。它涉及必须具备的关键要素，以实现数据产品的有效交付。我将这些要素归类为 三个主要要素——流程、人员和技术——它们需要和谐共作。下面的章节将对每个要素进行展开说明。

人员

只要数据将被多于一个人读取和解释，就必须考虑 人员 要素。虽然这看起来像是后期活动，但在任何工作流中——无论是自动化、常规还是临时的——尽早处理它都是至关重要的。

为了使其实际可行，数据质量始于对所提出请求的理解。所有利益相关者在交付任何分析时必须实现知识的自由流动。例如，当高级管理者询问“产品 A 的第 3 天留存率是多少？”时，不要立即编写花哨的 SQL 或 Python 脚本，而是先提出澄清性问题，例如：

• 您指的是经典留存还是滚动留存？
• 对于全球产品，您是否需要显示地区模式的地区留存？
• 留存率是否应以 UTC 24 小时周期来衡量，等等？

这些问题要么让您明确到底需要计算什么，要么为做出假设提供余地。总体而言，生成的数据及其解释的质量取决于人员之间的有效沟通。在分析师和工程师协同工作的团队中，必须将清晰的定义记录下来并随时可用，以产生可靠的下游数据。

Source: …

技术

工具清单不断增长。使用 Great Expectations、Amazon Deequ、SODA 等工具，以及嵌入平台的解决方案（如 DBT 中的验证规则、AWS Glue Data Quality 等），数据质量检查在技术上已经是一个可解决的问题。唯一值得探讨的问题是成本、团队能力以及与现有技术栈的最佳匹配——本质上是工具评估过程中出现的标准。

这些工具能够很好地创建数据应包含内容的有效定义。它们提供的典型功能包括以一致的方式：

• 创建数据质量期望
• 存储检查结果
• 向利益相关者报告结果

此外，将数据处理和分析工作视为软件开发实践已成为常态。编写可维护、可读且模块化的代码已成为促进协作和延长寿命的必要条件，而不是奢侈。使用 Git 等版本控制系统是实现这一目标的不可或缺的前提。

Process

我们已经看到，和谐合作的人们在对齐期望方面发挥了关键作用。我认为 process 是围绕人和技术的包装。好的流程促进人们与工具之间的无缝互动，以实现定义的目标。

例如，一组数据工程师和分析师可能使用 Write‑Audit‑Publish (WAP) 模式定义工作流，在审计层进行数据质量和验证测试。因此，任何数据产品在通过所有定义的测试之前都不会发布。大型数据集也可能有利用快速失败机制的初步检查。

构建有效的流程并不总是直截了当：

• 步骤过多 会使实现目标变得繁琐。
• 步骤过少 可能缺乏足够的稳健性，无法定义安全边界和指南，以实现一致、可持续的结果。

一个好的流程在两者之间取得平衡，可能需要多次迭代才能达到这种平衡。

结论

仅凭工具就能实现数据质量的说法很诱人，但如果没有合适的流程，工具就会变得无用；如果没有合适的人才以及坚持维护结构的承诺，流程也很容易被规避。这才是关键所在。

技术、流程和人员未能协同工作，会导致任何组织或项目的数据质量框架脆弱。进一步来说，上述理念可能不被视为数据质量，而是数据治理的一个方面。数据合约背后的概念也与这些原则高度一致。

总体而言，数据治理、数据合约、数据质量框架或组织内部对其的任何称呼的精细落地，都将依赖于这些以及更多因素。