这个改进方向要做的就是用户不用给太多的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是把所有的数据都读到内存中，然后再判断哪些是符合查询需求的。在ORCFile中数据以Stripe为单元读取到内 存，那么ORCFile的RecordReader会根据Stripe的元数据(Index Data，常驻内存)判断该Stripe是否满足这个查询的需求，如果不满足直接略过不读，从而节省了IO。
通过对ORCFile的上述分析，我想大家已经看到了brighthouse的影子了吧。都是把列数据相应的索引、统计数据、词典等放到内存中参与查询条件的过滤，如果不符合直接略过不读，大量节省IO。
4. HiveServer2的Security和Concurrency特性
HiveServer2能够支持并发客户端(JDBC/ODBC)的访问。
Cloudera还搞了个Sentry用于Hadoop生态系统的的安全性和授权管理方面的工作。这两个特点是企业级应用Hadoop/Hive主要关心的。
5. HCatalog Hadoop的统一元数据管理平台
目前Hive存储的表格元数据和HDFS存储的表格数据之间在schema上没有一致性保证，也就是得靠管理员来保证。目前Hive对列的改变 只会修改 Hive 的元数据，而不会改变实际数据。比如你要添加一个column，那么你用Hive命令行只是修改了了Hive元数据，没有修改HDFS上存储的格式。还得 通过修改导入HDFS的程序来改变HDFS上存储的文件的格式。Hadoop系统目前对表的处理是’schema on read’，有了HCatlog就可以做到EDW的’schema on write’。
6. Windowing and Analytics Functions的支持。
Tez/Stinger
Tez是一种新的基于YARN的DAG计算模型，主要是为了优化Hive而设计的。目前Tez/Stinger主要是Hortonworks在 搞，他们希望以后把Hive SQL解析成能够在Tez上跑的DAG而不是MapReduce，从而解决计算实时性的问题。Tez的主要特点有：
底层执行引擎不再使用MR，而是使用基于YARN的更加通用的DAG执行引擎，MR是高度抽象的Map和Reduce两个操作，而Tez则是在这两个操作的基础上提供了更丰富的接口。把Map具体到Input、 Processor、 Sort、Merge、Output，而Reduce也具体化成Input、Shuffle、Sort、Merge、Processor、 Output。其实这个跟Spark有点类似了，都是提供更丰富的可操作单元给用户。
传统的Reduce只能输出到HDFS，而Tez的Reduce Processor能够输出给下一个Reduce Processor作为输入。
Hot table也放到内存中cache起来
Tez service：预启动container和container重用，降低了每次Query执行计划生成之后Task启动的时间，从而提高实时性。
Tez本身只是YARN框架下得一个library，无需部署。只需指定mapreduce.framework.name=yarn-tez
Tez/Stinger还有一个最重要的feature : Vectorized Query Execution ( 该feature在HDP 2.0 GA中会提供)。
目前Hive中一行一行的处理数据，然后调用lazy deserialization解析出该列的Java对象，显然会严重影响效率。Vectorized Query Execution把多行数据同时读取并处理(基本的比较或者数值计算)，降低了函数调用的次数，提高了CPU利用率和cache命中率。