转自：http://labs.chinamobile.com/mblog/52251_204176
但是也要注意哦，这个数据比起MPP数据库来说还是差，差得比Hive和Impala比较还要远，那是因为多表关联最考数据本地性（Locality）了，而MPP擅长这点（虽然这次测试中行列混合的两个查询分布键都不一样，而列数据库的SQL2分布键不一样，但仍然效果明显）。所以如果Impala不改变存储结构的话，还是很难和MPP比较性能。但是要注意哦，这是8个节点，如果100个节点以上，特别是有故障发生的情况下，Impala的灵活性和健壮性就可能好多了。
接下来看看嵌套查询的时候Impala优化得如何，反正Hive在这个方面就很差哦。
|
测试场景 |
sql1执行耗时 |
|
HIVE+HDFS（gzip格式源数据） |
45m50s |
|
HIVE+HDFS（未压缩源数据） |
2h32m39s |
|
IMPALA+HDFS第一遍（未压缩源数据） |
25m29s |
|
IMPALA+HDFS第二遍（未压缩源数据） |
25m14s |
|
某行列混合数据库 |
1m20s |
|
某纯列式数据库 |
11s |
这个测试结果就有点吐血了，MPP数据库在很短的时间就完成了。Impala的时间相对较长，Hive就更别提了。我感觉这两个都没有成功将嵌套查询中的SQL替换成关联操作来处理吧。但是即使如此，Impala也比Hive好。
最后看看多任务并发吧。Hive是放弃这个测试了，要让100到1000个MR任务运行在8个节点上？还是算了把，不能对硬件太狠了。这个只有Impala和MPP数据库比较了。
|
测试场景 |
100个日期大查询 |
100万号码小查询 |
|
IMPALA+HDFS |
29h12m3s |
内存限制，执行不成功 |
|
某行列混合数据库 |
18m43s |
未执行 |
|
某纯列式数据库 |
1h3m58s |
46m27s |
可以看到，在并发方面Impala表现不是太好。另外在大量小查询方面，由于内存超过而无法验证。当然MPP的并发也不是太好，其实。为了继续验证对于小查询的并发，还做了补充的测试：
|
并发量1/任务量1000 |
并发量10/任务量1000 |
并发量100/任务量1000 |
并发量20/任务量200 |
并发量50/任务量200 |
|
|
总时间：9h28m19s 单次任务平均时间：34s |
总时间：3h41m7s 单次任务平均时间：13.3s |
执行失败，内存超出限制和连接限制 |
总时间：1h31m10s 单次任务平均时间：27.4s |
执行失败，内存超出限制和连接限制错误 |
可以看到，由于没有索引，Impala对于小查询仍旧按照表扫描的方式来，好慢啊！并发量有一个最优的值，比如上述的10，太大或太小都不好，但这个对于数据和语句而言各有差异。
总结：
1、Impala的性能的确比Hive好，而且都是用同样的HDFS上的文件，所以如果内存足够，用Impala引擎来做肯定好，但是没有宣传得那么好！所以以后我们在Hadoop上的查询，可能是双引擎啦。小的让Imapla搞定，大的就让Hive启动MapReduce。类似现在有的数据库有SQL和MR两个执行引擎。应当注意Hive更加灵活，对UDF支持很好，非结构化数据也可以Parser。
2、Impala由于未涉及底层存储引擎的修改，所以与MPP数据库在小规模集群下结构化数据查询中仍然有差距。相比Pivotal的HAWG似乎修改了存储引擎，理论上应该先进一点（但是测试上并没有表现出来）。进一步的优化肯定要修改HDFS的底层细节，比如增强数据本地性（Locality）采用Colocation的方案等等。另外也许增加了面向成本的优化对哪些坏的SQL，比如嵌套等，会优化得更好一些吧。