应该使用哪种数据仓库？
您选择哪个数据仓库取决于您要处理的数据量。本指南将引导您了解您的选择，无论您是小型初创公司还是大型企业。
在为组织或项目设置分析系统时，您需要确定在哪里存储数据。虽然没有万能的解决方案，但我们将为您提供数据仓库可用选项的粗略地图，目标是帮助您找到最适合您的预算、您期望处理的数据量以及您的性能需求的解决方案。
以下是我们为小型初创公司及以上公司提供的最佳数据仓库软件列表。
1. 您的应用程序数据库
最简单的选择是仅使用当前存储数据的生产数据库），无论是 Web 应用程序、移动应用程序还是原生桌面应用程序（而不是 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）是谷歌的半秘密武器之一。它速度很快，并且 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（简单存储服务），通常采用 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。
延伸阅读
下一步：ETL、ELT 和反向 ETL
如何将来自多个来源的数据引入你的数据仓库，然后如何通过将你的见解推送到你可以使用它们的地方来使这些数据投入运营。