在互联网企业和有大数据处理需求的传统企业中，基于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。
2. Hive query optimizer(查询优化器是Hive需要持续不断优化的一个topic)
例如JOIN顺序的优化，就是原来一个大表和多个小表在不同column匹配的条件下JOIN需要解析成多个Map join + MR job，现在可以合并成一个MR job。
这个改进方向要做的就是用户不用给太多的hint，hive可以自己根据表的大小、行数等，自动选择最快的join的方法(小表能装进内存的话就用Map join，Map join能和其他MR job合并的就合并)。这个思路跟cost-based query optimizer有点类似了，用户写出来的SQL在翻译成执行计划之前要计算那种执行方式和JOIN顺序效率更高。
3. ORCFile
ORCFile是一种列式存储的文件，对于分析型应用来说列存有非常大的优势。
原来的RCFile中把每一列看成binary blob，没有任何语义，所以只能用通用的zlib,LZO,Snappy等压缩方法。ORCFile能够获取每一列的类型(int还是string)，那么就可以使用诸如dictionary encoding, bit packing, delta encoding, run-length encoding等轻量级的压缩技术。这种压缩技术的优势有两点：一是提高压缩率;二是能够起到过滤无关数据的效果。
Predicate Pushdown:原来的Hive是把所有的数据都读到
