從日志統(tǒng)計(jì)到大數(shù)據(jù)分析

首先，我們回到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ù)人員按照需求文檔的格式要求，填寫統(tǒng)計(jì)需求，提交到需求管理平臺(tái)上，Nslog的團(tuán)隊(duì)負(fù)責(zé)人(開始不是我負(fù)責(zé))每周末，將需求分別分配給團(tuán)隊(duì)的幾個(gè)成員。每個(gè)成員拿到需求列表之后，就挨著做。需求的實(shí)現(xiàn)，一般都是寫 Perl 腳本，那個(gè)時(shí)候 Python 還沒流行起來。因?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ì)腳本的邏輯大概是這樣的：通過Wget從數(shù)據(jù)源服務(wù)器上抓取按小時(shí)切割的日志文件，完成后，跑統(tǒng)計(jì)邏輯，將生成的結(jié)果組織成HTML表格，郵件發(fā)送給相應(yīng)的團(tuán)隊(duì)。如下圖所示：

(圖1 使用單機(jī)腳本跑統(tǒng)計(jì))

這種模式有以下幾個(gè)問題：

(1)需求響應(yīng)周期長：從拿到需求，要和需求提出者確認(rèn)需求細(xì)節(jié)，找一個(gè)類似的腳本修改，測(cè)試邏輯正確性，測(cè)試數(shù)據(jù)正確性，安排運(yùn)維同學(xué)部署上線，平均每個(gè)需求要2天時(shí)間。這里還沒算需求的等待時(shí)間，這可能要等一兩周。

(2)運(yùn)維成本高：20臺(tái)統(tǒng)計(jì)服務(wù)器，每臺(tái)機(jī)器通過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)常抱怨就沒有哪一天能睡好覺的。

(3)運(yùn)行速度慢：因?yàn)槊總€(gè)腳本只能單機(jī)運(yùn)行，對(duì)于像知道、貼吧這樣的大流量業(yè)務(wù)線，每天原始日志就有好幾百G，光跑個(gè)排序就得好幾個(gè)小時(shí)。特別是像貼吧被人爆吧，數(shù)據(jù)量一下子就會(huì)增加很多，統(tǒng)計(jì)結(jié)果跑不出來。如果分成每臺(tái)機(jī)器跑一部分，維護(hù)代價(jià)非常大。

(4)職業(yè)發(fā)展瓶頸：那個(gè)時(shí)候還沒有大數(shù)據(jù)的概念，大家對(duì)數(shù)據(jù)的價(jià)值也沒現(xiàn)在這么認(rèn)可，甚至連招聘面試時(shí)，也是把能力一般的分配到統(tǒng)計(jì)團(tuán)隊(duì)。而寫腳本滿足需求這樣的工作是很枯燥的，對(duì)一個(gè)新人，寫上三個(gè)月會(huì)覺得能學(xué)到不少東西，寫六個(gè)月，就開始反感了，寫一年，就堅(jiān)決要求轉(zhuǎn)崗或走人了。

當(dāng)時(shí)我們的技術(shù)經(jīng)理(同時(shí)管理了知道、百科、Nslog 三個(gè)團(tuán)隊(duì))就覺得要做一套系統(tǒng)首要解決運(yùn)維成本高的問題。但已有團(tuán)隊(duì)的人員光滿足需求都忙不過來了，就從百科團(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)新人的成長。于是我們?nèi)齻€(gè)人開始梳理需求和考慮設(shè)計(jì)方案。

盤古開天地一

設(shè)計(jì)一套日志統(tǒng)計(jì)平臺(tái)的需求來源主要是Nslog的研發(fā)和運(yùn)維同學(xué)，整理了好幾十條，并出了一個(gè)基本的方案。我當(dāng)時(shí)覺得實(shí)現(xiàn)一個(gè)提升運(yùn)維管理的系統(tǒng)不難，難的是怎么是好用的?我很關(guān)心怎么提升需求處理的效率問題。這個(gè)時(shí)候其中一個(gè)人又被調(diào)到了一個(gè)基礎(chǔ)庫團(tuán)隊(duì)。也就是做這件事的就只剩我和校招新人了。而我們兩個(gè)都還沒做過需求處理，也不知道那幾百個(gè)腳本里面都寫的什么玩意兒。我說咱倆每人至少要看三個(gè)腳本，再抽查一些，看看這些腳本都有什么規(guī)律沒有。我研究了之后，發(fā)現(xiàn)還是有些規(guī)律的。

