主流开源分析引擎梳理，看看你最中意谁？| StoneDB 数据库观察

作者：StoneDB

2023-07-10
浙江
本文字数：12245 字
阅读完需：约 40 分钟

编者荐语：

本文来自石原子合伙人祁国辉老师，主要对主流的开源分析引擎进行详尽的分析，干货满满，欢迎大家阅读学习。

最近一段时间，我重新梳理了一下目前市面上主流的数据分析引擎，发现真是琳琅满目，令人眼花缭乱。静下心来花了两周时间横向看了一下，学习过程中，记了一些笔记，希望能够帮到大家。

作者 | 祁国辉

责编 | 韩楠

封面 &编辑 | 宇亭

总体来讲，分析下来，基本脉络来自两个方向：一个是 MPP 数据库的大规模并行；另外一个方向来自于 SQL on Hadoop。

结合这两条主线，各个产品在不同地方做了一些优化和取舍，比如 Kylin 和 Mesa 的预计算，比如大家 ClickHouse 的大宽表。

当然各家也都有一些共性，可谓是八仙过海，各显神通。比如大家都开始尽量向标准 SQL 靠拢，以屏蔽底层的技术复杂性。另外基于表组的 ORC 或者 parquet 的列式数据存储，提高 OLAP 查询时的 IO 效率，基于松耦合集群的架构，来支持海量数据下的横向扩展能力。说明在 OLAP 分析中的关键技术也基本上开始趋同。

而下一代的技术比如向量化执行， AI4DB、serverless、内存池化等基于最新技术的云化数仓，也将成为下一阶段大家发力的方向。

01 Greenplum

业界最著名的开源 MPP 数据库，基于 PostgreSQL，其架构核心是采用无共享的 MPP 架构，主要用于数据分析 OLAP。2010 年被 EMC 收购，于 2015 年开源，拥有完整的生态。

图源：Docs.greenplum.org

Greenplum 主要由 Master 节点、Segment 节点、interconnect 三大部分组成。

Greenplum master 是 Greenplum 数据库系统的入口，接受客户端连接及提交的 SQL 语句，将工作负载分发给其他数据库实例（segment 实例），由它们存储和处理数据。

Greenplum interconnect 负责不同 PostgreSQL 实例之间的通信。

Greenplum segment 是独立的 PostgreSQL 数据库，每个 segment 存储一部分数据。大部分查询处理都由 segment 完成。每个 Segment 存放一部分用户数据，但是用户不能直接访问 Segment，所有对 Segment 的访问都必须经过 Master。

Master 节点不存放任何用户数据，只是对客户端进行访问控制以及存储表分布逻辑的元数据，Segment 节点负责数据的存储，可以对分布键进行优化以充分利用 Segment 节点的 IO 性能来扩展整集群的 IO 性能，Segment 节点越多，数据就会打得越散，处理速度就越快。

存储方式可以根据数据热度或者访问模式的不同而使用不同的存储方式。一张表的不同数据可以使用不同的物理存储方式：行存储、列存储、外部表。

GreenPlum 属于比较早期开源的数据仓库产品，使用的用户很多，优缺点简要分析如下：

优点：

支持标准 SQL 语法，使用简单，与上下游工具无缝集成，利用 PG 生态，易于运维管理；
支持行列混存，支持数据压缩；
性能优异，利用 MPP 架构，充分发挥并行能力。

缺点：

多个 PG 数据库的组合，部署在开放平台上，稳定性不足；
查询没有利用到分片键，可能导致大量数据跨节点传输，性能会有所下降；
因为任何一个任务都会在每个节点并行执行，整个系统并发能力受单节点处理能力影响。

02 HAWQ

谈到 GreeenPlum ，就不得不提一下 HAWQ，因为 HAWQ 是和 GreenPlum 同源的，都是由 Pivotal 公司研发的，为什么叫 HAWQ，是因为它的名字叫 Hadoop with Query。它是用 Hadoop 替换了 GreenPlum 中的 MPP 和 sharenothing 的数据存储。

HAWQ 是一个 Hadoop 原生大规模并行 SQL 分析引擎，目前大家使用的是 Apache 开源的最新的 2.0 Alpha 版本，数据直接存储在 HDFS 上，并且 SQL 查询优化器中已经为基于 HDFS 的文件系统性能特征进行过细致的优化。

