大數(shù)據(jù)性能優(yōu)化之Hive優(yōu)化

1、Hive性能優(yōu)化1.概述 本人在工作中總結(jié)Hive的常用優(yōu)化手段和在工作中使用Hive出現(xiàn)的問(wèn)題。下面開(kāi)始本篇文章的優(yōu)化介紹。2.介紹首先，我們來(lái)看看hadoop的計(jì)算框架特性，在此特性下會(huì)衍生哪些問(wèn)題？ 數(shù)據(jù)量大不是問(wèn)題，數(shù)據(jù)傾斜是個(gè)問(wèn)題。 jobs數(shù)比較多的作業(yè)運(yùn)行效率相對(duì)比較低，比如即使有幾百行的表，如果多次關(guān)聯(lián)多次匯總，產(chǎn)生十幾個(gè)jobs，耗時(shí)很長(zhǎng)。原因是map reduce作業(yè)初始化的時(shí)間是比較長(zhǎng)的。 sum,count,max,min等UDAF，不怕數(shù)據(jù)傾斜問(wèn)題,hadoop在map端的匯總合并優(yōu)化，使數(shù)據(jù)傾斜不成問(wèn)題。 count(distinct ),在數(shù)據(jù)量大的情況下，效率較

2、低，如果是多count(distinct )效率更低，因?yàn)閏ount(distinct)是按group by 字段分組，按distinct字段排序，一般這種分布方式是很傾斜的。舉個(gè)例子：比如男uv,女uv，像淘寶一天30億的pv，如果按性別分組，分配2個(gè) reduce,每個(gè)reduce處理15億數(shù)據(jù)。面對(duì)這些問(wèn)題，我們能有哪些有效的優(yōu)化手段呢？下面列出一些在工作有效可行的優(yōu)化手段： 好的模型設(shè)計(jì)事半功倍。 解決數(shù)據(jù)傾斜問(wèn)題。 減少job數(shù)。 設(shè)置合理的map reduce的task數(shù)，能有效提升性能。(比如，10w+級(jí)別的計(jì)算，用160個(gè)reduce，那是相當(dāng)?shù)睦速M(fèi)，1個(gè)足夠)。 了解數(shù)據(jù)分布

3、，自己動(dòng)手解決數(shù)據(jù)傾斜問(wèn)題是個(gè)不錯(cuò)的選擇。set hive.groupby.skewindata=true;這是通用的算法優(yōu)化，但算法優(yōu)化有時(shí)不能適應(yīng)特定業(yè)務(wù)背景，開(kāi)發(fā)人員了解業(yè)務(wù)，了解數(shù)據(jù)，可以通過(guò)業(yè)務(wù)邏輯精確有效的解決數(shù)據(jù)傾斜問(wèn)題。 數(shù)據(jù)量較大的情況下，慎用count(distinct)，count(distinct)容易產(chǎn)生傾斜問(wèn)題。 對(duì)小文件進(jìn)行合并，是行至有效的提高調(diào)度效率的方法，假如所有的作業(yè)設(shè)置合理的文件數(shù)，對(duì)云梯的整體調(diào)度效率也會(huì)產(chǎn)生積極的正向影響。 優(yōu)化時(shí)把握整體，單個(gè)作業(yè)最優(yōu)不如整體最優(yōu)。而接下來(lái)，我們心中應(yīng)該會(huì)有一些疑問(wèn)，影響性能的根源是什么？3.性能低下的根源hive性

4、能優(yōu)化時(shí)，把HiveQL當(dāng)做M/R程序來(lái)讀，即從M/R的運(yùn)行角度來(lái)考慮優(yōu)化性能，從更底層思考如何優(yōu)化運(yùn)算性能，而不僅僅局限于邏輯代碼的替換層面。RAC（Real Application Cluster）真正應(yīng)用集群就像一輛機(jī)動(dòng)靈活的小貨車(chē)，響應(yīng)快；Hadoop就像吞吐量巨大的輪船，啟動(dòng)開(kāi)銷(xiāo)大，如果每次只做小數(shù)量的輸入輸出，利用率 將會(huì)很低。所以用好Hadoop的首要任務(wù)是增大每次任務(wù)所搭載的數(shù)據(jù)量。Hadoop的核心能力是parition和sort，因而這也是優(yōu)化的根本。觀察Hadoop處理數(shù)據(jù)的過(guò)程，有幾個(gè)顯著的特征： 數(shù)據(jù)的大規(guī)模并不是負(fù)載重點(diǎn)，造成運(yùn)行壓力過(guò)大是因?yàn)檫\(yùn)行數(shù)據(jù)的傾斜。 jo

