基于Hadoop的SQL查詢引擎性能研究

吳黎兵, 邱 鑫, 葉璐瑤, 王曉棟, 聶 雷

(1.武漢大學 計算機學院, 武漢 430072; 2.英特爾 英特爾亞太研發中心, 上海 201100)

?

基于Hadoop的SQL查詢引擎性能研究

吳黎兵1*, 邱 鑫1,2, 葉璐瑤1, 王曉棟2, 聶 雷1

(1.武漢大學 計算機學院, 武漢 430072; 2.英特爾 英特爾亞太研發中心, 上海 201100)

Apache Hadoop處理超大規模數據集有非常出色的表現,相比較于傳統的數據倉庫和關系型數據庫有不少優勢.為了讓原有業務能夠充分利用Hadoop的優勢,SQL-on-Hadoop系統越來越受到工業界和學術界的關注.基于Hadoop的SQL查詢引擎種類繁多,各有優勢,其運算引擎主要包括三種:①傳統的Map/Reduce引擎;②新興的Spark引擎;③基于shared-nothing架構的MPP引擎.本文選取了其中最有代表性的三種SQL查詢引擎—Hive、Spark SQL、Impala,并使用了一種類TPC-H的測試基準對它們的決策支持能力進行測試及評估.從實驗結果來看,Impala和Spark SQL相對于傳統的Hive都有較大的提高,其中Impala的部分查詢比Hive快了10倍以上,并且Impala在完成查詢所占用的集群資源也是最少的.然而若從穩定性、易用性、兼容性和性能等多個方面進行對比,并不存在各方面均最優的查詢引擎,因此在構建基于Hadoop的數據倉庫系統時,推薦采用Hive+Impala或者Hive+Spark SQL的混合架構.

大數據; SQL-on-Hadoop; 數據倉庫; Spark SQL; Impala; Hive

隨著數據量的急劇增長,傳統的數據倉庫應用已經難以滿足聯機分析處理 (On-line Analytical Processing, OLAP)對數據倉庫提出的新需求,特別是大數據4V特性中,大規模(Volume)、高復雜度(Variety)兩座大山讓擴展性不足的傳統數據倉庫不堪重負,尋求新型的高可擴展性數據倉庫成為了當務之急.

搭建在廉價商用機器之上的Hadoop[1],在處理超大數據集的優秀表現無疑是解決大數據問題的一大良方.其低成本、高性能、高可靠和高可擴展的特性已經逐漸得到業界的認可,國內外已有大量的應用案例.

Facebook公司[2-3]在面臨大數據的壓力后,對多套系統進行了深入的評估,最終選擇了Hadoop作為其商業數據庫的替代產品;中國農業銀行也已經將其歷史交易數據的存儲和查詢系統遷移到了x86服務器搭建的Hadoop集群之上,并從2013年開始對外提供長達10年的歷史交易數據查詢.

Hadoop平臺經過數年的發展,現已能完美滿足中國人民大學王珊教授在2011年對新型數據倉庫系統提出的8個重要特性[4].Hadoop的分布式文件系統(Hadoop Distributed File System, HDFS)雖然搭建在廉價的x86服務器上,但是其穩定性和可靠性已經達到了生產系統的要求,并且擁有極高的可擴展性,可以提供PB甚至ZB級別的存儲空間,不會出現傳統數據倉庫存儲空間耗盡后陷入擴容難的窘境.同時Hadoop平臺上的數據處理工具也十分豐富,不僅支持對結構化數據的處理,更可以處理半結構化甚至是非結構化的數據;支持的計算類型也不再是單一的Map/Reduce[5]所代表的批處理,也有了新興的流式處理框架——Storm、Spark Streaming.幾乎所有的數據處理工作都可以在Hadoop平臺上完成,而傳統的架構經常需要將數據在多個不同功能的平臺之間導入導出,造成了數據的冗余和大量時間、帶寬的浪費.

