前幾天翻出了2012年2月在微博上發(fā)出的一條信息（圖1），當(dāng)時(shí)我為什么會(huì)那么興奮，還得從更早的時(shí)候說(shuō)起。

（圖1 2012年的一條微博） 

初次失敗

2010年初，有個(gè)地圖團(tuán)隊(duì)的PM找到我，演示了一份PPT，那是某個(gè)公司的統(tǒng)計(jì)分析系統(tǒng)的對(duì)外交流材料。據(jù)說(shuō)這份材料先是被廠長(zhǎng)看到，覺得做的挺好，就安排下面的人看是否也能做一套。我看了之后，發(fā)現(xiàn)就是針對(duì)某個(gè)互聯(lián)網(wǎng)產(chǎn)品的流量、用戶量的幾個(gè)頁(yè)面展示，針對(duì)地域、渠道等幾個(gè)維度可以展開分析。心想這種系統(tǒng)在我們的Log統(tǒng)計(jì)平臺(tái)上很容易用幾個(gè)任務(wù)實(shí)現(xiàn)出來(lái)。但Log統(tǒng)計(jì)平臺(tái)是以統(tǒng)計(jì)任務(wù)來(lái)管理的，雖然功能強(qiáng)大，但是不利于展示上的組織。對(duì)于一個(gè)業(yè)務(wù)線來(lái)說(shuō)，就是一組報(bào)表，并沒(méi)有層級(jí)管理。相比之下，PPT中演示的系統(tǒng)在界面組織上，就會(huì)好很多。我就給這位PM說(shuō)，這套系統(tǒng)太簡(jiǎn)單了，既然我們要做，就要比他們做的牛逼。我先考慮一下，然后給出一套方案。

就這樣，我和團(tuán)隊(duì)的三四個(gè)兄弟開始考慮如何做一套牛逼的方案，調(diào)研來(lái)調(diào)研去，發(fā)現(xiàn)還是數(shù)據(jù)倉(cāng)庫(kù)教材里介紹的數(shù)據(jù)立方體的模型，適合做這件事。于是拿著這套方案和PM溝通，PM聽了介紹之后，說(shuō)要是真的可以實(shí)現(xiàn)，我們的系統(tǒng)就太強(qiáng)大了。就這么敲定了。那時(shí)的我一是會(huì)希望自己做的事情非常獨(dú)特，超越之前的任何方案，二是根本不會(huì)考慮人力是否能支持，***真正能投入到本項(xiàng)目的也就只有一個(gè)正式員工外加一個(gè)實(shí)習(xí)生。產(chǎn)品方案定了，接下來(lái)就是技術(shù)選型。

數(shù)據(jù)立方體是多維數(shù)據(jù)模型的一個(gè)通俗的叫法，主要由維度和指標(biāo)兩部分組成，比如地域是一個(gè)維度，操作系統(tǒng)也是個(gè)維度，銷售額是一個(gè)指標(biāo)，注冊(cè)用戶數(shù)也是個(gè)指標(biāo)，成單量也是一個(gè)指標(biāo)。那么我們就可以通過(guò)維度組合，看這種組合下的指標(biāo)情況。如圖2：

[[154900]]

（圖2 數(shù)據(jù)立方體的樣例）

通過(guò)這個(gè)數(shù)據(jù)立方體，我們就可以看來(lái)自北京的，使用iOS的銷售額是多少。這個(gè)模型非常清晰和簡(jiǎn)單，難點(diǎn)在于數(shù)據(jù)規(guī)模。我們針對(duì)百度的流量分析，可以拆開多個(gè)維度，比如時(shí)間、地域、渠道、操作系統(tǒng)、瀏覽器版本、頻道、行為類型等。每個(gè)單位時(shí)間內(nèi)，所產(chǎn)生的數(shù)據(jù)條數(shù)就是所有維度的乘積，假設(shè)每個(gè)維度有10個(gè)項(xiàng)目，如果有10個(gè)維度，那么就會(huì)產(chǎn)生10^10 條記錄。每條記錄按1KB大小，那么就是10TB數(shù)據(jù)量。如果在這個(gè)基礎(chǔ)上做計(jì)算，一臺(tái)機(jī)器的性能是顯然撐不住的。

