, *,

(1.上海師范大學(xué) 信息與機(jī)電工程學(xué)院,上海 200234; 2.南京航空航天大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,南京 211106)

基于Hive的性能優(yōu)化研究

王 康1,陳海光1*,李東靜2

(1.上海師范大學(xué) 信息與機(jī)電工程學(xué)院,上海200234;2.南京航空航天大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,南京211106)

主要從MapReduce作業(yè)調(diào)度和Hive性能調(diào)優(yōu)兩個(gè)方面對(duì)Hive的性能優(yōu)化進(jìn)行研究.對(duì)于MapReduce主要從編程模型切入,分析其執(zhí)行過程,并從map端、reduce端進(jìn)行參數(shù)調(diào)優(yōu).接著從Hive框架角度入手,分別從分區(qū)表和外部表以及常用數(shù)據(jù)文件的壓縮、行式存儲(chǔ)與列式存儲(chǔ)等方面進(jìn)行深入研究.實(shí)驗(yàn)結(jié)果表明,snappy壓縮、orcfile/parquet存儲(chǔ)格式對(duì)于列式查詢,提高查詢效率,對(duì)于大數(shù)據(jù)分析平臺(tái)有較好的兼容性.

數(shù)據(jù)倉庫; 作業(yè)調(diào)優(yōu); 性能優(yōu)化; 壓縮; 存儲(chǔ)格式

在大數(shù)據(jù)背景下,數(shù)據(jù)倉庫的應(yīng)用主要分為即聯(lián)機(jī)分析處理(Online Analytical Processing,OLAP)和即聯(lián)機(jī)事務(wù)處理(Online Transaction Processing,OLTP)兩種.其中,OLAP類型主要是統(tǒng)計(jì)分析型查詢,如max、min等操作,讀取整行數(shù)據(jù)查詢的可能性比較小;OLTP類型主要是事務(wù)型的查詢,一般是完整讀一行數(shù)據(jù),IO開銷比較大;大數(shù)據(jù)背景下信息爆炸,使得分布式/并行計(jì)算變得非常重要.從單機(jī)應(yīng)用到集群應(yīng)用的過渡中,誕生了MapReduce這樣的分布式計(jì)算框架[1],簡(jiǎn)化了并行程序的開發(fā),提供了水平擴(kuò)展和容錯(cuò)能力.在互聯(lián)網(wǎng)企業(yè)(如電商、游戲行業(yè))中,對(duì)于存儲(chǔ)和分析每天訂單日志數(shù)據(jù)的需求變得越來越迫切,因此由Facebook用于解決海量結(jié)構(gòu)化日志的數(shù)據(jù)統(tǒng)計(jì)開源數(shù)據(jù)倉庫Hive越來越受歡迎,從2010年下半年開始,Hive成為Apache頂級(jí)項(xiàng)目.

1 Hive與MapReduce

Hive是一個(gè)基于Hadoop的數(shù)據(jù)倉庫工具[2],通過Hive可以方便地進(jìn)行數(shù)據(jù)提取轉(zhuǎn)化加載(ETL)的工作.Hive定義了一個(gè)類似于SQL的查詢語言HQL,能夠?qū)⒂脩艟帉懙腟QL轉(zhuǎn)化為相應(yīng)的MapReduce程序.

圖1 Hive架構(gòu)

Hive架構(gòu)如圖1所示.客戶端主要分為CLI(hive shell)、JDBC(java訪問hive)、WEBUI(瀏覽器訪問hive,如Hue)等方式.元數(shù)據(jù)通常采用MySQL存儲(chǔ),主要存儲(chǔ)表名、表所屬的數(shù)據(jù)庫(默認(rèn)是default)、表的擁有者、列/分區(qū)字段、表的類型(是否是外部表)、表的數(shù)據(jù)所在目錄等.驅(qū)動(dòng)器Driver主要包含解析器、編譯器、查詢優(yōu)化器、執(zhí)行器.其中,解析器SQL Parser將HQL字符串轉(zhuǎn)換成抽象語法樹AST,這一步一般通過第三方工具庫完成.比如antlr主要對(duì)AST進(jìn)行語法分析,比如表、字段是否存在,SQL語義是否有誤(比如select中被判定為聚合的字段在group by中是否有出現(xiàn)).編譯器Compiler將AST編譯生成邏輯執(zhí)行計(jì)劃,查詢優(yōu)化器Query Optimizer對(duì)邏輯執(zhí)行計(jì)劃進(jìn)行優(yōu)化,執(zhí)行器把邏輯執(zhí)行計(jì)劃轉(zhuǎn)換成可以運(yùn)行的物理計(jì)劃,對(duì)于Hive來說,就是MapReduce.最后通過執(zhí)行這些MapReduce任務(wù)完成查詢?nèi)蝿?wù)和數(shù)據(jù)處理.