數據倉庫最重要的功能是進行OLAP并為用戶提供決策支持,因此SQL查詢的性能十分重要.本文關注于Hadoop平臺上的SQL執行引擎,也就是SQL-on-Hadoop系統.IBM的研究人員將SQL-on-Hadoop系統分為兩大類,Database-Hadoop hybrids和Native Hadoop-based systems[6].第一類僅利用了Hadoop的容錯性和調度方法,使用關系型數據庫執行查詢,其中的代表有Microsoft PolyBase、Pivotal HAWQ[7]、Hadapt以及IBM Big SQL;第二類系統與Hadoop集成度較高,充分利用了Hadoop高可擴展性的優勢,其中有3個大類:①基于Map/Reduce的Hive;②內存計算框架Apache Spark的子項目Spark SQL;③基于shared-nothing架構的大規模并行處理(Massively Parallel Processing, MPP)引擎,如Cloudera Impala、Apache Drill、LinkedIn Tajo和Facebook Presto.

本文選取了最具代表性的、架構各不相同的3種查詢引擎Spark SQL、Impala、Hive進行對比分析.

1 SQL-on-Hadoop系統

Hive是Hadoop生態系統中第一個SQL查詢引擎,也是目前應用最廣泛的一個.它在處理超大規模數據集時十分的穩定,但是在處理較小的數據集時受Map/Reduce高啟動延時的影響較為明顯.而新興的查詢引擎如Impala、Spark SQL主要是為了解決Hive進行ad-hoc查詢和交互式查詢時延時較高的問題.

如表1所示,Hive、Impala、Spark SQL的架構、運行環境和使用編程語言完全不同,Hive依賴于Map/Reduce,Spark SQL依賴于Spark,Map/Reduce和Spark都運行在Java虛擬機(Java Virtual Machine,JVM)上.而Impala則采用了無共享結構的(shared-nothing)架構,并使用了C/C++編寫,運行環境不同于Map/Reduce和Spark.3種查詢引擎均支持Hive查詢語句(Hive Query Language,HiveQL)和絕大部分的SQL92語法,同時Spark還擁有一種對彈性分布式數據集(Resilient Distributed Datasets,RDDs)進行查詢的本地語言(Domain Specific Language,DSL),可以很方便地嵌入到Spark應用程序中使用.3種查詢引擎均支持從HDFS上讀取多種格式的數據,Hive和Impala可以從基于Hadoop的NoSQL數據庫HBase中讀取數據,而Spark SQL支持讀取JSON格式的數據,這為分析網絡應用的數據提供了較大的便利.

表1 Hive、Spark SQL、Impala對比

1.1 Hive

Facebook公司將大量的數據轉移到HDFS上面以后,發現Map/Reduce在性能上已經滿足了需求,但是Hadoop的Map/Reduce編程模型較為底層,對于用戶來說并不友好,特別是對數據分析師們來說,他們熟知SQL卻對Java和Map/Reduce框架并不熟悉.雖然直接使用Map/Reduce開發應用的程序執行效率高,但是研發周期長、成本高并且代碼難以復用和維護.因此,簡單易用、高效率的SQL查詢系統更有用武之地,Hive就在這種環境下應運而生的.

Hive是構建在Hadoop之上的、開源的、通用的、可伸縮的SQL引擎,它使用一種類SQL語句—HiveQL對數據進行處理.如圖1中Hive的架構部分所示,Hive主要由元數據倉庫(MetaStore)和驅動(Driver)兩大組件構成.Hive的元數據倉庫中存儲Hive表的元數據信息,現在已經成為眾多SQL-on-Hadoop系統的共享元數據倉庫.驅動中又包括了編譯器(Compiler)、優化器(Optimizer)、執行器(Executor)3個模塊.用戶可以通過Hive Shell、JDBC/ODBC連接和Hadoop web界面程序Hue提交HiveQL語句,驅動在接收HiveQL語句后,先由編譯器根據存儲在Hive元數據倉庫中的元數據信息對該語句進行類型檢查和語義分析,其后生成對應的邏輯計劃(Logic Plan),邏輯計劃會被傳遞給優化器進行優化后生成一個由Map/Reduce作業和HDFS作業所組成的無回路有向圖(Directed Acycli Graph,DAG)執行計劃—優化的邏輯計劃(Optimized Logic Plan),執行器最后按照最優計劃中描述的依賴關系將Map/Reduce作業依次提交給Hadoop集群,所有任務完成后再將執行結果返回給用戶.

