Impala：新一代開源大資料分析引擎--轉載

標籤：

原文地址：http://www.parallellabs.com/2013/08/25/impala-big-data-analytics/

文 / 耿益鋒 陳冠誠

 大資料處理是雲端運算中非常重要的問題，自Google公司提出MapReduce分散式處理架構以來，以Hadoop為代表的開源軟體受到越來越多公司的重視和青睞。以Hadoop為基礎，之後的HBase，Hive，Pig等系統如雨後春筍般的加入了Hadoop的生態系統中。今天我們就來談談Hadoop系統中的一個新成員 – Impala。

Impala架構分析

Impala是Cloudera公司主導開發的新型查詢系統，它提供SQL語義，能夠查詢儲存在Hadoop的HDFS和HBase中的PB級大資料。已有的Hive系統雖然也提供了SQL語義，但是由於Hive底層執行使用的是MapReduce引擎，仍然是一個批處理過程，難以滿足查詢的互動性；相比之下，Impala的最大特點也是最大賣點就是它的快速。那麼Impala如何?大資料的快速查詢呢？在回答這個問題之前，我們需要先介紹Google的Dremel系統[1]，因為Impala最開始就是參照Dremel系統進行設計的。

 Dremel是Google的互動式資料分析系統，它構建於Google的GFS（Google File System）等系統之上，支撐了Google的資料分析服務BigQuery等諸多服務。Dremel的技術亮點主要有兩個：一個是實現了嵌套型資料的列儲存；二是使用了多層查詢樹，使得任務可以在數千個節點上的並存執行和彙總結果。列儲存在關係型資料庫中並不陌生，它可以減少查詢時處理的資料量，有效提升查詢效率。Dremel的列儲存的不同之處在於它針對的並不是傳統的關係資料，而是針對嵌套結構的資料。Dremel可以將一條條的嵌套結構的記錄轉換成列儲存形式，查詢時根據查詢條件讀取需要的列，然後進行條件過濾，輸出時再將列組裝成嵌套結構的記錄輸出，記錄的正向和反向轉換都通過高效的狀態機器實現。另一方面，Dremel的多層查詢樹則借鑒了分布式搜尋引擎的設計，查詢樹的根節點負責接收查詢，並將查詢分發到下一層節點，底層節點負責具體的資料讀取和查詢執行，然後將結果返回上層節點。關於Dremel技術實現上的更多資訊，讀者可以參閱[9]。

 Impala其實就是Hadoop的Dremel，Impala使用的列儲存格式是Parquet。Parquet實現了Dremel中的列儲存，未來還將支援Hive並添加字典編碼，遊程編碼等功能。Impala的系統架構一所示。Impala使用了Hive 的SQL介面（包括SELECT，INSERT，Join等操作），但目前只實現了Hive的SQL語義的子集（例如尚未對UDF提供支援），表的中繼資料資訊儲存在Hive的Metastore中。StateStore是Impala的一個子服務，用來監控叢集中各個節點的健康情況，提供節點註冊，錯誤偵測等功能。Impala在每個節點運行了一個後台服務impalad，impalad用來響應外部請求，並完成實際的查詢處理。Impalad主要包含Query Planner，Query Coordinator和Query Exec Engine三個模組。QueryPalnner接收來自SQL APP和 ODBC的查詢，然後將查詢轉換為許多子查詢，Query Coordinator將這些子查詢分發到各個節點上，由各個節點上的Query Exec Engine負責子查詢的執行，最後返回子查詢的結果，這些中間結果經過聚集之後最終返回給使用者。

 

圖1. Impala的系統架構圖 [2]

在Cloudera的測試中，Impala的查詢效率相比Hive，有數量級的提升。從技術角度上來看，Impala之所以能有好的效能，主要有如下幾方面的原因：

 1） Impala不需要把中間結果寫入磁碟，省掉了大量的I/O開銷。

2） 省掉了MapReduce作業啟動的開銷。MapReduce啟動task的速度是很慢的（預設每個心跳間隔是3秒鐘），Impala直接通過相應的服務進程來進行作業調度，速度快了很多。

3） Impala完全拋棄了MapReduce這個不太適合做SQL查詢的範式，而是像Dremel一樣借鑒了MPP並行資料庫的思想，從新另起爐灶，因此可以做更多的查詢最佳化，從而能省掉不必要的shuffle，sort等開銷；