我發(fā)現(xiàn)常見的統(tǒng)計(jì)有這么三類：

(1)計(jì)數(shù)統(tǒng)計(jì)：那個(gè)時(shí)代是流量時(shí)代，許多統(tǒng)計(jì)就是算PV(Page View)。一般是在 Apache Web Server日志中，去用正則表達(dá)式匹配滿足某些條件的記錄，做計(jì)數(shù)。

(2)去重統(tǒng)計(jì)：比如獨(dú)立 IP 數(shù)，獨(dú)立用戶數(shù)等。

(3)Top N統(tǒng)計(jì)：比如昨天檢索量最大的100個(gè)Query是什么。

我就問一直做統(tǒng)計(jì)的一位同學(xué)，這三類能不能占到所有統(tǒng)計(jì)需求的80%，他想了一下說有的。于是我就說咱們只要設(shè)計(jì)的系統(tǒng)，能夠?qū)⑦@部分的需求處理工作量降下來，我們的系統(tǒng)就是成功的。這個(gè)時(shí)候技術(shù)經(jīng)理又從其他團(tuán)隊(duì)借調(diào)了一個(gè)前端同學(xué)過來支援幾周。我和校招新人都不會(huì)前端開發(fā)，這事兒沒專業(yè)的人來搞不定。在接下來的兩周時(shí)間，我就和前端同學(xué)研究怎么設(shè)計(jì)這部分的抽象。前端同學(xué)先提了一個(gè)方案，類似于 Dreamweaver中的頁面HTML編輯界面，點(diǎn)選一個(gè)元素，可以進(jìn)行修改配置。我覺得這種方案，還沒直接寫腳本效率高呢。

我從awk腳本語言獲取了靈感。在awk語言中，都是awk condition { action } 這種模式，就是condition定義了滿足的限制條件，action是執(zhí)行的操作。比如：

awk ‘$6 == “Nov” { sum += $5 } END { print sum }’ ./test.txt

就是把test.txt中，滿足第6列等于 “Nov” 的記錄，計(jì)算第5列的求和。

對(duì)于常見的那三類統(tǒng)計(jì)需求，都是一種統(tǒng)計(jì)類型，加上一堆限制條件。為了降低限制條件的難度，我讓所有的條件之間只支持AND操作，不支持OR操作。我們知道AND和 NOT完全可以表示出來OR。

設(shè)計(jì)出來的效果是這樣的：

(圖2 簡單編輯界面)

上面是一個(gè)去重統(tǒng)計(jì)的例子，我選擇一個(gè)日志源，點(diǎn)擊“去重統(tǒng)計(jì)”按鈕，生成一個(gè)模版，填寫限制條件。一個(gè)統(tǒng)計(jì)任務(wù)就生成了。這里沒有顯示出來的是，每個(gè)日志源，都有一個(gè)對(duì)應(yīng)的agent函數(shù)，所做的事是一段解析程序，將原始日志解析成若干個(gè)變量，如圖中的去重字段部分，類似“_UserId”，這樣在統(tǒng)計(jì)模板中就可以直接使用了。這樣做了之后，可以讓一個(gè)統(tǒng)計(jì)任務(wù)的開發(fā)工作量，降低到5分鐘。

還有一個(gè)問題是計(jì)算性能問題。

盤古開天地二

