开源大数据查询分析引擎

引言

 

大数据查询分析是云计算中核心问题之一，自从Google在2006年以前的几篇论文奠基云计算领域基础，尤为是GFS、Map-Reduce、Bigtable被称为云计算底层技术三大基石。GFS、Map-Reduce技术直接支持了Apache Hadoop项目的诞生。Bigtable和Amazon Dynamo直接催生了NoSQL这个崭新的数据库领域，撼动了RDBMS在商用数据库和数据仓库方面几十年的统治性地位。FaceBook的Hive项目是创建在Hadoop上的数据仓库基础构架，提供了一系列用于存储、查询和分析大规模数据的工具。当咱们还浸淫在GFS、Map-Reduce、Bigtable等Google技术中，并进行理解、掌握、模仿时，Google在2009年以后，连续推出多项新技术，包括：Dremel、Pregel、Percolator、Spanner和F1。其中，Dremel促使了实时计算系统的兴起，Pregel开辟了图数据计算这个新方向，Percolator使分布式增量索引更新成为文本检索领域的新标准，Spanner和F1向咱们展示了跨数据中心数据库的可能。在Google的第二波技术浪潮中，基于Hive和Dremel，新兴的大数据公司Cloudera开源了大数据查询分析引擎Impala，Hortonworks开源了Stinger，Fackbook开源了Presto。相似Pregel，UC Berkeley AMPLAB实验室开发了Spark图计算框架，并以Spark为核心开源了大数据查询分析引擎Shark。因为某电信运营商项目中大数据查询引擎选型需求，本文将会对Hive、Impala、Shark、Stinger和Presto这五类主流的开源大数据查询分析引擎进行简要介绍以及性能比较，最后进行总结与展望。Hive、Impala、Shark、Stinger和Presto的进化图谱如图1所示。

 

 
图1. Impala、Shark、Stinger和Presto的进化图谱

当前主流引擎简介

 

基于Map-Reduce模式的Hadoop擅长数据批处理，不是特别符合即时查询的场景。实时查询通常使用MPP (Massively Parallel Processing)的架构，所以用户须要在Hadoop和MPP两种技术中选择。在Google的第二波技术浪潮中，一些基于Hadoop架构的快速SQL访问技术逐步得到人们关注。如今有一种新的趋势是MPP和Hadoop相结合提供快速SQL访问框架。最近有四个很热门的开源工具出来：Impala、Shark、Stinger和Presto。这也显示了大数据领域对于Hadoop生态系统中支持实时查询的指望。整体来讲，Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎，可是它们的技术侧重点彻底不一样。并且它们也不是为了替换Hive而生，Hive在作数据仓库时是很是有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具，各有不一样的侧重适应面，但从客户端使用来看它们与Hive有不少的共同之处，如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系如图2所示。Hive适用于长时间的批处理查询分析，而Impala、Shark、Stinger和Presto适用于实时交互式SQL查询，它们给数据分析人员提供了快速实验、验证想法的大数据分析工具。能够先使用Hive进行数据转换处理，以后使用这四个系统中的一个在Hive处理后的结果数据集上进行快速的数据分析。下面，从问题域出发简单介绍Hive、Impala、Shark、Stinger和Presto：

 

1) Hive，披着SQL外衣的Map-Reduce。Hive是为方便用户使用Map-Reduce而在外面封装了一层SQL，因为Hive采用了SQL，它的问题域比Map-Reduce更窄，由于不少问题，SQL表达不出来，好比一些数据挖掘算法，推荐算法、图像识别算法等，这些仍只能经过编写Map-Reduce完成。

 

2) Impala：Google Dremel的开源实现（Apache Drill相似），由于交互式实时计算需求，Cloudera推出了Impala系统，该系统适用于交互式实时处理场景，要求最后产生的数据量必定要少。

 

3) Shark/Spark：为了提升Map-Reduce的计算效率，Berkeley的AMPLab实验室开发了Spark，Spark可看作基于内存的Map-Reduce实现，此外，伯克利还在Spark基础上封装了一层SQL，产生了一个新的相似Hive的系统Shark。

 

4) Stinger Initiative（Tez optimized Hive）：Hortonworks开源了一个DAG计算框架Tez，Tez能够理解为Google Pregel的开源实现，该框架能够像Map-Reduce同样，能够用来设计DAG应用程序，但须要注意的是，Tez只能运行在YARN上。Tez的一个重要应用是优化Hive和PIG这种典型的DAG应用场景，它经过减小数据读写IO，优化DAG流程使得Hive速度提供了不少倍。

 

5) Presto：FaceBook于2013年11月份开源了Presto，一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、链接（join）和窗口函数（window functions)。Presto设计了一个简单的数据存储的抽象层，来知足在不一样数据存储系统（包括HBase、HDFS、Scribe等）之上均可以使用SQL进行查询。

 

 
图2. Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系

 

