這篇文章給大家分享的是有關(guān)Hive性能調(diào)優(yōu)中數(shù)據(jù)傾斜的示例分析的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

創(chuàng)新互聯(lián)建站專注于企業(yè)成都營(yíng)銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、瀏陽(yáng)網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、商城網(wǎng)站開(kāi)發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為瀏陽(yáng)等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。

Map數(shù)

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)一個(gè)大文件：假設(shè)input目錄下有1個(gè)文件a，大小為780M，那么hadoop會(huì)將該文件a分隔成7個(gè)塊（6個(gè)128m的塊和1個(gè)12m的塊），從而產(chǎn)生7個(gè)map數(shù)。b) 多個(gè)小文件：假設(shè)input目錄下有3個(gè)文件a，b，c大小分別為10m，20m，150m，那么hadoop會(huì)分隔成4個(gè)塊（10m，20m，128m，22m），從而產(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ú)憂了？答案也是不一定。比如有一個(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ù)。

如何適當(dāng)?shù)脑黾觤ap數(shù)

當(dāng)input的文件都很大，任務(wù)邏輯復(fù)雜，map執(zhí)行非常慢的時(shí)候，可以考慮增加Map數(shù)，來(lái)使得每個(gè)map處理的數(shù)據(jù)量減少，從而提高任務(wù)的執(zhí)行效率。針對(duì)上面的第4條 假設(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 mapreduce.job.reduces =10;
create table a_1 as
select * from a
distribute by rand();

這樣會(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ù)量；

調(diào)整reduce數(shù)

1. 調(diào)整reduce個(gè)數(shù)方法一

a） 每個(gè)Reduce 處理的數(shù)據(jù)量默認(rèn)是256MB

hive.exec.reducers.bytes.per.reducer=256123456

b） 每個(gè)任務(wù)最大的reduce數(shù)，默認(rèn)為1009

hive.exec.reducers.max=1009

c）計(jì)算reducer數(shù)的公式

N=min(參數(shù)2，總輸入數(shù)據(jù)量/參數(shù)1)

參數(shù)1：每個(gè)Reduce處理的最大數(shù)據(jù)量 參數(shù)2：每個(gè)任務(wù)最大Reduce數(shù)量

1. 調(diào)整reduce個(gè)數(shù)方法二

在hadoop的mapred-default.xml文件中修改 設(shè)置每個(gè)job的Reduce個(gè)數(shù)

set mapreduce.job.reduces = 15;

1. reduce個(gè)數(shù)并不是越多越好

a）過(guò)多的啟動(dòng)和初始化reduce也會(huì)消耗時(shí)間和資源；b） 有多少個(gè)reduce，就會(huì)有多少個(gè)輸出文件，如果生成了很多個(gè)小文件，那么如果這些小文件作為下一個(gè)任務(wù)的輸入，則也會(huì)出現(xiàn)小文件過(guò)多的問(wèn)題；

感謝各位的閱讀！關(guān)于“Hive性能調(diào)優(yōu)中數(shù)據(jù)傾斜的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！