h開發(fā)者第四期

1、Hadoop 技術(shù)本期主編何忠育( Spork )Hadoop 開發(fā)者第四期編輯(若冰)( 一見 )(小米)( beyi )代志遠(yuǎn)(國(guó)寶)( 飛鴻雪泥)何忠育( Spork )秘中凱美工/封面設(shè)計(jì)何忠育 ( Spork )投稿信箱hadooporHadoop 開發(fā)者第四期刊首語(yǔ)刊首語(yǔ)Hadoop 開發(fā)者第四期，在千呼萬(wàn)，終于艱難的出來(lái)。這是眾多 Hadoopor期望的一期，也是相對(duì)成一期，本期的作者大多都具備在一線的 Hadoop 開發(fā)或應(yīng)用經(jīng)驗(yàn)，因此實(shí)踐性較強(qiáng)。在這里，我要特別感謝所有無(wú)私經(jīng)驗(yàn)的作者們，沒有的支持和奉獻(xiàn)就不可能有Hadoop 開發(fā)者第四期。本期排版工作忠育（Spork）擔(dān)當(dāng)，

2、在他的細(xì)心下，Hadoop 開發(fā)者第四期才得以與大家見面。Hadoop 開發(fā)者第四期的誕生是一個(gè)艱辛的過(guò)程，鮮有人樂意主動(dòng)撰稿，就好里，常有人發(fā)帖求助，但少有人主動(dòng)提供幫助。在征集到一期的稿件之后，又比遇到了編輯、排版和審核的問(wèn)題，大家都很忙，所以我要特別感謝Hadoop 開發(fā)者團(tuán)隊(duì)成員中的 Spork 同學(xué)主動(dòng)跳出來(lái)?yè)?dān)當(dāng)了排版工作，也要非常感謝同學(xué)一字一字地審核每篇文章，并將發(fā)現(xiàn)的問(wèn)題逐一標(biāo)出來(lái)。( 若冰 )雖然我們?nèi)院軜I(yè)余，但不管怎樣，Hadoop 開發(fā)者第四期出來(lái)了，問(wèn)題雖然很多，但仍希望可以給每一位 Hadoopor 帶來(lái)一絲幫助，更希望有的行列、開源的行列。的技術(shù)者加入Hadoop

3、技術(shù)站長(zhǎng)：一見Hadoop 開發(fā)者第四期目 錄目 錄mooon1海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變4計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法15Join 算子在 Hadoop 中的實(shí)現(xiàn)20配置 Hive 元數(shù)據(jù) DB 為 PostgreSQL32ZooKeeper 權(quán)限管理機(jī)制36ZooKeeper 服務(wù)器工作原理和流程39ZooKeeper 實(shí)現(xiàn)共享鎖47Hadoop 最佳實(shí)踐50通過(guò) Hadoop 的 API 管理 Job54Hadoop 集群的配置調(diào)優(yōu)60Hadoop 平臺(tái)的 Java 規(guī)范及經(jīng)驗(yàn)63MapReduce 開發(fā)經(jīng)驗(yàn)總結(jié)67Hadoop 中的 tar 命令的實(shí)現(xiàn)70Hadoop 技術(shù)運(yùn)

4、營(yíng)數(shù)據(jù)92- I -Hadoop 開發(fā)者第四期mooonmooon一見*mooon 取名為“飛越”或“飛月”的意思，也可叫“非月”，但非 moon。在 2009 年，我對(duì) Hadoopmapreduce 源代碼進(jìn)行了一段時(shí)間的系統(tǒng)化分析，在這個(gè)過(guò)數(shù)據(jù)傾斜和并行調(diào)度，并探索出一些解決方案。有點(diǎn)想將，發(fā)覺 mapreduce 存在兩大問(wèn)題：的想法付諸實(shí)踐，但重實(shí)現(xiàn)一個(gè)mapreduce 的工作量是非常大的，而且還依賴于分布式文件系統(tǒng)。我決定動(dòng)手去做一些工作，但我不想僅僅奔著這個(gè)目標(biāo)而來(lái)，而是希望每一點(diǎn)都能做到盡可能的多復(fù)用，按層劃分是一個(gè)比較好的 主意。mooon 中的每一點(diǎn)每一步都結(jié)合了我近 1

5、0 年來(lái)的開發(fā)實(shí)踐，特別是多年的分布系式統(tǒng)開發(fā)經(jīng)驗(yàn)，但 mooon參照任何一個(gè)現(xiàn)存的系統(tǒng)去做，而是由目標(biāo)驅(qū)動(dòng)。在這過(guò)會(huì)利用一些開源，并以的形式存在，如 plugin_tinyxml 方式，盡量保持第代碼的性，這即是對(duì)他人勞動(dòng)成果的尊重，也是避免系統(tǒng)臃腫的必要舉措。本文將分四點(diǎn)對(duì) mooon 做一個(gè)簡(jiǎn)單介紹，希望能對(duì)您了解 mooon 起到一點(diǎn)幫助作用：一、優(yōu)勢(shì)和特點(diǎn)作者簡(jiǎn)介：，零二年畢業(yè)于湘潭工學(xué)院，曾就職于長(zhǎng)沙創(chuàng)智、金山和。工作前半年的時(shí)間主要從事 VC/Delphi 開發(fā)，后轉(zhuǎn)入 Linux/C+開發(fā)。鐘情于軟件技術(shù)，多年不減，在 2009 年發(fā)起開源項(xiàng)目“飛月”。擅長(zhǎng)軟件架構(gòu)設(shè)計(jì)，代碼編

6、寫嚴(yán)謹(jǐn)，重視軟件的可測(cè)試性、可觀察性和可運(yùn)營(yíng)，重視代碼的用戶體驗(yàn)。掌握方法重要，領(lǐng)悟思想方為根本， 方式：eyjian at面向?qū)ο蠛驮O(shè)計(jì)模式等方法，“簡(jiǎn)單”才是最為精髓的思想。.com- 1 -Hadoop 開發(fā)者第四期mooon二、分層結(jié)構(gòu)三、基礎(chǔ)類庫(kù)四、公共組件- 2 -Hadoop 開發(fā)者第四期mooon五、分布式平臺(tái)Mooon 的源代碼放在是：些情況。Code上，可通過(guò) SVN，或直接在瀏覽器上查看， 上輸出 mooon 的一。同時(shí)，我也會(huì)在- 3 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變*新入職的小 Q 懵懵懂懂，誤打誤撞踏上了數(shù)據(jù)分析的康莊大道

