這篇文章給大家分享的是有關(guān)如何控制hive中的map數(shù)的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

創(chuàng)新互聯(lián)公司是創(chuàng)新、創(chuàng)意、研發(fā)型一體的綜合型網(wǎng)站建設(shè)公司，自成立以來(lái)公司不斷探索創(chuàng)新，始終堅(jiān)持為客戶(hù)提供滿(mǎn)意周到的服務(wù)，在本地打下了良好的口碑，在過(guò)去的10年時(shí)間我們累計(jì)服務(wù)了上千家以及全國(guó)政企客戶(hù)，如成都圍欄護(hù)欄等企業(yè)單位，完善的項(xiàng)目管理流程，嚴(yán)格把控項(xiàng)目進(jìn)度與質(zhì)量監(jiān)控加上過(guò)硬的技術(shù)實(shí)力獲得客戶(hù)的一致稱(chēng)譽(yù)。

1. 通常情況下，作業(yè)會(huì)通過(guò)input的目錄產(chǎn)生一個(gè)或者多個(gè)map任務(wù)。 主要的決定因素有： input的文件總個(gè)數(shù)，input的文件大小，集群設(shè)置的文件塊大小(目前為128M, 可在hive中通過(guò)set dfs.block.size;命令查看到，該參數(shù)不能自定義修改)； 2. 舉例： a) 假設(shè)input目錄下有1個(gè)文件a,大小為780M,那么hadoop會(huì)將該文件a分隔成7個(gè)塊（6個(gè)128m的塊和1個(gè)12m的塊），從而產(chǎn)生7個(gè)map數(shù) b) 假設(shè)input目錄下有3個(gè)文件a,b,c,大小分別為10m，20m，130m，那么hadoop會(huì)分隔成4個(gè)塊（10m,20m,128m,2m）,從而產(chǎn)生4個(gè)map數(shù) 即，如果文件大于塊大小(128m),那么會(huì)拆分，如果小于塊大小，則把該文件當(dāng)成一個(gè)塊。 3. 是不是map數(shù)越多越好？ 答案是否定的。如果一個(gè)任務(wù)有很多小文件（遠(yuǎn)遠(yuǎn)小于塊大小128m）,則每個(gè)小文件也會(huì)被當(dāng)做一個(gè)塊，用一個(gè)map任務(wù)來(lái)完成， 而一個(gè)map任務(wù)啟動(dòng)和初始化的時(shí)間遠(yuǎn)遠(yuǎn)大于邏輯處理的時(shí)間，就會(huì)造成很大的資源浪費(fèi)。 而且，同時(shí)可執(zhí)行的map數(shù)是受限的。 4. 是不是保證每個(gè)map處理接近128m的文件塊，就高枕無(wú)憂(yōu)了？ 答案也是不一定。比如有一個(gè)127m的文件，正常會(huì)用一個(gè)map去完成，但這個(gè)文件只有一個(gè)或者兩個(gè)小字段，卻有幾千萬(wàn)的記錄， 如果map處理的邏輯比較復(fù)雜，用一個(gè)map任務(wù)去做，肯定也比較耗時(shí)。 針對(duì)上面的問(wèn)題3和4，我們需要采取兩種方式來(lái)解決：即減少map數(shù)和增加map數(shù)； 如何合并小文件，減少map數(shù)？ 假設(shè)一個(gè)SQL任務(wù)： Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’; 該任務(wù)的inputdir/group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04 共有194個(gè)文件，其中很多是遠(yuǎn)遠(yuǎn)小于128m的小文件，總大小9G，正常執(zhí)行會(huì)用194個(gè)map任務(wù)。 Map總共消耗的計(jì)算資源： SLOTS_MILLIS_MAPS= 623,020 我通過(guò)以下方法來(lái)在map執(zhí)行前合并小文件，減少map數(shù)： set mapred.max.split.size=100000000; set mapred.min.split.size.per.node=100000000; set mapred.min.split.size.per.rack=100000000; set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; 再執(zhí)行上面的語(yǔ)句，用了74個(gè)map任務(wù)，map消耗的計(jì)算資源：SLOTS_MILLIS_MAPS= 333,500 對(duì)于這個(gè)簡(jiǎn)單SQL任務(wù)，執(zhí)行時(shí)間上可能差不多，但節(jié)省了一半的計(jì)算資源。 大概解釋一下，100000000表示100M, sethive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;這個(gè)參數(shù)表示執(zhí)行前進(jìn)行小文件合并， 前面三個(gè)參數(shù)確定合并文件塊的大小，大于文件塊大小128m的，按照128m來(lái)分隔，小于128m,大于100m的，按照100m來(lái)分隔，把那些小于100m的（包括小文件和分隔大文件剩下的）， 進(jìn)行合并,最終生成了74個(gè)塊。 如何適當(dāng)?shù)脑黾觤ap數(shù)？ 當(dāng)input的文件都很大，任務(wù)邏輯復(fù)雜，map執(zhí)行非常慢的時(shí)候，可以考慮增加Map數(shù)，來(lái)使得每個(gè)map處理的數(shù)據(jù)量減少，從而提高任務(wù)的執(zhí)行效率。 假設(shè)有這樣一個(gè)任務(wù)： Select data_desc, count(1), count(distinct id), sum(case when …), sum(case when ...), sum(…) from a group by data_desc 如果表a只有一個(gè)文件，大小為120M，但包含幾千萬(wàn)的記錄，如果用1個(gè)map去完成這個(gè)任務(wù)，肯定是比較耗時(shí)的，這種情況下，我們要考慮將這一個(gè)文件合理的拆分成多個(gè)， 這樣就可以用多個(gè)map任務(wù)去完成。 set mapred.reduce.tasks=10; create table a_1 as  select * from a  distribute by rand(123);  這樣會(huì)將a表的記錄，隨機(jī)的分散到包含10個(gè)文件的a_1表中，再用a_1代替上面sql中的a表，則會(huì)用10個(gè)map任務(wù)去完成。 每個(gè)map任務(wù)處理大于12M（幾百萬(wàn)記錄）的數(shù)據(jù)，效率肯定會(huì)好很多。 看上去，貌似這兩種有些矛盾，一個(gè)是要合并小文件，一個(gè)是要把大文件拆成小文件，這點(diǎn)正是重點(diǎn)需要關(guān)注的地方， 根據(jù)實(shí)際情況，控制map數(shù)量需要遵循兩個(gè)原則：使大數(shù)據(jù)量利用合適的map數(shù)；使單個(gè)map任務(wù)處理合適的數(shù)據(jù)量；

感謝各位的閱讀！關(guān)于“如何控制hive中的map數(shù)”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！

當(dāng)前題目：如何控制hive中的map數(shù)
文章出自：http://jinyejixie.com/article24/ggsgce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、搜索引擎優(yōu)化、關(guān)鍵詞優(yōu)化、移動(dòng)網(wǎng)站建設(shè)、面包屑導(dǎo)航、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)