数据管道过去遵循严格的顺序：从源系统提取数据，将其转换为干净的结构化格式，然后将成品加载到数据库中。在存储昂贵且目标系统不够强大、无法进行繁重计算时，这种顺序（提取、转换、加载或 ETL）是有意义的。
但云数据仓库改变了这一切，ELT（提取、加载、转换）成了许多分析团队现在的默认模式。虽然传统的 ETL 保持着近 40% 的市场份额，但它正迅速输给 ELT 等其他数据管道类型。
下面，我们将讨论什么是 ELT，它是如何工作的，以及它适用和不适用的场景。
要点
ELT（提取、加载、转换）流程首先将原始数据加载到云数据仓库中，然后再对其进行转换。这让分析师能够更快地访问数据，并更灵活地改进模型。
云数据仓库非常适合 ELT，因为它们将存储与计算分离，可弹性增长，并允许分析师使用结构化查询语言 (SQL) 编写转换逻辑。
与直接同步到您的数据仓库而不通过第三方基础设施路由的支付服务商合作，可降低管道复杂性和安全风险。
什么是 ELT，它的工作原理是什么？
ELT（提取、加载、转换）是一种围绕三个步骤构建的数据集成模式：从源系统提取数据，将其原始数据加载到中央目标位置，然后在目标位置内对其进行转换以用于分析、报告或机器学习。
以下是典型的 ELT 工作流在实践中的运行方式：
提取： 连接器或管道作业从源系统拉取记录（以增量方式、按计划或由事件触发），并以其原始结构将它们写入目标位置。
加载： 原始表落在数据仓库中，通常在专用模式下，准确地保留了数据源中存在的字段名称、数据类型和关系。
转换： 转换逻辑在数据仓库内运行，由于使用了基于 SQL 的工具（如 dbt），团队可以控制这些模型的版本、对其进行测试，并在原始层之上构建数据集。
由于原始数据首先落地，分析师可以立即查询它，并且可以从单一数据源构建多个下游视图，而无需再次提取。如果转换模型有误，您可以重写它，并针对数据仓库中已有的数据重新运行它。
在实践中，ELT 与 ETL 有何不同？
ETL 和 ELT 之间的核心架构差异在于转换发生的位置：在 ETL 中是在目标位置之外，在 ELT 中是在目标位置之内。
以下是 ETL 和 ELT 之间最大的差异：
为什么 ELT 适合现代云数据仓库？
以下特性使 ELT 成为云数据仓库的理想选择：
存储和计算分离： Snowflake 和 BigQuery 等平台对存储数据和查询数据分别扣款。您可以存入任意数量的原始数据，而转换作业仅在运行时消耗计算资源。
弹性扩展： 您可以创建所需的计算资源，运行作业，然后再次将其缩减。数据仓库负责处理并行化。
列式存储： 云数据仓库以列格式存储数据，这使得分析查询（跨大型数据集的聚合、筛选、联接）比基于行的存储快得多。
原生 SQL： 大多数分析师和分析工程师已经了解 SQL。在数据仓库内运行转换意味着了解商家逻辑的人员可以直接编写并拥有转换模型。
什么时候适合使用 ELT？
ELT 并不是每个数据管道的正确答案，但它适用于一组特定的条件。
以下是 ELT 通常运作良好的情况：
大型或快速增长的数据集： 如果您每天同步数百万个事件，则在加载之前运行转换需要大量管道基础设施。在数据仓库内加载原始数据并进行转换在大规模应用中更为实用。
频繁更改的转换逻辑： 如果转换作为 SQL 模型存在于数据仓库中，则更新分析要求不需要重新部署管道基础设施。
多个下游用例： 数据仓库中的原始数据可以同时馈送给商业智能管理平台、机器学习特性库和运营报告。您只需构建一条管道，然后为每个用户以不同方式对数据进行建模。
具有分析工程能力的团队： ELT 将转换的所有权转移到分析层。使用 dbt 等工具的团队非常适合这种模式。
ELT 在以下情况下不太适用：
对原始数据的监管限制： 一些医疗保健和财务数据环境禁止在屏蔽或过滤敏感数据之前将其落地。在这些情况下，转换需要在上游进行。
严格的目标模式： 如果您的目标位置无法容纳原始或半结构化数据，ELT 的“先加载”方法带来的问题将比它解决的还要多。
小型且稳定的数据集： 如果简单的 ETL 管道就能完成任务，那么添加数据仓库转换基础设施就是徒增开销，而没有太大好处。
ELT 会带来哪些挑战？
将原始数据存储在数据仓库中功能强大，但这可能会带来治理和成本方面的挑战。
请考虑 ELT 的这些潜在挑战。
访问控制
原始表通常包含不应被广泛访问的数据，例如个人身份信息 (PII)、财务记录或内部标识符。在 ETL 中，敏感字段可以在数据到达目的地之前被屏蔽或删除。但在 ELT 中，数据首先落地。如果没有行级安全、列屏蔽或严格限定的数据仓库角色，分析师就可以查询他们本不应该看到的字段。
数据质量
来自上游数据源的糟糕数据会在运行任何检查之前进入您的数据仓库。如果您没有使用 dbt 的测试框架或数据仓库原生的数据质量功能在转换层中建立质量测试，空字段、重复记录、模式更改和类型不匹配可能会传播到下游模型中。
成本管理
转换作业在数据仓库计算资源上运行，编写糟糕的 SQL（例如无限制扫描、缺少分区过滤器或冗余的全表刷新）可能会产生高昂的成本。从一开始就值得在您的工作流中设置查询成本限制、尽可能使用增量模型以及监控计算用量。
ELT 工作流如何处理支付数据？
许多团队针对其支付服务商的应用程序编程接口 (API) 构建自定义集成，或者使用第三方连接器。但自定义集成需要随着 API 的更改而进行持续维护，而第三方连接器意味着需要通过其他供应商的基础设施路由敏感财务数据。
Stripe Data Pipeline 是直接内置在 Stripe 管理平台中的原生选项。只需点击几下，它即可将 Stripe 数据和报告同步到 Snowflake、Databricks、Amazon Redshift 等。它采用无代码方式，无需配置连接器，也无需管理单独的凭据。同步使用 Stripe 自有基础设施运行，因此在传输过程中没有第三方系统处理您的财务数据。
一些值得了解的具体细节：
历史覆盖范围： Stripe Data Pipeline 包含从您的 Stripe 账户开始使用的历史数据，而不是从您启用同步的那一刻起的数据。
模式： 数据落入镜像 Stripe 数据模型（例如收款、客户、订阅）的表中，这使得在其之上构建转换模型变得简单直接，而无需进行大量的原始层清理。
数据完整性： 除了原始对象数据外，Stripe Data Pipeline 还包括对预构建财务报告和精选数据集的访问，这可以加速报告并减少常见用例（如 MRR (每月经常性收入) 和欺诈分析）的转换工作。
本文中的内容仅供一般信息和教育目的，不应被解释为法律或税务建议。Stripe 不保证或担保文章中信息的准确性、完整性、充分性或时效性。您应该寻求在您的司法管辖区获得执业许可的合格律师或会计师的建议，以就您的特定情况提供建议。