7、，上班第一天，聽說(shuō)師（王 sir）是鼎鼎大名的數(shù)據(jù)分析王、業(yè)界泰斗，雞凍不已，欣喜之情溢于言表。的導(dǎo)王 sir 果然是位大牛，大會(huì)小會(huì)開個(gè)不停。小 Q 來(lái)了一上午，只和王 sir 打了個(gè)照面，就再?zèng)]見著他的。剛來(lái)也沒人指導(dǎo)，小 Q 有點(diǎn)不知所措，于是，翻開帶來(lái)的破舊的互聯(lián)網(wǎng)數(shù)據(jù)分析專業(yè)書，溫習(xí)下基礎(chǔ)知識(shí)：行為以 apach 日志的形式一般把用戶的關(guān)鍵字段：client_ip user_id access_time urlreferer status page_sizeagent下來(lái)了，這些日志中包含了下面一些因?yàn)樾枰y(tǒng)一對(duì)數(shù)據(jù)進(jìn)行離線計(jì)算，所以常常把它們?nèi)恳频酵粋€(gè)地方。簡(jiǎn)單算了一下：（1）

8、（2）（3）請(qǐng)求數(shù)：1kw/天每天日志大小：450Byte/行 * 1kw = 4.2G， 日志周期：2 年一天產(chǎn)生 4.5G 的日志，2 年需要 4.2G * 2 * 365 = 3.0T為了方便系統(tǒng)命令查看日志，不壓縮，總共需要 3.0T 的空間，剛好有一些 2U 的服務(wù)器，每臺(tái)共 1T 的磁盤空間，為了避免系統(tǒng)盤壞掉影響服務(wù)器使用，對(duì)系統(tǒng)盤做了 raid1；為了避免其他存放數(shù)據(jù)的盤壞掉導(dǎo)致數(shù)據(jù)無(wú)法恢復(fù)，對(duì)剩下的盤做了 raid5。做完 raid 后，除去系統(tǒng)盤的空間，每臺(tái)服務(wù)器你大概還有 800G 可以用于數(shù)據(jù)。先裝滿一臺(tái)，再順序裝下一臺(tái)，有浪費(fèi)，可以滿足需要，先放到這里來(lái)吧。于是所有的

9、數(shù)據(jù)都匯聚到這幾臺(tái) LogBackup 服務(wù)器上來(lái)了。數(shù)據(jù)從四個(gè)地區(qū)的 Collector 服務(wù)器上，跨 IDC 傳輸?shù)?LogBackup 服務(wù)器上，因?yàn)閯偲鸩?，你偷了個(gè)懶，直接使用 rsync 進(jìn)行傳輸，把傳輸模塊的開發(fā)也給省下了。有了 LogBackup 服務(wù)器，離線統(tǒng)計(jì)就可以全部在這些服務(wù)器上進(jìn)行了。在這套架構(gòu)上，用 wc、作者簡(jiǎn)介：jamesqin( 化、流程化建設(shè)。方式：jamesqin at)，負(fù)責(zé)各種運(yùn)營(yíng)支撐和管理平臺(tái)的架構(gòu)及開發(fā)，致力于運(yùn)維支撐體系的數(shù)據(jù)化、自動(dòng)vi- 4 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變grep、sort、uniq、awk、sed 等系統(tǒng)

10、命令，完成了很多的統(tǒng)計(jì)需求，比如統(tǒng)計(jì)頻率較高的 client_ip，某個(gè)新上線的的頁(yè)面的 referer 主要是哪些。嗯，不錯(cuò)，如果問(wèn)起這個(gè)的一些數(shù)據(jù)，回答起來(lái)絕對(duì)是游刃有余。_看書看得小有成就的小 Q 暗自竊喜，這時(shí)候王 sir 走過(guò)來(lái)關(guān)心下徒弟，小 Q 一激動(dòng)，就把的東東向王 sir 匯報(bào)了一番。王 sir 邊聽邊點(diǎn)點(diǎn)頭，稱贊小 Q 懂的還真不少??！“如果你的數(shù)據(jù)量再翻 10 倍，達(dá)到日志總行數(shù) 1 億/天，這個(gè)架構(gòu)還能支撐嗎？”“這個(gè)，這”突然一問(wèn)，問(wèn)懵了小 Q，露餡了不是? 小 Q 趕緊認(rèn)了，“這個(gè)還真不知道，求師傅詳解?！蓖?sir 看這徒弟如此積極好學(xué)，心里很是安慰，拿著筆在小 Q

11、 的筆記本上邊劃邊耐心講道。當(dāng)業(yè)務(wù)的迅猛發(fā)展就需要我們這些數(shù)據(jù)分析流量爆發(fā)增長(zhǎng)經(jīng)理如果想從中獲取的用戶特征和用戶信息，從不同的日志中找到令他們滿意的。如果（1）（2）（3）日志總行數(shù)：1 億/天每天日志大小：450Byte/行 * 1 億 = 42G， 日志種類：5 種那么之前采用的 LogBackup 服務(wù)器就會(huì)出現(xiàn)短板，雖然 LogBackup 服務(wù)器有空間不足的風(fēng)險(xiǎn)，但是它這樣單機(jī)，在一堆數(shù)據(jù)之中執(zhí)行一次 grep，都需要等上幾分鐘，串行操作直接導(dǎo)致性能瓶頸。這時(shí)候細(xì)心觀察 LogBackup 服務(wù)器上的 cpu 利用率數(shù)據(jù)，就會(huì)發(fā)現(xiàn)日志服務(wù)器大部分的時(shí)間都是閑置狀態(tài)，而一些臨時(shí)的 li

12、nux 命令或如下圖：運(yùn)行的時(shí)候，cpu 利用率也不高，從這里就可以找到點(diǎn)，LogBackup 服務(wù)器是 4 核 cpu，8G 內(nèi)存，8 塊 SAS 盤，RAID 方案為 2RAID1 + 6RAID5。2RAID1 一般用作系統(tǒng)盤，存放系統(tǒng)文件和用戶數(shù)據(jù)，日志數(shù)據(jù)就存放在那個(gè) RAID5 盤。因日志備份服務(wù)器一般為順序?qū)懭?，且寫入后修改或刪除，因此磁盤速度可以達(dá)到較高的順序速度。SAS 盤順序的平均速度為 110MB/s，6 個(gè)盤做 RAID 后，約有 550MB/s 的速度。下面是 RAID5 的工作原理圖：- 5 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變由此可見，RAID 技

