几个 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…. 提到了一个很有意识的点

1.上手快,使用方便
只需要几分钟就能使用 Drill。解压 Drill 软件在你的 Linux,Mac 或 Windows 笔记本电脑上运行本地的文件查询。无需设置任何基础设施或是定义 schemas。只需要指向数据,例如:数据在文件,目录,HBase 表和 Drill(PS:在 Drill 存在一个名为 employee.json 数据表)中。
$ tar -xvf apache-drill-.tar.gz
$ /bin/drill-embedded
0: jdbc:drill:zk=local> SELECT * FROM cp.`employee.json` LIMIT 5;

2.无模式的 JSON 模型
Drill 是目前第一个也是唯一的分布式 SQL 引擎,她不需要 schemas。她和 MongoDB,ElasticSearch 一样,是无模式的的 JSON 模型。无需定义和维护数据的转换(ETL)。Drill 能够自动解析数据的结构。
3.查询复杂,半结构化数据
使用 Drill 无模式的 JSON 模型,你可以查询复杂的半结构化数据。不需要在查询执行期间或在查询执行期间将数据进行平坦化或转换。Drill 还提供了直观的扩展 SQL 用于嵌套数据。这里是一个简单的查询一个 JSON 文件,来演示如何访问嵌套元素和数组:
SELECT * FROM (SELECT t.trans_id,
t.trans_info.prod_id[0] AS prod_id,
t.trans_info.purch_flag AS purchased
FROM `clicks/clicks.json` t) sq
WHERE sq.prod_id BETWEEN 700 AND 750 AND
sq.purchased = ‘true’
ORDER BY sq.prod_id;

第一个就是他可以跑在文件上,磁盘文件是一个没有经过什么结构化的东西,这也能跑,确实挺拼,第二个就是他可以跑在 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应用最多的是类似于广告分析创业公司Metamarkets中的应用场景,如广告分析、互联网广告系统监控以及网络监控等。当业务中出现以下情况时,Druid是一个很好的技术方案选择:

需要交互式聚合和快速探究大量数据时;
需要实时查询分析时;
具有大量数据时,如每天数亿事件的新增、每天数10T数据的增加;
对数据尤其是大数据进行实时分析时;
需要一个高可用、高容错、高性能数据库时。

后文也有提到,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…

3 主流OLAP系统对比分析
通过和其它同学交流,有一个感觉就是大家都觉得Kylin还不错,但并不是特别有信心,或者不知道非要用它的理由是什么,或者它和其它系统的对比是什么样的?这里也有部分测试结果可以和大家分享。

整个测试基于SSB的数据集,也是完全开源的,实际上是专门用于星型模型OLAP场景下的测试。整个测试数据集是非常标准的五张表,可以配置一些参数决定生成的数据集规模,然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括:Presto,Kylin1.3,Kylin1.5和Druid。数据规模包含千万、亿、十亿三种规模;维度个数为30个;指标个数为50个。典型的测试场景包括:上卷、下钻,和常用的聚合函数。

这里挑选了典型的五个查询场景:一个事实表的过滤和聚合;五张表全关联之后的查询;两个Count Dstinct指标和两个Sum指标;后面两个查询包含8~10个的维度过滤。

这张图是千万规模下的一个测试结果,包括了四个系统。我们在用Kylin或者其它系统之前没有专门用于OLAP分析的引擎,只能用通用的。Presto是其中表现非常好的引擎,但是在OLAP这种特定的场景下,可以看到不管跟Kylin还是Druid相比差的都比较多,所以前两个测试包含了Presto结果,后面就没有包含了

这里比较有趣的现象是在第三个查询,Kylin1.5反而比Kylin1.3要慢一些。这个地方我们还没有搞清楚是什么原因,后面会详细的看一下。当然这个也可以证明数据没有修改过,是真实的测试数据。

从后面的两个查询上可以看到,在千万规模的级别,和Druid还是有比较大的差距。这主要和它们的实现模式相关,因为Druid会把所有的数据预处理完以后都加载到内存里,在做一些小数据量聚合的时候,可以达到非常快的速度;但是Kylin要到HBase上读,相对来说它的性能要差一些,但也完全能满足需求。