Hive是Hadoop生態系統中第一個SQL執行引擎,也是目前最為穩定的SQL引擎,但是由于Hive所依賴的Map/Reduce存在如下兩點不足影響了Hive的性能:

1) 重量級的執行單元.每個Map和Reduce作業都需要啟動一個JVM來執行,雖然可以對JVM進行重用,但是花費在作業啟動上的時間依然不少;

2) I/O讀寫.較為復雜的SQL語句會被解釋成多個Map/Reduce作業運行,每個Map/Reduce作業執行結束后的中間結果需要暫存在HDFS上,這導致會在I/O上額外花費大量的時間.

1.2 Spark SQL

為解決Map/Reduce框架的不足,加州大學伯克利分校的AmpLab提出了內存計算框架Spark[8],Spark使用了較為輕量的線程作為執行器,從而大大減少了作業啟動的開銷,降低了通信成本,提高了調度的響應速度;并且Spark支持通用計算有向圖(general computation DAGs),不再是只由Map和Reduce操作所組成的兩級拓撲結構,從而減少了大量不必要的Map任務.Spark提供了一種高效的、可靠的、分布式的共享內存抽象—RDDs,RDDs使得Spark上的應用程序可以以特定的抽象格式將數據緩存到Spark集群的內存中,可以對RDDs使用map、filter、flatMap、reduceByKey等操作構建出新的RDDs[9].如Spark SQL中所使用Schema RDDs是一個由Row對象組成的、擁有結構信息的特殊RDDs,除了可以對它使用普通RDDs同樣的操作以外,還可以使用HiveQL、DSL對Schema RDDs進行查詢.

圖1 Hadoop、Hive、Impala與Spark架構圖Fig.1 Architecture of Hadoop, Hive, Impala and Spark

Spark SQL中驅動(Driver)的架構與其前身Shark[10]類似,但是與Shark依賴Hive來生成查詢計劃不同,Spark SQL僅依賴Hive的HiveQL解釋器(HiveQL Parser)來生成HiveQL的抽象語法樹(Abstract Syntax Tree, AST),并擁有自己的查詢優化器Catalyst,不再依賴于Hive進行查詢優化.如圖2所示,Catalyst接受來自HiveQL解釋器生成的AST后,將會依次進行邏輯計劃、優化的邏輯計劃、物理計劃(Physical Plans)的生成,最終有一個或多個物理計劃產生.Catalyst會根據它的運算代價模型(Cost Model)對所有物理計劃進行評估,然后根據最優的物理計劃生成其關聯執行操作(Relation Execution Operators).與Hive類似,驅動會通過Spark Context將Spark操作依次提交給Spark集群,在所有任務執行完成后將最終結果提交給用戶.

1.3 Impala

Impala[11]使用了與Spark完全不同的方法解決Hive查詢高延時的問題,它是由Cloudera公司主導開發的類MPP的SQL引擎.雖然架構在Hadoop之上,卻并不依賴Map/Reduce處理數據,而是使用本地的MPP執行引擎.Impala的設計思想起源于Google在2011年發表的Dremel[12],將MPP數據倉庫的shared-nothing思想與Hadoop的高可擴展性、高可靠性融合在了一起.

圖2 Catalyst執行流程Fig.2 Catalyst Executing Process

如圖1中Impala的架構部分所示,與Hive、Spark SQL架構有很大的不同,Impala使用的是經典的shared-nothing架構,在每個工組節點上均運行著一個名為impalad的守護進程,每個impalad都由計劃器(Planner)、協調器(Coordinator)和執行引擎(Exection Engine)3個模塊組成,用戶可以連接到任意一個impalad后提交自己的SQL語句,接收到SQL語句的impalad就會成為這次查詢的協調節點(Coordinate Node).協調節點的計劃器將根據Catalog Server中緩存的元數據信息和NameNode中數據塊的信息來生成執行計劃,然后協調器將任務分發給其他impalad,其他impalad任務執行完成后將結果返回,協調節點對收到的所有數據進行匯總后,再將最終結果返回給用戶.