13、術(shù)可以增大單個(gè)邏輯盤的容量，且具備了容錯(cuò)能力，由于使用了條帶方式，磁盤吞吐也較單盤有很大提升，這點(diǎn)和hadoop 的 HDFS 的可以和下圖的 HDFS 架構(gòu)圖對(duì)比一下：模型有異曲同工之妙，其中，RAID 卡就相當(dāng)于 HDFS 的 NameNode，整個(gè) RAID 盤就相當(dāng)于一個(gè)單機(jī)版的 HDFS。的物理磁盤就相當(dāng)于 HDFS 的 DataNode，既然多核 cpu 沒有吃滿，而 raid 盤的 IO 能力又這么強(qiáng)，那么提高的并發(fā)量就可以進(jìn)一步提升 cpu 的利用率。前面已經(jīng)提到，RAID 盤的 IO 能力比較高，成不平衡短板。因?yàn)椴l(fā)計(jì)算而在 IO 方面造另外，你注意到 HDFS 上的文件都

14、是分塊的，于是你的日志也需要分塊，好讓他們并發(fā)起來(lái)吧。樣，來(lái)自 4 個(gè)地區(qū)的日志文件，每隔 5 分鐘傳輸一次，每次都以的文件推送過(guò)來(lái)，這在 LogBackup 服務(wù)器上的日志就是打散的了（而不是一整個(gè)大文件）。這些文件存在在 RAID盤上，為后續(xù)用并發(fā)計(jì)算提供了基礎(chǔ)。你很快按照 MapReduce 的思路， 用 bash 實(shí)現(xiàn)了一個(gè)簡(jiǎn)易的并行計(jì)算框架， 起名為Bash-MapReduce。我們還是Hadoop 的 MapReduce 原理圖來(lái)說(shuō)明這個(gè)并發(fā)模型：- 6 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變我們對(duì)照上圖，結(jié)合一個(gè)例子來(lái)說(shuō)明，假設(shè)我們要計(jì)算某個(gè)一天的 PV，我們要計(jì)算

15、的全量數(shù)據(jù)（即 web 前端服務(wù)器一天切割成的 4 * 24 * 60 / 5 = 1152 個(gè)日志文件）如上圖Data 文件，因數(shù)據(jù)已經(jīng)分割在 1152 個(gè)文件中，就如上圖 Computer Cluster 中的DFS Block 1、DFS Block2，而我們的 Bash-MapReduce 框架，就是啟動(dòng) N 個(gè)進(jìn)程（一般地，N 取 cpu 個(gè)數(shù)的倍數(shù)，如 4 核 cpu，N 取 12），分別對(duì)各個(gè)文件（即各個(gè) DFS Block）進(jìn)行 PV 計(jì)算，每一個(gè)原始文件經(jīng)過(guò) map模塊后分別得到一個(gè)中間結(jié)果文件。Map 結(jié)束后，reduce 模塊把所有的中間結(jié)果收集起來(lái)，進(jìn)行歸并，得到最終的

16、結(jié)果（對(duì)應(yīng)于上圖的Results 文件）。從上圖也可以看到，并行模型中最重要的就是Map 模塊和 Reduce 模塊。Bash-MapReduce 框架就是提供了一個(gè)任務(wù)分發(fā)到進(jìn)程（Map）、中間結(jié)果歸并（Reduce）的架構(gòu)，具體的 Map 功能和Reduce 功能由用戶來(lái)編寫，其實(shí)就是寫兩個(gè)而已，這樣只需進(jìn)行簡(jiǎn)單的單文件計(jì)算編程，就可能獲得并發(fā)能力。需要注意的是，Map 模塊輸出的，必須是 key-value 類型的格式化數(shù)據(jù)。Bash-MapReduce 框架的并行模型圖如下所示：Bash-MapReduce 非常爭(zhēng)氣，把性能提高了好多倍，下圖是我們運(yùn)行 Bash-MapReduce 框

17、架進(jìn)行并行計(jì)算后的 cpu 利用率，4 個(gè) cpu 都已經(jīng)逼進(jìn)極限，而 IO 沒有造成瓶頸：有了這個(gè)簡(jiǎn)易的并行框架，以后小 case,so easy經(jīng)理那些個(gè)催命鬼再怎么催需求，幾秒就搞定他，呵呵，- 7 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變聽得云里霧里的小 Q 第一次親密接觸泰斗，短短幾分鐘，被他深入淺出的技術(shù)講解給震攝了，佩服得五體投地。王 sir 也從小 Q 朦朧的眼神中找到了強(qiáng)烈自豪感，呵呵，小成這樣，那后面的，嘿嘿，你懂的不知不覺，午飯時(shí)間到，王 sir 領(lǐng)著小 Q 去吃飯。飯局間，小 Q 為了怕冷場(chǎng)，又扯回到剛才討論的 MapReduce，對(duì)它的超強(qiáng)并發(fā)性贊不絕口。

18、王 sir 也想借此機(jī)會(huì)考驗(yàn)下小 Q 的反應(yīng)能力，問(wèn)了句：“凡事有利必有弊，有沒有考慮到它的弊呢？”一把就能把他整小 Q 撓撓頭，想了想，弱弱地問(wèn)道：“它每一個(gè)需求都需要去寫統(tǒng)計(jì)，統(tǒng)計(jì)邏輯是相同的，時(shí)間長(zhǎng)了，也就成了重復(fù)性的體力活，換個(gè)參數(shù)而已。我們是不是可以更智能點(diǎn)，讓查起來(lái)更方便 快捷呢？”王 sir 驚嘆小 Q 的靈性，太給力了，孺子可教也！于是，很興奮地講了一些領(lǐng)域特定語(yǔ)言（domain-specific languages，簡(jiǎn)稱 DSL） 方面的概念。LogBackup 服務(wù)器上的日志，一般都是經(jīng)過(guò)了初步格式化后，每行都是n 分隔，每列都是t 分隔。如果這些數(shù)據(jù)是存放在 MySQL

19、數(shù)據(jù)庫(kù)中的就好了，這樣很多統(tǒng)計(jì)就能用 SQL 來(lái)代替，比如前面提到的當(dāng)天次數(shù)做多的 ip 的 top10 榜單， 可以用“SELECT COUNT(1) AS pv FROMtb_mylog_20110302 GROUP BY client_ip ORDER BY pv DESC”統(tǒng)計(jì)出來(lái)。下一次需求變動(dòng)，如果只是更換一下日期，或者更換一下 GROUP BY 的字段，改 SQL 顯然比改 shell要簡(jiǎn)單得多。呵呵，不過(guò)呢，MySQL 是難以扛起“海量日志”這面大旗，SQL 的靈活性倒是挺，能不能開發(fā)一種類 SQL 的語(yǔ)言直接操作日志文件呢？想想，辦法總會(huì)有的：）當(dāng)被日復(fù)一日的簡(jiǎn)單重復(fù)折騰得家

