流行的分析数据验证技术以及您需要它们的原因

已发表: 2022-12-19

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

归根结底，您的数据分析需要像任何其他代码一样进行测试。如果您不验证此代码及其生成的数据，其成本可能很高（根据 Gartner 的数据，每年的成本高达 970 万美元）。

为避免这种命运，公司及其工程师可以利用多种主动和被动数据验证技术。我们强烈推荐前者，我们将在下面解释。主动的数据验证方法将帮助公司确保他们拥有的数据是干净的并且可以使用。

反应式与主动式数据验证技术：在数据问题成为问题之前解决它们

“一盎司的预防胜过一磅的治疗。” 这句老话几乎在任何情况下都是正确的，包括用于分析的数据验证技术。另一种说法是，积极主动比被动被动更好。

任何数据验证的目的都是确定数据可能不准确、不一致、不完整甚至缺失的地方。

根据定义，反应式数据验证发生在事后，并使用异常检测来识别您的数据可能存在的任何问题，并帮助缓解不良数据的症状。虽然这些方法聊胜于无，但它们并没有从一开始就解决导致不良数据的核心问题。

相反，我们认为团队应该尝试为他们的分析采用主动的数据验证技术，例如类型安全和模式化，以确保他们获得的数据准确、完整且符合预期的结构（并且未来的团队成员没有与糟糕的分析代码作斗争）。

虽然选择更全面的验证方法似乎很明显，但许多团队最终还是使用了反应式数据验证。这可能有多种原因。通常，分析代码是许多非数据团队的事后想法，因此未经测试。

不幸的是，未经任何验证就处理数据也很常见。此外，糟糕的分析代码只有在非常糟糕时才会被注意到，通常是在几周后有人注意到报告严重错误甚至缺失时。

反应式数据验证技术可能看起来像使用 dbt 或 Dataform 等工具转换仓库中的数据。

虽然所有这些方法都可以帮助您解决数据问题（并且通常使用客观上很棒的工具），但它们仍然无法帮助您解决不良数据的核心原因（例如，在项目中实施的零碎数据治理或分析 -没有跨团队沟通的项目基础），让你每次都回到他们身边。

仅仅反应性数据验证是不够的；您需要采用主动数据验证技术才能真正有效并避免前面提到的代价高昂的问题。原因如下：

数据是一项团队运动。 确保您的数据干净不仅仅取决于一个部门或一个人。它需要每个人共同努力，以确保高质量的数据并在问题发生之前解决问题。
数据验证应该是软件开发生命周期 (SDLC) 的一部分。 当您将它集成到您的 SDLC 中并与您现有的测试驱动开发和自动化 QA 流程并行时（而不是事后添加它），您可以通过预防数据问题而不是稍后解决问题来节省时间。
主动数据验证可以集成到您现有的工具和 CI/CD 管道中。 这对您的开发团队来说很容易，因为他们已经投资于测试自动化，现在可以快速扩展它以增加分析的覆盖范围。
主动数据验证测试是快速移动的团队高效运作的最佳方式之一。 它确保他们可以快速迭代并避免数据漂移和其他下游问题。
主动数据验证让您有信心根据需要更改和更新代码，同时最大限度地减少以后必须解决的错误数量。 此主动流程可确保您和您的团队仅更改与您关注的数据直接相关的代码。

既然我们已经确定了主动数据验证的重要性，下一个问题是：您如何做到这一点？团队使用哪些工具和方法来确保他们的数据在问题出现之前是好的？

让我们开始吧。

数据验证方法

数据验证不仅仅是在特定点发生的一个步骤。它可能发生在数据生命周期的多个点——客户端、服务器、管道或数据仓库本身。

它实际上在很多方面非常类似于软件测试。但是，有一个关键区别。您不是在单独测试输出；您还确认您的数据输入是正确的。

让我们看一下每个位置的数据验证情况，检查哪些是被动的，哪些是主动的。

客户端中的数据验证技术

您可以使用 Amplitude Data 等工具来利用类型安全、单元测试和 linting（静态代码分析）进行客户端数据验证。

现在，这是一个很好的起点，但重要的是要了解这种工具使您能够在这一层进行什么样的测试。这是一个细分：