2 實驗與分析

本文實驗采用了一套類TPC-H的測試基準,對Hive、Spark SQL、Impala的決策支持能力進行測試.TPC-H測試基準由英特爾和數家知名廠商共同制定,是一套評估數據倉庫決策支持能力的基準程序(Benchmark),它由一系列模擬真實業務的ad-hoc查詢和并發數據修改語句組成,SQL語句和數據集的具體描述參見說明文檔(http://www.tpc.org/tpc-documents-current-versions/pdf/tpch2.17.1.pdf).測試所用SQL語句是改寫后的HiveQL語句,由于TPC-H所用的SQL92語法在HiveQL中并不完全兼容,因此TPC-H的22個SQL語句中Q11和Q22無法執行.

2.1 測試環境

測試集群為8臺物理服務器,操作系統為RadHat6.4,每臺機器配備雙路二十核Intel Xeon CPU E5-2660 v2 @ 2.20GHz CPU,內存64GB,4塊7200轉2TB SATA硬盤:其中一塊系統盤,3塊為數據盤.由于磁盤陣列(Redundant Arrays of Independent Disks, RAID)會對Hadoop的性能有影響,故數據盤未做RAID,網絡環境為千兆網.其中一臺機器作為主節點,剩余7臺為工作節點,集群拓撲如圖3所示.所使用的軟件版本:Hadoop 2.5.0-cdh5,Hive 0.13.1-cdh5,Apache Spark 1.1.0,Impala 2.0.0-cdh5.

圖3 集群拓撲圖Fig.3 Cluster topology

2.2 數據及數據格式

Hive、Impala、Spark SQL共用同一份存儲在HDFS上的數據集,由TPC-H提供的DBGen程序生成,并存儲在HDFS上.如表2所示,共有8個表,原始文本文件共215.1GB,使用了3種不同的文件格式進行測試.

Parquet是Hadoop上的一種通用的、高效的列式存儲格式,相對于純文本文件有一定的壓縮率,能夠節省HDFS的存儲空間.Parquet文件可以使用Snappy或gzip壓縮算法進行進一步的壓縮.使用壓縮文件可以節省磁盤空間,并減小磁盤I/O壓力,但是需要消耗一部分計算資源進行解壓縮,所以可能會對性能有一定影響.綜合考慮,本文對Parquet文件的壓縮方法選用了壓縮比和解壓速度較為均衡的Snappy.

表2 實驗數據集

2.3 統計信息

統計信息分為表的統計信息和列的統計信息,表的統計信息包括表的行數、表的文件數以及表的所有數據文件的總字節數,列的統計信息包括該列的最大值、最小值、數值類型的絕對值之和、空行數等信息.查詢引擎的優化器可以根據統計信息使用基于損耗的優化方法,計算不同執行計劃所需的損耗,從而選出最優的執行計劃.如果在用戶提交的查詢恰好是統計信息中已有的信息時,可以不執行查詢,直接將結果返回給用戶.

Hive使用了“ANALYZE TABLE [table-name] COMPUTE STATISTICS FOR COLUMNS”計算每個表和所有列的統計信息,Spark SQL使用Hive收集到的統計信息,Impala使用了“compute stats [table-name]”計算每個表的統計信息.

2.4 實驗結果

表3 查詢運行時間

實驗采用20個SQL依次運行的方式,執行結果如表3所示.從總運行時間來看,Impala與Spark SQL的查詢速度與Hive相比都有較大的提高,Impala比Hive快了1.5倍,Spark SQL比Hive快了0.5倍.Impala有部分查詢的速度比Hive快了10倍甚至更多,如Q6、Q12和Q15.Spark SQL表現并沒有Impala出色,它是Spark在2014年9月發布的1.0.0版本中才推出的,在實驗中所用的Spark 1.1.0中還屬于測試組件,因此并不太穩定.同時因為其對Parquet格式的查詢存在一些問題,并沒能得到正確的結果.Impala處理Parquet格式時的效率顯著提高,特別是針對Parquet的單表統計查詢,如Q1的查詢速度提高了5倍之多，Q6的查詢速度也有6.5倍的提高.以Q1為例,Q1的查詢語句如下:

Q1: SELECT L-RETURNFLAG, L-LINESTATUS,

SUM(L-QUANTITY), SUM(L-EXTENDEDPRICE),

SUM(L-EXTENDEDPRICE*(1-L-DISCOUNT)),

SUM(L-EXTENDEDPRICE*(1-L-DISCOUNT)*(1+L-TAX)), AVG(L-QUANTITY),

AVG(L-EXTENDEDPRICE), AVG(L-DISCOUNT),

COUNT(1)

FROM lineitem

WHERE L-SHIPDATE<='1998-09-02'

GROUP BY L-RETURNFLAG, L-LINESTATUS

ORDER BY L-RETURNFLAG, L-LINESTATUS;

Q1對lineitem表中L-SHIPDATE字段小于等于“1998-09-02”的數據進行了聚集操作,并根據L-RETURNFLAG和L-LINESTATUS兩個字段進行排序.通過查看查詢運行時的詳細信息,對文本文件的查詢需要遍歷整個lineitem表的149.4GB數據,對Parquet文件的查詢得益于Parquet列式存儲的優勢,只需要讀取查詢中需要處理的列,因此大大降低了I/O成本.Impala僅讀取了Parquet/None格式20.12%的數據,即13.1GB,Parquet/Snappy僅需要讀取10.6GB,但是Snappy解壓需要消耗時間,Parquet/None與Parquet/Snappy最終的查詢時間相差不大.

Impala擁有一個非常強大的自動緩存功能,對同一張表進行多次查詢時表現得更加明顯.Q1和Q6都是針對lineitem表的統計分析型語句,在運行完Q1語句后,Impala會將lineitem表的數據都緩存到內存中,再執行Q6語句.其執行時間大大減少,對文本文件的查詢從110.93 s降低到了12 s,對Parquet的查詢從14 s降低到3 s左右.

得益于Spark提供的強大接口和Shark在SQL處理上的積累,還處于測試版本的Spark SQL順利地完成了所有語句的執行,并且執行速度比Hive要快.但是Spark SQL使用過程中遇到了一些問題,例如默認使用的Broadcast Hash Join在執行部分Query時會返回大量的中間結果給Spark驅動,導致驅動(運行在Master節點上,分配內存20GB)由于內存不足而運行失敗,最后改用了Shuffle Hash Join的方式才解決問題.

2.5 Q21資源消耗情況

如圖4所示,Q21中的作業由3個子查詢組成,子查詢S1和S2是兩個對lineitem表中數據進行的聚集操作,S3是依次與lineitem、supplier、nation、orders、AGG1和AGG2進行關聯操作后進行的一次聚集操作后得到AGG3,再對AGG3進行一次排序.在實驗過程中,收集了3種引擎在運行Q21時集群CPU、內存、網絡、磁盤的使用情況,如圖5所示.可以發現Impala在完成查詢的同時對集群資源的占用是最少的,Hive其次,Spark SQL占用資源最多,特別是在內存占用方面和磁盤讀取上更為明顯.

圖4 Query 21Fig.4 Query 21

圖5 Q21集群資源消耗圖Fig.5 Cluster resource usage of Q21

Impala與Hive和Spark SQL的最大不同是它使用C/C++編寫,可以更加方便地在底層進行大量的優化；而Hive和Spark SQL均運行在JVM之上,相對來說對CPU和內存的控制并沒有Impala做得精細.如圖5a所示,Impala占用的CPU時間要明顯少于Hive和Spark SQL,這得益于Impala專門針對CPU層進行了大量的優化,Impala的查詢在每個節點上僅占用一個CPU線程,在相當低的CPU使用率下查詢結果與另外兩個引擎不相上下.而Hive和Spark SQL的運行環境為JVM,他們在CPU層的優化完全依賴于JVM,因此優化沒有Impala細致.圖5b中,Impala與Hive所占用的內存相差不大,而Spark SQL由于Spark的關系長時間占用了大量的內存空間,Spark并不像Map/Reduce那樣使用進程作為執行單元,而在占用資源較多的Executor Backend進程中使用線程來執行任務,因此實驗中為Executor Backend分配的50GB內存會在任務結束前被一直占用.

在磁盤使用方面,Impala和Hive比Spark SQL表現要好一些.S1和S2都是對lineitem表進行聚集操作,從圖5c對磁盤讀取速率來看,Spark SQL在執行S1和S2時分別從磁盤中讀取了一次lineitem表.Hive和Impala在執行S1的時候均從磁盤讀取了大量的數據,但是在S2執行的過程中,Impala對磁盤的使用率最低,而Hive對磁盤的讀操作要遠少于Spark SQL.出現這樣的情況是因為HDFS Datanode會使用操作系統緩存對已讀文件塊進行緩存,但是由于Spark在執行的過程中占用了大量的系統內存,留給Datanode可用的緩存空間并不多,因此Spark從Datanode的系統緩存中讀取的數據相對較少.

從圖5d對磁盤的寫入速率中可以發現,Impala在S1和S2執行結束后將結果寫入HDFS時,集群磁盤才有一個比較大的寫入,也就是說Impala在聚合操作的過程中僅有少量的數據重分布(shuffle),所有的中間結果都暫存在內存中,而Hive和Spark SQL在執行S1和S2的過程中有一些中間數據shuffle到磁盤中.

從圖5e所展示的網絡流量上看,Impala在執行S3的時候網絡I/O非常高.因為Impala采用了Broadcast Join的方式進行表連接操作,會將較小的表緩存到每個impalad的內存中,impalad在各自的聚集操作結束后將計算出的結果AGG3通過網絡傳輸給協調節點進行最后的排序,因此Impala在執行的過程中會出現一個較大的網絡流量.

2.6 結論

從實驗過程和結果中來看,3個查詢引擎都有各自的優點,現階段并不存在一個各方面都最優的查詢引擎.Impala是其中最快的一個,它的查詢速度比Hive要快1.5倍,運行較為穩定,但是Impala在查詢總大小超過內存大小的數據時還存在一些問題:在嘗試執行1TB數據規模的TPC-H測試語句時,Impala會因為內存不足導致查詢終止,即使啟用了中間結果緩存磁盤的功能,查詢也會在持續運行數小時后異常退出.而Hive運行十分穩定,對超大規模數據的查詢能得正確的結果,但是受到Map/Reduce啟動過慢等問題的影響,在本文實驗中性能是最弱的.Spark SQL目前還處于測試版本,雖然在實驗中性能比Hive要好,但是目前還不成熟,如果能在后續的版本中解決好穩定性以及資源占用過多的問題,將會成為一個非常優秀的查詢引擎.

結合本次實驗以及英特爾在Hadoop上的使用經驗來看,在構建基于Hadoop的數據倉庫系統時,推薦SQL引擎部分采用穩定的Hive搭配高性能的Impala或Spark SQL的混合架構.3個查詢引擎互相兼容,共享了同一個元數據庫,同時使用并不需要在不同的引擎中多次建表.在實際使用中,得益于Hadoop集群強大的計算和存儲能力,可以將原始數據的ETL(Extract Transform Load)工作中的轉換操作T轉移到Hadoop上交給Hive執行.在ETL完成后,對較大規模的原始數據的統計分析工作可以交給Hive完成,而在對經過統計分析后得到的小規模數據集進行查詢時可以使用速度更快的Impala或者Spark SQL,在對數據集緩存以后,絕大部分的查詢在秒級即可完成.

3 結束語

Hadoop是新一代數據倉庫的有力競爭者,基于Hadoop的多種SQL查詢引擎各有優勢,但從穩定性、易用性、兼容性和性能多個方面對比分析,目前并不存在各方面均最優的SQL引擎,因此推薦使用Hive+Impala或者Hive+Spark SQL的混合架構,規模較大的查詢和分析工作由Hive完成,小規模的數據集則可以使用速度更快的Impala或者Spark SQL.這種混合架構既得到了Hive的高穩定性和易用性的優點,還可以享受Impala和Spark SQL的高性能帶來的快速查詢.

[1] SHVACHKO K, KUANG H, RADIA S, et al. The hadoop distributed file system[C]//2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST). IEEE, 2010:1-10.

[2] THUSOO A, SARMA J S, JAIN N, et al. Hive: a warehousing solution over a map-reduce framework[J]. Proceedings of the VLDB Endowment, 2009, 2(2):1626-1629.

[3] THUSOO A, SARMA J S, JAIN N, et al. Hive-a petabyte scale data warehouse using hadoop[J]//2010 IEEE 26th International Conference on Data Engineering (ICDE). IEEE, 2010, 41(3):996-1005.

[4] 王 珊, 王會舉, 覃雄派, 等. 架構大數據: 挑戰, 現狀與展望[J]. 計算機學報, 2011, 34(10):1741-1752.

[5] DEAN J, GHEMAWAT S. MapReduce: simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1):107-113.

