数据仓库选择
您选择哪个数据仓库取决于您正在争论的数据量。无论你是一家小型初创企业还是一家大型企业，本指南将为您提供各种选择。
当为一个组织或项目建立一个分析系统时，你需要找出你的数据存储在哪里。虽然没有一刀切的解决方案，但我们将为您提供一个大致的数据仓库选择图，其目标是帮助您找到最适合您预算的解决方案、您希望使用的数据量以及您的性能需求。
这是我们选择的最好的数据仓库软件，面向小型初创公司。
1.应用程序数据库
最简单的选择是使用生产数据库它当前正在存储您的数据，无论是web应用程序、移动应用程序还是本机桌面应用程序（而不是Metabase自己的应用程序）应用程序数据库).
常见示例：
MySQL数据库
PostgreSQL
SQL服务器
甲骨文公司
赞成的意见欺骗
您的数据仓库已存在。分析工作负载可能会减慢应用程序的速度。
不需要转换数据或移动数据。当平衡到根本不同的使用模式时，扩展变得很困难。
只需要处理一个数据库服务器。数据模式通常很难用于分析。
将数据库同时用作生产数据库和数据仓库通常是“真实”应用程序的初步阶段，但是如果您要构建一个小型的内部应用程序、MVP或原型，那么在单个数据库上加倍使用是一个可行的选择。一旦您准备好启动（对于消费者应用程序），您可能希望从这个设置迁移到下面一个更具伸缩性的选项。如果尚未为应用程序选择数据库，请确保它支持读取副本，这将使我们进入下一个选项：
2.应用程序数据库的读取副本
如果主数据库支持读取副本，您可以做的下一件最懒的事情是创建主数据库的读取副本，即生产数据库的副本。您还可以设置另一个名称空间，以包含第三方数据或事件，并称之为win。
赞成的意见欺骗
你不需要管理另一种数据库。针对事务负载进行优化的数据库对于分析来说通常是次优的
不需要转换数据或移动数据。你需要管理另一个数据库。服务器。
您可以独立缩放分析负载和事务负载。数据模式通常很难用于分析。
通常，一旦你开始认真对待分析，你的规模就会增加（两者都在体积数据和复杂性对于分析查询），迁移到专用数据仓库有显著的性能优势。
3.运行与应用程序相同的数据库
如果您没有需要在多台计算机上运行数据库的规模，则可以使用与应用程序数据库相同类型的数据库作为专用分析数据仓库（例如，如果您的应用程序使用PostgreSQL，则可以使用另一个Postgres数据库来存储分析数据）。此设置与以前的不同之处在于，此数据仓库不仅仅是数据库的读取副本；而是针对分析工作负载进行了调整。此优化包括配置数据库的设置，以及重塑数据在表中的布局方式，以使分析查询更快、更易于编写。
赞成的意见欺骗
你只需要管理一种数据库。您需要管理另一个数据库服务器。
您可以独立地扩展分析和事务负载。为事务性负载而优化的数据库在分析方面通常是次优的。
您可以针对分析工作优化数据模型/模式。你需要移动数据（并转换它）。
?这些数据库通常仅限于单个节点，这会影响可伸缩性。
这个设置可以让你走得很远。一旦您到达一个点，普通查询需要几分钟或更长的时间，您应该用更大的马力来评估选项。
4.基于SQL的分析数据库
在这里，我们将进入为分析工作负载设计的数据库。“普通”数据库软件和用于重分析工作负载的数据库之间的主要区别是并行化和数据格式。你会经常看到这些条款联机事务处理数据库（OLTP）和联机分析处理数据库（OLAP）。这些是OLAP数据库。
OLAP与OLTP的区别
要弄清楚OLAP和OLTP数据库之间的区别：事务性（OLTP）工作负载通常有许多小的读、写和更新。对于给定的公司，这些工作负载在一台机器上的生存时间可能比分析工作负载长得多。相比之下，分析（OLAP）工作负载的读取操作频率较低，但这些读取操作涉及的数据量要大得多。
例子事务性工作负载：获取单个用户的上次登录时间，以便在应用程序中显示给他们。
例子分析的工作负载：一个查询，用于统计过去三个月每天用户登录的总数，以创建折线图。
事务数据库通常以行格式存储数据。例如，假设我们有一个包含每个用户的用户记录的表记录包括他们的名字，地址，最后登录时间和出生日期。事务数据库将存储所有这四个领域在一个单元中，这使数据库能够快速检索（或更新）记录。
相反，分析数据库倾向于使用列式存储，将所有的名称存储在一起，最后登录的所有时间都存储在一起，等等很简单，因为数据库可以忽略数据库中除出生日期列之外的所有数据。通过减少数据库需要扫描的数据量，列式存储显著提高了分析查询的性能。另一方面，列式存储在事务性工作负载方面并不是很出色。
基于SQL的托管分析数据库选项
如果您没有太多的内部数据库管理专业知识，那么基于SQL的分析数据库作为一种服务可能会是一件了不起的事情。这个空间竞争非常激烈，所以这里的普遍看法是，你应该使用你当前云提供商提供的选项，尽管如果你正处于这个阶段，可能是时候四处逛逛，看看是否能得到更好的交易。这些数据仓库的主要挑战是将数据导入其中可能会很复杂。性能是相当地所有方案都具有可比性，所以对基准测试结果显示一种解决方案的性能显著优于其他方案持怀疑态度。
赞成的意见欺骗
设计用于分析查询。可能很贵。
可扩展。潜在的不可预测的定价。
战斗考验。获取数据是一件痛苦的事。
以下是一些主要的数据仓库：
Redshift-亚马逊网络服务
红移是Amazon Web Service（AWS）托管的数据仓库。总的来说，这是最便宜、最简单的选择。您将不得不处理手动配置集群的问题，但您将获得更可预测的定价，因为您将是“购买”更多机器时间的人。最近，AWS补充道RA3实例对于Redshift产品，它让您分离计算和存储，类似于bigquery和Snowflake等选项。与AWS
Aqua结合使用，可以显著提高性能。
BigQuery-谷歌云平台
有一段时间，大查询（在内部和研究文献中称为Dremel）是谷歌的半秘密武器之一。它很快，而且BigQuery抽象了基础设施，而不是按每台机器付费（就像在服务器上运行Postgres一样），而是根据数据量和查询使用的CPU/IO向您收费。它以前使用SQL的自定义方言，但自从2.0版以来，它已切换到标准SQL.BigQuery还提供内置的机器学习功能大查询ML。按计算和存储付费的另一面是，定价不太可预测。
Snowflake-提供托管或其他提供商
Snowflake是最流行的数据仓库之一。它的优点是速度快（有些人声称他们的计算优化使他们最快），而且您不需要缩放Snowflake，所以不必担心配置机器。缺点是价格昂贵。
Vertica-托管服务或运行您自己的
眩晕提供一个免费的社区版，仅限于3个节点和1
TB的数据，而商业版没有这些限制，可以作为Docker镜像和通过Kubernetes获得。
专有分析数据库
有各种复杂（且昂贵）的数据库解决方案针对分析工作负载进行了优化。如果您正在阅读本指南，那么您很可能不会与数据库供应商达成6-7位数的合约。
赞成的意见欺骗
强大的服务组件，如果你需要帮助（并可以支付）。很贵。
一些有预售选项或托管。您需要管理另一个数据库服务器。
长期的操作历史和复杂部署经验。通常设置和管理非常复杂。
示例：
Teradata公司
Oracle数据仓库
5.数据仓库之外：数据湖、湖仓一体
这就是选项数量开始失控的地方。如果您是一家规模巨大的公司，您可以考虑构建一个专用的数据管道，该管道使用数据湖：存储所有结构化和非结构化数据的位置。这里的问题是，围绕数据湖构建一条管道需要召集一支（昂贵的）数据工程师团队。此时，您将使用事件（如app
open，button clicked）来检测应用程序，根据需要装饰数据（比如向事件添加其他相关细节，比如用户会话细节），然后将清理后的数据转储到廉价存储中（如AWS的）S3（简单存储服务），通常采用如下格式镶木地板).?这个对象存储就是你的数据湖。
用户通常不会直接查询数据湖。相反，您将根据需要使用提取转换负载（ETL）操作。您将使用像Presto这样的查询引擎在数据湖上运行ETL查询，目标是将数据组织到表中，以预测您的业务将提出的各种问题。这些查询引擎允许您像询问关系数据库一样询问对象存储（如S3）的问题，就像使用SQL查询文件系统一样。
你可以用有向非循环图（DAGs）计划和运行这些ETL：气流这里很方便。ETL的想法是生成事实表和维度表，以及列出聚合数据的摘要表（每天的订单数、平均会话持续时间等等）。ETL生成的表将来自多个来源的大量信息结合在一起，这些信息将有助于企业做出决策（例如，您想知道的有关订单或产品的所有信息，等等）。这就像在运行中构建数据仓库。
您还可以将这些ETL表转储回您的数据湖，或者如果您真的需要快速的话仪表板-存储在内存数据库中德鲁伊.
赞成的意见欺骗
可以扩展到海量数据集。数据工程师和管道服务都很昂贵。
灵活，不需要提前定义模式。你承担了很多运动部件的复杂性。
近年来，混合数据湖和数据仓库体系结构引起了人们的兴趣。这些湖仓一体旨在为数据湖提供一些结构，目标是减少管理，并使分析工具更直接地访问数据。
使用数据湖设置的一些常用工具：
Presto开放源代码查询引擎，允许您使用SQL查询文件存储
Athena.AWS的无服务器交互式查询服务。
Spark SQL。对Parquet格式或配置单元表中的数据运行SQL查询。
Azure
? ?? Data Lake Storage.
Databricks
Data lakes on AWS数据湖设置概述。
Airflow用于调度ETLs。
Druid.In-memory数据库来存储用于分析查询的ETL表。
Pinot专门为实时分析而构建的OLAP数据库。从LinkedIn出来，现在在Apache的主导下。