我們就在尋找適合在這種數(shù)據(jù)規(guī)模上進(jìn)行查詢的存儲(chǔ)系統(tǒng)。找來(lái)找去，發(fā)現(xiàn)InfoBright這一存儲(chǔ)引擎最合適，它采用列式存儲(chǔ)，在針對(duì)多維數(shù)據(jù)分析這種模型上，性能很好。但因?yàn)槭菃螜C(jī)的，支持的數(shù)據(jù)規(guī)模有限，我們對(duì)某些維度的元素進(jìn)行了聚合，來(lái)降低數(shù)據(jù)量，***降到半年的累計(jì)數(shù)據(jù)預(yù)計(jì)幾百G。就這樣，我們?cè)诎雮€(gè)正式員工、兩個(gè)實(shí)習(xí)生的人員配置下，開啟了整個(gè)項(xiàng)目。當(dāng)時(shí)我是雄心勃勃，還把部門的高級(jí)總監(jiān)邀請(qǐng)到開發(fā)群里，因?yàn)獒槍?duì)流量數(shù)據(jù)的多維分析，顯然部門老大是最需要的。兩個(gè)月后，悲劇發(fā)生了。

產(chǎn)品是做出來(lái)了，但多個(gè)維度的組合查詢性能一塌糊涂，我有時(shí)候在界面上做了個(gè)查詢，半個(gè)小時(shí)后都還看不到結(jié)果，根本沒(méi)法用，整個(gè)產(chǎn)品只能算個(gè)半吊子的Demo，連部門老大也退出了群。在我這工作的八年的職業(yè)生涯中，有兩個(gè)項(xiàng)目我認(rèn)為是徹底的失敗了，一個(gè)就是這個(gè)cube項(xiàng)目，另一個(gè)是基于impala改進(jìn)的一個(gè)交互式查詢產(chǎn)品，以后有機(jī)會(huì)再介紹。認(rèn)識(shí)到性能問(wèn)題后，我們又嘗試將查詢引擎從InfoBright替換到InfiniDB，只能說(shuō)略好，但沒(méi)有本質(zhì)區(qū)別。

順帶交代兩句這兩個(gè)存儲(chǔ)引擎的命運(yùn)，InfoBright這家波蘭公司的產(chǎn)品，在這兩年轉(zhuǎn)型做針對(duì)物聯(lián)網(wǎng)的存儲(chǔ)引擎了。而InfiniDB在去年的10月1日宣布了破產(chǎn)?？磥?lái)創(chuàng)業(yè)公司純粹做一款數(shù)據(jù)庫(kù)引擎，日子并不會(huì)太好過(guò)。

出了存儲(chǔ)層的問(wèn)題，還有查詢解釋層Mondrian的性能問(wèn)題，以及報(bào)表引擎JPivot的性能問(wèn)題，數(shù)據(jù)導(dǎo)入的性能問(wèn)題，預(yù)處理數(shù)據(jù)的計(jì)算性能問(wèn)題，數(shù)據(jù)字段變更的維護(hù)問(wèn)題等?？傊谝粋€(gè)不合適的時(shí)機(jī)，提出了一個(gè)比較理想化的idea，結(jié)果可想而知了。
 

漸入佳境

這次項(xiàng)目失敗后，我對(duì)數(shù)據(jù)立方體這種理論化的模型產(chǎn)生了懷疑，覺得在現(xiàn)實(shí)場(chǎng)景下走不通，作為數(shù)據(jù)倉(cāng)庫(kù)教材里的內(nèi)容講講幫助理解，還是可以的。又過(guò)了一年，成立了基礎(chǔ)架構(gòu)部數(shù)據(jù)團(tuán)隊(duì)，并從Google聘請(qǐng)了一位總監(jiān)，就是開始我在截圖里提到的“硅谷知青” Alex Lv。他來(lái)百度之前，在Yahoo干過(guò)7年，Google干過(guò)5年，一直圍繞數(shù)據(jù)倉(cāng)庫(kù)方向，可以說(shuō)是這一領(lǐng)域的資深專家，Google的Tenzing引擎，就是他的團(tuán)隊(duì)做出的。他來(lái)了之后，真的是把我的思路打開了一大圈，相比之下，我之前對(duì)數(shù)據(jù)架構(gòu)的理解真的太狹隘了。

他先是給我們提出了數(shù)據(jù)分層的金字塔模型，決定構(gòu)建Baidu Data Warehouse（UDW），能夠?qū)⒂脩粼诎俣人挟a(chǎn)品線的行為統(tǒng)一到一起去。有了這個(gè)地基，剩下的數(shù)據(jù)使用問(wèn)題，就變得容易了。