20、不能回，通宵達(dá)旦筋疲力盡的時(shí)候，絕望中的一縷曙光照亮了整個(gè)黑夜，它就是 LogQL（Log Query Language）。LogQL 是一種專門用于日志統(tǒng)計(jì)的語(yǔ)言，它是一種領(lǐng)域特定語(yǔ)言（ DSL）， 什么是 DSL 呢？ 比如 AWK就是一種 DSL， 另外， 一些軟件為了增強(qiáng)應(yīng)用程序的配置能力，也會(huì)設(shè)計(jì)專門的語(yǔ)言。LogBackup 服務(wù)器上的幾種日志有固定格式，于是你開發(fā) LogQL 具備了前提條件。以一個(gè)統(tǒng)計(jì)需求為例，要設(shè)計(jì)的 LogQL 的語(yǔ)法是類似這樣的：/ 需求: 統(tǒng)計(jì)INIT FIELDS Referer; pv = 0;給我們的站點(diǎn)帶來(lái)多少 pv和/ 掃描到每一行都需要提取

21、referer 字段進(jìn)行分析/ 定義變量 pvINPUT DATE 20110212-20110214;TYPE 1;/ 選擇日志范圍/ 指定日志格式LINE_FILTER referer LIKE “%”- 8 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變AND (referrer LIKE “% OR referrer LIKE “%OR referrer LIKE “%” ”);LINE_STATpv = pv + 1; OUTPUTpv;/ 每一行經(jīng)過(guò) LINE_FILTER 后，都執(zhí)行此操作/ 輸出內(nèi)容，日志本身的 field 或定義的變量不經(jīng)一番寒徹骨，哪來(lái)梅花撲鼻香哦，熬

22、夜奮戰(zhàn)幾宿，基于 lex 和 yacc 把 LogQL 開發(fā)出來(lái)了，可以上面的小示例類似的語(yǔ)法，解決了絕大部分的統(tǒng)計(jì)需求。實(shí)用、高效，又省心，感謝 LogQL，讓我們專注于要提取的數(shù)據(jù)，而不是提取的邏輯，了我們這幫被催命鬼（經(jīng)理）的奴隸。呵呵，悲催吧誰(shuí)叫我們是數(shù)據(jù)分析者，傷得起嗎你？！起來(lái)，不愿做奴隸的人們被鬼催的感覺，痛不們。啊，我們要當(dāng)?shù)?，救世主就是我?dāng)被需求驅(qū)動(dòng)著，感覺很，不愿做需求響應(yīng)者，想翻身做需求管理者。于是搭建了一個(gè) web 前臺(tái)，寫了個(gè)網(wǎng)頁(yè)，讓每個(gè)人都可以從網(wǎng)頁(yè)提交 LogQL 到 LogBackup 服務(wù)器去執(zhí)行統(tǒng)計(jì)任務(wù)。另外，還稍上一份詳盡的 LogQL 的使用說(shuō)明，并召集

23、經(jīng)理進(jìn)行 LogQL 的使用培訓(xùn)，由于LogQL 是類 SQL 的語(yǔ)言，簡(jiǎn)單易用，立完成數(shù)據(jù)的統(tǒng)計(jì)與提取。經(jīng)理們很快掌握了你發(fā)明的 LogQL，并通過(guò)你的 web 前嗯嗯，不用再親自出馬，難得片刻閑，嘿嘿，喝杯咖啡，品一品這種久違的悠然自得的愜意 小 Q 望著師傅那一臉的自豪，對(duì)他的欽佩猶如滔滔江水連綿不絕，又如黃河泛濫一發(fā)不可收拾！“這么好用的 LogQL 我居然都沒聽說(shuō)過(guò)，簡(jiǎn)直太膚淺了”，這不比不知道，一比嚇幾跳，泰斗，果然名不虛傳吶。王 sir 看到小 Q 那傻乎乎一愣愣的表情，心里知道是咋回事，竊喜;) 不由得驚嘆呵呵，侃了半天，餓了，菜也涼了，還是邊吃邊聊（此處略去1萬(wàn)字）的功！小

24、Q 吃了差不多，請(qǐng)教師傅一個(gè)問(wèn)題：莫非 LogQL 就是江湖流傳上的“葵花寶典”？王 sir 大囧，口里的飯都快噴了捂嘴大笑，哈哈！興致來(lái)了，接上：做事就要做到極致，光憑 LogQL 這一把刷子，是遠(yuǎn)遠(yuǎn)不夠的：（1）（2）計(jì)算性能：LogQL 只能運(yùn)行在單機(jī)上，受到 cpu 限制，并發(fā)能力有限；內(nèi)存消耗：LogQL 只能運(yùn)行在單機(jī)上，受到內(nèi)存限制，做類似 DISTINCT 的時(shí)候，會(huì)導(dǎo)致大量數(shù)據(jù)積壓在內(nèi)存，最后導(dǎo)致語(yǔ)言引擎 core 掉；最典型的案例，就是統(tǒng)計(jì)UV 的時(shí)候，需要在內(nèi)存中維護(hù) user_id 的列表，那會(huì)讓內(nèi)存受到極大。（3）日志連續(xù)性：日志文件分布在多臺(tái)服務(wù)器上，存滿一臺(tái)，則存

25、下一臺(tái)。如果需要分析的日志剛好跨了兩臺(tái)，單機(jī)運(yùn)行的 LogQL 就傻眼了；- 9 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變（4）日志格式定義：LogQL 要支持新格式的日志，需要進(jìn)行一些配置，就好比 SQL 的 Create Table 一樣，只不過(guò)，在 LogQL 中進(jìn)行有點(diǎn)麻煩；迭代計(jì)算：有時(shí)候 LogQL 計(jì)算出來(lái)的數(shù)據(jù)，需要作為下一步的輸出，但是 LogQL 不支持管理中間數(shù)據(jù)；（5）（6）一下再輸出來(lái)，好比 SQL 中的 SUBSTR(access_time, 1,自定義函數(shù)：某些字段需要10)，很無(wú)奈，不支持。（7）LogQL 只支持對(duì)未壓縮的文本進(jìn)行統(tǒng)計(jì)，對(duì)磁盤空間的