因此對(duì)Hive優(yōu)化來說,主要分為底層的MapReduce作業(yè)調(diào)優(yōu)[3-4]和Hive性能調(diào)優(yōu)兩大部分,將分別在第二節(jié)和第三節(jié)進(jìn)行分析.

2 MapReduce作業(yè)調(diào)優(yōu)

2.1MapReduce編程模型

MapReduce是一種分布式計(jì)算模型,主要解決海量數(shù)據(jù)的計(jì)算問題[5].MapReduce將整個(gè)并行計(jì)算過程抽象到兩個(gè)函數(shù)[6]:(1)map(映射).對(duì)一些獨(dú)立元素組成的列表的每一個(gè)元素進(jìn)行指定的操作,可以高度并行;(2)reduce(化簡(jiǎn)).對(duì)一個(gè)列表的元素進(jìn)行合并.

MapReduce的總體執(zhí)行流程主要分為五個(gè)部分:input→map→shuffle→reduce→output,如圖2所示[7].map和reduce函數(shù)的輸入和輸出都是鍵/值對(duì)(K/V對(duì)).對(duì)于hadoop應(yīng)用開發(fā)人員需要實(shí)現(xiàn)的接口有:InputFormat、RecordReader、Mapper、Partitioner、Combiner、Reducer、OutputFormat.其中,InputFormat接口用于將輸入文件解析成邏輯上的輸入分片(InputSplit,其大小默認(rèn)是一個(gè)文件塊大小128 MB,數(shù)量決定map task的個(gè)數(shù)),并將它們分割成K/V對(duì)形式的記錄,默認(rèn)類型TextInputFormat;RecordReader接口從輸入分片讀取記錄并將其解析成K/V對(duì),并交由map處理,一般使用默認(rèn)方式LineRecordReader即可;Mapper主要負(fù)責(zé)解析輸入的K/V對(duì),并產(chǎn)生一些中間K/V對(duì),通常遵循格式如map(k1,v1) →list(k2,v2),一般來說map函數(shù)的輸入K/V的類型(k1和v1)不同于輸出類型(k2和v2);Partitioner接口用以指定map task產(chǎn)生的K/V對(duì)交由哪個(gè)reduce task處理;Combiner接口完成map節(jié)點(diǎn)內(nèi)的規(guī)約,即進(jìn)行map端的reduce操作,使得map的輸出更為緊湊,傳遞給reduce的數(shù)據(jù)更少;Reducer完成對(duì)多個(gè)map任務(wù)的輸出進(jìn)行合并、排序,執(zhí)行reduce函數(shù)自己的邏輯,對(duì)輸入的K/V處理,轉(zhuǎn)換成新的K/V輸出,通常遵循格式如reduce(k2,list(v2))→list(k3,v3);reduce函數(shù)的輸入類型必須和map函數(shù)的輸入類型相同,輸出類型(k3和v3)可以不同于輸入類型;OutputFormat用于將reduce輸出的K/V對(duì)寫到類似于Hadoop分布式文件系統(tǒng)(HDFS)上[8-9].

圖2 MapReduce處理流程圖

但實(shí)際上,開發(fā)人員只需要完成Mapper和Reducer接口的設(shè)計(jì).對(duì)于少數(shù)簡(jiǎn)單的應(yīng)用,甚至連Reduce接口都不用實(shí)現(xiàn).這大大降低了并行編程的技術(shù)難度和工作量,其他并行編程中的種種復(fù)雜問題,如分布式存儲(chǔ)、工作調(diào)度、負(fù)載平衡、容錯(cuò)處理、網(wǎng)絡(luò)通信等,均由YARN框架負(fù)責(zé)處理.從map輸出到reduce處理數(shù)據(jù)的中間的這個(gè)過程稱為shuffle[10],這個(gè)過程是MapReduce的核心,在接下來的兩小節(jié)圍繞這個(gè)過程展開進(jìn)行優(yōu)化.