4） 通過使用LLVM來統一編譯運行時代碼，避免了為支援通用編譯而帶來的不必要開銷；

5） 用C++實現，做了很多有針對性的硬體最佳化，例如使用SSE指令；

6） 使用了支援Data locality的I/O調度機制，儘可能的將資料和計算分配在同一台機器上進行，減少了網路開銷；

雖然Impala是參照Dremel來實現，但是Impala也有一些自己的特色，例如Impala不僅僅支援Parquet格式，同時也可以直接處理文本，SequenceFile等Hadoop中常用的檔案格式。另外一個更關鍵的地方在於，Impala是開源的，再加上Cloudera在Hadoop領域的領導地位，其生態圈有很大可能會在將來快速成長。可以預見在不久的未來，Impala很可能像之前的Hadoop和Hive一樣在大資料處理領域大展拳腳。Cloudera自己也說期待未來Impala能完全取代Hive。當然，使用者從Hive上遷移到Impala上來是需要時間的，而且Impala也只是剛剛發布1.0版，雖然號稱已經可以穩定的在生產環境上運行，但相信仍然有很多可改進的空間[7]。需要說明的是，Impala並不是用來取代已有的MapReduce系統，而是作為MapReduce的一個強力補充，總的來說Impala適合用來處理輸出資料適中或比較小的查詢，而對於大資料量的批處理任務，MapReduce依然是更好的選擇。另外一個花邊訊息是，Cloudera裡負責Impala的架構師Marcel Komacker就曾在Google負責過F1系統的查詢引擎開發，可見Google確實為大資料的流行出錢出力J

Impala與Shark，Drill等的比較

開源組織Apache也發起了名為Drill的項目來實現Hadoop上的Dremel，目前該項目正在開發當中，相關的文檔和代碼還不多，可以說暫時還未對Impala構成足夠的威脅[10]。從Quora上的問答來看，Cloudera有7-8名工程師全職在Impala項目上，而相比之下Drill目前的動作稍顯遲鈍。具體來說，截止到2012年10月底，Drill的程式碼程式庫裡實現了query parser, plan parser，及能對JSON格式的資料進行掃描的plan evaluator；而Impala同期已經有了一個比較完畢的分布式query execution引擎，並對HDFS和HBase上的資料讀入，錯誤偵測，INSERT的資料修改，LLVM動態翻譯等都提供了支援。當然，Drill作為Apache的項目，從一開始就避免了某個vendor的一家獨大，而且對所有Hadoop流行的發行版都會做相應的支援，不像Impala只支援Cloudera自己的發行版CDH。從長遠來看，誰會佔據上風還真不一定[10]。

除此之外，加州伯克利大學AMPLab也開發了名為Shark的大資料分析系統。在今天6月份的《程式員》上有一篇專門分析與Shark相關的Spark系統的文章，感興趣的讀者朋友可以參考。從長遠目標來看，Shark想成為一個既支援大資料SQL查詢，又能支援進階資料分析任務的一體化資料處理系統。從技術實現的角度上來看，Shark基於Scala語言的運算元推導實現了良好的容錯機制，因此對失敗了的長任務和短任務都能從上一個“快照點”進行快速恢複。相比之下，Impala由於缺失足夠強大的容錯機制，其上啟動並執行任務一旦失敗就必須“從頭來過”，這樣的設計必然會在效能上有所缺失。而且Shark是把記憶體當作第一類的儲存介質來做的系統設計，所以在處理速度上也會有一些優勢[11]。實際上，AMPLab最近對Hive，Impala，Shark及Amazon採用的商業MPP資料庫Redshift進行了一次對比實驗，在Scan Query，Aggregation Query和Join Query三種類型的任務中對它們進行了比較。圖2就是AMPLab報告中Aggregation Query的效能對比。在圖中我們可以看到，商業版本的Redshift的效能是最好的， Impala和Shark則各有勝負，且兩者都比Hive的效能高出了一大截。更多相關的實驗結果讀者朋友可以參考[12]。

圖2. Redshift，Impala，Shark與Hive的Aggregation Query效能對比 [12]

