日前，由51CTO傳媒精心打造的WOT2016大數據峰會在北京盛大開幕。本次大會議題涵蓋實時計算、機器學習、等九大數據領域前沿技術專場，百度大數據平臺架構師侯玨、HBase核心貢獻者 Ted Yu、一點資訊大數據平臺研發總監田超等應邀出席并發表演講。

一點資訊大數據平臺研發總監田超發表演講

　　在大會現場，一點資訊大數據總監田超深度透析用戶點擊反饋背后的系統設計，并以一點資訊實時反饋平臺為例，分享了支撐一點資訊億級別用戶實時計算系統的設計理念和心得。

　　他表示，實時的數據處理能力對于一個現代互聯網公司來說是必要的組成部分，一點資訊作為一家融合了“搜索”和“推薦”的興趣引擎平臺，根據不同場景、頻道下的點擊反饋形成數據矩陣，對數據進行深層次挖掘，并通過大規模實時點擊反饋系統和大規模機器學習進行智能推薦，從而為用戶提供兼具共性與個性的移動價值閱讀，實現了用戶體驗的提升。

　　以下是演講節選：

　　大家好，很高興今天與大家分享一點資訊關于大數據技術的一些心得。作為近兩年來在移動資訊領域發展最快的公司之一，目前，一點資訊的日活達4800萬。此外，我想在這里特別強調的是，一點資訊主動訂閱用戶數已達4700萬。作為一家融合了搜索和推薦的技術驅動資訊平臺，與單純被動根據用戶歷史記錄進行推薦不同，我們更注重自由訂閱來給予用戶主動表達的出口，通過全網化的智能客戶端，不僅為大家帶來有趣、有料的新聞，也更提供有用、有品的資訊。

　　實時點擊反饋平臺打造***推薦服務

　　上圖是今天我們主要講的，點擊反饋相關推薦的部分。主要包括兩個，左手邊叫Neo的系統是今天的主題，也就是點擊反饋計算平臺。

　　因為這次論壇的主題是實時計算，所以我們也回顧一下整個推薦系統里面實時計算所涉及的三個方面的應用場景：***部分是實時畫像中的后驗指標，包括了用戶畫像，內容畫像和頻道畫像等。第二部分，應用場景是我們實時的數據分析，讓我們在做不同實驗時，了解到不同人群、文章點擊率的變化。第三部就是在線的機器學習，后面我會詳細介紹。

　　值得注意的是，雖然推薦服務系統為我們帶來很多便利，但同時也面臨不少問題和挑戰，下面我將從一點資訊的平臺為例，為大家分別闡述五個方面的主要問題以及解決方式。

　　問題1：如何統一各種近似的實時Pipeline

　　***個問題就是近似的pipeline大家怎么樣去統一?做實時計算時，大家常常發現你的Storm、spark跑著各種各樣相近但又不同的作業，這些作業中80%運算是相同的。

　　在一點資訊內部，我們設計了一套叫Neo的點擊反饋平臺系統，統一了主要的實時點擊反饋計算邏輯。Neo系統的核心數據結構是一個Multi-Dimensional Matrix，用以描述用戶在各個維度和粒度的興趣屬性和基礎屬性兩部分，可以在不同維度和數據粒度上進行各種聚合運算。其次，我們圍繞著核心數據結構構造了整個運行時的framwork，可以支持用戶自定義自己的算子。

　　問題2：實時計算和離線計算的統一

　　第二個問題說實時計算和離線計算怎么樣統一?

　　實時計算與離線計算的統計是流式計算領域里的研究熱點之一，對于我們的生產工作來說也有著比較重要的實際意義，市面上有一些開源和技術和論文包括Spark、SummingBird、Google DataFlow等都對如何實現有自己的解決方案。一點資訊采用的是Lambda architecture，對于核心計算邏輯有一套統一的數據結構抽象和計算算子抽象。我們本質上處理的是事件流在不同矩陣上以不同粒度聚合的問題，這里尤其是對于矩陣的Delta和Base之間的計算，我們給出了一套比較完整的抽象。這一套核心代碼可以同時跑在Storm/JStorm， Spark、Mapeduce上。

　　問題3：數據變化如何追蹤與Debug

　　我們的平臺除了考慮到了上面所述的數據結構和計算模型外，還考慮到了時間的因素。時間是一個非常重要的維度，對于我們的計算引擎也是一個挑戰?？偨Y來說，包括這幾個問題：不同類型的Feature需要不同的淘汰策略，需要能夠計算各種時間周期上的feature、需要能夠知道數據歷史變化的狀態、數據分析需要追蹤指標變化曲線。

　　對于這些問題，我們構建了比較完整的windowingmodol的實時計算模型：在hbase上存儲細粒度的delta數據，這一部分的數據是實時更新的，每次更新時計算pipeline會通過kafka寫入一個WAL，有一個Pusher組件會監聽這個WAL，并可以根據自定義的策略對不同的數據表采用不同的window計算模型;在pusher層面，支持各種時間窗口淘汰策略，包括Fixedwindow，session window，slidingwindow，decay，last value win等，

　　問題4：高性能存儲引擎

　　一點資訊在高峰期產生的2M+QPS的讀請求，和200K+的更新量，因此對我們線上的分布式存儲系統會有比較高的性能要求，市面上線程的分布式存儲方案都不能解決我們面臨的問題。

　　因此我們開發了自己的分布式存儲系統NeoDB，底層基于Rocksdb，上層使用ThriftRPC，我們對系統層次做了很多的優化，，包括把一些部分計算可以推到***下節點上、減少Compaction的層次，控制Compaction對于讀請求的影響、控制寫放大，優化緩存***率等。

　　問題5：如何監控和維護整個系統

　　***一個問題怎么樣做監控和維護整個系統。這里面涉及到一些問題，主要包括怎么對數據流lag做監控報警。對流式計算如何做profiling，線上如何做負載均衡等。我們針對這些問題開發了兩個系統，一個是監控我們做了YMetric的監控系統?？蛻舳思嫒輈odahale metrics庫，會將metric匯總發送到Kafka中，并由我們統一的Storm Pipeline進行聚合計算，結果存儲在openTSDB之中。我們的這套系統支持多Metric的自定義計算、報警、Trending預測等。

　　另外一個系統是ycluster服務，她有點像Apache Helix，但是我們做的更為簡單易用，YCluster是一套基于Zookeeper的分布式負載均衡和機群管理系統，支持Multiple Service Namespace、Hash Sharding、Multiple Replica。同時我們基于YCluster做了Neo系統的Smart Client，通過這套Smart Client完成路由和負載均衡的工作，我們支持多種不同負載均衡的算法，包括簡單的Random和Round-Robin、，同時我們做了一個叫做link Scheduler的負載均衡的算法，可以支持多數據中心中的本地優先調度，并支持相同副本的優先調度，從而大幅度提升了緩存***率。

　　我們這套東西大概線上跑了一年多了不到兩年，目前承擔了一點資訊一直以來快速服務的增長，這里面就是今天我跟大家介紹的東西，另外補充一點是說，我們也歡迎對一點資訊感興趣的同學加入進來。