大多数团队需要大量数据，您可以信任、查询和使用这些数据，而无需理清混乱的导出结果、字段不匹配或半损坏的管理平台。除了移动数据外，提取、转换和加载管道还能将数据转化为可大规模使用且不会出现意外问题的数据。2024年，全球估计创建、捕获、复制和消费了 149 ZB 的数据，因此，拥有一个能够简化数据处理的管道非常重要。

以下是一份指南，介绍了 ETL 管道的工作原理、其重要性以及如何设计一个能够随业务扩展的管道。

本文内容

• 什么是 ETL 管道？
  
• ETL 管道如何工作？
  
• 为什么商家需要使用 ETL 管道？
  
• ETL 有哪些常见挑战，您如何解决这些挑战？
  
• 如何设计一个可扩展的 ETL 管道？
  

什么是 ETL 管道？

ETL 管道是将原始数据转化为可用数据并实现迁移的系统。此缩写代表以下含义：

• 提取 (Extract)： 从源系统拉取数据。
  
• 转换 (Transform)： 清理提取的数据并重新格式。
  
• 加载 (Load)： 将数据输送至集中目的地（如数据仓库）。
  

实际上，ETL 管道从支付平台、产品数据库和网络分析工具等来源收集数据。系统会对这些数据进行处理（清理数据、统一格式并整合系统），然后将最终产品推送到可用的地方，例如用于报告、管理平台或建模。

提取、加载和转换 (ELT) 是什么？

传统上，ETL 管道会在将数据加载到仓库之前对其进行转换。但如今，随着计算速度更快、存储成本更低，许多团队都使用 ELT——首先加载原始数据，然后在仓库内进行转换。

ELT 的操作顺序不同，但其目的与 ETL 相同：将数据集中迁移到一个地方，并使其处于可用状态。

ETL 管道如何工作？

ETL管道主要分为提取、转换和加载三个阶段，但这一过程很少是整齐划一的线性流程。一个构建良好的管道会持续运转，管理不同的数据批次，协调依赖关系，并在最后一批数据处理完成前就提供见解。

以下是每个阶段的具体情况：

提取

提取方法基于系统而异。速率限制和延迟决定了 API 的处理节奏。对于生产数据库，团队通常使用增量提取，仅拉取自上次运行以来已更改的数据，以最大程度地减少负载。管道首先从它所在的位置拉取数据。

数据来源可能包括：

• 关系数据库（如 PostgreSQL、MySQL）
  
• 通过 API 从 CRM 系统、支持软件和支付服务商等工具获取的 SaaS 平台数据
  
• 平面文件、日志、云存储桶或文件传输协议 (FTP) 服务器
  

转换

这是管道的核心部分，通常也是最复杂的部分。提取后，数据会进入暂存环境进行处理。转换阶段可能涉及：

• 数据清理： 删除损坏的行，删除重复的记录，并填充缺失值。
  
• 数据标准化： 统一格式和单位（如转换时间戳、匹配货币代码）。
  
• 数据合并： 将跨来源的信息整合起来（例如，将 CRM 系统中的用户记录与 支付系统的交易历史记录进行匹配）。
  
• 字段衍生： 计算新指标或应用业务逻辑（例如，根据行为模式标记“流失风险”客户）。
  

您可以使用结构化查询语言 (SQL) 和 Python 等编程语言或通过 Apache Spark 等转换引擎执行这些步骤，具体取决于数据的大小和范围。最终得到的是符合业务数据模型和分析目标的整洁、结构化的数据集。

加载

数据转换后，即可将其移动到最终目的地，这可能是：

• 云数据仓库（如 Amazon、BigQuery）
  
• 数据湖
  
• 报告数据库
  

数据加载方式取决于您的目标。有些团队会持续追加新记录，而另一些团队则会插入或更新行以保持表格的最新状态。全表交换或分区覆盖是常见的数据审查方法。

高效的管道会以批量或大容量模式处理加载，尤其是在处理大规模数据时。这有助于减少写入冲突、避免性能瓶颈，并以可预测的格式为下游系统提供可用数据。