当前主流引擎架构

 

Hive

Hive是基于Hadoop的一个数据仓库工具，能够将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，能够将SQL语句转换为Map-Reduce任务进行运行，十分适合数据仓库的统计分析。其架构如图3所示，Hadoop和Map-Reduce是Hive架构的根基。Hive架构包括以下组件：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。
 

图3. Hive架构

Impala架构

 

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，它能够当作是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体。Impala没有再使用缓慢的Hive&Map-Reduce批处理，而是经过使用与商用并行关系数据库中相似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），能够直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大下降了延迟，其架构如图4所示，Impala主要由Impalad，State Store和CLI组成。Impalad与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator经过JNI调用java前端解释SQL查询语句，生成查询计划树，再经过调度器把执行计划分发给具备相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果经过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持链接，用于肯定哪一个Impalad是健康和能够接受新的工做。Impala State Store跟踪集群中的Impalad的健康状态及位置信息，由state-stored进程表示，它经过建立多个线程来处理Impalad的注册订阅和与各Impalad保持心跳链接，各Impalad都会缓存一份State Store中的信息，当State Store离线后，由于Impalad有State Store的缓存仍然能够工做，但会由于有些Impalad失效了，而已缓存数据没法更新，致使把执行计划分配给了失效的Impalad，致使查询失败。CLI提供给用户查询使用的命令行工具，同时Impala还提供了Hue，JDBC，ODBC，Thrift使用接口。

 

 
图4. Impala架构

 

Shark架构

 

Shark是UC Berkeley AMPLAB开源的一款数据仓库产品，它彻底兼容Hive的HQL语法，但与Hive不一样的是，Hive的计算框架采用Map-Reduce，而Shark采用Spark。因此，Hive是SQL on Map-Reduce，而Shark是Hive on Spark。其架构如图4所示，为了最大程度的保持和Hive的兼容性，Shark复用了Hive的大部分组件，以下所示：

 

1) SQL Parser&Plan generation: Shark彻底兼容Hive的HQL语法，并且Shark使用了Hive的API来实现query Parsing和 query Plan generation，仅仅最后的Physical Plan execution阶段用Spark代替Hadoop Map-Reduce；

 

2) metastore：Shark采用和Hive同样的meta信息，Hive里建立的表用Shark可无缝访问；

 

3) SerDe: Shark的序列化机制以及数据类型与Hive彻底一致；

 

4) UDF: Shark可重用Hive里的全部UDF。经过配置Shark参数，Shark能够自动在内存中缓存特定的RDD（Resilient Distributed Dataset），实现数据重用，进而加快特定数据集的检索。同时，Shark经过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一块儿，最大化RDD的重复使用；

 

5) Driver：Shark在Hive的CliDriver基础上进行了一个封装，生成一个SharkCliDriver，这是shark命令的入口；

 

6) ThriftServer：Shark在Hive的ThriftServer（支持JDBC/ODBC）基础上，作了一个封装，生成了一个SharkServer，也提供JDBC/ODBC服务。

 

 
图5. Shark架构

 

Spark是UC Berkeley AMP lab所开源的类Hadoop Map-Reduce的通用的并行计算框架，Spark基于Map-Reduce算法实现的分布式计算，拥有Hadoop Map-Reduce所具备的优势；但不一样于Map-Reduce的是Job中间输出和结果能够保存在内存中，从而再也不须要读写HDFS，所以Spark能更好地适用于数据挖掘与机器学习等须要迭代的Map-Reduce的算法。其架构如图6所示：

 

 
图6. Spark架构

与Hadoop的对比，Spark的中间数据放到内存中，对于迭代运算效率更高，所以Spark适用于须要屡次操做特定数据集的应用场合。须要反复操做的次数越多，所需读取的数据量越大，受益越大，数据量小可是计算密集度较大的场合，受益就相对较小。Spark比Hadoop更通用，Spark提供的数据集操做类型有不少种（map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等），而Hadoop只提供了Map和Reduce两种操做。Spark能够直接对HDFS进行数据的读写，一样支持Spark on YARN。Spark能够与Map-Reduce运行于同集群中，共享存储资源与计算，数据仓库Shark实现上借用Hive，几乎与Hive彻底兼容。

Stinger架构

 

