几个 hadoop 生态下 SQL 引擎的区别

hive、spark SQL 这个太熟就不多说了，kylin 是基于预先算好存 hbase 来实现秒回的，属于抢跑型选手，这个也不展开对比

重点会看看这几个：

• Impala
• Drill
• Presto
• Druid
• HAWQ
• Phoniex

网络上看这些东西的时候基本都没个靠谱和详细的解释，还是得靠自己来拼

https://www.zhihu.com/question… 这个上面的一些答案算是说的挺不错的了

===========

首先是 Impala，参考这个文章， https://segmentfault.com/a/119… ，关于 impala 的起源：

 Impala是Cloudera公司主导开发的新型查询系统，它提供 SQL 语义，能够查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但是由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性；相比之下，Impala的最大特点也是最大卖点就是它的快速。那么Impala如何实现大数据的快速查询呢？在回答这个问题之前，我们需要先介绍Google的Dremel系统[1]，因为Impala最开始就是参照Dremel系统进行设计的。
 Dremel是Google的交互式数据分析系统，它构建于Google的GFS（Google File System）等系统之上，支撑了Google的数据分析服务BigQuery等诸多服务。Dremel的技术亮点主要有两个：一个是实现了嵌套型数据的列存储；二是使用了多层查询树，使得任务可以在数千个节点上的并行执行和聚合结果。列存储在关系型数据库中并不陌生，它可以减少查询时处理的数据量，有效的提升查询效率。Dremel的列存储的不同之处在于它针对的并不是传统的关系数据，而是针对嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式，查询时根据查询条件读取需要的列，然后进行条件过滤，输出时再将列组装成嵌套结构的记录输出，记录的正向和反向转换都通过高效的状态机实现。另一方面，Dremel的多层查询树则借鉴了分布式搜索引擎的设计，查询树的根节点负责接收查询，并将查询分发到下一层节点，底层节点负责具体的数据读取和查询执行，然后将结果返回上层节点。关于Dremel技术实现上的更多信息，读者可以参阅[9]。 

关于其工作原理

Impala其实就是Hadoop的Dremel，Impala使用的列存储格式是Parquet。Parquet实现了Dremel中的列存储，未来还将支持Hive并添加字典编码，游程编码等功能。Impala的系统架构如图一所示。Impala使用了Hive 的SQL接口（包括SELECT，INSERT，Join等操作），但目前只实现了Hive的SQL语义的子集（例如尚未对UDF提供支持），表的元数据信息存储在Hive的Metastore中。StateStore是Impala的一个子服务，用来监控集群中各个节点的健康状况，提供节点注册，错误检测等功能。Impala在每个节点运行了一个后台服务impalad，impalad用来响应外部请求，并完成实际的查询处理。Impalad主要包含Query Planner，Query Coordinator和Query Exec Engine三个模块。QueryPalnner接收来自SQL APP和 ODBC的查询，然后将查询转换为许多子查询，Query Coordinator将这些子查询分发到各个节点上，由各个节点上的Query Exec Engine负责子查询的执行，最后返回子查询的结果，这些中间结果经过聚集之后最终返回给用户。

其对比 hive

在Cloudera的测试中，Impala的查询效率相比Hive，有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有如下几方面的原因：

Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。

省掉了MapReduce作业启动的开销。MapReduce启动task的速度是很慢的（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。

Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想，从新另起炉灶，因此可以做更多的查询优化，从而能省掉不必要的shuffle，sort等开销；

通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销；

用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令；

使用了支持Data locality的I/O调度机制，尽可能的将数据和计算分配在同一台机器上进行，减少了网络开销；

虽然Impala是参照Dremel来实现，但是Impala也有一些自己的特色，例如Impala不仅仅支持Parquet格式，同时也可以直接处理文本，SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于，Impala是开源的，再加上Cloudera在Hadoop领域的领导地位，其生态圈有很大可能会在将来快速成长。可以预见在不久的未来，Impala很可能像之前的Hadoop和Hive一样在大数据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然，用户从Hive上迁移到Impala上来是需要时间的，而且Impala也只是刚刚发布1.0版，虽然号称已经可以稳定的在生产环境上运行，但相信仍然有很多可改进的空间[7]。需要说明的是，Impala并不是用来取代已有的MapReduce系统，而是作为MapReduce的一个强力补充，总的来说Impala适合用来处理输出数据适中或比较小的查询，而对于大数据量的批处理任务，MapReduce依然是更好的选择。另外一个花边消息是，Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发，可见Google确实为大数据的流行出钱出力。

但是在这里有提到 https://blog.csdn.net/xiangxiz…

架构是完美的，现实是骨感的，实际使用过程中，Impala性能和稳定性还差得远。尤其是Impala虽然号称支持HDFS和HBASE，但实际使用中发现，运行在HDFS上，性能还差强人意，运行在HBASE上性能很差，另外还经常有内存溢出之类的问题尚待解决。

