王雨舟：知乎大資料平臺架構和實踐優化

  又是一年SACC，又是一時秋意正濃，即便是天氣欠佳，大資料平臺架構技術與實踐專場同樣擠滿了求學好問的技術人。知乎大資料平臺負責人王雨舟現場分享了知乎大資料平臺架構和實踐優化之路。作為一個專業的知識問答社群，知乎背後的技術能力如何?使用者互動頻繁，活躍度節節攀高，知乎大資料平臺是如何設計以支撐這一切的呢?

　　據調查，截止2017年8月，知乎註冊使用者數破億，全站DAU達2600萬，提問量達1900萬，回答量達7100萬，月瀏覽量180億。當大家越來越習慣在碎片化時間開啟知乎閱讀或評論時，我們似乎都忽略了這家企業的成長速度。

　　2010年12月，知乎網站開放，2013年，知乎向公眾開放註冊，註冊使用者迅速由40萬攀升至400萬，2017年1月，知乎宣佈完成D輪1億美元融資，正式邁入獨角獸行列。這一切正如知乎王雨舟所說：“We are growing FASTER”!

　　資料平臺如何在人員相對穩定的情況下支撐公司業務快速擴張 ?

　　成長快固然是件好事，但技術必須跟得上成長的速度，不然使用者體驗肯定要降低。王雨舟以知乎為例分享了這一痛點的解決方案。首先，知乎資料平臺是公司級的資料平臺，負責維護基礎流量資料和資料倉儲;維護演算法、商業、搜尋、後端服務需要的資料來源;為管理層、運營、產品、資料分析師等提供資料看板和分析系統;維護資料地圖、埋點管理系統、埋點配置和測試系統等產品;維護A/B實驗等。

　　隨著業務線的擴張，快速滿足新業務需求的過程必然需要處理流量資料埋點，建立資料倉儲，建立資料來源、指標、維度、報表以及業務看板。知乎的一大特點是資料平臺使用者可以自定義建立報表和儀表盤資料。過去，新增一個需求可能需要不小的開發週期，現在使用者可以通過簡單的圖形操作即可完成，這意味著擁有了秒級查詢的能力，解決了指標開發人力投入與資料 T+1 的痛點。

　　知乎大資料平臺架構圖曝光

　　以上是知乎大資料架構圖全貌，中間很重要的一部分是資料倉儲，它與實時計算和離線計算均相關。圖中可以很清楚的看出資料分層部分，其星形模型有事實表和維度表，事實表採用退化維度，減少關聯多表操作。

　　去年，知乎也出現了MySQL資料實時查詢的需求，當時知乎調研了Hive和HBase，但當兩張大表join的時候，二者效能很低。最後，知乎選擇將MySQL的BinLog實時打到Kafka，起一套Spark Streaming程式，實時將資料寫到kudu裡面，用impala實時查詢Kudu。隨著業務線進一步擴張，王雨舟發現當MySQL表結構改變的時候，Kudu整個資料都需要重導，知乎決定開始採用TiDB，但目前正在研究中，所以架構圖中暫未公佈。

　　據王雨舟介紹，資料採集部分整個客戶端和前端採用Protobuf格式打點，知乎對資料打點的要求還是比較嚴格的，目前做到了半自動的方式打點。同時，使用了業內比較受歡迎的Hybrid框架，保證JS和Native打通。客戶端更關注埋點定位，內容資料由後端序列化生成下發。這個過程，王雨舟也發現了埋點資料面臨的一些問題，因此，知乎正在上線埋點管理系統和埋點測試系統，幫助客戶端工程師更好自測。日誌接收部分，自研日誌接收服務，傳送到Kafka，可以自適應Kafka健康狀態，保證資料不丟。

　　面對業務急速擴張過程中的各種需求，知乎資料平臺組通過通用靈活的系統做到了完美的支援，未來知乎還有很多很酷的專案待實現，不如一起加入吧!

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2153971/，如需轉載，請註明出處，否則將追究法律責任。