26、占用是一個(gè)較大的?？嘞鹿﹄S口一說(shuō)，了 LogQL 的大把缺點(diǎn)，師傅也愁啊，小 Q 不忍心師傅這等郁悶，夫，經(jīng)常上 bbs ，求仙問(wèn)道。得知名師指點(diǎn)，一款名為 hive 的工具，灰常，把 LogQL 缺的地方全補(bǔ)上了。它是基于 Hadoop 的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫(kù)表，并提供完整的 sql功能，可以將 sql 語(yǔ)句轉(zhuǎn)換為 MapReduce 任務(wù)進(jìn)行運(yùn)行。學(xué)習(xí)成本低，可以通過(guò)類 SQL 語(yǔ)句快速實(shí)現(xiàn)簡(jiǎn)單的 MapReduce 統(tǒng)計(jì)，不必開發(fā)專門的 MapReduce應(yīng)用，十分適合數(shù)據(jù)倉(cāng)庫(kù)的統(tǒng)計(jì)分析。通過(guò)閱讀 hive 的 manual，現(xiàn)在能很申請(qǐng)到一些預(yù)算用于

27、 hadoop 平臺(tái)的搭建，按照上的操作手冊(cè)，可以很快把集群搭建起來(lái)，現(xiàn)在是考慮遷移到 hadoop 平臺(tái)的時(shí)候了。接下來(lái)，Hadoop 平臺(tái)搭建后的第一件事情，就是數(shù)據(jù)遷移?？紤]到日志的安全性，日志備份機(jī)還是需要繼續(xù)保留，以便有需要的時(shí)候取出；考慮到日常的統(tǒng)計(jì)分析需求處理的日志一般都在最近的 60 天，因此最近的 60 天日志可以放到 hadoop 平臺(tái)中進(jìn)行及計(jì)算；考慮到 MapReduce 編程的易操作性，使用 hive 對(duì) hadoop 平臺(tái)上的數(shù)據(jù)進(jìn)行管理。因此，既然 hadoop 平臺(tái)于并行計(jì)算，而 LogBackup于備份，那么 LogBackup 仍需保留。因?yàn)?hadoop

28、能自動(dòng)識(shí)別壓縮文件，使用 gzip 對(duì)日志文件進(jìn)行壓縮，默認(rèn)的壓縮級(jí)別，壓縮比可以達(dá)到 5：1，為了節(jié)省空間及網(wǎng)絡(luò)帶寬，日志文件在 Collector 服務(wù)器直接壓縮，一式兩份，一份傳給 LogBackup 服務(wù)器，一份傳給 hadoop 集群。然后你可以通過(guò) hive 客戶端，創(chuàng)建 external表來(lái)管理這些格式化的日志。CREATE EXTERNALclient_ip user_id access_time urlreferer status page_sizeagentTABLE IF NOT EXISTS tb_weblog ( STRING,STRING, STRING, STRI

29、NG, STRING, INT, INT,STRING)PARTITIONED BYROW FORMAT(statdate STRING, channel STRING)DELIMITED FIELDS TERMINATED BY 't'LOCATION '/user/dw/weblog'其中，statdate 是當(dāng)天的日期，格式為“YYYYMMDD”；channel 是頻道名稱，因?yàn)槟愕挠兄黝l道、頻道、博客頻道等，進(jìn)行頻道切分有助于后續(xù)按頻道進(jìn)行有性的流量分析。借助于 hive，進(jìn)行日志統(tǒng)計(jì)就非常簡(jiǎn)單，比如我們要處理這樣一個(gè)需求：計(jì)算 1 月份各頻道每- 10

30、 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變天的回彈率，其中，回彈率=回彈用戶數(shù)/總用戶數(shù)，回彈用戶定義為 pv=1 的那些用戶。輸出的形式“日期 頻道名 回彈率”。這個(gè)需求的目的是想了解各頻道對(duì)用戶吸引力如何。根據(jù)需求，我們需要分別統(tǒng)計(jì)當(dāng)天 pv=1 的用戶數(shù)和當(dāng)天總用戶數(shù)，很明顯我們需要統(tǒng)計(jì)每個(gè)用戶每天的 pv 數(shù)，在此基礎(chǔ)上才能提取到 pv=1 的用戶數(shù)。為了簡(jiǎn)化操作，我們需要先建立一張中間表：用戶行為寬表。有了這，以后用戶級(jí)別的需求都可以基于此寬表進(jìn)行。這結(jié)構(gòu)設(shè)計(jì)如下：CREATE EXTERNALuser_id channel pvTABLEIF NOT EXISTS tb

31、_weblog_user ( STRING,STRING,INT)PARTITIONED BY (statdate STRING) CLUSTERED BY(suid) INTO 8 BUCKETSROW FORMAT DELIMITED FIELDS TERMINATED BY 't'LOCATION '/user/dw/tb_weblog_user'我們期待這按天生成，內(nèi)容類似下面：hive> select * from tb_weblog_user where statdate='20110101' limit 10;OK100038

32、929610004083410016147081002153202100220578110024591591002495573100256716810026161181002647394www www image news news www blog blog newsimage321313123220110101201101012011010120110101201101012011010120110101201101012011010120110101，逐天把數(shù)據(jù)跑出來(lái)建好表結(jié)構(gòu)之后，我們寫一個(gè)#!/bin/sh function init()export exportexportHADO

33、OP_HOME=/usr/local/hadoop HIVE_HOME=/usr/local/hivePATH=$PATH:$HADOOP_HOME/bin:$HIVE_HOME/binfunction do_one_day()local _date=$1hql="ALTER TABLE tb_weblog_user ADD PARTITION (statdate='$_date') LOCATION '/user/dw/tb_weblog_user/$_date'"hive -e "$hql"hql="INSE

34、RT OVERWRITE TABLE tb_weblog_user PARTITION(statdate='$_date')- 11 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變SELECT user_id,channel,COUNT(1) AS pv FROM tb_weblog WHERE statdate = '$_date' GROUP BY statdate,channel,user_id"hive -e "$hql"Initfor the_day in seq -w 1 31 dodo_one_day 20110

35、1$the_daydone這個(gè)的邏輯有幾個(gè)關(guān)鍵點(diǎn)：1、對(duì)于每天，用戶寬表都需要增加分區(qū) statdate，這個(gè)是建表的時(shí)候規(guī)定的；2、從原始的tb_weblog_user 中。流量數(shù)據(jù)表 tb_weblog 中進(jìn)行，把匯總結(jié)果充入到我們的用戶寬表有了用戶寬表，我們?cè)倩剡^(guò)頭來(lái)統(tǒng)計(jì)回彈用戶率這個(gè)需求，那就輕而易舉了。SELECT channel, IF(pv=1, 1, 0) AS reject_uv, COUNT(1) AS uv FROM tb_weblog_userWHERE statdate like '201101%'GROUP BY statdate, channel;