而看下来，感觉 impala 最大的问题还是跟 cdh 绑定，是有 cloudera 来推的，这样可能就局限了点

其官网介绍在这里 https://impala.apache.org/over…

===========

然后是 drill，在这里 https://drill.smartloli.org/1…. 提到了一个很有意识的点

第一个就是他可以跑在文件上，磁盘文件是一个没有经过什么结构化的东西，这也能跑，确实挺拼，第二个就是他可以跑在 json 上，并且还提供了一个查询的 SQL 语法，json 是一个很自由的嵌套型数据结构，这么跑，性能还能有保证吗

在这里 https://drill.smartloli.org/2…. 提到 drill 也是参考了 google dremel ，那架构上应该跟 impala 差不多

在这里 https://blog.csdn.net/weixin_3… 也介绍了下 drill 的架构和工作原理，总的来说还是一个 mpp 的架构

那么很自然的问题就来了，冤家路窄狭路相逢， impala 和 drill 的对比表现怎么样呢

性能评测没找到对应的直接资料，原理分析看到一个文章 https://www.rittmanmead.com/bl…

 Similarities and Differences  As we saw above, Drill and Impala have a similar structure – both take advantage of always on daemons (faster compared to the start of a MapReduce job) and assume an optimistic query execution passing results in cache. The code compilation and the distributed engine are also common to both, which are optimized for columnar storage types like Parquet.
There are, however, several differences. Impala works only on top of the Hive metastore while Drill supports a larger variety of data sources and can link them together on the fly in the same query. For example, implicit schema-defined files like JSON and XML, which are not supported natively by Impala, can be read immediately by Drill.  Drill usually doesn’t require a metadata definition done upfront, while for Impala, a view or external table has to be declared before querying. Following this point there is no concept of a central and persistent metastore, and there is no metadata repository to manage just for Drill. In OBIEE’s world, both Impala and Drill are supported data sources. The same applies to Data Visualization Desktop.  Impala Drill
The aim of this article isn’t a performance-wise comparison since those depends on a huge amount of factors including data types, file format, configurations, and query types. A comparison dated back in 2015 can be found here. Please be aware that there are newer versions of the tools since this comparison, which bring a lot of changes and improvements for both projects in terms of performance. 

其中提到一个文章 https://allegro.tech/2015/06/f… 这里有一个评测结果

 Summary  When evaluating benchmark results, Hive MapReduce presented the poorest performance which was not a surprise. The whole hackathon event had been organised to evaluate better solutions and Hive MapReduce was a baseline to find potential improvements. The more complex queries were run, the worse performance could have been observed in that engine. The only exception to that rule were Allegro-analytical queries number 5. and 6. Those performed worse using Presto. Impala turned to be the performance leader in the most queries. At the end we sum up our results obtained for all the engines. Please note that these are our impressions based on our queries and functionality needs.
Hive on Spark — The only technology which we were not able to set up. Important for further evaluations in the future as it runs on Hive and does not require significant changes in the query structure.  Hive on Tez — The tool that does a great job on our Hadoop cluster. It allowed to run all queries and performance results appeared to be stable and satisfactory.  Spark SQL — Spark SQL turned out to be useful, despite it lacks a row_num function. Surprisingly it still suffers some performance issues in some queries although performing better than average in general.  Presto — Convenient to use, most of the queries run easily with small modifications and work stable. We expected better performance than achieved. This could have been influenced by data locality problems as Presto was run standalone and had to access HDFS data remotely.  Impala — The best benchmark performer which additionally runs on YARN. On the other hand it still lacks some basic functionalities and has some limitations. It does not support CTAS (Create Table as Select) nor composite or nested data types. It also behaves unstable when running out of memory and the obtained execution times seem to have the highest variance among the competitors.  Drill — If it is able to execute a query, it does so extremely fast. The benchmark results are comparable to Impala despite the fact that Drill has been set up on machines external to HDFS. Unfortunately we do not consider Drill as production ready yet as it has several gaps in the query language, especially the capabilities and stability of user defined functions which are already used in lots of our Hive queries.  We already use Hive MapReduce, Hive Tez and SparkSQL on our cluster. None of the evaluated technologies, absent in our Hadoop ecosystem, combined performance and functionalities good enough to drive a change in our ecosystem. Some performed better then what we already have but the performance change is not a significant overall boost. What could be gained is an improvement which requires deep architectural changes like data formats, separate infrastructure or even disabling security. After the hackathon we decided to focus on Hive on Tez and Spark SQL. We believe that with a limited amount of time, we can tune them to run really stable and more efficiently than now.
The evaluated projects grow rapidly and we are sure (and even hope) that our results get out of date soon. We will surely repeat this evaluation in the future. 

