開源大資料查詢分析引擎現狀

標籤：

引言

 

大資料查詢分析是雲端運算中核心問題之一，自從Google在2006年之前的幾篇論文奠定雲端運算領域基礎，尤其是GFS、Map-Reduce、Bigtable被稱為雲端運算底層技術三大基石。GFS、Map-Reduce技術直接支援了Apache Hadoop項目的誕生。Bigtable和Amazon Dynamo直接催生了NoSQL這個嶄新的資料庫領域，撼動了RDBMS在商用資料庫和資料倉儲方面幾十年的統治性地位。FaceBook的Hive項目是建立在Hadoop上的資料倉儲基礎構架，提供了一系列用於儲存、查詢和分析大規模資料的工具。當我們還浸淫在GFS、Map-Reduce、Bigtable等Google技術中，並進行理解、掌握、模仿時，Google在2009年之後，連續推出多項新技術，包括：Dremel、Pregel、Percolator、Spanner和F1。其中，Dremel促使了即時計算系統的興起，Pregel開闢了圖資料計算這個新方向，Percolator使分布式增量索引更新成為文本檢索領域的新標準，Spanner和F1向我們展現了跨資料中心資料庫的可能。在Google的第二波技術浪潮中，基於Hive和Dremel，新興的大資料公司Cloudera開源了大資料查詢分析引擎Impala，Hortonworks開源了Stinger，Fackbook開源了Presto。類似Pregel，UC Berkeley AMPLAB實驗室開發了Spark圖計算架構，並以Spark為核心開源了大資料查詢分析引擎Shark。由於某電信電訊廠商項目中大資料查詢引擎選型需求，本文將會對Hive、Impala、Shark、Stinger和Presto這五類主流的開源大資料查詢分析引擎進行簡要介紹以及效能比較，最後進行總結與展望。Hive、Impala、Shark、Stinger和Presto的進化圖譜1所示。

 

 
圖1. Impala、Shark、Stinger和Presto的進化圖譜

當前主流引擎簡介

 

基於Map-Reduce模式的Hadoop擅長資料批處理，不是特別符合即時查詢的情境。即時查詢一般使用MPP (Massively Parallel Processing)的架構，因此使用者需要在Hadoop和MPP兩種技術中選擇。在Google的第二波技術浪潮中，一些基於Hadoop架構的快速SQL訪問技術逐步獲得人們關注。現在有一種新的趨勢是MPP和Hadoop相結合提供快速SQL訪問架構。最近有四個很熱門的開源工具出來：Impala、Shark、Stinger和Presto。這也顯示了大資料領域對於Hadoop生態系統中支援即時查詢的期望。總體來說，Impala、Shark、Stinger和Presto四個系統都是類SQL即時大資料查詢分析引擎，但是它們的技術側重點完全不同。而且它們也不是為了替換Hive而生，Hive在做資料倉儲時是非常有價值的。這四個系統與Hive都是構建在Hadoop之上的資料查詢工具，各有不同的側重適應面，但從用戶端使用來看它們與Hive有很多的共同之處，如資料表中繼資料、Thrift介面、ODBC/JDBC驅動、SQL文法、靈活的檔案格式、儲存資源集區等。Hive與Impala、Shark、Stinger、Presto在Hadoop中的關係2所示。Hive適用於長時間的批處理查詢分析，而Impala、Shark、Stinger和Presto適用於即時互動式SQL查詢，它們給資料分析人員提供了快速實驗、驗證想法的大資料分析工具。可以先使用Hive進行資料轉換處理，之後使用這四個系統中的一個在Hive處理後的結果資料集上進行快速的資料分析。下面，從問題域出發簡單介紹Hive、Impala、Shark、Stinger和Presto：

 

1) Hive，披著SQL外衣的Map-Reduce。Hive是為方便使用者使用Map-Reduce而在外面封裝了一層SQL，由於Hive採用了SQL，它的問題域比Map-Reduce更窄，因為很多問題，SQL表達不出來，比如一些資料採礦演算法，推薦演算法、Image Recognition演算法等，這些仍只能通過編寫Map-Reduce完成。

 

