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

（圖1 2012年的一條微博） 

初次失敗

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

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

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

[[154900]]

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

通過這個(gè)數(shù)據(jù)立方體，我們就可以看來自北京的，使用iOS的銷售額是多少。這個(gè)模型非常清晰和簡單，難點(diǎn)在于數(shù)據(jù)規(guī)模。我們針對百度的流量分析，可以拆開多個(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)。找來找去，發(fā)現(xiàn)InfoBright這一存儲(chǔ)引擎最合適，它采用列式存儲(chǔ)，在針對多維數(shù)據(jù)分析這種模型上，性能很好。但因?yàn)槭菃螜C(jī)的，支持的數(shù)據(jù)規(guī)模有限，我們對某些維度的元素進(jìn)行了聚合，來降低數(shù)據(jù)量，***降到半年的累計(jì)數(shù)據(jù)預(yù)計(jì)幾百G。就這樣，我們在半個(gè)正式員工、兩個(gè)實(shí)習(xí)生的人員配置下，開啟了整個(gè)項(xiàng)目。當(dāng)時(shí)我是雄心勃勃，還把部門的高級總監(jiān)邀請到開發(fā)群里，因?yàn)獒槍α髁繑?shù)據(jù)的多維分析，顯然部門老大是最需要的。兩個(gè)月后，悲劇發(fā)生了。

產(chǎn)品是做出來了，但多個(gè)維度的組合查詢性能一塌糊涂，我有時(shí)候在界面上做了個(gè)查詢，半個(gè)小時(shí)后都還看不到結(jié)果，根本沒法用，整個(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í)到性能問題后，我們又嘗試將查詢引擎從InfoBright替換到InfiniDB，只能說略好，但沒有本質(zhì)區(qū)別。

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

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

漸入佳境

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

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

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

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

對于交互式查詢的需求，問題是一樣存在的。我們數(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)，滿足毫秒級的查詢問題（對外的百度統(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)了通過mysql直接訪問doris，支持了SQL語法。其實(shí)InfoBright也是這么一個(gè)實(shí)現(xiàn)思路。于是這樣查詢性能的問題也解決了。所有的核心報(bào)表，都通過數(shù)據(jù)立方體來實(shí)現(xiàn)，展現(xiàn)部分用了Oracle BIEE。

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

發(fā)揮魔力

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

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

因?yàn)閯?chuàng)業(yè)是針對互聯(lián)網(wǎng)創(chuàng)業(yè)公司的，數(shù)據(jù)規(guī)模上肯定和在百度沒法比，另外，創(chuàng)業(yè)公司沒有歷史包袱，因此可以在數(shù)據(jù)源頭上去規(guī)范起來。做了七年的數(shù)據(jù)平臺(tái)，我總結(jié)的最重要的一點(diǎn)就是要把數(shù)據(jù)源處理好，如果源頭不好，后面即使用再復(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ù)庫里的一條標(biāo)準(zhǔn)記錄。再稍加處理，就能形成標(biāo)準(zhǔn)的多維數(shù)據(jù)源。

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

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

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

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