h開發(fā)者第四期

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28、能自動識別壓縮文件，使用 gzip 對日志文件進行壓縮，默認(rèn)的壓縮級別，壓縮比可以達到 5：1，為了節(jié)省空間及網(wǎng)絡(luò)帶寬，日志文件在 Collector 服務(wù)器直接壓縮，一式兩份，一份傳給 LogBackup 服務(wù)器，一份傳給 hadoop 集群。然后你可以通過 hive 客戶端，創(chuàng)建 external表來管理這些格式化的日志。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 是頻道名稱，因為你的有主頻道、頻道、博客頻道等，進行頻道切分有助于后續(xù)按頻道進行有性的流量分析。借助于 hive，進行日志統(tǒng)計就非常簡單，比如我們要處理這樣一個需求：計算 1 月份各頻道每- 10

30、 -Hadoop 開發(fā)者第四期海量數(shù)據(jù)處理平臺架構(gòu)演變天的回彈率，其中，回彈率=回彈用戶數(shù)/總用戶數(shù)，回彈用戶定義為 pv=1 的那些用戶。輸出的形式“日期 頻道名 回彈率”。這個需求的目的是想了解各頻道對用戶吸引力如何。根據(jù)需求，我們需要分別統(tǒng)計當(dāng)天 pv=1 的用戶數(shù)和當(dāng)天總用戶數(shù)，很明顯我們需要統(tǒng)計每個用戶每天的 pv 數(shù)，在此基礎(chǔ)上才能提取到 pv=1 的用戶數(shù)。為了簡化操作，我們需要先建立一張中間表：用戶行為寬表。有了這，以后用戶級別的需求都可以基于此寬表進行。這結(jié)構(gòu)設(shè)計如下：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ù)跑出來建好表結(jié)構(gòu)之后，我們寫一個#!/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ù)處理平臺架構(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這個的邏輯有幾個關(guān)鍵點：1、對于每天，用戶寬表都需要增加分區(qū) statdate，這個是建表的時候規(guī)定的；2、從原始的tb_weblog_user 中。流量數(shù)據(jù)表 tb_weblog 中進行，把匯總結(jié)果充入到我們的用戶寬表有了用戶寬表，我們再回過頭來統(tǒng)計回彈用戶率這個需求，那就輕而易舉了。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)計日期”的格式，從開發(fā)到數(shù)據(jù)統(tǒng)計完畢， 幾分鐘就可以完成，非常方便。如果我們使用以前的方式，使用常規(guī)的編程語言來開發(fā)實現(xiàn)，恐怕在開發(fā)上需要耗費的各種開銷會非常可觀。這個需求實現(xiàn)的關(guān)鍵點在于中間表-用戶行為寬表的引入，試想，如果需求中“回彈用戶”的定義發(fā)生了改變，pv<=2 的用戶都算入回彈用戶，那我們需要修改的，僅僅是那個基于寬表提取數(shù)據(jù)的 SQL，影響不大。鑒于原始的流水表數(shù)據(jù)量太大，而中間表在這次統(tǒng)計需求中發(fā)揮了很重要的作用，你很自然的想到，原始流水表進行一個初步的匯總，會后續(xù)的統(tǒng)計分析是非常有幫助的。于是，類似用戶行為寬表，你根據(jù)日常

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

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

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

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

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

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

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

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

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

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

47、 user.id,count(1) from user group by user.idhive.groupby.mapaggr.checkinterval = 100000 hive.map.aggr.hash.min.reduction=0.5。上面這兩個參數(shù)聚合，如果聚合后的關(guān)掉 map 聚合的策略。Map 開始的時候先嘗試給前 100000 條做 hash數(shù)/100000>0.5 說明這個 groupby_key 沒有什么重復(fù)的，再繼續(xù)做局部聚合沒有意義，100000 以后就自動把聚合開關(guān)關(guān)掉，在 map 的 log 中會看到下面的提示：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)的時候，比如下面的 sql，由于 map 需要保存所有的 user.id，map 聚合開關(guān)會自動關(guān)掉，導(dǎo)致出現(xiàn)計算不均衡的現(xiàn)象，只有 2 個 redcue 做聚合，每個 reduce 處理 100 億條。select user.gender,coun

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

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

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

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

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

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