【轉載】時隔一年多，我又用起了 Superset

去年 6 月份在流利說提離職後，leader 問我為什麼要走。我說，流利說有很健全的資料處理基礎設施，但這不是所有的公司都會有的條件，是以我想看看在一個基建不全的創業公司我是否也可以像現在一樣做的好。

7 月份正式離職到了現在的公司，一開始靠數着營運背景的訂單，看着公衆号背景的漲粉，配合友盟拿到的分享資料，拉了張 EXCEL 大表就開始預測着未來的營收支出。在業務蒸蒸日上的時候，給出的預測結果表現的也是很讓人滿意，隔壁公司的黃老闆還天天跑來串門問怎麼預測的。

預測的結果看起來十分的美好，但是它其實需要有很多的前提假設成立才能站得住腳，比如使用者大體的表現是一緻的，又比如投放成本不會過高，再比如微信不會打擊朋友圈打卡。是以我迫切的希望了解事實是否像我們假設的那般美好，我開始提議希望能在這家公司建立第一套資料基建 —— 自采集埋點配合資料庫查詢。

我深知它的價值，隻要有原始資料未來就可以拿它們計算出我們需要的結果。但是我又無法辯駁過 CTO 市面上已有那麼多成熟的第三方資料平台可用，為什麼一定要大費周章的自建埋點體系。我抛出的每個具體的理由都因為存在其他的解決方案而不成立，而當我抛出 它是為了解決未來可能會出現不确定問題 時又被要求給出具體的問題。

我又試圖說服 COO 出面幫我說服 CTO，但是被幾個理由駁回了：

創業公司都不知道能不能活下去，你花資源做這些基礎建設萬一公司倒閉了那不是浪費資源麼？

資料能給我們回報，但是不能告訴我們接下來該做什麼 。

最後我選擇了妥協，繼續使用友盟看使用者行為資料，業務資料需求需要送出給後端來開發輸出到 BI背景。這樣的模式弊端太明顯了，因為資料需求一開始是不确定的，隻有被證明過有價值且需要經常觀察的資料才會被固化到 BI 報表裡，而現在我們直接掠過了不同次元的資料觀察，就直接跳到固化報表這一步，像極了還沒學會走路就想要開始跑了。

BI 報表的設計到評審，全程都是非常痛苦的一件事情，因為我無法确定設計出來的這些次元、名額是否能夠滿足後續分析需求，過度設計的話又無法在評審上順利地說服開發。外加上後端資源有限，每次送出的 BI 報表需求都需要協調後端資源，想看的資料往往要等上一兩周才能看到，難受極了。業務方也不敢去想太多的資料需求，因為即使提了也不會被滿足，還不如多花點時間想想自己該做什麼。

如果業務沒有受挫，這家公司的資料航線應該會一直朝着之前既定的方向前進。當資料持續下跌後，所有人開始焦慮到底發生了什麼，寄希望于我能根據資料給出答案。但是我能看到的資料其實和其他人是一樣的，那我唯一能表現出不一樣的地方隻有對相關業務動作的聯想，但是這些聯想出來的猜想又沒有其他資料可以去驗證，最後大部分隻能不了了之。

為了盡可能在現有的資料條件下，搞清楚到底發生了什麼，我說服了CTO和後端開發給我了 MongoDB 的查詢權限。MongoDB 的文法寫起來痛苦極了，因為 MongoDB 是非關系型資料庫（NOSQL），它的主要應用場景是單表查詢，如果需要頻繁查詢的關聯資訊往往會被開發備援在表中。但是資料分析的不确定性資料需求，往往需要關聯各式各樣的表才能輸出結果，是以我不得不開始生澀地使用 $match 文法。在被後端開發告知 MongoDB $match 的性能要比 $in 差很多 後，我後面通過 pymongo 結合 pandas 進行資料分析了，寫起來也順手多了。

然而僅僅依賴業務資料，還有很多問題無法得到解釋，最後在 CEO 和 COO 的推動下公司終于決定自建埋點采集。期間其實還有嘗試過友盟以外的第三方資料平台，但是最後都被否掉了。因為第三方資料平台往往是标品，他們能夠滿足的是衆多公司共有的資料問題，而一些個性化的需求滿足起來可能成本會比自建還要高的多。