SQL on Hadoop 的主要设计目标是：在 Hadoop 上执行 SQL 连接时，最大程度地降低数据传输的开销。HAWQ 采用 Dynamic pipelining 来解决这一关键要求，使基于 HDFS 的数据适用于交互式查询。HAWQ 要比现有 Hadoop 查询引擎快一或两个数量级。这些性能改进主要归功于 Dynamic pipelining 和 HAWQ 内基于成本的查询优化器的强大功能。

图源：https://hawq.apache.org/docs/

Apache HAWQ 采用主从（Master-Segment）的改进 MPP 架构。一个典型的 Apache HAWQ 集群是分布式部署在多个服务器节点上，如多个物理机或多个虚拟机。在 HAWQ Master 端，Apache HAWQ 提供集中的元数据管理并接受所有客户端连接的请求，当一个客户端的数据计算请求以 SQL 形式发送到 Master 后，被优化的分布式执行计划被生成并派发到多个 Segment 服务器运行，计算由多个执行器进程（QE）实现并行计算。

存储由 Hadoop HDFS 提供服务，绝大多数情况下 Segment 服务器将使用本地 HDFS DataNode 服务实现数据存取。集群的计算资源由 Master 端的资源管理器统一调度，并以资源容器的形式在 Segment 端体现。

HAWQ 的主要优缺点总结如下：

优点：

完善的 Sql 支持；
原生 Hadoop 支持，利用 YARN，能和各类 Hadoop 生态组件进行整合，支持各类常见的文件格式；
优异的 OLAP 查询性能，利用 Pivotal Orca 优化器，性能上表现不错；
先进的架构，对比传统 MPP，天生存算分离。

缺点：

安装配置复杂；
内部技术实现复杂，要达到最佳性能，还是需要内部表。

03 Hive

Hive 是基于 Hadoop 构建的一套数据仓库分析系统，它提供了丰富的 SQL 查询方式来分析存储在 Hadoop 分布式文件系统中的数据。由 Facebook 研发。

Hive 的计算基于 Hadoop 实现的一个特别的计算模型 MapReduce，它可以将计算任务分割成多个处理单元，然后分散到一批家用或服务器级别的硬件机器上，降低成本并提高水平扩展性。

Hive 的数据存储在 Hadoop 一个分布式文件系统上，即 HDFS。用户输入 SQL 后，Hive 会将其翻译成 MapReduce 或者 Spark 任务，提交到 Yarn 上面执行，执行成功将返回结果。

图源：https://cwiki.apache.org/confluence/display/Hive/Design

Hive 比较适合离线处理，因为它把 SQL 转 MapReduce 执行响应速度较慢，Hive 发展很快，例如查询优化方面采用了 CBO，在执行引擎方面用 Tez 来替换 MapReduce，通过 LLAP 来 cache 查询结果做优化，利用 DAG 减少落盘次数来提速，以及 ORC 存储不断演进。

不过相比较而言，这些新技术从市场应用来说还不算成熟稳定，Hive 仍然被大量用户定义为可靠的 ETL 工具而非即时查询产品。

Hive 在 0.14 以后的版本支持事务，前提是文件格式为 orc 格式，同时必须分桶，还必须显式声明 transactional=true。

优缺点分析：

优点：

最基础的一款 Hadoop 数据仓库产品，更够部署在所有 Hadoop 发行版本之上；
目前大多数其他技术都搭建在 Hive 之上，基于 MR 之上，封装了 SQL 支持；
系统稳定， HQL 使用者众多。

缺点：

Hive 不支持事务，一般用于读多写少的情况，不建议改动数据，因为数据存储在 HDFS 中，而 HDFS 的文件不支持修改；
Hive 延迟比较大，因其底层是 MapReduce，执行效率较慢。但当数据规模较大的情况下，Hive 的并行计算优势就体现出来了；
Hive 不支持索引，查询的时候是全表扫描，这也是其延迟大的原因之一。

Hive 虽然存在性能上的问题，直接使用不多，但是现在基本上作为 SQL on Hadoop 的基础组件，在大数据家族中使用非常广泛。

04 Impala