在亿级的规模上情况又有了变化,还是看后面两个查询,Kylin1.3基本上是一个线性的增长,这个数据已经变得比较难看了,这是由于Kylin1.3在扫描HBase的时候是串行方式,但是Kylin1.5反而会有更好的表现,这是因为Kylin1.5引入了HBase并行Scan,大大降低了扫描的时间。Kylin1.5的数据会shard到不同的region上,在千万量级上数据量还比较小,没有明显的体现,但是上亿以后,随着数据量上升,region也变多了,反而能把并发度提上去。所以在这里可以看到Kylin1.5表现会更好。这里也可以看出,在数据量成数量级上升后,Kylin表现的更加稳定,在不同规模数据集上依然可以保持不错的查询性能。而Druid随着数据量的增长性能损失也成倍增长。

刚才是在性能方面做的一些分析,其实对于一个系统来说,性能只是一个方面,除此之外,我们也会去考量其它方面的情况,主要有以下四点。

第一,功能的完备性。刚才提到我们所有的数据必须是精确的,但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如Druid性能表现确实更好,但是它去重计数没有办法做到精确。

第二,系统的易用性。作为一个平台服务,不仅要把系统用起来,还要维护它,因此要考虑部署和监控的成本。这方面Kylin相对来说也是比较好的。Druid一个集群的角色是非常多的,如果要把这个系统用起来的话,可能光搭这个环境,起这些服务都要很长的时间。这个对于我们做平台来讲,实际上是一个比较痛的事。不管是在部署,还是加监控的时候,成本都是相对比较高的。另外一个查询接口方面,我们最熟悉或者最标准,最好用的当然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL,当然现在也有一些插件,但是在功能的完备性和数据的效率上都不如原生的支持。

第三,数据成本。刚才提到了有些数据需要做一些预处理,比如表的拉平或者表达式列的变换,除此之外还有一些格式的转化,比如有的系统只能读TEXT格式,这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询,这个时间中间有多长。数据存储和服务的时候需要多少机器资源,这个都可以归为数据成本,就是使用这个数据需要付出的成本。

第四,查询灵活性。经常有业务方问到,如果Cube没定义的话怎么办?现在当然查询只能失败。这个说明有的查询模式不是那么固定的,可能突然要查一个数,但以后都不会再查了。实际上在需要预定义的OLAP引擎上,这种需求普遍来讲支持都不是太好。

这张图是各个系统全方位的一个对比。

从查询效率上看,这里表现最不好的就是Presto,表现最好的应该是Druid和Kylin1.5,两者不相上下。从功能完备性上来讲,确实Presto语法和UDF等等是很完备的,Kylin会稍微差一些,但比Druid好一点。

系统易用性上区别不是太大,这里主要考虑有没有标准的SQL接口或者部署成本高不高,用户上手能不能更快,目前来看Druid接口上确实不够友好,需要去翻它的文档才知道怎么去写查询的语法。

在查询成本上,Presto是最好的,因为几乎不需要做什么特殊的处理,基本上Hive能读的数据Presto也都能读,所以这个成本非常低。Druid和Kylin的成本相对较高,因为都需要提前的预计算,尤其是Kylin如果维度数特别多,而且不做特别优化的话,数据量还是很可观的。

最后从灵活性上来讲, Presto只要SQL写出来怎么查都可以,Druid和Kylin都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。

刚才比较客观的对比了几个系统,接下来再总结一下Kylin的优势。

第一,性能非常稳定。因为Kylin依赖的所有服务,比如Hive、HBase都是非常成熟的,Kylin本身的逻辑并不复杂,所以稳定性有一个很好的保证。目前在我们的生产环境中,稳定性可以保证在99.99%以上。同时查询时延也比较理想。我们现在有一个业务线需求,每天查询量在两万次以上,95%的时延低于1秒,99%在3秒以内。基本上能满足我们交互式分析的需求。

第二,对我们特别重要的一点,就是数据的精确性要求。其实现在能做到的只有Kylin,所以说我们也没有什么太多其他的选择。

第三,从易用性上来讲,Kylin也有非常多的特点。首先是外围的服务,不管是Hive还是HBase,只要大家用Hadoop系统的话基本都有了,不需要额外工作。在部署运维和使用成本上来讲,都是比较低的。其次,有一个公共的Web页面来做模型的配置。相比之下Druid现在还是基于配置文件来做。这里就有一个问题,配置文件一般都是平台方或者管理员来管理的,没办法把这个配置系统开放出去,这样在沟通成本和响应效率上都不够理想。Kylin有一个通用的Web Server开放出来,所有用户都可以去测试和定义,只有上线的时候需要管理员再review一下,这样体验就会好很多。

