:::: MENU ::::

TalkingData's Blog

现在开始,用数据说话。

Impala 1.0初探

  • May 21 / 2013
  • 0
Data

Impala 1.0初探

随着大数据处理技术的发展,基于大数据的实时查询技术在最近一年也有了长足的发展,Cloudera的Implala就是其中发展比较快的一个。2012年10月份的大数据技术会议上,Cloudera发布了Impala的1.0beta。经过半年时间的等待,在北京时间2013年5月1日早晨,我们终于收到了Impala 1.0正式GA的消息。而TalkingData技术团队也在第一时间下载并安装了Impala 1.0,并且根据自己的业务特点,对Impala 1.0和Hive的查询性能进行了初步的性能测试。

系统环境

  • 4台虚拟机,每台5.8G内存, CentOS 6.2
  • Hadoop CDH 4.2.1
  • 1台用作master, 3台用作slave
  • Master上运行: namenode, secondarynamenode, jobtracker, hivemetastore, impala  statestore, zookeeper
  • 每台slave上运行: datanode, impalad, tasktracker

数据集

文件格式: RCFile+Snappy压缩

表table1:

  • 35 columns
  • 在10次测试中,表A的行数由94 million增加到660 million, 文件数由217个增加到2297个,文件大小总和由5.3G增加到36.9G

表table2:

  • 12 columns
  • 行数: 11 million; 文件数: 7; 文件大小总和: 1.4G

执行Query

Query1:

select count(*) from table1;

单个大表的简单Count操作

Query2:

单个大表,带子查询的汇总操作

select count(devid) devnum, developerid

from (select developerid, devid

from table1

where duration > 60

group by developerid, devid) a

group by developerid

order by devnum desc limit 10;

 Query3:

两个表Join的汇总操作,小表在右。

select a.developerid, b.platformid,

sum(a.duration) total_duration

from table1 a

join table2 b on a.sessionid=b.sessionid

group by a.developerid, b.platformid

order by developerid, platformid limit 20;

 Query4:

在Query3的基础上,增加Query的复杂度。

select a.developerid, a.productid, b.platformid,

count(a.devid), sum(a.duration) total_duration, avg(a.duration)

from table1 a

join table2 b on a.sessionid=b.sessionid

group by a.developerid, a.productid ,b.platformid

order by developerid, platformid limit 20;

结果曲线

Query1:

对于一个大表的简单的count操作,Impala相对Hive没有明显优势,执行时间在同一个数量级。

Query2:

在单表有复杂子查询语句的聚合操作情况下,Impala对比Hive有了超过两倍的性能提高,并且整个曲线更为平缓。

Query3:

从这个图的曲线看,我们可以发现Impala在两个表Join并有聚合的情况下,性能是Hive的5倍。随着数据量的加大,Impala的耗时更为线性。

Query4:

从这个结果可以看到,对于更为复杂的查询,Hive和Impala的曲线走势和Query3类似,Implala相对于Hive有7倍左右的性能提升。我们可以从下图的Query3和Query4对比进行进一步分析:

Query3&Query4:

从这个Query3和Query4的对比图我们可以看到,对于两个SQL,Impala经过优化,执行时间基本相同。而对于Hive,因为多了聚合操作,引入了更多的MR任务,因此会花费更多的时间来执行。

这几组测试结果,正如Cloudera在自己的官方文档所说:” Queries that require multiple MapReduce phases in Hive or require reduce-side joins will see a higher speedup than, say, simple single-table aggregation queries.”

对于大数据的多表join复杂的查询,由于Impala创建的高效的执行计划,相比Hive的多次MapReduce任务,无疑更具有明显的速度优势。

随着对Impala的逐步深入和了解,我们会进行进一步的针对不同场景的测试,更深入的分析这个新的大数据实时查询利器。

 

Leave a comment

随时欢迎您 联系我们