如果您正在构建数据管道以为商业智能工具提供数据或训练机器学习模型，您需要做出的最早决策之一是转换发生的位置：在数据进入您的仓库之前还是之后。这意味着您必须在提取、转换、加载 (ETL) 和提取、加载、转换 (ELT) 管道之间做出选择。

这一选择决定了分析师访问原始数据的速度、您在何处投入了多少计算资源，以及当您的数据模型发生变化时您进行调整的难易程度。预计到 2030 年，全球数据管道工具市场的价值将达到 483.3 亿美元，而 ETL 正逐渐落后于 ELT 和其他类型的管道。

在下文中，我们将探讨每种模型的工作原理、何时选择 ETL 或 ELT 更为合理，以及专用连接器如何针对特定数据源融入这两种方法。

要点

• ETL 在数据到达目的地之前对其进行转换。ELT 会加载原始数据并利用数据仓库自身的计算资源在其内部进行转换。

• ELT 是大多数现代数据团队的默认模式。ETL 在受限的目的地、严格的治理要求以及传统管道中仍然很受欢迎。

• 针对特定数据源的专用连接器可以降低通用连接器有时会引入的数据质量问题的风险。

ETL 与 ELT 管道：有何区别？

ETL 代表“提取、转换、加载 (extract, transform, load)”。在 ETL 模型中，您从源系统提取数据，通过转换层运行它，清理、重塑并过滤它，然后将处理后的结果加载到目标位置，例如数据仓库或数据集市。

使用 ETL 时，一个单独的独立处理引擎会在数据到达目的地之前完成繁重的工作。仓库收到的是结构化数据，准备好进行查询，而不是原始数据记录。从源端重新处理意味着需要重新提取，或在其他地方维护一份单独的原始副本。

ELT 代表“提取、加载、转换 (extract, load, transform)”，倒转了后两个步骤。原始数据首先落在目标位置，然后利用数据仓库自身的计算能力在仓库内运行转换。

当云数据仓库使通过大型数据集运行结构化查询语言 (SQL) 转换变得廉价且快速时，这种转变变得非常实用。您的数据仓库成为了转换环境，而不是存在于源和目标之间的独立转换引擎。

ETL 是如何工作的？

ETL 管道分三个阶段运行，每个阶段都有不同的责任。

以下是 ETL 的工作原理：

• 提取： 连接器或提取作业从源中提取数据，例如数据库、支付应用编程接口 (API)、软件即服务 (SaaS) 平台或平面文件。此步骤处理身份验证、分页、增量与完全刷新逻辑以及速率限制。

• 转换： 提取的数据进入处理层，在那里得到清理（例如，处理空值、类型转换）、重塑（例如，连接、聚合、列重命名）、过滤，有时还会用来自其他源的参考数据进行丰富。

• 加载： 处理后的数据集作为完全覆盖、更新插入或追加加载到目标位置，具体取决于管道的配置方式。

在以下特定情况中，使用 ETL 仍然是明智的选择：

• 受限目标： 计算受限的旧版数据仓库或本地系统无法就地高效运行大型转换，因此加载预先转换的数据是唯一可行的选择。

• 严格的治理要求： 某些组织需要确保个人身份信息或敏感财务数据绝不以原始形式落入仓库。在上游进行转换和脱敏可以从架构上满足该要求。

• 边缘环境： 将数据推送到中央基础设施的物联网 (IoT) 和嵌入式系统通常无法发送大型原始负载，这使得传输前的本地转换成为一种实际的必要。

• 旧版管道债务： 许多成熟组织拥有可靠运行多年的 ETL 管道。将它们重建为 ELT 带有风险，这可能不值得冒险。

ELT 是如何工作的？

ELT 管道提取原始或轻度格式化的源数据并将其直接加载到目标。转换在之后运行，按计划或按需激活，并使用数据仓库自身的计算能力。