2) Impala：Google Dremel的開源實現（Apache Drill類似），因為互動式即時計算需求，Cloudera推出了Impala系統，該系統適用於互動式即時處理情境，要求最後產生的資料量一定要少。

 

3) Shark/Spark：為了提高Map-Reduce的計算效率，Berkeley的AMPLab實驗室開發了Spark，Spark可看做基於記憶體的Map-Reduce實現，此外，伯克利還在Spark基礎上封裝了一層SQL，產生了一個新的類似Hive的系統Shark。

 

4) Stinger Initiative（Tez optimized Hive）：Hortonworks開源了一個DAG計算架構Tez，Tez可以理解為Google Pregel的開源實現，該架構可以像Map-Reduce一樣，可以用來設計DAG應用程式，但需要注意的是，Tez只能運行在YARN上。Tez的一個重要應用是最佳化Hive和PIG這種典型的DAG應用情境，它通過減少資料讀寫IO，最佳化DAG流程使得Hive速度提供了很多倍。

 

5) Presto：FaceBook於2013年11月份開源了Presto，一個分布式SQL查詢引擎，它被設計為用來專門進行高速、即時的資料分析。它支援標準的ANSI SQL，包括複雜查詢、彙總（aggregation）、串連（join）和視窗函數（window functions)。Presto設計了一個簡單的資料存放區的抽象層，來滿足在不同資料存放區系統（包括HBase、HDFS、Scribe等）之上都可以使用SQL進行查詢。

 

 
圖2. Hive與Impala、Shark、Stinger、Presto在Hadoop中的關係

 

當前主流引擎架構

 

Hive

Hive是基於Hadoop的一個資料倉儲工具，可以將結構化的資料檔案映射為一張資料庫表，並提供完整的SQL查詢功能，可以將SQL語句轉換為Map-Reduce任務進行運行，十分適合資料倉儲的統計分析。其架構3所示，Hadoop和Map-Reduce是Hive架構的根基。Hive架構包括如下組件：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。
 

圖3. Hive架構

Impala架構

 

Impala是Cloudera在受到Google的Dremel啟發下開發的即時互動SQL大資料查詢工具，它可以看成是Google Dremel架構和MPP (Massively Parallel Processing)結構的結合體。Impala沒有再使用緩慢的Hive&Map-Reduce批處理，而是通過使用與商用並行關聯式資料庫中類似的分散式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢資料，從而大大降低了延遲，其架構4所示，Impala主要由Impalad，State Store和CLI組成。Impalad與DataNode運行在同一節點上，由Impalad進程表示，它接收用戶端的查詢請求（接收查詢請求的Impalad為Coordinator，Coordinator通過JNI調用java前端解釋SQL查詢語句，產生查詢計劃樹，再通過調度器把執行計畫分發給具有相應資料的其它Impalad進行執行），讀寫資料，並存執行查詢，並把結果通過網路流式的傳送回給Coordinator，由Coordinator返回給用戶端。同時Impalad也與State Store保持串連，用於確定哪個Impalad是健康和可以接受新的工作。Impala State Store跟蹤叢集中的Impalad的健康狀態及位置資訊，由state-stored進程表示，它通過建立多個線程來處理Impalad的註冊訂閱和與各Impalad保持心跳串連，各Impalad都會緩衝一份State Store中的資訊，當State Store離線後，因為Impalad有State Store的緩衝仍然可以工作，但會因為有些Impalad失效了，而已快取資料無法更新，導致把執行計畫分配給了失效的Impalad，導致查詢失敗。CLI提供給使用者查詢使用的命令列工具，同時Impala還提供了Hue，JDBC，ODBC，Thrift使用介面。

 

 
圖4. Impala架構

 

Shark架構

 

