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