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

時間 2020-02-12

原文原文鏈接

文 / 耿益鋒陳冠誠html

Impala 項目主頁在：https://github.com/cloudera/impalagit

大數據處理是雲計算中很是重要的問題，自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系統進行設計的。github

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負責子查詢的執行，最後返回子查詢的結果，這些中間結果通過彙集以後最終返回給用戶。apache

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

在Cloudera的測試中，Impala的查詢效率相比Hive，有數量級的提高。從技術角度上來看，Impala之因此能有好的性能，主要有以下幾方面的緣由：架構

Impala不須要把中間結果寫入磁盤，省掉了大量的I/O開銷。app
省掉了MapReduce做業啓動的開銷。MapReduce啓動task的速度是很慢的（默認每一個心跳間隔是3秒鐘），Impala直接經過相應的服務進程來進行做業調度，速度快了不少。框架
Impala徹底拋棄了MapReduce這個不太適合作SQL查詢的範式，而是像Dremel同樣借鑑了MPP並行數據庫的思想，重新另起爐竈，所以能夠作更多的查詢優化，從而能省掉沒必要要的shuffle，sort等開銷；
經過使用LLVM來統一編譯運行時代碼，避免了爲支持通用編譯而帶來的沒必要要開銷；
用C++實現，作了不少有針對性的硬件優化，例如使用SSE指令；
使用了支持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確實爲大數據的流行出錢出力。

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系統出來。總的來看，將來的大數據分析技術將會變得愈來愈成熟、愈來愈便宜、愈來愈易用；相應的，用戶將會更容易更方便地從本身的大數據中挖掘出有價值的商業信息。