36、輸出的結(jié)果是“頻道名 回彈用戶數(shù) 當(dāng)天用戶數(shù) 統(tǒng)計(jì)日期”的格式，從開發(fā)到數(shù)據(jù)統(tǒng)計(jì)完畢， 幾分鐘就可以完成，非常方便。如果我們使用以前的方式，使用常規(guī)的編程語(yǔ)言來(lái)開發(fā)實(shí)現(xiàn)，恐怕在開發(fā)上需要耗費(fèi)的各種開銷會(huì)非?？捎^。這個(gè)需求實(shí)現(xiàn)的關(guān)鍵點(diǎn)在于中間表-用戶行為寬表的引入，試想，如果需求中“回彈用戶”的定義發(fā)生了改變，pv<=2 的用戶都算入回彈用戶，那我們需要修改的，僅僅是那個(gè)基于寬表提取數(shù)據(jù)的 SQL，影響不大。鑒于原始的流水表數(shù)據(jù)量太大，而中間表在這次統(tǒng)計(jì)需求中發(fā)揮了很重要的作用，你很自然的想到，原始流水表進(jìn)行一個(gè)初步的匯總，會(huì)后續(xù)的統(tǒng)計(jì)分析是非常有幫助的。于是，類似用戶行為寬表，你根據(jù)日常

37、的需求，擴(kuò)展了寬表，上百個(gè)字段的寬表也是常有的事。在時(shí)間維度上也增加了一些新的寬表，如用戶、月寬表，這樣就能很方便對(duì)各種周期的數(shù)據(jù)進(jìn)行總覽，這些寬表一次生成，多次使用，因?yàn)槭菂R總數(shù)據(jù)，規(guī)模比流水表小了不少，流水表一般是一月一刪， 而匯總數(shù)據(jù)體積小，可以保留更長(zhǎng)的時(shí)間。同時(shí)也避免了臨時(shí)數(shù)據(jù)提取時(shí)產(chǎn)生的計(jì)算消耗，從而提高了數(shù)據(jù)提取的效率。支持類 SQL 語(yǔ)法的計(jì)算平臺(tái)和寬表概念的出現(xiàn)是一個(gè)很重要的轉(zhuǎn)折點(diǎn)，開發(fā)開始從重復(fù)性的數(shù)據(jù)提取工作中脫離出來(lái)，有的時(shí)間去透過(guò)數(shù)據(jù)思考業(yè)務(wù)，數(shù)據(jù)工作從面向數(shù)據(jù)，開始轉(zhuǎn)向面向業(yè)務(wù)。工作思路和方法上，都有很多轉(zhuǎn)變。一開始在 hive 上執(zhí)行的任務(wù)不多，也都比較簡(jiǎn)單，我們

38、在linux 下簡(jiǎn)單的使用 shell進(jìn)行開發(fā)，再使用 crontab 來(lái)定時(shí)啟動(dòng)，基本上都能滿足需要。但是由于日志量大小變化及 hadoop集群的性能等因素影響，同一個(gè) hive 任務(wù)的每次執(zhí)行耗時(shí)并不固定，如果寫死在 crontab 中的定時(shí)任務(wù)的啟動(dòng)時(shí)間安排不得當(dāng)，很容易導(dǎo)致下一個(gè)定時(shí)任務(wù)啟動(dòng)了，但它所依賴的上一個(gè)定時(shí)任務(wù)的- 12 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變輸出結(jié)果還沒有生成，進(jìn)而導(dǎo)致該任務(wù)執(zhí)行失敗。更糟糕的是，后續(xù)還有一大堆任務(wù)依賴該任務(wù)的輸出結(jié)果（中間寬表），并且都是定時(shí)執(zhí)行的，于是紛紛執(zhí)行失敗，出現(xiàn)了可怕的多米諾骨牌效應(yīng)。最常見的情況是，我們每天早上 1

39、0 點(diǎn)前會(huì)從寬表中提取一些數(shù)據(jù)，作為日?qǐng)?bào)郵件發(fā)出。前一天的數(shù)據(jù)最早頂多凌晨 0 點(diǎn)就緒，到 10 點(diǎn)必須生成寬表，集群的工作時(shí)間只有 10 個(gè)小時(shí)。為了避免前面提及的多米諾骨牌效應(yīng)，在任務(wù)少的時(shí)候，我們可以通過(guò)適當(dāng)拉寬任務(wù)的定時(shí)啟 動(dòng)的時(shí)間間隔來(lái)保證每一個(gè)環(huán)節(jié)都有充足的時(shí)間完成計(jì)算任務(wù)，但是在任務(wù)較多的情況下，任務(wù)排期就會(huì)出現(xiàn)。另外，任務(wù)之間有依賴關(guān)系， crontab 并不是一個(gè)很好的管理任務(wù)間依賴關(guān)系的工具。除了依賴關(guān)系管理，我們還需要失敗重試、告警通知。當(dāng)然，把這些需求留給 crontab 似乎太過(guò)苛刻，因此我們?cè)O(shè)計(jì)一個(gè)任務(wù)調(diào)度系統(tǒng)，統(tǒng)一對(duì)計(jì)算任務(wù)進(jìn)行管理。結(jié)合前面遇到的問(wèn)題，我們一起來(lái)

40、梳理一下，任務(wù)調(diào)度系統(tǒng)需要提供哪些特性呢？梳理一下，列個(gè)：用不嚴(yán)謹(jǐn)?shù)墓ぷ髁鞒毯痛植诘挠?jì)算邏輯來(lái)提供的數(shù)據(jù)，是非常的，因?yàn)檫\(yùn)維故障隨處可見，磁盤可能損壞、服務(wù)器可能、機(jī)架可能斷電、機(jī)房可能著火、網(wǎng)絡(luò)可能癱瘓，各種不確定的因- 13 -NO.特性描述1擴(kuò)展能力提供水平擴(kuò)展能力，可動(dòng)態(tài)增加或減少任務(wù)數(shù)量，并調(diào)整任務(wù)之間的依 賴關(guān)系；2并行能力對(duì)于已經(jīng)滿足依賴條件的任務(wù)，能一定數(shù)量的任務(wù)進(jìn)入執(zhí)行狀態(tài)， 防止并發(fā)過(guò)高壓垮集群，也避免串行執(zhí)行，不能充分發(fā)揮集群的性能3前置檢查提交自定義 ，編寫自定義的條件檢查是否滿足任務(wù)執(zhí)行條件。比如任務(wù)運(yùn)行前需要通過(guò)檢查前一天的數(shù)據(jù)是否齊全，可以約定數(shù)據(jù)傳 輸完畢后，

