百度作爲全球最大的中文搜索引擎公司，提供基於搜索引擎的各種產品，包括以網絡搜索爲主的功能性搜索；以貼吧爲主的社區搜索；針對區域、行業的垂直搜索、MP3音樂搜索，以及百科等，幾乎覆蓋了中文網絡世界中所有的搜索需求。
百度對海量數據處理的要求是比較高的，要在線下對數據進行分析，還要在規定的時間內處理完並反饋到平臺上。百度在互聯網領域的平臺需求如圖3-3所示，這裏就需要通過性能較好的雲平臺進行處理了，Hadoop就是很好的選擇。在百度，Hadoop主要應用於以下幾個方面：
日誌的存儲和統計；
網頁數據的分析和挖掘；
商業分析，如用戶的行爲和廣告關注度等；
在線數據的反饋，及時得到在線廣告的點擊情況；
用戶網頁的聚類，分析用戶的推薦度及用戶之間的關聯度。
MapReduce 主要是一種思想，不能解決所有領域內與計算有關的問題，百度的研究人員認爲比較好的模型應該如圖3-4所示，HDFS實現共享存儲，一些計算使用 MapReduce解決，一些計算使用MPI解決，而還有一些計算需要通過兩者來共同處理。因爲MapReduce適合處理數據很大且適合劃分的數據，所 以在處理這類數據時就可以用MapReduce做一些過濾，得到基本的向量矩陣，然後通過MPI進一步處理後返回結果，只有整合技術才能更好地解決問題。
 |
| 圖3-3 互聯網領域的平臺需求 |
百度現在擁有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爲基礎的開源分佈式數據存儲系統，百度將它作爲分析用戶行爲的平臺，同時在元數據集中化、內存佔用優化、集羣安全停機、故障自動恢復等方面做了一些改進。
Facebook 作爲全球知名的社交網站，擁有超過3億的活躍用戶，其中約有3千萬用戶至少每天更新一次自己的狀態；用戶每月總共上傳10億餘張照片、1千萬個視頻；以及 每週共享10億條內容，包括日誌、鏈接、新聞、微博等。因此Facebook需要存儲和處理的數據量是非常巨大的，每天新增加4TB壓縮後的數據，掃描 135TB大小的數據，在集羣上執行Hive任務超過7500次，每小時需要進行8萬次計算，所以高性能的雲平臺對Facebook來說是非常重要的，而 Facebook主要將Hadoop平臺用於日誌處理、推薦系統和數據倉庫等方面。
Facebook 將數據存儲在利用Hadoop/Hive搭建的數據倉庫上，這個數據倉庫擁有4800個內核，具有5.5PB的存儲量，每個節點可存儲12TB大小的數 據，同時，它還具有兩層網絡拓撲，如圖3-5所示。Facebook中的MapReduce集羣是動態變化的，它基於負載情況和集羣節點之間的配置信息可 動態移動。
 |
| （點擊查看大圖）圖3-5 集羣的網絡拓撲 |
圖 3-6爲Facebook的數據倉庫架構，在這個架構中，網絡服務器和內部服務生成日誌數據，這裏Facebook使用開源日誌收集系統，它可以將數以百 計的日誌數據集存儲在NFS服務器上，但大部分日誌數據會複製到同一個中心的HDFS實例中，而HDFS存儲的數據都會放到利用Hive構建的數據倉庫 中。Hive提供了類SQL的語言來與MapReduce結合，創建併發布多種摘要和報告，以及在它們的基礎上進行歷史分析。Hive上基於瀏覽器的接口 允許用戶執行Hive查詢。Oracle和MySQL數據庫用來發布這些摘要，這些數據容量相對較小，但查詢頻率較高並需要實時響應。一些舊的數據需要及 時歸檔，並存儲在較便宜的存儲器上，如圖3-7所示。
 |
| （點擊查看大圖）圖3-6 Facebook數據倉庫架構 |
下 面介紹Facebook在AvatarNode和調度策略方面所做的一些工作。AvatarNode主要用於HDFS的恢復和啓動，若HDFS崩潰，原有 技術恢復首先需要花10～15分鐘來讀取12GB的文件鏡像並寫回，還要用20～30分鐘處理來自2000個DataNode的數據塊報告，最後用 40～60分鐘來恢復崩潰的NameNode和部署軟件。表3-1說明了BackupNode和AvatarNode的區別，AvatarNode作爲普 通的NameNode啓動，處理所有來自DataNode的消息。AvatarDataNode與DataNode相似，支持多線程和針對多個主節點的多 隊列，但無法區分原始和備份。人工恢復使用AvatarShell命令行工具，AvatarShell執行恢復操作並更新ZooKeeper的 zNode，恢復過程對用戶來說是透明的。分佈式Avatar文件系統實現在現有文件系統的上層。
 |
| （點擊查看大圖）圖3-7 數據歸檔 |
表3-1 BackupNode和AvatarNode的區別
 |
基 於位置的調度策略在實際應用中存在着一些問題：如需要高內存的任務可能會被分配給擁有低內存的TaskTracker；CPU資源有時未被充分利用；爲不 同硬件的TaskTracker進行配置也比較困難等。Facebook採用基於資源的調度策略，即公平享有調度方法，實時監測系統並收集CPU和內存的 使用情況，調度器會分析實時的內存消耗情況，然後在任務之間公平分配任務的內存使用量。它通過讀取/proc/目錄解析進程樹，並收集進程樹上所有的 CPU和內存的使用信息，然後通過TaskCounters在心跳（heartbeat）時發送信息。
Facebook 的數據倉庫使用Hive，其構架如圖3-8所示，有關Hive查詢語言的相關知識可查閱第11章的內容。這裏HDFS支持三種文件格式：文本文件 （TextFile），方便其他應用程序讀寫；順序文件（SequenceFile），只有Hadoop能夠讀取並支持分塊壓縮；RCFile，使用順序 文件基於塊的存儲方式，每個塊按列存儲，這樣有較好的壓縮率和查詢性能。Facebook未來會在Hive上進行改進，以支持索引、視圖、子查詢等新功 能。
 |
| （點擊查看大圖）圖3-8 Hive的體系結構 |
現在Facebook使用Hadoop遇到的挑戰有：
服務質量和隔離性方面，較大的任務會影響集羣性能；
安全性方面，如果軟件漏洞導致NameNode事務日誌崩潰該如何處理；
數據歸檔方面，如何選擇歸檔數據，以及數據如何歸檔；
性能提升方面，如何有效地解決瓶頸等。