并行处理

在成熟的管道中，这些阶段并不是严格按序执行的。相反，它们是错开且并行执行的：例如，在对周一提取的数据进行转换时，周二的数据提取就可以开始了。

这种管道能保持高吞吐量。但这也可能带来一些复杂问题：如果中途某个环节出现故障，您需要了解是哪个阶段出现了问题，以及如何在不破坏数据流的情况下恢复。

编排

Apache Airflow、Prefect 和云原生服务（如 AWS Glue）等编排程序可管理这些阶段。它们负责协调：

• 任务依赖关系： 确定哪些任务先运行，哪些任务后运行。
  
• 调度安排： 确定每个阶段的启动时间（如每小时、每天，或基于触发事件）。
  
• 故障处理： 当任务停滞或中断时，提供后续处理步骤。
  
• 资源管理： 确定计算任务在哪里运行以及同时运行多少个任务。
  

如果没有编排，ETL 就会变得脆弱并且需要手动干预。有了编排，数据基础设施将变得更加可预测和可靠。

为什么商家需要使用 ETL 管道？

许多商家表示其自身以数据为驱动。但真正的挑战在于，将正确的数据整合到一个统一的位置，并使其处于商家可用的状态。ETL 管道为团队提供了一种可靠的方法，用于收取、清理和组合来自整个商家的数据，以便将其用于分析、报告、预测、人工智能、审计或投资者更新。

以下是商家投资 ETL 管道的原因：

创建跨系统的统一视图

默认情况下，数据是碎片化的。销售数据可能真实存在于您的客户关系管理 (CRM) 系统中。交易通过您的支付平台进行。产品使用情况记录在日志文件中。每个系统都只讲述了故事的一部分。

ETL 管道从这些来源提取原始数据，协调重叠字段（如客户 ID），并将清理后的统一版本加载到中央数据仓库中。例如，软件即服务 (SaaS) 业务可能会使用 ETL 管道来整合产品使用情况、支持工单和账单数据，以便在一个地方监控账户健康状况。

这种整合视图不仅能提升决策质量，更是回答“哪些营销活动带来了高价值客户？”等多源问题的唯一途径。

提高数据质量

原始数据可能很混乱。不同的系统使用不同的格式，应用不一致的标签，或者包含重复项和间隙。

ETL 管道设定了最低质量标准。它们在将数据发送到分析师或高管使用的软件之前，会清理脏记录、规范类别和格式，并应用业务规则。这可以减少临时修复的次数、减少关于字段不匹配的问题，并增强对数据内容的信心。

实现手动工作流程自动化

如果没有 ETL，团队通常依赖导出、电子表格和脚本，这些工具在有人更新字段名时可能会失效。这种方法速度很慢，而且无法扩展。

ETL 管道可自动执行这些工作流程。它们按计划或事件运行，以可重复的方式移动数据，并且无需人工监视整个流程。

支持扩展和复杂性

随着业务的发展，数据量也会随之增长。这意味着更多的客户、事件和系统。手动整合数据将难以为继。

ETL 管道专为扩展而设计。它们可以处理大量数据、并行运行，并随着新来源和用例的出现而进行调整。

为更好的分析和决策提供动力

管理平台和 AI 模型的质量取决于为其提供数据的质量。如果管道出现问题，分析也会受到影响。

ETL 管道可确保决策者获得及时、值得信赖的数据。这包括：

• 每周收入
  
• 客户流失趋势
  
• 不同细分市场的产品性能
  
• 实时欺诈信号
  

Stripe Data Pipeline 允许商家自动将支付和财务数据推送到平台，而无需自己构建和维护管道。

管理风险并保持合规

当数据（尤其是敏感数据）在系统之间移动时，会存在安全漏洞、违反法规和不一致的访问控制等风险。

借助 ETL 管道，商家可以拥有更多控制权。它们可以：

• 在处理过程中屏蔽或加密敏感字段
  
• 记录访问和转换以进行审计
  
