数仓的选择

[dazdata]

应使用哪种数据仓库方案？

选择哪个方案取决于要处理的数据量。本指南将引导您完成您的选择，无论您是小型初创公司还是大型企业。
为组织或项目设置分析系统时，您需要确定存储数据的位置。虽然没有放之四海而皆准的解决方案，但我们将为您提供对于数据仓库的方案的选择指引，目的是帮助您找到最适合您的预算、数据量以及性能需求的解决方案。

以下是我们的列出的几种数仓方案，适用于小型创业公司。

1. 应用程序数据库
   最简单的选择是直接使用生产数据库，无论是Web应用程序，移动应用程序还是本机桌面应用程序（而不是Metabase自己的应用程序）应用程序数据库).
   常见应用数据库：

   • Mysql
   • Postgresql
   • SQL Server
   • Oracle

   优点	缺点
   不需要单独再创建数仓	当调用查询数据的时候会对应用程序造成影响
   不用再做数据转换和数据转移	不支持弹性扩容或者缩容
   只用与引用数据库连接即可不需要做其它操作	数据库的表结构不利与做数据分析，需要大量的join操作

   将一个数据库即作生产库又用作数据仓库，这对于一个真正的应用来说，这是一个很初级的做法。但是，如果你只是构建一个小型的内部应用，或者只是做原型验证，这也可以作为一个可行的选项。
   一旦你准备好要做一个真正的应用的时候，你就要做好迁移到更加弹性的架构方案上。如果你还没有为你的应用程序选择一个数据库方案，那么请选择支持只读副本的方案，接下来我们将介绍到。

2. 应用程序数据库的只读副本
   如果你的主数据库支持只读副本，您可以为生产数据库创建一个只读副本。

   优点	缺点
   你不需要管理不同类型的数据库	需要管理额外的数据库服务器
   不需要转换和转移数据	数据库没有为数据分析做专门优化
   不影响生产库性能	数据库的表结构不利与做数据分析，需要大量的join操作

   通常，一旦你开始认真对待数据分析，并且你的分析规模一直在增加（数据量和分析查询的复杂性方面），这时候迁移到专用的数据仓库将具有显著的性能优势。

3. 运行与应用程序相同类型的数据库
   如果你没有使用数据库集群的需求。那么你可以使用一台和你应用服务器数据库同类型的数据库作为专门的数据分析数据库（例如：我使用pg跑我的应用，那么我可以再拿一台pg作为专门的分析数据库）。这个方案不同于前一个用只读副本的方案，它专门给数据分析使用。这样，我们在配置数据库的时候就可以将它为数据分析方向优化，以及重建数据表结构。让它更适合数据分析工作。

   优点	缺点
   只需要管理同一种服务器	需要管理多个数据库服务器
   工作负载独立，不影响应用数据库	需要转移数据，并对其转换
   可以优化数据模型，表结构，让它更适合做数据分析工作	为事务负载优化的数据库通常不适合分析目的的工作
   	这种类型数据库通常只有单个节点，这会影响可伸缩性

   这个方案对于中小型团队来说，是最常见的方案。 但如果经常遇到一个查询需要几分钟或更长时间的才能响应的时候，你就应该考虑性能更强的方案。

4. SQL分析型数据库
   这是我们进入为分析工作负载设计的数据库的地方。 普通的数据库软件和用于重量级分析数据库之间的主要区别在于并行化和数据格式。你经常会看到OLTP和OLAP这样的数据库分类。以下是两者的区别。
   OLAP（On-Line Analytical Processing）联机分析处理，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。应用在数据仓库，使用对象是决策者。OLAP系统强调的是数据分析，响应速度要求没那么高。
   OLTP（On-Line Transaction Processing）联机事务处理，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率，实时性比较高。
   事务型数据库（OLTP）工作负载通常具有许多小的读取、写入和更新。这些工作负载可以在一台机器上比给定公司的分析工作负载更长的时间。相比之下，分析型数据区(OLAP) 工作负载的读取操作频率较低，但这些读取涉及的数据量要大得多。
   事务性工作负载示例：获取单个用户的上次登录时间以在应用程序中显示给他们。
   分析工作负载示例：查询过去三个月每天的用户登录总数以创建折线图。
   事务数据库通常以行格式存储数据。例如，假设我们有一个包含用户记录的表，每个用户记录都包含他们的姓名、地址、上次登录时间和出生日期。事务数据库将所有四个字段存储在一个单元中，这使数据库能够非常快速地检索（或更新）该记录。
   相反，分析数据库倾向于使用列式存储，将所有名称存储在一起，将所有最后登录时间存储在一起，等等。列式存储可以进行诸如“我们用户群的平均年龄是多少？”之类的操作。很容易，因为数据库可以忽略数据库中除出生日期列之外的所有数据。通过减少数据库需要扫描的数据量，列式存储显着提高了分析查询的性能。另一方面，列式存储在事务性工作负载中并不是那么出色。
   托管的基于 SQL 的分析数据库选项
   如果您没有太多内部数据库管理专业知识，那么基于 SQL 的分析数据库即服务可能会非常有用。这个空间竞争非常激烈，所以这里的普遍看法是你应该只使用你当前的云提供商提供的选项，但如果你正处于这个阶段，可能是时候货比三家了，看看你是否能得到更好的交易。这些数据仓库的主要挑战是将数据输入其中可能很复杂。所有选项的性能都具有相对可比性，因此对显示一种解决方案显着优于其他解决方案的基准测试持怀疑态度。

   优点	缺点
   专为分析查询设计	价格昂贵
   可伸缩	潜在的不可预测的定价
   经过了市场的考验	获取数据比较麻烦

   以下是一些主要的数据仓库：

   • Redshift - AWS
     Redshift 是 Amazon Web Service (AWS) 的托管数据仓库。这通常是总体上最便宜和最简单的选择。您将不得不手动配置集群，但您将获得更可预测的定价，因为您将成为“购买”更多机器时间的人。最近，AWS 在 Redshift 产品中添加了 RA3 实例，让您可以分离计算和存储，类似于 Big Query 和 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 获得，没有这些限制。

