数据管道是一个自动化系统，它将数据从源系统移动到分析目的地。它为依赖数据运行的企业解决了一个常见问题：如何处理和分析散落在许多不同系统中的有用信息。管道能够可靠、重复地移动数据。
在下面，我们将解释数据管道是什么、它如何工作、批处理与流处理方法的区别，以及支付数据如何融入管道设置。
要点
数据管道取代了在压力下容易中断的手动导出和临时流程。
批处理和流处理管道的选择取决于您需要的数据的新鲜度。财务和分析工作负载通常很适合运行批处理。
在管道设置中，支付数据需要特别小心。从支付服务商原生的同步可以提高安全性和可靠性。
为什么数据管道对报告和决策至关重要？
数据管道的价值在于，当您的数据集中存放于可用之处时，一切将变为可能。数据管道会带来以下好处：
减少数据孤岛： 当您的数据分散在不同系统中时，例如，收入数据保留在您的支付服务商处，客户数据保存在您的客户关系管理 (CRM) 系统中，而支持数据存放在帮助中心内，您将很难回答跨越这些边界的问题。集中这些来源的管道可以实现跨职能分析。
统一定义： 管道可以强制执行结构化。如果每个团队都从相同的、经过同样计算的仓库表格中提取数据，那么如月度经常性收入 (MRR) 这样的指标在各报告中便具有统一定义——并且不会对谁的数据正确产生争论。
可重复、可审计流程： 管道日复一日地产生可比较的结果。这种可重复性使跟踪长期指标并在异常出现时调查异常成为可能。
更快的报告周期： 以前财务团队要花费数天时间提取并核对数据，当数据已经在仓库中清理和结构化后，他们可以大幅缩短这个周期。
数据管道的核心组件是什么？
许多管道，无论复杂程度如何，都是由相同的构建块构建的。以下是重要的组件：
来源： 数据的起源，包括数据库、软件即服务 (SaaS) 应用程序编程接口 (API)、事件流和平面文件。管道提取的来源越多，跟踪每个来源的模式、可靠性以及更改频率就越重要。
摄取： 从源头提取数据进入管道的机制。这可能意味着预定的数据库查询、对 webhook 流的订阅或第三方连接器。摄取通常是管道中断的地方（例如，API 更改、凭证过期、来源失败），因此建立良好的摄取层可以检测并从失败中恢复。
转换： 将原始数据重塑成有利于分析的形式的步骤。例如，转换清理记录并删除重复项、连接来自多个来源的数据、计算衍生字段或在天然不共享一致模式的跨系统中强制执行统一模式。
编排： 管理依赖和调度的层面。如果表 B 依赖于表 A 完全加载，那么编排层需要知道这一点并强制执行顺序。诸如 Apache Airflow、Prefect 和 data build tool (dbt) 之类的工具可以处理这种依赖管理。
目的地： 处理后的数据落地的位置。通常，这会是像 Snowflake 或 Redshift 这样的云数据仓库，或者是像 S3 或 Google Cloud Storage (GCS) 这样的云存储。目的地的选择决定了下游可能进行什么样的分析。
批处理和流处理管道有什么区别？
对于数据移动，流处理和批处理都有合法的用途。正确的选择取决于您的数据在导致真正问题之前可以有多陈旧。
批处理管道
它们按计划（例如，每小时、每晚、每周）移动数据。它们非常适合对延迟要求不高的工作负载，如月度财务报告、每周客户同期群分析以及每晚同步到数据仓库。批处理系统的构建和运行通常更简单。并且，对于许多分析使用场景而言，它正是您所需要的。
流处理管道
这些管道连续处理数据，在事件发生时处理，其延迟以秒或毫秒衡量，而不是以小时衡量。它们专为基于过时数据进行操作会带来实际成本的用例（如欺诈检测、实时库存跟踪和实时仪表板）而构建。
在选择这种数据移动路径之前，请先评估团队的实力。流媒体基础设施更昂贵且更难调试。如果您的数据团队很小，那么流式管道的开销可能会抵消其延迟优势。
数据管道、ETL 和 ELT 之间有何关系？
数据管道是任何将数据从源移动到目的地的自动化系统，而提取、转换和加载 (ETL) 以及提取、加载和转换 (ELT) 则是构建这种移动方式的两种模式。以下是它们的运作机制。
ETL
ETL 意味着数据在加载到目的地之前被转换。转换发生在一个中间层，这样只有被清洗过、格式化的输出才会到达仓库。当存储昂贵且仓库不适合处理大规模原始数据时，这是主导模式。
ELT
在 ELT 中，后面的步骤是反向的。首先将原始数据提取并加载到数据仓库中，然后再在那里使用结构化查询语言 (SQL) 或类似 dbt 的工具进行转换。现代云仓库价格低廉，足以存储原始数据；也足够强大，可以在查询时或作为计划任务对数据进行转换。由于它保留了用于重新处理的原始数据，并使转换更易于审计、版本控制和修改等部分原因，ELT 已成为分析工作负载的一种更为常见的模式。
并非每条管道都能整齐地归入其中一类。有些管道几乎不进行任何转换来移动数据；它们将原始事件日志从 API 同步到云存储以便以后处理。这些术语可作为架构意图的速记而非精确的分类法。
支付服务商如何融入数据管道设置？
支付数据往往是公司数据仓库中最有价值、最复杂的数据之一。团队在尝试管理它时，通常会经历相同的发展过程。
逗号分隔值 (CSV) 导出
许多团队从 CSV 导出开始。他们下载报告，进行清理，然后上传到仓库。但是导出会中断，模式会改变，或者有人忘记运行流程。这通常会导致历史数据缺失或不一致。
第三方 ETL 连接器
接下来，他们转向一些工具，这些工具可以从支付 API 中提取数据，并按计划加载到仓库中。这些工具相当可靠，但会在敏感数据流中引入供应商。如果团队有流经额外第三方系统的财务数据，这不仅扩大了攻击面，产生了监管合规方面的考虑，还会生成与其支付服务商所持数据可能存在细微差别的数据。
通过 Stripe Data Pipeline 原生同步
Stripe Data Pipeline 支持直接同步到 Stripe，无需第三方连接器即可将数据移动到仓库或云存储目的地。只需点击几下即可完成设置，无需代码，且该管道包含来自用户 Stripe 账户的历史数据。它还包括精选综合报告和定制数据集，例如结构化财务摘要和支持分析的表格，以分析 MRR、欺诈等。这些由 Stripe 自己的系统生成，通用连接器无法复制。
本文中的内容仅供一般信息和教育目的，不应被解释为法律或税务建议。Stripe 不保证或担保文章中信息的准确性、完整性、充分性或时效性。您应该寻求在您的司法管辖区获得执业许可的合格律师或会计师的建议，以就您的特定情况提供建议。