为什么数据团队在数据验证方面苦苦挣扎（以及如何改变它）

已发表: 2022-12-19

编者按：本文最初发表于 2020 年 12 月 18 日的 Iteratively 博客。

你知道那句老话，“垃圾进，垃圾出”吗？很有可能，您可能听说过与数据卫生相关的短语。但是你如何解决糟糕的数据管理和质量问题呢？好吧，这很棘手。特别是如果您无法控制跟踪代码的实施（许多数据团队就是这种情况）。

然而，仅仅因为数据主管不拥有从数据设计到提交的管道并不意味着所有的希望都破灭了。作为数据消费者（即产品经理、产品团队和分析师）和数据生产者（工程师）之间的桥梁，您可以帮助开发和管理数据验证，从而全面改善数据卫生。

在我们进入杂草之前，当我们说数据验证时，我们指的是帮助数据团队维护其数据质量的过程和技术。

现在，让我们看看为什么数据团队会为这种验证而苦苦挣扎，以及他们如何克服这些挑战。

首先，为什么数据团队在数据验证方面苦苦挣扎？

数据团队在分析数据验证方面苦苦挣扎的三个主要原因：

他们通常不直接参与事件跟踪代码的实施和故障排除，这使得数据团队处于通常没有围绕分析数据验证的标准化流程，这意味着测试受制于不一致的 QA 检查。
数据团队和工程师依赖于反应式验证技术而不是主动数据验证方法，这并不能解决核心数据卫生问题。

这三个挑战中的任何一个都足以让最好的数据主管（以及支持他们的团队）感到沮丧。原因是有道理的：质量差的数据不仅代价高昂——根据 IBM 的数据，不良数据平均造成3 万亿美元的损失。在整个组织中，它还削弱了对数据本身的信任，并导致数据团队和工程师浪费数小时的工作时间来消除错误。

这个故事的寓意是？当数据验证被搁置一旁时，没有人会赢。

值得庆幸的是，这些挑战可以通过良好的数据验证实践来克服。让我们更深入地了解每个痛点。

数据团队通常无法控制数据收集本身

正如我们上面所说，数据团队在数据验证方面遇到困难的主要原因是他们不是执行相关事件跟踪工具的人（充其量，他们可以看到存在问题，但他们无法解决问题).

这让数据分析师和产品经理，以及任何希望让他们的决策更加受数据驱动的人，都背负着事后理清和清理数据的任务。没有人——我们是说没有人——以消遣的方式享受数据处理。

对于大多数数据团队来说，这个痛点特别难以克服，因为除了工程师之外，数据名册上很少有人具备自己进行数据验证的技术技能。数据生产者和数据消费者之间的组织孤岛使这个痛点更加敏感。为了缓解这种情况，数据主管必须促进跨团队协作以确保数据干净。

毕竟，数据是一项团队运动，如果您的球员不能互相交谈、一起训练或集思广益以获得更好的结果，您将无法赢得任何比赛。

数据检测和验证没有什么不同。您的数据消费者需要与数据生产者合作，在源头实施和执行数据管理实践，包括测试，以便在任何人在下游执行处理任务之前主动检测数据问题。

这将我们带到下一点。

数据团队（及其组织）通常没有围绕分析的数据验证设置流程

您的工程师知道测试代码很重要。每个人可能并不总是喜欢这样做，但确保您的应用程序按预期运行是交付优质产品的核心部分。

事实证明，确保分析代码按预期收集和交付事件数据也是构建和迭代优秀产品的关键。

那么断开连接在哪里？测试分析数据的做法对于工程和数据团队来说仍然相对较新。很多时候，分析代码被认为是功能的附加组件，而不是核心功能。这一点，再加上乏善可陈的数据治理实践，可能意味着它只是零星地全面实施（或根本没有实施）。

简而言之，这通常是因为数据团队以外的人还不了解事件数据对他们日常工作的价值。他们不知道干净的事件数据是他们后院的摇钱树，他们所要做的就是定期浇水（验证）以赚取资金。

