所以，在我看來我們需要找到一種手段，首先第一我能優(yōu)化我的方案，第二優(yōu)化用戶作業(yè)。前面說過比較難實(shí)現(xiàn)就是如果從配置上講，最好能配置資源，當(dāng)然動(dòng)態(tài)配置是因?yàn)槟阈枰私猓伎迹ツM用戶作業(yè)到底是怎么執(zhí)行的才能去做，而我們這里提出一個(gè)比較確切，比較簡(jiǎn)單方式，我不需要了解這些配置，我從tasks靜態(tài)解決這些問題。
我們看一下Hadoop MapReduce，來看一下Task Runtime，可以看到是通過Task的JVIM，這只是一個(gè)框架，這里講的是去負(fù)責(zé)啟動(dòng)用戶，用戶進(jìn)城之后通過管道，標(biāo)準(zhǔn)輸入，標(biāo)準(zhǔn)輸出來做，這樣的話其實(shí)很難做到對(duì)用戶進(jìn)程的控制。為什么要用JAVA呢？這是Hadoop最早提出來JAVA需要跨平臺(tái)，做系統(tǒng)軟件你知道用JAVA實(shí)現(xiàn)跨平臺(tái)很難，對(duì)于現(xiàn)在國(guó)內(nèi)互聯(lián)網(wǎng)公司來說，所有服務(wù)器，以及系統(tǒng)都是定制的，他不需要跨平臺(tái)的功能。
第二個(gè)因?yàn)镴AVA編程語言特性大家都知道，Hadoop為了更好的收縮性，他分裝了很多層，在編程者看來這是有必要進(jìn)行簡(jiǎn)化的。第三個(gè)最重要就是JNI，Hadoop是怎么做的？壓縮都是本地庫，壓縮方法有很多，比如Linux自帶的，包括LGO，包括Google最近開源壓縮庫都是C++本地，只能通過JNI，因?yàn)镴NI比傳統(tǒng)高效一點(diǎn)，所以在Hadoop里面是通過JNI來做的。
第四點(diǎn)你本身的程序是獨(dú)立于框架的，所以你框架是很難做影響的。這一頁就給大家介紹一下現(xiàn)有實(shí)現(xiàn)的四個(gè)問題，我們?cè)趺磥斫鉀Q。這是我們的目標(biāo)，我們總目標(biāo)基于原來框架，我們目標(biāo)有兩點(diǎn)，第一就是提升整個(gè)集群的資源利用率，第二就是附帶解決開發(fā)效率的問題。提升資源利用率，如果我們想象把整個(gè)框架和用戶，這幅圖，如果整個(gè)框架和應(yīng)用綁定起來，和用戶能綁定起來，我就能做最簡(jiǎn)單的編譯優(yōu)化，用最簡(jiǎn)單的方式去進(jìn)行實(shí)現(xiàn)。
第二，我們希望用C++來實(shí)現(xiàn)，為什么？因?yàn)槲沂亲鯤adoop出身的，所以我用Hadoop創(chuàng)始人那一句話有兩點(diǎn)，因?yàn)槟愕腗apReduce是C++密集型計(jì)算，當(dāng)然你這里不是內(nèi)容密集型，因?yàn)槊恳粋�(gè)tasks執(zhí)行都會(huì)推出，但如果在2.0，你的tasks為了更高效不推出去接新的tasks，對(duì)于C++來說，JAVA用的久人也知道，最近JAVA最新JNI優(yōu)化器優(yōu)化之后，比C++性能差不了太多，原來大家認(rèn)為差5倍，4倍，現(xiàn)在差2，3倍，當(dāng)然差距還是有。選擇C++的話，一方面比JAVA效能高，另外相對(duì)全面應(yīng)用也有好處，第三點(diǎn)JAVA是虛擬機(jī)自己控制，而C++里面可以更快釋放。所以，對(duì)于資源管理更好，當(dāng)然這些不是我的觀點(diǎn)。
前面回顧一下我介紹的背景，因?yàn)槲覀兊募涸诓粩嗟臄U(kuò)張，而且我們集群的使用效率會(huì)有一些問題，基于這種現(xiàn)狀，我們除了在作業(yè)召集的優(yōu)化，我們還做了tasks級(jí)別的優(yōu)化，我們是要解決兩個(gè)問題。第一要提升資源效率，框架的資源效率，第二我們希望把框架和應(yīng)用程序綁定起來，這樣在優(yōu)化框架同時(shí)能優(yōu)化應(yīng)用程序，靜態(tài)的方式。具體該怎么做，我們介紹一下。MFramework Model，首先看一下整個(gè)框架中位置，第二看一下功能模型什么樣子，第三實(shí)際處理模型什么樣子，第四看一下接口提供哪些編程接口，最后對(duì)比一下HCE和現(xiàn)有的Hadoop。
Overviwe，整個(gè)HCE的位置就如紅字所設(shè)，是相當(dāng)于一個(gè)處理引擎。說白了實(shí)現(xiàn)了Hadoop里面非調(diào)度那層，因?yàn)樵贖adoop里面調(diào)度是有JAVA做的，執(zhí)行是有C++做的，因?yàn)檎{(diào)度沒必要做成C++，非內(nèi)存密集型。所以，你只需要關(guān)注，這樣你可以把Hadoop分成兩層，第一層是調(diào)度，第二層是調(diào)度，執(zhí)行用C++執(zhí)行，調(diào)度用JAVA。
因?yàn)楦綆?huì)提供一些其他的編程語言接口，因?yàn)閭鹘y(tǒng)現(xiàn)在一些編程語言接口用的比較多，Hadoop作為用戶一般是用JAVA，還有以數(shù)據(jù)倉(cāng)庫來做，通過多變，HCE本身是C++實(shí)現(xiàn)的，他最終提供是C++接口。C++大家都知道，支持其他編程語言接口非常方便。因?yàn)槠渌_本語言，所有都是基于C實(shí)現(xiàn)的，換句話你只需要做一個(gè)最簡(jiǎn)單解釋器就能實(shí)現(xiàn)對(duì)接，而且更高效。
他底層是基于HDCSS，尤其在國(guó)內(nèi)很多系統(tǒng)都是用C++實(shí)現(xiàn)的。如果用HadoopC++實(shí)現(xiàn)數(shù)據(jù)庫的話，C++框架直接去接C++的數(shù)據(jù)庫會(huì)更高效，不然的話你JAVA想把MapReduce加在C++實(shí)現(xiàn)的框架上，必須要實(shí)現(xiàn)語言轉(zhuǎn)換。所以，他對(duì)底層支持也會(huì)更好一些。整個(gè)數(shù)據(jù)通路，一般傳統(tǒng)數(shù)據(jù)分析流程是前端WAP抓到數(shù)據(jù)之后，給到最前端的中間件，或者KV，Data，他們通過一些云傳輸，像開源，或者通過一些大塊傳輸傳給后臺(tái)的分析系統(tǒng)，分析系統(tǒng)做一些計(jì)算，或者做一些MPI計(jì)算，這樣有上層JAVA進(jìn)行讀取相關(guān)數(shù)據(jù)分析，反饋用戶最經(jīng)典就是Twitter的方式，通過簡(jiǎn)單實(shí)施流處理。
因?yàn)閷?shí)施流處理不能脫離，因?yàn)橛写翱诟拍睿罱K結(jié)果可能還是需要P處理來校驗(yàn)，這方面不多說。我們還是回到MapReduce本身，本身我們一下具體該怎么做。MapReduce階段本身的Map階段，首先他是有讀文件，一個(gè)任務(wù)會(huì)把文件讀進(jìn)來，第二是做一些Map處理，相當(dāng)于是去引用用戶的一些方法，因?yàn)樵谝粋�(gè)Map處理里面，你用戶計(jì)算的這且東西越來越大內(nèi)存可能放不下。因?yàn)槟忝颗_(tái)機(jī)器可能跑8個(gè)Map，16個(gè)Map，內(nèi)存放不下的時(shí)候要設(shè)置起來，有一個(gè)設(shè)置階段。還有我先寫一個(gè)臨時(shí)目錄，最后再提交到正式目錄這么一個(gè)過程。Reduce有一些Shuffling為什么重點(diǎn)關(guān)注Map沒有重點(diǎn)關(guān)注Reduce，那會(huì)我講的時(shí)候第三頁，我說過，有一個(gè)圖，本身Reduce個(gè)數(shù)就比Map要少很多，一般輕量級(jí)計(jì)算少5-10倍很正常，而且Reduce的計(jì)算是很輕量級(jí)的。
所以，你用框架去優(yōu)化就夠了，不用對(duì)Reducetasks做額外優(yōu)化。而且Reduce很大一部分是在Shuffling因?yàn)槟闶遣⑿杏?jì)算，多個(gè)Reduce需要知道輸出結(jié)果，就需要有Shuffling，多點(diǎn)到多點(diǎn)的數(shù)據(jù)傳輸，在Web2.0需要其他方式實(shí)現(xiàn)，我通過實(shí)現(xiàn)Shuffling脫離，把這部分單獨(dú)剝離出去，相當(dāng)于有三個(gè)階段，總的來說還是有兩個(gè)階段，Shuffling相當(dāng)于有一個(gè)獨(dú)立的服務(wù)，當(dāng)Reduce輸出外之后會(huì)通知Shuffling進(jìn)程，相當(dāng)于服務(wù)托管，說我算完了，Shuffling服務(wù)把他把Reduce輸出結(jié)果拖到Reduce階段，傳統(tǒng)Reduce是要站槽位，占資源那一剎那并不能計(jì)算，把Shuffling脫離出去之后就不用占用這部分資源。
所以，HCE不解決這個(gè)問題，HCE只解決Map問題，而Shuffling的問題要留在2.0解決。看這個(gè)圖一個(gè)首先會(huì)通過Map會(huì)產(chǎn)生多個(gè)文件，之后會(huì)進(jìn)行排序，做一些設(shè)置，最后合成整個(gè)輸出，把這個(gè)文件再Shuffling到其他Reduce處理節(jié)點(diǎn)上進(jìn)行處理。HCE其實(shí)主要是解決Map端，因?yàn)镸ap端后面測(cè)試我們可以看到，Map端實(shí)際上占性能開銷最大還是OI相關(guān)的，以及比較占CPU資源的槽，我們就需要進(jìn)行獨(dú)立解決。
推薦閱讀
圓桌沙龍：NoSQL技術(shù)實(shí)戰(zhàn)
時(shí)至今日，“Big data”(大數(shù)據(jù))時(shí)代的來臨已經(jīng)毋庸置疑，尤其是在電信、金融等行業(yè)，幾乎已經(jīng)到了“數(shù)據(jù)就是業(yè)務(wù)本身”的地步。這種趨勢(shì)已經(jīng)讓很多相信數(shù)據(jù)之力量的企業(yè)做出改變。恰逢此時(shí)，為了讓更多的人了解和使>>>詳細(xì)閱讀
本文標(biāo)題：百度楊棟：HCE助MapReduce提升資源利用率
地址：http://m.sdlzkt.com/a/kandian/20120305/36929.html
網(wǎng)友點(diǎn)評(píng)
精彩導(dǎo)讀
科技快報(bào)
品牌展示