百度技術沙龍（第2期）- 2. 互連網應用服務擴充的一點經驗

源地址：http://www.infoq.com/cn/presentations/maruyue-ls-data-processing

 

在百度技術沙龍第2期（5月15日）的活動上，我們邀請到了百度分布式進階工程師馬如悅以及FreeWheel的核心系統技術總監王迪分別分享了關於分布式以及服務擴充兩個話題，本文將對他們的演講內容進行一下簡單的總結，並為大家提供了示範文檔的下載。

為Hadoop的發展貢獻自己的力量

在馬如悅的演講中，他主要介紹了百度的大規模資料存放區、資料分析以及資料索引，主要包括以下內容點：

• 大規模資料存放區
  • Lustre和HDFS
  • 系統結構
  • HDFS優勢、不足
• 大規模資料分析
  • MPI和MapReduce
  • MapReduce概念性模型、實現模型
  • MapReduce-Hadoop實現
• 大規模資料索引
  • MySQL和HBase對比
  • HBase詳解
• 在以上三方面百度遇到的問題、對策和原則

其中，馬如悅提到，百度現在要處理的資料量非常龐大：儲存20PB+資料，每日新增資料10TB+，每天處理的資料1PB+，每天提交10K+次作業。現在使用的檔案系統是HDFS，資料存放區是HBase，有超過2K台伺服器節點，每個節點為2*4 core。現在遇到的一個棘手問題便是namenode的瓶頸問題：因為要儲存大量的（小）檔案，使namenode的壓力非常大，他們剛剛採購了48GB的記憶體，但是這48GB的記憶體，預計只能堅持到今年年底，到時候，可能會採購96GB的記憶體來緊急應對這個問題。所以百度在namenode的分布式方面，進行了很多研究。馬如悅建議大家：

如果對這方面感興趣的話，可以參考Linux 2.6.34中的Ceph檔案系統，它就是一個基於PB規模的Distributed File System。

最後，馬如悅提到了百度目前正在重點研究/解決的幾個問題/方向，他建議如果大家想對Hadoop做出一些成績的話，這幾個方向也是現在的熱點：

• HDFS namenode的分布式改進
• HDFS datanode的讀寫非同步化
• MapReduce的jobtracker的分布式改進
• MapReduce的新作業和任務調度器
• MapReduce的Hadoop C++擴充架構

有讀者對Hadoop C++的擴充非常感興趣，馬如悅對此闡述了一下百度Hadoop的使用方式：

我們會定期在Hadoop的官方版本上找到一個穩定版本，然後進行自訂開發。過一段時間，當我們發現官方的版本如果增加了很多新增加的功能，比我們好很多，我們再開一個新的分支，把我們的功能移上去。我們的工程師在開發Hadoop的C++擴充，我們大概是在0.19版分出來的，至今我們發現chunk版本仍然跑不過百度自己的版本，所以我們不會去做移植。HCE在我們的版本上開發的，所以如果轉移到chunk上，會有些難度，需要做一些調整，這會花費一些時間。上周我們工程師剛完成了一個版本，馬上就可以為大家貢獻出一個連結去試用。

以資料驅動為中心

王迪是FreeWheel核心系統的技術總監，從07年FreeWheel創立起，他全程參與到其廣告核心系統的架構設計，也見證了FreeWheel從最初的的只有20台廣告伺服器、日均幾十萬的訪問量、不到1G/天的日誌量，發展到現在擁有60台廣告伺服器、日均廣告要求5000萬次、Tlog伺服器8台、日均4小時處理日誌200G這麼一個規模。3年之間，流量增長20倍。他主要談到了以下的一些經驗和原則：

• 應用服務擴充
  • 無狀態應用服務
  • 複製與多層次Cache
• 資料倉儲擴充
  • De-normalization/Pivot
  • Roll up/Data Availability
  • Benchmarking與查詢最佳化
  • Split-Loading/Sharding
• 運營原則
  • 50%運行負載上限 & N+1 Data Center
  • 監控和響應
  • 多階段部署

很多具體的實踐方法，都是針對他們具體的商業模式以及實際工作中摸索出來的，它不一定是“最好”的，但卻是最適合的，比如對系統的負載當達到50%的時候，就是一個最佳化和擴容的訊號了；再比如，以自動化迴歸測試為核心，但並未使用TDD單元測試，等等等等。

在提問環節，有讀者對如何在迴歸測試中組織測試案例高度興趣，王迪解釋到：

比如我們有700個測試案例，需要QA做一些資料，可以用SQL檔案的方式存在本地，然後把請求和預期也同樣以檔案的方式存在本地，然後在架構啟動並執行時候，把它們載入到資料庫當中，然後再服務結束後，再從資料庫中取出來。