SQL on Hadoop的最新進展及7項相關技術分享

大資料最大的魅力在於通過技術分析和挖掘帶來新的商業價值。 SQL on Hadoop是非常關鍵的一個方向。 CSDN雲計算特別邀請梁堰波撰寫這篇文章，對7種最新技術做深度闡述。 文章較長，但相信一定有收穫。 2013年12月5日-6日，以「應用驅動的架構與技術」為主題的第七屆中國大資料技術大會(Big Data Technology Conference 2013，BDTC 2013)召開之前，我們還將組織好友就熱點技術進行深入討論， 如果有問題，歡迎在評論部分留言。


　　大資料是現在非常熱門的一個話題，從工程或者技術的角度來看，大資料的核心是如何存儲、分析、挖掘海量的資料解決實際的問題。 那麼對於一個工程師或者分析師來說，如何查詢和分析TB/PB級別的資料是在大資料時代不可回避的問題。 SQL on Hadoop就成為了一個重要的工具。 為什麼非要把SQL放到Hadoop上？ SQL便於使用;那為什麼非得基於Hadoop呢？ Hadoop架構具備很強的魯棒性和可擴充性。 本文從技術架構和最新進展兩個角度分析一下各種SQL on Hadoop產品的優缺點和適用範圍：Hive、Tez/Stinger、Impala、Shark/Spark、Phoenix、 Hdapt/HadoopDB、Hawq/ Greenplum。


　　在互聯網企業和有大資料處理需求的傳統企業中，基於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。 HTTPs://issues.apache.org/jira/browse/HIVE-3952


　　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是把所有的資料都讀到記憶體中，然後再判斷哪些是符合查詢需求的。 在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命中率。


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


　　Impala


　　Impala可以看成是Google Dremel架構和MPP (Massively Parallel Processing)結構的混合體，目前主要是Cloudera在主導這個專案。


　　優點：


　　目前支援兩種類型的JOIN：broadcast join和partition join。 對於大表JOIN時由於記憶體限制，裝不下時就要dump部分資料到磁片，那樣就會比較慢。


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


　　Parquet列存格式，同時能夠處理嵌套資料。 通過嵌套資料以及擴展的SQL查詢語義，在某些特定的場景上避開了JOIN從而解決了一部分性能的bottleneck。


Cloudera Manager 4.6以後會有slow query的分析功能。


　　Runtime Code Generation


　　缺點：


　　Impala不會按照group by的列排序


　　目前不支援UDF，Impala 1.2即將支援Hive UDFs和Impala native UDFs and UDAs


　　不支援像Hive的Serializer/Deserializer，從而使得它做從非結構化到結構化資料的ETL工作比較麻煩。 所以本質上講Impala適合MR配合做ETL之後的查詢工作。


　　由於Impala的設計初衷是short query，所以不支援fault tolerance。 如果參與查詢的某個node出錯，Impala將會丟棄本次查詢。


　　安全方面的支援還比較差。 impalad之間傳輸的資料沒有加密，不支援表或者列級別的授權。


　　每個PlanFragment執行儘量並行化，但是有的時候並不是很容易。 例如Hash Join需要等到其中一個表完全Scan結束才能開始。


　　雖然有這麼多缺點，但是很多公司還是開始嘗試Impala了。 以百度為例，百度嘗試把MySQL接入Impala的後端作為儲存引擎，同時實現相應操作對應的PlanFragment，那麼使用者來的query還是按照原來的解析方法解析成各種PlanFragment，然後直接調度到對應的節點 (HDFS DataNode/HBaseRegionServer/MySQL)上執行。 會把某些來源資料或者中間資料放到MySQL中，使用者的query涉及到使用這部分資料時直接去MySQL裡面拿。


　　Shark/Spark


　　由於資料能放到記憶體儘量放到記憶體，使用記憶體非常aggressive。 優點是做JOIN時會比較快，缺點是佔用記憶體太大，且自行管理記憶體，佔用記憶體後不會釋放。


由於Shark借用了Hive的codebase，所以在SQL，SerDes，UDF支援方面和Hive是完全相容的。


　　支援從short query到long time query等不同細微性的查詢，所以具有fault tolerance特性。


