编者荐语：
本文来自石原子合伙人祁国辉老师，主要对主流的开源分析引擎进行详尽的分析，干货满满，欢迎大家阅读学习。
最近一段时间，我重新梳理了一下目前市面上主流的数据分析引擎， 发现真是琳琅满目， 令人眼花缭乱。静下心来花了两周时间横向看了一下， 学习过程中， 记了一些笔记， 希望能够帮到大家。
作者 | 祁国辉
责编 | 韩 楠
封面&编辑 | 宇亭
总体来讲，分析下来， 基本脉络来自两个方向：一个是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 属于比较早期开源的数据仓库产品， 使用的用户很多， 优缺点简要分析如下：
优点：
缺点：
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的主要优缺点总结如下：
优点：
缺点：
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。
优缺点分析：
优点：
缺点：
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客户端。
优缺点分析：
优点：
缺点：
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实现无缝集成。
优缺点分析：
优点：
缺点：
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的并行能力提升性能，不过只在商业版本中使用， 此处就不再赘述了。
优缺点分析：
优点：
缺点：
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会定期对这些文件进行合并。
优缺点分析：
优点：
缺点：
08 ClickHouse
ClickHouse 是由俄罗斯的第一大搜索引擎 Yandex 公司开源的列存数据库。
ClickHouse 作为开源 OLAP 引擎，因其出色的性能表现在大数据生态中得到了广泛的应用。它使用本地盘来自己管理数据，官方推荐使用 SSD 作为存储介质来提升性能。
相比传统的大数据解决方案，ClickHouse 有以下的优点：
- 配置丰富，只依赖于 Zookeeper线性可扩展性；
- 可以通过添加服务器扩展集群容错性高；
- 不同分片间采用异步多主复制单表性能极佳；
- 采用向量计算；
- 支持采样和近似计算等优化手段功能强大；
- 支持多种表引擎。
图源：https://help.aliyun.com/document_detail/167448.html?spm=a2c4g.11174283.6.542.2acb49afFy52rZ
优缺点分析：
优点：
缺点：
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。
优缺点分析：
优点：
缺点：
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去执行各种任务的节点 ：
- Worker ：是一个真正的计算的节点，执行任务的节点，它接收到task后，就会到对应的数据源里面，去把数据提取出来；
- Connector：负责实际执⾏查询任务， 通过不同的connector去适配不同的数据源；
- Discover Services：是将coordinator和woker结合到一起的服务，上图中的Metadata和 Data Location：
Presto是通过connector plugin获取数据和元信息的，它不是一个数据存储引擎，不需要有数据，presto为其他数据存储系统提供了SQL能⼒，客户端协议是HTTP+JSON。
优缺点分析：
优点：
缺点：
11 Google Mesa
Mesa是一个分布式、多副本的、高可用的数据处理、存储和查询系统，针对结构化数据。一般数据从上游服务产生（比如一个批次的spark streaming作业产生），在内部做数据的聚合和存储。支持近实时更新（与Cube方案比），数据分维度列和指标列，指标列指定聚合函数。
Mesa能满足复杂和具有挑战性的用户与系统需求，包括近实时数据提取和查询，同时在海量数据和查询量中保持高可用性、可靠性、容错率和扩展性。Mesa每秒能处理数百万行更新，每天进行数十亿查询抓取数万亿行数据。Mesa能进行跨数据中心复制，即使在整个数据中心故障时，也能以低延迟返回一致和可重复的查询结果。
它的特色类似MOLAP， 对各种关键维度（Key）进行预先聚合， 用户查询直接访问聚合后的数据， 对于数据的持续更新，会在后台以Micro-batch的方式进行更新， 所有的更新会保存在Delta中， 后台会根据一定条件对预聚合的数据核Delta 进行compaction。主要用于Google AD部门。
优缺点分析：
优点：
缺点：
Google Mesa的数据模型，后来也被百度的广告部门所采用， 也就产生了下面要提到的这一产品，Apache Doris。
12 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++ 编写。
优缺点分析：
优点：
缺点：
13 总结
开源分析引擎发展十多年来， 不断有新的思想加入， 也不断有新的技术和产品被世人所接受，每个产品之所以能够得到大家的认可， 必然具有其独到的一些特点。当然，开源产品的共同特色就是优点和缺点都非常明显；在学习开源引擎的过程中， 建议大家多去做一些横向对比，通过对比，就可以理解每个产品的优势和短板， 进一步对产品原理有更深入的体会。
下面通过一个简单的表格来示例：
补充一点：部分资料和架构图均来自网上， 如有侵权，将做删除处理。
参考资料：
[1]docs.vmware.com/en/VMware-T…
[2]hawq.apache.org/docs/usergu…
[3]cwiki.apache.org/confluence/…
[4]www.w3cschool.cn/impala/impa…
[5]Apache Kylin | 大数据分析型数据仓库
[6]Apache Kylin | Apache kylin4 新架构分享
[7]Apache Kudu - Introducing Apache Kudu
[8]help.aliyun.com/document_de…
[9]Design · Apache Druid
[10]Presto_SQL_on_Everything.pdf (trino.io)
[11]Introduction to Apache Doris - Apache Doris
▼
作者介绍
祁国辉
前 Oracle 云平台事业部电信行业技术总监 现任杭州石原子科技有限公司合伙人
【作者介绍】网名"atiger"，前 Oracle 云平台事业部电信行业技术总监。拥有超过25年数据库和数据仓库HK经验。曾创办著名数据仓库网站：www.dwway.com (数据仓库之路）。
如果您对我们的源码感兴趣，欢迎到我们的 GitHub 代码仓库阅读查看，觉得不错记得点个 Star 哦~
StoneDB 代码仓库：github.com/stoneatom/s…
StoneDB 社区官网：stonedb.io/
StoneDB-5.7-V1.0.2正式发布，新增RPM包，两分钟极速安装MySQL分析加速器~
