您应该使用哪种数据仓库？
您选择哪种数据仓库取决于您处理的数据量。本指南将为您介绍可用的选项，无论您是小型初创公司还是大型企业。
在为组织或项目设置分析系统时，您需要确定数据的存储位置。虽然没有一劳永逸的解决方案，但我们将为您提供一份数据仓库选择的粗略路线图，旨在帮助您找到最适合您的预算、预期数据量和性能需求的解决方案。
以下是我们为小型初创公司及以上规模的最佳数据仓库软件选择列表。
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 实例，允许您将计算和存储分离，类似于 BigQuery 和 Snowflake 等选项。与 AWS Aqua 结合使用时，您可以显着提高性能。
BigQuery - Google Cloud Platform
有一段时间，BigQuery（在内部和研究文献中被称为 Dremel）是 Google 的半秘密武器之一。它速度很快，并且 BigQuery 抽象了基础设施，不再按机器收费（就像您在服务器上运行 Postgres 那样），而是根据您的数据量以及查询使用的 CPU/IO 量收费。它曾经使用自定义的 SQL 方言，但自 2.0 版本以来已切换到 标准 SQL。BigQuery 还通过 BigQuery ML 提供内置的机器学习功能。按计算和存储付费的另一面是定价可能不太可预测。
Snowflake - 可托管或通过其他提供商提供
Snowflake 是最受欢迎的数据仓库之一。其优点是速度快（有人声称其计算优化使其成为最快的），并且您无需扩展 Snowflake，因此无需担心配置机器。缺点是它很昂贵。
Vertica - 托管服务或自行运行
Vertica 提供一个免费的社区版，限制为 3 个节点和 1 TB 数据；商业版则以 Docker 镜像和通过 Kubernetes 提供，没有这些限制。
专有分析数据库
有各种复杂（且昂贵）的数据库解决方案，专门针对分析工作负载进行了优化。如果您正在阅读本指南，您很可能不会考虑与数据库供应商进行高达 6-7 位数的合作。
| 优点 | 缺点 |
|---|---|
| 如果您需要帮助（并且可以支付），则具有强大的服务组件。 | 昂贵。 |
| 部分提供本地部署或托管选项。 | 您需要管理另一个数据库服务器。 |
| 悠久的操作历史和复杂部署经验。 | 设置和管理通常非常复杂。 |
示例
5. 数据仓库之外：数据湖和湖仓
在这里，选项的数量开始失控。如果您是一家处理大量数据的公司，您可以考虑构建一个使用数据湖的专用数据管道：一个存储所有数据（包括结构化和非结构化数据）的地方。这里的难点在于，围绕数据湖构建管道将涉及组建一个（昂贵的）数据工程师团队。此时，您将通过事件（例如应用程序打开、按钮点击）来检测您的应用程序，根据需要修饰数据（例如向事件添加其他相关详细信息，例如用户会话详细信息），然后将清理后的数据转储到廉价存储（例如 AWS 的 S3 (Simple Storage Service)，通常采用 Parquet 等格式）。此对象存储就是您的数据湖。
您的用户通常不会直接查询数据湖。相反，您将使用 提取、转换、加载 (ETL) 操作根据需要创建数据“结构”。您将使用 Presto 等查询引擎对数据湖运行 ETL 查询，目标是将数据组织成表，以预测您的业务将提出的问题类型。这些查询引擎允许您像关系数据库一样查询 S3 等对象存储——这就像使用 SQL 查询文件系统一样。
您可以使用有向无环图 (DAG) 来调度和运行这些 ETL：Airflow 在这里非常有用。您的 ETL 的目的是生成事实表和维度表，以及列出聚合数据（每日订单数量、平均会话持续时间等）的摘要表。ETL 生成的表将来自多个源的大量信息关联起来，这将有助于业务做出决策（例如，您想了解的有关订单或产品的一切信息等）。这就像即时构建您的数据仓库。
您还可以将这些 ETL 表转储回数据湖，或者——如果您确实需要快速仪表板——转储到像 Druid 这样的内存数据库中。
| 优点 | 缺点 |
|---|---|
| 可扩展到海量数据集。 | 数据工程师和管道服务费用昂贵。 |
| 灵活，无需提前定义架构。 | 您正在承担许多活动部件的复杂性。 |
混合数据湖和数据仓库为我们带来了数据湖仓，这是一种旨在为数据湖提供一定结构，并以减少管理和使分析工具更直接地访问数据为目标的架构。
一些与数据湖设置配合使用的流行工具
- Presto 开源查询引擎，允许您使用 SQL 查询文件存储
- Athena。AWS 的无服务器交互式查询服务。
- Spark SQL。在 Parquet 格式或 Hive 表中的数据上运行 SQL 查询。
- Azure 数据湖存储.
- Databricks
- AWS 上的数据湖 数据湖设置概述。
- Airflow 用于调度 ETL。
- Druid。用于存储 ETL 后的表以进行分析查询的内存数据库。
- Pinot 专为实时分析而构建的 OLAP 数据库。起源于 LinkedIn，现属于 Apache 项目。
延伸阅读
下一步：ETL、ELT 和逆向 ETL
如何将来自多个来源的数据导入数据仓库，然后通过将您的见解推送到可以利用它们的地方来操作化这些数据。