Impala 由 Cloudera 公司开发，提供 SQL 语义，可查询存储在 Hadoop 和 HBase 上的 PB 级海量数据。

Impala 作为新一代开源大数据分析引擎，最初参照 Dremel（由 Google 开发的交互式数据分析系统），支持实时计算，提供与 Hive 类似的功能，在性能上高出 Hive3~30 倍。Impala 可能会超过 Hive 的使用率能成为 Hadoop 上最流行的实时计算平台。

Impala 采用与商用并行关系数据库类似的分布式查询引擎，可直接从 HDFS、HBase 中用 SQL 语句查询数据，不需把 SQL 语句转换成 MR 任务，降低延迟，可很好地满足实时查询需求。

Impala 不能替换 Hive，可提供一个统一的平台用于实时查询。Impala 的运行依赖于 Hive 的元数据（Metastore）。Impala 和 Hive 采用相同的 SQL 语法、ODBC 驱动程序和用户接口，可统一部署 Hive 和 Impala 等分析工具，同时支持批处理和实时查询。

Impala 经常搭配存储引擎 Kudu 一起提供服务，这么做最大的优势是查询比较快，并且支持数据的 Update 和 Delete。

Impala 是采用 MPP 架构的查询引擎，本身不存储任何数据，直接使用内存进行计算，兼顾数据仓库，具有实时、批处理、多并发等优点。

图源 https://www.w3cschool.cn/impala/impala_architecture.html

上图是 Impala 系统结构图，Impala 和 Hive、HDFS、HBase 统一部署在 Hadoop 平台上。Impala 由 Impalad、State Store 和 Interfaces 几个部分组成。

Implalad：是 Impala 的一个进程，负责协调客户端提供的查询执行，给其他 Impalad 分配任务，以及收集其他 Impalad 的执行结果进行汇总。Impalad 也会执行其他 Impalad 给其分配的任务，主要是对本地 HDFS 和 HBase 里的部分数据进行操作。Impalad 进程主要含 Query Planner、Query Coordinator 和 Query Exec Engine 三个模块，与 HDFS 的数据节点（HDFS DataNode）运行在同一节点上，且完全分布运行在 MPP（大规模并行处理系统）架构上。

State Store：收集分布在集群上各个 Impalad 进程的资源信息，用于查询的调度，它会创建一个 statestored 进程，来跟踪集群中的 Impalad 的健康状态及位置信息。State stored 进程通过创建多个线程来处理 Impalad 的注册订阅以及与多个 Impalad 保持心跳连接，此外，各 Impalad 都会缓存一份 State Store 中的信息。当 State Store 离线后，Impalad 一旦发现 State Store 处于离线状态时，就会进入恢复模式，并进行返回注册。当 State Store 重新加入集群后，自动恢复正常，更新缓存数据。

Interfaces：Interfaces 给用户提供了执行查询的命令行工具。Impala 还提供了 Hue、shell、JDBC 及 ODBC 使用接口。

Impala 的查询过程也是典型的 MPP 架构，当用户提交查询前，Impala 先创建一个 Impalad 进程来负责协调客户端提交的查询，该进程会向 State Store 提交注册订阅信息，State Store 会创建一个 statestored 进程，statestored 进程通过创建多个线程来处理 Impalad 的注册订阅信息。通过 CLI 提交一个查询到 Impalad 进程，Impalad 的 Query Planner 对 SQL 语句解析，生成解析树；Planner 将解析树变成若干 PlanFragment，发送到 Query Coordinator。

图源 https://www.cnblogs.com/mephisto/p/6921663.html

其中 PlanFragment 由 PlanNode 组成，能被分发到单独的节点上执行，每个 PlanNode 表示一个关系操作和对其执行优化需要的信息。Query Coordinator 从 MySQL 元数据库中获取元数据（即查询需要用到哪些数据），从 HDFS 的名称节点中获取数据地址（即数据被保存到哪个数据节点上），从而得到存储这个查询相关数据的所有数据节点。

Query Coordinator 初始化相应的 Impalad 上的任务，即把查询任务分配给所有存储这个查询相关数据的数据节点。Query Executor 通过流式交换中间输出，并由 Query Coordinator 汇聚来自各个 Impalad 的结果。

最后 Query Coordinator 把汇总后的结果返回给 CLI 客户端。

