所以，在我看來我們需要找到一種手段，首先第一我能優化我的方案，第二優化用戶作業。前面說過比較難實現就是如果從配置上講，最好能配置資源，當然動態配置是因為你需要了解，思考，去模擬用戶作業到底是怎么執行的才能去做，而我們這里提出一個比較確切，比較簡單方式，我不需要了解這些配置，我從tasks靜態解決這些問題。
我們看一下Hadoop MapReduce，來看一下Task Runtime，可以看到是通過Task的JVIM，這只是一個框架，這里講的是去負責啟動用戶，用戶進城之后通過管道，標準輸入，標準輸出來做，這樣的話其實很難做到對用戶進程的控制。為什么要用JAVA呢？這是Hadoop最早提出來JAVA需要跨平臺，做系統軟件你知道用JAVA實現跨平臺很難，對于現在國內互聯網公司來說，所有服務器，以及系統都是定制的，他不需要跨平臺的功能。
第二個因為JAVA編程語言特性大家都知道，Hadoop為了更好的收縮性，他分裝了很多層，在編程者看來這是有必要進行簡化的。第三個最重要就是JNI，Hadoop是怎么做的？壓縮都是本地庫，壓縮方法有很多，比如Linux自帶的，包括LGO，包括Google最近開源壓縮庫都是C++本地，只能通過JNI，因為JNI比傳統高效一點，所以在Hadoop里面是通過JNI來做的。
第四點你本身的程序是獨立于框架的，所以你框架是很難做影響的。這一頁就給大家介紹一下現有實現的四個問題，我們怎么來解決。這是我們的目標，我們總目標基于原來框架，我們目標有兩點，第一就是提升整個集群的資源利用率，第二就是附帶解決開發效率的問題。提升資源利用率，如果我們想象把整個框架和用戶，這幅圖，如果整個框架和應用綁定起來，和用戶能綁定起來，我就能做最簡單的編譯優化，用最簡單的方式去進行實現。
第二，我們希望用C++來實現，為什么？因為我是做Hadoop出身的，所以我用Hadoop創始人那一句話有兩點，因為你的MapReduce是C++密集型計算，當然你這里不是內容密集型，因為每一個tasks執行都會推出，但如果在2.0，你的tasks為了更高效不推出去接新的tasks，對于C++來說，JAVA用的久人也知道，最近JAVA最新JNI優化器優化之后，比C++性能差不了太多，原來大家認為差5倍，4倍，現在差2，3倍，當然差距還是有。選擇C++的話，一方面比JAVA效能高，另外相對全面應用也有好處，第三點JAVA是虛擬機自己控制，而C++里面可以更快釋放。所以，對于資源管理更好，當然這些不是我的觀點。
前面回顧一下我介紹的背景，因為我們的集群在不斷的擴張，而且我們集群的使用效率會有一些問題，基于這種現狀，我們除了在作業召集的優化，我們還做了tasks級別的優化，我們是要解決兩個問題。第一要提升資源效率，框架的資源效率，第二我們希望把框架和應用程序綁定起來，這樣在優化框架同時能優化應用程序，靜態的方式。具體該怎么做，我們介紹一下。MFramework Model，首先看一下整個框架中位置，第二看一下功能模型什么樣子，第三實際處理模型什么樣子，第四看一下接口提供哪些編程接口，最后對比一下HCE和現有的Hadoop。
Overviwe，整個HCE的位置就如紅字所設，是相當于一個處理引擎。說白了實現了Hadoop里面非調度那層，因為在Hadoop里面調度是有JAVA做的，執行是有C++做的，因為調度沒必要做成C++，非內存密集型。所以，你只需要關注，這樣你可以把Hadoop分成兩層，第一層是調度，第二層是調度，執行用C++執行，調度用JAVA。
因為附帶會提供一些其他的編程語言接口，因為傳統現在一些編程語言接口用的比較多，Hadoop作為用戶一般是用JAVA，還有以數據倉庫來做，通過多變，HCE本身是C++實現的，他最終提供是C++接口。C++大家都知道，支持其他編程語言接口非常方便。因為其他腳本語言，所有都是基于C實現的，換句話你只需要做一個最簡單解釋器就能實現對接，而且更高效。
他底層是基于HDCSS，尤其在國內很多系統都是用C++實現的。如果用HadoopC++實現數據庫的話，C++框架直接去接C++的數據庫會更高效，不然的話你JAVA想把MapReduce加在C++實現的框架上，必須要實現語言轉換。所以，他對底層支持也會更好一些。整個數據通路，一般傳統數據分析流程是前端WAP抓到數據之后，給到最前端的中間件，或者KV，Data，他們通過一些云傳輸，像開源，或者通過一些大塊傳輸傳給后臺的分析系統，分析系統做一些計算，或者做一些MPI計算，這樣有上層JAVA進行讀取相關數據分析，反饋用戶最經典就是Twitter的方式，通過簡單實施流處理。
因為實施流處理不能脫離，因為有窗口概念，最終結果可能還是需要P處理來校驗，這方面不多說。我們還是回到MapReduce本身，本身我們一下具體該怎么做。MapReduce階段本身的Map階段，首先他是有讀文件，一個任務會把文件讀進來，第二是做一些Map處理，相當于是去引用用戶的一些方法，因為在一個Map處理里面，你用戶計算的這且東西越來越大內存可能放不下。因為你每臺機器可能跑8個Map，16個Map，內存放不下的時候要設置起來，有一個設置階段。還有我先寫一個臨時目錄，最后再提交到正式目錄這么一個過程。Reduce有一些Shuffling為什么重點關注Map沒有重點關注Reduce，那會我講的時候第三頁，我說過，有一個圖，本身Reduce個數就比Map要少很多，一般輕量級計算少5-10倍很正常，而且Reduce的計算是很輕量級的。
所以，你用框架去優化就夠了，不用對Reducetasks做額外優化。而且Reduce很大一部分是在Shuffling因為你是并行計算，多個Reduce需要知道輸出結果，就需要有Shuffling，多點到多點的數據傳輸，在Web2.0需要其他方式實現，我通過實現Shuffling脫離，把這部分單獨剝離出去，相當于有三個階段，總的來說還是有兩個階段，Shuffling相當于有一個獨立的服務，當Reduce輸出外之后會通知Shuffling進程，相當于服務托管，說我算完了，Shuffling服務把他把Reduce輸出結果拖到Reduce階段，傳統Reduce是要站槽位，占資源那一剎那并不能計算，把Shuffling脫離出去之后就不用占用這部分資源。
所以，HCE不解決這個問題，HCE只解決Map問題，而Shuffling的問題要留在2.0解決。看這個圖一個首先會通過Map會產生多個文件，之后會進行排序，做一些設置，最后合成整個輸出，把這個文件再Shuffling到其他Reduce處理節點上進行處理。HCE其實主要是解決Map端，因為Map端后面測試我們可以看到，Map端實際上占性能開銷最大還是OI相關的，以及比較占CPU資源的槽，我們就需要進行獨立解決。
推薦閱讀
時至今日，“Big data”(大數據)時代的來臨已經毋庸置疑，尤其是在電信、金融等行業，幾乎已經到了“數據就是業務本身”的地步。這種趨勢已經讓很多相信數據之力量的企業做出改變。恰逢此時，為了讓更多的人了解和使>>>詳細閱讀
本文標題：百度楊棟：HCE助MapReduce提升資源利用率
地址：http://www.sdlzkt.com/a/kandian/20120305/36929.html
網友點評
精彩導讀
科技快報
品牌展示