hadoop2.0之Impala初体验二

转自：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，比如嵌套等，会优化得更好一些吧。