第四,最后一点就是活跃开放的社区和热心的核心开发者团队,社区里讨论非常开放,大家可以提自己的意见及patch,修复bug以及提交新的功能等,包括我们美团团队也贡献了很多特性,比如写入不同的HBase集群等。这里特别要指出的是核心团队都是中国人,这是Apache所有项目里唯一中国人为主的顶级项目,社区非常活跃和热心,有非常多的中国工程师。特别是当你贡献越来越多的时候,社区会邀请成为committer等,包括我自己及团队成员也已经是Apache Kylin的committer。同时也非常高兴看到以韩卿为首的Apache Kylin核心团队在今年初成立的创业公司Kyligence,相信可以为整个项目及社区的发展带来更大的空间和未来。

还有这个 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/…

3. Pivotal的SQL on Hadoop方案
Pivotal的SQL on Hadoop方案是基于10多年来产品开发的成果价值,即投资研发Greenplum Database——Pivotal的旗舰分析数据仓库。Pivotal正是利用这一代码基础和深度数据管理专业知识来构建了业内最好的SQL on Hadoop企业引擎。然后,我们使用业内唯一一款基于代价的查询优化框架来增强其性能,该框架专为HDFS量身打造。

图2:将基于MPP的分析数据仓库用于SQL on Hadoop方案

该SQL on Hadoop产品称为HAWQ,全称Hadoop With Query(带查询Hadoop)。HAWQ使企业能够获益于经过锤炼的基于MPP的分析功能及其查询性能,同时利用Hadoop堆栈。HAWQ可与其它传统的SQL on Hadoop引擎(如图1所示)共存于一个分析堆栈。

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

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

作者:interma
链接:https://www.zhihu.com/question/54597742/answer/140549982
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

但HAWQ相对其他Sql on Hadoop产品,也有许多明显的优点:非常完善的Sql支持SQL-92, SQL-99, SQL-2003, OLAP extension。支持的sql列表:http://hdb.docs.pivotal.io/201/hawq/reference/SQLCommandReference.html原生Hadoop支持YARN能和各类Hadoop生态组件进行整合支持各类常见常见的文件格式(by PXF)。优异的OLAP查询性能Pivotal Orca优化器:Orca: A Modular Query Optimizer Architecture for Big Data sigmod2014Benchmark: Pivotal HAWQ Benchmark Demonstrates Up To 21x Faster Performance…先进的架构(对比传统MPP)GPDB(PostgreSql) + HDFS针对传统MPP架构问题进行了改进:Apache HAWQ: Next Step In Massively Parallel Processing 一定程度市场认可(主要是欧美传统企业,国内市场目前尚待开拓):Pivotal Big Data Suite | Big Data非玩票项目除了Apache社区之外,背后还有Pivotal进行商业支持。 另外为HAWQ打一下广告:它是少数几个完全由国人主导的Apache项目,无论是参与社区,或是加入Pivotal公司,都非常非常欢迎~

===========

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

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

Phoenix最值得关注的一些特性有:

嵌入式的JDBC驱动,实现了大部分的java.sql接口,包括元数据API
可以通过多部行键或是键/值单元对列进行建模
完善的查询支持,可以使用多个谓词以及优化的扫描键
DDL支持:通过CREATE TABLE、DROP TABLE及ALTER TABLE来添加/删除列
版本化的模式仓库:当写入数据时,快照查询会使用恰当的模式
DML支持:用于逐行插入的UPSERT VALUES、用于相同或不同表之间大量数据传输的UPSERT SELECT、用于删除行的DELETE
通过客户端的批处理实现的有限的事务支持
单表——还没有连接,同时二级索引也在开发当中
紧跟ANSI SQL标准

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

2.1 Coprocessor
HBase的协处理器主要受Google BigTable的影响,具体可参考Dean-Keynote-Ladis2009-page 66-67。 对于HBase来说,引入Coprocessor也是为了提供更好的并行计算能力,而无需依赖于Hadoop的MapReduce。同时,基于Coprocessor,可以更好的实现二级索引、复杂过滤规则、权限访问控制等更接地气的特性。Coprocessor有两种类型,Observer和EndPoint。

前者Observer,类似于RDBMS的触发器,主要作用于RegionServer服务端,通过重载Coprocessor框架的Upcall函数插入用户自己的逻辑,这些逻辑只有在固定的事件发生时才会被触发调用执行,主要有三类hook接口:RegionObserver、WALObserver和MasterObserver。RegionObserver提供了一些数据层操作事件的hook,如Put、Get、Delete和Scan等,在每个操作发生或结束时,会触发调用一些前置的Hook(pre+操作,如preGet)或后置的Hook(post+操作,如postGet);WALObserver提供了WAL相关的Hook;MasterObserver提供了HMaster相关的Hook。

