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

（圖1 2012年的一條微博） 

初次失敗

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

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

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

[[154900]]

（圖2 數據立方體的樣例）

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

我們就在尋找適合在這種數據規模上進行查詢的存儲系統。找來找去，發現InfoBright這一存儲引擎最合適，它采用列式存儲，在針對多維數據分析這種模型上，性能很好。但因為是單機的，支持的數據規模有限，我們對某些維度的元素進行了聚合，來降低數據量，***降到半年的累計數據預計幾百G。就這樣，我們在半個正式員工、兩個實習生的人員配置下，開啟了整個項目。當時我是雄心勃勃，還把部門的高級總監邀請到開發群里，因為針對流量數據的多維分析，顯然部門老大是最需要的。兩個月后，悲劇發生了。

產品是做出來了，但多個維度的組合查詢性能一塌糊涂，我有時候在界面上做了個查詢，半個小時后都還看不到結果，根本沒法用，整個產品只能算個半吊子的Demo，連部門老大也退出了群。在我這工作的八年的職業生涯中，有兩個項目我認為是徹底的失敗了，一個就是這個cube項目，另一個是基于impala改進的一個交互式查詢產品，以后有機會再介紹。認識到性能問題后，我們又嘗試將查詢引擎從InfoBright替換到InfiniDB，只能說略好，但沒有本質區別。

順帶交代兩句這兩個存儲引擎的命運，InfoBright這家波蘭公司的產品，在這兩年轉型做針對物聯網的存儲引擎了。而InfiniDB在去年的10月1日宣布了破產?？磥韯摌I公司純粹做一款數據庫引擎，日子并不會太好過。

出了存儲層的問題，還有查詢解釋層Mondrian的性能問題，以及報表引擎JPivot的性能問題，數據導入的性能問題，預處理數據的計算性能問題，數據字段變更的維護問題等?？傊谝粋€不合適的時機，提出了一個比較理想化的idea，結果可想而知了。
 

漸入佳境

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

他先是給我們提出了數據分層的金字塔模型，決定構建Baidu Data Warehouse（UDW），能夠將用戶在百度所有產品線的行為統一到一起去。有了這個地基，剩下的數據使用問題，就變得容易了。

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

相比cube項目，常規報表數據是例行跑出的，而不是實時交互，這對查詢性能要求沒那么高。在UDW的基礎之上，數據立方體的思路我意識到竟然能很好的解決計算資源浪費的問題，驚嘆之余，發出了開頭的那條微博。

對于交互式查詢的需求，問題是一樣存在的。我們數據團隊是由兩個團隊合并創建的，一個是我所帶領的數據平臺團隊，一個是內部叫做Doris的分布式查詢團隊。Doris主要是解決海量數據下，使用MPP架構，滿足毫秒級的查詢問題（對外的百度統計以前就使用了這一系統）。如果能把它改造一下，能夠對接報表引擎，就可以滿足。

這個最重要的改造就是要支持SQL。這一思路在一位Google的架構師James Peng的加入，得以傳遞。Doris團隊的人員花了兩周時間，直接將Doris作為mysql的存儲引擎，這樣就實現了通過mysql直接訪問doris，支持了SQL語法。其實InfoBright也是這么一個實現思路。于是這樣查詢性能的問題也解決了。所有的核心報表，都通過數據立方體來實現，展現部分用了Oracle BIEE。

可以這么說，Oracle BIEE是我用到過了最爛的企業軟件，第二爛的是Oracle ERP軟件。雖然基于多維數據模型，實現了報表的基本需求。但是有兩個嚴重的問題，一是BIEE配置報表非常麻煩，即使規整好的數據，還在再建一層數據模型，多此一舉，界面操作非常復雜；二是數據的預處理即ETL工作比較復雜，數據源的變更，會導致結果出錯，ETL計算周期長，導致報表發送延遲。總之是能基本滿足，但不是特別的優雅。后來我們又開發了自己的可視化系統，解決報表展示問題。
 

發揮魔力

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

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

因為創業是針對互聯網創業公司的，數據規模上肯定和在百度沒法比，另外，創業公司沒有歷史包袱，因此可以在數據源頭上去規范起來。做了七年的數據平臺，我總結的最重要的一點就是要把數據源處理好，如果源頭不好，后面即使用再復雜的算法，也不能做好。我曾經在百度花了一年半的時間，推動公司的核心業務線從打印的各種花樣的文本日志，轉變成直接打印二進制結構化的，后面的數據處理都變得容易很多。那現在從零開始，就可以直接和創業公司一起，把數據源頭規范好，把每一條的用戶記錄，規范成有多個維度的帶有格式的數據，就像數據庫里的一條標準記錄。再稍加處理，就能形成標準的多維數據源。

在這個多維數據源基礎上，進一步規范成多維數據分析模型，搭配上合適的存儲和查詢引擎，就能實現多種維度的交叉分析，但有在秒級響應。再將常用的事件分析、漏斗轉化、留存分析進行抽象，直接建立在這一數據模型之上。我們可能用過各種BI（Business Inteligence，商務智能）系統，見過數百張報表，紛繁復雜?？墒轻槍τ脩粜袨榉治?，在這幾個簡單功能之上，就能生成五彩繽紛的報表。

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

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

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