数据仓库、数据湖和数据集市的比较
您可能会经常听到这些术语，因此这里将为您介绍数据仓库、数据湖和数据集市之间的区别。
关于这些标准数据仓库术语的症结在于它们并不完善。它们是模糊的营销词汇，带有过载的比喻，所以即使是经验丰富的数据专业人士也可能对它们具体指代什么感到模糊。有时它们可以指代特定的事物，有时则可以指代非常抽象的事物。我们撰写本文是因为您可能会经常听到这些术语，并希望为您提供每个术语的背景信息。
如果您正在寻找有关如何存储分析数据的建议，请查看您应该使用哪种数据仓库？。
数据仓库
数据仓库仅仅是一个结构化的场所，您可以在其中存放想要查询的数据。它可以是一个具有针对查询大量数据进行优化的列式存储的可扩展数据库，也可以是一个放着一些文件柜的房间。这里的要点是，数据仓库与您的生产数据库是不同的，即使该数据仓库只是您的 PostgreSQL 生产数据库的副本。它是一个旨在存储数据用于分析的场所，而不是为了满足您的应用程序或服务的需求。数据仓库本质上也是只读的；唯一应该写入数据仓库的是ETL。
然而，理想情况下，您会希望以一种能够预测您将要提出的问题的方式来组织数据。这意味着您需要获取为您的应用程序事务优化的规范化数据，以及来自您的第三方应用程序和服务的所有数据转储（想想您客户关系管理软件中所有来之不易的数据），并将其 ETL 到列或表中，以便轻松回答诸如上个月与前一个月相比有多少客户注册，或者哪个入职环节的流失率最高等问题。
您还会听到人们专门将数据仓库称为一种特定类型的数据库或云服务，它们专门从事分析查询处理。像 BigQuery、Redshift、Snowflake 和 Vertica 这样的数据仓库旨在聚合和过滤大量数据。另一方面，它们作为应用程序数据库使用时效果不佳，因为它们不擅长查找特定记录（例如在用户登录时返回某个人的个人资料信息）。
数据湖
数据湖是您所有来源的所有数据（通常在一个类似于分布式文件系统的对象存储服务中，例如 AWS 的 S3）的倾倒场。这些数据不一定都是结构化的（您甚至不需要文件柜）。数据湖的优势在于，您无需预先确定要在数据上运行哪种查询。数据仓库固然很棒，但它们需要大量工作才能设置，包括弄清楚如何对数据进行建模，然后将来自所有杂乱来源的数据转换成该结构。有了数据湖，您只需根据需要使用 ETL 构建表即可。您可以使用 Presto 等查询引擎，它们允许您使用 SQL 查询分布在大量 S3 存储桶（本质上是一个分布式文件系统）中的数据。或者您可以在数据湖的部分数据上训练机器学习模型。
一些云提供商提供数据湖产品，例如 AWS 的数据湖，其中数据湖“产品”是服务的特定组合（“基础设施组件”），它们共同帮助您将数据进出存储，在本例中是 AWS 的 S3 (Simple Storage Service)。另一种方法，BigQuery 使用的方法是联邦数据源，其中“湖”不是一个地方，而是 BigQuery 可以查询的多个地方。
数据集市
数据集市本质上是一组仪表板，它们分析来自数据仓库或数据湖的子集数据，用于特定的业务功能。也就是说，数据集市结合了数据仓库或数据湖的一部分，经过为团队或分析领域精心策划，以及分析该数据的仪表板和可视化。它们不是您可以购买的东西；它们是您的组织必须定义和构建的东西。
数据集市通常被认为是数据栈的垂直切片，这些切片对应于组织内的不同团队。因此，企业中营销团队的示例数据集市将包括所有表和模型（以及团队感兴趣的事实和维度聚合的汇总表）、构建这些表的 ETL，以及对这些精选数据的人机界面：带有营销团队创建的图表和仪表板（或传统上由数据或工程团队为他们设置的）的 BI 工具（如 Metabase）。
数据集市不一定非要那么严格，也不应该如此。如果您愿意，您可以在 Metabase 中汇集一组涵盖运营团队感兴趣的所有问题的集合和仪表板，并将其称为运营数据集市。您还可以按主题组织数据及其分析：例如，我们了解的客户信息、供应链信息、激活漏斗等等。BI 工具还可以进行巧妙的操作，例如构建带有过滤器的仪表板，使您可以轻松地聚焦于特定产品或类别等。
数据集市作为一个概念已经存在了一段时间，但现在您不常听到这个词了。传统上，数据集市的开发由数据或工程团队为其他团队完成，这有好有坏。好的一面是，它确保数据易于使用、探索和扩展；坏的一面是，它会使数据孤立，并通过使难以提出相关问题或合并来自其他地方的数据来扼杀好奇心。但数据集市背后的基本思想（即组织数据以使人们更容易提出问题）与 Metabase 对商业智能的看法息息相关。BI 应该是自助服务的，所以好的数据集市设计不仅为人们提供了一组答案，还为人们提供了回答这些问题、切片和切块这些答案以及提出自己问题所需的工具。