Hadoop MapReduce開發(fā)最佳實踐

前言本文是Hadoop最佳實踐系列第二篇，上一篇為《Hadoop管理員的十個最佳實踐》。MapRuduce開發(fā)對于大多數(shù)程序員都會覺得略顯復雜，運行一個WordCount（Hadoop中helloword程序）不僅要熟悉MapRuduce模型，還要了解Linux命令（盡管有Cygwin，但在Windows下運行MapRuduce仍然很麻煩），此外還要學習程序的打包、部署、提交job、調(diào)試等技能，這足以讓很多學習者望而退步。所以如何提高MapReduce開發(fā)效率便成了大家很關(guān)注的問題。但Hadoop的Committer早已經(jīng)考慮到這些問題，從而開發(fā)了ToolRunner、MRunit（MapReduce最佳實踐第二篇中會介紹）、MiniMRCluster、MiniDFSCluster等輔助工具，幫助解決開發(fā)、部署等問題。舉一個自己親身的例子：某周一和搭檔(結(jié)對編程)決定重構(gòu)一個完成近10項統(tǒng)計工作的MapRuduce程序，這個MapReduce（從Spring項目移植過來的）,因為依賴Spring框架(原生Spring，非SpringHadoop框架),導致性能難以忍受，我們決定將Spring從程序中剔除。重構(gòu)之前程序運行是正確的，所以我們要保障重構(gòu)后運行結(jié)果與重構(gòu)前一致。搭檔說，為什么我們不用TDD來完成這個事情呢？于是我們研究并應用了MRunit，令人意想不到的是，重構(gòu)工作只用了一天就完成，剩下一天我們進行用findbug掃描了代碼，進行了集成測試。這次重構(gòu)工作我們沒有給程序帶來任何錯誤，不但如此我們還擁有了可靠的測試和更加穩(wěn)固的代碼。這件事情讓我們很爽的同時，也在思考關(guān)于MapReduce開發(fā)效率的問題，要知道這次重構(gòu)我們之前評估的時間是一周，我把這個事情分享到EasyHadoop群里，大家很有興趣，一個朋友問到，你們的評估太不準確了，為什么開始不評估2天完成呢？我說如果我們沒有使用MRUnit，真的是需要一周才能完成。因為有它單元測試，我可以在5秒內(nèi)得到我本次修改的反饋，否則至少需要10分鐘（編譯、打包、部署、提交MapReduce、人工驗證結(jié)果正確性），而且重構(gòu)是個反復修改，反復運行，得到反饋，再修改、再運行、再反饋的過程，MRunit在這里幫了大忙。相同智商、相同工作經(jīng)驗的開發(fā)人員，借助有效的工具和方法，竟然可以帶來如此大的開發(fā)效率差距，不得不讓人驚詫！PS.本文基于Hadoop1.0（ClouderaCDH3uX）。本文適合讀者：Hadoop初級、中級開發(fā)者。1.使用ToolRunner讓參數(shù)傳遞更簡單關(guān)于MapReduce運行和參數(shù)配置，你是否有下面的煩惱：將MapReduceJob配置參數(shù)寫到j(luò)ava代碼里，一旦變更意味著修改java文件源碼、編譯、打包、部署一連串事情。當MapReduce依賴配置文件的時候，你需要手工編寫java代碼使用DistributedCache將其上傳到HDFS中，以便map和reduce函數(shù)可以讀取。當你的map或reduce函數(shù)依賴第三方j(luò)ar文件時，你在命令行中使用”-libjars”參數(shù)指定依賴jar包時，但根本沒生效。其實，Hadoop有個ToolRunner類，它是個好東西，簡單好用。無論在《Hadoop權(quán)威指南》還是Hadoop項目源碼自帶的example，都推薦使用ToolRunner。下面我們看下src/example目錄下WordCount.java文件，它的代碼結(jié)構(gòu)是這樣的：publicclassWordCount{//略...publicstaticvoidmain(String[]args)throwsException{包列表最低下的“JRESystemLibrary”，雙擊”Accessrules”，在彈出窗口中點擊“add按鈕”，然后在新對話框中"Resolution"下拉框選擇"Accessible"，"RulePattern"填寫*/，保存后就OK了。如下圖：2.如何使用這個源碼項目呢？比如我知道Hadoop某個源碼文件的名稱，在eclipse中可以通過快捷鍵“Ctrl+Shift+R”調(diào)出查找窗口，輸入文件名，如“MapTask”，那可以打開這個類的源碼了。還有個使用場景，當我們編寫MapReduce程序的時候，我想直接打開某個類的源碼，通過上面的操作還是有點麻煩，比如我想看看Job類是如何實現(xiàn)的，當我點擊它的時候會出現(xiàn)下面的情景：解決辦法很簡單：點擊圖中“AttachSource”按鈕->點擊“Workspace”按鈕->選擇剛才新建的Hadoop源碼項目。完成后源碼應該就蹦出來了?？偨Y(jié)一下，本實踐中我們獲得了什么功能：知道hadoop源碼文件名，快速找到該文件寫程序的時候直接查看Hadoop相關(guān)類源碼Debug程序的時候，可以直接進入源碼查看并跟蹤運行推薦指數(shù)：★★★★推薦理由：通過源碼可以幫助我們更深入了解Hadoop，可以幫助我們解決復雜問題3.正確使用壓縮算法下表資料引用cloudera官方網(wǎng)站的一篇博客，原文點這里。CompressionFileSize(GB)CompressionTime(s)DecompressionTime(s)Nonesome_logs8.0--Gzipsome_logs.gz1.324172LZOsome_logs.lzo2.05535上面表格與筆者集群實際環(huán)境測試結(jié)果一致，所以我們可以得出如下結(jié)論：LZO文件的壓縮和解壓縮性能要遠遠好于Gzip文件。相同文本文件，使用Gzip壓縮可以比LZO壓縮大幅減少磁盤空間。上面的結(jié)論對我們有什么幫助呢？在合適的環(huán)節(jié)使用合適壓縮算法。在中國的帶寬成本是非常貴的，費用上要遠遠高于美國、韓國等國家。所以在數(shù)據(jù)傳輸環(huán)節(jié)，我們希望使用了Gzip算法壓縮文件，目的是減少文件傳輸量，降低帶寬成本。使用LZO文件作為MapReduce文件的輸入（創(chuàng)建lzoindex后是支持自動分片輸入的）。對于大文件，一個maptask的輸入將變?yōu)橐粋€block，而不是像Gzip文件一樣讀取整個文件，這將大幅提升MapReduce運行效率。主流傳輸工具FlumeNG和scribe默認都是非壓縮傳輸?shù)模ǘ际峭ㄟ^一行日志一個event進行控制的），這點大家在使用時要注意。FlumeNG可以自定義組件方式實現(xiàn)一次傳輸多條壓縮數(shù)據(jù)，然后接收端解壓縮的方式來實現(xiàn)數(shù)據(jù)壓縮傳輸，scribe沒有使用過不評論。另外值得一提的就是snappy，它是由Google開發(fā)并開源的壓縮算法的，是Cloudera官方大力提倡在MapReduce中使用的壓縮算法。它的特點是：與LZO文件相近的壓縮率的情況下，還可以大幅提升壓縮和解壓縮性能，但是它作為MapReduce輸入是不可以分割的。延伸內(nèi)容：Cloudera官方Blog對Snappy介紹：/blog/2011/09/snappy-and-hadoop/老外上傳的壓縮算法性能測試數(shù)據(jù)：/SFaNzRuf推薦指數(shù)：★★★★★推薦理由：壓縮率和壓縮性能一定程度是矛盾體，如何均衡取決于應用場景。使用合適壓縮算法直接關(guān)系到老板的錢，如果能夠節(jié)省成本，體現(xiàn)程序員的價值。4.在合適的時候使用Combinermap和reduce函數(shù)的輸入輸出都是key-value，Combiner和它們是一樣的。作為map和reduce的中間環(huán)節(jié)，它的作用是聚合maptask的磁盤，減少map端磁盤寫入，減少reduce端處理的數(shù)據(jù)量，對于有大量shuffle的job來說，性能往往取決于reduce端。因為reduce端要經(jīng)過從map端copy數(shù)據(jù)、reduce端歸并排序，最后才是執(zhí)行reduce方法，此時如果可以減少maptask輸出將對整個job帶來非常大的影響。什么時候可以使用Combiner？比如你的Job是WordCount，那么完全可以通過Combiner對map函數(shù)輸出數(shù)據(jù)先進行聚合，然后再將Combiner輸出的結(jié)果發(fā)送到reduce端。什么時候不能使用Combiner？WordCount在reduce端做的是加法，如果我們reduce需求是計算一大堆數(shù)字的平均數(shù)，則要求reduce獲取到全部的數(shù)字進行計算，才可以得到正確值。此時，是不能使用Combiner的，因為會其會影響最終結(jié)果。注意事項：即使設(shè)置Combiner，它也不一定被執(zhí)行（受參數(shù)bine影響），所以使用Combiner的場景應保證即使沒有Combiner，我們的MapReduce也能正常運行。推薦指數(shù)：★★★★★推薦理由：在合適的場景使用Combiner，可以大幅提升MapReduce性能。5.通過回調(diào)通知知道MapReduce什么時候完成你知道什么時候MapReduce完成嗎？知道它執(zhí)行成功或是失敗嗎？Hadoop包含job通知這個功能，要使用它非常容易，借助我們實踐一的ToolRunner，在命令行里面就可以進行設(shè)置，下面是一個例子：hadoopjarMyJob.jarcom.xxx.MyJobDriver\-Djob.end.notification.url=http://moniter/mapred_notify/\$jobId/\$jobStatus通過上面的參數(shù)設(shè)置后，當MapReduce完成后將會回調(diào)我參數(shù)中的接口。其中$jobId和$jobStatus會自動被實際值代替。上面在$jobId和$jobStatus兩個變量前，我添加了shell中的轉(zhuǎn)義符”\”，如果使用java代碼設(shè)置該參數(shù)是不需要轉(zhuǎn)義符的?？偨Y(jié)下：看看我們通過該實踐可以獲得什么？獲取MapReduce運行時間和回調(diào)完成時間，可以分析最耗時Job，最快完成Job。通過MapReduce運行狀態(tài)（包括成功、失敗、Kill），可以第一時間發(fā)現(xiàn)錯誤，并通知運維。通過獲取MapReduce完成時間，可以第一時間通過用戶，數(shù)據(jù)已經(jīng)計算完成，提升用戶體驗Hadoop這塊功能的源碼文件是JobEndNotifier.java，可以馬上通過本文實踐二看看究竟。其中下面兩個參數(shù)就是我通過翻源碼的時候發(fā)現(xiàn)的，如果希望使用該實踐趕緊通過ToolRunner設(shè)置上吧（別忘了加-D，格式是-Dkey=value）。job.end.retry.attempts//設(shè)置回調(diào)通知retry次數(shù)erval//設(shè)置回調(diào)時間間隔，單位毫秒當然如果hadoop沒有提供Job狀態(tài)通知的功能，我們也可以通過采