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