5、bs數(shù)比較多的作業(yè)運(yùn)行效率相對(duì)比較低，比如即使有幾百行的表，如果多次關(guān)聯(lián)對(duì)此匯總，產(chǎn)生幾十個(gè)jobs，將會(huì)需要30分鐘以上的時(shí)間且大部分時(shí)間被用于作業(yè)分配，初始化和數(shù)據(jù)輸出。M/R作業(yè)初始化的時(shí)間是比較耗時(shí)間資源的一個(gè)部分。 在使用SUM，COUNT，MAX，MIN等UDAF函數(shù)時(shí)，不怕數(shù)據(jù)傾斜問(wèn)題，Hadoop在Map端的匯總合并優(yōu)化過(guò)，使數(shù)據(jù)傾斜不成問(wèn)題。 COUNT(DISTINCT)在數(shù)據(jù)量大的情況下，效率較低，如果多COUNT(DISTINCT)效率更低，因?yàn)?COUNT(DISTINCT)是按GROUP BY字段分組，按DISTINCT字段排序，一般這種分布式方式是很傾斜的；比如：

6、男UV，女UV，淘寶一天30億的PV，如果按性別分組，分配2個(gè) reduce,每個(gè)reduce處理15億數(shù)據(jù)。 數(shù)據(jù)傾斜是導(dǎo)致效率大幅降低的主要原因，可以采用多一次 Map/Reduce 的方法， 避免傾斜。最后得出的結(jié)論是：避實(shí)就虛，用 job 數(shù)的增加，輸入量的增加，占用更多存儲(chǔ)空間，充分利用空閑 CPU 等各種方法，分解數(shù)據(jù)傾斜造成的負(fù)擔(dān)。4.配置角度優(yōu)化我們知道了性能低下的根源，同樣，我們也可以從Hive的配置解讀去優(yōu)化。Hive系統(tǒng)內(nèi)部已針對(duì)不同的查詢(xún)預(yù)設(shè)定了優(yōu)化方法，用戶(hù)可以通過(guò)調(diào)整配置進(jìn)行控制， 以下舉例介紹部分優(yōu)化的策略以及優(yōu)化控制選項(xiàng)。4.1列裁剪Hive 在讀數(shù)據(jù)的時(shí)候，可

7、以只讀取查詢(xún)中所需要用到的列，而忽略其它列。 例如，若有以下查詢(xún)：SELECT a,b FROM q WHERE e10;在實(shí)施此項(xiàng)查詢(xún)中，Q 表有 5 列（a，b，c，d，e），Hive 只讀取查詢(xún)邏輯中真實(shí)需要 的 3 列 a、b、e，而忽略列 c，d；這樣做節(jié)省了讀取開(kāi)銷(xiāo)，中間表存儲(chǔ)開(kāi)銷(xiāo)和數(shù)據(jù)整合開(kāi)銷(xiāo)。裁剪所對(duì)應(yīng)的參數(shù)項(xiàng)為：hive.optimize.cp=true（默認(rèn)值為真）4.2分區(qū)裁剪可以在查詢(xún)的過(guò)程中減少不必要的分區(qū)。 例如，若有以下查詢(xún)：SELECT*FROM (SELECTT a1,COUNT(1) FROM T GROUPBY a1) subq WHERE subq.pr

8、tn=100; #（多余分區(qū)） SELECT*FROM T1 JOIN (SELECT*FROM T2) subq ON (T1.a1=subq.a2) WHERE subq.prtn=100;查詢(xún)語(yǔ)句若將“subq.prtn=100”條件放入子查詢(xún)中更為高效，可以減少讀入的分區(qū) 數(shù)目。 Hive 自動(dòng)執(zhí)行這種裁剪優(yōu)化。分區(qū)參數(shù)為：hive.optimize.pruner=true（默認(rèn)值為真）4.3JOIN操作在編寫(xiě)帶有 join 操作的代碼語(yǔ)句時(shí)，應(yīng)該將條目少的表/子查詢(xún)放在 Join 操作符的左邊。 因?yàn)樵?Reduce 階段，位于 Join 操作符左邊的表的內(nèi)容會(huì)被加載進(jìn)內(nèi)存，載入條目