當(dāng)時(shí)Hadoop剛推出，還只是測(cè)試版。對(duì)于它能解決多少問題，我們心里是沒底的。在百度內(nèi)部已經(jīng)有少量的需求在嘗試使用，手工寫 MapReduce 代碼的方式。我也嘗試寫了一個(gè)，還是比較容易的，但有一定的學(xué)習(xí)代價(jià)。系統(tǒng)部有一個(gè)團(tuán)隊(duì)，在負(fù)責(zé)Hadoop 的維護(hù)。為了保險(xiǎn)，我把底層計(jì)算接口設(shè)計(jì)成兩套，同樣的代碼，既可以提交到Hadoop，又可以提交到單機(jī)。在單機(jī)上用腳本串起來，模擬在集群上的運(yùn)行。Hadoop本身支持將任務(wù)分割為Mapper和Reducer兩個(gè)階段，我又增加了一個(gè)Computer階段，作用是將Reducer的結(jié)果(一般是統(tǒng)計(jì)數(shù)值)拿到執(zhí)行機(jī)(分布式提交任務(wù)的節(jié)點(diǎn))，并將其插入到數(shù)據(jù)庫。我當(dāng)時(shí)的想法是如果Hadoop不靠譜，我就把這20臺(tái)單機(jī)，組成一個(gè)小集群，管理提交的任務(wù)。當(dāng)然，這樣的話就實(shí)現(xiàn)不了單個(gè)任務(wù)的分布式化了。

整個(gè)架構(gòu)圖是這樣的：

(圖3 初版日志統(tǒng)計(jì)平臺(tái)架構(gòu)圖)

其中Code Engine和CWrapper是我設(shè)計(jì)和實(shí)現(xiàn)的，Scheduler和數(shù)據(jù)庫表設(shè)計(jì)是校招新人實(shí)現(xiàn)的，Web UI是后來加入的實(shí)習(xí)生花了一周時(shí)間找了個(gè)網(wǎng)上的模板改的。日志的上傳是運(yùn)維同學(xué)開發(fā)的。為了說服運(yùn)維同學(xué)完成部分開發(fā)工作，承諾讓其將所有的數(shù)據(jù)上傳之后，再更新數(shù)據(jù)庫里的數(shù)據(jù)源就緒狀態(tài)。

在這個(gè)系統(tǒng)實(shí)現(xiàn)中，我們把PHP用到了極致，Web UI是PHP的，后端的幾個(gè)模塊是 PHP的，就連生成的 MapReduce代碼，也是PHP的。有人可能會(huì)對(duì)PHP的運(yùn)算性能有疑問，當(dāng)時(shí)負(fù)責(zé)Hadoop維護(hù)的同學(xué)為了推動(dòng)更多的人使用，承諾我們100多臺(tái)機(jī)器隨便用，不用考慮性能問題，缺機(jī)器了他們直接申請(qǐng)加，我們就沒這方面的考慮。PHP 的開發(fā)效率還是很高的，我的 Code Engine 實(shí)現(xiàn)任務(wù)配置到 MapReduce 代碼的編譯，最初的版本只花了我2個(gè)小時(shí)，140行代碼。

就這樣，一個(gè)偉大的系統(tǒng)經(jīng)過兩三個(gè)月的時(shí)間拼湊完成了。其實(shí)到快發(fā)布，還沒有名字。有一天經(jīng)理問我叫什么，我說就叫 Log Statistics Platform的前三個(gè)字母LSP，于是就有了名字(之后我為了方便記憶，讓大家把平臺(tái)叫做 Log 平臺(tái))。

平臺(tái)帶來了幾點(diǎn)好處：

(1)需求響應(yīng)周期大大縮短：因?yàn)閷?duì)常用的三類統(tǒng)計(jì)做了很好的抽象，即使產(chǎn)品同學(xué)都能直接配置統(tǒng)計(jì)任務(wù)，開發(fā)周期從2天時(shí)間降低到5分鐘。并且統(tǒng)計(jì)需求的處理，完全交還給了各個(gè)業(yè)務(wù)方，沒有了需求等待時(shí)間。

(2)運(yùn)維成本大大降低：由統(tǒng)一的系統(tǒng)進(jìn)行任務(wù)的管理，具有依賴關(guān)系的管理，大大降低了出錯(cuò)帶來的恢復(fù)成本。

