您应该使用哪个数据仓库？
你选择哪种数据仓库取决于你需要处理多少数据。本指南将向您介绍您的选项，无论您是小型初创公司还是大型企业。
当为组织或项目设置分析系统时，您需要确定存储数据的位置。虽然没有一刀切的方法，但我们仍将为您提供一个关于数据仓库选择的大致地图，目的是帮助您找到最适合您预算、预期处理的数据量以及性能需求的解决方案。
以下是我们的最佳数据仓库软件选择列表，从小型初创公司到大型企业。
1. 您的应用数据库
最简单的选择是直接使用当前存储您数据的生产数据库（无论是一个Web应用、移动应用还是本地桌面应用，而不是Metabase自己的应用数据库）。
常见示例
| 优点 | 缺点 |
|---|---|
| 您的数据仓库已经存在。 | 分析工作负载可能会减慢您的应用程序。 |
| 只需要处理一个数据库服务器。 | 数据模式通常难以用于分析。 |
| 不需要转换数据或移动数据。 | 在平衡两种基本不同的使用模式时，扩展变得困难。 |
将数据库作为生产数据库和数据仓库通常是“真实”应用程序的初步阶段，但如果你正在构建一个小型、内部应用程序、MVP或原型，同时使用一个数据库是一个可行的选择。一旦你准备推出（针对消费者应用程序），你很可能会想要迁移到以下更可扩展的选择。如果你还没有为你的应用程序选择数据库，请确保它支持只读副本，这使我们来到了下一个选项。
2. 您应用数据库的只读副本
如果你的主要数据库支持只读副本，那么你可以做的最懒惰的事情就是创建主要数据库的只读副本，即生产数据库的副本。你还可以设置另一个命名空间来包含第三方数据或事件，然后称之为胜利。
| 优点 | 缺点 |
|---|---|
| 你不需要管理不同类型的数据库。 | 针对事务负载优化的数据库通常不适合分析。 |
| 不需要转换数据或移动数据。 | 你需要管理另一个数据库服务器。 |
| 你可以独立扩展分析和事务负载。 | 数据模式通常难以用于分析。 |
通常，一旦你开始认真对待分析，并且规模增加（数据量的大小和查询的复杂性），转移到专用数据仓库会有明显的性能优势。
3. 运行与应用程序相同的数据库类型
如果您没有需要运行在多台机器上的数据库的规模，您可以使用与您的应用程序数据库相同的数据库类型作为专用分析数据仓库（例如，如果您正在使用PostgreSQL作为您的应用程序，则可以使用另一个PostgreSQL数据库来存储您的分析数据）。这种配置与之前的不同之处在于，这个数据仓库不仅仅是数据库的读取副本；相反，它是针对分析工作负载进行调整的。这种调整包括配置数据库的设置，并重新设计数据在表中的布局，以便分析查询更快、更易于编写。
| 优点 | 缺点 |
|---|---|
| 您只需要管理一种类型的数据库。 | 您需要管理另一个数据库服务器。 |
| 您可以独立扩展分析和事务负载。 | 针对事务负载优化的数据库通常在分析用途方面表现不佳。 |
| 您可以优化数据模型/模式以适应您的分析工作。 | 您需要移动数据（并对其进行转换）。 |
| 这些数据库通常仅限于单个节点，这影响了可扩展性。 |
这种配置可以带您走得很远。一旦您达到常见查询需要几分钟或更长时间的程度，您应该评估具有更多马力的选项。
4. 基于SQL的分析数据库
这里我们进入专为分析工作负载设计的数据库。与“正常”数据库软件和为重分析工作负载设计的数据库之间的主要区别在于并行化和数据格式。您通常会看到在线事务处理数据库（OLTP）和在线分析处理数据库（OLAP）这两个术语。这些都是OLAP数据库。
OLAP和OLTP之间的区别
为了清楚地了解OLAP和OLTP数据库之间的区别：事务性（OLTP）工作负载通常有许多小的读取、写入和更新操作。这些工作负载可以比给定公司的分析工作负载在单台机器上存活得更久。相比之下，分析（OLAP）工作负载的读取操作不太频繁，但这些读取涉及的数据量很大。
- 事务性工作负载的示例：获取单个用户的最后登录时间以在应用程序中显示给用户。
- 分析工作负载的示例：查询过去三个月每天用户登录总数以创建折线图。
事务性数据库通常以行格式存储数据。例如，假设我们有一个包含用户记录的表，每个用户记录包含他们的姓名、地址、最后登录时间和出生日期。事务性数据库将这四个字段存储在一个单元中，这使数据库能够非常快速地检索（或更新）该记录。
相反，分析数据库倾向于使用列式存储，将所有的姓名放在一起，所有的最后登录时间放在一起，等等。列式存储使得像“我们用户群体的平均年龄是多少？”这样的操作变得容易，因为数据库可以忽略数据库中除出生日期列之外的所有数据。通过减少数据库需要扫描的数据量，列式存储大大提高了分析查询的性能。另一方面，列式存储在事务性工作负载方面并不那么出色。
基于SQL的托管分析数据库选项
如果您没有多少内部数据库管理专业知识，基于SQL的分析数据库作为服务可以是一笔大交易。这个领域竞争非常激烈，所以一般的建议是，您应该只是使用您当前云提供商提供的选项，尽管如果您已经达到这个阶段，可能需要四处看看是否有更好的交易。这些数据仓库的主要挑战是，将数据导入其中可能很复杂。所有选项的性能在相对上是可比的，所以对于显示一个解决方案明显优于其他解决方案的基准测试要持怀疑态度。
| 优点 | 缺点 |
|---|---|
| 专为分析查询设计。 | 可能很昂贵。 |
| 可扩展。 | 价格可能难以预测。 |
| 经过实战检验。 | 导入数据很麻烦。 |
以下是一些主要的数据仓库
Redshift - 亚马逊网络服务
Redshift 是亚马逊网络服务（AWS）托管的数据仓库。它通常是整体上最便宜和最简单的选择。您需要手动配置集群，但您将获得更可预测的定价，因为您将是“购买”更多机器时间的那个。最近，AWS 将 RA3 实例 添加到 Redshift 产品中，这使得您可以将计算和存储分离，类似于 Big Query 和 Snowflake 这样的选项。并且当与 AWS Aqua 结合使用时，您可以显著提高性能。
BigQuery - 谷歌云平台
一段时间以来，BigQuery（在内部和科研文献中称为 Dremel）是谷歌的半秘密武器之一。它速度很快，而且与您在服务器上运行 Postgres 一样，BigQuery 抽象了基础设施，而是根据您的数据量和查询使用的 CPU/IO 量来收费。它曾使用自定义的 SQL 句法，但自 2.0 版本以来，它已切换到 标准 SQL。BigQuery 还提供内置的机器学习功能，带有 BigQuery ML。按计算和存储付费的弊端是定价可能不太可预测。
Snowflake - 可供托管，或在其他提供商处使用
Snowflake 是最受欢迎的数据仓库之一。其优势在于速度快（有些人声称他们的计算优化使他们成为最快的），您不需要扩展 Snowflake，因此无需担心配置机器。缺点是它很昂贵。
Vertica - 托管服务或自行运行
Vertica 提供了一个免费的社区版，限制为 3 个节点和 1 TB 的数据，而商业版没有这些限制，可以作为 Docker 镜像和通过 Kubernetes 提供。
专有分析数据库
有许多针对分析工作负载优化的复杂（且昂贵）的数据库解决方案。如果您正在阅读本指南，那么您很可能不需要与数据库供应商签订 6-7 位数的合同。
| 优点 | 缺点 |
|---|---|
| 如果您需要帮助（并且可以付费），则具有强大的服务组件。 | 很昂贵。 |
| 有些提供本地选项或托管选项。 | 您需要管理另一个数据库服务器。 |
| 拥有长期运营历史和复杂部署的经验。 | 通常设置和管理非常复杂。 |
示例
5. 超越数据仓库：数据湖和湖屋
这里的选择开始变得失控。如果您是一家处理大规模数据的公司，您可以考虑构建一个使用 数据湖 的专用数据管道：一个存储您所有数据的地方，无论是结构化数据还是非结构化数据。这里的难点在于，围绕数据湖构建的管道将需要组装一个（昂贵的）数据工程师团队。到这一点，您将在应用中添加事件（如应用打开、按钮点击），根据需要装饰那些数据（如向事件添加其他相关细节，例如用户会话详情），然后将清理后的数据导入便宜的存储（如 AWS 的 S3（简单存储服务），通常以 parquet 等格式）。这个对象存储就是您的数据湖。
用户通常不会直接查询数据湖。相反，您会使用提取、转换、加载（ETL）操作根据需要创建数据的“结构”。您将使用像Presto这样的查询引擎在数据湖上运行ETL查询，目标是组织数据到表格中，这些表格可以预测企业会提出的问题。这些查询引擎允许您像查询关系数据库一样查询对象存储（如S3） - 就像使用SQL查询文件系统一样。
您可以使用有向无环图（DAG）来安排和运行这些ETL：Airflow在这里非常有用。您的ETL的想法是生成事实表和维度表，以及列出聚合数据的摘要表（例如，每日订单数、平均会话持续时间等）。由ETL生成的表将来自多个来源的大量信息结合起来，有助于企业做出决策（例如，您想要了解有关订单或产品的所有信息等）。就像在实时构建您的数据仓库一样。
您还可以将这些ETL表回放到您的数据湖中，或者如果您真的需要快速的仪表板，则可以放入内存数据库（如Druid）中。
| 优点 | 缺点 |
|---|---|
| 可扩展到大规模数据集。 | 数据工程师和管道服务成本很高。 |
| 灵活，无需预先定义模式。 | 您正在承担许多动态部分的复杂性。 |
混合数据湖和数据仓库为我们带来了数据湖屋（data lakehouse），这是一种旨在为数据湖提供一些结构的架构，旨在减少管理并使分析工具能够更直接地访问数据。
一些用于与数据湖设置一起工作的流行工具
- Presto 允许使用SQL查询文件存储的开源查询引擎
- Athena。AWS的无服务器交互式查询服务。
- Spark SQL。在Parquet格式或Hive表中的数据上运行SQL查询。
- Azure数据湖存储.
- Databricks
- AWS上的数据湖 数据湖设置的概述。
- Airflow 用于安排ETL。
- Druid。内存数据库，用于存储您的ETL表以进行分析查询。
- Pinot 为实时分析专门设计的OLAP数据库。源自LinkedIn，现在在Apache下。
进一步阅读
下一节：ETL、ELT和反向ETL
如何将来自多个来源的数据引入您的数据仓库，然后通过将您的见解推送到您可以使用它们的地方来使该数据实现操作化。