为了让每个人都明白他们需要关心事件数据这棵摇钱树，数据团队需要宣传在整个组织中可以使用经过充分验证的数据的所有方式。虽然数据团队可能在其组织内受到限制和孤立，但最终还是要由这些数据拥护者来打破他们与其他利益相关者之间的壁垒，以确保采用正确的流程和工具来提高数据质量。

为了克服数据管理的这种狂野西部并确保适当的数据治理，数据团队必须建立流程，明确说明何时、何地以及如何主动测试数据。这听起来可能令人生畏，但实际上，数据测试可以无缝地融入现有的软件开发生命周期 (SDLC)、工具和 CI/CD 管道。

为设计数据策略的数据团队以及实施和测试代码的工程团队提供清晰的流程和说明，将帮助每个人理解他们应该期望看到的输出和输入。
数据团队和工程师依赖于被动而非主动的数据测试技术
在生活的几乎每个方面，积极主动总比被动被动好。这也适用于分析的数据验证。
但是许多数据团队和他们的工程师感到被困在反应性数据验证技术中。如果没有使主动测试变得容易的可靠数据治理、工具和流程，事件跟踪通常必须快速实施和交付以包含在版本中（或在一次交付后追溯添加）。这些迫使数据主管及其团队在事后使用异常检测或数据转换等技术。
这种方法不仅不能解决坏数据的根本问题，而且会花费数据工程师数小时的时间来消除错误。它还会花费分析师数小时的时间来清理不良数据，并使企业因数据更好时可能发生的所有产品改进而损失收入。

数据主管必须帮助塑造数据管理流程，而不是处于持续的数据追赶状态，其中包括早期主动测试和具有护栏功能的工具（例如类型安全），以提高数据质量并减少下游返工。
那么，什么是主动数据验证措施？让我们来看看。
数据验证方法和技术
主动数据验证意味着在数据管道的每个阶段采用正确的工具和测试流程：
在客户端中使用 Amplitude 等工具来利用类型安全、单元测试和 A/B 测试。
在管道中使用诸如 Amplitude、Segment Protocols 和用于模式验证的 Snowplow 开源模式回购 Iglu 等工具，以及用于集成和组件测试、新鲜度测试和分布式测试的其他工具。
在仓库中使用 dbt、Dataform 和 Great Expectations 等工具来利用模式化、安全测试、关系测试、新鲜度和分布测试以及范围和类型检查。
当数据团队积极维护和执行主动数据验证措施时，他们可以确保收集的数据有用、清晰和干净，并且所有数据持有者都了解如何保持这种状态。

此外，围绕数据收集、处理和测试技术的挑战可能难以单独克服，因此领导打破数据团队和工程团队之间的组织孤岛非常重要。
如何更好地更改数据验证以进行分析
迈向分析的功能性数据验证实践的第一步是认识到数据是一项团队运动，需要来自各个级别的数据股东的投资，无论是您作为数据负责人，还是您的个人工程师实施跟踪代码行。
从客户到仓库，组织中的每个人都受益于良好的数据收集和数据验证。
要推动这一点，您需要三件事：
来自数据主管和公司领导层的自上而下的指导，建立在整个企业中维护和使用数据的流程
在公司的各个层面传播数据，以便每个团队了解数据如何帮助他们更好地完成工作，以及定期测试如何支持这一点
用于很好地管理数据的工作流和工具，无论是内部工具，混合工具（如 Segment Protocols 或 Snowplow 和 dbt），还是更好的内置分析平台（如 Amplitude）。 在所有这些步骤中，同样重要的是，数据领导者要尽早和经常地分享胜利并朝着伟大的数据迈进。这种透明度不仅可以帮助数据消费者了解他们如何更好地使用数据，还可以帮助数据生产者（例如，您的工程师进行测试）看到他们的劳动成果。这是双赢的。
克服数据验证难题
数据验证对数据团队来说很困难，因为数据消费者无法控制实施，数据生产者不理解为什么实施很重要，零敲碎打的验证技术让每个人都对不良数据做出反应，而不是阻止它。但它不一定是那样的。

数据团队（以及支持他们的工程师）可以通过共同努力克服数据质量问题，利用好数据的跨职能优势，并利用现有的强大工具来简化数据管理和测试。