SQL on Hadoop系統的最新進展(2)

　　關于ORCFile的壓縮效果，使用情況和性能可以參考hortonworks的博客

　　http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

　　未來ORCFile還會支持輕量級索引，就是每一列中以1W行作為一組的最大值和最小值。

　　通過對ORCFile的上述分析，我想大家已經看到了brighthouse的影子了吧。都是把列數據相應的索引、統計數據、詞典等放到內存中參與查詢條件的過濾，如果不符合直接略過不讀，大量節省IO。關于brighthouse大家可以參考下面的分析。

　　4，HiveServer2的Security和Concurrency特性

　　http://blog.cloudera.com/blog/2013/07/how-hiveserver2-brings-security-and-concurrency-to-apache-hive/

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

　　Cloudera還搞了個Sentry用于Hadoop生態系統的的安全性和授權管理方面的工作。

　　這兩個特點是企業級應用Hadoop/Hive主要關心的。

　　5，HCatalog Hadoop的統一元數據管理平臺

　　目前Hive存儲的表格元數據和HDFS存儲的表格數據之間在schema上沒有一致性保證，也就是得靠管理員來保證。目前Hive對列的改變只會修改 Hive 的元數據，而不會改變實際數據。比如你要添加一個column，那么你用hive命令行只是修改了了Hive元數據，沒有修改HDFS上存儲的格式。還得通過修改導入HDFS的程序來改變HDFS上存儲的文件的格式。而且還要重啟Hive解析服務，累壞了系統管理員。

　　Hadoop系統目前對表的處理是’schema on read’，有了HCatlog就可以做到EDW的’schema on write’。

　　HCatlog提供REST接口提供元數據服務，有利于不同平臺(HDFS/HBase/Oracle/MySQL)上的不同數據(unstructured/semi-structured/structured)共享。能夠把Hadoop和EDW結合起來使用。

　　HCatlog對用戶解耦了schema和storage format。舉個例子吧，在寫MR任務的時候，目前是把所有的行數據都當成Text來處理，Text一點點解析出各個Column需要編程人員來控制。有個HCatlog之后編程人員就不用管這事了，直接告訴它是哪個Database->Table，然后schema可以通過查詢HCatlog來獲得。也省得數據存儲格式發生變化之后，原來的程序不能用的情況發生。

　　6，Windowing and Analytics Functions的支持。

　　支持Windowing functions : lead, lag, first_value, last_value

　　支持over clause : partition by, order by, window frame

　　支持analytics functions : rank, row_number, dense_rank, cume_dist, percent_rank, ntile

　　https://cwiki.apache.org/confluence/display/Hive/LanguageManual+WindowingAndAnalytics

　　https://issues.apache.org/jira/browse/HIVE-4197

　　Tez/Stinger(升級版的Hive)

　　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。在MR程序里，編程人員只需編寫對應的Processor邏輯，其他的是通過指定幾種具體實現來完成的;而在Tez里面給我們更大的自由度。其實這個跟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

　　http://dongxicheng.org/mapreduce-nextgen/apache-tez-newest-progress/

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

　　https://issues.apache.org/jira/browse/HIVE-4160

　　目前Hive中一行一行的處理數據，然后調用lazy deserialization解析出該列的Java對象，顯然會嚴重影響效率。

　　多行數據同時讀取并處理(基本的比較或者數值計算)，降低了一行一行處理中過多的函數調用的次數，提高了CPU利用率和cache命中率

　　需要實現基于向量的vectorized scan, filter, scalar aggregate, group-by-aggregate, hash join等基本操作單元。

　　未來工作方向：

　　Cost-based optimizer，基于統計選擇執行策略，例如多表JOIN時按照怎樣的順序執行效率最高。

　　統計執行過程中每個中間表的Row/Column等數目，從而決定啟動多少個MR執行

　　Impala

　　Impala可以看成是Google Dremel架構和MPP (Massively Parallel Processing)結構的混合體。

　　https://github.com/cloudera/impala

　　Dremel論文： http://research.google.com/pubs/pub36632.html

　　優點：

　　目前支持兩種類型的JOIN：broadcast join和partition join。對于大表JOIN時由于內存限制，裝不下時就要dump部分數據到磁盤，那樣就會比較慢

　　Impala各個任務之間傳輸數據采用的是push的方式(MR采用的是pull的方式)，也就是上游任務計算完就會push到下游，這樣能夠分散網絡壓力，提高job執行效率。

　　Parquet列存格式，同時能夠處理嵌套數據。通過嵌套數據以及擴展的SQL查詢語義，在某些特定的場景上避開了JOIN從而解決了一部分性能的bottleneck。(Impala目前支持LZO Text, Sequence, Avro, RCFile, Parquet, 不支持ORCFile。但是未來支持多種存儲文件格式是個趨勢，所以Impala讀取文件這部分功能也需要盡快插件化。)

原文轉自：http://yanbohappy.sinaapp.com/?p=381