2.2map端調(diào)優(yōu)參數(shù)

2.2.1 mapreduce.task.io.sort.mb

當(dāng)map task開始運(yùn)算,其產(chǎn)生的中間K/V對(duì)并非直接寫入磁盤,而是利用內(nèi)存buffer執(zhí)行緩存,并在內(nèi)存buffer中進(jìn)行一些預(yù)排序優(yōu)化整個(gè)map的性能[11].如圖2所示,每一個(gè)map都會(huì)對(duì)應(yīng)存在一個(gè)內(nèi)存buffer(圖2中的buffer in memory),map會(huì)將已經(jīng)產(chǎn)生的部分結(jié)果先寫入到該buffer中,當(dāng)buffer達(dá)到一定閾值,會(huì)啟動(dòng)一個(gè)后臺(tái)線程對(duì)buffer的內(nèi)容進(jìn)行排序,然后寫入本地磁盤(spill文件).這個(gè)buffer默認(rèn)是100 MB大小,對(duì)于大規(guī)模集群可以將這個(gè)參數(shù)調(diào)大,用以減少磁盤I/O.

2.2.2 mapreduce.map.sort.spill.percent

這個(gè)參數(shù)值就是buffer的閾值,默認(rèn)是0.80,當(dāng)buffer中的數(shù)據(jù)達(dá)到這個(gè)閾值,后臺(tái)線程會(huì)對(duì)buffer中已有的數(shù)據(jù)進(jìn)行排序,然后寫入磁盤.這個(gè)參數(shù)同樣也是影響spill執(zhí)行的頻繁程度,進(jìn)而影響map task對(duì)磁盤I/O的頻率,但通常不需要人為調(diào)整,調(diào)整io.sort.mb參數(shù)對(duì)用戶來說更加方便.

2.2.3 mapreduce.task.io.sort.factor

當(dāng)map task的計(jì)算部分全部完成后,如果map有輸出,就會(huì)生成若干個(gè)spill文件,這些文件就是map的輸出結(jié)果.map在正常退出之前,需要將這些spill文件合并(merge)成一個(gè)文件.merge的過程中,執(zhí)行merge sort的時(shí)候,每次同時(shí)打開多少個(gè)spill文件由該參數(shù)決定,默認(rèn)值10.當(dāng)map的中間結(jié)果非常大,調(diào)大io.sort.factor有利于減少merge次數(shù),進(jìn)而減少map對(duì)磁盤的讀寫頻率,達(dá)到優(yōu)化作業(yè)的目的.

2.2.4 mapreduce.map.output.compress和mapreduce.map.output.compress.codec

減少中間結(jié)果讀寫進(jìn)出磁盤的方法還有壓縮.map的過程中,無論是spill的時(shí)候,還是最后的merge結(jié)果,文件都是可以壓縮的.壓縮的好處在于減少寫入讀出磁盤的數(shù)據(jù)量.如果對(duì)中間結(jié)果進(jìn)行壓縮,需要將這2個(gè)參數(shù)分別設(shè)置為true(默認(rèn)值false不壓縮)及org.apache.hadoop.io.compress.DefaultCodec(默認(rèn)值),關(guān)于是否壓縮及壓縮方式的權(quán)衡在3.2節(jié)將進(jìn)行詳細(xì)介紹.

2.3reduce端調(diào)優(yōu)參數(shù)

2.3.1 mapreduce.reduce.shuffle.parallelcopies

當(dāng)job(mapreduce.job.reduce.slowstart.completedmaps參數(shù)控制)已完成5%的map tasks數(shù)量之后reduce開始進(jìn)行shuffle,從不同的已經(jīng)完成的map上下載屬于自己這個(gè)reduce的部分?jǐn)?shù)據(jù).由于map通常有許多個(gè),所以對(duì)一個(gè)reduce來說,下載也可以是并行地從多個(gè)map下載,可以通過這個(gè)參數(shù)來調(diào)整并行度.如果一個(gè)時(shí)間段內(nèi)job完成的map有100個(gè)或者更多,那么reduce最多只能同時(shí)下載5個(gè)map的數(shù)據(jù).所以當(dāng)map很多并且完成得比較快的情況下調(diào)大該參數(shù),有利于reduce更快地獲取屬于自己的數(shù)據(jù),對(duì)于大集群可調(diào)整為15～20.

