Impala：新一代開源大數據分析引擎

原文發表在《程序員》雜志2013年第8期，略有刪改。 文 / 耿益鋒 陳冠誠 ? 大數據處理是云計算中非常重要的問題，自Google公司提出MapReduce分布式處理框架以來，以Hadoop為代表的開源軟件受到越來越多公司的重視和青睞。以Hadoop為基礎，之后的HBase，Hive，

原文發表在《程序員》雜志2013年第8期，略有刪改。

文 / 耿益鋒陳冠誠

?大數據處理是云計算中非常重要的問題，自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：新一代開源大數據分析引擎, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com