后者EndPoint类似于RDBMS的存储过程,主要作用于客户端,客户端可以调用这些EndPoint执行一段Server端代码,并将Server端代码结果返回给客户端进一步处理,如常见聚合操作,找一张大表某个字段的最大值,如果不用Coprocesser则只能全表扫描,在客户端遍历所有结果找出最大值,且只能利用有限的客户端资源进行迭代计算,无法利用上HBase的并发计算能力;如果用了Coprocessor,则client端可在RegionServer端执行统计每个Region最大值的逻辑,并将Server端结果返回客户端,再找出所有Server端所返回的最大值中的最大值得到最终结果,很明显,这种方式尽量将统计执行下放到Server端,Client端只执行一些最后的聚合,大幅提高了统计效率;还有一个很常见的需求可能就是统计表的行数,其逻辑和上面一样,具体可参考Coprocessor Introduction,在这里就不展开了,后面有机会针对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…

The Base LSM Algorithm从概念上说,最基本的LSM是很简单的 。将之前使用一个大的查找结构(造成随机读写,影响写性能),变换为将写操作顺序的保存到一些相似的有序文件(也就是sstable)中。所以每个文件包 含短时间内的一些改动。因为文件是有序的,所以之后查找也会很快。文件是不可修改的,他们永远不会被更新,新的更新操作只会写到新的文件中。读操作检查很 有的文件。通过周期性的合并这些文件来减少文件个数。

作者:wuxinliulei
链接:https://www.zhihu.com/question/19887265/answer/78839142
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

===========

另外,还看到了华为的 CarbonData

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

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

CarbonData基础特性

多维数据聚集:在入库时对数据按多个维度进行重新组织,使数据在“多维空间上更内聚”,在存储上获得更好的压缩率,在计算上获得更好的数据过滤效率。
带索引的列存文件结构:首先,CarbonData为多类场景设计了多个级别的索引,并融入了一些搜索的特性,有跨文件的多维索引,文件内的多维索引,每列的minmax索引,以及列内的倒排索引等。其次,为了适应HDFS的存储特点,CarbonData的索引和数据文件存放在一起,一部分索引本身就是数据,另一部分索引存放在文件的元数据结构中,他们都能随HDFS提供本地化的访问能力。
列组:整体上,CarbonData是一种列存结构,但相对于行存来说,列存结构在应对明细数据查询时会有数据还原代价高的问题,所以为了提升明显数据查询性能,CarbonData支持列组的存储方式,用户可以把某些不常作为过滤条件但又需要作为结果集返回的字段作为列组来存储,经过CarbonData编码后会将这些字段使用行存的方式来存储以提升查询性能。
数据类型:目前CarbonData支持所有数据库的常用基本类型,以及Array,Struct复杂嵌套类型。同时社区也有人提出支持Map数据类型,我们计划未来添加Map数据类型。
压缩:目前CarbonData支持Snappy压缩,压缩是针对每列分别进行的,因为列存的特点使得压缩非常高效。数据压缩率基于应用场景不同一般在2到8之间。
Hadoop集成:通过支持InputFormat/OutputFormat接口,CarbonData可以利用Hadoop的分布式优点,也能在所有以Hadoop为基础的生态系统中使用。
CarbonData高级特性

可计算的编码方式:除了常见的Delta,RLE,Dictionary,BitPacking等编码方式外,CarbonData还支持将多列进行联合编码,以及应用了全局字典编码来实现免解码的计算,计算框架可以直接使用经过编码的数据来做聚合,排序等计算,这对需要大量shuffle的查询来说性能提升非常明显。
与计算引擎联合优化:为了高效利用CarbonData经过优化后的数据组织,CarbonData提供了有针对性的优化策略,目前CarbonData社区首先做了和Spark的深度集成,其中基于SparkSQL框架增强了过滤下压,延迟物化,增量入库等特性,同时支持所有DataFrame API。相信未来通过社区的努力,会有更多的计算框架与CarbonData集成,发挥数据组织的价值。

3 thoughts on “几个 hadoop 生态下 SQL 引擎的区别

  1. Pingback: 再谈 SQL 引擎 | ZRJ

Leave a Reply to nikolali Cancel reply

Your email address will not be published. Required fields are marked *