ETL

ETL 代表提取、转换和加载，指的是从源系统中提取数据，将其转换为一致的结构，然后加载到目标位置（例如数据仓库）的过程。它是分析的基础架构，其可靠性决定了基于它构建的报表是否可信。

每个阶段都面临着不同的挑战。数据提取必须从原本并非设计用于外部查询的系统中获取数据，同时还要应对 API 速率限制、增量变更检测以及无法可靠识别变更内容的数据源。数据转换必须协调不一致的格式、不同的标识符、冲突的定义以及缺失值。数据加载必须处理海量数据、维护历史记录，并处理延迟到达或顺序错乱的记录。

ELT 变体反转了最后两个阶段，将原始数据加载到目标位置并在那里进行转换。这种做法已变得十分普遍，因为现代数据仓库平台拥有足够的处理能力，可以高效地进行原地转换，而且保留原始数据允许对转换进行修改和重新应用，而无需从源位置重新提取数据。这也意味着转换逻辑中的错误是可以恢复的，而不是永久性的。

增量处理是实际应用中的必然选择，但也正是它使大多数实现变得复杂。每次运行都重新处理所有历史数据固然简单，但随着数据量的增长，这种方法就变得难以维系。因此，数据管道必须能够识别自上次运行以来发生的变化。缺乏可靠变更时间戳的数据源、追溯更新的记录以及不留痕迹的删除操作，都使得这项工作比表面看起来更加困难；而错误的增量逻辑则会导致数据不完整且难以察觉。

故障处理机制决定了管道是否达到生产级别。管道经常会因为源系统更改模式、凭证过期、上游服务不可用或收到意外数据而发生故障。关键特性包括：能够立即检测到故障；部分运行不会导致目标系统处于不一致状态；重新运行能够产生相同的结果而不是重复记录；以及能够及时通知相关人员，而不是等到报告出现错误时才发现故障。

数据质量验证应该在数据处理流程内部进行，而不是在流程之后。通过检查行数是否符合预期、验证关键字段是否已填充、确认数值是否在合理范围内以及测试引用一致性，可以在数据入口处发现错误。如果没有这些测试，错误数据就会传播到报告和决策中，而且通常是在几周后，有人注意到某个不合理的数字时才发现。

调度和依赖关系管理决定了输出结果是否一致。流水线很少独立运行，下游作业如果在其上游源作业完成之前启动，则会产生看似完整但部分完成的结果。编排工具可以显式地表达这些依赖关系，而如果流水线不是通过声明的依赖关系而是通过时间假设来链接，则会间歇性地出现难以重现的故障。

文档和溯源至关重要，因为数据管道的寿命远超构建它们的人员。了解每个字段的来源、应用了哪些转换以及编码了哪些业务规则，对于解答“为什么某个数字是这个样子”以及评估更改源系统的影响都至关重要。缺乏文档记录的数据管道会变成无人敢修改的系统，这最终会导致组织内部出现多个并行管道，各自生成相互矛盾的数据。

因为可靠性而非复杂程度决定了最终交付的价值，所以应用于管道的工程规范应该与应用于生产软件的工程规范相匹配。实际上，管道的建设和运营是由…… 产品开发 或 IT部门转换逻辑编码业务定义由以下方式指定： 数据分析而且，验证规则最好在构建第一个管道之前就达成一致，而不是在发生第一个事件之后再添加。