, *,
(1.上海師范大學(xué) 信息與機電工程學(xué)院,上海 200234; 2.南京航空航天大學(xué) 計算機科學(xué)與技術(shù)學(xué)院,南京 211106)
基于Hive的性能優(yōu)化研究
王 康1,陳海光1*,李東靜2
(1.上海師范大學(xué) 信息與機電工程學(xué)院,上海200234;2.南京航空航天大學(xué) 計算機科學(xué)與技術(shù)學(xué)院,南京211106)
主要從MapReduce作業(yè)調(diào)度和Hive性能調(diào)優(yōu)兩個方面對Hive的性能優(yōu)化進行研究.對于MapReduce主要從編程模型切入,分析其執(zhí)行過程,并從map端、reduce端進行參數(shù)調(diào)優(yōu).接著從Hive框架角度入手,分別從分區(qū)表和外部表以及常用數(shù)據(jù)文件的壓縮、行式存儲與列式存儲等方面進行深入研究.實驗結(jié)果表明,snappy壓縮、orcfile/parquet存儲格式對于列式查詢,提高查詢效率,對于大數(shù)據(jù)分析平臺有較好的兼容性.
數(shù)據(jù)倉庫; 作業(yè)調(diào)優(yōu); 性能優(yōu)化; 壓縮; 存儲格式
在大數(shù)據(jù)背景下,數(shù)據(jù)倉庫的應(yīng)用主要分為即聯(lián)機分析處理(Online Analytical Processing,OLAP)和即聯(lián)機事務(wù)處理(Online Transaction Processing,OLTP)兩種.其中,OLAP類型主要是統(tǒng)計分析型查詢,如max、min等操作,讀取整行數(shù)據(jù)查詢的可能性比較小;OLTP類型主要是事務(wù)型的查詢,一般是完整讀一行數(shù)據(jù),IO開銷比較大;大數(shù)據(jù)背景下信息爆炸,使得分布式/并行計算變得非常重要.從單機應(yīng)用到集群應(yīng)用的過渡中,誕生了MapReduce這樣的分布式計算框架[1],簡化了并行程序的開發(fā),提供了水平擴展和容錯能力.在互聯(lián)網(wǎng)企業(yè)(如電商、游戲行業(yè))中,對于存儲和分析每天訂單日志數(shù)據(jù)的需求變得越來越迫切,因此由Facebook用于解決海量結(jié)構(gòu)化日志的數(shù)據(jù)統(tǒng)計開源數(shù)據(jù)倉庫Hive越來越受歡迎,從2010年下半年開始,Hive成為Apache頂級項目.
Hive是一個基于Hadoop的數(shù)據(jù)倉庫工具[2],通過Hive可以方便地進行數(shù)據(jù)提取轉(zhuǎn)化加載(ETL)的工作.Hive定義了一個類似于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存儲,主要存儲表名、表所屬的數(shù)據(jù)庫(默認(rèn)是default)、表的擁有者、列/分區(qū)字段、表的類型(是否是外部表)、表的數(shù)據(jù)所在目錄等.驅(qū)動器Driver主要包含解析器、編譯器、查詢優(yōu)化器、執(zhí)行器.其中,解析器SQL Parser將HQL字符串轉(zhuǎn)換成抽象語法樹AST,這一步一般通過第三方工具庫完成.比如antlr主要對AST進行語法分析,比如表、字段是否存在,SQL語義是否有誤(比如select中被判定為聚合的字段在group by中是否有出現(xiàn)).編譯器Compiler將AST編譯生成邏輯執(zhí)行計劃,查詢優(yōu)化器Query Optimizer對邏輯執(zhí)行計劃進行優(yōu)化,執(zhí)行器把邏輯執(zhí)行計劃轉(zhuǎn)換成可以運行的物理計劃,對于Hive來說,就是MapReduce.最后通過執(zhí)行這些MapReduce任務(wù)完成查詢?nèi)蝿?wù)和數(shù)據(jù)處理.
因此對Hive優(yōu)化來說,主要分為底層的MapReduce作業(yè)調(diào)優(yōu)[3-4]和Hive性能調(diào)優(yōu)兩大部分,將分別在第二節(jié)和第三節(jié)進行分析.
2.1MapReduce編程模型
MapReduce是一種分布式計算模型,主要解決海量數(shù)據(jù)的計算問題[5].MapReduce將整個并行計算過程抽象到兩個函數(shù)[6]:(1)map(映射).對一些獨立元素組成的列表的每一個元素進行指定的操作,可以高度并行;(2)reduce(化簡).對一個列表的元素進行合并.
MapReduce的總體執(zhí)行流程主要分為五個部分:input→map→shuffle→reduce→output,如圖2所示[7].map和reduce函數(shù)的輸入和輸出都是鍵/值對(K/V對).對于hadoop應(yīng)用開發(fā)人員需要實現(xiàn)的接口有:InputFormat、RecordReader、Mapper、Partitioner、Combiner、Reducer、OutputFormat.其中,InputFormat接口用于將輸入文件解析成邏輯上的輸入分片(InputSplit,其大小默認(rèn)是一個文件塊大小128 MB,數(shù)量決定map task的個數(shù)),并將它們分割成K/V對形式的記錄,默認(rèn)類型TextInputFormat;RecordReader接口從輸入分片讀取記錄并將其解析成K/V對,并交由map處理,一般使用默認(rèn)方式LineRecordReader即可;Mapper主要負(fù)責(zé)解析輸入的K/V對,并產(chǎn)生一些中間K/V對,通常遵循格式如map(k1,v1) →list(k2,v2),一般來說map函數(shù)的輸入K/V的類型(k1和v1)不同于輸出類型(k2和v2);Partitioner接口用以指定map task產(chǎn)生的K/V對交由哪個reduce task處理;Combiner接口完成map節(jié)點內(nèi)的規(guī)約,即進行map端的reduce操作,使得map的輸出更為緊湊,傳遞給reduce的數(shù)據(jù)更少;Reducer完成對多個map任務(wù)的輸出進行合并、排序,執(zhí)行reduce函數(shù)自己的邏輯,對輸入的K/V處理,轉(zhuǎn)換成新的K/V輸出,通常遵循格式如reduce(k2,list(v2))→list(k3,v3);reduce函數(shù)的輸入類型必須和map函數(shù)的輸入類型相同,輸出類型(k3和v3)可以不同于輸入類型;OutputFormat用于將reduce輸出的K/V對寫到類似于Hadoop分布式文件系統(tǒng)(HDFS)上[8-9].
圖2 MapReduce處理流程圖
但實際上,開發(fā)人員只需要完成Mapper和Reducer接口的設(shè)計.對于少數(shù)簡單的應(yīng)用,甚至連Reduce接口都不用實現(xiàn).這大大降低了并行編程的技術(shù)難度和工作量,其他并行編程中的種種復(fù)雜問題,如分布式存儲、工作調(diào)度、負(fù)載平衡、容錯處理、網(wǎng)絡(luò)通信等,均由YARN框架負(fù)責(zé)處理.從map輸出到reduce處理數(shù)據(jù)的中間的這個過程稱為shuffle[10],這個過程是MapReduce的核心,在接下來的兩小節(jié)圍繞這個過程展開進行優(yōu)化.
2.2map端調(diào)優(yōu)參數(shù)
2.2.1 mapreduce.task.io.sort.mb
當(dāng)map task開始運算,其產(chǎn)生的中間K/V對并非直接寫入磁盤,而是利用內(nèi)存buffer執(zhí)行緩存,并在內(nèi)存buffer中進行一些預(yù)排序優(yōu)化整個map的性能[11].如圖2所示,每一個map都會對應(yīng)存在一個內(nèi)存buffer(圖2中的buffer in memory),map會將已經(jīng)產(chǎn)生的部分結(jié)果先寫入到該buffer中,當(dāng)buffer達到一定閾值,會啟動一個后臺線程對buffer的內(nèi)容進行排序,然后寫入本地磁盤(spill文件).這個buffer默認(rèn)是100 MB大小,對于大規(guī)模集群可以將這個參數(shù)調(diào)大,用以減少磁盤I/O.
2.2.2 mapreduce.map.sort.spill.percent
這個參數(shù)值就是buffer的閾值,默認(rèn)是0.80,當(dāng)buffer中的數(shù)據(jù)達到這個閾值,后臺線程會對buffer中已有的數(shù)據(jù)進行排序,然后寫入磁盤.這個參數(shù)同樣也是影響spill執(zhí)行的頻繁程度,進而影響map task對磁盤I/O的頻率,但通常不需要人為調(diào)整,調(diào)整io.sort.mb參數(shù)對用戶來說更加方便.
2.2.3 mapreduce.task.io.sort.factor
當(dāng)map task的計算部分全部完成后,如果map有輸出,就會生成若干個spill文件,這些文件就是map的輸出結(jié)果.map在正常退出之前,需要將這些spill文件合并(merge)成一個文件.merge的過程中,執(zhí)行merge sort的時候,每次同時打開多少個spill文件由該參數(shù)決定,默認(rèn)值10.當(dāng)map的中間結(jié)果非常大,調(diào)大io.sort.factor有利于減少merge次數(shù),進而減少map對磁盤的讀寫頻率,達到優(yōu)化作業(yè)的目的.
2.2.4 mapreduce.map.output.compress和mapreduce.map.output.compress.codec
減少中間結(jié)果讀寫進出磁盤的方法還有壓縮.map的過程中,無論是spill的時候,還是最后的merge結(jié)果,文件都是可以壓縮的.壓縮的好處在于減少寫入讀出磁盤的數(shù)據(jù)量.如果對中間結(jié)果進行壓縮,需要將這2個參數(shù)分別設(shè)置為true(默認(rèn)值false不壓縮)及org.apache.hadoop.io.compress.DefaultCodec(默認(rèn)值),關(guān)于是否壓縮及壓縮方式的權(quán)衡在3.2節(jié)將進行詳細(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開始進行shuffle,從不同的已經(jīng)完成的map上下載屬于自己這個reduce的部分?jǐn)?shù)據(jù).由于map通常有許多個,所以對一個reduce來說,下載也可以是并行地從多個map下載,可以通過這個參數(shù)來調(diào)整并行度.如果一個時間段內(nèi)job完成的map有100個或者更多,那么reduce最多只能同時下載5個map的數(shù)據(jù).所以當(dāng)map很多并且完成得比較快的情況下調(diào)大該參數(shù),有利于reduce更快地獲取屬于自己的數(shù)據(jù),對于大集群可調(diào)整為15~20.
2.3.2 mapreduce.reduce.shuffle.input.buffer.percent
reduce在shuffle階段對下載的map數(shù)據(jù),并不立刻寫入磁盤,而是會先緩存在內(nèi)存中,然后當(dāng)內(nèi)存使用達到一定量的時候才刷入磁盤.這個參數(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)的緩存大小也會變大.
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é)果下載到本地時,也是需要進行merge的,所以這個參數(shù)的配置選項同樣會影響reduce進行merge時的行為,該參數(shù)的詳細(xì)介紹2.2節(jié)已提及.
2.3.5 mapreduce.reduce.input.buffer.percent
在reduce過程中,內(nèi)存中保存map輸出的空間占整個堆空間的比例.默認(rèn)值為0,在reduce任務(wù)開始之前,所有map輸出都被合并到磁盤上,以便reduce提供盡可能多的內(nèi)存.如果reduce計算需要的內(nèi)存比較小,可以增加此參數(shù)值來最小化訪問磁盤的空間,加速數(shù)據(jù)讀取速度.
2.4其他優(yōu)化技術(shù)
對于Hadoop 2.x版本的集群,可以將NameNode配置成基于QJM(Quorum Journal Manager)方式的高可用集群[3-4],來避免單點故障.此外,可以通過配置fs.trash.interval屬性(以min為單位的垃圾回收時間,默認(rèn)值0,垃圾回收機制關(guān)閉)來啟動垃圾回收機制,一般可以設(shè)置成10 080 min,即被刪除的文件在回收站中保留7 d.針對MapReduce小作業(yè),開啟uber模式(mapreduce.job.ubertask.enable,默認(rèn)值false,將其設(shè)置成true)使得該作業(yè)在一個Java虛擬機(JVM)中運行,省去啟動多個JVM的時間.
3.1分區(qū)表和外部表
和傳統(tǒng)的數(shù)據(jù)庫相比,Hive也是將數(shù)據(jù)存儲于表中,表的每一列都有一個相關(guān)的類型.分區(qū)表實際上就是對應(yīng)一個HDFS文件系統(tǒng)[8-9]上的獨立的文件夾,該文件夾下是該分區(qū)所有的數(shù)據(jù)文件.Hive中的分區(qū)就是分目錄,把一個大的數(shù)據(jù)集根據(jù)業(yè)務(wù)需要分割成更小的數(shù)據(jù)集.在查詢時通過where子句中的表達式來選擇查詢所需要的指定的分區(qū),這樣的查詢效率會提高很多.例如通過“select * from click_log where ds=′20151111′”語句選取查詢所需要的分區(qū)目錄,其中ds為分區(qū)的字段,這樣查詢時可以降低磁盤I/O、網(wǎng)絡(luò)I/O,提高查詢效率.
Hive中表主要分為內(nèi)部表和外部表兩種.內(nèi)部表也稱之為MANAGED_TABLE,默認(rèn)存儲在/user/hive/warehouse目錄下,也可以通過location指定,刪除表時會刪除表數(shù)據(jù)以及元數(shù)據(jù).外部表稱之為EXTERNAL_TABLE,在創(chuàng)建表時可以自己指定目錄位置,刪除表時只會刪除元數(shù)據(jù)不會刪除表數(shù)據(jù).
3.2數(shù)據(jù)文件的壓縮
數(shù)據(jù)壓縮其實就是對數(shù)據(jù)進行編碼的過程,它能夠減少存儲空間和網(wǎng)絡(luò)傳輸時間.數(shù)據(jù)壓縮類型主要分為2種:第一種是無損壓縮,壓縮過程中重復(fù)數(shù)據(jù)會被刪除,解壓的時候會被添加進來.常見的無損壓縮方法有Run Length Encoding、Lempel-Ziv-Welch Encoding、Huffman Encoding.無損壓縮不能忍受任何數(shù)據(jù)丟失,用于法律或醫(yī)學(xué)類文檔、計算機程序等重要類文檔;第二種是有損壓縮,常見的有損壓縮類型有圖片JPEG、音頻MP3、視頻MPEG.有損壓縮后的細(xì)微變化,無法用肉眼觀察.
數(shù)據(jù)壓縮的優(yōu)點是能夠提高I/O效率,節(jié)省存儲空間和提高網(wǎng)絡(luò)傳輸速度并減少網(wǎng)絡(luò)負(fù)載.缺點是CPU利用率和處理時間的增加.因此CPU處于空閑狀態(tài)可以考慮壓縮,如果集群CPU被MapReduce作業(yè)占滿,那么就不應(yīng)該考慮壓縮.
為了測試常用的bzip2、gzip、lzo、snappy等壓縮格式,對1.4 GB的純文本原始文件進行壓縮對比,測試環(huán)境機器配置為:內(nèi)存:8 GB,硬盤:1 TB,CPU:8core i7,網(wǎng)絡(luò):1個1 000 MB網(wǎng)卡,操作系統(tǒng):CentOS 6.4-64 bit.實驗結(jié)果如圖3、4所示.
圖3 不同壓縮格式壓縮比對比
圖4 不同壓縮格式壓縮解壓時間對比
從實驗結(jié)果可以得出,壓縮比排序為:bzip2>gzip>lzo>snappy,其中bzip2最節(jié)省存儲空間.解壓速度排序為:lzo>snappy>gzip>bzip2,其中l(wèi)zo解壓速度是最快的.歷史數(shù)據(jù)可以選用一些壓縮比高的壓縮方式,如bzip2,降低存儲空間.一些新的數(shù)據(jù)或熱點數(shù)據(jù)(即訪問量比較多的Hive表)可以采用解壓速度比較快的壓縮方式,如lzo、snappy等.因此,壓縮方式的權(quán)衡主要是存儲資源和計算資源之間的權(quán)衡,主要取決于CPU資源的繁忙程度.壓縮比高(如bzip2)在存儲、計算時占用資源比較多,解壓速度就比較慢.
3.3數(shù)據(jù)存儲格式
3.3.1 行式存儲
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ù)時,默認(rèn)的存儲格式是stored as textfile(純文本存儲),數(shù)據(jù)不做壓縮,磁盤開銷大.TextFile具有以下特點:(1)解析開銷大;(2)沒有schema(類似關(guān)系型數(shù)據(jù)庫中的列);(3)每個字段之間用分隔符分割;(4)不具備類型,所有的數(shù)據(jù)都是字符串類型.例如年齡age=10,將年齡當(dāng)做字符串來處理.
3.3.1.2 SequenceFile
圖5 SequenceFile文件格式結(jié)構(gòu)
SequenceFile格式是按照K/V對存儲,一行記錄Record一個K/V對,其本質(zhì)還是按行存儲.例如一個Record是10個字節(jié),K的長度是4(如“abcd”),那么在讀取V的時候,可以跳過前面的4個字節(jié)即可取得V值,即Record Length=KLength+VLength.此外,還可以對V進行壓縮,如圖5所示.
TextFile與SequenceFile區(qū)別主要有:(1)SequenceFile相比TextFile,冗余了長度記錄(如同樣的文件用TextFile格式存儲是100 MB,用SequenceFile格式存儲很可能變成120 MB);(2)SquenceFile可以進行壓縮(不對K做任何操作,只對V進行壓縮),而且是可以分割(并行計算)的.
3.3.2 列式存儲
對于5行3列的邏輯表,如圖6所示.當(dāng)只提取字段c時,行式存儲需要讀取的15個字段值,而列式存儲只需要讀取5個字段值,其讀取數(shù)據(jù)量是行式存儲的1/3.
圖6 列式存儲與行式存儲對比
3.3.2.1 Row Columnar File(rcfile)
鑒于行式存儲的缺點,FaceBook提出了一種rcfile列式存儲格式.rcfile優(yōu)點主要有:(1)保證row group為單位的塊中所有列存儲在一起,避免查詢時跨塊進行查詢;(2)每個row group是按列存儲的,減少HDFS讀取數(shù)據(jù)量(例如,一張表有100個列,查詢只需要3列,那么rcfile存儲格式查詢時可以跳過其中的97列,降低查詢的延時);(3)按列存儲,每列的數(shù)據(jù)類型相同,采用特定的壓縮方式進行壓縮.在Facebook內(nèi)部,rcfile只實現(xiàn)了部分功能,存儲空間僅僅能減少10%,查詢性能并沒有得到顯著的提高.
3.3.2.2 Optimized Row Columar File(ORCFile)
ORCFile是Hive、Shark、Spark支持的存儲格式,使用這種存儲格式存儲列數(shù)較多的表.使用ORCFile存儲格式,一個表由多個條帶(stripe)組成orcfile,一個stripe 256 MB.stripe主要分為:(1)按照列存儲數(shù)據(jù);(2)index data索引數(shù)據(jù),每列數(shù)據(jù)的存儲范圍(數(shù)值類型則存max、min等信息,string類型則存字符串的前綴、后綴等信息),默認(rèn)10 000行建立一個索引index.例如“select *** from xxx where age > 50”查詢語句,先到stripe的index data中尋找索引進行判斷.假設(shè)這張表有3個stripe([10,30],[31,50],[51,99]),那么直接跳過前兩個stripe到第3個stripe讀取數(shù)據(jù),提高了查詢效率.
ORCFile的優(yōu)點主要有:(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)勢是能3 s分析1 PB數(shù)據(jù).Parquet存儲結(jié)構(gòu)的主要亮點是支持嵌套數(shù)據(jù)結(jié)構(gòu)以及高效且種類豐富的算法,以應(yīng)對不同值分布特征的壓縮,支持的壓縮格式有uncompressed不壓縮、gzip、snappy等.
3.4實驗分析
圖7 實驗建表語句
實驗通過對原始數(shù)據(jù)為18.1 MB大小(textfile存儲格式)的網(wǎng)站訪問日志進行測試,導(dǎo)入到Hive表中,其中建表語句如圖7所示.
實驗的Hadoop(hadoop-2.5.0-cdh5.3.3)和Hive (hive-0.13.1-cdh5.3.3)集群是由3臺與單機配置相同的機器組成(測試環(huán)境機器配置如3.2節(jié)所述),通過命令“hadoop fs-du -h /user/hive/warehouse/page_ views_xxx”查看某個HDFS文件的大小.
3.4.1 ORCFile存儲格式與行式存儲對比
ORCFile相關(guān)聯(lián)的Hive表屬性配置如表1所示,與行式存儲對比結(jié)果如表2所示.
表1 ORCFile相關(guān)聯(lián)的Hive表屬性配置說明
表2 ORCFile存儲格式與行式存儲對比結(jié)果表
通過分析實驗結(jié)果,可以發(fā)現(xiàn)HDFS Read的字節(jié)數(shù)是19015214 B(18.1 MB),和原始的文件大小相同.當(dāng)采用SequenceFile格式后,相比原始的TextFile存儲格式存儲空間,大小明顯增大,采用列式存儲ORCFile格式后HDFS的寫入字節(jié)數(shù)明顯減少,大大減少了磁盤寫入的數(shù)據(jù)量.
表3 單列查詢結(jié)果對比
3.4.2 單列條件查詢對比
查詢語句采用行式存儲和列出存儲對比實驗,結(jié)果如表3所示.
通過分析實驗結(jié)果,可以得到行式存儲TextFile讀取了19015214 B,和原始文件大小相同,也就是全表讀取.而列式存儲ORCFile讀取的數(shù)據(jù)量明顯減少,只讀取session_id這一列,過濾了其他不必要的列,整個查詢語句對應(yīng)的MapReduce執(zhí)行時間明顯縮短,提高了查詢效率.
表4 Parquet不同壓縮格式存儲空間大小對比
3.4.3 Parquet不同壓縮格式對比
通過分析實驗結(jié)果(表4),可以得出對于原始數(shù)據(jù)18.1 MB大小的數(shù)據(jù),通過snappy壓縮之后大概可以壓縮至6.4 MB,gzip壓縮能壓縮至3.9 MB.gzip壓縮比高,解壓速度比較慢,snappy解壓速度比較快.
本文作者通過對MapReduce作業(yè)進行調(diào)優(yōu),主要圍繞其核心的shuffle過程進行參數(shù)優(yōu)化,總結(jié)了常用的重要參數(shù).此外分析了分區(qū)表、外部表的基本特性,采用常用壓縮、存儲格式角度入手,分析各自優(yōu)缺點.傳統(tǒng)的數(shù)據(jù)倉庫中大多數(shù)都是OLAP查詢,使用snappy壓縮、ORCfile/parquet列式存儲格式可以大大提高查詢性能,同時也可以兼容spark分布式計算框架.通過實驗驗證了壓縮、列式存儲格式在Hive列式查詢場景的優(yōu)勢.
[1] 懷特.Hadoop權(quán)威指南 [M].北京:清華大學(xué)出版社,2010.
White T.Hadoop:the definitive guide [M].Beijing:Tsinghua University Press,2010.
[2] 葉文宸.基于hive的性能優(yōu)化方法的研究與實踐 [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].計算機技術(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é)報,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實現(xià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)師簡介: 陳海光(1971-),男,副教授,主要從事數(shù)據(jù)挖掘、信息安全方面的研究.E-mail:chhg@shnu.edu.cn
TP301
:A
:1000-5137(2017)04-0527-08
*