以筆者愚見，其實對大資料分析的項目來說，技術往往不是最關鍵的。例如Hadoop中的MapReduce和HDFS都是源於Google，原創性較少。事實上，開源項目的生態圈，社區，發展速度等，往往在很大程度上會影響Impala和Shark等開源大資料分析系統的發展。就像Cloudera一開始就決定會把Impala開源，以期望利用開源社區的力量來推廣這個產品；Shark也是一開始就開源了出來，更不用說Apache的Drill更是如此。說到底還是誰的生態系統更強的問題。技術上一時的領先並不足以保證項目的最終成功。雖然最後那一款產品會成為事實上的標準還很難說，但是，我們唯一可以確定並堅信的一點是，大資料分析將隨著新技術的不斷推陳出新而不斷普及開來，這對使用者永遠都是一件幸事。舉個例子，如果讀者注意過下一代Hadoop（YARN）的發展的話就會發現，其實YARN已經支援MapReduce之外的計算範式（例如Shark，Impala等），因此將來Hadoop將可能作為一個相容並包的大平台存在，在其上提供各種各樣的資料處理技術，有應對秒量級查詢的，有應對大資料批處理的，各種功能應有盡有，滿足使用者各方面的需求。

未來展望

其實除了Impala，Shark，Drill這樣的開源方案外，像Oracle，EMC等傳統廠商也沒在坐以待斃等著自己的市場被開源軟體侵吞。像EMC就推出了HAWQ系統，並號稱其效能比之Impala快上十幾倍，而前面提到的Amazon的Redshift也提供了比Impala更好的效能。雖然說開源軟體因為其強大的成本優勢而擁有極其強大的力量，但是傳統資料庫廠商仍會嘗試推出效能、穩定性、維護服務等指標上更加強大的產品與之進行差異化競爭，並同時參與開源社區、借力開源軟體來豐富自己的產品線、提升自己的競爭力，並通過更多的高附加值服務來滿足某些消費者需求。畢竟，這些廠商往往已在並行資料庫等傳統領域積累了大量的技術和經驗，這些底蘊還是非常深厚的。甚至現在還有像NuoDB（一個創業公司）這樣號稱即支援ACID，又有Scalability的NewSQL系統出來。總的來看，未來的大資料分析技術將會變得越來越成熟、越來越便宜、越來越易用；相應的，使用者將會更容易更方便地從自己的大資料中挖掘出有價值的商業資訊。

參考資料

[1]http://research.google.com/pubs/pub36632.html

[2]http://blog.cloudera.com/blog/2012/10/cloudera-impala-real-time-queries-in-apache-hadoop-for-real/

[3]http://www.slideshare.net/cloudera/data-science-on-hadoop

[4] Impala重點問題列表：http://yuntai.1kapp.com/?p=1089

[5] Hive原理與不足：http://www.ccplat.com/?p=1035

[6] Impala/Hive現狀分析與前景展望：http://yanbohappy.sinaapp.com/?p=220

[7] What’s next for Cloudera Impala:http://blog.cloudera.com/blog/2012/12/whats-next-for-cloudera-impala/

[8] MapReduce：一個巨大的倒退：http://t.cn/zQLFnWs

[9] Google Dremel 原理 — 如何能3秒分析1PB：http://www.yankay.com/google-dremel-rationale/

[10] Isn’t Cloudera Impala doing the same job as Apache Drill incubator project? http://www.quora.com/Cloudera-Impala/Isnt-Cloudera-Impala-doing-the-same-job-as-Apache-Drill-incubator-project

[11] Shark：https://github.com/amplab/shark/wiki

[12] Big Data Benchmark: https://amplab.cs.berkeley.edu/benchmark/

[13] Impala wiki：http://dirlt.com/impala.html

[14]How does Impala compare to Shark: http://www.quora.com/Apache-Hadoop/How-does-Impala-compare-to-Shark

[15] EMC講解Hawq SQL效能：左手Hive右手Impala: http://stor-age.zdnet.com.cn/stor-age/2013/0308/2147607.shtml

 作者簡介

耿益鋒，清華大學電腦系博士研究生，主要研究方向包括大資料處理和雲端運算中新應用和新情境下分布式系統的設計和最佳化。

陳冠誠，IBM中國研究院研究員，主要技術方向為大規模分布式系統中的軟硬體協同設計。個人部落格為並行實驗室（www.parallellabs.com），新浪微博@冠誠。

 

Impala：新一代開源大資料分析引擎--轉載