Impala：新一代开源大数据分析引擎 -

weitao1026

浏览: 1053802 次
性别:
来自: 上海

最近访客更多访客>>

vicento4

723499280

liuzidong

s1986q

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

Impala：新一代开源大数据分析引擎

博客分类：

hadoop/spark/Hbase/Hive/pig/Zookeeper/HAWQ/cloudera/Impala/Oozie

大数据处理是云计算中非常重要的问题，自Google公司提出MapReduce分布式处理框架以来，以Hadoop为代表的开源软件受到越来越多公司的重视和青睐。以Hadoop为基础，之后的Hbase，Hive，Pig等系统如雨后春笋般的加入了Hadoop的生态系统中。今天我们就来谈谈Hadoop系统中的一个新成员 – Impala。

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负责子查询的执行，最后返回子查询的结果，这些中间结果经过聚集之后最终返回给用户。

图1. Impala的系统架构图 [2]

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

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

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

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

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

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

6）使用了支持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确实为大数据的流行出钱出力J

Impala与Shark，Drill等的比较

开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发当中，相关的文档和代码还不多，可以说暂时还未对Impala构成足够的威胁[10]。从Quora上的问答来看，Cloudera有7-8名工程师全职在Impala项目上，而相比之下Drill目前的动作稍显迟钝。具体来说，截止到2012年10月底，Drill的代码库里实现了query parser, plan parser，及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完毕的分布式query execution引擎，并对HDFS和HBase上的数据读入，错误检测，INSERT的数据修改，LLVM动态翻译等都提供了支持。当然，Drill作为Apache的项目，从一开始就避免了某个vendor的一家独大，而且对所有Hadoop流行的发行版都会做相应的支持，不像Impala只支持Cloudera自己的发行版CDH。从长远来看，谁会占据上风还真不一定[10]。

除此之外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。在今天6月份的《程序员》上有一篇专门分析与Shark相关的Spark系统的文章，感兴趣的读者朋友可以参考。从长远目标来看，Shark想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Shark基于Scala语言的算子推导实现了良好的容错机制，因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下，Impala由于缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失。而且Shark是把内存当作第一类的存储介质来做的系统设计，所以在处理速度上也会有一些优势[11]。实际上，AMPLab最近对Hive，Impala，Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query，Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中我们可以看到，商业版本的Redshift的性能是最好的， Impala和Shark则各有胜负，且两者都比Hive的性能高出了一大截。更多相关的实验结果读者朋友可以参考[12]。

图2. Redshift，Impala，Shark与Hive的Aggregation Query性能对比 [12]

以笔者愚见，其实对大数据分析的项目来说，技术往往不是最关键的。例如Hadoop中的MapReduce和HDFS都是源于Google，原创性较少。事实上，开源项目的生态圈，社区，发展速度等，往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源，以期望利用开源社区的力量来推广这个产品；Shark也是一开始就开源了出来，更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后那一款产品会成为事实上的标准还很难说，但是，我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持MapReduce之外的计算范式（例如Shark，Impala等），因此将来Hadoop将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。

未来展望

其实除了Impala，Shark，Drill这样的开源方案外，像Oracle，EMC等传统厂商也没在坐以待毙等着自己的市场被开源软件侵吞。像EMC就推出了HAWQ系统，并号称其性能比之Impala快上十几倍，而前面提到的Amazon的Redshift也提供了比Impala更好的性能。虽然说开源软件因为其强大的成本优势而拥有极其强大的力量，但是传统数据库厂商仍会尝试推出性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争，并同时参与开源社区、借力开源软件来丰富自己的产品线、提升自己的竞争力，并通过更多的高附加值服务来满足某些消费者需求。毕竟，这些厂商往往已在并行数据库等传统领域积累了大量的技术和经验，这些底蕴还是非常深厚的。甚至现在还有像NuoDB（一个创业公司）这样号称即支持ACID，又有Scalability的NewSQL系统出来。总的来看，未来的大数据分析技术将会变得越来越成熟、越来越便宜、越来越易用；相应的，用户将会更容易更方便地从自己的大数据中挖掘出有价值的商业信息。