原始文章传送门 http://www.gruter.com/blog/?p=391

General Feature
数据往往以RC & ORC & Parquet等格式存放在HDFS 以及在分布式环境上执行SQL

SQL-on-Hadoop solutions
1.  Hive: 将SQL转成MapReduce Job，继承了MR的稳定可靠，同时也带来了Shuffle过程的额外消耗
2.  Stinger: 将计算框架迁移到Tez上， 因此并不算是一个独立的新解决方案，但可以解决Hive一部分不足
3.  Apache Iajo: 在HDFS上使用了自己的分布式执行引擎
4.  Impala: 使用了自己的分布式计算框架，在Shuffer阶段会将所有数据保存在内存中，因此避免了shuffling overheads,  但是不能处理超过内存限制的数据量
5.  Apache Drill: Google Dremel的开源实现，目前还在开发中，而且还没实现其主要的分布式处理模块

Key SQL-on-Hadoop performance factors
1.  磁盘扫描速度，因为数据通常是存放在HDFS；此外中间数据的传输效率也是个重要因素，因为像Group By或者Order By之类的算子往往会以多步来执行
2.  Query Execution启动时间，对于短查询而言，启动时间会成为较大的OverHeads，而在长查询中，启动时间往往占比很小
3. 文件格式，目前有 RC & ORC & Parquet等，往往这些文件格式有不同的特性，往往需要根据实际的应用场景来选择合适的文件。Query往往会生成大量的结果文件，文件格式和文件写效率是一个关键的因素，比如ORC文件格式有较好的读性能，但是写性能较差。此外合适的压缩机制也是一个关键因素在SQL-on-Hadoop系统中

The absolute performance limits of SQL-on-Hadoop
1.  除了上面的因素之外，还有一些限制是不能超出的：处理性能会小于或者等于在HDFS上的磁盘带宽
2.  对于像Select count(*) from table这样的查询而言，由于没有shuffle消耗，因此磁盘读取速度，Query启动时间和文件格式成为关键因素，当使用相同的文件格式和大量的数据场景下，各个解决方案的时间相差不远
3. 对于across a range of natural field queries,  Stinger这些只是比Hive快1.5-3倍左右

Frequently-used performance comparison queries
1.  对于短查询而言，Stinger由于省去了启动时间，因此可能会比Hive快上百倍，但是并不意味着在长查询中也有同样的效果
2.  而对于Order By这类操作，Hive只用单机来执行，对于能够分布式Order By方案而言，查询效率是能够比Hive高上千倍的，只要节点数足够多。但是并不能就宣称比Hive快上上千倍