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