[6] FLORATOU A, MINHAS U F, OZCAN F. SQL-on-Hadoop: Full circle back to shared-nothing database architectures[J]. Proceedings of the VLDB Endowment, 2014, 7(12):1-12.

[7] CHANG L, WANG Z, MA T, et al. HAWQ: a massively parallel processing SQL engine in hadoop[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data. ACM, 2014:1223-1234

[8] ZAHARIA M, CHOWDHURY M, FRANKLIN M J, et al. Spark: cluster computing with working sets[J]. Book of Extremes, 2010, 15(1):1765-1773.

[9] ZAHARIA M, CHOWDHURY M, DAS T, et al. Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing[C]//Procegs of the 9th USENIX conference on Networked Systems Design and Implementation. USENIX Association, 2012:141-146.

[10] XIN R S, ROSEN J, ZAHARIA M, et al. Shark: SQL and rich analytics at scale[C]//Proceedings of the 2013 International Conference on Management of Data. ACM, 2013:13-24.

[11] BITTORF M K A B V, BOBROVYTSKY T, ERICKSON C C A C J, et al. Impala: A modern, open-source SQL engine for Hadoop[J]. The biennial Conference on Innovative Data Systems Research (CIDR), 2015:1-10.

[12] MELNIK S, GUBAREV A, LONG J J, et al. Dremel: interactive analysis of web-scale datasets[J]. Communications of the ACM, 2011, 54(6):114-123.

Research on SQL-on-Hadoop systems

WU Libing1, QIU Xin1,2, YE Luyao1, WANG Xiaodong2, NIE Lei1

(1.Computer School, Wuhan University, Wuhan 430072; 2.Intel Asia-Pacific R&D Center, Intel Corporation, Shanghai 201100)

Hadoop has huge advantage over traditional data warehouse and RDBMs on storing and processing large amount of data. In order to be compatible with existing business logic, SQL-on-Hadoop systems are getting more and more attentions from both industry and academia. There are variable kinds of SQL-on-Hadoop systems with different architectures and different execution engines. Those systems are generally divided into three categories: traditional engines based on Map/Reduce, newborn engines based on Spark, and MPP engines based on shared-nothing architecture. In this paper, three SQL-on-Hadoop systems, Hive, Spark SQL and Impala, are chosen to represent each category, respectively. A TPC-H like workload is used to benchmark the efficiency and resource usage for each system. Through detailed analysis of the experimental result, both Impala and Spark SQL are faster than Hive. In some particular queries, Impala is 10X faster than Hive with minimum CPU / RAM usage among the three SQL systems. However, when compared in terms of stability, usability, compatibility and performance, no one can beat others at all aspects. So while building the data warehouse system based on Hadoop, it is recommended to use a hybrid architecture using Hive+Impala or Hive+Spark SQL.

big data; SQL-on-Hadoop; data warehouse; Spark SQL; Impala; Hive

2015-09-06.

國家自然科學基金項目(61272112,61472287);湖北省自然科學基金重點項目(2015CFA068).

1000-1190(2016)02-0174-09

TP311

A

*E-mail: wu@whu.edu.cn.