大數據：Hive常(chang)用參數調優
1、limit限(xian)制調整
一般情況下，Limit語句(ju)(ju)還是需(xu)要執行(xing)整個查詢語句(ju)(ju)，然后再返(fan)回部(bu)分結果。
有一(yi)個配置屬性(xing)可以開啟，避免這(zhe)種情(qing)況(kuang)---對(dui)數據(ju)源(yuan)進(jin)行抽樣
hive.limit.optimize.enable=true --- 開啟對(dui)數(shu)據源(yuan)進行采樣的功能
hive.limit.row.max.size --- 設置(zhi)最小的(de)采樣容量
hive.limit.optimize.limit.file --- 設置最大的采樣樣本數
缺(que)點：有可能部分數據永遠(yuan)不會被處理到
2.JOIN優化
1). 將大表放后(hou)頭
Hive假(jia)定查詢中最后(hou)的一(yi)個表(biao)是大表(biao)。它會將其它表(biao)緩存起(qi)來(lai)，然(ran)后(hou)掃(sao)描最后(hou)那(nei)個表(biao)。
因此通常需要(yao)將小表(biao)(biao)放前(qian)面，或者標(biao)記哪(na)張表(biao)(biao)是大表(biao)(biao)：/*streamtable(table_name) */
2). 使(shi)用(yong)相同的連接鍵
當對3個或者(zhe)更多個表進行join連接時(shi)，如果(guo)每個on子句都使用相同的連接鍵的話，那么(me)只會產(chan)生一個MapReduce job。
3). 盡量盡早地(di)過濾數據(ju)
減少每個(ge)階段(duan)的(de)數據量,對于分區表(biao)要加分區，同時只選擇需(xu)要使用到的(de)字(zi)段(duan)。
4). 盡(jin)量原(yuan)子化操作
盡量避免一(yi)個(ge)SQL包含復(fu)雜(za)邏(luo)輯，可以使用中間表(biao)來完成復(fu)雜(za)的邏(luo)輯
3. 本地模(mo)式
有時hive的(de)輸入數(shu)據量(liang)是非常小的(de)。在(zai)這種情況下，為(wei)查詢出發執(zhi)行(xing)任(ren)(ren)務(wu)的(de)時間消(xiao)耗可能會(hui)比實際job的(de)執(zhi)行(xing)時間要多(duo)的(de)多(duo)。對于大多(duo)數(shu)這種情況，hive可以通過本地模式在(zai)單臺機器上(shang)處理(li)所有的(de)任(ren)(ren)務(wu)。對于小數(shu)據集，執(zhi)行(xing)時間會(hui)明(ming)顯被縮短
set hive.exec.mode.local.auto=true;
當一(yi)個job滿(man)足如下條件才(cai)能真正使用本地模式：
1.job的(de)輸入數據大小必(bi)須小于參(can)數：hive.exec.mode.local.auto.inputbytes.max(默認(ren)128MB)
2.job的map數(shu)(shu)必須小于參(can)數(shu)(shu)：hive.exec.mode.local.auto.tasks.max(默認4)
3.job的reduce數(shu)必須為0或者1
可用參數hive.mapred.local.mem(默認0)控(kong)制(zhi)child jvm使(shi)用的最大(da)內存數。
4.并行(xing)執(zhi)行(xing)
hive會(hui)將(jiang)一(yi)(yi)個(ge)查詢(xun)轉化為(wei)一(yi)(yi)個(ge)或多(duo)個(ge)階(jie)(jie)段(duan)(duan)(duan)，包(bao)括：MapReduce階(jie)(jie)段(duan)(duan)(duan)、抽樣階(jie)(jie)段(duan)(duan)(duan)、合(he)并階(jie)(jie)段(duan)(duan)(duan)、limit階(jie)(jie)段(duan)(duan)(duan)等。默認情(qing)況下，一(yi)(yi)次只執行一(yi)(yi)個(ge)階(jie)(jie)段(duan)(duan)(duan)。 不過，如果某(mou)些階(jie)(jie)段(duan)(duan)(duan)不是(shi)互相(xiang)依賴(lai)，是(shi)可以并行執行的。
set hive.exec.parallel=true,可以開啟并(bing)發(fa)執行。
set hive.exec.parallel.thread.number=16; //同一個sql允許(xu)最大并行度，默(mo)認為(wei)8。
會比較耗(hao)系統資源。
5.strict模式
--對分區表進行查詢，在(zai)where子句中(zhong)沒有(you)加分區過濾的話，將禁止提交任務(默認：nonstrict)
set hive.mapred.mode=strict;
注：使用嚴(yan)格模式可以禁止3種(zhong)類型的查詢：
（1）對于分(fen)區表，不(bu)(bu)加(jia)分(fen)區字段過濾條件，不(bu)(bu)能執行
（2）對于(yu)order by語(yu)句，必須(xu)使用limit語(yu)句。
（3）限(xian)制笛卡爾積的(de)查詢（join的(de)時候不使(shi)用(yong)on，而(er)使(shi)用(yong)where的(de)）。
6.調整mapper和reducer個數
Map階段(duan)優化
map執行時間：map任(ren)務啟動和(he)初始(shi)化的(de)時間+邏輯處理(li)的(de)時間。
1.通(tong)常情況下，作業會通(tong)過input的(de)目錄產生一(yi)個或者多個map任(ren)務(wu)。
主要(yao)的(de)決定(ding)因(yin)素有： input的(de)文件總個數(shu)，input的(de)文件大(da)小，集群設置的(de)文件塊(kuai)大(da)小(目前為128M, 可在hive中通過set dfs.block.size;命令查看到，該參數(shu)不能自定(ding)義修改)；
2.舉(ju)例(li)：
a)假設input目錄下有(you)1個文件(jian)a,大小為780M,那么hadoop會將該文件(jian)a分(fen)隔(ge)成7個塊(kuai)(kuai)(kuai)（6個128m的(de)塊(kuai)(kuai)(kuai)和1個12m的(de)塊(kuai)(kuai)(kuai)），從而(er)產生(sheng)7個map數
b)假設input目錄下(xia)有3個文件a,b,c,大小分別為10m，20m，130m，那(nei)么hadoop會分隔成4個塊（10m,20m,128m,2m）,從而(er)產(chan)生(sheng)4個map數
即，如果文(wen)件(jian)大于塊(kuai)大小(128m),那么會拆分(fen)，如果小于塊(kuai)大小，則把該文(wen)件(jian)當成一個塊(kuai)。
3.是不是map數越多越好？
答(da)案(an)是(shi)否(fou)定(ding)的(de)(de)。如果一個(ge)任務(wu)有很多(duo)小(xiao)文件（遠(yuan)遠(yuan)小(xiao)于塊大小(xiao)128m）,則每(mei)個(ge)小(xiao)文件也會被當做一個(ge)塊，用(yong)一個(ge)map任務(wu)來(lai)完成，而一個(ge)map任務(wu)啟動(dong)和初始(shi)化(hua)的(de)(de)時(shi)間遠(yuan)遠(yuan)大于邏輯處理的(de)(de)時(shi)間，就(jiu)會造成很大的(de)(de)資(zi)源(yuan)浪(lang)費。而且，同時(shi)可執行的(de)(de)map數是(shi)受限的(de)(de)。
4.是(shi)不(bu)是(shi)保證每個map處(chu)理接近128m的文件塊，就(jiu)高枕無憂了(le)？
答案也是不(bu)一(yi)定。比如有一(yi)個(ge)(ge)(ge)127m的(de)文件，正常會用一(yi)個(ge)(ge)(ge)map去完成，但這個(ge)(ge)(ge)文件只有一(yi)個(ge)(ge)(ge)或(huo)者兩個(ge)(ge)(ge)小字段(duan)，卻有幾千萬的(de)記錄，如果map處(chu)理的(de)邏輯比較復雜(za)，用一(yi)個(ge)(ge)(ge)map任(ren)務去做，肯定也比較耗(hao)時。
針對上面的問題3和(he)4，我們需要采取兩(liang)種方(fang)式來解決：即(ji)減少map數和(he)增(zeng)加map數；
如(ru)何合并小(xiao)文件(jian)，減少map數？
假設一個SQL任務：Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;
該任務(wu)的(de)inputdir /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
共(gong)有(you)194個文件(jian)，其中(zhong)很多是遠(yuan)(yuan)遠(yuan)(yuan)小于128m的小文件(jian)，總大小9G，正常執(zhi)行會用194個map任務。
Map總共消耗(hao)的計(ji)算(suan)資源： SLOTS_MILLIS_MAPS= 623,020
通過以下(xia)方(fang)法來(lai)在map執行前合并小文件，減少map數：
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;
再執行(xing)上面的(de)語句(ju)，用了74個(ge)map任務，map消耗的(de)計算資源： SLOTS_MILLIS_MAPS=333,500
對于這個簡單(dan)SQL任務，執行(xing)時間上(shang)可能差不多，但節省了(le)一半的計算(suan)資源。
大(da)概解釋一下，100000000表示100M,
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
這個(ge)參數表示執行(xing)前進行(xing)小文件合并，
前面三個參數(shu)確定(ding)合(he)并文件塊(kuai)的大小，大于文件塊(kuai)大小128m的，按照128m來分隔，小于(yu)128m,大于(yu)100m的(de)(de)，按照100m來(lai)分隔，把那些小于(yu)100m的(de)(de)（包括(kuo)小文件和(he)分隔大文件剩下的(de)(de)），進行合(he)并,最終生成了(le)74個塊。
如(ru)何適當的增(zeng)加map數？
當input的文(wen)件都很(hen)大，任務(wu)邏輯復雜，map執行非常(chang)慢的時候(hou)，可(ke)以考慮增加Map數，
來(lai)使得每(mei)個map處理(li)的數據量(liang)減(jian)少，從而提高任務的執行效率。
假設有這(zhe)樣一個(ge)任(ren)務：
Select data_desc,
count(1),
count(distinct id),
sum(case when …),
sum(case when ...),
sum(…)
from a group by data_desc
如(ru)果表(biao)a只有一(yi)個文件(jian)，大(da)小為(wei)120M，但包含幾千萬的記(ji)錄，
如(ru)果用1個map去完成這個任務，肯定是比較(jiao)耗時(shi)的(de)，
這種情況下(xia)，我們要考慮將這一個(ge)文件合理的拆(chai)分成多(duo)個(ge)，
這(zhe)樣(yang)就可以用(yong)多個map任務去完成(cheng)。
set mapred.reduce.tasks=10;
create table a_1 as
select * from a
distribute by rand(123);
;
這樣會將a表的(de)記錄，隨機的(de)分散到包含(han)10個(ge)文件的(de)a_1表中，再(zai)用a_1代替(ti)上面sql中的(de)a表，則(ze)會用10個(ge)map任務去完(wan)成(cheng)。
每個(ge)map任務處理大于12M（幾百萬記(ji)錄）的數據，效率(lv)肯定會(hui)好很多。
看上去，貌(mao)似這兩種(zhong)有些矛盾，一(yi)個(ge)是要合并小(xiao)文件，一(yi)個(ge)是要把大文件拆成(cheng)小(xiao)文件，這點(dian)正是重(zhong)點(dian)需要關注(zhu)的地方，
根據實際情況，控制map數(shu)量需要遵循兩(liang)個(ge)原則：使大數(shu)據量利用合適的map數(shu)；使單個(ge)map任務處(chu)理合適的數(shu)據量；
二、控制hive任務(wu)的(de)reduce數：
1.Hive自己如何確定(ding)reduce數：
reduce個數的(de)設(she)定(ding)(ding)極大影(ying)響任務執(zhi)行效率，不(bu)指定(ding)(ding)reduce個數的(de)情況下(xia)，Hive會猜(cai)測確定(ding)(ding)一個reduce個數，基于以下(xia)兩個設(she)定(ding)(ding)：
hive.exec.reducers.bytes.per.reducer（每個reduce任務(wu)處理的(de)數據量，默認為1000^3=1G）
hive.exec.reducers.max（每個任(ren)務最(zui)大的reduce數，默認為999）
計算reducer數(shu)的公(gong)式很簡單N=min(參數(shu)2，總輸入數(shu)據量/參數(shu)1)
即，如果reduce的輸入（map的輸出）總大小不超過1G,那么只會有一(yi)個reduce任(ren)務；
如：
select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;
/group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04 總大小為9G多，
因此這句有10個reduce
2.調整(zheng)reduce個數方法一：
調整hive.exec.reducers.bytes.per.reducer參(can)數的值；
set hive.exec.reducers.bytes.per.reducer=500000000; （500M）
select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 這次有(you)20個reduce
3.調整reduce個數(shu)方法二；
set mapred.reduce.tasks = 15;
select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;這次有15個reduce
4.reduce個數并(bing)不是越(yue)多(duo)越(yue)好；
同(tong)map一樣(yang)，啟動(dong)和初始化reduce也會消耗時間(jian)和資源(yuan)；
另外(wai)，有多少(shao)個(ge)(ge)reduce,就會有多少(shao)個(ge)(ge)輸出文件(jian)，如(ru)果生成(cheng)了很多個(ge)(ge)小文件(jian)，
那么如果這(zhe)些小(xiao)文件作(zuo)為下一個任務的(de)輸入，則也會出現(xian)小(xiao)文件過多的(de)問題；
5.什么情況下只(zhi)有一個(ge)reduce；
很多(duo)時候你會發現任(ren)務中不管數(shu)(shu)據量多(duo)大，不管你有(you)沒(mei)有(you)設置調整reduce個數(shu)(shu)的參數(shu)(shu)，任(ren)務中一(yi)直都只有(you)一(yi)個reduce任(ren)務；
其(qi)實只有(you)一(yi)個reduce任務的情況(kuang)，除了數據(ju)量(liang)小于hive.exec.reducers.bytes.per.reducer參數值(zhi)的情況(kuang)外(wai)，還有(you)以下(xia)原因：
a)沒有group by的匯總，比如把select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;
寫成 select count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04';
這點非常(chang)常(chang)見，希望大家盡量改(gai)寫。
b)用(yong)了Order by
c)有笛卡爾積
通常(chang)這(zhe)些情況下(xia)，除了找辦法來變通和(he)避(bi)免，我(wo)暫時沒(mei)有什么好的辦法，
因(yin)為這些(xie)操作都(dou)是全局的，所以hadoop不(bu)得不(bu)用一個reduce去完成；
同(tong)樣的，在設置reduce個數的時候也需要考慮這兩個原則：
使大數據(ju)量(liang)利用(yong)合適的reduce數；使單(dan)個reduce任務處理合適的數據(ju)量(liang)。
2 Reduce階段優(you)化
調整方式：
-- set mapred.reduce.tasks=?
-- set hive.exec.reducers.bytes.per.reducer = ?
一般根(gen)據輸入(ru)文件的總大小,用它(ta)的estimation函(han)數(shu)(shu)來(lai)自動計算reduce的個數(shu)(shu)：reduce個數(shu)(shu) = InputFileSize / bytes per reducer
7.JVM重用
--用(yong)于避免小文件(jian)的場景或者task特別多的場景，這類場景大多數(shu)執行(xing)時間都很(hen)短，因為(wei)hive調起mapreduce任務，JVM的啟(qi)動(dong)過程會造成(cheng)很(hen)大的開銷，尤(you)其(qi)是job有成(cheng)千上萬(wan)個task任務時，JVM重用(yong)可以使得JVM實例(li)在同一個job中重新使用(yong)N次
set mapred.job.reuse.jvm.num.tasks=10; --10為重用個數
8.動(dong)態分區調整
--動(dong)態分區屬性：設(she)置為true表示開(kai)啟動(dong)態分區功能（默認為false）
hive.exec.dynamic.partition=true;
--動態分(fen)區屬性：設置為nonstrict,表示允許所有分(fen)區都(dou)是(shi)動態的（默認為strict）
--設置為strict，表示(shi)必須保(bao)證(zheng)至(zhi)少有一個分區是靜態的
hive.exec.dynamic.partition.mode=strict;
--動(dong)態分區屬(shu)性：每個mapper或(huo)reducer可以創建的最大(da)動(dong)態分區個數
hive.exec.max.dynamic.partitions.pernode=100;
--動(dong)態分(fen)區屬(shu)性(xing)：一(yi)個(ge)動(dong)態分(fen)區創建(jian)語句可以創建(jian)的(de)最大(da)動(dong)態分(fen)區個(ge)數
hive.exec.max.dynamic.partitions=1000;
--動態分區屬性：全(quan)局(ju)可(ke)以創建的(de)最大文(wen)件個數(shu)
hive.exec.max.created.files=100000;
--控制DataNode一(yi)次可以打(da)開的文件個(ge)數
--這個(ge)參數必須(xu)設置(zhi)在DataNode的(de)$HADOOP_HOME/conf/hdfs-site.xml文件(jian)中
<property>
<name>dfs.datanode.max.xcievers</name>
<value>8192</value>
</property>
9.推測執行
--目的(de)：是通過加快獲取單(dan)個(ge)task的(de)結果以及進行(xing)偵測將執行(xing)慢(man)的(de)TaskTracker加入到黑名單(dan)的(de)方式來提高整體的(de)任務執行(xing)效率(lv)
（1）修(xiu)改 $HADOOP_HOME/conf/mapred-site.xml文件
<property>;
<name>mapred.map.tasks.speculative.execution </name>
<value>true</value>
</property>
<property>
<name>mapred.reduce.tasks.speculative.execution </name>
; <value>true</value>
</property>
（2）修(xiu)改hive配(pei)置
set hive.mapred.reduce.tasks.speculative.execution=true;
10.數據傾斜
表現(xian)：任務(wu)進度長時間維持在99%（或100%），查看任務(wu)監控頁(ye)面，發(fa)現(xian)只有(you)少量(liang)（1個或幾個）reduce子任務(wu)未完成。因為其(qi)處(chu)理的(de)數據量(liang)和其(qi)他reduce差異過(guo)大。
單(dan)一reduce的記(ji)(ji)錄數與平均記(ji)(ji)錄數差異過大，通(tong)常(chang)可(ke)能達(da)到3倍甚至(zhi)更多。 最長(chang)(chang)時長(chang)(chang)遠(yuan)大于平均時長(chang)(chang)。
原(yuan)因
1)、key分布不(bu)均勻
2)、業(ye)務數據(ju)本身的特(te)性(xing)
3)、建表時(shi)考(kao)慮不(bu)周
4)、某(mou)些SQL語句本身就有數據傾斜
| 關(guan)鍵詞 | 情形 | 后果 |
|---|---|---|
| join | 其中(zhong)一個表較(jiao)小，但是key集中(zhong) | 分發到某一個或幾個Reduce上的數據遠高(gao)于(yu)平(ping)均值 |
| join | 大表與大表，但(dan)是分桶的判斷(duan)字段0值或空值過多 | 這些空值都(dou)由一個(ge)reduce處(chu)理，灰常慢 |
| group by | group by 維度過(guo)小，某值的數量過(guo)多 | 處理某值的(de)reduce灰常耗(hao)時 |
| count distinct | 某特(te)殊值(zhi)過多 | 處理此特(te)殊(shu)值(zhi)reduce耗時 |
解決方案：
參數調(diao)節
hive.map.aggr=true
11. 其他參數調(diao)優
--開啟CLI提(ti)示符前(qian)打印(yin)出當前(qian)所在的數據庫名(ming)
set hive.cli.print.current.db=true;
--讓CLI打印出字段名稱
hive.cli.print.header=true;
--設(she)置任務(wu)名稱(cheng)，方(fang)便查找監(jian)控
SET ;mapred.job.name=P_DWA_D_IA_S_USER_PROD;
--決定(ding)是否(fou)可以(yi)在 Map 端(duan)進行聚合操作
set hive.map.aggr=true;
--有數據傾斜的時候進行負載均衡
set hive.groupby.skewindata=true;
--對于(yu)簡單的不需要聚(ju)合的類似SELECT <col> from <table> LIMIT n語句，不需要起(qi)MapReduce job，直接通過Fetch task獲取數據(ju)
set hive.fetch.task.conversion=more;
12、小文件問題(ti)
小文件是如何(he)產(chan)生(sheng)的
1.動態分區插入(ru)數據，產生(sheng)大量(liang)的小文件，從而導致map數量(liang)劇(ju)增(zeng)。
2.reduce數量越(yue)多，小文件也越(yue)多(reduce的(de)(de)個(ge)數和輸出文件是(shi)對應的(de)(de))。
3.數(shu)據源本身就包含大量的(de)小(xiao)文(wen)件。
小文件問題的影(ying)響
1.從Hive的(de)(de)角度(du)看，小文件(jian)會開很(hen)多map，一(yi)個map開一(yi)個JVM去執(zhi)行(xing)，所以(yi)這(zhe)些任務的(de)(de)初始化，啟(qi)動，執(zhi)行(xing)會浪費(fei)大量的(de)(de)資源，嚴重影(ying)響性能。
2.在HDFS中(zhong)，每個小(xiao)文(wen)件對象約(yue)占(zhan)150byte，如(ru)果小(xiao)文(wen)件過(guo)多(duo)會占(zhan)用大量內存。這樣NameNode內存容量嚴重(zhong)制(zhi)約(yue)了集(ji)群(qun)的擴(kuo)展。
小文件(jian)問題(ti)的解決方案
從(cong)(cong)小文件(jian)產生(sheng)的途經就(jiu)可以從(cong)(cong)源頭上控(kong)制小文件(jian)數量，方法如下：
1.使(shi)用Sequencefile作為表存儲格式，不要用textfile，在一定程度上可以減少小文(wen)件。
2.減少reduce的數(shu)量(可(ke)以(yi)使用參(can)數(shu)進(jin)行控(kong)制)。
3.少用(yong)動(dong)態分區(qu)，用(yong)時(shi)記(ji)得按distribute by分區(qu)。
對于(yu)已(yi)有的小文件，我們可以通過以下幾種方案(an)解決：
1.使用hadoop archive命令把小文件進行歸檔(dang)。
2.重(zhong)建表(biao)，建表(biao)時減少reduce數(shu)量。
3.通過(guo)參數進行調節，設置map/reduce端的相關參數，如下(xia)：
設置map輸入合并小文件的相關參數：
//每個Map最大輸入(ru)大小(xiao)(這個值(zhi)決定了(le)合并后文件的數(shu)量) set mapred.max.split.size=256000000; //一個節點上split的(de)至少的(de)大小(xiao)(這個值(zhi)決定了多個DataNode上的(de)文(wen)件(jian)是(shi)否需要合并) set mapred.min.split.size.per.node=100000000; //一個交(jiao)(jiao)換機下split的至少的大小(xiao)(這(zhe)個值決定了多個交(jiao)(jiao)換機上的文件是否需要合并) set mapred.min.split.size.per.rack=100000000; //執行(xing)Map前進行(xing)小(xiao)文件合并 set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
設置map輸出和(he)reduce輸出進(jin)行(xing)合并的相關參數：
//設置(zhi)map端(duan)輸出(chu)進行合(he)并，默認為true set hive.merge.mapfiles = true //設置reduce端(duan)輸出進行合并，默(mo)認為false set hive.merge.mapredfiles = true //設置合并文件(jian)的大小 set hive.merge.size.per.task = 256*1000*1000 //當輸出(chu)文(wen)件的平均大小小于(yu)該值(zhi)時，啟(qi)動(dong)一個獨立(li)的MapReduce任務進行文(wen)件merge。 set hive.merge.smallfiles.avgsize=16000000
設置如(ru)下(xia)參數取消一些限制(HIVE 0.7后沒有此限制)：
hive.merge.mapfiles=false
默認值：true
描述：是否合(he)(he)并Map的輸出文件，也就是把小文件合(he)(he)并成一個map
hive.merge.mapredfiles=false
默(mo)認值：false
描(miao)述：是否合并(bing)Reduce的輸出(chu)文件(jian)，也就是在Map輸出(chu)階段做一次reduce操(cao)作，再輸出(chu)
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
這個參數表示執行前進行小文件(jian)合并，
前(qian)面三(san)個參數(shu)確定合(he)并(bing)文(wen)件塊的大(da)小(xiao)，大(da)于文(wen)件塊大(da)小(xiao)128m的，
按(an)照128m來分隔，小(xiao)于128m,大于100m的(de)，按(an)照100m來分隔，把(ba)那些小(xiao)于100m的(de)（包括小(xiao)文件和(he)分隔大文件剩(sheng)下的(de)），進行合并,最(zui)終生(sheng)成了74個塊。
參考：