2.3.2 mapreduce.reduce.shuffle.input.buffer.percent

reduce在shuffle階段對(duì)下載的map數(shù)據(jù),并不立刻寫入磁盤,而是會(huì)先緩存在內(nèi)存中,然后當(dāng)內(nèi)存使用達(dá)到一定量的時(shí)候才刷入磁盤.這個(gè)參數(shù)(默認(rèn)值0.7)是shuffle在reduce內(nèi)存中的數(shù)據(jù)最多使用內(nèi)存量為:0.7×reduce task的最大heap使用量(通常通過mapred.child.java.opts來設(shè)置).如果reduce的heap由于業(yè)務(wù)原因調(diào)整得比較大,相應(yīng)的緩存大小也會(huì)變大.

2.3.3 mapreduce.reduce.shuffle.merge.percent

假設(shè)reduce task最大內(nèi)存使用量為1 GB(-Xmx1024m),2.3.2節(jié)參數(shù)為0.7,則約700 MB內(nèi)存用來緩存從map端copy過來的數(shù)據(jù).而這700 MB的緩存數(shù)據(jù),需要寫入磁盤完成spill操作.與map端相似,內(nèi)存使用到定義百分比程度就開始往磁盤寫,默認(rèn)值是0.66.調(diào)整此參數(shù)的目的是避免下載速度過快造成reduce端緩存來不及釋放的問題.

2.3.4 mapreduce.task.io.sort.factor

reduce將map結(jié)果下載到本地時(shí),也是需要進(jìn)行merge的,所以這個(gè)參數(shù)的配置選項(xiàng)同樣會(huì)影響reduce進(jìn)行merge時(shí)的行為,該參數(shù)的詳細(xì)介紹2.2節(jié)已提及.

2.3.5 mapreduce.reduce.input.buffer.percent

在reduce過程中,內(nèi)存中保存map輸出的空間占整個(gè)堆空間的比例.默認(rèn)值為0,在reduce任務(wù)開始之前,所有map輸出都被合并到磁盤上,以便reduce提供盡可能多的內(nèi)存.如果reduce計(jì)算需要的內(nèi)存比較小,可以增加此參數(shù)值來最小化訪問磁盤的空間,加速數(shù)據(jù)讀取速度.

2.4其他優(yōu)化技術(shù)

對(duì)于Hadoop 2.x版本的集群,可以將NameNode配置成基于QJM(Quorum Journal Manager)方式的高可用集群[3-4],來避免單點(diǎn)故障.此外,可以通過配置fs.trash.interval屬性(以min為單位的垃圾回收時(shí)間,默認(rèn)值0,垃圾回收機(jī)制關(guān)閉)來啟動(dòng)垃圾回收機(jī)制,一般可以設(shè)置成10 080 min,即被刪除的文件在回收站中保留7 d.針對(duì)MapReduce小作業(yè),開啟uber模式(mapreduce.job.ubertask.enable,默認(rèn)值false,將其設(shè)置成true)使得該作業(yè)在一個(gè)Java虛擬機(jī)(JVM)中運(yùn)行,省去啟動(dòng)多個(gè)JVM的時(shí)間.

3 Hive性能調(diào)優(yōu)

3.1分區(qū)表和外部表

和傳統(tǒng)的數(shù)據(jù)庫相比,Hive也是將數(shù)據(jù)存儲(chǔ)于表中,表的每一列都有一個(gè)相關(guān)的類型.分區(qū)表實(shí)際上就是對(duì)應(yīng)一個(gè)HDFS文件系統(tǒng)[8-9]上的獨(dú)立的文件夾,該文件夾下是該分區(qū)所有的數(shù)據(jù)文件.Hive中的分區(qū)就是分目錄,把一個(gè)大的數(shù)據(jù)集根據(jù)業(yè)務(wù)需要分割成更小的數(shù)據(jù)集.在查詢時(shí)通過where子句中的表達(dá)式來選擇查詢所需要的指定的分區(qū),這樣的查詢效率會(huì)提高很多.例如通過“select * from click_log where ds=′20151111′”語句選取查詢所需要的分區(qū)目錄,其中ds為分區(qū)的字段,這樣查詢時(shí)可以降低磁盤I/O、網(wǎng)絡(luò)I/O,提高查詢效率.

