您应该使用哪个数据仓库？
选择哪种数据仓库取决于您处理的数据量。本指南将为您介绍各种选项，无论您是小型初创公司还是大型企业。
在为组织或项目设置分析系统时，您需要确定将数据存储在哪里。虽然没有一劳永逸的解决方案，但我们将为您提供数据仓库的粗略选择地图，旨在帮助您找到最适合您的预算、预期数据量和性能需求的解决方案。
以下是我们为从小型初创公司到大型企业推荐的最佳数据仓库软件列表。
1. 您的应用程序数据库
最简单的选择是直接使用当前存储您数据的生产数据库，无论是网络应用程序、移动应用程序还是本地桌面应用程序（而不是 Metabase 自己的应用程序数据库）。
常见示例
| 优点 | 缺点 |
|---|---|
| 您的数据仓库已经存在。 | 分析工作负载可能会减慢您的应用程序。 |
| 只需处理一个数据库服务器。 | 数据模式通常难以用于分析。 |
| 无需转换或移动数据。 | 在平衡两种根本不同的使用模式时，扩展变得困难。 |
将数据库同时用作生产数据库和数据仓库通常是“真实”应用程序的初步阶段，但如果您正在构建小型内部应用程序、MVP 或原型，则将单个数据库加倍使用是一个可行的选择。一旦您准备好发布（对于消费者应用程序），您可能希望从这种设置迁移到下面更具可扩展性的选择。如果您尚未为您的应用程序选择数据库，请确保它支持只读副本，这引出了下一个选项
2. 您的应用程序数据库的只读副本
如果您的主数据库支持只读副本，您可以做的第二件最省力的事情是创建主数据库的只读副本，即生产数据库的副本。您还可以设置另一个命名空间以包含您的第三方数据或事件，并将其视为成功。
| 优点 | 缺点 |
|---|---|
| 您无需管理不同类型的数据库。 | 为事务性负载优化的数据库通常不适合分析 |
| 无需转换或移动数据。 | 您需要管理另一个数据库服务器。 |
| 您可以独立扩展分析和事务性负载。 | 数据模式通常难以用于分析。 |
通常，一旦您开始认真对待分析，并且您的规模增加（数据**量**和分析查询的**复杂性**），迁移到专用数据仓库会带来显著的性能优势。
3. 运行与您的应用程序相同类型的数据库
如果您不需要在多台机器上运行数据库的规模，您可以使用与应用程序数据库相同类型的数据库作为专用分析数据仓库（例如，如果您的应用程序使用 PostgreSQL，则可以使用另一个 Postgres 数据库来存储您的分析数据）。这种设置与前一种不同之处在于，这个数据仓库不仅仅是您数据库的只读副本；它经过调优以适应分析工作负载。这种调优涉及配置数据库的设置，并重塑数据在表中的布局方式，以使分析查询更快且更易于编写。
| 优点 | 缺点 |
|---|---|
| 您只需管理一种数据库。 | 您需要管理另一个数据库服务器。 |
| 您可以独立扩展分析和事务性负载。 | 针对事务性负载优化的数据库通常不适用于分析目的。 |
| 您可以根据分析工作优化数据模型/模式。 | 您需要移动数据（并对其进行转换）。 |
| 这些数据库通常仅限于单个节点，这会影响可伸缩性。 |
这种设置可以带您走得很远。一旦您达到常见查询需要几分钟或更长时间的地步，您就应该评估更强大的选项。
4. 基于 SQL 的分析数据库
这里我们开始介绍专为分析工作负载设计的数据库。“普通”数据库软件与旨在处理繁重分析工作负载的数据库之间的主要区别在于并行化和数据格式。您经常会看到联机事务处理数据库 (OLTP) 和联机分析处理数据库 (OLAP) 这两个术语。这些就是 OLAP 数据库。
OLAP 和 OLTP 的区别
为了明确 OLAP 和 OLTP 数据库之间的区别：事务（OLTP）工作负载通常有许多小型的读取、写入和更新操作。对于给定的公司，这些工作负载可以在单台机器上运行的时间比分析工作负载要长得多。相比之下，分析（OLAP）工作负载的读取操作频率较低，但这些读取涉及的数据量要大得多。
- **事务性**工作负载示例：获取单个用户的上次登录时间，以便在应用程序中显示给他们。
- **分析性**工作负载示例：查询过去三个月每天用户登录总数以创建折线图。
事务数据库通常以行格式存储数据。例如，假设我们有一个包含用户记录的表，每条用户记录包括其姓名、地址、上次登录时间和出生日期。事务数据库将所有这四个字段存储在一个单元中，这使得数据库能够非常快速地检索（或更新）该记录。
相反，分析数据库倾向于使用列式存储，将所有姓名存储在一起，所有上次登录时间存储在一起，依此类推。列式存储使得诸如“我们用户群的平均年龄是多少？”之类的操作变得容易，因为数据库可以忽略数据库中除出生日期列之外的所有数据。通过减少数据库需要扫描的数据量，列式存储显着提高了分析查询的性能。另一方面，列式存储在事务性工作负载方面并不那么出色。
托管式基于 SQL 的分析数据库选项
如果您没有太多内部数据库管理专业知识，基于 SQL 的分析数据库即服务可能是一个不错的选择。这个领域竞争非常激烈，所以这里的普遍经验法则是您应该使用当前云提供商提供的选项，尽管如果您达到了这个阶段，可能需要货比三家，看看是否能获得更好的交易。这些数据仓库的主要挑战是，将数据导入其中可能很复杂。所有选项的性能**相对**相当，因此对于显示一个解决方案明显优于其他解决方案的基准测试要持怀疑态度。
| 优点 | 缺点 |
|---|---|
| 专为分析查询而设计。 | 可能很昂贵。 |
| 可扩展。 | 潜在不可预测的定价。 |
| 久经考验。 | 导入数据很麻烦。 |
以下是一些主要的数据仓库
Redshift - 亚马逊网络服务
Redshift是亚马逊网络服务 (AWS) 的托管数据仓库。它通常是整体上最便宜、最简单的选项。您必须手动预置集群，但您将获得更可预测的定价，因为您将是“购买”更多机器时间的人。最近，AWS 在 Redshift 产品中添加了 RA3 实例，这使您可以像 BigQuery 和 Snowflake 等选项一样将计算和存储分离。当与 AWS Aqua 结合使用时，您可以显著提高性能。
BigQuery - 谷歌云平台
在一段时间内，BigQuery（内部和研究文献中称为 Dremel）是 Google 的半秘密武器之一。它速度快，并且不按机器付费（就像您在服务器上运行 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 Data Lake Storage.
- Databricks
- AWS 上的数据湖 数据湖设置概述。
- Airflow 用于调度 ETL。
- Druid。用于存储 ETL 后的表以进行分析查询的内存数据库。
- Pinot 专为实时分析而构建的 OLAP 数据库。起源于 LinkedIn，现属于 Apache。