(3)運(yùn)行速度飛快：我現(xiàn)在仿佛還能回憶起從平臺(tái)上提交第一個(gè)任務(wù)時(shí)的感覺，以前幾個(gè)小時(shí)才能跑完的任務(wù)，只需要幾分鐘就跑完了。我之前擔(dān)心的 Hadoop 不能覆蓋所有統(tǒng)計(jì)需求的問題，也不存在。

(4)組員積極性變高，終于在干一件有點(diǎn)技術(shù)含量的事了。

盤古開天地三

平臺(tái)在2009年4月正式發(fā)布后，各個(gè)團(tuán)隊(duì)的需求鋪天蓋地而來，日志源的中轉(zhuǎn)上傳很快就成了瓶頸。都是所有的日志源完成上傳后，才開始統(tǒng)計(jì)計(jì)算，這樣上傳期間的幾個(gè)小時(shí)時(shí)間就白白浪費(fèi)掉了。我們首先將日志上傳改成每份完成后單獨(dú)打就緒標(biāo)記。后來有次和 Hadoop 團(tuán)隊(duì)的同學(xué)溝通，我就提起能不能每個(gè) Mapper 作為一個(gè)日志抓取的任務(wù)，這樣可以讓100多臺(tái)機(jī)器同時(shí)抓數(shù)據(jù)，他們說沒問題，已經(jīng)有團(tuán)隊(duì)這么干。于是我們很快上線了新版本，實(shí)現(xiàn)分布式的抓取。

架構(gòu)改成了這樣：

(圖4 分布式抓取架構(gòu))

這時(shí)候的產(chǎn)品，已經(jīng)是一個(gè)比較完整的產(chǎn)品了，我開始在公司范圍內(nèi)推廣。本來公司里有十幾個(gè)類似我們的統(tǒng)計(jì)團(tuán)隊(duì)，我就是要說服他們把任務(wù)遷移到我們平臺(tái)。記得很深刻的一次是和網(wǎng)頁搜索部的統(tǒng)計(jì)團(tuán)隊(duì)溝通，他們看了演示之后很震驚，說本來他們只是在設(shè)想這種系統(tǒng)的可能性，沒想到你們已經(jīng)做出來了。當(dāng)時(shí)我們又入職了一位同學(xué)專門負(fù)責(zé)響應(yīng)需求，有一天，業(yè)務(wù)部門的同學(xué)反饋說不能加他好友了(我們用的是百度自己的聊天軟件 Baidu Hi)，我們就找 Hi 團(tuán)隊(duì)的同事咨詢，他們說這位同學(xué)到了好友上限2000人，之前還沒遇到過這種情況。他們的解決方案是修改人數(shù)配置，重啟整個(gè) Baidu Hi 服務(wù)。

在整個(gè)推廣的過程中，我就像拿著一款先進(jìn)設(shè)備，去拯救那些水深火熱的人們。我們一邊推廣，一邊完善整個(gè)平臺(tái)。

從最開始平臺(tái)是為統(tǒng)計(jì)而生，但我漸漸的發(fā)現(xiàn)，統(tǒng)計(jì)只是一類需求，其他Hadoop任務(wù)，也可以通過我們這個(gè)平臺(tái)管理起來。我就想將Log平臺(tái)發(fā)展為Hadoop的殼，所有提交給Hadoop的任務(wù)，都能通過Log平臺(tái)管理起來。Log平臺(tái)演化成一個(gè)通用計(jì)算平臺(tái)。

我前面提到通過三類常見統(tǒng)計(jì)的抽象，來解決80%的問題。但當(dāng)這80%需求解決之后，你會(huì)發(fā)現(xiàn)又有新的80%的需求冒出來。如果讓用戶直接寫MapReduce任務(wù)提交，這個(gè)代價(jià)太大了。平臺(tái)開始上線時(shí)，提交任務(wù)就支持兩種模式。一種是簡單編輯，就是前面的三類抽象(后來加了更多的類別)。一種就是復(fù)雜編輯，直接貼MapReduce代碼。對(duì)于后者，如果能抽象一個(gè)更好用的計(jì)算框架，將MapReduce隱藏起來，顯然就又可以提升開發(fā)效率了。

