Hadoop在百度的應用－－4000個節點的分散式叢集
百度的高效能運算系統（主要是後端資料訓練和計算）目前有4000節點，超過10個的叢集，最大的叢集規模在1000個節點以上。每個節點由8核CPU以及16G記憶體以及12TB硬碟組成，每天的資料生成量在3PB以上。規劃當中的架構將有超過1萬個節點，每天的資料生成量在10PB以上。
圖1.1 百度高效能運算系統的架構
底層的計算資源管理層採用了Agent排程不同型別的計算分別給MPI結構的演算法和Map-Reduce和DAG演算法應用等。而通過排程的分配，可以讓HPC高效能運算叢集和大規模分散式叢集各得其所的計算相應資料。
圖1.2 作業執行
百度通過HCE對streaming作業的排序，壓縮，解壓縮，記憶體控制進行了優化並提供了C++版的MapReduce介面。
圖1.3 實現概覽
下面是C++版的Map-Reduce程式輪廓：
圖1.4 Map/Reduce程式輪廓
下面是Map-Reduce經典應用WorkCount的例子：
圖1.5 wordcount程式
百度HCE語言的有關內容，HCE是基於C++的Hadoop環境，是一個全功能C++環境，可以避開Java語言對於釋放記憶體和資源申請的弊端，並在呼叫資料時繞開Java語言的所有關節，極大的提升演算法效率。
HCE作業排程的一些特點：
圖1.6 HCE作業排程特點
2、Hadoop在百度的應用
百度作為全球最大的中文搜尋引擎公司，提供基於搜尋引擎的各種產品，包括以網路搜尋為主的功能性搜尋；以貼吧為主的社群搜尋；針對區域、行業的垂直搜尋、MP3音樂搜尋，以及百科等，幾乎覆蓋了中文網路世界中所有的搜尋需求。
百度對海量資料處理的要求是比較高的，要線上下對資料進行分析，還要在規定的時間內處理完並反饋到平臺上。百度在網際網路領域的平臺需求如圖3-3所示，這裡就需要通過效能較好的雲平臺進行處理了，Hadoop就是很好的選擇。在百度，Hadoop主要應用於以下幾個方面：
* 日誌的儲存和統計；
* 網頁資料的分析和挖掘；
* 商業分析，如使用者的行為和廣告關注度等；
* 線上資料的反饋，及時得到線上廣告的點選情況；
* 使用者網頁的聚類，分析使用者的推薦度及使用者之間的關聯度。
圖3-3 網際網路領域的平臺需求
MapReduce主要是一種思想，不能解決所有領域內與計算有關的問題，百度的研究人員認為比較好的模型應該如圖3-4所示，HDFS實現共享儲存，一些計算使用MapReduce解決，一些計算使用MPI解決，而還有一些計算需要通過兩者來共同處理。因為MapReduce適合處理資料很大且適合劃分的資料，所以在處理這類資料時就可以用MapReduce做一些過濾，得到基本的向量矩陣，然後通過MPI進一步處理後返回結果，只有整合技術才能更好地解決問題。
注：MPI為訊息傳遞介面，一種並行程式設計技術（可參考MPI相關資料），標準MPI雖然很龐大，但是它的最終目的是服務於程序間通訊這一目標的。
百度現在擁有3個Hadoop叢集，總規模在700臺機器左右，其中有100多臺新機器和600多臺要淘汰的機器（它們的計算能力相當於200多臺新機器），不過其規模還在不斷的增加中。現在每天執行的MapReduce任務在3000個左右，處理資料約120TB/天。
百度為了更好地用Hadoop進行資料處理，在以下幾個方面做了改進和調整：
（1）調整MapReduce策略
限制作業處於執行狀態的任務數；
調整預測執行策略，控制預測執行量，一些任務不需要預測執行；
根據節點記憶體狀況進行排程；
平衡中間結果輸出，通過壓縮處理減少I/O負擔。
（2）改進HDFS的效率和功能
許可權控制，在PB級資料量的叢集上資料應該是共享的，這樣分析起來比較容易，但是需要對許可權進行限制；
讓分割槽與節點獨立，這樣，一個分割槽壞掉後節點上的其他分割槽還可以正常使用；
修改DFSClient選取塊副本位置的策略，增加功能使DFSClient選取塊時跳過出錯的DataNode；
解決VFS（Virtual File System）的POSIX（Portable Operating System Interface of Unix）相容性問題。
（3）修改Speculative的執行策略
採用速率倒數替代速率，防止資料分佈不均時經常不能啟動預測執行情況的發生；
增加任務時必須達到某個百分比後才能啟動預測執行的限制，解決reduce執行等待map資料的時間問題；
只有一個map或reduce時，可以直接啟動預測執行。
（4）對資源使用進行控制
對應用實體記憶體進行控制。如果記憶體使用過多會導致作業系統跳過一些任務，百度通過修改Linux核心對程序使用的實體記憶體進行獨立的限制，超過閾值可以終止程序。
分組排程計算資源，實現儲存共享、計算獨立，在Hadoop中執行的程序是不可搶佔的。
在大塊檔案系統中，x86平臺下一個頁的大小是4KB。如果頁較小，管理的資料就會很多，會增加資料操作的代價並影響計算效率，因此需要增加頁的大小。
百度在使用Hadoop時也遇到了一些問題，主要有：
MapReduce的效率問題：比如，如何在shuffle效率方面減少I/O次數以提高並行效率；如何在排序效率方面設定排序為可配置的，因為排序過程會浪費很多的計算資源，而一些情況下是不需要排序的。
HDFS的效率和可靠性問題：如何提高隨機訪問效率，以及資料寫入的實時性問題，如果Hadoop每寫一條日誌就在HDFS上儲存一次，效率會很低。
記憶體使用的問題：reducer端的shuffle會頻繁地使用記憶體，這裡採用類似Linux的buddy system來解決，保證Hadoop用最小的開銷達到最高的利用率；當Java 程序內容使用記憶體較多時，可以調整垃圾回收（GC）策略；有時存在大量的記憶體複製現象，這會消耗大量CPU資源，同時還會導致記憶體使用峰值極高，這時需要減少記憶體的複製。
作業排程的問題：如何限制任務的map和reduce計算單元的數量，以確保重要計算可以有足夠的計算單元；如何對TaskTracker進行分組控制，以限制作業執行的機器，同時還可以在使用者提交任務時確定執行的分組並對分組進行認證。
效能提升的問題：UserLogs cleanup在每次task結束的時候都要檢視一下日誌，以決定是否清除，這會佔用一定的任務資源，可以通過將清理執行緒從子Java程序移到TaskTracker來解決；子Java程序會對文字行進行切割而map和reduce程序則會重新切割，這將造成重複處理，這時需要關掉Java程序的切割功能；在排序的時候也可以實現並行排序來提升效能；實現對資料的非同步讀寫也可以提升效能。
健壯性的問題：需要對mapper和reducer程式的記憶體消耗進行限制，這就要修改Linux核心，增加其限制程序的實體記憶體的功能；也可以通過多個map程式共享一塊記憶體，以一定的代價減少對實體記憶體的使用；還可以將DataNode和TaskTracker的UGI配置為普通使用者並設定賬號密碼；或者讓DataNode和TaskTracker分賬號啟動，確保HDFS資料的安全性，防止Tracker操作DataNode中的內容；在不能保證使用者的每個程式都很健壯的情況下，有時需要將程序終止掉，但要保證父程序終止後子程序也被終止。
Streaming侷限性的問題：比如，只能處理文字資料，mapper和reducer按照文字行的協議通訊，無法對二進位制的資料進行簡單處理。為了解決這個問題，百度人員新寫了一個類Bistreaming（Binary Streaming），這裡的子Java程序mapper和reducer按照（KeyLen，Key，ValLen，Value）的方式通訊，使用者可以按照這個協議編寫程式。
使用者認證的問題：這個問題的解決辦法是讓使用者名稱、密碼、所屬組都在NameNode和Job Tracker上集中維護，使用者連線時需要提供使用者名稱和密碼，從而保證資料的安全性。
記憶體方面，降低NameNode的記憶體使用並研究JVM的記憶體管理；
排程方面，改進任務可以被搶佔的情況，同時開發出自己的基於Capacity的作業排程器，讓等待作業佇列具有優先順序且佇列中的作業可以設定Capacity，並可以支援TaskTracker分組；
壓縮演算法，選擇較好的方法提高壓縮比、減少儲存容量，同時選取高效率的演算法以進行shuffle資料的壓縮和解壓；
對mapper程式和reducer程式使用的資源進行控制，防止過度消耗資源導致機器宕機。以前是通過修改Linux核心來進行控制的，現在考慮通過在Linux中引入cgroup來對mapper和reducer使用的資源進行控制；
將DataNode的併發資料讀寫方式由多執行緒改為select方式，以支援大規模併發讀寫和Hypertable的應用。
百度同時也在使用Hypertable，它是以Google釋出的BigTable為基礎的開源分散式資料儲存系統，百度將它作為分析使用者行為的平臺，同時在元資料集中化、記憶體佔用優化、叢集安全停機、故障自動恢復等方面做了一些改進。