解密百度大數據:百度是如何使用hadoop的,并且做了哪些改進?

6 評論 11611 瀏覽 20 收藏 10 分鐘

引讀:百度作為全球最大的中文搜索引擎公司,提供基于搜索引擎的各種產品,幾乎覆蓋了中文網絡世界中所有的搜索需求,因此,百度對海量數據處理的要求是比較高的, 要在線下對數據進行分析,還要在規定的時間內處理完并反饋到平臺上。百度在互聯網領域的平臺需求要通過性能較好的云平臺進行處理了,Hadoop就是很好 的選擇。

 

在百度,Hadoop主要應用于以下幾個方面:

日志的存儲和統計;

網頁數據的分析和挖掘;

商業分析,如用戶的行為和廣告關注度等;

在線數據的反饋,及時得到在線廣告的點擊情況;

用戶網頁的聚類,分析用戶的推薦度及用戶之間的關聯度。

MapReduce主要是一種思想,不能解決所有領域內與計算有關的問題,百度的研究人員認為比較好的模型應該如下圖:

121813vuud7x0jp7umpofq

HDFS?實現共享存儲,一些計算使用MapReduce解決,一些計算使用MPI解決,而還有一些計算需要通過兩者來共同處理。因為MapReduce適合處理數 據很大且適合劃分的數據,所以在處理這類數據時就可以用MapReduce做一些過濾,得到基本的向量矩陣,然后通過MPI進一步處理后返回結果,只有整 合技術才能更好地解決問題。

百度現在擁有3個Hadoop集群,總規模在700臺機器左右,其中有100多臺新機器和600多臺要淘汰的機器(它們的計算能力相當于200多臺新機器),不過其規模還在不斷的增加中?,F在每天運行的MapReduce任務在3000個左右,處理數據約120TB/天。

百度為了更好地用Hadoop進行數據處理,在以下幾個方面做了改進和調整:

(1)調整MapReduce策略

限制作業處于運行狀態的任務數;

調整預測執行策略,控制預測執行量,一些任務不需要預測執行;

根據節點內存狀況進行調度;

平衡中間結果輸出,通過壓縮處理減少I/O負擔。

(2)改進HDFS的效率和功能

權限控制,在PB級數據量的集群上數據應該是共享的,這樣分析起來比較容易,但是需要對權限進行限制;

讓分區與節點獨立,這樣,一個分區壞掉后節點上的其他分區還可以正常使用;

修改DSClient選取塊副本位置的策略,增加功能使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為基礎的開源分布式數據存儲系統,百度將它作為分析用戶行為的平臺,同時在元數據集中化、內存占用優化、集群安全停機、故障自動恢復等方面做了一些改進。

來源:開源中國

 

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 和hadoop實戰第二版(陸嘉恒)第457頁好像。。。。

    來自北京 回復