数据摄取是每个数据管道的第一步。它是指从源系统收集数据并将其移动到可进行查询的仓库、数据湖或分析平台的流程。

当数据摄取失败时，您会得到过时的管理平台、中断的对账以及在不完整数据上训练的机器学习模型。更糟糕的是，糟糕的数据可能会影响您的底线。超过 25% 的组织报告称，由于数据质量差，他们每年损失 500 万美元或更多。

下面，我们将仔细研究什么是数据摄取、主要的数据摄取模式、推动大多数管道投资的用例，以及团队面临的挑战。

要点

• 数据摄取将数据从源系统移动到可以存储和查询的目标位置。商家选择的模式决定了该数据的新鲜程度。

• 可靠的摄取取决于两件事：完整性（即应有的所有记录都在那里）和及时性（即数据在第一个人需要它之前到达）。

• 现代支付服务商可以将数据直接同步到 Snowflake、Redshift 和 Amazon S3 等目标位置。这使得商家无需自定义工程或第三方连接器供应商即可访问其完整的交易历史记录。

数据摄取是指从源系统提取数据并将其加载到可进行存储、查询和使用的目标位置的流程。它将数据馈送到数据仓库、数据湖和分析平台。

在支付环境中，数据摄取可能涉及从不同来源收集数据，包括销售点 (POS) 系统、电子商务网站和支付网关。

数据摄取的主要类型有哪些？

您的数据需要多新鲜，以及过时数据在失去用处之前可以保留多久，决定了哪种数据摄取方法最适合您的商家。

以下是要考虑的主要方法。

批量摄取

批量摄取按计划提取数据并批量移动。延迟通常为几小时或几天，这对于许多工作负载来说是可以接受的。财务结算、每周的高管报告以及历史趋势分析（例如流失分析）通常都可以使用此类数据。

流式摄取

流式摄取在事件产生时就对其进行处理，从而将延迟降至几秒或更短。基础设施的要求更高——您通常使用诸如 Apache Kafka 或云原生的等效系统，而且您的消费者应用程序需要处理乱序事件和至少一次的交付。当数据的价值需要欺诈信号、实时库存和实时个性化时，这通常是正确的选择。

变更数据捕获

变更数据捕获 (CDC) 读取源数据库的交易日志，并仅发出已更改的内容，在没有重复全表读取开销的情况下实现分钟级的延迟。它在复杂性和新鲜度方面介于批量和流式之间，当您需要来自关系系统的近实时 (NRT) 准确性时，它特别有用。

常见的数据摄取用例有哪些？

数据摄取的存在是为了服务下游的某个流程。您选择的模式在很大程度上取决于数据的使用方式。

以下是常见的数据摄取用例：

• 商业智能 (BI) 报告： 收入、转化率、流失率和支持量被馈送到团队每天检查的管理平台中。摄取新鲜度决定了该数据的最新程度。

• 财务报告： 月末和季度末的结算取决于降落在一个能够让财务运行其查询的仓库里的完整、准确的交易数据。在这里，完整性和新鲜度同样重要。

• 客户和产品分析： 行为事件数据与客户关系管理 (CRM) 和交易数据相结合，可为产品和增长团队提供全貌。摄取连接了这些源系统，并使得组合数据集能够被查询。

• 欺诈监控： 基于 12 小时前的数据做出的决策通常是基于无关数据做出的决策。欺诈检测是流式或近实时 CDC 值得额外付出的用例之一。

• 机器学习： 训练管道需要大量的历史数据；推理管道需要新鲜特征。摄取可服务于两者：批量摄取可用于训练集，而较低延迟的模式可用于特征存储。

好的数据摄取是什么样的？

当数据既完整又按时到达时，分析师可以停止怀疑他们的数字，也不必在每次报告之前运行对账检查。

好的数据摄取保证了完整性。所有应该存在的记录都在那里。精心设计的摄取层可处理去重、回填缺口，并在迟到记录成为报告错误之前将其捕获。

数据也会在需要时到达。这并不总是意味着越快越好：它意味着数据在用户需要之前就已就绪。

数据摄取面临的主要挑战有哪些？

数据摄取看起来很简单，直到您在多个源系统中运行它。以下数据摄取挑战总是会带来麻烦。

安全性和数据暴露

通过摄取基础设施移动敏感数据（例如：金融交易、个人身份信息、支付记录）会在每个节点产生暴露风险。通过第三方提取、转换、加载 (ETL) 连接器路由支付数据的团队，等于让该供应商访问其完整的交易历史记录。这是否可接受取决于供应商合同、监管合规要求和风险承受能力。

扩大规模

数量随着时间的推移而复合增加。源系统中的架构更改可能会以并不总是立即显现的方式破坏管道。分区策略、增量加载和架构演变处理是需要在它们成为事件之前加以考虑的工程问题。

碎片化

在许多组织中，摄取是无组织的，而不是一个经过刻意设计的系统。假设数据团队为 Salesforce 构建了一个连接器，而工程团队为生产数据库构建了一个单独的连接器，财务部门有一个逗号分隔值 (CSV) 导出文件，有人在每周一上传。结果就是产生重复、不一致的数据管道，这些管道难以监控，更难以信任。

质量失败

管道有时会以明显的方式中断：作业出错，或者管理平台变为空白。但失败也可能被隐藏。例如，上游的架构更改可能会删除一列，然后下游的表开始丢失数据，或者 API 速率限制可能会导致看起来完整的部分加载。如果没有检查行数、值范围和引用完整性的监控，您只有在出现足够严重的损坏引起注意时才会知道。

数据摄取与 ETL 和 ELT 有何不同？

数据摄取、ETL 和 ELT 描述了同一管道中重叠的部分，但它们的含义不同。

• 数据摄取： 它是将数据从源系统移动到目标系统的操作。它涉及传输和交付。它不考虑数据在传输过程中是否发生变化。
  
• 提取、转换、加载 (ETL)： 这是一种架构，即从源提取数据，在中间环节进行转换（历来在专用的转换工具或暂存服务器中进行），然后以最终可供查询的形式加载到目标位置。转换发生在数据到达目标位置之前。
  
• 提取、加载、转换 (ELT)： 也是上述架构，只是最后两个步骤相反。原始数据首先落入数据仓库，然后在那里使用结构化查询语言 (SQL) 或数据构建工具 (dbt)等工具进行转换。随着云数据仓库变得足够便宜和强大，能够大规模运行繁重的转换操作，这种方法变得切实可行，且现在已成为现代数据技术栈的主导模式。
  

支付服务商如何帮助实现数据摄取？

Stripe Data Pipeline 是一项从 Stripe 到您的仓库或云存储目标位置的直接同步服务，无需中介。它适用于现有的 Stripe 用户，并连接到 Snowflake、Redshift 和 Databricks 等目标位置。设置不需要编写代码或配置连接器。

以下是 Stripe Data Pipeline 如何帮助实现数据摄取的：

• 数据新鲜度： 同步持续运行，大多数数据在底层事件发生后的几小时内即可用。

• 历史数据： 关联后，您可以访问完整的 Stripe 历史记录，而不仅仅是自关联之日起的数据。

• 数据完整性： Stripe Data Pipeline 包含预构建的财务报告（例如提现对账和余额摘要），以及针对常见用例（如月度经常性收入 (MRR) 和欺诈分析）的精选数据集。第三方供应商无法同步这些数据源，需要手动导出或重建数据。

• 减少供应商暴露风险： 由于同步是从 Stripe 直接到您的仓库，因此您的支付数据不会经过第三方供应商的基础设施。