优缺点分析：

优点：

基于内存运算，不需要把中间结果写入磁盘，省掉了大量的 I/O 开销；
无需转换为 Mapreduce，直接访问存储在 HDFS，HBase 中的数据进行作业调度；
速度快。使用了支持 Data locality 的 I/O 调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销；
支持各种文件格式，如 TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。可以访问 Hive 的 metastore，对 hive 数据直接做数据分析。

缺点：

对内存的依赖大，且完全依赖于 Hive；
实践中，分区过大会造成性能严重下降；
只能读取文本文件，不能直接读取自定义二进制文件。

05 Spark

2009 年，加州大学伯克利分校的 AMP 实验室，诞生了一个叫做 Spark 的项目。该项目在 2013 年成为了 Apache 的孵化项目，并以极快的速度成为了一个备受欢迎和关注的顶级项目。

Spark 项目的初衷是为了代替 MapReduce，提供一种既可以极大批量地处理分布式的数据，又有足够的容错能力，且上手容易，速度快，可以让人实现实时交互分析的解决方案。既支持作业任务处理，又支持流处理（SparkStreaming）和 SQL（SparkSQL），以及机器学习和图处理，社区生态活跃。

Hive 是提供了一个 SQL on hadoop 的机制，使得基于 Hadoop 的查询变得容易很多，但是因为 Hive 底层仍然是使用 Map/Reduce 的方法，所以在过程中需要把大量的中间结果保存在磁盘中，因而整体的性能偏慢。

而 Spark 没有像 Hive 一样使用磁盘读写，而转用性能高得多的内存存储输入数据、处理中间结果，以及存储最终结果。在大数据的场景中，很多计算都有循环往复的特点，像 Spark 这样允许在内存中缓存输入输出，上一个 job 的结果马上可以被下一个使用，性能自然要比 Hive 好得多。

Spark 的技术核心点在于弹性分布式数据集(RDD，Resilient Distributed Datasets)。RDD 是一种分布式的内存抽象，允许在大型集群上执行基于内存的计算(In-Memory Computing)，Spark RDD 能够将数据 cache 到内存中，省去了从磁盘加载的过程，同时 Spark shuffle 过程中的数据也是直接放在内存中的。

RDD 是一个分区的只读记录的集合，用户可以控制 RDD 的其他两个方面：持久化和分区。

一方面用户可以选择重用哪个 RDD，并为其制定存储策略(比如，内存存储)， Spark 提供了三种对持久化 RDD 的存储策略：未序列化 Java 对象存于内存中、序列化后的数据存于内存、序列化后的数据存于磁盘存储。

另一方面可以让 RDD 中的数据根据记录的 key 分布到集群的多个机器上，实现分布式内存计算。

后来 Spark 继续扩展，数据存储模式也有了不同的选择，数据可以存储成为 parquet，也可存储在数据库，当然也可以存储在 Hive 表上。

通常认为，与 MR 相比 spark 通过内存计算来显著提速。Spark 社区非常成熟，后面提到的很多平台或大数据组件，都与 Spark 实现无缝集成。

优缺点分析：

优点：

速度更快：因为使用内存引擎，数据不落地，Spark 性能表现非常优异；
易用性：提供丰富的 API，支持 JAVA、Scala、Python 和 R 四种语言；
通用性：Spark 提供了大量的库，包括 SQL、DataFrames、MLlib、GraphX 和 Spark Streaming。开发人员可以在同一个应用程序中无缝地组合这些库。

缺点：

稳定性，因为大量数据在内存中计算，完全依赖 java 的内存回收机制，长时间运行容易出现故障；
无法支持海量数据，因为要在内存中生成 RDD，所以数据量受内存限制；
不能像 SQL 一样，支持复杂统计分析。

06 Kylin

Kylin 是一个开源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的 Hive 表。核心是预加载和构建 cube，cube 指定度量维度，Kylin 的核心思想是预计算，利用空间换时间来加速查询模式固定的 OLAP 查询。

