数据管道速查手册

第 8 章 管道中的数据验证 管道中的数据验证

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

即使是设计最完善的数据管道，也难免会出错。 如果流程、协调和基础架构设计得当，很多问题都可以避免，或至少可以减轻。但是，为了确保数据本身的质量和有效性，您需要对数据验证进行投资。最好假设未经测试的数据不能安全地用于分析。本章将讨论 ELT 管道各步骤中的数据验证原则。

尽早验证，经常验证

尽管初衷是好的，但一些数据团队还是将数据验证留到了管道的末端，并在转换过程中或甚至在所有转换完成后实施某种类型的验证。在这种设计中，他们认为数据分析师（通常拥有转换逻辑）最适合理解数据并确定是否存在任何质量问题。

在这种设计中，数据工程师专注于将数据从一个系统转移到另一个系统、协调管道和维护数据基础架构。虽然这是数据工程师的职责所在，但有一点是缺失的：由于忽略了流经管道中每一步的数据内容，他们将信任寄托在了源系统的所有者、自己的摄取流程以及转换数据的分析师身上。虽然这种责任分离听起来很高效，但很可能会导致数据质量低下，以及在发现质量问题时调试过程效率低下。

在流水线的末端发现数据质量问题，不得不追溯到起点是最糟糕的情况。通过在流水线的每个步骤进行验证，您更有可能在当前步骤而不是之前的步骤中找到根本原因。

虽然不能指望数据工程师掌握足够的上下文来对每个数据集进行验证，但他们可以通过编写非上下文验证检查以及提供基础架构和模板来发挥带头作用，使那些更接近管道中每个步骤的团队成员和利益相关者能够执行更具体的验证。

源系统数据质量

鉴于有大量源系统被导入到典型的数据仓库中，在数据导入过程中，无效数据很可能会在某些时候进入仓库。虽然源系统所有者似乎会在录入之前发现某种无效数据，但通常情况并非如此，原因有以下几点：

无效数据可能不会影响源系统本身的运行

源系统应用程序的逻辑可能会通过在应用程序层进行重复数据复制来解决表中重复/模糊记录等问题，或者在应用程序本身中使用默认值来填充 NULL 日期值。

当记录成为孤儿时，源系统可能运行正常

例如，一条Customer 记录可能会被删除，但与该客户相关的Order 记录可能会保留下来。虽然应用程序可能会忽略这些Order 记录，但这种情况肯定会对数据分析产生影响。

尚未发现或修复的错误可能实际上存在于源代码系统中

在我的职业生涯中，遇到过多次数据团队发现源系统中存在关键问题的情况！

备注

无论原因如何，底线是数据工程师绝不能假定他们正在获取的数据不存在质量问题，即使最终加载到仓库中的数据完全符合其来源。

数据输入风险

除了源系统的质量问题外，数据摄取过程 本身也可能导致数据质量问题。下面是一些常见的例子：

摄取的提取或加载步骤中出现系统中断或超时

虽然有时这种情况会导致严重错误并停止管道，但在其他情况下，"无声 "故障会导致部分提取或加载数据集。

增量摄取中的逻辑错误

回顾第 4章和第 5章中的增量提取模式。从数据仓库中的表中读取最新记录的时间戳，然后提取源系统中时间戳更近的记录，以便将它们加载到仓库中。一个简单的逻辑错误，如在 SQL 语句中使用了 "大于或等于 "运算符而不是 "大于"，都可能导致重复记录被录入。还有许多其他可能性，例如各系统的时区不一致。

提取文件中的解析问题

正如第 4章和第 5 章所述，典型的做法是从源系统中提取数据，存储在 CSV 等平面文件中，然后从该文件加载到数据仓库中。当数据从源系统翻译成平面文件时，有时会包含特殊字符或其他意外的字符编码。根据数据工程师和数据仓库加载机制处理此类情况的方式，记录有可能被丢弃，或者新加载的记录中包含的数据可能是畸形的。 ...