大数据是现在非常热门的一个话题，从工程或者技术的角度来看，大数据的核心是如何存储、分析、挖掘海量的数据解决实际的问题。那么对于一个工程师或者分析师来说，如何查询和分析TB/PB级别的数据是在大数据时代不 可回避的问题。SQL on Hadoop就成为了一个重要的工具。为什么非要把SQL放到Hadoop上？ SQL易于使用;那为什么非得基于Hadoop呢？Hadoop架构具备很强的鲁棒性和可扩展性。本文从技术架构和最新进展两个角度分析一下各种SQL on Hadoop产品的优缺点和适用范围：Hive、Tez/Stinger、Impala、Shark/Spark、Phoenix、 Hdapt/HadoopDB、Hawq/Greenplum。
在互联网企业和有大数据处理需求的传统企业中，基于Hadoop构建的数据仓库的数据来源主要有以下几个：
通过Flume/Scribe/Chukwa这样的日志收集和分析系统把来自Apache/Nginx的日志收集到HDFS上，然后通过Hive查询。
通过Sqoop这样的工具把用户和业务维度数据(一般存储在Oracle/MySQL中)定期导入Hive，那么OLTP数据就有了一个用于OLAP的副本了。
通过ETL工具从其他外部DW数据源里导入的数据。
目前所有的SQL on Hadoop产品其实都是在某个或者某些特定领域内适合的，没有silver bullet。像当年Oracle/Teradata这样的满足几乎所有企业级应用的产品在大数据时代是不现实的。所以每一种SQL on Hadoop产品都在尽量满足某一类应用的特征。典型需求：
interactive query (ms~3min)
data analyst，reporting query (3min~20min)
data mining，modeling and large ETL (20 min ~ hr ~ day)
机器学习需求(通过MapReduce/MPI/Spark等计算模型来满足)
Hive
Hive是目前互联网企业中处理大数据、构建数据仓库最常用的解决方案，甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序，而全用来跑Hive SQL的查询任务。
对于有很多data scientist和analyst的公司，会有很多相同表的查询需求。那么显然每个人都从Hive中查数据速度既慢又浪费资源。如果能把经常访问的数据放到内存组成的集群中供用户查询那样效率就会高很多。Facebook针对这一需求开发了Presto，一个把热数据放到内存中供SQL查询的系统。这个设计思路跟Impala和Stinger非常类似了。使用Presto进行简单查询只需要几百毫秒，即使是非常复杂的查询，也只需数分钟即可完成，它在内存中运行，并且不会向磁盘写入。Facebook有超过850名工程师每天用它来扫描超过320TB的数据，满足了80%的ad-hoc查询需求。
目前Hive的主要缺点：
data shuffle时网络瓶颈，Reduce要等Map结束才能开始，不能高效利用网络带宽。
一般一个SQL都会解析成多个MR job，Hadoop每次Job输出都直接写HDFS，大量磁盘IO导致性能比较差。
每次执行Job都要启动Task，花费很多时间，无法做到实时。
由于把SQL转化成MapReduce job时，map、shuffle和reduce所负责执行的SQL解析出得功能不同。那么就有Map->MapReduce或者 MapReduce->Reduce这样的需求，这样可以降低写HDFS的IO数量，从而提高性能。但是目前MapReduce框架还不支持 M->MR或者MR->R这样的任务执行。
目前Hive主要的改进(主要是体现在 Hive 0.11版本上)：
1. 同一条hive sql解析出的多个MR任务的合并。由Hive解析出来的MR jobs中有非常多的Map->MapReduce类型的job，可以考虑把这个过程合并成一个MRjob。 https://issues.apache.org/jira/browse/HIVE-3952
2. Hive query optimizer(查询优化器是Hive需要持续不断优化的一个topic)
例如JOIN顺序的优化，就是原来一个大表和多个小表在不同column匹配的条件下JOIN需要解析成多个Map join + MR job，现在可以合并成一个MR job。