Kylin 的理论基础是 Cube 理论，每一种维度组合称之为 Cuboid，所有 Cuboid 的集合是 Cube。其中由所有维度组成的 Cuboid 称为 Base Cuboid，图中（time，item，location，supplier）即为 Base Cuboid，所有的 Cuboid 都可以基于 Base Cuboid 计算出来。Cuboid 我们可以理解为就是一张预计算过后的大宽表，在查询时，Kylin 会自动选择满足条件的最合适的 Cuboid 来进行加速。

图源：Apache Kylin | Apache kylin4 新架构分享

下图所示内容则描述了 Kylin 和周边生态产品共存的关系，以及 Kylin 内部数据获取，构建 Cube，用户查询交互和 SQL 解析优化的全流程。

图源：Apache Kylin | 大数据分析型数据仓库

在目前开源版本的实现中，构建完的数据是存储在 HBase 中的，而 Hbase 的缺点造成很多的局限：

- 运维困难，一旦 HBase 性能不好，那么 Kylin 的性能也会受到影响。

- HBase 的资源隔离能力也比较弱，Kylin 的性能会受到 Hbase 上其他大负载的影响。

- HBase 里存储的都是经过编码后的 Byte Array 类型，性能优化比较困难。

Kylin 4.0 中引入了新的架构，支持 Spark+ parquet，通过 Spark 的并行能力提升性能，不过只在商业版本中使用，此处就不再赘述了。

优缺点分析：

优点：

支持标准 SQL 接口；
支持超大数据集；
超高性能，通过预计算达到亚秒级响应。

缺点：

集群依赖较多，如 HBase 和 Hive 等，属于重量级方案，因此运维成本也较高；
维度变化需要重新刷新数据，不适合即席查询分析；
维度多容易出现数据爆炸。

07 Apache Kudu

Kudu 是 Cloudera 开源的运行在 hadoop 平台上的列式存储系统（fast analytics on fast data），核心 C++编写。

它比 HDFS 和 Hbase 的优势在于以下亮点：

一是 kudu 的表结构与关系型数据库类似，使用简单；

二是提供高效插入/更新机制，大量随机读性能要显著超过 Hbase。

因此可以适用于近实时的分析，快速分析那些快速变化的数据。

图源：Apache Kudu - Introducing Apache Kudu

kudu 由 master server 与 tablet server 两部分组成：

master server 负责集群管理、元数据管理等管理工作；
tablet server 提供数据存储、数据读写功能。

上图显示了一个具有三个 master 和多个 tablet server 的 Kudu 集群，每个服务器都支持多个 tablet。它说明了如何使用 Raft 共识来允许 master 和 tablet server 的 leader 和 follow。

此外，tablet server 可以成为某些 tablet 的 leader，也可以是其他 tablet follower。leader 以金色显示，而 follower 则显示为蓝色。

和 HBase 采用的 LSM 方案不同的是，Kudu 对同一行的数据更新记录的合并工作是在更新的时候进行，在 Kudu 中一行数据只会存在于一个 DiskRowSet 中，避免读操作时的比较合并工作。在 Kudu 中，对于 Flush 到磁盘上的 DiskRowSet（DRS）数据，实际上是分两种形式存在的：

一种是 Base 的数据，按列式存储格式存在，一旦生成，就不再修改；
另一种是 Delta 文件，存储 Base 数据中有变更的数据，一个 Base 文件可以对应多个 Delta 文件，更新、删除操作需要记录到特殊的数据结构里，保存在内存中的 DeltaMemStore 或磁盘上的 DeltaFIle 里面。DeltaMemStore 是 B-Tree 实现的，因此速度快，而且可修改。磁盘上的 DeltaFIle 是二进制的列式的块，当数据频繁删改的时候，磁盘上会有大量的 DeltaFiles 文件，Kudu 会定期对这些文件进行合并。

优缺点分析：

优点：

使用简单，kudu 的表结构与关系型数据库类似；
支持高效插入/更新机制，大量随机读性能要显著超过 Hbase。

缺点：

并发支持能力不足；
一般和 Impala 结合使用，架构复杂；
国内用户不多。

08 ClickHouse

ClickHouse 是由俄罗斯的第一大搜索引擎 Yandex 公司开源的列存数据库。

ClickHouse 作为开源 OLAP 引擎，因其出色的性能表现在大数据生态中得到了广泛的应用。它使用本地盘来自己管理数据，官方推荐使用 SSD 作为存储介质来提升性能。

