內存中，然后再判斷哪些是符合查詢需求的。在ORCFile中數(shù)據(jù)以Stripe為單元讀取到內存，那么ORCFile的RecordReader會根據(jù)Stripe的元數(shù)據(jù)(Index Data，常駐內存)判斷該Stripe是否滿足這個查詢的需求，如果不滿足直接略過不讀，從而節(jié)省了IO。

通過對ORCFile的上述分析，我想大家已經(jīng)看到了brighthouse的影子了吧。都是把列數(shù)據(jù)相應的索引、統(tǒng)計數(shù)據(jù)、詞典等放到內存中參與查詢條件的過濾，如果不符合直接略過不讀，大量節(jié)省IO。

4. HiveServer2的Security和Concurrency特性

HiveServer2能夠支持并發(fā)客戶端(JDBC/ODBC)的訪問。

Cloudera還搞了個Sentry用于Hadoop生態(tài)系統(tǒng)的的安全性和授權管理方面的工作。這兩個特點是企業(yè)級應用Hadoop/Hive主要關心的。

5. HCatalog Hadoop的統(tǒng)一元數(shù)據(jù)管理平臺

目前Hive存儲的表格元數(shù)據(jù)和HDFS存儲的表格數(shù)據(jù)之間在schema上沒有一致性保證，也就是得靠管理員來保證。目前Hive對列的改變只會修改 Hive 的元數(shù)據(jù)，而不會改變實際數(shù)據(jù)。比如你要添加一個column，那么你用Hive命令行只是修改了了Hive元數(shù)據(jù)，沒有修改HDFS上存儲的格式。還得通過修改導入HDFS的程序來改變HDFS上存儲的文件的格式。Hadoop系統(tǒng)目前對表的處理是’schema on read’，有了HCatlog就可以做到EDW的’schema on write’。

6. Windowing and Analytics Functions的支持。

Tez/Stinger

Tez是一種新的基于YARN的DAG計算模型，主要是為了優(yōu)化Hive而設計的。目前Tez/Stinger主要是Hortonworks在搞，他們希望以后把Hive SQL解析成能夠在Tez上跑的DAG而不是MapReduce，從而解決計算實時性的問題。Tez的主要特點有：

·底層執(zhí)行引擎不再使用MR，而是使用基于YARN的更加通用的DAG執(zhí)行引擎

·MR是高度抽象的Map和Reduce兩個操作，而Tez則是在這兩個操作的基礎上提供了更豐富的接口。把Map具體到Input、Processor、 Sort、Merge、Output，而Reduce也具體化成Input、Shuffle、Sort、Merge、Processor、 Output。其實這個跟Spark有點類似了，都是提供更豐富的可操作單元給用戶。

·傳統(tǒng)的Reduce只能輸出到HDFS，而Tez的Reduce Processor能夠輸出給下一個Reduce Processor作為輸入。

·Hot table也放到內存中cache起來

·Tez service：預啟動container和container重用，降低了每次Query執(zhí)行計劃生成之后Task啟動的時間，從而提高實時性。

·Tez本身只是YARN框架下得一個library，無需部署。只需指定mapreduce.framework.name=yarn-tez

·Tez/Stinger還有一個最重要的feature : Vectorized Query __execution ( 該feature在HDP 2.0 GA中會提供)。

目前Hive中一行一行的處理數(shù)據(jù)，然后調用lazy deserialization解析出該列的Java對象，顯然會嚴重影響效率。Vectorized Query __execution把多行數(shù)據(jù)同時讀取并處理(基本的比較或者數(shù)值計算)，降低了函數(shù)調用的次數(shù)，提高了CPU利用率和cache命中率。

Hive->Tez/Stinger未來工作的主要方向：Cost-based optimizer，基于統(tǒng)計選擇執(zhí)行策略，例如多表JOIN時按照怎樣的順序執(zhí)行效率最高。統(tǒng)計執(zhí)行過程中每個中間表的Row/Column等數(shù)目，從而決定啟動多少個MR執(zhí)行。