亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

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

        2017-09-18 13:00:12,*,
        關鍵詞:優(yōu)化

        , *,

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

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

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

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

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

        數據倉庫; 作業(yè)調優(yōu); 性能優(yōu)化; 壓縮; 存儲格式

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

        1 Hive與MapReduce

        Hive是一個基于Hadoop的數據倉庫工具[2],通過Hive可以方便地進行數據提取轉化加載(ETL)的工作.Hive定義了一個類似于SQL的查詢語言HQL,能夠將用戶編寫的SQL轉化為相應的MapReduce程序.

        圖1 Hive架構

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

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

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

        2.1MapReduce編程模型

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

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

        圖2 MapReduce處理流程圖

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

        2.2map端調優(yōu)參數

        2.2.1 mapreduce.task.io.sort.mb

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

        2.2.2 mapreduce.map.sort.spill.percent

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

        2.2.3 mapreduce.task.io.sort.factor

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

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

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

        2.3reduce端調優(yōu)參數

        2.3.1 mapreduce.reduce.shuffle.parallelcopies

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

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

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

        2.3.3 mapreduce.reduce.shuffle.merge.percent

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

        2.3.4 mapreduce.task.io.sort.factor

        reduce將map結果下載到本地時,也是需要進行merge的,所以這個參數的配置選項同樣會影響reduce進行merge時的行為,該參數的詳細介紹2.2節(jié)已提及.

        2.3.5 mapreduce.reduce.input.buffer.percent

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

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

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

        3 Hive性能調優(yōu)

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

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

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

        3.2數據文件的壓縮

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

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

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

        圖3 不同壓縮格式壓縮比對比

        圖4 不同壓縮格式壓縮解壓時間對比

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

        3.3數據存儲格式

        3.3.1 行式存儲

        3.3.1.1 TextFile

        當通過“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上加載數據時,默認的存儲格式是stored as textfile(純文本存儲),數據不做壓縮,磁盤開銷大.TextFile具有以下特點:(1)解析開銷大;(2)沒有schema(類似關系型數據庫中的列);(3)每個字段之間用分隔符分割;(4)不具備類型,所有的數據都是字符串類型.例如年齡age=10,將年齡當做字符串來處理.

        3.3.1.2 SequenceFile

        圖5 SequenceFile文件格式結構

        SequenceFile格式是按照K/V對存儲,一行記錄Record一個K/V對,其本質還是按行存儲.例如一個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所示.當只提取字段c時,行式存儲需要讀取的15個字段值,而列式存儲只需要讀取5個字段值,其讀取數據量是行式存儲的1/3.

        圖6 列式存儲與行式存儲對比

        3.3.2.1 Row Columnar File(rcfile)

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

        3.3.2.2 Optimized Row Columar File(ORCFile)

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

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

        3.3.2.3 Parquet

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

        3.4實驗分析

        圖7 實驗建表語句

        實驗通過對原始數據為18.1 MB大小(textfile存儲格式)的網站訪問日志進行測試,導入到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相關聯的Hive表屬性配置如表1所示,與行式存儲對比結果如表2所示.

        表1 ORCFile相關聯的Hive表屬性配置說明

        表2 ORCFile存儲格式與行式存儲對比結果表

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

        表3 單列查詢結果對比

        3.4.2 單列條件查詢對比

        查詢語句采用行式存儲和列出存儲對比實驗,結果如表3所示.

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

        表4 Parquet不同壓縮格式存儲空間大小對比

        3.4.3 Parquet不同壓縮格式對比

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

        4 結束語

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

        [1] 懷特.Hadoop權威指南 [M].北京:清華大學出版社,2010.

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

        [2] 葉文宸.基于hive的性能優(yōu)化方法的研究與實踐 [D].南京:南京大學,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] 高莉莎,劉正濤,應毅.基于應用程序的MapReduce性能優(yōu)化 [J].計算機技術與發(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].電子學報,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實現中的性能分析及改進優(yōu)化 [D].成都:電子科技大學,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.

        (責任編輯:包震宇)

        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-),男,碩士研究生,主要從事數據挖掘方面的研究.E-mail:525262800@qq.com

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

        TP301

        :A

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

        *

        猜你喜歡
        優(yōu)化
        超限高層建筑結構設計與優(yōu)化思考
        房地產導刊(2022年5期)2022-06-01 06:20:14
        PEMFC流道的多目標優(yōu)化
        能源工程(2022年1期)2022-03-29 01:06:28
        民用建筑防煙排煙設計優(yōu)化探討
        關于優(yōu)化消防安全告知承諾的一些思考
        一道優(yōu)化題的幾何解法
        由“形”啟“數”優(yōu)化運算——以2021年解析幾何高考題為例
        圍繞“地、業(yè)、人”優(yōu)化產業(yè)扶貧
        事業(yè)單位中固定資產會計處理的優(yōu)化
        消費導刊(2018年8期)2018-05-25 13:20:08
        4K HDR性能大幅度優(yōu)化 JVC DLA-X8 18 BC
        幾種常見的負載均衡算法的優(yōu)化
        電子制作(2017年20期)2017-04-26 06:57:45
        久久久久久国产精品免费网站| 中国午夜伦理片| 日本乱偷人妻中文字幕在线| 久草视频福利| 国产三级在线观看性色av | 一区二区三区国产黄色| 麻豆av一区二区三区| 中国亚洲女人69内射少妇| 国产欧美亚洲精品第二区首页| 97成人精品在线视频| 国产成人综合美国十次| 久久久久亚洲av无码专区体验| 无码av免费精品一区二区三区| 日韩女优一区二区在线观看 | 国产日韩欧美在线| 中文字幕亚洲日本va| 中文字幕一区二区三区的| 三叶草欧洲码在线| 狠狠色噜噜狠狠狠97影音先锋| 成人影院免费视频观看| 91久久精品色伊人6882| 精品国产人成亚洲区| 国产精品每日更新在线观看| 亚洲一区免费视频看看| 丰满熟妇人妻av无码区| 人妻无码一区二区三区四区| 中文字幕无码免费久久9| 精品日本一区二区三区| 最爽无遮挡行房视频| 日韩成人精品在线| 92自拍视频爽啪在线观看| 欧美日韩在线视频| 国产成人精品av| 久久国产精品岛国搬运工| 午夜av天堂精品一区| 国产乱码精品一区二区三区四川人| 激情婷婷六月| 亚洲av第二区国产精品| 国产亚州精品女人久久久久久 | 在线a亚洲视频播放在线观看| 亚洲av综合色区久久精品|