• 将数据集中在安全控制等级更高的环境中
  

这些任务使遵从 欧盟通用数据保护条例 (GDPR) 和 健康保险流通与责任法案 (HIPAA) 等数据保护规则变得更加容易，并降低了丢失敏感数据的风险。

ETL 有哪些常见挑战，您如何解决这些挑战？

ETL 管道很重要，但它们却并不简单。其复杂性源于所涉及的真实数据、系统和业务逻辑。但是，只要采用正确的架构和习惯，就能解决大多数问题。

以下是 ETL 最常见的问题以及解决方法：

数据质量问题

如果源数据不一致或有缺陷，即使管道运行完美，仍可能产生低质量的结果。

为什么会发生这种情况

• 系统间的格式或代码冲突（如“CA”与“California”）。
  
• 存在重复项、缺失值或格式错误的条目。
  
• 下游字段是根据上游错误计算得出的。
  

有什么解决方法

• 在管道中构建数据验证环节（而非将其作为最后一步）。
  
• 为异常值或意外的空值设置阈值和警报。
  
• 定义何为“干净”数据的规则，并记录下来。
  
• 隔离不良数据行，而非直接丢弃。
  

复杂转换

有些转换很容易，而有些转换则很快变得复杂，尤其是在合并数据源或应用多步骤逻辑时。

为什么会发生这种情况

• 业务规则发生变化、叠加，或未得到充分记录。
  
• 跨系统联接需要处理大量的边缘情况。
  
• 如果转换未经过优化，性能会下降。
  

有什么解决方法

• 将转换拆分为可测试、调试和重用的模块化步骤。
  
• 使用版本控制来跟踪逻辑随时间的变化。
  
• 如果可能，将繁重的计算转移到分布式引擎，或将它们推送到数据仓库。
  
• 像对待生产代码一样对待转换代码：进行同行评审、测试和监控。
  

性能和可扩展性瓶颈

处理百万条记录时运行良好的管道，在处理千万条记录时可能会停止运行，或完成时间过长。

为什么会发生这种情况

• 某些流程本可以并行运行，但却以串行方式运行。
  
• 系统在输入/输出 (I/O)、中央处理器 (CPU) 或内存方面达到限制。
  
• 代码逐行处理数据，而不是批量处理数据。
  
• 重复的完整提取使源系统过载。
  

有什么解决方法

• 设计适合您的并行处理方式：按日期、区域和客户 ID 进行分区。
  
• 尽可能使用增量加载，而不是完整刷新。
  
• 将繁重的处理任务卸载到灵活的系统（如分布式计算、自动扩展仓库）。
  
• 定期分析管道性能，并优化最慢的步骤。
  

源码系统过多，缺乏标准化

每个新来源都会增加难度：API 不同，字段名称冲突，有些源每分钟发送一次数据，而有些源则每周发送一次。

为什么会发生这种情况

• 许多业务系统不是为集成应用而设计的。
  
• 源格式不一致（如 CSV 导出、API、旧数据库）。
  
• 团队在缺乏协调的情况下以不同的方式拉取数据。
  

有什么解决方法

• 尽可能采用标准化的提取方法 - 使用共享连接器或集中式摄取工具。
  
• 隔离每个源的逻辑（使用单独的模块或脚本），以便于维护。
  
• 在管道早期对字段命名和元数据进行标准化。
  
• 尽可能使用变更数据捕获 (CDC)，仅同步更新数据。
  

安全与监管合规风险

移动敏感数据时，尤其是客户或财务信息，会产生风险。您的管道必须考虑 加密、隐私规则和审计跟踪。

为什么会发生这种情况

• 系统不必要地提取敏感字段。
  
• 临时存储未得到保护。
  
• 没有记录谁在何时访问了哪些数据。
  

有什么解决方法

• 在转换过程中屏蔽或加密敏感数据。
  
• 限制对暂存区域的访问，并应用基于角色的控制。
  
• 使用安全的协议进行提取和传输。
  
• 维护审计日志，并支持根据请求进行删除或编辑。
  