9、較少的表 可以有效減少 OOM（out of memory）即內(nèi)存溢出。所以對(duì)于同一個(gè) key 來(lái)說(shuō)，對(duì)應(yīng)的 value 值小的放前，大的放后，這便是“小表放前”原則。 若一條語(yǔ)句中有多個(gè) Join，依據(jù) Join 的條件相同與否，有不同的處理方法。4.3.1JOIN原則在使用寫(xiě)有 Join 操作的查詢(xún)語(yǔ)句時(shí)有一條原則：應(yīng)該將條目少的表/子查詢(xún)放在 Join 操作符的左邊。原因是在 Join 操作的 Reduce 階段，位于 Join 操作符左邊的表的內(nèi)容會(huì)被加載進(jìn)內(nèi)存，將條目少的表放在左邊，可以有效減少發(fā)生 OOM 錯(cuò)誤的幾率。對(duì)于一條語(yǔ)句中有多個(gè) Join 的情況，如果 Join 的條件相

10、同，比如查詢(xún)：INSERT OVERWRITE TABLE pv_users SELECT pv.pageid, u.age FROM page_view p JOINuser u ON (pv.userid = u.userid) JOIN newuser x ON (u.userid = x.userid); 如果 Join 的 key 相同，不管有多少個(gè)表，都會(huì)則會(huì)合并為一個(gè) Map-Reduce 一個(gè) Map-Reduce 任務(wù)，而不是 n 個(gè) 在做 OUTER JOIN 的時(shí)候也是一樣如果 Join 的條件不相同，比如：INSERT OVERWRITE TABLE pv_users

11、SELECT pv.pageid, u.age FROM page_view p JOINuser u ON (pv.userid = u.userid) JOIN newuser x on (u.age = x.age);Map-Reduce 的任務(wù)數(shù)目和 Join 操作的數(shù)目是對(duì)應(yīng)的，上述查詢(xún)和以下查詢(xún)是等價(jià)的：INSERT OVERWRITE TABLE tmptable SELECT*FROM page_view p JOINuser u ON (pv.userid = u.userid); INSERT OVERWRITE TABLE pv_users SELECT x.pageid

12、, x.age FROM tmptable x JOIN newuser y ON (x.age = y.age);4.4MAP JOIN操作Join 操作在 Map 階段完成，不再需要Reduce，前提條件是需要的數(shù)據(jù)在 Map 的過(guò)程中可以訪問(wèn)到。比如查詢(xún)：INSERT OVERWRITE TABLE pv_users SELECT/*+ MAPJOIN(pv) */ pv.pageid, u.age FROM page_view pv JOINuser u ON (pv.userid = u.userid);可以在 Map 階段完成 Join，如圖所示：相關(guān)的參數(shù)為： hive.join

13、.erval = 1000 hive.mapjoin.size.key = 10000 hive.mapjoin.cache.numrows = 100004.5GROUP BY操作進(jìn)行GROUP BY操作時(shí)需要注意一下幾點(diǎn)： Map端部分聚合事實(shí)上并不是所有的聚合操作都需要在reduce部分進(jìn)行，很多聚合操作都可以先在Map端進(jìn)行部分聚合，然后reduce端得出最終結(jié)果。這里需要修改的參數(shù)為：hive.map.aggr=true（用于設(shè)定是否在 map 端進(jìn)行聚合，默認(rèn)值為真） hive.groupby.mapaggr.checkinterval=（用于設(shè)定 map 端進(jìn)行聚