　　性能：特別簡單的select...where查詢，shark性能的提升不明顯(因為hive也不怎麼費時間)。 但是如果查詢比較複雜select...join...where...group by，hive的job數目會比較多，讀寫HDFS次數增多，時間自然會變長。 當記憶體還足夠大的時候shark性能是最好的，如果記憶體不夠裝下所有的資料時性能會下降，但還是會比Hive好很多。


　　Phoenix


　　Salesforce開源的基於HBase的SQL查詢系統。 基本原理是將一個對於HBase client來說比較複雜的查詢轉換成一系列Region Scan，結合coprocessor和custom filter在多台Region Server上進行並行查詢，匯總各個Scan結果。 種種跡象表明，Phoenix應該不是個優化的OLAP系統，更像是一個用於簡單單表查詢，過濾，排序，檢索的OLTP系統。


　　優點：


　　HBase預設存儲的資料類型都是字串，但Phoenix支援更多的資料類型。


　　使用JDBC運算元據，而不是HBase client API


　　在RegionServer端通過coprocessor過濾where條件，執行aggregation函數。 比較Hive on HBase,Impala on HBase和Phoenix這三者的架構是相似的，不同點就是Hive on HBase和Impala on HBase都沒有把coprocessor利用好，都是通過HBase client API把資料讀到他們自己進程的記憶體之後才進行的filter, aggregation等操作。


