本身功能框架大概分四個(gè)層次，最上層提供了Java，C++，Streaming，Python，Php，相比于原來只提供Java接口，他認(rèn)為如果你是原生態(tài)就做Java，其他語言統(tǒng)一Streaming，這樣問題開發(fā)者會(huì)有一些變動(dòng)，第二Streaming還是有一些管道開銷。處理每一個(gè)KV都需要管道，管道就是拷貝一次，都會(huì)額外有兩次拷貝到Java里面，如果省去這一點(diǎn)可以節(jié)省一點(diǎn)，有人說節(jié)省這一點(diǎn)重要嗎？對于一個(gè)上萬臺(tái)集群，只要節(jié)省1%就賺了幾百萬，節(jié)這么一個(gè)概念。
第二層次是Compiler Optimization，對編譯做的。還有一個(gè)代碼實(shí)現(xiàn)，能夠從C++轉(zhuǎn)到上面的Php接口，這個(gè)其實(shí)代碼量100內(nèi)搞定，很方便實(shí)現(xiàn)多語言。執(zhí)行層沒什么好說的，執(zhí)行層和Hadoop原來都是一樣的，只不過我們原來做了一些優(yōu)化，讓每一個(gè)模塊都比原來高高興一點(diǎn)。底層的壓縮庫，我們做了一些調(diào)優(yōu)，因?yàn)榇蠹叶贾溃l(fā)明一個(gè)壓縮算法很難，因?yàn)橄駛鹘y(tǒng)是有幾十種壓縮算法，我們只需要針對不同數(shù)據(jù)去選擇不同的壓縮算法。還有存儲(chǔ)接口，可以和C++存儲(chǔ)更好交互，換句話能夠在其他C++實(shí)現(xiàn)的上節(jié)省很多IO如果你要通過GNI，其他的方式來做。
文件格式傳統(tǒng)Hadoop支持兩種，MapReduce，文本等格式。看一下整個(gè)數(shù)據(jù)流，整個(gè)HCE數(shù)據(jù)流，用戶提交作業(yè)從這端開始提交，到切割處理，相當(dāng)于上層只是在Java只是一個(gè)虛擬的代理，真正實(shí)現(xiàn)都是在C++上面。其實(shí)早期做了一項(xiàng)，通過C++空間來實(shí)現(xiàn)Shuffling，其實(shí)效果不大，本身瓶頸不在于傳輸，而在于本身在2.0里面，把部分槽位省下來，本身性能有很大提高。其實(shí)C++端貢獻(xiàn)最大還是Reduce這塊，相當(dāng)數(shù)據(jù)流這端，最終數(shù)據(jù)輸出在控制上層做完就OK了。
換句話說，把數(shù)據(jù)切到C++的第三個(gè)，為什么還要實(shí)現(xiàn)，因?yàn)楹芏嘧鳂I(yè)已經(jīng)用Streaming跑，我們增加了StreamingOver Hce的接口。這里SSE怎么利用靜態(tài)編譯去優(yōu)化一個(gè)程序？實(shí)現(xiàn)一些傳統(tǒng)方法向，這種操作對每一種都有3到5倍，甚至10倍提升。有人說這些用戶他可能不用，換句話說SSE就是強(qiáng)迫用戶用，用戶用C編程必須要去包HCE框架，這種SSE指令級(jí)帶來性能提升。
最終會(huì)提供這么幾個(gè)接口，像C++，CHE等一些接口，性能大概有10%-30%提升，而誰在用呢？像Java是Hive在用。對于一些需要提升性能的，因?yàn)槭牵�有一些比較大的用戶程序占了很多東西作業(yè)，他是用C++就能有很多提升。進(jìn)行一個(gè)對比，HCE對比Hadoop有這么幾個(gè)方面，提供編程接口更多一些，很容易支持其他存儲(chǔ)系統(tǒng)。第三，本身要比基于JNI的性能提升很多，再就是我們用實(shí)現(xiàn)靜態(tài)編譯，使用戶進(jìn)程能夠跑的很快，當(dāng)然會(huì)做一些像比較久遠(yuǎn)算法，在大數(shù)據(jù)里面，因?yàn)槟J(rèn)Hadoop最終容易實(shí)現(xiàn)combiner，這是什么呢？就是Map階段去做Reduce，這是很重要優(yōu)化。所以，HCE用這些技術(shù)都會(huì)比Hadoop更優(yōu)。
最后我們看一下對比，他的性能比，這是原來Hadoop，什么叫Timings，我把所有Shuffling切成一段段對比，HCE取兩塊，其他都是一些功能型實(shí)現(xiàn)。為什么優(yōu)化呢？因?yàn)榈谝籆++在本地做排序，第二我們有用JNG，我們考慮 壓縮因素，壓縮算法有很多，尤其是中間結(jié)果壓縮，基于本地的，換句話說你在本地，大家看這幅圖，什么情況最高呢？他恰恰中間結(jié)果用了IOGO壓縮最多，換句話這個(gè)壓縮比最好，耗的CPU最多，需不需要用這個(gè)呢？不一定，大家去看官網(wǎng)，其實(shí)你做壓縮，本地本身跑計(jì)算這些數(shù)據(jù)已經(jīng)是半結(jié)構(gòu)化的數(shù)據(jù)，或者結(jié)構(gòu)化的數(shù)據(jù)，他做到這一部，用其他壓縮法壓縮比也不會(huì)差一倍，本身CPU消耗，包括Google等等這些東西也比哪些高很多，這是10個(gè)節(jié)點(diǎn)100G測算結(jié)果。
如果我用SSE指令來編譯的時(shí)候，利用編譯優(yōu)化的算法還有額外10%的提升。第二個(gè)應(yīng)用，這是百度實(shí)際應(yīng)用，跑兩個(gè)實(shí)際應(yīng)用，第一個(gè)是語言的影響，第一個(gè)是Hadoop傳統(tǒng)Streaming，大概跑了50秒。本身HCE，這是差不多在90臺(tái)機(jī)器上跑的，用HCEStreaming有所提升，你省去Streaming管道還有一個(gè)提升，傳統(tǒng)跑了20多秒，變成Streaming跑了這么多等等都不同，所以根據(jù)實(shí)際來看優(yōu)化框架和靜態(tài)編譯優(yōu)化程序我們都做到了。
最后總結(jié)一下，不應(yīng)該叫Jobs，我們?nèi)绾稳?yōu)化一個(gè)tasks，我們HCE目標(biāo)就是優(yōu)化tasks。首先你要通告combiner，保證在Map端數(shù)據(jù)減少，到Reduce就很輕量級(jí)。第二是用C++接口，第二通過壓縮算法等來進(jìn)行。Contribution大概在今年年底，所有集成作業(yè)都會(huì)切到HCE上，當(dāng)然是百度的。第二就是Applications，有哪些用戶，有哪些作業(yè)？他任務(wù)都很大，很重量級(jí)。第二就是MapReduce-based warehouse，這就是我那會(huì)說的話，HCE本身會(huì)節(jié)省超過10%機(jī)器，為公司能節(jié)省，如果全部用上的話能節(jié)省10%。
什么叫Hive Over HCE。有一個(gè)同學(xué)在Hive工作，我把HCE推薦給Hive，他做了一些試用，以及他們跑的一些作業(yè)。FaceBook這邊做了一些簡單實(shí)踐，他相當(dāng)于把MapReduce，因?yàn)榇蠹伊私釮ive就是MapReduce一層分裝，把Hive和Reduce本身實(shí)現(xiàn)復(fù)雜邏輯。Hive支持是劣存儲(chǔ)，他實(shí)現(xiàn)這些東西，然后就遷過去。他給出數(shù)據(jù)，他們實(shí)際跑的FaceBook一些作業(yè)有20%到50%性能提升，為什么平均30%呢，不是很高呢，因?yàn)樗淖鳂I(yè)都是很重量級(jí)。換句話FaceBook作業(yè)都是好CPU，什么在好CPU，超過70%是壓縮和解壓縮，為什么？因?yàn)閲鴥?nèi)這方面可能做的不好，國外所有的輸入輸出都是利用Jira壓縮，現(xiàn)在國內(nèi)都是計(jì)算式瓶頸，有的人覺得不差錢加機(jī)器擴(kuò)容解決，國外這塊做的比較精細(xì)一點(diǎn)。
有沒有辦法解決呢？我建議一種方法，用SSE把壓縮庫重新編譯成內(nèi)聯(lián)的方式。因?yàn)樗械膲嚎s都是用我前面說的這些簡單的語言，函數(shù)實(shí)現(xiàn)，而壓縮庫本身是是0的，你必須利用高效指令進(jìn)行優(yōu)化，因?yàn)镠adoop利用到這種技術(shù)。所以，這是一個(gè)額外話題，你希望去優(yōu)化程序，你應(yīng)該去關(guān)注程序本身性能損耗在哪里，有沒有相似或者有沒有一些簡單不用去實(shí)現(xiàn)那么復(fù)雜的動(dòng)態(tài)配置來解決這個(gè)問題。
推薦閱讀
圓桌沙龍：NoSQL技術(shù)實(shí)戰(zhàn)
時(shí)至今日，“Big data”(大數(shù)據(jù))時(shí)代的來臨已經(jīng)毋庸置疑，尤其是在電信、金融等行業(yè)，幾乎已經(jīng)到了“數(shù)據(jù)就是業(yè)務(wù)本身”的地步。這種趨勢已經(jīng)讓很多相信數(shù)據(jù)之力量的企業(yè)做出改變。恰逢此時(shí)，為了讓更多的人了解和使>>>詳細(xì)閱讀
本文標(biāo)題：百度楊棟：HCE助MapReduce提升資源利用率
地址：http://m.sdlzkt.com/a/kandian/20120305/36929.html
網(wǎng)友點(diǎn)評
精彩導(dǎo)讀
科技快報(bào)
品牌展示