14、合操作的條目數(shù)） 有數(shù)據(jù)傾斜時(shí)進(jìn)行負(fù)載均衡此處需要設(shè)定 hive.groupby.skewindata，當(dāng)選項(xiàng)設(shè)定為 true 是，生成的查詢(xún)計(jì)劃有兩 個(gè) MapReduce 任務(wù)。在第一個(gè) MapReduce 中，map 的輸出結(jié)果集合會(huì)隨機(jī)分布到 reduce 中， 每個(gè) reduce 做部分聚合操作，并輸出結(jié)果。這樣處理的結(jié)果是，相同的 Group By Key 有可 能分發(fā)到不同的 reduce 中，從而達(dá)到負(fù)載均衡的目的；第二個(gè) MapReduce 任務(wù)再根據(jù)預(yù)處 理的數(shù)據(jù)結(jié)果按照 Group By Key 分布到 reduce 中（這個(gè)過(guò)程可以保證相同的 Group By Key

15、分布到同一個(gè) reduce 中），最后完成最終的聚合操作。4.6合并小文件我們知道文件數(shù)目小，容易在文件存儲(chǔ)端造成瓶頸，給 HDFS 帶來(lái)壓力，影響處理效率。對(duì)此，可以通過(guò)合并Map和Reduce的結(jié)果文件來(lái)消除這樣的影響。用于設(shè)置合并屬性的參數(shù)有： 是否合并Map輸出文件：hive.merge.mapfiles=true（默認(rèn)值為真） 是否合并Reduce 端輸出文件：hive.merge.mapredfiles=false（默認(rèn)值為假） 合并文件的大?。篽ive.merge.size.per.task=256*1000*1000（默認(rèn)值為 ）5.程序角度優(yōu)化5.1熟練使用SQL提高查詢(xún)熟練

16、地使用 SQL，能寫(xiě)出高效率的查詢(xún)語(yǔ)句。場(chǎng)景：有一張 user 表，為賣(mài)家每天收到表，user_id，ds（日期）為 key，屬性有主營(yíng)類(lèi)目，指標(biāo)有交易金額，交易筆數(shù)。每天要取前10天的總收入，總筆數(shù)，和最近一天的主營(yíng)類(lèi)目。 解決方法 1如下所示：常用方法INSERT OVERWRITE TABLE t1 SELECTuser_id,substr(MAX(CONCAT(ds,cat),9) AS main_cat) FROM users WHERE ds=/ 為日期列的值，實(shí)際代碼中可以用函數(shù)表示出當(dāng)天日期 GROUPBYuser_id; INSERT OVERWRITE TABLE t2 S

17、ELECTuser_id,sum(qty) AS qty,SUM(amt) AS amt FROM users WHERE ds BETWEENANDGROUPBYuser_idSELECT t1.user_id,t1.main_cat,t2.qty,t2.amt FROM t1 JOIN t2 ON t1.user_id=t2.user_id下面給出方法1的思路，實(shí)現(xiàn)步驟如下：第一步：利用分析函數(shù)，取每個(gè) user_id 最近一天的主營(yíng)類(lèi)目，存入臨時(shí)表 t1。第二步：匯總 10 天的總交易金額，交易筆數(shù)，存入臨時(shí)表 t2。第三步：關(guān)聯(lián) t1，t2，得到最終的結(jié)果。解決方法 2如下所示：優(yōu)化方

18、法SELECTuser_id,substr(MAX(CONCAT(ds,cat),9) AS main_cat,SUM(qty),SUM(amt) FROM users WHERE ds BETWEENANDGROUPBYuser_id在工作中我們總結(jié)出：方案 2 的開(kāi)銷(xiāo)等于方案 1 的第二步的開(kāi)銷(xiāo)，性能提升，由原有的 25 分鐘完成，縮短為 10 分鐘以?xún)?nèi)完成。節(jié)省了兩個(gè)臨時(shí)表的讀寫(xiě)是一個(gè)關(guān)鍵原因，這種方式也適用于 Oracle 中的數(shù)據(jù)查找工作。SQL 具有普適性，很多 SQL 通用的優(yōu)化方案在 Hadoop 分布式計(jì)算方式中也可以達(dá)到效果。5.2無(wú)效ID在關(guān)聯(lián)時(shí)的數(shù)據(jù)傾斜問(wèn)題問(wèn)題：日志中