5. 数据仓库：数据湖和DW
   这就是选项数量开始失控的地方。如果您是一家处理大规模的公司，您可以考虑构建一个使用数据湖的专用数据管道：一个存储所有数据的地方，包括结构化和非结构化数据。这里的问题是，围绕数据湖构建管道将涉及组建一个（昂贵的）数据工程师团队。此时，您将使用事件（例如应用打开、按钮单击）来检测您的应用程序，根据需要装饰该数据（例如向事件添加其他相关详细信息，例如用户会话详细信息），然后转储清理后的数据数据存储到廉价存储中（如 AWS 的 S3（简单存储服务），通常采用 parquet 等格式）。此对象存储就是您的数据湖。
   您的用户通常不会直接查询数据湖。相反，您将使用提取转换加载 (ETL) 操作根据需要创建数据的“结构”。您将使用 Presto 之类的查询引擎在数据湖上运行 ETL 查询，目的是将数据组织到表中，以预测您的业务将提出的问题类型。这些查询引擎允许您向 S3 等对象存储提出问题，就好像它是一个关系数据库一样——就像使用 SQL 查询文件系统一样。
   您可以使用有向无环图 (DAG) 来安排和运行这些 ETL：Airflow 在这里派上用场。您的 ETL 的想法是生成事实和维度表，以及列出聚合数据（每日订单数、平均会话持续时间等）的汇总表。 ETL 生成的表格将来自多个来源的大量信息联系在一起，这些信息将有助于企业做出决策（例如，您想知道的关于订单或产品的所有信息等）。这就像在运行中构建您的数据仓库。
   您还可以将这些 ETL 表转储到您的数据湖中，或者如果您确实需要快速的仪表板，则可以将这些 ETL 表转储到像 Druid 这样的内存数据库中。

   优点	缺点
   可以扩展到海量数据集	数据工程师和support服务很昂贵
   灵活，不需要提前定义模式	组件太多，比较复杂

   近年来，混合数据湖和数据仓库架构引起了行业的一些兴趣。这些数据湖库旨在为数据湖提供一些结构，目的是减少管理难度并让分析工具更直接地访问数据。

   一些用于数据湖设置的流行工具：

   • Presto，开源查询引擎，可让您使用 SQL 查询文件存储
   • Athena，AWS的serverless交互式查询服务。
   • Spark SQL，对 Parquet 格式或 Hive 表的数据运行 SQL 查询。
   • Azure Data Lake Storage
   • Databricks
   • Airflow，用于调度 ETL。
   • Druid，内存数据库，用于存储您的 ETL 表以进行分析查询。
   • Pinot，OLAP DB 专为实时分析而构建。来自LinkedIn，现在在Apache下。

[Hugebin]

那么，如果要在Metabase上建设数仓的话，可否有对应的策略和方法论呢？

[deson.zhao]

我们想通过指定keytab的方式连接impala 这个能实现吗 有多个票据 不同的部门使用不同的票据 现在的impala驱动好像实现不了

[dazdata]

@deson-zhao 可以借用clickhouse实现，clickhouse支持jdbc的表函数，把clickhouse作为中间转换层 就行了

[sjm]

什么时候才能支持 on Doris？

[ressmix]

同问，有计划支持Apache Doris的数据源吗