相比传统的大数据解决方案，ClickHouse 有以下的优点：

配置丰富，只依赖于 Zookeeper 线性可扩展性；
可以通过添加服务器扩展集群容错性高；
不同分片间采用异步多主复制单表性能极佳；
采用向量计算；
支持采样和近似计算等优化手段功能强大；
支持多种表引擎。

图源：https://help.aliyun.com/document_detail/167448.html?spm=a2c4g.11174283.6.542.2acb49afFy52rZ

优缺点分析：

优点：

速度快。ClickHouse 性能超过了市面上大部分的列式存储数据库，相比传统的数据 ClickHouse 要快 100~1000 倍，ClickHouse 还是有非常大的优势。
功能多。ClickHouse 支持数据统计分析各种场景，支持类 SQL 查询，支持多库函数（例如 IP 转化，URL 分析等，预估计算/HyperLoglog 等）支持数组(Array)和嵌套数据结构(Nested Data Structure)，支持数据库异地复制部署。
独立技术架构，部署简单，可以在目前任何具有 x86_64，AArch64 或 PowerPC64LE CPU 架构的 Linux，FreeBSD 或 Mac OS X 上运行。

缺点：

模型简单，因为 Clickhouse 对 join 支持不好，所以一般都是把数据拼成一个大宽表来执行，那么一旦需求变换，或者数据分析维度变化，表中的数据必须重新刷新，带来巨大的工作量，同时这种大宽表带来巨大的数据膨胀。
并发支持不足， Clickhouse 并发支持能力弱，在 OLAP 场景中，一旦出现多个用户并发查询，查询性能会受到巨大影响。甚至导致无法返回结果。
ClickHouse 不支持事务性的 DDL 与 DML 操作，而且多副本模式的元数据管理强依赖于 ZooKeeper，表结构变更时常常出现不同副本之间元数据不一致的问题。
多种表引擎带来选择困难症， Clickhouse 提供 28 种表引擎，不同表引擎适合不同场景，不利于新手上手学习。

09 Druid

Apache Druid，由美国 MetaMarkets 公司开发，后来 Apache 基金会孵化而出。它具有如下特性：

实时可见：消息摄入后分钟级查询可见；
交互查询：查询延时在秒级，核心思想为内存计算和并行计算；
维度灵活：支持几十个维度任意组合，仅在索引时指定的维度查询可见；
易于变更：需求变更后调整索引配置立马生效；
流批一体：新版本 KIS 模式可实现 Exactly Once 语义。

图源：Design · Apache Druid

Druid 有几种不同的 Services：

Coordinator 负责在集群环境中的数据可用性；
Overlord 控制数据装载 workload 的分派；
Broker 负责承接用户请求；
Router 可选，负责请求的路由，把响应请求分别路由到 Broker, Coordinators, 和 Overlords；
Historical 负责存储查询数据；
MiddleManager 负责数据装载。

Druid 服务可以按照用户需求随意部署，但是为了便于部署，一般建议按照上图来部署，分成几种服务器类型: Master, Query, Data。

Master：运行 Coordinator 和 Overlord 服务, 负责数据的持久化保存和数据的装载的分派；
Query：运行 Broker 和可选的路由服务, 负责处理来自客户端的查询；
Data：运行 Historical 和 MiddleManager 服务，执行数据装载任务和存储所有数据。

Druid 还包含 3 个外部依赖：

Metadata：存储 Druid 中的各种 metadata（里面的数据都是 Druid 自身创建和插入的），包含 3 张表：”druid_config”（通常是空的）, “druid_rules”（coordinator nodes 使用的一些规则信息，比如哪个 segment 从哪个 node 去 load）和“druid_segments”（存储每个 segment 的 metadata 信息）。
Deep storage：存储 segments，Druid 目前已经支持本地磁盘，NFS 挂载磁盘，HDFS，S3 等。Deep Storage 的数据有 2 个来源，一个是 Batch，另一个是 real-time nodes。
ZooKeeper：被 Druid 用于管理当前 cluster 的状态，比如记录哪些 segments 从 Real-time nodes 移到了 Historical nodes。

优缺点分析：

优点：