Hive中表主要分為內(nèi)部表和外部表兩種.內(nèi)部表也稱之為MANAGED_TABLE,默認(rèn)存儲(chǔ)在/user/hive/warehouse目錄下,也可以通過location指定,刪除表時(shí)會(huì)刪除表數(shù)據(jù)以及元數(shù)據(jù).外部表稱之為EXTERNAL_TABLE,在創(chuàng)建表時(shí)可以自己指定目錄位置,刪除表時(shí)只會(huì)刪除元數(shù)據(jù)不會(huì)刪除表數(shù)據(jù).

3.2數(shù)據(jù)文件的壓縮

數(shù)據(jù)壓縮其實(shí)就是對(duì)數(shù)據(jù)進(jìn)行編碼的過程,它能夠減少存儲(chǔ)空間和網(wǎng)絡(luò)傳輸時(shí)間.數(shù)據(jù)壓縮類型主要分為2種:第一種是無損壓縮,壓縮過程中重復(fù)數(shù)據(jù)會(huì)被刪除,解壓的時(shí)候會(huì)被添加進(jìn)來.常見的無損壓縮方法有Run Length Encoding、Lempel-Ziv-Welch Encoding、Huffman Encoding.無損壓縮不能忍受任何數(shù)據(jù)丟失,用于法律或醫(yī)學(xué)類文檔、計(jì)算機(jī)程序等重要類文檔;第二種是有損壓縮,常見的有損壓縮類型有圖片JPEG、音頻MP3、視頻MPEG.有損壓縮后的細(xì)微變化,無法用肉眼觀察.

數(shù)據(jù)壓縮的優(yōu)點(diǎn)是能夠提高I/O效率,節(jié)省存儲(chǔ)空間和提高網(wǎng)絡(luò)傳輸速度并減少網(wǎng)絡(luò)負(fù)載.缺點(diǎn)是CPU利用率和處理時(shí)間的增加.因此CPU處于空閑狀態(tài)可以考慮壓縮,如果集群CPU被MapReduce作業(yè)占滿,那么就不應(yīng)該考慮壓縮.

為了測(cè)試常用的bzip2、gzip、lzo、snappy等壓縮格式,對(duì)1.4 GB的純文本原始文件進(jìn)行壓縮對(duì)比,測(cè)試環(huán)境機(jī)器配置為:內(nèi)存:8 GB,硬盤:1 TB,CPU:8core i7,網(wǎng)絡(luò):1個(gè)1 000 MB網(wǎng)卡,操作系統(tǒng):CentOS 6.4-64 bit.實(shí)驗(yàn)結(jié)果如圖3、4所示.

圖3 不同壓縮格式壓縮比對(duì)比

圖4 不同壓縮格式壓縮解壓時(shí)間對(duì)比

從實(shí)驗(yàn)結(jié)果可以得出,壓縮比排序?yàn)?bzip2>gzip>lzo>snappy,其中bzip2最節(jié)省存儲(chǔ)空間.解壓速度排序?yàn)?lzo>snappy>gzip>bzip2,其中l(wèi)zo解壓速度是最快的.歷史數(shù)據(jù)可以選用一些壓縮比高的壓縮方式,如bzip2,降低存儲(chǔ)空間.一些新的數(shù)據(jù)或熱點(diǎn)數(shù)據(jù)(即訪問量比較多的Hive表)可以采用解壓速度比較快的壓縮方式,如lzo、snappy等.因此,壓縮方式的權(quán)衡主要是存儲(chǔ)資源和計(jì)算資源之間的權(quán)衡,主要取決于CPU資源的繁忙程度.壓縮比高(如bzip2)在存儲(chǔ)、計(jì)算時(shí)占用資源比較多,解壓速度就比較慢.

3.3數(shù)據(jù)存儲(chǔ)格式

3.3.1 行式存儲(chǔ)

3.3.1.1 TextFile

