深入浅出学Hive：Hive优化
目錄：
初始Hive
Hive安裝與配置
Hive內(nèi)建操作符與函數(shù)開發(fā)
Hive JDBC
Hive參數(shù)
Hive高級編程
Hive QL
Hive Shell基本操作
Hive優(yōu)化
Hive體系結(jié)構(gòu)
Hive原理
?
?
?
第一部分：Hadoop 計算框架的特性
什么是數(shù)據(jù)傾斜
?由于數(shù)據(jù)的不均衡原因，導致數(shù)據(jù)分布不均勻，造成數(shù)據(jù)大量的集中到一點，造成數(shù)據(jù)熱點
Hadoop框架的特性
?不怕數(shù)據(jù)大，怕數(shù)據(jù)傾斜
?jobs數(shù)比較多的作業(yè)運行效率相對比較低，比如即使有幾百行的表，如果多次關(guān)聯(lián)多次匯總，產(chǎn)生十幾個jobs，耗時很長。原因是map reduce作業(yè)初始化的時間是比較長的
?sum,count,max,min等UDAF，不怕數(shù)據(jù)傾斜問題,hadoop在map端的匯總合并優(yōu)化，使數(shù)據(jù)傾斜不成問題
?count(distinct ),在數(shù)據(jù)量大的情況下，效率較低，因為count(distinct)是按group by 字段分組，按distinct字段排序，一般這種分布方式是很傾斜的
第二部分：優(yōu)化的常用手段
優(yōu)化的常用手段
?解決數(shù)據(jù)傾斜問題
?減少job數(shù)
?設(shè)置合理的map reduce的task數(shù)，能有效提升性能。
?了解數(shù)據(jù)分布，自己動手解決數(shù)據(jù)傾斜問題是個不錯的選擇
?數(shù)據(jù)量較大的情況下，慎用count(distinct)。
?對小文件進行合并，是行至有效的提高調(diào)度效率的方法。
?優(yōu)化時把握整體，單個作業(yè)最優(yōu)不如整體最優(yōu)。
?
?
第三部分：Hive的數(shù)據(jù)類型方面的優(yōu)化
優(yōu)化原則
?按照一定規(guī)則分區(qū)（例如根據(jù)日期）。通過分區(qū)，查詢的時候指定分區(qū)，會大大減少在無用數(shù)據(jù)上的掃描, 同時也非常方便數(shù)據(jù)清理。
?合理的設(shè)置Buckets。在一些大數(shù)據(jù)join的情況下，map join有時候會內(nèi)存不夠。如果使用Bucket Map Join的話，可以只把其中的一個bucket放到內(nèi)存中，內(nèi)存中原來放不下的內(nèi)存表就變得可以放下。這需要使用buckets的鍵進行join的條件連結(jié)，并且需要如下設(shè)置
???? set hive.optimize.bucketmapjoin = true
第四部分：Hive的操作方面的優(yōu)化
?全排序
?怎樣做笛卡爾積
?怎樣決定map個數(shù)
?怎樣決定reducer個數(shù)
?合并MapReduce操作
?Bucket 與 sampling
?Partition
?JOIN
?Group By
?合并小文件
全排序?
?Hive的排序關(guān)鍵字是SORT BY，它有意區(qū)別于傳統(tǒng)數(shù)據(jù)庫的ORDER BY也是為了強調(diào)兩者的區(qū)別–SORT BY只能在單機范圍內(nèi)排序
怎樣做笛卡爾積
?當Hive設(shè)定為嚴格模式（hive.mapred.mode=strict）時，不允許在HQL語句中出現(xiàn)笛卡爾積
?MapJoin是的解決辦法
?MapJoin，顧名思義，會在Map端完成Join操作。這需要將Join操作的一個或多個表完全讀入內(nèi)存
?MapJoin的用法是在查詢/子查詢的SELECT關(guān)鍵字后面添加/*+ MAPJOIN(tablelist) */提示優(yōu)化器轉(zhuǎn)化為MapJoin（目前Hive的優(yōu)化器不能自動優(yōu)化MapJoin）
?其中tablelist可以是一個表，或以逗號連接的表的列表。tablelist中的表將會讀入內(nèi)存，應該將小表寫在這里
?在大表和小表做笛卡爾積時，規(guī)避笛卡爾積的方法是，給Join添加一個Join key，原理很簡單：將小表擴充一列join key，并將小表的條目復制數(shù)倍，join key各不相同；將大表擴充一列join key為隨機數(shù)
?
控制Hive的Map數(shù)
?通常情況下，作業(yè)會通過input的目錄產(chǎn)生一個或者多個map任務
?主要的決定因素有： input的文件總個數(shù)，input的文件大小，集群設(shè)置的文件塊大小(目前為128M, 可在hive中通過set dfs.block.size;命令查看到，該參數(shù)不能自定義修改)
?是不是map數(shù)越多越好
答案是否定的。如果一個任務有很多小文件（遠遠小于塊大小128m）,則每個小文件也會被當做一個塊，用一個map任務來完成，?
而一個map任務啟動和初始化的時間遠遠大于邏輯處理的時間，就會造成很大的資源浪費。?
而且，同時可執(zhí)行的map數(shù)是受限的
?是不是保證每個map處理接近128m的文件塊，就高枕無憂了？
???? 答案也是不一定。比如有一個127m的文件，正常會用一個map去完成，但這個文件只有一個或者兩個小字段，卻有幾千萬的記錄，?
如果map處理的邏輯比較復雜，用一個map任務去做，肯定也比較耗時。?
針對上面的問題3和4，我們需要采取兩種方式來解決：即減少map數(shù)和增加map數(shù)；
?是不是保證每個map處理接近128m的文件塊，就高枕無憂了？
???? 答案也是不一定。比如有一個127m的文件，正常會用一個map去完成，但這個文件只有一個或者兩個小字段，卻有幾千萬的記錄，?
如果map處理的邏輯比較復雜，用一個map任務去做，肯定也比較耗時。?
針對上面的問題3和4，我們需要采取兩種方式來解決：即減少map數(shù)和增加map數(shù)；
?舉例
??? a)?假設(shè)input目錄下有1個文件a,大小為780M,那么hadoop會將該文件a分隔成7個塊（6個128m的塊和1個12m的塊），從而產(chǎn)生7個map數(shù)?
b)??? 假設(shè)input目錄下有3個文件a,b,c,大小分別為10m，20m，130m，那么hadoop會分隔成4個塊（10m,20m,128m,2m）,從而產(chǎn)生4個map數(shù)?
即，如果文件大于塊大小(128m),那么會拆分，如果小于塊大小，則把該文件當成一個塊
?
怎樣決定reducer個數(shù)
?Hadoop MapReduce程序中，reducer個數(shù)的設(shè)定極大影響執(zhí)行效率
?不指定reducer個數(shù)的情況下，Hive會猜測確定一個reducer個數(shù)，基于以下兩個設(shè)定：
???? 參數(shù)1：hive.exec.reducers.bytes.per.reducer（默認為1G)
??? 參數(shù)2 ：hive.exec.reducers.max（默認為999）
?計算reducer數(shù)的公式
?N=min(參數(shù)2，總輸入數(shù)據(jù)量/參數(shù)1)
?依據(jù)Hadoop的經(jīng)驗，可以將參數(shù)2設(shè)定為0.95*(集群中TaskTracker個數(shù))
?reduce個數(shù)并不是越多越好
同map一樣，啟動和初始化reduce也會消耗時間和資源；?
另外，有多少個reduce,就會有多少個輸出文件，如果生成了很多個小文件，那么如果這些小文件作為下一個任務的輸入，則也會出現(xiàn)小文件過多的問題
?什么情況下只有一個reduce
?????????? 很多時候你會發(fā)現(xiàn)任務中不管數(shù)據(jù)量多大，不管你有沒有設(shè)置調(diào)整reduce個數(shù)的參數(shù)，任務中一直都只有一個reduce任務；?
其實只有一個reduce任務的情況，除了數(shù)據(jù)量小于
????? hive.exec.reducers.bytes.per.reducer參數(shù)值的情況外，還有以下原因：?
a)??? 沒有g(shù)roup by的匯總?
b)??? 用了Order by
合并?MapReduce?操作?
?
??Multi-group by
?Multi-group by是Hive的一個非常好的特性，它使得Hive中利用中間結(jié)果變得非常方便
?FROM log
?? insert overwrite table test1 select log.id group by log.id
??? insert? overwrite table test2 select log.name group by log.name
??上述查詢語句使用了Multi-group by特性連續(xù)group by了2次數(shù)據(jù)，使用不同的group by key。這一特性可以減少一次MapReduce操作。
Bucket?與 Sampling
?Bucket是指將數(shù)據(jù)以指定列的值為key進行hash，hash到指定數(shù)目的桶中。這樣就可以支持高效采樣了
?Sampling可以在全體數(shù)據(jù)上進行采樣，這樣效率自然就低，它還是要去訪問所有數(shù)據(jù)。而如果一個表已經(jīng)對某一列制作了bucket，就可以采樣所有桶中指定序號的某個桶，這就減少了訪問量。
?如下例所示就是采樣了test中32個桶中的第三個桶。
?SELECT * FROM test 、、、TABLESAMPLE(BUCKET 3 OUT OF 32);
JOIN?原則
?在使用寫有 Join 操作的查詢語句時有一條原則：應該將條目少的表/子查詢放在 Join 操作符的左邊
?原因是在 Join 操作的 Reduce 階段，位于 Join 操作符左邊的表的內(nèi)容會被加載進內(nèi)存，將條目少的表放在左邊，可以有效減少發(fā)生 OOM 錯誤的幾率
Map Join?
?Join 操作在 Map 階段完成，不再需要Reduce，前提條件是需要的數(shù)據(jù)在 Map 的過程中可以訪問到
?例如：
?INSERT OVERWRITE TABLE phone_traffic
SELECT /*+ MAPJOIN(phone_location) */? l.phone,p.location,l.traffic from phone_location p join log l on (p.phone=l.phone)
?相關(guān)的參數(shù)為：
hive.join.emit.interval = 1000?How many rows in the right-most join operand Hive should buffer before emitting the join result.
hive.mapjoin.size.key = 10000
hive.mapjoin.cache.numrows = 10000
Group By?
?Map 端部分聚合
?并不是所有的聚合操作都需要在 Reduce 端完成，很多聚合操作都可以先在 Map 端進行部分聚合，最后在 Reduce 端得出最終結(jié)果
?
??基于 Hash
??參數(shù)包括：
?hive.map.aggr = true 是否在 Map 端進行聚合，默認為 True
?hive.groupby.mapaggr.checkinterval = 100000 在 Map 端進行聚合操作的條目數(shù)目
?有數(shù)據(jù)傾斜的時候進行負載均衡
?hive.groupby.skewindata = false
?當選項設(shè)定為 true，生成的查詢計劃會有兩個 MR Job。第一個 MR Job 中，Map 的輸出結(jié)果集合會隨機分布到 Reduce 中，每個 Reduce 做部分聚合操作，并輸出結(jié)果，這樣處理的結(jié)果是相同的 Group By Key 有可能被分發(fā)到不同的 Reduce 中，從而達到負載均衡的目的；第二個 MR Job 再根據(jù)預處理的數(shù)據(jù)結(jié)果按照 Group By Key 分布到 Reduce 中（這個過程可以保證相同的 Group By Key 被分布到同一個 Reduce 中），最后完成最終的聚合操作。
合并小文件
?文件數(shù)目過多，會給 HDFS 帶來壓力，并且會影響處理效率，可以通過合并 Map 和 Reduce 的結(jié)果文件來消除這樣的影響：
?hive.merge.mapfiles = true 是否和并 Map 輸出文件，默認為 True
?hive.merge.mapredfiles = false 是否合并 Reduce 輸出文件，默認為 False
?hive.merge.size.per.task = 256*1000*1000 合并文件的大小
轉(zhuǎn)載請注明出處【?http://sishuok.com/forum/blogPost/list/0/6229.html】
總結(jié)
以上是生活随笔為你收集整理的深入浅出学Hive：Hive优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 深入浅出学Hive：Hive内建操作符与
- 下一篇： 深入浅出学Hive：Hive高级编程