19、常會(huì)出現(xiàn)信息丟失，比如每日約為 20 億的全網(wǎng)日志，其中的 user_id 為主 鍵，在日志收集過(guò)程中會(huì)丟失，出現(xiàn)主鍵為 null 的情況，如果取其中的 user_id 和 bmw_users 關(guān)聯(lián)，就會(huì)碰到數(shù)據(jù)傾斜的問(wèn)題。原因是 Hive 中，主鍵為 null 值的項(xiàng)會(huì)被當(dāng)做相同的 Key 而分配進(jìn)同一個(gè)計(jì)算 Map。解決方法 1：user_id 為空的不參與關(guān)聯(lián)，子查詢(xún)過(guò)濾 nullSELECT*FROMlog a JOIN bmw_users b ON a.user_idISNOTNULLAND a.user_id=b.user_idUNIONAllSELECT*FROMlog a WH

20、ERE a.user_idISNULL解決方法 2 如下所示：函數(shù)過(guò)濾 nullSELECT*FROMlog a LEFTOUTERJOIN bmw_users b ONCASEWHEN a.user_idISNULLTHEN CONCAT(dp_hive,RAND() ELSE a.user_idEND=b.user_id;調(diào)優(yōu)結(jié)果：原先由于數(shù)據(jù)傾斜導(dǎo)致運(yùn)行時(shí)長(zhǎng)超過(guò) 1 小時(shí)，解決方法 1 運(yùn)行每日平均時(shí)長(zhǎng) 25 分鐘，解決方法 2 運(yùn)行的每日平均時(shí)長(zhǎng)在 20 分鐘左右。優(yōu)化效果很明顯。我們?cè)诠ぷ髦锌偨Y(jié)出：解決方法2比解決方法1效果更好，不但I(xiàn)O少了，而且作業(yè)數(shù)也少了。解決方法1中l(wèi)og讀取

21、兩次，job 數(shù)為2。解決方法2中 job 數(shù)是1。這個(gè)優(yōu)化適合無(wú)效 id（比如-99、 ，null 等）產(chǎn)生的傾斜問(wèn)題。把空值的 key 變成一個(gè)字符串加上隨機(jī)數(shù)，就能把傾斜的 數(shù)據(jù)分到不同的Reduce上，從而解決數(shù)據(jù)傾斜問(wèn)題。因?yàn)榭罩挡粎⑴c關(guān)聯(lián)，即使分到不同 的 Reduce 上，也不會(huì)影響最終的結(jié)果。附上 Hadoop 通用關(guān)聯(lián)的實(shí)現(xiàn)方法是：關(guān)聯(lián)通過(guò)二次排序?qū)崿F(xiàn)的，關(guān)聯(lián)的列為 partion key，關(guān)聯(lián)的列和表的 tag 組成排序的 group key，根據(jù) pariton key分配Reduce。同一Reduce內(nèi)根據(jù)group key排序。5.3不同數(shù)據(jù)類(lèi)型關(guān)聯(lián)產(chǎn)生的傾斜問(wèn)題問(wèn)題

22、：不同數(shù)據(jù)類(lèi)型 id 的關(guān)聯(lián)會(huì)產(chǎn)生數(shù)據(jù)傾斜問(wèn)題。一張表 s8 的日志，每個(gè)商品一條記錄，要和商品表關(guān)聯(lián)。但關(guān)聯(lián)卻碰到傾斜的問(wèn)題。 s8 的日志中有 32 為字符串商品 id，也有數(shù)值商品 id，日志中類(lèi)型是 string 的，但商品中的 數(shù)值 id 是 bigint 的。猜想問(wèn)題的原因是把 s8 的商品 id 轉(zhuǎn)成數(shù)值 id 做 hash 來(lái)分配 Reduce， 所以字符串 id 的 s8 日志，都到一個(gè) Reduce 上了，解決的方法驗(yàn)證了這個(gè)猜測(cè)。解決方法：把數(shù)據(jù)類(lèi)型轉(zhuǎn)換成字符串類(lèi)型SELECT*FROM s8_log a LEFTOUTERJOIN r_auction_auctions

