数据管道速查手册

第 9 章. 维护管道的最佳做法

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

到目前为止，本书一直专注于构建数据管道。本章将讨论如何在复杂性增加时维护这些管道，以及如何应对管道所依赖的系统不可避免的变化。

处理源系统中的更改

对于数据工程师来说，最常见的维护挑战之一就是如何应对这样一个事实，即他们从系统中获取的数据并不是一成不变的。 开发人员总是在对软件进行修改，要么增加功能，要么重构代码库，要么修复漏洞。当这些变化对要摄取的数据的模式或含义带来修改时，管道就会面临失败或不准确的风险。

正如本书通篇所讨论的，现代数据基础架构的现实情况是，数据从大量不同的来源摄取。因此，很难找到一个放之四海而皆准的解决方案来处理源系统中的模式和业务逻辑变更。尽管如此，我还是建议投资一些最佳实践。

引入抽象

只要有可能，最好在源系统和摄取流程之间引入一层抽象层。 同样重要的是，源系统的所有者必须维护或了解抽象方法。

例如，与其直接从 Postgres 数据库中获取数据，不如考虑与数据库所有者合作，建立一个 REST API，从数据库中提取数据，并可通过查询进行数据提取。 即使应用程序接口（API）只是一个直通接口，但它存在于由源系统所有者维护的代码库中，这意味着系统所有者知道正在提取哪些数据，而不必担心其Postgres应用数据库的内部结构会发生变化。如果他们选择修改数据库表的结构，则需要对应用程序接口进行修改，但无需考虑其他代码可能会依赖于该应用程序接口。

此外，如果源系统的变更导致支持的 API 端点所包含的字段被移除，那么就可以就如何处理做出明智的决定。也许这个字段会随着时间的推移而被逐步淘汰，或者支持历史数据，但今后将不再支持。无论是哪种情况，只要有明确的抽象层存在，就会意识到需要处理变化。

REST API 并非抽象的唯一选择，有时也并非最佳选择。通过 Kafka 主题发布数据是一种 极佳的方式，既能维护商定的模式，又能将发布事件的源系统和订阅事件的系统（摄取）的具体情况完全分开。

维护数据合同

如果您必须直接从源系统的数据库或通过某种非明确设计用于提取的方法摄取数据，那么创建和维护数据合约是管理模式和逻辑变更的一种技术含量较低的解决方案。

数据合同

数据合同是源系统所有者与从该系统获取数据用于数据管道的团队之间的书面协议。合同应说明正在提取哪些数据、通过哪种方法（全量、增量）、多长时间提取一次，以及谁（个人、团队）是源系统和数据摄取的联系人。数据合同应存储在知名且易于查找的位置，如 GitHub repo 或内部文档网站。如果可能，以标准化的形式格式化数据合同，以便将其集成到开发流程中或通过编程进行查询。

数据合同可以文本文件的形式编写，但最好是标准化的配置文件，如例 9-1 所示。在这个示例中，从 Postgres 数据库的表中摄取数据的数据合约是以 JSON 格式存储的。

例 9-1. orders_contract.json

{ ingestion_jobid: "orders_postgres", source_host: "my_host.com", source_db: "ecommerce", source_table: "orders", ingestion_type: "full", ingestion_frequency_minutes: "60", source_owner: "[e-mail]", ingestion_owner: ...