我就安排一個(gè)工程師(目前是我的合伙人之一)出一個(gè)方案，只用了一周時(shí)間，就設(shè)計(jì)出來原型了。下面是個(gè)例子(我們叫它 DQuery)：

(圖5 DQuery 代碼樣例)

對(duì)于一個(gè)輸入，我們可以去選擇某些字段，進(jìn)行分組，每組在計(jì)數(shù)，然后輸出到一個(gè)文件。這樣就實(shí)現(xiàn)了一個(gè)統(tǒng)計(jì)任務(wù)。這種鏈?zhǔn)降奶幚矸绞?，在現(xiàn)代已經(jīng)很普遍了，特別是 Spark 里都是采用的類似表示方法。我們?cè)?009底做了這個(gè)事情，在2011年公司號(hào)召多提交專利時(shí)，提交了發(fā)明專利。今年3月初時(shí)，專利剛被審核通過。這種將數(shù)據(jù)流式的進(jìn)行變換的思想，已經(jīng)見諸于各大分布式計(jì)算系統(tǒng)。

在給出 DQuery 原型后，我覺得團(tuán)隊(duì)太弱小了，只能有一個(gè)全職參與這件事。于是找基礎(chǔ)庫團(tuán)隊(duì)的同學(xué)尋求支持。他們最開始提出何不實(shí)現(xiàn)一個(gè) Google Sawzall，但我覺得太底層了。最終說服對(duì)方安排一位工程師參與進(jìn)來。結(jié)果就是他們兩個(gè)人花了2個(gè)半月，就把這個(gè)語言開發(fā)出來了。

可能你會(huì)問為什么當(dāng)時(shí)不選擇使用 Hive?事實(shí)上，那個(gè)時(shí)候 Hive 的工程師也來公司交流和推廣了。但有兩個(gè)需求不好滿足：

(1)任務(wù)合并：對(duì)于同一個(gè)數(shù)據(jù)源，可能有幾百個(gè)統(tǒng)計(jì)任務(wù)。這種統(tǒng)計(jì)任務(wù)可能都很簡單，但是都要將數(shù)據(jù)源讀取一遍，也就是一個(gè)高 IO 低 CPU 的任務(wù)。我們當(dāng)時(shí)想直接讀取一遍，然后將多個(gè)任務(wù)同時(shí)計(jì)算，這樣效率會(huì)高很多。這在 Hive 上是不支持的。

(2)用戶行為分析：我當(dāng)時(shí)比較樂觀，覺得我一年解決統(tǒng)計(jì)問題，第二年解決分析問題，第三年解決挖掘問題。事實(shí)上到現(xiàn)在分析問題也沒解決徹底。我們知道 Hive 是基于 SQL 的，而 SQL 是上下文無關(guān)的。也就是說你取出的一批數(shù)據(jù)，有前后關(guān)系的話，是很難操作的。我需要在語言上支持。而在 DQuery 語言中，我們?cè)O(shè)計(jì)了一個(gè)方法叫 process，可以嵌入用戶的邏輯，非常靈活。這里要說的是 DQuery 是一個(gè)基于 PHP 語言的框架，這樣 DQuery 表達(dá)不了的，都可以寫原始 PHP 代碼。

就這樣到2010年底的時(shí)候，實(shí)現(xiàn)了全公司日志統(tǒng)計(jì)全部統(tǒng)一到 Log 平臺(tái)。這是我在百度八年，干的最有成就感的一件事情。

秦天下

