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