我一開始以為自采集的埋點使用者資料會直接進入資料庫存放起來的，結果 CTO 調研了一圈最後選擇了 阿裡雲的日志服務，這玩意兒有點類似 Kafka ，可以存放、加工日志類資料的地方。有些抵觸但是還能接受，至少可以進行使用者分層分析了。于是我們制定了一套自采集的架構，包含了：埋點文檔規範、埋點資料字段、埋點上報時機等，會通過後端寫入日志服務時補充一些使用者标簽資料。

雖然可以進行分層的使用者行為分析了，也一定程度上解決了很多的問題。但是業務資料和埋點資料依舊是隔離的，如果需要用到标簽以外的業務資料進行分層時，阿裡雲的日志服務有點捉襟見肘了。而老闆們原計劃的大資料團隊建設是放在了 Q4，但是我覺得等不了那麼久。因為當時正在招第一個資料分析師，如果招來了人卻因為工具受限而無法發揮出他的價值，我會覺得很浪費。

無意間在 日志服務 的投遞功能裡發現了 MaxCompute —— 阿裡雲數加（DataWorks）平台的一款資料計算引擎，看了簡介又去知乎、簡書上了解了下相關評價，感覺可以一試。去找了 CTO，這回他很支援，我猜大機率是因為他比較傾向于使用第三方現成的工具，而不是自己搭建一套東西。開通 MaxCompute 後，我們先是把 日志服務 的資料投遞到了MaxCompute表裡，再通過 DataWorks 的資料內建功能把 MongoDB 的資料內建到 MaxCompute 表中。

就這樣我們打通了我們的埋點資料和業務資料，我寫了很多的配置腳本去同步 MongoDB 的資料，又花了大量的時間來建構一些中間表。資料庫頂層的模型設計我直接照搬了流利說的—— ETL -> DW(Data Warehouse) -> DM (Data Market) -> DA (Data Analysis) ，這應該也是一個業内比較通用的做法。同時 DataWorks 提供的資料服務，很友善的能讓後端調用 MaxCompute 表中的資料，一定程度上減輕了我們對後端資源的需求。

由于 MaxCompute 更像是結合 Hive 和 airflow 的産品，而數加配套的 QuickBI 似乎又沒那麼好用，我總覺得我們還是缺少了一個互動式分析工具。畢竟資料需求中總會有一些周期性但是又隻持續一段時間的需求，如果将他們産品化吧似乎有點浪費，不産品化吧每隔一段時間跑來問你要也挺煩的。于是乎我就研究了下 Superset， 恰好看到 MaxCompute 的文檔中提到過，MaxCompute Lightning相容PostgreSQL接口，所有支援PostgreSQL資料庫連接配接的用戶端工具都可以用于連接配接MaxCompute Lightning，而 Superset 也恰好支援 PostgreSQL資料庫連接配接。在本地測試成功後，我就去和 CTO 分享了一下并得到了支援，預計下周就可以用上了。

我對于 Superset 的期待是

資料賦能營運，讓業務方可以在最短的時間内看到自己想看到的資料

釋放後端資源，讓後端同學可以更專注于他們更專業的地方

提升分析效率，短時間内可以看到更多的資料，不同次元的多項名額

這是一篇碎碎念，純粹是因為有一種熬出頭的感覺外帶點興奮寫下的，發與不發糾結了兩天。想表達的點就是創業公司想要搭建一套完成的資料分析基礎設施，很難又很簡單。難在這對創業公司的絕大多數人都是陌生的領域，外加眼花缭亂的第三方市場。雖然明知這件事的重要，但是很難作出一個正确的決策。簡單的是，無論采用直接可用的第三方資料平台，還是用雲廠商提供的封裝後的一整套體系，又或是基于雲廠商提供的服務自建一套，都有很多現成的可用的方案。

結尾再普及一下什麼是埋點資料和業務資料，這兩種資料其實都是原始資料：

業務資料往往是因為業務開展需要存儲下來的，比如你的訂單、昵稱、頭像、聊天記錄等等，不難發現這些資料有個共性——它們都是你的行為産生的結果，是以業務資料可以簡單了解為行為結果資料。

埋點資料隻是想對使用者行為加以分析而收集的，比如你打開了小王的朋友圈，你掃了一下二維碼，你播放了某首歌曲等等，同樣的埋點資料也有共性——它們都是你行為過程中采集的資料，是以埋點資料可以簡單的了解為過程資料。

結合兩類原始資料就可以給你賦予各種各樣的标簽，再把帶有同類标簽的使用者聚合在一起觀察業務表現的共性就是絕大多數的資料分析場景。

原創： 柯小一

公衆号：柯一不等式

歡迎加入“MaxCompute開發者社群2群”