23、b ON a.auction_id=CASE(b.auction_id AS STRING)調(diào)優(yōu)結(jié)果顯示：數(shù)據(jù)表處理由 1 小時(shí) 30 分鐘經(jīng)代碼調(diào)整后可以在 20 分鐘內(nèi)完成。5.4利用Hive對(duì)UNION ALL優(yōu)化的特性多表 union all 會(huì)優(yōu)化成一個(gè) job。問(wèn)題：比如推廣效果表要和商品表關(guān)聯(lián)，效果表中的 auction_id 列既有 32 為字符串商 品 id，也有數(shù)字 id，和商品表關(guān)聯(lián)得到商品的信息。解決方法：Hive SQL 性能會(huì)比較好SELECT*FROM effect a JOIN (SELECT auction_id AS auction_id FROM auct

24、ions UNIONAllSELECT auction_string_id AS auction_id FROM auctions) b ON a.auction_id=b.auction_id比分別過(guò)濾數(shù)字 id，字符串 id 然后分別和商品表關(guān)聯(lián)性能要好。這樣寫(xiě)的好處：1 個(gè) MapReduce 作業(yè)，商品表只讀一次，推廣效果表只讀取一次。把 這個(gè) SQL 換成 Map/Reduce 代碼的話，Map 的時(shí)候，把 a 表的記錄打上標(biāo)簽 a，商品表記錄 每讀取一條，打上標(biāo)簽 b，變成兩個(gè)對(duì)，。所以商品表的 HDFS 讀取只會(huì)是一次。5.5解決Hive對(duì)UNION ALL優(yōu)化的短板Hive 對(duì)

25、 union all 的優(yōu)化的特性：對(duì) union all 優(yōu)化只局限于非嵌套查詢(xún)。 消滅子查詢(xún)內(nèi)的 group by示例 1：子查詢(xún)內(nèi)有 group bySELECT*FROM (SELECT*FROM t1 GROUPBY c1,c2,c3 UNIONALLSELECT*FROM t2 GROUPBY c1,c2,c3)t3 GROUPBY c1,c2,c3從業(yè)務(wù)邏輯上說(shuō)，子查詢(xún)內(nèi)的 GROUP BY 怎么都看顯得多余（功能上的多余，除非有 COUNT(DISTINCT)），如果不是因?yàn)?Hive Bug 或者性能上的考量（曾經(jīng)出現(xiàn)如果不執(zhí)行子查詢(xún) GROUP BY，數(shù)據(jù)得不到正確的結(jié)果的

26、 Hive Bug）。所以這個(gè) Hive 按經(jīng)驗(yàn)轉(zhuǎn)換成如下所示：SELECT*FROM (SELECT*FROM t1 UNIONALLSELECT*FROM t2)t3 GROUPBY c1,c2,c3調(diào)優(yōu)結(jié)果：經(jīng)過(guò)測(cè)試，并未出現(xiàn) union all 的 Hive Bug，數(shù)據(jù)是一致的。MapReduce 的 作業(yè)數(shù)由 3 減少到 1。t1 相當(dāng)于一個(gè)目錄，t2 相當(dāng)于一個(gè)目錄，對(duì) Map/Reduce 程序來(lái)說(shuō)，t1，t2 可以作為 Map/Reduce 作業(yè)的 mutli inputs。這可以通過(guò)一個(gè) Map/Reduce 來(lái)解決這個(gè)問(wèn)題。Hadoop 的 計(jì)算框架，不怕數(shù)據(jù)多，就怕作業(yè)

27、數(shù)多。但如果換成是其他計(jì)算平臺(tái)如 Oracle，那就不一定了，因?yàn)榘汛蟮妮斎氩鸪蓛蓚€(gè)輸入， 分別排序匯總后 merge（假如兩個(gè)子排序是并行的話），是有可能性能更優(yōu)的（比如希爾排 序比冒泡排序的性能更優(yōu)）。 消滅子查詢(xún)內(nèi)的 COUNT(DISTINCT)，MAX，MIN。SELECT*FROM (SELECT*FROM t1 UNIONALLSELECT c1,c2,c3 COUNT(DISTINCT c4) FROM t2 GROUPBY c1,c2,c3) t3 GROUPBY c1,c2,c3;由于子查詢(xún)里頭有 COUNT(DISTINCT)操作，直接去 GROUP BY 將達(dá)不到業(yè)務(wù)目