===========

接下来轮到 presto， 从上面的评测来看，presto 的工作原来应该跟 impala 和 drill 差不多，在这里 https://tech.meituan.com/prest… 有一个背景介绍

Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在以前，Facebook的科学家和分析师一直依靠Hive来做数据分析。但Hive使用MapReduce作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用Hive进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作Facebook庞大的数据仓库。

2012年开始试用的一些外部项目都不合适，他们决定自己开发，这就是Presto。2012年秋季开始开发，目前该项目已经在超过 1000名Facebook雇员中使用，运行超过30000个查询，每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。

本文首先介绍Presto从用户提交SQL到执行的这一个过程，然后尝试对Presto实现实时查询的原理进行分析和总结，最后介绍Presto在美团的使用情况。

从其原理看，跟前面的 impala drill 确实差不多，但是主要是诞生背景，是在试用了外部的项目不满意后才开发，所以应该是实际使用结果上会更好才对，上述的文末，也提到对比

选择presto的原因

2013年我们也用过一段时间的impala，当时impala不支持线上1.x的hadoop社区版，所以搭了一个CDH的小集群，每天将大集群的热点数据导入小集群。但是hadoop集群年前完成升级2.2之后，当时的impala还不支持2.2 hadoop版本。而Presto刚好开始支持2.x hadoop社区版，并且Presto在Facebook 300PB大数据量的环境下可以成功的得到大量使用，我们相信它在美团也可以很好的支撑我们实时分析的需求，于是决定先上线测试使用一段时间。

对比结果可以看上面 drill 那段

===========

Druid 在这里 http://www.infoq.com/cn/news/2… 提到了 druid 的背景

后文也有提到，Druid的主要贡献者包括广告分析创业公司，不过，这其中看到一个很引人注目的点，在 https://yuzhouwan.com/posts/58… 提到

实时数据注入

Druid 支持 流数据的注入，并提供了 数据的事件驱动，保证在 实时和离线环境下事件的 时效性 和 统一性

并且，在 druid 的介绍中，没有看到对 hadoop 和 hdfs 的过多依赖，他应该是用自己的存储的

在这里 http://lxw1234.com/archives/20… 有一个简单的架构说明

 2.1 Overlord Node (Indexing Service)  Overlord会形成一个加载批处理和实时数据到系统中的集群，同时会对存储在系统中的数据变更（也称为索引服务）做出响应。另外，还包含了Middle Manager和Peons，一个Peon负责执行单个task，而Middle Manager负责管理这些Peons。
2.2 Coordinator Node  监控Historical节点组，以确保数据可用、可复制，并且在一般的“最佳”配置。它们通过从 MySQL 读取数据段的元数据信息，来决定哪些数据段应该在集群中被加载，使用Zookeeper来确定哪个Historical节点存在，并且创建Zookeeper条目告诉Historical节点加载和删除新数据段。
2.3 Historical Node  是对“historical”数据（非实时）进行处理存储和查询的地方。Historical节点响应从Broker节点发来的查询，并将结果返回给broker节点。它们在Zookeeper的管理下提供服务，并使用Zookeeper监视信号加载或删除新数据段。
2.4 Broker Node  接收来自外部客户端的查询，并将这些查询转发到Realtime和Historical节点。当Broker节点收到结果，它们将合并这些结果并将它们返回给调用者。由于了解拓扑，Broker节点使用Zookeeper来确定哪些Realtime和Historical节点的存在。
2.5 Real-time Node  实时摄取数据，它们负责监听输入数据流并让其在内部的Druid系统立即获取，Realtime节点同样只响应broker节点的查询请求，返回查询结果到broker节点。旧数据会被从Realtime节点转存至Historical节点。
2.6 ZooKeeper  为集群服务发现和维持当前的数据拓扑而服务；
2.7 MySQL  用来维持系统服务所需的数据段的元数据；
2.8 Deep Storage  保存“冷数据”，可以使用HDFS。 

但是看这些说明其实只能简单的了解到他的逻辑结构，对于这些组件到底是怎么实现的，其实还是没什么概念，网上对 druid 的相关资料不多，这里 https://www.jianshu.com/c/6cb0… 有一个翻译版，但是其实如果能耐下性子来读，翻译版还是不如读原文版的好 http://druid.io/docs/latest/de…

关于 druid 和 presto 以及 kylin 的对比，美团这里有一个文章， http://www.infoq.com/cn/articl…

还有这个 PPT 也是总结的很不错的， http://www.ouyangchen.com/wp-c…

另外，在这里 https://strata.oreilly.com.cn/… 提到了一个用法

