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