轉(zhuǎn)眼到了2011年初，那個(gè)時(shí)候團(tuán)隊(duì)已經(jīng)合并到了網(wǎng)頁搜索部的相關(guān)性部門，我感覺這不利于發(fā)展。我的想法是要把團(tuán)隊(duì)面向全公司服務(wù)，甚至成為像 NLP(自然語言處理)部門在廠長心中的地位。但網(wǎng)頁相關(guān)性部門的上司覺得先服務(wù)好本部門就夠了。我和基礎(chǔ)架構(gòu)部的一個(gè)經(jīng)理(最早在百度負(fù)責(zé)維護(hù)和開發(fā) Hadoop 團(tuán)隊(duì)的負(fù)責(zé)人，在他完成了 Hadoop 在全百度的推廣之后，改為負(fù)責(zé)一個(gè)分布式存儲(chǔ)團(tuán)隊(duì)了)商量了一下，覺得兩個(gè)團(tuán)隊(duì)合并，成立一個(gè)專門的數(shù)據(jù)團(tuán)隊(duì)，是一件更有意義的事。兩人一拍即合。基礎(chǔ)架構(gòu)部的老大又從 Google 挖來了一位專家做我們團(tuán)隊(duì)的負(fù)責(zé)人，他之前在 Yahoo 做了7年，Google 做了5年，一直在做數(shù)據(jù)倉庫，絕對(duì)的資深專家，我很崇拜的人。

記得在2011年的7月1日，團(tuán)隊(duì)開了個(gè)All Hands大會(huì)，公司 VP 在講話中說：在中國是 D 說了算，在百度也是 D 說了算，后一個(gè) D 是指 Data 。說起來在百度這八年，百度文化有29條，我第二喜歡的就是“用數(shù)據(jù)說話”，數(shù)據(jù)雖然有欺騙性，但總的來說有數(shù)據(jù)要比沒有數(shù)據(jù)好，它不帶有感情，冷靜客觀。就這樣，我們 DataTeam 成立了，或者叫 DreamTeam。團(tuán)隊(duì)的一線人員一共二十來個(gè)，超過一半是我之前的下屬。

有新總監(jiān)的領(lǐng)導(dǎo)，我們的思路完全被打開了一圈。但在最開始，我們的思路依舊有些混亂，之前的產(chǎn)品還要維護(hù)，想做的新東西很多，我們似乎沒有一個(gè)中心。眼看到了國慶，有一天我問新總監(jiān)他覺得什么最重要，如果只挑一件事情的話，他說是 UDW(User Data Warehouse，意為用戶數(shù)據(jù)倉庫)。我說那咱們核心成員就用來做這個(gè)項(xiàng)目。于是我迅速將 Log 的核心成員，抽調(diào)到了這一項(xiàng)目，在之后的三年里，我的主要精力可以說都是圍繞它展開的。

在新總監(jiān)來到百度之后，很快發(fā)現(xiàn)了我們的數(shù)據(jù)源真叫一個(gè)混亂。公司有上百個(gè)業(yè)務(wù)線，每個(gè)業(yè)務(wù)線的數(shù)據(jù)格式都是不同的。如果你要基于所有的數(shù)據(jù)源做一個(gè)業(yè)務(wù)，比如個(gè)性化推薦，那么需要和所有的業(yè)務(wù)線溝通數(shù)據(jù)格式，并維護(hù)這條飛線。相比之下，在 Google 數(shù)據(jù)源都是被規(guī)范管理的，使用 Protocol Buffer 來規(guī)范數(shù)據(jù)格式。新總監(jiān)認(rèn)為我們要先把數(shù)據(jù)源給統(tǒng)一起來，形成一個(gè)好的數(shù)據(jù)基礎(chǔ)，后續(xù)的數(shù)據(jù)分析完全依賴于它。