高性能，低延迟。Druid 能够对历史和实时数据提供亚秒级别的查询，Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合。
简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。
支持实时数据摄入。其机制将热点和实时数据存储在实时节点（Realtime Node）内存中，将历史数据存储在历史节点（history node）的硬盘中，实时+伪实时的结构，保证查询基本都在毫秒级。

缺点：

配置和查询都比较复杂和繁琐，维度变更复杂。
不支持 SQL 或类 SQL 接口。对 SQL 支持的不够完善，不支持 Join。
支持时序实时摄入，对 update 支持不足。

10 Presto（Trino）

Presto 是由 FaceBook 开源的一个基于内存的 MPP 计算引擎，主要用以解决 Facebook 海量 Hadoop 数据仓库的低延迟交互分析问题。

Facebook 版本的 Presto 更多的是以解决企业内部需求功能为主，也叫 Presto DB，后来，Presto 其中的几个人出来创建了更通用的 Presto 分支，取名 Presto SQL，这个开源版本也是更为被大家通用的版本。再后来，为了更好地与 Facebook 的 Presto DB 进行区分，Presto SQL 改名为 Trino。

Presto 适用于交互式分析查询，可支持众多的数据源，包括 HDFS、RDBMS、KAFKA 等，而且提供了非常友好的接口开发数据源连接器。数据规模可以支持 GB 到 PB 级，主要应用于处理秒级查询的场景。

图源：Presto_SQL_on_Everything.pdf (trino.io)

组件工作模式：

Coordinator ：是一个中心的查询角色，它主要的一个作用是接受查询请求，将他们转换成各种各样的任务，将任务拆解后分发到多个 worker 去执行各种任务的节点：

解析 SQL 语句；
生成执行计划；
分发执⾏任务给 Worker 节点执行。

Worker ：是一个真正的计算的节点，执行任务的节点，它接收到 task 后，就会到对应的数据源里面，去把数据提取出来；

Connector：负责实际执⾏查询任务，通过不同的 connector 去适配不同的数据源；

Discover Services：是将 coordinator 和 woker 结合到一起的服务，上图中的 Metadata 和 Data Location：

Worker 节点启动后向 Discovery Server 服务注册；
Coordinator 从 Discovery Server 获得 Worker 节点。

Presto 是通过 connector plugin 获取数据和元信息的，它不是一个数据存储引擎，不需要有数据，presto 为其他数据存储系统提供了 SQL 能⼒，客户端协议是 HTTP+JSON。

优缺点分析：

优点：

Presto/Trino 支持内存并行处理、跨集群节点管线执行、多线程执行模型、高效的扁平内存数据结构(最小化 Java 的垃圾回收)、Java 字节码生成。超过了 Impala 和 Spark SQL。
支持多源联邦查询，我们的数据会储存在各种各样的数据库中，以前都需要经过 ETL 抽取到数据仓库中，现在用 Presto/Trino 在一条 SQL 中就能直接查询多个不同数据源实现联邦查询，而且 SQL 语法兼容大部分 HiveQL。
支持湖仓一体，减少数据仓库复杂度：可以去除数仓的 ODS、DWD 层，甚至可以不用 DWM 层，用 Presto/Trino 连接各种数据源，直接清洗出 DWS 大宽表层。而且维度表也可以使用 Presto/Trino 直接从源数据库读取，并使用 Presto/Trino 向 ADS 数据应用层提供服务。

缺点：

join 查询时，都要使用临时表。此时就会产生大量的临时数据，所以速度会变慢。
不适合计算太大的数据量。
不关心中间查询容错，如果某个节点失败，整个查询也将失败。

11 Google Mesa

Mesa 是一个分布式、多副本的、高可用的数据处理、存储和查询系统，针对结构化数据。一般数据从上游服务产生（比如一个批次的 spark streaming 作业产生），在内部做数据的聚合和存储。支持近实时更新（与 Cube 方案比），数据分维度列和指标列，指标列指定聚合函数。

Mesa 能满足复杂和具有挑战性的用户与系统需求，包括近实时数据提取和查询，同时在海量数据和查询量中保持高可用性、可靠性、容错率和扩展性。Mesa 每秒能处理数百万行更新，每天进行数十亿查询抓取数万亿行数据。Mesa 能进行跨数据中心复制，即使在整个数据中心故障时，也能以低延迟返回一致和可重复的查询结果。

