数据湖和数据仓库解决不同的问题。数据湖以原生格式廉价地存储原始数据，而数据仓库快速地提供精选数据。您单独或结合使用它们的方式会影响您的分析团队所能做的事情，而现代数据的规模使这个选择更加重要。2024 年，每天有 4.0289 亿 TB 的数据被创建、捕获、复制或消耗，每年加起来大约有 147 泽字节。

下面，我们将比较数据湖与数据仓库，解释它们在模式、成本、性能和治理方面的差异，以及如何为您的工作负载匹配正确的架构。

要点

• 数据湖使用读取时模式来灵活地存储原始数据，而数据仓库使用写入时模式来为商业智能 (BI) 和报告提供快速、一致的查询性能。

• 成熟的数据团队通常在分层架构中使用这两个系统，原始数据在数据湖中落地，精选数据流入数据仓库用于分析。

• 构建自己的管道这种传统的支付数据方法往往很脆弱，因为 API 模式更改可能会破坏管道。

什么是数据湖？

数据湖是一个以原始的、原生格式存储数据的集中式存储库。这包括结构化数据（表格）、半结构化数据（如 JavaScript Object Notation (JSON) 日志）和非结构化数据（文本、图像、视频）。

数据湖背后的决定性理想是读取时模式。数据完全按照产生时的样子落地，而在查询时，当有人知道他们试图回答的问题时，才会应用结构。这种灵活性使数据湖非常适合大规模提取和探索性分析。您几乎可以存储任何东西，而无需提前决定如何对其进行建模。

什么是数据仓库？

数据仓库是一个结构化的分析系统，专为快速、一致的查询而设计。

在数据落地仓库之前，通常会对其进行清理、转换和建模为优化用于分析的明确定义的方案。这种方法被称为写入时模式：结构和定义在数据被存储之前就确定下来了。其结果是一个精选的环境，分析师可以在其中运行查询、构建管理平台并计算指标，而无需担心不一致的格式或缺失的背景。

数据湖优先考虑灵活性，而数据仓库优先考虑分析的可靠性和性能。

数据湖与数据仓库之间的主要区别是什么？

数据湖和数据仓库之间的实际差异远不止于数据存储的位置。它们的结构方式、使用者身份以及查询成本也是关键的区别。

结构

数据湖存储原始数据，仅在运行查询时才应用结构。这种灵活性允许对同一数据集进行多种解释。数据仓库在写入数据时强制执行结构，因此查询订单的每个人都会看到相同的架构模式和定义。

查询性能

数据仓库专为交互式分析而构建。在 Snowflake 或 BigQuery 等系统中针对大型表的查询可以在几秒钟内返回结果。除非您投资了列式存储、分区和压缩等优化功能，否则在湖存储中查询原始文件可能会更慢且成本更高。

数据类型

数据仓库擅长处理用于报告和管理平台的结构化关系型数据。数据湖的适应性更强：它们可以存储原始日志、嵌套的 JSON、机器学习数据集、图像以及其他非关系型格式。

治理与信任

仓库数据通常经过验证和转换管道，这使其适合于业务报告。数据湖中的数据通常是原始数据和探索性数据，因此通常需要进行额外的处理，才能支持生产指标。

成本状况

在存储大量原始数据或不常访问的数据时，数据湖的成本要低得多。仓库每 TB 的成本更高，但提供更快的查询性能，并更好地支持高并发分析工作负载。

组织如何结合使用数据湖和数据仓库？

成熟的平台倾向于同时使用这两种系统，由每种系统处理其最适合的管道部分。通常，数据湖作为原始数据的着陆区，而仓库则向分析师和业务工具提供精选的、可用于分析的数据集。

一种常见的模式是 medallion 架构，其中包括：

• Bronze： 提取的原始数据

• Silver： 清理并去重的数据集

• Gold： 用于报告的汇总的业务就绪型表

在许多实现中，Bronze 和 Silver 数据位于湖存储中，而 Gold 数据集则由仓库提供。

