開源大數據查詢分析引擎

引言

 

大數據查詢分析是雲計算中核心問題之一，自從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表達不出來，好比一些數據挖掘算法，推薦算法、圖像識別算法等，這些仍只能經過編寫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更好的性能。雖說開源軟件由於其強大的成本優點而擁有極其強大的力量，可是傳統數據庫廠商仍會嘗試推出性能、穩定性、維護服務等指標上更增強大的產品與之進行差別化競爭，並同時參與開源社區、借力開源軟件來豐富本身的產品線、提高本身的競爭力，並經過更多的高附加值服務來知足某些消費者需求。畢竟，這些廠商每每已在並行數據庫等傳統領域積累了大量的技術和經驗，這些底蘊仍是很是深厚的。總的來看，將來的大數據分析技術將會變得愈來愈成熟、愈來愈便宜、愈來愈易用；相應的，用戶將會更容易更方便地從本身的大數據中挖掘出有價值的商業信息。