Shark是UC Berkeley AMPLAB開源的一款資料倉儲產品，它完全相容Hive的HQL文法，但與Hive不同的是，Hive的計算架構採用Map-Reduce，而Shark採用Spark。所以，Hive是SQL on Map-Reduce，而Shark是Hive on Spark。其架構4所示，為了最大程度的保持和Hive的相容性，Shark複用了Hive的大部分組件，如下所示：

 

1) SQL Parser&Plan generation: Shark完全相容Hive的HQL文法，而且Shark使用了Hive的API來實現query Parsing和 query Plan generation，僅僅最後的Physical Plan execution階段用Spark代替Hadoop Map-Reduce；

 

2) metastore：Shark採用和Hive一樣的meta資訊，Hive裡建立的表用Shark可無縫訪問；

 

3) SerDe: Shark的序列化機制以及資料類型與Hive完全一致；

 

4) UDF: Shark可重用Hive裡的所有UDF。通過配置Shark參數，Shark可以自動在記憶體中緩衝特定的RDD（Resilient Distributed Dataset），實現資料重用，進而加快特定資料集的檢索。同時，Shark通過UDF使用者自訂函數實現特定的資料分析學習演算法，使得SQL資料查詢和運算分析能結合在一起，最大化RDD的重複使用；

 

5) Driver：Shark在Hive的CliDriver基礎上進行了一個封裝，產生一個SharkCliDriver，這是shark命令的入口；

 

6) ThriftServer：Shark在Hive的ThriftServer（支援JDBC/ODBC）基礎上，做了一個封裝，產生了一個SharkServer，也提供JDBC/ODBC服務。

 

 
圖5. Shark架構

 

Spark是UC Berkeley AMP lab所開源的類Hadoop Map-Reduce的通用的並行計算架構，Spark基於Map-Reduce演算法實現的分散式運算，擁有Hadoop Map-Reduce所具有的優點；但不同於Map-Reduce的是Job中間輸出和結果可以儲存在記憶體中，從而不再需要讀寫HDFS，因此Spark能更好地適用於資料採礦與機器學習等需要迭代的Map-Reduce的演算法。其架構6所示：

 

 
圖6. Spark架構

與Hadoop的對比，Spark的中間資料放到記憶體中，對於迭代運算效率更高，因此Spark適用於需要多次操作特定資料集的應用場合。需要反覆操作的次數越多，所需讀取的資料量越大，受益越大，資料量小但是計算密集度較大的場合，受益就相對較小。Spark比Hadoop更通用，Spark提供的資料集操作類型有很多種（map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等），而Hadoop只提供了Map和Reduce兩種操作。Spark可以直接對HDFS進行資料的讀寫，同樣支援Spark on YARN。Spark可以與Map-Reduce運行於同叢集中，共用儲存資源與計算，資料倉儲Shark實現上借用Hive，幾乎與Hive完全相容。

Stinger架構

 

Stinger是Hortonworks開源的一個即時類SQL即時查詢系統，聲稱可以提升較Hive 100倍的速度。與Hive不同的是，Stinger採用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一個重要作用是最佳化Hive和PIG這種典型的DAG應用情境，它通過減少資料讀寫IO，最佳化DAG流程使得Hive速度提供了很多倍。其架構7所示， Stinger是在Hive的現有基礎上加了一個最佳化層Tez（此架構是基於Yarn），所有的查詢和統計都要經過它的最佳化層來處理，以減少不必要的工作以及資源開銷。雖然Stinger也對Hive進行了較多的最佳化與加強，Stinger總體效能還是依賴其子系統Tez的表現。而Tez是Hortonworks開源的一個DAG計算架構，Tez可以理解為Google Pregel的開源實現，該架構可以像Map-Reduce一樣，用來設計DAG應用程式，但需要注意的是，Tez只能運行在YARN上。

 

 
圖7. Stinger架構

 

Presto架構

 

