转自：http://labs.chinamobile.com/mblog/52251_204175
Impala，这个非洲的高角羚，被伟大的Cloudera公司赋予了新的含义。随着2013年5月1日的1.0版本发布，一个构建在HDFS上的非MR机制的SQL解析引擎正在慢慢成熟。
Impala相比原来的Hive来说，在解析上有很大的突破，至少我在初体验的时候感觉到有如下几点：
1、对SQL92更好的支持，而不是一部分子集。
2、不用MapReduce来进行执行，而使用自己的SQL解析和分布式执行引擎，效率有所提升
3、充分使用内存来提升效率，所以两次重复查询效果迥异。
但是对于Cloudera公司在发布会上宣布的XX倍于HIVE查询性能的提升，我心存畏惧。于是请一帮兄弟利用公司资源搞出一个测试环境，要自己来亲密接触一下Impala，大致的测试环境是如下的：
l 硬件环境：8台X86机架式服务器，每台2CPU供16核，128G内存，16块SAS 450G硬盘，2个万兆以太网卡绑定为主备方式。Master节点没有单独出来。
l 软件环境：Redhat、CDH4.3
测试的案例和数据来自于之前在同一套硬件平台上测试的MPP数据库产品的案例和数据，所以也可以把他们的结果拿出来做一个对比。
遗憾的是，到现在我们才理解Cloudera所说的充分利用内存的含义所在：原来Impala不能用内存为缓存区，而是所有查询数据必须装入内存才可以。晕倒！这样一来，我们就有大部分测试案例无法执行，特别是涉及语音详单的，虽然我们累计内存达到了1TB（自己觉得还是多牛叉的），但是那个语音详单表非压缩的数据有4TB。果然随后我们在Impala的官方文档中找到了这么一小行字：Impala currently does not support queries that use more memory than is available on the system. If this is anissue for your use case (for example, joins between large tables), more memory will be beneficial.这行字在很小的地方，而且说得含含糊糊，Cloudera也有不靠谱的时候啊。无法查询超过内存的大小的表，这是第一个初体验吧。
第二个初体验马上就来了。Impala 1.0号称支持多种格式的压缩文件，但是那是有条件的。比如如果是文本文件的话，就不支持Gzip压缩，只支持LZO的压缩格式。而其他所谓的结构化的文件格式，比如Parquet、Avro、RCFile、SequenceFile等文件格式，就可以支持多种压缩方式，比如Snappy, GZIP, deflate, BZIP2。估计这与它执行引擎的工作方式有关。于是我们就只好哭泣着将用Gzip压缩的文本文件解压，这花了两天时间！所以第二个初体验就是，谨慎选择文件格式和压缩形式！
现在才可以正式开始测试了，这个到是很快的，因为那些超级大的都不能运行在Impala上。先看单表查询的吧。
|
测试场景 |
sql2耗时 |
sql3耗时 |
|
HIVE+HDFS |
58s |
43s |
|
IMPALA+HDFS第一遍 |
18s |
14s |
|
IMPALA+HDFS第二遍 |
9s |
12s |
|
某行列混合数据库 |
6s |
29s |
|
某纯列式数据库 |
1s |
9s |
果然Impala在同样的数据上要快Hive很多，那是因为它不用启动众多的由JAVA编写的MapReduce程序，数据也不用由于Map和Reduce两个过程在节点间交互（因为只是单表查询，没有JOIN）。而且第二次执行明显比第一次执行快，应该是Impala利用内存在缓存的结果。但是应该注意到，与MPP数据库相比较起来，Impala还是有差距的，我觉得那是因为它只是一个SQL解析和查询执行的引擎，而不是存储引擎，其存储还是使用了HDFS，而HDFS并不是为了其SQL查询而优化的。例如我们测试中用到了128M的块大小设置，这样有可能数据并没有均匀分布到8台机器之上，性能并没有达到最优化。
同样需要注意的一点，单个操作的性能（一般对并行考虑比较多）并不一定是唯一考虑的东西，而有的时候，我们会限制单个操作所使用资源以便提高吞吐率（并发）。这也是某些测试对某些产品不合理的地方。但是遗憾的是Impala在并发测试方面也并不好，所以并不是它为了并发牺牲了并行，而是结构性问题。
接着看看多表关联的测试：
|
测试场景 |
sql1耗时 |
sql2耗时 |
|
HIVE+HDFS场景（gzip格式据） |
1h17m15s |
38m32s |
|
IMPALA+HDFS第一遍 |
30m42s |
19m56s |
|
IMPALA+HDFS第二遍 |
24m17s |
18m43s |
|
某行列混合数据库 |
9m59s |
7m5s |
|
某纯列式数据库 |
5m30s |
1m50s |
由于这个场景中的非压缩数据HIVE查询可能由于参数设置原因而有问题（可能测试的时候忘记设置REDUCE_TASK数量了，汗！），所以只好用原来在压缩文件上的测试数据代替，实际上Hive的执行结果还可能比这个长。但是即使这样，Impala也快了一倍多。说明它的新查询引擎还是很给力的，但是并没有Cloudera宣传的那么给力，最讨厌虚假宣传了！