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

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

?

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

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

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

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

大數(shù)據(jù); SQL-on-Hadoop; 數(shù)據(jù)倉庫; Spark SQL; Impala; Hive

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

搭建在廉價商用機(jī)器之上的Hadoop[1],在處理超大數(shù)據(jù)集的優(yōu)秀表現(xiàn)無疑是解決大數(shù)據(jù)問題的一大良方.其低成本、高性能、高可靠和高可擴(kuò)展的特性已經(jīng)逐漸得到業(yè)界的認(rèn)可,國內(nèi)外已有大量的應(yīng)用案例.

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

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

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

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

1 SQL-on-Hadoop系統(tǒng)

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

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

表1 Hive、Spark SQL、Impala對比

1.1 Hive

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

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

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

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

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

1.2 Spark SQL

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

圖1 Hadoop、Hive、Impala與Spark架構(gòu)圖Fig.1 Architecture of Hadoop, Hive, Impala and Spark

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

1.3 Impala

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

圖2 Catalyst執(zhí)行流程Fig.2 Catalyst Executing Process

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

2 實驗與分析

本文實驗采用了一套類TPC-H的測試基準(zhǔn),對Hive、Spark SQL、Impala的決策支持能力進(jìn)行測試.TPC-H測試基準(zhǔn)由英特爾和數(shù)家知名廠商共同制定,是一套評估數(shù)據(jù)倉庫決策支持能力的基準(zhǔn)程序(Benchmark),它由一系列模擬真實業(yè)務(wù)的ad-hoc查詢和并發(fā)數(shù)據(jù)修改語句組成,SQL語句和數(shù)據(jù)集的具體描述參見說明文檔(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無法執(zhí)行.

2.1 測試環(huán)境

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

圖3 集群拓?fù)鋱DFig.3 Cluster topology

2.2 數(shù)據(jù)及數(shù)據(jù)格式

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

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

表2 實驗數(shù)據(jù)集

2.3 統(tǒng)計信息

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

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

2.4 實驗結(jié)果

表3 查詢運行時間

實驗采用20個SQL依次運行的方式,執(zhí)行結(jié)果如表3所示.從總運行時間來看,Impala與Spark SQL的查詢速度與Hive相比都有較大的提高,Impala比Hive快了1.5倍,Spark SQL比Hive快了0.5倍.Impala有部分查詢的速度比Hive快了10倍甚至更多,如Q6、Q12和Q15.Spark SQL表現(xiàn)并沒有Impala出色,它是Spark在2014年9月發(fā)布的1.0.0版本中才推出的,在實驗中所用的Spark 1.1.0中還屬于測試組件,因此并不太穩(wěn)定.同時因為其對Parquet格式的查詢存在一些問題,并沒能得到正確的結(jié)果.Impala處理Parquet格式時的效率顯著提高,特別是針對Parquet的單表統(tǒng)計查詢,如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”的數(shù)據(jù)進(jìn)行了聚集操作,并根據(jù)L-RETURNFLAG和L-LINESTATUS兩個字段進(jìn)行排序.通過查看查詢運行時的詳細(xì)信息,對文本文件的查詢需要遍歷整個lineitem表的149.4GB數(shù)據(jù),對Parquet文件的查詢得益于Parquet列式存儲的優(yōu)勢,只需要讀取查詢中需要處理的列,因此大大降低了I/O成本.Impala僅讀取了Parquet/None格式20.12%的數(shù)據(jù),即13.1GB,Parquet/Snappy僅需要讀取10.6GB,但是Snappy解壓需要消耗時間,Parquet/None與Parquet/Snappy最終的查詢時間相差不大.

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

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

2.5 Q21資源消耗情況

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

圖4 Query 21Fig.4 Query 21

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

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

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

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

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

2.6 結(jié)論

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

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

3 結(jié)束語

Hadoop是新一代數(shù)據(jù)倉庫的有力競爭者,基于Hadoop的多種SQL查詢引擎各有優(yōu)勢,但從穩(wěn)定性、易用性、兼容性和性能多個方面對比分析,目前并不存在各方面均最優(yōu)的SQL引擎,因此推薦使用Hive+Impala或者Hive+Spark SQL的混合架構(gòu),規(guī)模較大的查詢和分析工作由Hive完成,小規(guī)模的數(shù)據(jù)集則可以使用速度更快的Impala或者Spark SQL.這種混合架構(gòu)既得到了Hive的高穩(wěn)定性和易用性的優(yōu)點,還可以享受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] 王 珊, 王會舉, 覃雄派, 等. 架構(gòu)大數(shù)據(jù): 挑戰(zhàn), 現(xiàn)狀與展望[J]. 計算機(jī)學(xué)報, 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.

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

1000-1190(2016)02-0174-09

TP311

A

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