從零構(gòu)建大數(shù)據(jù)平臺方面的經(jīng)驗分享

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