當(dāng)通過“create table mylog(user_id bigint,page_url string,unix_time int)stored as textfile;load data inpath ′/user/myname/log.txt′ into table mylog;”兩條HQL語句創(chuàng)建Hive表并從HDFS上加載數(shù)據(jù)時(shí),默認(rèn)的存儲(chǔ)格式是stored as textfile(純文本存儲(chǔ)),數(shù)據(jù)不做壓縮,磁盤開銷大.TextFile具有以下特點(diǎn):(1)解析開銷大;(2)沒有schema(類似關(guān)系型數(shù)據(jù)庫中的列);(3)每個(gè)字段之間用分隔符分割;(4)不具備類型,所有的數(shù)據(jù)都是字符串類型.例如年齡age=10,將年齡當(dāng)做字符串來處理.

3.3.1.2 SequenceFile

圖5 SequenceFile文件格式結(jié)構(gòu)

SequenceFile格式是按照K/V對(duì)存儲(chǔ),一行記錄Record一個(gè)K/V對(duì),其本質(zhì)還是按行存儲(chǔ).例如一個(gè)Record是10個(gè)字節(jié),K的長(zhǎng)度是4(如“abcd”),那么在讀取V的時(shí)候,可以跳過前面的4個(gè)字節(jié)即可取得V值,即Record Length=KLength+VLength.此外,還可以對(duì)V進(jìn)行壓縮,如圖5所示.

TextFile與SequenceFile區(qū)別主要有:(1)SequenceFile相比TextFile,冗余了長(zhǎng)度記錄(如同樣的文件用TextFile格式存儲(chǔ)是100 MB,用SequenceFile格式存儲(chǔ)很可能變成120 MB);(2)SquenceFile可以進(jìn)行壓縮(不對(duì)K做任何操作,只對(duì)V進(jìn)行壓縮),而且是可以分割(并行計(jì)算)的.

3.3.2 列式存儲(chǔ)

對(duì)于5行3列的邏輯表,如圖6所示.當(dāng)只提取字段c時(shí),行式存儲(chǔ)需要讀取的15個(gè)字段值,而列式存儲(chǔ)只需要讀取5個(gè)字段值,其讀取數(shù)據(jù)量是行式存儲(chǔ)的1/3.

圖6 列式存儲(chǔ)與行式存儲(chǔ)對(duì)比

3.3.2.1 Row Columnar File(rcfile)

鑒于行式存儲(chǔ)的缺點(diǎn),FaceBook提出了一種rcfile列式存儲(chǔ)格式.rcfile優(yōu)點(diǎn)主要有:(1)保證row group為單位的塊中所有列存儲(chǔ)在一起,避免查詢時(shí)跨塊進(jìn)行查詢;(2)每個(gè)row group是按列存儲(chǔ)的,減少HDFS讀取數(shù)據(jù)量(例如,一張表有100個(gè)列,查詢只需要3列,那么rcfile存儲(chǔ)格式查詢時(shí)可以跳過其中的97列,降低查詢的延時(shí));(3)按列存儲(chǔ),每列的數(shù)據(jù)類型相同,采用特定的壓縮方式進(jìn)行壓縮.在Facebook內(nèi)部,rcfile只實(shí)現(xiàn)了部分功能,存儲(chǔ)空間僅僅能減少10%,查詢性能并沒有得到顯著的提高.

3.3.2.2 Optimized Row Columar File(ORCFile)

ORCFile是Hive、Shark、Spark支持的存儲(chǔ)格式,使用這種存儲(chǔ)格式存儲(chǔ)列數(shù)較多的表.使用ORCFile存儲(chǔ)格式,一個(gè)表由多個(gè)條帶(stripe)組成orcfile,一個(gè)stripe 256 MB.stripe主要分為:(1)按照列存儲(chǔ)數(shù)據(jù);(2)index data索引數(shù)據(jù),每列數(shù)據(jù)的存儲(chǔ)范圍(數(shù)值類型則存max、min等信息,string類型則存字符串的前綴、后綴等信息),默認(rèn)10 000行建立一個(gè)索引index.例如“select *** from xxx where age > 50”查詢語句,先到stripe的index data中尋找索引進(jìn)行判斷.假設(shè)這張表有3個(gè)stripe([10,30],[31,50],[51,99]),那么直接跳過前兩個(gè)stripe到第3個(gè)stripe讀取數(shù)據(jù),提高了查詢效率.

ORCFile的優(yōu)點(diǎn)主要有:(1)每一列的數(shù)據(jù)類型分布采用相應(yīng)的壓縮算法(數(shù)值類型采用Run-Length Encoding,String類型采用Dictionary Encoding),壓縮性能能得到很大提高;(2)數(shù)值類型或字符串類型建立相應(yīng)的索引,使查詢效率提高.

