在多維數據分析模型的路上越走越遠
02-01
作者: Sensors Data 創始人&CEO 桑文鋒,歡迎試用我們的產品Sensors Analytics | 神策分析。n前幾天翻出了2012年2月在微博上發出的一條信息(圖1),當時我為什麼會那麼興奮,還得從更早的時候說起。n
(圖2 數據立方體的樣例)n通過這個數據立方體,我們就可以看來自北京的,使用iOS的銷售額是多少。這個模型非常清晰和簡單,難點在於數據規模。我們針對百度的流量分析,可以拆開多個維度,比如時間、地域、渠道、操作系統、瀏覽器版本、頻道、行為類型等。每個單位時間內,所產生的數據條數就是所有維度的乘積,假設每個維度有10個項目,如果有10個維度,那麼就會產生10^10 條記錄。每條記錄按1KB大小,那麼就是10TB數據量。如果在這個基礎上做計算,一台機器的性能是顯然撐不住的。我們就在尋找適合在這種數據規模上進行查詢的存儲系統。找來找去,發現InfoBright這一存儲引擎最合適,它採用列式存儲,在針對多維數據分析這種模型上,性能很好。但因為是單機的,支持的數據規模有限,我們對某些維度的元素進行了聚合,來降低數據量,最後降到半年的累計數據預計幾百G。就這樣,我們在半個正式員工、兩個實習生的人員配置下,開啟了整個項目。當時我是雄心勃勃,還把部門的高級總監邀請到開發群里,因為針對流量數據的多維分析,顯然部門老大是最需要的。兩個月後,悲劇發生了。n產品是做出來了,但多個維度的組合查詢性能一塌糊塗,我有時候在界面上做了個查詢,半個小時後都還看不到結果,根本沒法用,整個產品只能算個半吊子的Demo,連部門老大也退出了群。在我這工作的八年的職業生涯中,有兩個項目我認為是徹底的失敗了,一個就是這個cube項目,另一個是基於impala改進的一個互動式查詢產品,以後有機會再介紹。認識到性能問題後,我們又嘗試將查詢引擎從InfoBright替換到InfiniDB,只能說略好,但沒有本質區別。順帶交代兩句這兩個存儲引擎的命運,InfoBright這家波蘭公司的產品,在這兩年轉型做針對物聯網的存儲引擎了。而InfiniDB在去年的10月1日宣布了破產。看來創業公司純粹做一款資料庫引擎,日子並不會太好過。n除了存儲層的問題,還有查詢解釋層Mondrian的性能問題,以及報表引擎JPivot的性能問題,數據導入的性能問題,預處理數據的計算性能問題,數據欄位變更的維護問題等。總之在一個不合適的時機,提出了一個比較理想化的idea,結果可想而知了。n
推薦閱讀:
(圖1 2012年的一條微博)n
初次失敗2010年初,有個地圖團隊的PM找到我,演示了一份PPT,那是某個公司的統計分析系統的對外交流材料。據說這份材料先是被廠長看到,覺得做的挺好,就安排下面的人看是否也能做一套。我看了之後,發現就是針對某個互聯網產品的流量、用戶量的幾個頁面展示,針對地域、渠道等幾個維度可以展開分析。心想這種系統在我們的Log統計平台上很容易用幾個任務實現出來。但Log統計平台是以統計任務來管理的,雖然功能強大,但是不利於展示上的組織。對於一個業務線來說,就是一組報表,並沒有層級管理。相比之下,PPT中演示的系統在界面組織上,就會好很多。我就給這位PM說,這套系統太簡單了,既然我們要做,就要比他們做的牛逼。我先考慮一下,然後給出一套方案。n就這樣,我和團隊的三四個兄弟開始考慮如何做一套牛逼的方案,調研來調研去,發現還是數據倉庫教材里介紹的數據立方體的模型,適合做這件事。於是拿著這套方案和PM溝通,PM聽了介紹之後,說要是真的可以實現,我們的系統就太強大了。就這麼敲定了。那時的我一是會希望自己做的事情非常獨特,超越之前的任何方案,二是根本不會考慮人力是否能支持,最後真正能投入到本項目的也就只有一個正式員工外加一個實習生。產品方案定了,接下來就是技術選型。數據立方體是多維數據模型的一個通俗的叫法,主要由維度和指標兩部分組成,比如地域是一個維度,操作系統也是個維度,銷售額是一個指標,註冊用戶數也是個指標,成單量也是一個指標。那麼我們就可以通過維度組合,看這種組合下的指標情況。如圖2:n漸入佳境
這次項目失敗後,我對數據立方體這種理論化的模型產生了懷疑,覺得在現實場景下走不通,作為數據倉庫教材里的內容講講幫助理解,還是可以的。又過了一年,成立了基礎架構部數據團隊,並從Google聘請了一位總監,就是開始我在截圖裡提到的「矽谷知青」 Alex Lv。他來百度之前,在Yahoo干過7年,Google干過5年,一直圍繞數據倉庫方向,可以說是這一領域的資深專家,Google的Tenzing引擎,就是他的團隊做出的。他來了之後,真的是把我的思路打開了一大圈,相比之下,我之前對數據架構的理解真的太狹隘了。他先是給我們提出了數據分層的金字塔模型,決定構建Baidu Data Warehouse(UDW),能夠將用戶在百度所有產品線的行為統一到一起去。有了這個地基,剩下的數據使用問題,就變得容易了。n這就回到了文章開頭我發微博的那天,Alex Lv給我講解了在UDW基礎之上,將用戶數據按照時間細粒度匯聚,可以根據不同維度組合查詢,所有的報表需求都在這個基礎上出。相比之下,我們之前的報表數據,都是直接從原始數據,經過計算,生成統計結果,計算效率是很低的,中間數據沒有得到重複使用。相比cube項目,常規報表數據是例行跑出的,而不是實時交互,這對查詢性能要求沒那麼高。在UDW的基礎之上,數據立方體的思路我意識到竟然能很好的解決計算資源浪費的問題,驚嘆之餘,發出了開頭的那條微博。n對於互動式查詢的需求,問題是一樣存在的。我們數據團隊是由兩個團隊合併創建的,一個是我所帶領的數據平台團隊,一個是內部叫做Doris的分散式查詢團隊。Doris主要是解決海量數據下,使用MPP架構,滿足毫秒級的查詢問題(對外的百度統計以前就使用了這一系統)。如果能把它改造一下,能夠對接報表引擎,就可以滿足。這個最重要的改造就是要支持SQL。這一思路在一位Google的架構師James Peng的加入,得以傳遞。Doris團隊的人員花了兩周時間,直接將Doris作為mysql的存儲引擎,這樣就實現了通過mysql直接訪問doris,支持了SQL語法。其實InfoBright也是這麼一個實現思路。於是這樣查詢性能的問題也解決了。所有的核心報表,都通過數據立方體來實現,展現部分用了Oracle BIEE。n可以這麼說,Oracle BIEE是我用到過了最爛的企業軟體,第二爛的是Oracle ERP軟體。雖然基於多維數據模型,實現了報表的基本需求。但是有兩個嚴重的問題,一是BIEE配置報表非常麻煩,即使規整好的數據,還在再建一層數據模型,多此一舉,界面操作非常複雜;二是數據的預處理即ETL工作比較複雜,數據源的變更,會導致結果出錯,ETL計算周期長,導致報表發送延遲。總之是能基本滿足,但不是特別的優雅。後來我們又開發了自己的可視化系統,解決報表展示問題。n發揮魔力
我在百度工作這幾年,一直很反對做半吊子的產品,像我前面提到的cube項目,就是半吊子的典型。是圍繞某個問題的一個解決方案,但這一解決方案很不成熟,用起來很不爽。《Lean Startup》里傳遞的一種理念是要做MVP(Minimium Viable Product,最小可用產品),先做一個原型,投放市場,然後根據反饋,迅速迭代。而蘋果卻貌似反其道而行之的,不管是iPod還是iPhone,還是iPad,等它發布的時候,我們都發現它們是成品,直接就是有魔力的產品,有些人會把它們形容為驚艷。在參加工作三年之後,我逐步找到了一個把產品做出魔力的感覺,儘管還不斷的失手,但越來越有自信了。至少有一點,我能保證我做出來的產品,一定是非常流暢的,讓人用起來不卡殼,即使這是一個to B的工具產品。這次創業可以自行操刀,更是期望哪怕少做兩個功能,也要把它做的有魔力。n因為創業是針對互聯網創業公司的,數據規模上肯定和在百度沒法比,另外,創業公司沒有歷史包袱,因此可以在數據源頭上去規範起來。做了七年的數據平台,我總結的最重要的一點就是要把數據源處理好,如果源頭不好,後面即使用再複雜的演算法,也不能做好。我曾經在百度花了一年半的時間,推動公司的核心業務線從列印的各種花樣的文本日誌,轉變成直接列印二進位結構化的,後面的數據處理都變得容易很多。那現在從零開始,就可以直接和創業公司一起,把數據源頭規範好,把每一條的用戶記錄,規範成有多個維度的帶有格式的數據,就像資料庫里的一條標準記錄。再稍加處理,就能形成標準的多維數據源。n在這個多維數據源基礎上,進一步規範成多維數據分析模型,搭配上合適的存儲和查詢引擎,就能實現多種維度的交叉分析,但有在秒級響應。再將常用的事件分析、漏斗轉化、留存分析進行抽象,直接建立在這一數據模型之上。我們可能用過各種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。n
我在朋友圈發了那條微博的截圖之後,Alex Lv回復說:為什麼多維分析易說難做,你一定想明白了。推薦閱讀:
※Python爬蟲進階四之PySpider的用法
※(轉)41個超級網路資源資料庫,絕對有你想要的!
※數據分析探索之旅(一):學習數據分析的初衷與規劃
※分析結果不被重視?因為你忽略了一個重要指標
TAG:大数据分析 |