维护债务和管道偏移

随着源模式和业务定义的变化以及任务悄然失败，管道需要持续关注。

为什么会发生这种情况

• 管道缺乏可观察性，因此问题被忽视。
  
• 没有人负责管道的日常维护。
  
• 逻辑是硬编码，且没有记录。
  

有什么解决方法

• 将管道视为动态基础设施：存储多个版本、受监控且可测试。
  
• 添加日志记录、指标和健康检查。
  
• 使用编排软件来跟踪依赖关系和重试操作。
  
• 为常见故障编写运行手册 - 不要依赖内存。
  

正确的做法可以缓解这些挑战，并防止它们成为反复出现的紧急情况。它们还将帮助您构建透明、可维护且具有足够弹性、能够随业务发展的管道。

如何设计一个可扩展的 ETL 管道？

真正的考验在于，当数据量增长 10 倍，您的 商业模式发生变化或新增 3 个系统时，ETL 管道能否保持高效运转。灵活的管道可以吸收这种变化，而不会中断、减慢或变得过于复杂。

以下是构建可扩展管道的方法：

以增长为设计前提

扩张性意味着要为更多情况做好准备：

• 数据源
  
• 数据量
  
• 需要访问权限的团队
  
• 监管开销
  

考虑一下，如果这条管道需要支持 10 倍的数据量或填充 5 个新的管理平台，哪些部分可能会首先出现问题。构建时要设计足够的容量，这样您就不会在六个月后被迫进行高成本的重建了。

采用支持扩展的架构

有些管道从一开始就注定要失败，因为它们依赖于无法横向扩展的系统或流程。为了避免这种情况，应该：

• 选择能在多台机器上并行运行任务的处理引擎
  
• 使用能够分离存储和计算，并能独立扩展两者的数据库或数据仓库
  
• 采用批量加载或分区写入，而非逐行操作
  

如果管道的任何部分使一台机器达到性能极限，那么这就是瓶颈所在。

设计并行处理

并行处理是减少运行时间、提升处理能力的关键所在。串行管道或许会让人感觉安全，但速度缓慢。如果您一次只处理一个文件、一个客户或一个地区的数据，那么无论您的基础设施多么强大，吞吐量都会受到限制。相反，您应该：

• 按逻辑单元（如日期、区域、客户 ID）对数据进行分区
  
• 在依赖项允许的情况下，同时运行提取、转换和加载步骤
  
• 使每个阶段都无状态化，以便多个实例并行运行
  

利用云弹性

云 基础设施可轻松扩展 ETL，无需过度配置。您可以：

• 在需求高峰时自动扩展计算能力
  
• 使用对象存储服务进行暂存，无需担心容量问题
  
• 让托管 ETL 服务处理繁重的资源分配工作
  

在小问题变得紧急之前加以改进

在扩展方面，细微的选择会产生很大的影响。建议采取以下措施：

• 使用列式文件格式（例如 Parquet）暂存数据，以加快读写速度
  
• 压缩大文件，减少 I/O 耗时
  
• 编写高效的 SQL 查询，避免不必要的转换
  
• 对任务进行性能分析，尽早发现瓶颈
  

保持管道模块化

模块化的管道更易于扩展、测试和故障排除。它们在组织层面和技术层面都具备可扩展性。当需要新增数据源或修改转换规则时，您不必拆解 2,000 行的庞杂代码。相反，您应该：

• 将管道分解为逻辑阶段（如摄取、处理、加载）
  
• 封装转换，以便独立更新或重新利用
  
• 清晰地记录输入、输出和依赖关系
  

构建可见性

随着管道的扩展，了解其内部运行情况的需求也随之增加。您看不到就无法修复或 扩展。确保您：

• 监控任务运行时间、行数、错误率和新鲜度
  
• 设置故障和阈值警告
  
• 跟踪数据血源，以便团队了解数据的来源和变化方式
  
• 记录每一步的事件，并提供足够的上下文以快速调试问题
  

良好的可见性可以让您自信地进行扩展。