3.3.2.3 Parquet

Parquet等開源框架比較復(fù)雜,其靈感主要來自于Google公開的Dremel論文,其優(yōu)勢(shì)是能3 s分析1 PB數(shù)據(jù).Parquet存儲(chǔ)結(jié)構(gòu)的主要亮點(diǎn)是支持嵌套數(shù)據(jù)結(jié)構(gòu)以及高效且種類豐富的算法,以應(yīng)對(duì)不同值分布特征的壓縮,支持的壓縮格式有uncompressed不壓縮、gzip、snappy等.

3.4實(shí)驗(yàn)分析

圖7 實(shí)驗(yàn)建表語句

實(shí)驗(yàn)通過對(duì)原始數(shù)據(jù)為18.1 MB大小(textfile存儲(chǔ)格式)的網(wǎng)站訪問日志進(jìn)行測(cè)試,導(dǎo)入到Hive表中,其中建表語句如圖7所示.

實(shí)驗(yàn)的Hadoop(hadoop-2.5.0-cdh5.3.3)和Hive (hive-0.13.1-cdh5.3.3)集群是由3臺(tái)與單機(jī)配置相同的機(jī)器組成(測(cè)試環(huán)境機(jī)器配置如3.2節(jié)所述),通過命令“hadoop fs-du -h /user/hive/warehouse/page_ views_xxx”查看某個(gè)HDFS文件的大小.

3.4.1 ORCFile存儲(chǔ)格式與行式存儲(chǔ)對(duì)比

ORCFile相關(guān)聯(lián)的Hive表屬性配置如表1所示,與行式存儲(chǔ)對(duì)比結(jié)果如表2所示.

表1 ORCFile相關(guān)聯(lián)的Hive表屬性配置說明

表2 ORCFile存儲(chǔ)格式與行式存儲(chǔ)對(duì)比結(jié)果表

通過分析實(shí)驗(yàn)結(jié)果,可以發(fā)現(xiàn)HDFS Read的字節(jié)數(shù)是19015214 B(18.1 MB),和原始的文件大小相同.當(dāng)采用SequenceFile格式后,相比原始的TextFile存儲(chǔ)格式存儲(chǔ)空間,大小明顯增大,采用列式存儲(chǔ)ORCFile格式后HDFS的寫入字節(jié)數(shù)明顯減少,大大減少了磁盤寫入的數(shù)據(jù)量.

表3 單列查詢結(jié)果對(duì)比

3.4.2 單列條件查詢對(duì)比

查詢語句采用行式存儲(chǔ)和列出存儲(chǔ)對(duì)比實(shí)驗(yàn),結(jié)果如表3所示.

通過分析實(shí)驗(yàn)結(jié)果,可以得到行式存儲(chǔ)TextFile讀取了19015214 B,和原始文件大小相同,也就是全表讀取.而列式存儲(chǔ)ORCFile讀取的數(shù)據(jù)量明顯減少,只讀取session_id這一列,過濾了其他不必要的列,整個(gè)查詢語句對(duì)應(yīng)的MapReduce執(zhí)行時(shí)間明顯縮短,提高了查詢效率.

表4 Parquet不同壓縮格式存儲(chǔ)空間大小對(duì)比

3.4.3 Parquet不同壓縮格式對(duì)比

通過分析實(shí)驗(yàn)結(jié)果(表4),可以得出對(duì)于原始數(shù)據(jù)18.1 MB大小的數(shù)據(jù),通過snappy壓縮之后大概可以壓縮至6.4 MB,gzip壓縮能壓縮至3.9 MB.gzip壓縮比高,解壓速度比較慢,snappy解壓速度比較快.

4 結(jié)束語

本文作者通過對(duì)MapReduce作業(yè)進(jìn)行調(diào)優(yōu),主要圍繞其核心的shuffle過程進(jìn)行參數(shù)優(yōu)化,總結(jié)了常用的重要參數(shù).此外分析了分區(qū)表、外部表的基本特性,采用常用壓縮、存儲(chǔ)格式角度入手,分析各自優(yōu)缺點(diǎn).傳統(tǒng)的數(shù)據(jù)倉庫中大多數(shù)都是OLAP查詢,使用snappy壓縮、ORCfile/parquet列式存儲(chǔ)格式可以大大提高查詢性能,同時(shí)也可以兼容spark分布式計(jì)算框架.通過實(shí)驗(yàn)驗(yàn)證了壓縮、列式存儲(chǔ)格式在Hive列式查詢場(chǎng)景的優(yōu)勢(shì).