這就回到了文章開頭我發(fā)微博的那天，Alex Lv給我講解了在UDW基礎(chǔ)之上，將用戶數(shù)據(jù)按照時(shí)間細(xì)粒度匯聚，可以根據(jù)不同維度組合查詢，所有的報(bào)表需求都在這個(gè)基礎(chǔ)上出。相比之下，我們之前的報(bào)表數(shù)據(jù)，都是直接從原始數(shù)據(jù)，經(jīng)過(guò)計(jì)算，生成統(tǒng)計(jì)結(jié)果，計(jì)算效率是很低的，中間數(shù)據(jù)沒(méi)有得到重復(fù)使用。

相比cube項(xiàng)目，常規(guī)報(bào)表數(shù)據(jù)是例行跑出的，而不是實(shí)時(shí)交互，這對(duì)查詢性能要求沒(méi)那么高。在UDW的基礎(chǔ)之上，數(shù)據(jù)立方體的思路我意識(shí)到竟然能很好的解決計(jì)算資源浪費(fèi)的問(wèn)題，驚嘆之余，發(fā)出了開頭的那條微博。

對(duì)于交互式查詢的需求，問(wèn)題是一樣存在的。我們數(shù)據(jù)團(tuán)隊(duì)是由兩個(gè)團(tuán)隊(duì)合并創(chuàng)建的，一個(gè)是我所帶領(lǐng)的數(shù)據(jù)平臺(tái)團(tuán)隊(duì)，一個(gè)是內(nèi)部叫做Doris的分布式查詢團(tuán)隊(duì)。Doris主要是解決海量數(shù)據(jù)下，使用MPP架構(gòu)，滿足毫秒級(jí)的查詢問(wèn)題（對(duì)外的百度統(tǒng)計(jì)以前就使用了這一系統(tǒng)）。如果能把它改造一下，能夠?qū)訄?bào)表引擎，就可以滿足。

這個(gè)最重要的改造就是要支持SQL。這一思路在一位Google的架構(gòu)師James Peng的加入，得以傳遞。Doris團(tuán)隊(duì)的人員花了兩周時(shí)間，直接將Doris作為mysql的存儲(chǔ)引擎，這樣就實(shí)現(xiàn)了通過(guò)mysql直接訪問(wèn)doris，支持了SQL語(yǔ)法。其實(shí)InfoBright也是這么一個(gè)實(shí)現(xiàn)思路。于是這樣查詢性能的問(wèn)題也解決了。所有的核心報(bào)表，都通過(guò)數(shù)據(jù)立方體來(lái)實(shí)現(xiàn)，展現(xiàn)部分用了Oracle BIEE。

可以這么說(shuō)，Oracle BIEE是我用到過(guò)了最爛的企業(yè)軟件，第二爛的是Oracle ERP軟件。雖然基于多維數(shù)據(jù)模型，實(shí)現(xiàn)了報(bào)表的基本需求。但是有兩個(gè)嚴(yán)重的問(wèn)題，一是BIEE配置報(bào)表非常麻煩，即使規(guī)整好的數(shù)據(jù)，還在再建一層數(shù)據(jù)模型，多此一舉，界面操作非常復(fù)雜；二是數(shù)據(jù)的預(yù)處理即ETL工作比較復(fù)雜，數(shù)據(jù)源的變更，會(huì)導(dǎo)致結(jié)果出錯(cuò)，ETL計(jì)算周期長(zhǎng)，導(dǎo)致報(bào)表發(fā)送延遲?？傊悄芑緷M足，但不是特別的優(yōu)雅。后來(lái)我們又開發(fā)了自己的可視化系統(tǒng)，解決報(bào)表展示問(wèn)題。
 

發(fā)揮魔力

我在百度工作這幾年，一直很反對(duì)做半吊子的產(chǎn)品，像我前面提到的cube項(xiàng)目，就是半吊子的典型。是圍繞某個(gè)問(wèn)題的一個(gè)解決方案，但這一解決方案很不成熟，用起來(lái)很不爽。《Lean Startup》里傳遞的一種理念是要做MVP（Minimium Viable Product，最小可用產(chǎn)品），先做一個(gè)原型，投放市場(chǎng)，然后根據(jù)反饋，迅速迭代。而蘋果卻貌似反其道而行之的，不管是iPod還是iPhone，還是iPad，等它發(fā)布的時(shí)候，我們都發(fā)現(xiàn)它們是成品，直接就是有魔力的產(chǎn)品，有些人會(huì)把它們形容為驚艷。