2013年11月Facebook開源了一個分布式SQL查詢引擎Presto，它被設計為用來專門進行高速、即時的資料分析。它支援標準的ANSI SQL子集，包括複雜查詢、彙總、串連和視窗函數。其簡化的架構8所示，用戶端將SQL查詢發送到Presto的協調器。協調器會進行語法檢查、分析和規劃查詢計劃。調度器將執行的管道組合在一起，將任務分配給那些裡資料最近的節點，然後監控執行過程。用戶端從輸出段中將資料取出，這些資料是從更底層的處理段中依次取出的。Presto的運行模型與Hive有著本質的區別。Hive將查詢翻譯成多階段的Map-Reduce任務，一個接著一個地運行。每一個任務從磁碟上讀取輸入資料並且將中間結果輸出到磁碟上。然而Presto引擎沒有使用Map-Reduce。它使用了一個定製的查詢執行引擎和響應操作符來支援SQL的文法。除了改進的調度演算法之外，所有的資料處理都是在記憶體中進行的。不同的處理端通過網路組成處理的流水線。這樣會避免不必要的磁碟讀寫和額外的延遲。這種流水線式的執行模型會在同一時間運行多個資料處理段，一旦資料可用的時候就會將資料從一個處理段傳入到下一個處理段。 這樣的方式會大大的減少各種查詢的端到端回應時間。同時，Presto設計了一個簡單的資料存放區抽象層，來滿足在不同資料存放區系統之上都可以使用SQL進行查詢。儲存連接器目前支援除Hive/HDFS外，還支援HBase、Scribe和定製開發的系統。
 

圖8. Presto架構

 

效能評測總結

 

通過對Hive、Impala、Shark、Stinger和Presto的評測和分析，總結如下：

 

1) 列儲存一般對查詢效能提升明顯，尤其是大表是一個包含很多列的表。例如，從Stinger（Hive 0.11 with ORCFile）VS Hive，以及Impala的Parquet VS Text file；

 

2) 繞開MR計算模型，省去中間結果的持久化和MR任務調度的延遲，會帶來效能提升。例如，Impala，Shark，Presto要好於Hive和Stinger，但這種優勢隨著資料量增加和查詢變複雜而減弱；

 

3) 使用MPP資料庫技術對串連查詢有協助。例如，Impala在兩表，多表串連查詢中優勢明顯；

 

4) 充分利用緩衝的系統在記憶體充足的情況下效能優勢明顯。例如，Shark，Impala在小資料量時效能優勢明顯；記憶體不足時效能下降嚴重，Shark會出現很多問題；

 

5) 資料扭曲會嚴重影響一些系統的效能。例如，Hive、Stinger、Shark對資料扭曲比較敏感，容易造成傾斜；Impala受這方面的影響似乎不大；
對於Hive、Impala、Shark、Stinger和Presto這五類開源的分析引擎，在大多數情況下，Imapla的綜合效能是最穩定的，時間效能也是最好的，而且其安裝配置過程也相對容易。其他分別為Presto、Shark、Stinger和Hive。在記憶體足夠和非Join操作情況下，Shark的效能是最好的。

 

總結與展望

 

對大資料分析的項目來說，技術往往不是最關鍵的，關鍵在於誰的生態系統更強，技術上一時的領先並不足以保證項目的最終成功。對於Hive、Impala、Shark、Stinger和Presto來講，最後哪一款產品會成為事實上的標準還很難說，但我們唯一可以確定並堅信的一點是，大資料分析將隨著新技術的不斷推陳出新而不斷普及開來，這對使用者永遠都是一件幸事。舉個例子，如果讀者注意過下一代Hadoop（YARN）的發展的話就會發現，其實YARN已經支援Map-Reduce之外的計算範式（例如Shark，Impala等），因此將來Hadoop將可能作為一個相容並包的大平台存在，在其上提供各種各樣的資料處理技術，有應對秒量級查詢的，有應對大資料批處理的，各種功能應有盡有，滿足使用者各方面的需求。

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

文章來源： 啟明星辰

開源大資料查詢分析引擎現狀