Stinger是Hortonworks开源的一个实时类SQL即时查询系统，声称能够提高较Hive 100倍的速度。与Hive不一样的是，Stinger采用Tez。因此，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一个重要做用是优化Hive和PIG这种典型的DAG应用场景，它经过减小数据读写IO，优化DAG流程使得Hive速度提供了不少倍。其架构如图7所示， Stinger是在Hive的现有基础上加了一个优化层Tez（此框架是基于Yarn），全部的查询和统计都要通过它的优化层来处理，以减小没必要要的工做以及资源开销。虽然Stinger也对Hive进行了较多的优化与增强，Stinger整体性能仍是依赖其子系统Tez的表现。而Tez是Hortonworks开源的一个DAG计算框架，Tez能够理解为Google Pregel的开源实现，该框架能够像Map-Reduce同样，用来设计DAG应用程序，但须要注意的是，Tez只能运行在YARN上。

 

 
图7. Stinger架构

 

Presto架构

 

2013年11月Facebook开源了一个分布式SQL查询引擎Presto，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL子集，包括复杂查询、聚合、链接和窗口函数。其简化的架构如图8所示，客户端将SQL查询发送到Presto的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一块儿，将任务分配给那些里数据最近的节点，而后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。Presto的运行模型与Hive有着本质的区别。Hive将查询翻译成多阶段的Map-Reduce任务，一个接着一个地运行。每个任务从磁盘上读取输入数据而且将中间结果输出到磁盘上。然而Presto引擎没有使用Map-Reduce。它使用了一个定制的查询执行引擎和响应操做符来支持SQL的语法。除了改进的调度算法以外，全部的数据处理都是在内存中进行的。不一样的处理端经过网络组成处理的流水线。这样会避免没必要要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。 这样的方式会大大的减小各类查询的端到端响应时间。同时，Presto设计了一个简单的数据存储抽象层，来知足在不一样数据存储系统之上均可以使用SQL进行查询。存储链接器目前支持除Hive/HDFS外，还支持HBase、Scribe和定制开发的系统。
 

图8. Presto架构

 

性能评测总结

 

经过对Hive、Impala、Shark、Stinger和Presto的评测和分析，总结以下：

 

1) 列存储通常对查询性能提高明显，尤为是大表是一个包含不少列的表。例如，从Stinger（Hive 0.11 with ORCFile）VS Hive，以及Impala的Parquet VS Text file；

 

2) 绕开MR计算模型，省去中间结果的持久化和MR任务调度的延迟，会带来性能提高。例如，Impala，Shark，Presto要好于Hive和Stinger，但这种优点随着数据量增长和查询变复杂而减弱；

 

3) 使用MPP数据库技术对链接查询有帮助。例如，Impala在两表，多表链接查询中优点明显；

 

4) 充分利用缓存的系统在内存充足的状况下性能优点明显。例如，Shark，Impala在小数据量时性能优点明显；内存不足时性能降低严重，Shark会出现不少问题；

 

5) 数据倾斜会严重影响一些系统的性能。例如，Hive、Stinger、Shark对数据倾斜比较敏感，容易形成倾斜；Impala受这方面的影响彷佛不大；
对于Hive、Impala、Shark、Stinger和Presto这五类开源的分析引擎，在大多数状况下，Imapla的综合性能是最稳定的，时间性能也是最好的，并且其安装配置过程也相对容易。其余分别为Presto、Shark、Stinger和Hive。在内存足够和非Join操做状况下，Shark的性能是最好的。

 

总结与展望

 

对大数据分析的项目来讲，技术每每不是最关键的，关键在于谁的生态系统更强，技术上一时的领先并不足以保证项目的最终成功。对于Hive、Impala、Shark、Stinger和Presto来说，最后哪一款产品会成为事实上的标准还很难说，但咱们惟一能够肯定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，若是读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持Map-Reduce以外的计算范式（例如Shark，Impala等），所以未来Hadoop将可能做为一个兼容并包的大平台存在，在其上提供各类各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各类功能应有尽有，知足用户各方面的需求。

除了Hive、Impala、Shark、Stinger和Presto这样的开源方案外，像Oracle，EMC等传统厂商也没在坐以待毙等着本身的市场被开源软件侵吞。像EMC就推出了HAWQ系统，并号称其性能比之Impala快上十几倍，而Amazon的Redshift也提供了比Impala更好的性能。虽说开源软件由于其强大的成本优点而拥有极其强大的力量，可是传统数据库厂商仍会尝试推出性能、稳定性、维护服务等指标上更增强大的产品与之进行差别化竞争，并同时参与开源社区、借力开源软件来丰富本身的产品线、提高本身的竞争力，并经过更多的高附加值服务来知足某些消费者需求。毕竟，这些厂商每每已在并行数据库等传统领域积累了大量的技术和经验，这些底蕴仍是很是深厚的。总的来看，将来的大数据分析技术将会变得愈来愈成熟、愈来愈便宜、愈来愈易用；相应的，用户将会更容易更方便地从本身的大数据中挖掘出有价值的商业信息。