41、個(gè)check文件，則前置檢查 則只需簡(jiǎn)單檢查check 文件存在與否，便知數(shù)據(jù)完整性；4重試機(jī)制任務(wù)執(zhí)行失敗時(shí)，提供錯(cuò)誤重試機(jī)制， 數(shù)內(nèi)重試不 需要告警。有時(shí)候hadoop集群并行處理的任務(wù)較多，會(huì)導(dǎo)致臨時(shí)文件撐滿datanode， 這種情況下一般重試會(huì)湊效；5提交自動(dòng)以 ，用于任務(wù)異常終止。某些任務(wù)執(zhí)行過(guò) 需要建立臨時(shí)表， 些中間數(shù)據(jù)，如果任務(wù)異常 ，則臨時(shí)表、中間數(shù)據(jù)就會(huì)成為 ，調(diào)度系統(tǒng)需要負(fù)責(zé) ；6性能每個(gè)任務(wù)的啟動(dòng)時(shí)間、完成時(shí)間、執(zhí)行狀態(tài)、執(zhí)行耗時(shí)均做 ，對(duì)于耗時(shí)超過(guò)設(shè)置值的需要告警。除了告警 的用途外，通過(guò)耗時(shí) ， 也可以直觀的找到耗時(shí)大戶，進(jìn)行任務(wù)性能調(diào)優(yōu)的時(shí)候，這些耗時(shí)數(shù)據(jù) 將成

42、為重要的參考；7任務(wù)提供定時(shí)調(diào)度、手工調(diào)度兩種 方式。其中，手工調(diào)度是指能通過(guò)前臺(tái)頁(yè)面 任務(wù)的start、stop、restart操作。在調(diào)試任務(wù)、重跑數(shù)據(jù)、手工恢復(fù)數(shù)據(jù)等場(chǎng)合都會(huì)用到該功能；8依賴管理能描述任務(wù)間的依賴關(guān)系，保證任務(wù)按照依賴性的先后順序進(jìn)行調(diào)度。 如果某個(gè)節(jié)點(diǎn)任務(wù)執(zhí)行失敗，系統(tǒng)自動(dòng)取消所有依賴于該節(jié)點(diǎn)的后續(xù)任 務(wù)，并調(diào)用告警機(jī)制。比如日寬表計(jì)算失敗，則當(dāng)日的日?qǐng)?bào)郵件能停發(fā) 或改發(fā)故障通知，而不是 攜帶錯(cuò)誤數(shù)據(jù)空白數(shù)據(jù)的郵件；9柔性機(jī)制能標(biāo)注任務(wù)的重要級(jí)別，在集群 吃緊等情況下進(jìn)行服務(wù)降級(jí)，優(yōu)先保證重要任務(wù)的調(diào)度權(quán)。比如當(dāng)天日?qǐng)?bào)所依賴數(shù)據(jù)的運(yùn)算任務(wù)優(yōu)先級(jí)較 高，而月匯總表的運(yùn)算

43、任務(wù)可以降權(quán)；Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺(tái)架構(gòu)演變素太多，一旦出現(xiàn)故障，沒有任何防范措施的數(shù)據(jù)提取只能是提供錯(cuò)誤的數(shù)據(jù)，錯(cuò)誤的數(shù)據(jù)將信任，久而久之，不光數(shù)據(jù)服務(wù)部門喪失數(shù)據(jù)公，整日疲于做數(shù)據(jù)核查、數(shù)據(jù)恢復(fù)，也會(huì)成為消耗時(shí)間的苦差事。不過(guò)現(xiàn)在借助于任務(wù)調(diào)度系統(tǒng)，我們的任務(wù)管理能力將得到大大增強(qiáng)，現(xiàn) 在可以高枕無(wú)憂了。路慢慢其修遠(yuǎn)兮，吾將上下而求索，共勉！咆哮體后記：深夜，夜涼如水有！疲憊困睡！親！偶生噩夢(mèng)，真 BT 有發(fā)飆：把這些個(gè)數(shù)據(jù)在幾個(gè) hadoop 集群間飛會(huì)兒！好環(huán)躁??！又來(lái)一 SB 催命鬼：簡(jiǎn)單配置就實(shí)現(xiàn)數(shù)據(jù)在不同數(shù)據(jù)平臺(tái)間流轉(zhuǎn)??！哎，還要搞個(gè)通用數(shù)據(jù)傳輸模塊，有架構(gòu)演

44、變！永無(wú)止境，傷不起呀！你傷不起啊啊啊??！- 14 -Hadoop 開發(fā)者第四期計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法*一、 Hive 簡(jiǎn)介由于在數(shù)據(jù)處理領(lǐng)域的影響力以及 Hive 開源社區(qū)非?；钴S，Hive 慢慢的被國(guó)內(nèi)很多大型互聯(lián)網(wǎng)公司采用作為替代傳統(tǒng)關(guān)系型數(shù)據(jù)倉(cāng)庫(kù)的解決方案。本文主要介紹在 hive 使用過(guò)計(jì)算不均衡產(chǎn)生的，以及相應(yīng)的解決辦法。二、 Group By 中的計(jì)算均衡優(yōu)化1.1 Map 端部分聚合先看看下面這條 SQL，由于用戶的只有男和女兩個(gè)值。如果沒有 map 端的部分聚合優(yōu)化，map 直接把 groupby_key 當(dāng)作 red

45、uce_key給 reduce 做聚合，就會(huì)導(dǎo)致計(jì)算不均衡的現(xiàn)象。雖然 map 有 100 萬(wàn)個(gè)，但是 reduce 只有兩個(gè)在做聚合，每個(gè) reduce 處理 100 億條select user.gender,count(1) from user group by user.gender。沒開 map 端聚合產(chǎn)生的計(jì)算不均衡現(xiàn)象hive.map.aggr=true 參數(shù)在 group by 的時(shí)候是否 map 局部聚合，這個(gè)參數(shù)默認(rèn)是打開的。參數(shù)打開后的計(jì)算過(guò)程如下圖。由于 map 端已經(jīng)做了局部聚合，雖然還是只有兩個(gè) reduce 做最后的聚合，但是每個(gè) reduce 只用處理 100 萬(wàn)