类型安全是指编译器在源代码中验证数据类型和实现指令，防止由于拼写错误或意外变量而导致的下游错误。
单元测试是指您单独测试特定选择的代码。 不幸的是，大多数团队在验证他们的分析时并没有将分析集成到他们的单元测试中。
A/B 测试是指您针对黄金状态数据集（您认为完美的分析版本）或生产数据副本测试分析流程。 这可以帮助您确定您所做的更改是否有效以及对现有情况的改进。

管道中的数据验证技术

管道中的数据验证就是确保客户端发送的数据与您仓库中的数据格式相匹配。如果两者不在同一页面上，您的数据消费者（产品经理、数据分析师等）将无法从另一端获得有用的信息。

管道中的数据验证方法可能如下所示：

模式验证以确保您的事件跟踪与模式注册表中定义的内容相匹配。
在 dbt 等工具中通过关系、唯一和代理键实用程序测试进行集成和组件测试，以确保平台之间的跟踪正常运行。
通过 dbt 之类的工具进行新鲜度测试，以确定您的源数据有多“新鲜”（也就是它的最新和健康程度）。
使用 Great Expectations 等工具进行分布式测试，以便在数据集或样本与预期输入不匹配时收到警报，并确保对跟踪所做的更改不会弄乱现有数据流。

仓库中的数据验证技术

您可以使用 dbt 测试、Dataform 测试和 Great Expectations 来确保发送到您的仓库的数据符合您期望和需要的约定。您还可以在此层进行转换，包括在这些转换中进行类型检查和类型安全，但我们不建议将此方法作为您的主要验证技术，因为它是被动的。

此时，团队可用的验证方法包括验证数据是否符合某些约定，然后对其进行转换以匹配它们。团队还可以使用 dbt 进行关系和新鲜度测试，以及使用 Great Expectations 进行价值/范围测试。

所有这些工具的功能都归结为这一层的一些关键数据验证技术：

确保CRUD数据和转换符合既定约定的模式化。
安全测试以确保数据符合 GDPR 等安全要求。
在 dbt 等工具中进行关系测试，以确保一个模型中的字段映射到给定表中的字段（也称为参照完整性）。
新鲜度和分布测试（正如我们在管道部分中提到的）。
范围和类型检查，确认从客户端发送的数据在仓库的预期范围或格式内。

通过深入研究 Lyft 的发现和元数据引擎 Amundsen，可以找到其中许多测试的一个很好的例子。该工具允许公司的数据消费者搜索用户元数据，以提高其可用性和安全性。 Lyft 确保数据质量和可用性的主要方法是通过图形清理 Airflow 任务进行版本控制，当新数据添加到他们的仓库时，该任务会删除旧的重复数据。

为什么现在是采用更好的数据验证技术的时候了

过去，数据团队在数据验证方面苦苦挣扎，因为他们的组织没有意识到数据卫生和治理的重要性。那不是我们生活的世界了。

公司已经意识到数据质量至关重要。仅仅以一种被动的方式清理坏数据是不够的。雇佣数据工程师团队通过转换或编写无休止的 SQL 查询来清理数据是一种不必要且低效的时间和金钱使用。

过去，80% 的数据准确度是可以接受的（取舍取决于用例），而留有 20% 的误差范围。这对于简单的分析可能没问题，但对于驱动产品推荐引擎、检测异常或制定关键业务或产品决策来说还不够好。

公司聘请工程师来创造产品并完成出色的工作。如果他们不得不花时间处理不良数据，那么他们就没有充分利用时间。但是数据验证让他们有时间重新专注于他们最擅长的事情：为组织创造价值。

好消息是高质量的数据触手可及。为实现这一目标，公司需要打破数据生产者和数据消费者之间的孤岛，帮助每个人了解其价值。然后，公司应该扔掉电子表格并在他们的分析中应用更好的工程实践，例如版本控制和模式化。最后，他们应该确保整个组织都遵循数据最佳实践，并制定跟踪和数据治理计划。

投资于主动分析验证以获得数据红利

在当今世界，反应式、隐式数据验证工具和方法已经远远不够了。它们会耗费您的时间、金钱，也许最重要的是信任。

为了避免这种命运，拥抱积极主动的哲学。通过从开始和整个软件开发生命周期验证您的分析数据，在问题成为代价高昂的问题之前识别问题。