除此之外，为了填补Druid没有SQL接口的空缺，我们引入了Drill和Druid进行集成。Drill提供了标准的SQL接口，以及可扩展的分布式查询引擎。我们用drill替代了Druid的broker，获得了支持标准SQL以及支持更复杂Query的能力，比如具有超大结果集的group by和join查询。同时，通过对Drill + Parquet，Drill + Druid，Druid broker这三者进行性能对比，我们发现Drill + Druid具有最好的表现。

===========

HAWQ 这个东西的产生背景参考这里 https://blog.csdn.net/wzy0623/…

HAWQ 作为一个搞 RDBMS 的厂商做出来的东西，自有其特点，例如支持丰富和兼容的 SQL 语法，优化器是基于代价的优化器来搞的

在这里 https://www.zhihu.com/question… 也有一些点评

===========

Phoniex 是一个构建在 hbase 之上的引擎，并且不局限于 olap，而是更偏向于 oltp，应该说，phoenix 主要是为了让 hbase 用起来更像一个 sql，从这个角度来说，其实应该是跟 tidb 来对比的

其架构应该比较好理解，就是基于 hbase 的原生能力，封装了一层 sql 引擎，在这里 http://www.infoq.com/cn/news/2… 提到

在这里 https://www.cnblogs.com/ballwq… 介绍了 hbase 的 coprocessor

但是也提到

最新版本对HBase、Hadoop等有严格版本控制，对于已经用上HBase的业务来说要升级HBase版本适配Phoenix代价太大

与HBase强相关，作为HBase中的一个组件启动，HBase元数据容易遭到破坏

官方提供的创建索引方法，容易导致插入失败，查询失败，程序崩溃等问题

所以还是不够成熟和稳定

===========

另外，查资料的过程中，还看到了 google dremel，这个东西又和 f1 spanner 有什么区别联系呢

关于 dremel 可以看到这里 http://www.yankay.com/google-d…

在这里 https://blog.csdn.net/x802796/… 有提到

GOOGLE的分布式数据库系统从BIGTABLE的正式推出后，先后对外发布了Bigtable、Dremel、 Spanner等不同的分布式数据库产品，有的是引入新的设计实现，有的是针对原有的技术进行改进和优化，用于满足不同的GOOGLE的应用场景，支持日益增加的数据量管理要求。

GOOGLE分布式数据库技术，从个人理解看，可以分为三个阶段，第一阶段以Bigtable产品为代表，实现了数据的分布式存储、行数据的事务性管理和较好的扩展性，从存储WEB页面而生，创造性提出了KEY-VALUE这种MAP数据结构，并广泛应用到GOOGLE的各种应用中，与GOOGLE的MapReduce GFS技术搭配，构成了GOOGLE分布式云计算的三架马车，对应开源社区推出HBASE产品，也在近年得到了广泛应用。

第二个阶段以Dremel产品为代表，Dremel产品采用了与Bigtable不同的数据结构，立足实时对于海量数据进行分析，据说在秒级可以完成PB级别的数据分析和处理，可以做是分布式数据库实时处理的杰作，其实时处理能力达到令人惊艳的速度。

第三阶段以Spanner数据库技术为代表，Spanner数据库在可以做到多数据表事务一致性管理，利用原子时钟（TrueTime）和Paxos协议解决了分布式数据库多表事务一致性管理的难题，打破的CAP不可三者兼得的理论神话，使得分布式数据库技术得到了革命性的进步。

严格来讲Dremel与Bigtable和Spanner解决的问题有所不同，Dremel侧重于对应海量数据的实时处理，而Bigtable和Spanner更侧重于传统的关系型数据库支持功能对齐和替换，并不是简单产品替换关系。从GOOGLE的分布式数据库技术的发展历程看，这些技术得以成功推出，有创造性的新锐视角和解决方案，更有其坚持在廉价PC服务器上面构筑海量数据处理系统的理想和情怀，更有起高超的技术实力和团队合作，这些因素的结合，使得技术难关被不断的突破，分布式数据库产品得以大成，这些产品的确值得技术人员去深入学习和体会。

这个是个系列文章，讲得挺不错的

GOOGLE分布式数据库技术演进研究–从Bigtable、Dremel到Spanner

（一） https://blog.csdn.net/x802796/…

（二） https://blog.csdn.net/x802796/…

（三） https://blog.csdn.net/x802796/…

而目前国人很火的 tikv 和 tidb 就是对 spanner 的一个开源实现

顺带说一下，不管是 hbase 还是 tikv，其底层的 lsm tree 也是一个很有意思的东西，可以看到这里 https://www.zhihu.com/question…

===========

另外，还看到了华为的 CarbonData

carbondata 其实只是一个 hive 上的文件格式，竞品是 parquet，目标是为了实现秒级的 olap 查询

在这里 http://www.infoq.com/cn/news/2… 提到