從零構建大數據平臺方面的經驗分享

?2008年底，我開始在百度負責一個日志統計的小團隊，開發了一套基于Hadoop的日志統計平臺，結果一年半的時間統一了全百度的日志統計工作。之后一直圍繞數據這一方向，覆蓋數據的采集、傳輸、建模存儲、查詢分析、數據可視化等，打造了全百度的用戶數據倉庫（User Data Warehouse），并推動全公司核心業務線的日志源結構化（Protocol Buffer）。這篇文章講述我在百度從零構建大數據平臺方面的經歷。
　　洪荒年代
　　首先，我們回到2008年。那個時候，我是屬于百度搜索新產品部的，像知道、貼吧、百科等，都屬于這個部門的產品。部門里有個小團隊叫Nslog，一共四個人，其中兩個是實習生，所負責的工作就是部門內的各種需求統計。
　　統計的方式是這樣的，各個產品線的業務人員按照需求文檔的格式要求，填寫統計需求，提交到需求管理平臺上，Nslog的團隊負責人（開始不是我負責）每周末，將需求分別分配給團隊的幾個成員。每個成員拿到需求列表之后，就挨著做。需求的實現，一般都是寫 Perl 腳本，那個時候 Python 還沒流行起來。因為統計需求比較類似，一般都是拿一個已有的腳本復制一份，修改一下，測試邏輯，測試大數據量下的準確性，然后部署到線上去。一共有20臺機器跑統計腳本，每臺機器上都用Crontab配置天級的例行任務。每個統計腳本的邏輯大概是這樣的：通過Wget從數據源服務器上抓取按小時切割的日志文件，完成后，跑統計邏輯，將生成的結果組織成HTML表格，郵件發送給相應的團隊。如下圖所示：
　　
　?。▓D1 使用單機腳本跑統計）
　　這種模式有以下幾個問題：
　?。?）需求響應周期長：從拿到需求，要和需求提出者確認需求細節，找一個類似的腳本修改，測試邏輯正確性，測試數據正確性，安排運維同學部署上線，平均每個需求要2天時間。這里還沒算需求的等待時間，這可能要等一兩周。
　?。?）運維成本高：20臺統計服務器，每臺機器通過Crontab管理了幾十個腳本。這些腳本之間，可能還存在依賴關系，比如凌晨4點跑的一個腳本B，依賴于凌晨2點啟動的某個腳本A。如果腳本A掛了，腳本B還是會正常的啟動?；謴腿蝿辗浅Ｂ闊?，真是牽一發而動全身。運維同學經常抱怨就沒有哪一天能睡好覺的。
　?。?）運行速度慢：因為每個腳本只能單機運行，對于像知道、貼吧這樣的大流量業務線，每天原始日志就有好幾百G，光跑個排序就得好幾個小時。特別是像貼吧被人爆吧，數據量一下子就會增加很多，統計結果跑不出來。如果分成每臺機器跑一部分，維護代價非常大。
　?。?）職業發展瓶頸：那個時候還沒有大數據的概念，大家對數據的價值也沒現在這么認可，甚至連招聘面試時，也是把能力一般的分配到統計團隊。而寫腳本滿足需求這樣的工作是很枯燥的，對一個新人，寫上三個月會覺得能學到不少東西，寫六個月，就開始反感了，寫一年，就堅決要求轉崗或走人了。
　　當時我們的技術經理（同時管理了知道、百科、Nslog 三個團隊）就覺得要做一套系統首要解決運維成本高的問題。但已有團隊的人員光滿足需求都忙不過來了，就從百科團隊借調了兩個人（不包括我）。那時候的我剛從百度知道轉到百科團隊，正想在百科團隊大干一場。借調去的兩個人其中一個是校招新人，我的項目經理就安排我也參與到項目中，培養新人的成長。于是我們三個人開始梳理需求和考慮設計方案。
　　盤古開天地一
　　設計一套日志統計平臺的需求來源主要是Nslog的研發和運維同學，整理了好幾十條，并出了一個基本的方案。我當時覺得實現一個提升運維管理的系統不難，難的是怎么是好用的？我很關心怎么提升需求處理的效率問題。這個時候其中一個人又被調到了一個基礎庫團隊。也就是做這件事的就只剩我和校招新人了。而我們兩個都還沒做過需求處理，也不知道那幾百個腳本里面都寫的什么玩意兒。我說咱倆每人至少要看三個腳本，再抽查一些，看看這些腳本都有什么規律沒有。我研究了之后，發現還是有些規律的。
　　我發現常見的統計有這么三類：
　?。?）計數統計：那個時代是流量時代，許多統計就是算PV（Page View）。一般是在 Apache Web Server日志中，去用正則表達式匹配滿足某些條件的記錄，做計數。
　?。?）去重統計：比如獨立 IP 數，獨立用戶數等。
　?。?）Top N統計：比如昨天檢索量最大的100個Query是什么。
　　我就問一直做統計的一位同學，這三類能不能占到所有統計需求的80%，他想了一下說有的。于是我就說咱們只要設計的系統，能夠將這部分的需求處理工作量降下來，我們的系統就是成功的。這個時候技術經理又從其他團隊借調了一個前端同學過來支援幾周。我和校招新人都不會前端開發，這事兒沒專業的人來搞不定。在接下來的兩周時間，我就和前端同學研究怎么設計這部分的抽象。前端同學先提了一個方案，類似于 Dreamweaver中的頁面HTML編輯界面，點選一個元素，可以進行修改配置。我覺得這種方案，還沒直接寫腳本效率高呢。
　　我從awk腳本語言獲取了靈感。在awk語言中，都是awk condition { action } 這種模式，就是condition定義了滿足的限制條件，action是執行的操作。比如：
　　awk ‘$6 == “Nov” { sum += $5 } END { print sum }’ 。/test.txt
　　就是把test.txt中，滿足第6列等于 “Nov” 的記錄，計算第5列的求和。
　　對于常見的那三類統計需求，都是一種統計類型，加上一堆限制條件。為了降低限制條件的難度，我讓所有的條件之間只支持AND操作，不支持OR操作。我們知道AND和 NOT完全可以表示出來OR。
　　設計出來的效果是這樣的：
　　
　?。▓D2 簡單編輯界面）
　　上面是一個去重統計的例子，我選擇一個日志源，點擊“去重統計”按鈕，生成一個模版，填寫限制條件。一個統計任務就生成了。這里沒有顯示出來的是，每個日志源，都有一個對應的agent函數，所做的事是一段解析程序，將原始日志解析成若干個變量，如圖中的去重字段部分，類似“_UserId”，這樣在統計模板中就可以直接使用了。這樣做了之后，可以讓一個統計任務的開發工作量，降低到5分鐘。
　　還有一個問題是計算性能問題。
　　盤古開天地二
　　當時Hadoop剛推出，還只是測試版。對于它能解決多少問題，我們心里是沒底的。在百度內部已經有少量的需求在嘗試使用，手工寫 MapReduce 代碼的方式。我也嘗試寫了一個，還是比較容易的，但有一定的學習代價。系統部有一個團隊，在負責Hadoop 的維護。為了保險，我把底層計算接口設計成兩套，同樣的代碼，既可以提交到Hadoop，又可以提交到單機。在單機上用腳本串起來，模擬在集群上的運行。Hadoop本身支持將任務分割為Mapper和Reducer兩個階段，我又增加了一個Computer階段，作用是將Reducer的結果（一般是統計數值）拿到執行機（分布式提交任務的節點），并將其插入到數據庫。我當時的想法是如果Hadoop不靠譜，我就把這20臺單機，組成一個小集群，管理提交的任務。當然，這樣的話就實現不了單個任務的分布式化了。