它的特色类似 MOLAP，对各种关键维度（Key）进行预先聚合，用户查询直接访问聚合后的数据，对于数据的持续更新，会在后台以 Micro-batch 的方式进行更新，所有的更新会保存在 Delta 中，后台会根据一定条件对预聚合的数据核 Delta 进行 compaction。主要用于 Google AD 部门。

优缺点分析：

优点：

近实时的更新吞吐量。支持持续的更新，每秒支持数百万行的更新。
同时支持低时延查询性能和批量大量查询。99%的查询在几百毫秒之内返回。
跨数据中心备份。

缺点：

仅在 Google 内部使用，专为 Google 广告业务服务。
市面上相关材料不多，用户也不多。

Google Mesa 的数据模型，后来也被百度的广告部门所采用，也就产生了下面要提到的这一产品，Apache Doris。

11 Apache Doris

前身是百度 2017 年开源系统 PALO，后贡献给 Apache 更名为 Doris。Doris 是一个 MPP 的 OLAP 系统，主要整合了 Google Mesa(数据模型)，Apache Impala(MPP Query Engine)和 Apache ORCFile (存储格式，编码和压缩) 的技术。高度兼容 Mysql 协议。

元数据管理对 impala 的 p2p 模式做了更新，Doris 采用 Paxos 协议以及 Memory + Checkpoint + Journal 的机制来确保元数据的高性能及高可靠。

2020 年 2 月，百度 Doris 团队的开发人员离职创业，基于 Apache Doris 之前的版本做了自己的商业化产品 DorisDB ，后改名为 StarRocks。后来 StarRocks 也开源了，所以在此认为这两个产品同源。

图源：Introduction to Apache Doris - Apache Doris

部署架构：分为 FE（前端）和 BE（后端）两个组件。

图源：Introduction to Apache Doris - Apache Doris

- FE 负责接受用户请求、优化、调度查询，由 Java 编写；对于所有的元数据，保存在内置的 BerkeleyDB，并且通过多副本实现高可用。

- BE 负责存储数据、执行 MPP 计划中的各个片段，类似于 Worker 的角色，由 C++ 编写。

优缺点分析：

优点：

良好的架构设计，支持高并发低延时的查询服务，支持高吞吐量的交互式分析。多 FE 均可对外提供服务，并发增加时，线性扩充 FE 和 BE 即可支持高并发的查询请求。
性能优异：高效的列式存储引擎，同时提供丰富的索引结构来加速数据读取与过滤，利用分区分桶裁剪功能支持在线服务业务的超高并发，单节点最高可支持上千 QPS。更进一步，结合向量化执行引擎来提升效率，同时利用物化视图技术实现预聚合加速，同时进行基于规划和基于代价的查询优化。
支持批量数据 load 和流式数据 load，支持数据更新。支持 Update/Delete 语法，unique/aggregate 数据模型，支持动态更新数据，实时更新聚合指标。
提供了高可用，容错处理，高扩展的企业级特性。FE Leader 错误异常，FE Follower 秒级切换为新 Leader 继续对外提供服务。支持数据多副本存储，集群具备自愈功能，自身的分布式管理框架可以自动管理数据副本的分布、修复和均衡，副本损坏时系统可以自动感知并进行修复。
支持聚合表和物化视图。多种数据模型，支持 aggregate, replace 等多种数据模型，支持创建 rollup 表，支持创建物化视图。rollup 表和物化视图支持动态更新，无需用户手动处理。
MySQL 协议兼容，支持直接使用 MySQL 客户端连接，非常易用的数据应用对接。

缺点：

目前 Doris 比较抢眼，尤其是推出全向量化支持之后，但是本身成熟度还有待考验。
目前国内有多个基于 Doris 的产品，各自独立演进，可能会对后期有影响。

13 总结

开源分析引擎发展十多年来，不断有新的思想加入，也不断有新的技术和产品被世人所接受，每个产品之所以能够得到大家的认可，必然具有其独到的一些特点。当然，开源产品的共同特色就是优点和缺点都非常明显；在学习开源引擎的过程中，建议大家多去做一些横向对比，通过对比，就可以理解每个产品的优势和短板，进一步对产品原理有更深入的体会。

下面通过一个简单的表格来示例：