[1] 懷特.Hadoop權(quán)威指南 [M].北京:清華大學(xué)出版社,2010.

White T.Hadoop:the definitive guide [M].Beijing:Tsinghua University Press,2010.

[2] 葉文宸.基于hive的性能優(yōu)化方法的研究與實(shí)踐 [D].南京:南京大學(xué),2011.

Ye W C.The research and practice of performance optimization based on Hive [D].Nanjing:Nanjing University,2011.

[3] Babu S.Towards automatic optimization of MapReduce programs [C].Proceedings of the 1st ACM symposium on Cloud computing,Indianapolis:ACM,2010.

[4] Jiang D,Ooi B C,Shi L,et al.Theperformance of MapReduce:an in-depth study [J].Proceedings of the Vldb Endowment,2010,3(1-2):472-483.

[5] 高莉莎,劉正濤,應(yīng)毅.基于應(yīng)用程序的MapReduce性能優(yōu)化 [J].計(jì)算機(jī)技術(shù)與發(fā)展,2015,25(7):96-99.

Gao L S,Liu Z T,Ying Y.Performance optimization of MapReduce based on applications [J].Computer Technology and Development,2015,25(7):96-99.

[6] Yang H C,Dasdan A,Hsiao R L,et al.Map-reduce-merge:simplified relational data processing on large clusters [C].Proceedings of the 2007 ACM SIGMOD international conference on Management of data,Beijing:ACM,2007.

[7] 李建江,崔健,王聃,等.MapReduce并行編程模型研究綜述 [J].電子學(xué)報(bào),2011,39(11):2635-2642.

Li L J,Cui J,Wang D,et al.Survey of MapReduce parallel programming model [J].Acta Electronica Sinica,2011,39(11):2635-2642.

[8] Ghemawat S,Gobioff H,Leung S T.The Google file system [C].Acm Sigops Operating Systems Review,2003,37 (5):29-43.

[9] Shvachko K,Kuang H,Radia S,et al.TheHadoop distributed file system [C].Mass Storage Systems and Technologies (MSST) 2010 IEEE 26th Symposium on,Incline Village:IEEE,2010.

[10] Seo S,Jang I,Woo K,et al.HPMR:Prefetching and pre-shuffling in shared MapReduce computation environment [C].2013 IEEE International Conference on Cluster Computing,New Orleans:IEEE,2009.

[11] 張密密.MapReduce模型在Hadoop實(shí)現(xiàn)中的性能分析及改進(jìn)優(yōu)化 [D].成都:電子科技大學(xué),2010.

Zhang M M.Performance analysis and improvement optimization of MapReduce model in Hadoop implementation [D].Chengdu:University of Electronic Science and Technology of China,2010.

(責(zé)任編輯：包震宇)

PerformanceoptimizationresearchbasedonHive

Wang Kang1,ChenHaiguang1*,LiDongjing2

(1.The College of Information,Mechanical and Electrical Engineering,Shanghai Normal University,Shanghai200234,China;2.College of Computer Science and Technology,Nanjing University of Aeronautics and Astronautics,Nanjing211106,China)

This paper research Hive performance optimization mainly from the two aspects of MapReduce scheduling and Hive performance tuning.MapReduce′s programming model and its implementation process is analyzed,and parameters are tuned from the map side and reduce side.Then Hive′s framework is researched from the aspects of the partition table,the external surface and common data file compression,the line storage and column type storage.The experimental results show that snappy compression and orcfile/parquet storage format can improve the efficiency of query for the column type queries, and has good compatibility.

data warehouse; job optimization; performance optimization; compression; storage format

2015-12-10

王 康(1988-),男,碩士研究生,主要從事數(shù)據(jù)挖掘方面的研究.E-mail:525262800@qq.com

導(dǎo)師簡(jiǎn)介: 陳海光(1971-),男,副教授,主要從事數(shù)據(jù)挖掘、信息安全方面的研究.E-mail:chhg@shnu.edu.cn

TP301

:A

:1000-5137(2017)04-0527-08

*