这种分层架构的缺点在于其复杂性。数据会在各个系统之间复制，通过管道进行移动和转换，并且团队需要在多个地方管理治理和访问控制。组织正在尝试通过基于 Delta Lake、Apache Iceberg 或 Hudi 等技术构建的湖仓一体架构来简化这一过程。这些系统添加了传统上与仓库相关的功能，例如原子性、一致性、隔离性和持久性 (ACID) 事务以及强制执行架构模式，这些功能直接指向湖存储。

这允许团队使用一个平台而不是两个。它的效果如何取决于查询的复杂性以及运营团队的成熟度。

如何在数据湖和数据仓库之间做出选择？

正确的答案取决于谁在使用数据以及他们需要从中获取什么。通常，组织有多个具有不同需求的团队。

需考虑以下事项：

商业智能 (BI) 和报告团队

如果您的主要受众是使用 Looker、Tableau 或 Metabase 等工具构建管理平台的数据分析师，那么数据仓库通常是最好的基础。这些工具依赖于一致的模式、可靠的指标以及快速的查询响应。

数据科学和机器学习团队

训练模型通常需要原始的、大容量的数据集，例如事件流、文本、行为日志或其他复杂格式。数据湖提供了在数据成型为结构化表格之前存储和探索这些数据的灵活性。

大规模提取数据的工程团队

当系统每天生成数十亿个事件时，数据湖通常是最实用的第一个目的地。它更便宜，能很好地处理不断发展的模式，并且不需要上游系统符合预定义的数据模型。

混合工作负载

组织倾向于将两者结合起来：使用数据湖来提取和存储原始数据，使用数据仓库来提供精选数据集，并使用连接两者的转换层。在这种类型的设置中，问题在于每个系统在整体数据管道中的位置。

支付提供商如何适合您的数据湖或数据仓库架构？

传统的支付数据方法是使用应用程序编程接口 (API) 构建自己的管道来处理分页和速率限制，将结果写入存储无限期地维持集成。

这样做是可行的，但它很脆弱。API 模式更改可以破坏管道，历史回填需要额外的逻辑，并且支付数据包含敏感财务信息。这意味着将其通过其他第三方提取、转换和加载 (ETL) 供应商发送，会造成许多财务和监管合规团队感到不适的安全暴露。

Stripe Data Pipeline 直接解决了这些挑战。它由 Stripe 构建和维护的一个原生连接器，对现有 Stripe 用户可用，通过将 Stripe 数据（交易、客户、订阅、提现）直接同步到数据仓库或云存储目的地来工作。

与第三方连接器相比，原生方法有几个优点：

• 数据完整性：Stripe Data Pipeline 包含您账户的历史数据、预构建的财务报告和精选数据集，这些是第三方连接器通常不会公开或需要自定义配置才能展现的。

• 规模化可靠性：由于管道由 Stripe 本身维护，它会自动跟踪 API 更改、处理模式演变，并考虑到外部连接器有时会遗漏的 Stripe 数据模型中的边缘情况。

• 减少安全暴露：财务交易数据在 Stripe 和您的存储目的地之间移动，而无需通过中间供应商的基础设施，这简化了您的数据安全状况。

Stripe Data Pipeline 如何提供帮助

Stripe Data Pipeline 允许您将 Stripe 数据与其他业务数据结合起来，在数据仓库中进行相同的分析。Stripe Data Pipeline 和 Stripe Sigma 均由相同的底层 Stripe 数据驱动，但 Data Pipeline 让您轻松地结合其他数据集查看这些数据。

Stripe Data Pipeline 可以帮您：

• 直接同步至您的仓库
  数据移动至 Amazon Redshift、Snowflake 或 Amazon S3，无需通过第三方连接器路由，这使得敏感的财务数据远离其他供应商基础结构。

• 建立单一事实来源
  将您的 Stripe 数据集中在一个地方，以加速财务结算，识别顶级支付方式，增强人工智能模型等。

• 进行无代码设置
  连接在 Stripe 管理平台中配置，无需代码。在几分钟内设置 Stripe Data Pipeline，并持续在您的数据存储目的地自动接收 Stripe 数据和报告。

了解有关 Stripe Data Pipeline 如何帮助您释放业务数据的更多信息。