SQL on Hadoop系統的最新進展

　　為什么非要把SQL放到Hadoop上? SQL易于使用。

　　那為什么非得基于Hadoop呢?the robust and scalable architecture of Hadoop

　　目前SQL on Hadoop產品主要有以下幾種：

　　Hive, Tez/Stinger, Impala, Shark/Spark, Phoenix, Hawq/Greenplum, HadoopDB, Citusdata等。本文主要討論Hive, Tez/Stinger, Impala, Shark以及傳統開源數據倉庫brighthouse的特點和最新進展;下一篇文章會討論Phoenix, Hadapt/HadoopDB, Hawq/Greenplum。

　　在互聯網企業中一般的基于Hadoop的數據倉庫的數據來源主要有以下幾個：

　　1，通過Flume/Scribe/Chukwa這樣的日志收集和分析系統把來自Apache/nginx等Server cluster的日志收集到HDFS上，然后通過Hive創建Table時指定SerDe把非結構化的日志數據轉化成結構化數據。

　　2，通過Sqoop這樣的工具把用戶和業務維度數據(一般存儲在Oracle/MySQL中)定期導入Hive，那么OLTP數據就有了一個用于OLAP的副本了。

　　3，通過ETL工具從其他外部DW數據源里導入的數據。

　　目前所有的SQL on Hadoop產品其實都是在某個或者某些特定領域內適合的，沒有silver bullet。像當年Oracle/Teradata這樣的滿足幾乎所有企業級應用的產品在現階段是不現實的。所以每一種SQL on Hadoop產品都在盡量滿足某一類應用的特征。

　　典型需求：

　　1, interactive query (ms~3min)

　　2，data analyst, reporting query (3min~20min)

　　3，data mining, modeling and large ETL (20 min ~ hr ~ day)

　　4，機器學習需求(通過MapReduce/MPI/Spark等計算模型來滿足)

　　Hive

　　Hive是目前互聯網企業中處理大數據、構建數據倉庫最常用的解決方案，甚至在很多公司部署了Hadoop集群不是為了跑原生MapReduce程序，而全用來跑Hive SQL的查詢任務。

　　對于有很多data scientist和analyst的公司，會有很多相同table的查詢需求。那么顯然每個人都從hive中查數據速度既慢又浪費資源。我們在online的數據庫系統部署的時候都會在DB前面部署Redis或者memcache用于緩存用戶經常訪問的數據。那么OLAP應用也可以參考類似的方法，把經常訪問的數據放到內存組成的集群中供用戶查詢。

　　Facebook針對這一需求開發了Presto，一個把熱數據放到內存中供SQL查詢的系統。這個設計思路跟Impala和Stinger非常類似了。使用Presto進行簡單查詢只需要幾百毫秒，即使是非常復雜的查詢，也只需數分鐘即可完成，它在內存中運行，并且不會向磁盤寫入。Facebook有超過850名工程師每天用它來掃描超過320TB的數據，滿足了80%的ad-hoc查詢需求。

　　目前Hive的主要缺點：

　　1，data shuffle時網絡瓶頸，Reduce要等Map結束才能開始，不能高效利用網絡帶寬

　　2，一般一個SQL都會解析成多個MR job，Hadoop每次Job輸出都直接寫HDFS，性能差

　　3，每次執行Job都要啟動Task，花費很多時間，無法做到實時

　　4，由于把SQL轉化成MapReduce job時，map,shuffle和reduce所負責執行的SQL功能不同。那么就有Map->MapReduce或者MapReduce->Reduce這樣的需求。這樣可以降低寫HDFS的次數，從而提高性能。

　　目前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)

　　http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/optimize-joins.html

　　Joins where one side fits in memory

　　Star schema join的改進，就是原來一個大表和多個小表在不同column匹配的條件下join需要解析成多個map join + MR job，現在可以合并成一個MR job

　　這個改進方向要做的就是用戶不用給太多的hint，hive可以自己根據表的大小、行數等，自動選擇最快的join的方法(小表能裝進內存的話就用map join，Map join能和其他MR job合并的就合并)。這個思路跟cost-based query optimizer有點類似了，用戶寫出來的SQL在翻譯成執行計劃之前要計算那種執行方式效率更高。

　　3，ORCFile

　　ORCFile是一種列式存儲的文件，對于分析型應用來說列存有非常大的優勢。 http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html

　　原來的RCFile中把每一列看成binary blob，沒有任何語義，所以只能用通用的zlib,LZO,Snappy等壓縮方法。

　　ORCFile能夠獲取每一列的類型(int還是string)，那么就可以使用諸如dictionary encoding, bit packing, delta encoding, run-length encoding等輕量級的壓縮技術。這種壓縮技術的優勢有兩點：一是提高壓縮率;二是能夠起到過濾無關數據的效果

　　現在ORCFile中主要有三種編碼：

　　bit編碼，所有數據類型都可以用。Google’s protocol buffers and uses the high bit to represent whether this byte is not the last and the lower 7 bits to encode data

　　run-length encoding(行程長度壓縮算法)，int類型專用。

　　dictionary encoding，string類型專用。同時這個dictionary還能幫助過濾查詢中的predicate條件。

　　Run length Encoding對某些列壓縮會減少存儲3-4個數量級，對內存提升也有2-3個數量級，Dictionary Encoding一般對磁盤空間減少大概20倍，對內存空間大概減少5倍，根據Google PowerDrill的實驗，在常見的聚合查詢中這些特殊的編碼方式會對查詢速度有2-3個數量級的提升.

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

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