数据仓库与数据湖与数据集市对比
你可能经常听到这些术语，所以这里提供一些关于数据仓库、数据湖和数据集市之间差异的背景信息。
关于这些标准数据仓库术语的问题在于，它们并不理想。它们是模糊的市场词汇，带有过载的隐喻，即使是经验丰富的数据人员也可能对它们所指的具体内容有一个模糊的概念。有时它们可以指代具体的事物，有时又可以指代非常抽象的事物。我们写这篇文章是因为你可能经常听到这些术语，并希望为你提供有关每个术语的背景信息。
如果你正在寻找有关存储分析数据的建议，请查看你应该使用哪个数据仓库？。
数据仓库
数据仓库是一个结构化的地方，你可以把你想查询的数据放在那里。它可能是一个具有列式存储的可扩展数据库，适用于大量数据查询，也可能是一个有文件柜的房间。这里的关键是，数据仓库与你的生产数据库是不同的，即使这个数据仓库只是你的PostgreSQL生产数据库的副本。这是一个为了分析而保留数据的地方，而不是为了你的应用程序或服务的需要。数据仓库基本上是只读的；唯一应该写入数据仓库的是ETL。
理想情况下，你会希望以这种方式组织你的数据，以预测你将要提出的问题。这意味着你将需要使用优化你应用程序事务的规范化数据，以及来自第三方应用程序和服务的所有数据（比如来自客户关系管理软件的所有来之不易的数据），并将它们ETL到使回答诸如“上个月有多少客户注册，与上个月相比如何？”或“哪个入门环节的流失率最大？”等问题变得容易的列或表中。
你还会听到人们将数据仓库特别指称为一种特定类型的数据库或专注于分析查询处理的云服务。像BigQuery、Redshift、Snowflake和Vertica这样的数据仓库是为聚合和过滤大量数据而设计的。不利的一面是，它们作为应用程序数据库的使用效果不佳，因为它们不是很好用于查找特定记录（比如当用户登录时返回一个人的个人资料信息）。
数据湖
数据湖是存放来自你所有来源（通常在类似于分布式文件系统（如AWS的S3）的对象存储服务中）的所有数据的地方。这些数据不一定是有结构的（你这里甚至不需要文件柜）。数据湖的优势在于，你不需要提前确定要在数据上运行的查询类型。数据仓库很好，但它们可能需要大量工作来设置，无论是确定你想要如何建模你的数据，还是将所有混乱的数据源转换为这种结构。在数据湖中，你只需要在你需要的时候建立ETL表。你可以使用像Presto这样的查询引擎，它允许你使用SQL查询分布在多个S3桶（本质上是一个分布式文件系统）上的数据。或者你可以在数据湖的一部分上训练机器学习模型。
一些云服务提供商提供数据湖产品，例如AWS的数据湖，这里的“数据湖”产品是一组特定的服务组合（即“基础设施组件”），这些服务共同帮助您将数据存入和取出存储，在这种情况下是AWS的S3（简单存储服务）。另一种方法是BigQuery使用的方法，即联邦数据源，其中“湖”不是单一地点，而是BigQuery可以查询的多个地点。
数据集市
数据集市本质上是一套仪表盘，用于分析数据仓库或数据湖中特定业务功能的数据子集。也就是说，数据集市将数据仓库或湖的一部分与仪表板和可视化分析工具相结合，这些工具分析这些数据。它们不是你可以购买的东西；它们是你组织必须定义和构建的东西。
数据集市通常被视为数据堆栈的垂直切片，其中这些切片对应于组织内部的不同团队。因此，一个企业中营销团队的数据集市示例将包括所有表格和模型（以及汇总事实和维度的摘要表格），构建这些表格的ETL，以及该精选数据的“人机界面”：营销团队创建的BI工具（如Metabase）的图表和仪表板（或传统上由数据或工程团队为他们设置）。
数据集市不必那么严格，也不应该那么严格。如果你想，你可以在Metabase中创建一个问题集和仪表板的集合，覆盖运营团队感兴趣的所有内容，并将其称为运营数据集市。你还可以按主题组织数据和其分析：这是我们关于客户的所有知识，我们关于供应链的所有知识，我们的激活漏斗等等。BI工具还可以做些有趣的事情，比如你可以构建带有过滤器的仪表板，这使得轻松关注特定的产品或类别变得容易。
数据集市作为一个概念已经存在了一段时间，但你现在很少听到这个术语。传统上，数据集市开发由数据或工程团队为其他团队完成，这可能是好是坏。如果它确保数据易于使用、探索和扩展，那就是好的；如果它使数据孤立并限制了好奇心，因为很难提出相关问题或结合其他数据，那就是不好的。但是，数据集市背后的基本思想（即组织数据以便人们更容易提问）与Metabase对商业智能的看法非常相似。BI应该是自助的，因此良好的数据集市设计不仅给人们一套答案，还给他们回答这些问题的工具，分析这些答案，并提出他们自己的问题。
进一步阅读
下一节：你应该使用哪个数据仓库？
你选择的数据库取决于你处理多少数据。本指南将向您介绍您的选项，无论您是小型初创企业还是大型企业。