28、標(biāo)。這時(shí)采用 臨時(shí)表消滅 COUNT(DISTINCT)作業(yè)不但能解決傾斜問(wèn)題，還能有效減少 jobs。INSERT t4 SELECT c1,c2,c3,c4 FROM t2 GROUPBY c1,c2,c3; SELECT c1,c2,c3,SUM(income),SUM(uv) FROM (SELECT c1,c2,c3,income,0AS uv FROM t1 UNIONALLSELECT c1,c2,c3,0AS income,1AS uv FROM t2) t3 GROUPBY c1,c2,c3;job 數(shù)是 2，減少一半，而且兩次 Map/Reduce 比 COUNT(DIST

29、INCT)效率更高。調(diào)優(yōu)結(jié)果：千萬(wàn)級(jí)別的類(lèi)目表，member 表，與 10 億級(jí)得商品表關(guān)聯(lián)。原先 1963s 的任務(wù)經(jīng)過(guò)調(diào)整，1152s 即完成。 消滅子查詢(xún)內(nèi)的 JOINSELECT*FROM (SELECT*FROM t1 UNIONALLSELECT*FROM t4 UNIONALLSELECT*FROM t2 JOIN t3 ON t2.id=t3.id) x GROUPBY c1,c2;上面代碼運(yùn)行會(huì)有 5 個(gè) jobs。加入先 JOIN 生存臨時(shí)表的話 t5，然后 UNION ALL，會(huì)變成 2 個(gè) jobs。INSERT OVERWRITE TABLE t5 SELECT*FR

30、OM t2 JOIN t3 ON t2.id=t3.id; SELECT*FROM (t1 UNIONALL t4 UNIONALL t5);調(diào)優(yōu)結(jié)果顯示：針對(duì)千萬(wàn)級(jí)別的廣告位表，由原先 5 個(gè) Job 共 15 分鐘，分解為 2 個(gè) job 一個(gè) 8-10 分鐘，一個(gè)3分鐘。5.6GROUP BY替代COUNT(DISTINCT)達(dá)到優(yōu)化效果計(jì)算 uv 的時(shí)候，經(jīng)常會(huì)用到 COUNT(DISTINCT)，但在數(shù)據(jù)比較傾斜的時(shí)候 COUNT(DISTINCT)會(huì)比較慢。這時(shí)可以嘗試用 GROUP BY 改寫(xiě)代碼計(jì)算 uv。 原有代碼INSERT OVERWRITE TABLE s_dw_tan

31、x_adzone_uv PARTITION (ds=) SELECTAS thedate,adzoneid,COUNT(DISTINCT acookie) AS uv FROM s_ods_log_tanx_pv t WHERE t.ds=GROUPBY adzoneid關(guān)于COUNT(DISTINCT)的數(shù)據(jù)傾斜問(wèn)題不能一概而論，要依情況而定，下面是我測(cè)試的一組數(shù)據(jù)：測(cè)試數(shù)據(jù)：條#統(tǒng)計(jì)每日IP CREATETABLE ip_2014_12_29 ASSELECTCOUNT(DISTINCT ip) AS IP FROM logdfs WHERE logdate=2014_12_29; 耗時(shí)：

32、24.805 seconds #統(tǒng)計(jì)每日IP（改造） CREATETABLE ip_2014_12_29 ASSELECTCOUNT(1) AS IP FROM (SELECTDISTINCT ip from logdfs WHERE logdate=2014_12_29) tmp; 耗時(shí)：46.833 seconds測(cè)試結(jié)果表名：明顯改造后的語(yǔ)句比之前耗時(shí)，這是因?yàn)楦脑旌蟮恼Z(yǔ)句有2個(gè)SELECT，多了一個(gè)job，這樣在數(shù)據(jù)量小的時(shí)候，數(shù)據(jù)不會(huì)存在傾斜問(wèn)題。6.優(yōu)化總結(jié)優(yōu)化時(shí)，把hive sql當(dāng)做mapreduce程序來(lái)讀，會(huì)有意想不到的驚喜。理解hadoop的核心能力，是hive優(yōu)化的根本。這是這一年來(lái)，項(xiàng)目組所有成員寶貴的經(jīng)驗(yàn)總結(jié)。 長(zhǎng)期觀察hadoop處理數(shù)據(jù)的過(guò)程，有幾個(gè)顯著的特征:. 不怕數(shù)據(jù)多，就怕數(shù)據(jù)傾斜。. 對(duì)jobs數(shù)