46、行，相對(duì)優(yōu)化前的 100 億小了 1 萬(wàn)倍。作者簡(jiǎn)介：，目前從事分布式數(shù)據(jù)倉(cāng)庫(kù)技術(shù)架構(gòu)和開發(fā)工作，對(duì)hdfs+mapreduce+hive 的技術(shù)框架和源碼有深入的研究。積累了豐富的海量數(shù)據(jù)處理平臺(tái)和業(yè)務(wù)流程建設(shè)經(jīng)驗(yàn)。個(gè)人職業(yè)目標(biāo)是希望能成為國(guó)內(nèi)頂尖的云計(jì)算領(lǐng)域。方式：fiberlijun at - 15 -Hadoop 開發(fā)者第四期計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法map 端聚合打開map 聚合開關(guān)缺省是打開的，但是不是所有的聚合都需要這個(gè)優(yōu)化。考慮下面的 sql，如果groupby_key 是用戶 ID，因?yàn)橛脩?ID 沒有重復(fù)的，因此 map 聚合沒有太大意義，并且浪費(fèi)select

47、 user.id,count(1) from user group by user.idhive.groupby.mapaggr.checkinterval = 100000 hive.map.aggr.hash.min.reduction=0.5。上面這兩個(gè)參數(shù)聚合，如果聚合后的關(guān)掉 map 聚合的策略。Map 開始的時(shí)候先嘗試給前 100000 條做 hash數(shù)/100000>0.5 說(shuō)明這個(gè) groupby_key 沒有什么重復(fù)的，再繼續(xù)做局部聚合沒有意義，100000 以后就自動(dòng)把聚合開關(guān)關(guān)掉，在 map 的 log 中會(huì)看到下面的提示：2011-02-23 06:46:11,2

48、06 WARN org.apache.hadoop hive.ql.exec.GroupByOperator: Disable Hash Aggr: #hash table = 99999 #total = 100000 reduction = 0.0 minReduction = 0.51.2 數(shù)據(jù)傾斜通常這種情況都是在有 distinct 出現(xiàn)的時(shí)候，比如下面的 sql，由于 map 需要保存所有的 user.id，map 聚合開關(guān)會(huì)自動(dòng)關(guān)掉，導(dǎo)致出現(xiàn)計(jì)算不均衡的現(xiàn)象，只有 2 個(gè) redcue 做聚合，每個(gè) reduce 處理 100 億條。select user.gender,coun

49、t(distinct user.id) from user group by user.gender- 16 -Hadoop 開發(fā)者第四期計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法hive.groupby.skewindata = true 參數(shù)會(huì)把上面的 sql 翻譯成兩個(gè) MR，第一個(gè) MR 的 reduce_key是 gender+id。因?yàn)?id 是一個(gè)隨機(jī)散列的值，因此這個(gè) MR 的 reduce 計(jì)算是很均勻的，reduce 完成局部聚合的工作。MR1第二個(gè) MR 完成最終的聚合，統(tǒng)計(jì)男女的 distinct id 值，數(shù)據(jù)流如下圖所示，每個(gè) Map 只輸出兩條，因此雖然只有兩個(gè) r

50、edcue 計(jì)算也沒有關(guān)系，絕大部分計(jì)算量已經(jīng)在第一個(gè) MR 完成了。MR2hive.groupby.skewindata 默認(rèn)是關(guān)閉的，因此如果確定有不均衡的情況，需要手動(dòng)打開這個(gè)開關(guān)。當(dāng)然，并不是所有的有 distinct 的 group by 都需要打開這個(gè)開關(guān)，比如下面的 sql。因?yàn)?user.id 是一個(gè)散列的值，因此已經(jīng)是計(jì)算均衡的了，所有的 reduce 都會(huì)均勻計(jì)算。只有在 groupby_key 不散列，而 distinct_key 散列的情況下才需要打開這個(gè)開關(guān)，其他的情況 map 聚合優(yōu)化就足矣。select id,distinct(gender) from user

51、group by user id;三、 Join 中的計(jì)算均衡優(yōu)化在 hive 中，join 操作一般都是在 reduce 階段完成的，寫 sql 的時(shí)候要注意把放在 join 的左- 17 -Hadoop 開發(fā)者第四期計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法邊，是在 Join 操作的 Reduce 階段，位于 Join 操作符左邊的表的內(nèi)容會(huì)被加載進(jìn)內(nèi)存，將條目少的表放在左邊，可以有效減少發(fā)生 out of memory 錯(cuò)誤的幾率。 個(gè)大表和一個(gè)配置表的 reduce join 經(jīng)常會(huì)引起計(jì)算不均衡的情況。 比如配置 表gender_config(gender string,gender_

52、id int)。把“男”“女”字符串表 join 的 sql 如下：成一個(gè) id。配置表和上面的 userselect user.id gender_config.gender_id from gender_config join user on gender_config.gender=user.gendergender 只有男女兩個(gè)值，hive 處理 join 的時(shí)候把 join_key 作為 reduce_key,因此會(huì)出現(xiàn)和 groupby 類似的 reduce 計(jì)算不均衡現(xiàn)象，只有兩個(gè) reduce 參與計(jì)算，每個(gè) reduce 計(jì)算 100 億條。一個(gè)大表和一個(gè)小配置表的 redu

53、ce join 流程圖這種大表和配置表通常采用 mapjoin 的方式來(lái)解決這種不均衡的現(xiàn)象。目前 hive 是采用/*+ MAPJOIN(gender_config) */提示的方式告訴翻譯器把 sql 翻譯成 mapjoin，提示里必須指明配置表是哪個(gè)。select /*+ MAPJOIN(gender_config) */ user id gender_config.gender_id from gender_configjoin user on gender_config.gender=user.gender一個(gè)大表和一個(gè)小配置表的 map join 流程圖- 18 -Hadoop 開

54、發(fā)者第四期計(jì)算不均衡問(wèn)題在 Hive 中的解決辦法每個(gè) map 會(huì)把讀到 hash table，然后和大表做 hash join。因此 map join 的關(guān)鍵是能放入 map 進(jìn)程的內(nèi)存，如果內(nèi)存放不下會(huì)序列化到硬盤，效率會(huì)直線下降。成千上萬(wàn)個(gè) map 從 hdfs 讀這個(gè)進(jìn)的內(nèi)存，使得的讀操作變成成個(gè) join 的瓶頸，甚至有些時(shí)候有些 map 讀這個(gè)會(huì)失敗（因?yàn)橥瑫r(shí)有太多進(jìn)程讀了），最后導(dǎo)致 join 失敗。臨時(shí)解決辦法是增加的副本個(gè)數(shù)。Hive-1641 已經(jīng)解決了這個(gè)問(wèn)題， 主要思路是把Distributed Cache 里，map 讀本地文件即可。Hive 目前的 mapjoin 實(shí)現(xiàn)還不是很完美，開源社區(qū)有一些 patch 都是解決 mapjoin 的問(wèn)題，具放入體可以參考這個(gè)。- 19 -Hadoop 開發(fā)者第四期Join 算子在Had