從查詢的角度來看HBase的column主要分為兩類：primary key(row key column)和other columns。 主要的不同是row key column能夠利用Region Server的index, filter, sort等特性，而other columns沒有這些特性，只能通過二級索引輔助做一些優化。 Phoenix能夠在HBase上創建二級索引用於優化條件查詢(目前只支援在static table上建二級索引，一個更通用的HBase二級索引實現方法參考 HTTPs://github.com/Huawei-Hadoop/hindex)。


　　如果是row key column上的IN/OR/LIKE條件，可以通過Region Server的skip scan filter優化。


　　Dynamic columns支援。


　　AutoCommit=false時(預設是false)把所有操作先緩存在用戶端，只有你顯示commit時才一次批量提交到HBase，SQL解析優化全是在用戶端做，這個有點事務的意思。


　　缺點：


　　不支援JOIN，考慮到HBase的設計初衷是儘量用冗餘數據減少複雜的JOIN操作，實際上可以把相關資料都放在同一個表裡，而不需要為了減少資料冗余，拆分到多個表中，所以很大程度也可以認為這不是一個缺點。


　　從架構上看也僅是把SQL轉成HBase Client的API和coprocessor的調用，而且coprocessor還不適合大規模資料的傳輸，所以如果中間結果的資料量還是比較大的話性能問題還是很明顯的。


　　這個缺點是所有的基於HBase的SQL系統都有的(包括Hive on HBase和Impala on HBase)。 不管什麼請求到HBase Region Server這邊都得通過RegionScanner，這個介面不是面向OLAP型應用優化的存儲檔讀取介面。 例如RegionScanner的實現裡好多條件比較，是不利於全資料表掃描的。


還有個問題就是coprocessor的問題了，由於coprocessor和HBase Region Server是在一個JVM裡面，所以當coprocessor計算邏輯非常複雜，中間結果資料量很大的時候會佔用大量記憶體。 同時coprocessor不是流式地讀取資料，某些節點資料積累過多也會造成記憶體不夠用的問題。


　　RoadMap:


　　JOIN支援，雖然有點不符合設計初衷，但是大家都支援，就我不支援，太過時了吧。


　　Transaction支援，通過參考 HTTPs://github.com/yahoo/omid的方法。


　　Online Schema Evolution，動態改變column的類型，rename等。


　　Hadapt/HadoopDB


　　架構和Hive相似，底層儲存引擎有兩種：HDFS和RDBMS(PostgreSQL)，一個DataNode節點上有一個RDBMS節點。


　　提供兩種介面：SQL和MR，SQL也是解析成MR job來執行的，所以總的來說執行引擎都是MR。


　　把多個MR任務，轉換成單node上的SQL+一個MR(data shuffle)，這個跟水準壓縮，垂直壓縮類似，儘量減少SQL解析出的MR task個數，減少任務之間寫HDFS的IO資料量。 把一個SQL拆解成兩部分：適合SQL做的用單機SQL，不適合的用MR(data shuffle)


和Hive的不同點在於Hive只能操控HDFS上的資料，而Hadapt可以操控HDFS和RDBMS兩種資料來源。 對於RDBMS這個資料來源來說，資料被預先load到分散式的RDBMS節點中，有統一的Catalog管理所有RDBMS中的資料。 例如Map中的有些執行邏輯直接通過一個在RDBMS上執行的SQL來獲得(修改InputFormat)，然後使用MR來做JOIN/Group By。 而且如果在資料被load到分散式PG節點上時分佈情況正好符合group by/order by的條件，那麼還省得通過MR的shuffle來做了。


　　Hadapt的本質還是把SQL解析成MR任務來做，所以Hive的有些缺點(啟動時間長，JOIN效率較低)它也是具有的。 還有如果想要join/group by/order by能夠在RDBMS資料來源之間高效執行，還得考慮資料預分佈的問題。


　　在執行多個查詢的時候，後面的查詢能夠利用前面查詢的查詢結果(有點類似于資料倉儲中的物化視圖的概念)，從而可以提高查詢的性能。


　　現在企業級應用大多使用的方案是Hadoop+MPP的方式，即通過Hadoop批次處理非結構化資料(進行ETL操作)然後通過connector導入MPP進行結構化資料的查詢操作。 但是這只是臨時的替代方案，Hadapt說invisible loading才是最合理的，這樣企業就有了一個統一分析平臺。


　　Hawq


　　原來GPDB中的存儲是本地磁片，現在改成HDFS，原來GPDB的單節點的RDBMS只充當執行引擎的功能，不再充當儲存引擎功能。


　　查詢執行通過GPDB的並存執行引擎(不再使用MR)，每次查詢開始把資料從HDFS中導入到GPDB，執行過程中通過記憶體交換資料而非MR那樣每次任務結束都寫磁片。


　　GP特有的cost-based parallel query optimizer and planner是它的一大優勢，也是目前其他大多數的產品中沒有的，它能夠幫使用者選出該SQL最高效的執行順序。


使用GPDB充當執行引擎的好處：標準SQL相容;支援ACID事務; JDBC/ODBC支援; JOIN順序優化和索引支援(查詢最佳化工具);支援行/列兩種存儲格式。


　　GPXF使得Hawq能夠讀取存儲在HDFS上的任何格式的資料以及存儲在其他檔案系統和設備中的資料。


　　底層的HDFS需要支援trancate語義和native C interface。


　　支援In-Database analytics ( HTTP://madlib.net/ ):


　　性能相關：


　　Scott Yara(Greenplum老大)公開承認Hawq比pure GPDB要慢。 這麼做的目的無非就是更好的利用HDFS的可擴充性，統一存儲管理。


　　和其他SQL on Hadoop產品的性能對比方面，Hawq在group by和join操作上與其他方案相比優勢明顯，前提是資料量不是特別大。 (是不是因為資料導入的時候partition做的好呢，是不是拿load的時間換group by/join的時間呢？ )


　　總之，目前在SQL on Hadoop領域普遍比較薄弱的環節是：


　　1. workload management and query optimization多個表的JOIN如何執行，例如3個表的JOIN會有6種執行策略，那麼哪一種才是效率最高的呢。 顯然要通過計算每種執行順序的開銷來獲得。 在傳統資料庫或者資料倉儲領域都有非常好的查詢最佳化工具，而在分散式系統中該如何衡量這些指標(磁片IO，網路頻寬，記憶體)與最後查詢效率之間的關係是個需要認真研究的問題。


　　2. 關聯子查詢correlated sub-queries還是沒有誰能夠實現。 在TPC-H中又很多關聯子查詢的例子，但是現在的SQL on Hadoop產品都不支援。 聽Impala的人說，他們客戶對這個的需求不是很強烈，大部分關聯子查詢可以轉化成JOIN操作。 但是目前的商業產品像Hawq是支援關聯子查詢的。


　　除了上面主要討論的開源產品以外，大資料分析領域還有很多商業產品。 這些商業產品可以分為兩類：一類是面向企業級應用的、以賣license或軟硬體一體機形式出售的Teradata/Aster Data, HP/Vertica, SAP/HANA,IBM/BigSQL, Oracle和Microsoft也有類似的產品;另一類是利用大規模雲計算基礎設施，提供的資料分析服務的Google/BigQuery(典型的Analysis as a Service)和Amazon/Redshif。