在參加工作三年之后，我逐步找到了一個(gè)把產(chǎn)品做出魔力的感覺，盡管還不斷的失手，但越來(lái)越有自信了。至少有一點(diǎn)，我能保證我做出來(lái)的產(chǎn)品，一定是非常流暢的，讓人用起來(lái)不卡殼，即使這是一個(gè)to B的工具產(chǎn)品。這次創(chuàng)業(yè)可以自行操刀，更是期望哪怕少做兩個(gè)功能，也要把它做的有魔力。

因?yàn)閯?chuàng)業(yè)是針對(duì)互聯(lián)網(wǎng)創(chuàng)業(yè)公司的，數(shù)據(jù)規(guī)模上肯定和在百度沒(méi)法比，另外，創(chuàng)業(yè)公司沒(méi)有歷史包袱，因此可以在數(shù)據(jù)源頭上去規(guī)范起來(lái)。做了七年的數(shù)據(jù)平臺(tái)，我總結(jié)的最重要的一點(diǎn)就是要把數(shù)據(jù)源處理好，如果源頭不好，后面即使用再?gòu)?fù)雜的算法，也不能做好。我曾經(jīng)在百度花了一年半的時(shí)間，推動(dòng)公司的核心業(yè)務(wù)線從打印的各種花樣的文本日志，轉(zhuǎn)變成直接打印二進(jìn)制結(jié)構(gòu)化的，后面的數(shù)據(jù)處理都變得容易很多。那現(xiàn)在從零開始，就可以直接和創(chuàng)業(yè)公司一起，把數(shù)據(jù)源頭規(guī)范好，把每一條的用戶記錄，規(guī)范成有多個(gè)維度的帶有格式的數(shù)據(jù)，就像數(shù)據(jù)庫(kù)里的一條標(biāo)準(zhǔn)記錄。再稍加處理，就能形成標(biāo)準(zhǔn)的多維數(shù)據(jù)源。

在這個(gè)多維數(shù)據(jù)源基礎(chǔ)上，進(jìn)一步規(guī)范成多維數(shù)據(jù)分析模型，搭配上合適的存儲(chǔ)和查詢引擎，就能實(shí)現(xiàn)多種維度的交叉分析，但有在秒級(jí)響應(yīng)。再將常用的事件分析、漏斗轉(zhuǎn)化、留存分析進(jìn)行抽象，直接建立在這一數(shù)據(jù)模型之上。我們可能用過(guò)各種BI（Business Inteligence，商務(wù)智能）系統(tǒng)，見過(guò)數(shù)百?gòu)垐?bào)表，紛繁復(fù)雜。可是針對(duì)用戶行為分析，在這幾個(gè)簡(jiǎn)單功能之上，就能生成五彩繽紛的報(bào)表。

 
（圖3 Sensors Analytics上的多維分析功能截圖）

當(dāng)我向客戶介紹我們產(chǎn)品的底層實(shí)現(xiàn)時(shí)，都會(huì)感覺思路特簡(jiǎn)單。但當(dāng)用到我們的產(chǎn)品時(shí)，又感覺特別強(qiáng)大，又非常易用?？蛇@簡(jiǎn)單的背后，是花了大量的經(jīng)歷去抽象功能，并打磨細(xì)節(jié)。有一位GA（Google Analytics）專家，對(duì)統(tǒng)計(jì)分析工具非常精通，尤其擅長(zhǎng)GA。我的兩位合伙人和他交流之后，我問(wèn)他們公司有沒(méi)有可能用我們的產(chǎn)品，兩個(gè)人都說(shuō)不可能，人家都已經(jīng)有了一套完整的現(xiàn)有方案，可沒(méi)過(guò)兩天，發(fā)來(lái)消息說(shuō)決定要用我們的產(chǎn)品，我是被驚喜到了。在這創(chuàng)業(yè)的短短5個(gè)多月，10來(lái)個(gè)人的團(tuán)隊(duì)，產(chǎn)出了20多萬(wàn)行的代碼，而我只在開始的一個(gè)半月，光界面部分，就提交了100個(gè)bug，這樣才有了我們的Sensors Analytics 1.0（有興趣的可以到http://www.sensorsdata.cn/申請(qǐng)?jiān)囉茫＜词宫F(xiàn)在，我還在每天至少提交一個(gè)bug/feature。

我在朋友圈發(fā)了那條微博的截圖之后，Alex Lv回復(fù)說(shuō)：為什么多維分析易說(shuō)難做，你一定想明白了。