Hive->Tez/Stinger未来工作的主要方向：Cost-based optimizer，基于统计选择执行策略，例如多表JOIN时按照怎样的顺序执行效率最高。统计执行过程中每个中间表的Row/Column等数目，从而决定启动多少个MR执行。
Impala
Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的混合体，目前主要是Cloudera在主导这个项目。
优点：
目前支持两种类型的JOIN：broadcast join和partition join。对于大表JOIN时由于内存限制，装不下时就要dump部分数据到磁盘，那样就会比较慢。
Impala各个任务之间传输数据采用的是push的方式(MR采用的是pull的方式)，也就是上游任务计算完就会push到下游，这样能够分散网络压力，提高job执行效率。
Parquet列存格式，同时能够处理嵌套数据。通过嵌套数据以及扩展的SQL查询语义，在某些特定的场景上避开了JOIN从而解决了一部分性能的bottleneck。
Cloudera Manager 4.6以后会有slow query的分析功能。
Runtime Code Generation
缺点：
Impala不会按照group by的列排序
目前不支持UDF，Impala 1.2即将支持Hive UDFs和Impala native UDFs and UDAs
不支持像Hive的Serializer/Deserializer，从而使得它做从非结构化到结构化数据的ETL工作比较麻烦。所以本质上讲Impala适合MR配合做ETL之后的查询工作。
由于Impala的设计初衷是short query，所以不支持fault tolerance。如果参与查询的某个node出错，Impala将会丢弃本次查询。
安全方面的支持还比较差。impalad之间传输的数据没有加密，不支持表或者列级别的授权。
每个PlanFragment执行尽量并行化，但是有的时候并不是很容易。例如Hash Join需要等到其中一个表完全Scan结束才能开始。
虽然有这么多缺点，但是很多公司还是开始尝试Impala了。以百度为 例，百度尝试把MySQL接入Impala的后端作为存储引擎，同时实现相应操作对应的PlanFragment，那么用户来的query还是按照原来的 解析方法解析成各种PlanFragment，然后直接调度到对应的节点(HDFS DataNode/HBaseRegionServer/MySQL)上执行。会把某些源数据或者中间数据放到MySQL中，用户的query涉及到使用 这部分数据时直接去MySQL里面拿。
Shark/Spark
由于数据能放到内存尽量放到内存，使用内存非常aggressive。优点是做JOIN时会比较快，缺点是占用内存太大，且自行管理内存，占用内存后不会释放。
由于Shark借用了Hive的codebase，所以在SQL，SerDes，UDF支持方面和Hive是完全兼容的。
支持从short query到long time query等不同粒度的查询，所以具有fault tolerance特性。
性能：特别简单的select…where查询，shark性能的提升不明显(因为hive也不怎么费时间)。但是如果查询比较复杂 select…join…where…group by，hive的job数目会比较多，读写HDFS次数增多，时间自然会变长。当内存还足够大的时候shark性能是最好的，如果内存不够装下所有的数据 时性能会下降，但还是会比Hive好很多。
Phoenix
Salesforce开源的基于HBase的SQL查询系统。基本原理是将一个对于HBase client来说比较复杂的查询转换成一系列Region Scan，结合coprocessor和custom filter在多台Region Server上进行并行查询，汇总各个Scan结果。种种迹象表明，Phoenix应该不是个优化的OLAP系统，更像是一个用于简单单表查询，过滤，排 序，检索的OLTP系统。
优点：
HBase默认存储的数据类型都是字符串，但Phoenix支持更多的数据类型。