例如，连接器可以从源中提取数据并将其写入数据仓库中的原始架构中。一位分析工程师编写数据构建工具 (dbt) 模型，读取该原始架构，应用业务逻辑并创建商业智能 (BI) 工具可以查询的清理后的表。当需要更改逻辑时，他们只需更新模型并针对已经存在的数据再次运行即可。

ELT 之所以是一个明智的选择，原因如下：

• 更快访问原始数据： 数据很快就会到达仓库，因此团队可以在转换层完成之前开始探索和验证数据。

• 更低成本的改进： 在 ETL 中更改转换通常意味着修改管道、重新处理并重新加载。在 ELT 中，您只需更新 SQL 模型并针对已经拥有的数据再次运行即可。

• 仓库规模的计算： 云数据仓库旨在快速处理大型数据集，这意味着您正在将强大的计算能力应用于转换，而不是独立增加一个单独的中间件层。

• 完整的原始历史记录： 因为原始数据始终在数据仓库中，所以您可以重新从头推导出任何下游表，这在业务定义发生变化或您必须调试数据质量问题时非常重要。

如何在 ETL 和 ELT 之间做出选择？

大型组织通常会针对不同来源并行运行这两种数据处理模型。您组织的需求将帮助您决定哪种方法是最合适的。

以下是您需要考虑的事项。

数据量和速度

大容量、高频的数据通常更适合 ELT 数据管道。云仓库能够很好地处理此类数据，并且在上游运行繁重的转换引擎的成本增长极快。作为权衡，当转换任务繁重时，您的仓库计算账单也会增加，并且存储原始数据也会带来成本。

具有稳定、明确转换逻辑的低容量管道可以继续使用 ETL，而不会遇到太多困难。

转换所有权

如果您的转换基于 SQL 并且由需要快速适应的分析工程师负责，那么结合使用 dbt 或类似工具的 ELT 可能是更好的选择。

如果您的转换是使用 Python 或 Java 编写的，并且由数据工程团队负责，那么 ETL 可能会自然地融入您现有的工具链中。

原始数据访问

如果分析师需要访问原始源数据（例如，用于临时探索、审计，或者因为转换逻辑仍在开发中），ELT 默认是更好的选择。不保留原始数据的 ETL 管道很难在后期提供这种访问能力。

治理和监管合规

如果在到达共享目的地之前必须对特定数据进行脱敏或匿名化处理，ETL 可以通过架构为您强制执行该要求。

ELT 可以通过列级安全性和仓库级访问控制来满足许多相同的要求，但具体实现方式有所不同，值得对照您的监管合规义务进行评估。

团队工作流

与维护他们没有参与构建的自定义 ETL 管道相比，精通 SQL 且具有围绕 dbt 进行版本控制习惯的团队将从 ELT 设置中获得更多价值。与团队工作方式的兼容性是一个合理的考量因素。

数据连接器如何融入 ETL 和 ELT 管道？

通用的 ETL 和 ELT 工具通过可配置的连接器处理各种来源。这种广泛性很有用，但也需要权衡。

支付数据就是一个很好的例子。Stripe 的数据模型涵盖事件、扣款、退款、争议、余额交易、客户、订阅和账单。一个跟不上 Stripe API 版本控制或错误处理增量同步逻辑的通用连接器可能会产生难以捕获的错误，直到它们影响到管理平台或财务对账。

Stripe Data Pipeline 直接解决了这个问题：

• 由 Stripe 构建和维护： 因为 Stripe 拥有该连接器并直接镜像内部 Stripe 基础设施，所以您可以持续可靠地同步数据，同时确保完整性和准确性——无论您有多少数据且没有 API 速率限制。

• 直接与数据仓库同步： 数据移动到 Amazon Redshift、Snowflake、Databricks 等，无需通过第三方连接器路由，这使得敏感财务数据远离其他供应商基础设施。

• 完整的 Stripe 数据集： 同步涵盖 Stripe 对象、预构建的财务报告以及精选数据集，以加速分析和报告。

• 轻量级设置： 连接在 Stripe 管理平台中配置，无需代码。如果您已经为其他源运行 ELT 管道，Stripe 数据可以顺畅地融入同样的模式。