對(duì)于這種思路，我是有疑慮的。在2009年的時(shí)候，我就做了一個(gè)叫麥哲倫的用戶行為查詢平臺(tái)，通過輸入一個(gè) ID，返回用戶的行為記錄，主要包括知道，百科，貼吧之類的產(chǎn)品。當(dāng)時(shí)的做法是我把每個(gè)產(chǎn)品線的用戶訪問行為，比如在百度知道提問，用一個(gè) Action ID 來標(biāo)記，這個(gè)行為有一系列屬性。對(duì)于有些屬性，我還和業(yè)務(wù)線建立了專門的接口，用于獲取這些屬性的具體內(nèi)容。比如通過問題的 ID，獲取到問題的標(biāo)題，以保證行為記錄的可讀性。這個(gè)系統(tǒng)是很快建立起來了，但被使用的頻率非常低?；ê艽缶φ淼臄?shù)據(jù)，似乎一時(shí)半會(huì)兒看不到多大價(jià)值。還有個(gè)問題是業(yè)務(wù)線的數(shù)據(jù)格式變更，我的數(shù)據(jù)處理邏輯都要更新，很難維護(hù)。所以這種思路被重新提出時(shí)，我最顧慮的是做出來之后有什么用，在應(yīng)用點(diǎn)不明確的時(shí)候，我們是不是該做這件事。但新總監(jiān)在公司層面很快推動(dòng)達(dá)成了一致，總之是公司支持做這件事情。執(zhí)行從來不是我的問題，既然都確定要做了，我很快就帶著團(tuán)隊(duì)做起來。最開始選擇最核心的八條業(yè)務(wù)線，在2012年的 Q1 季度末，正式對(duì)公司內(nèi)部發(fā)布了。

UDW 做了一件事情，將全公司的每個(gè)業(yè)務(wù)線的每一種用戶行為，定義為一種 Event，這個(gè) Event 包括一系列的屬性，核心的是 UserID，Event Type，事件相關(guān)的其他屬性。這樣，一個(gè)用戶在百度的任意行為就統(tǒng)一到了一張表上。再有人想做數(shù)據(jù)分析，就可以直接用干凈統(tǒng)一的基礎(chǔ)數(shù)據(jù)了。

從數(shù)據(jù)角度來看，是一個(gè)金字塔：

(圖6 數(shù)據(jù)金字塔)

最底層是上百條業(yè)務(wù)線的文本日志，通過 LogFormat 轉(zhuǎn)成 Protocol Buffer 格式。在此基礎(chǔ)上，構(gòu)建 UDW。在 UDW 基礎(chǔ)之上，我們構(gòu)建圍繞各種主題的數(shù)據(jù)，形成 DataMart。比如基于 Query 的基礎(chǔ)數(shù)據(jù)。再進(jìn)一步匯聚，就可以用于 BI 的 Insight。

這里我總結(jié)一下 UDW 思路的優(yōu)缺點(diǎn)。優(yōu)點(diǎn)是為上層應(yīng)用提供了一套統(tǒng)一干凈的基礎(chǔ)數(shù)據(jù)，上層的使用變得非常簡單。一個(gè)廣告團(tuán)隊(duì)，僅僅是將數(shù)據(jù)源切換到 UDW，就提升了接近20%的收入。更何況以前在做個(gè)需要多個(gè)業(yè)務(wù)線數(shù)據(jù)源的應(yīng)用，只需要和我們 UDW 打交道，這減少了多大的工作量和溝通成本。

不好的地方是源頭的數(shù)據(jù)并沒有變更，我們中間是通過 ETL 過程將數(shù)據(jù)接入到 UDW 的，而這個(gè)過程工作復(fù)雜難以維護(hù)，具有很長的滯后性。并且因?yàn)槎嗔艘惠営?jì)算，實(shí)效性也降低了。一些業(yè)務(wù)線開始抱怨，對(duì) UDW 產(chǎn)生了嚴(yán)重依賴，特別是相對(duì)比較獨(dú)立的業(yè)務(wù)線，做這件事完全沒什么好處，還不如根據(jù)原始數(shù)據(jù)來計(jì)算。

在這之后，我又帶著團(tuán)隊(duì)完成了核心數(shù)據(jù)源的日志 Protocol Buffer 改造，并構(gòu)建了新的傳輸、查詢、調(diào)度系統(tǒng)。在2012年初老大給我講 Google 那邊能夠打了日志馬上就可以分析，我都覺得很不可思議，那時(shí)候百度的延遲至少是小時(shí)級(jí)的?？山?jīng)過兩年多的努力，我們也達(dá)到了這一點(diǎn)。以上是我的經(jīng)歷分享，希望能夠給讀者啟發(fā)，少走一些彎路。