摘要：前言近期，智能大數據服務商個推推出了應用統計產品個數，今天我們就和大家來談一談個數實時統計與數據智能平臺整合架構設計。個推最廣為人知的能力就是推送服務，而將應用內的統計數據與推送系統有效整合，能夠輔助更加精細化的運營。

前言：近期，智能大數據服務商“個推”推出了應用統計產品“個數”，今天我們就和大家來談一談個數實時統計與AI數據智能平臺整合架構設計。

很多人可能好奇，擁有數百億SDK的個推，專注消息推送服務多年，現在為什么要做應用統計？畢竟市面上已經有非常多的類似產品了。我認為答案是“天時地利人和”。

首先是天時。目前，互聯網行業已發展到了所謂的“下半場”甚至是“加時賽”，運營工作走向精細化，DAU和效果被放到第一位，從業者們也逐步認識到數據優化及使用良好的模型的重要性。

其二是地利。個推經過多年的積累，擁有了堅實的數據基礎；另外，個推基礎架構也非常成熟，并在諸多垂直領域實實在在提供了很多數據服務。

第三是人和。內部的研發人員在實戰中積累了豐富的經驗，公司與外部應用開發者和合作伙伴建立了長期緊密的聯系。

正是在這樣的背景下，我們推出了這一款應用統計產品“個數”。

前段時間流行的詞匯是“growth hacker”，而現階段，單純的用戶增長已經無法滿足發展，公司及產品的思考點都在于“效果”。相比于其他統計產品，個數產品的靈魂是運營，即圍繞著核心KPI，保持應用的活躍度，提高整體的收益。

安全、準確、靈活的數據能夠保證運營工作的有效開展；而承載數據的平臺則需做到高并發、高可用、高實時；SDK作為基礎，其核心在于包的體積足夠小，并且集成方便，能夠快速運行。這樣一個從上到下的金字塔，構建起了個數產品。

四大核心能力，打造智能化統計
首先，實時的多維統計是整個應用統計的基礎功能。其中，穩定與實時是兩大關鍵；在顆粒度方面，頁面級統計最適合運營者。

第二部分是數據整合。利用個推的大數據能力，我們能夠提供獨特的第三方視角，幫助應用認清自身，并找到它在行業內的地位。

第三部分是自動建模預測。這是個數非常獨特的功能點。我們希望通過一整套解決方案，幫助應用開發者真正體驗到模型的價值，并通過實際數據反饋，不斷優化改進產品。

第四部分是精準推送。個推最廣為人知的能力就是推送服務，而將應用內的統計數據與推送系統有效整合，能夠輔助更加精細化的運營。

技術架構：業務域+數據域

個數的整體架構分為業務域與數據域。其中，數據域分為三個層面：數據網關層、數據業務層和數據平臺層。

數據網關層主要做業務層與數據層之間的承載，包括Kafka集群與API網關，使得上下數據互通。數據業務層部分主要基于特定業務的研發工作，由于這部分工作不在平臺間通用，因而是獨立的一層。在這一層下，產品根據功能的不同配置了若干個獨立的Hadoop集群，同時把核心能力包裝成公共服務，提供給業務研發人員使用。

業務域部分包括了傳統的微服務及相應的存儲模塊。

第一，這兩層之間的數據防火墻非常重要，二級數據防火墻可確保系統內部數據的有效隔離。

第二，數據域的分層。對此，個數架構上設立的三層對應三個不同的職能團隊，數據網管層—數據運維，數據業務層—業務線的研發團隊，數據平臺層—數據部門，這樣的職能劃分可以有效提升業務線產品研發效率。

第三，集群資源的隔離。業務線的開放集群需要通過資源劃分的方式，實現資源的隔離。此外，隔離GPU計算集群資源也是非常有必要的。

第四，實時與離線的兼顧。在開發時，無論是何種產品，我們始終需要把實時和離線兩種情況考慮在內。

最后，數據儲存。業務線、數據層、平臺層都要有相應的數據儲存。此外，應通過合理的規劃，確保每一類數據存放在合適的位置。

實時多維統計架構解析

Mobile API從SDK收集到上報的數據，以文件形式Log保存下來，通過Flume進入到Kafka，接下來通過實時與離線兩條路進行處理，最后通過數據API封裝提供給上層的業務系統使用。

在離線統計方面，個數可支持到小時級別。同時，我們會全流程監控數據的流轉情況，當出現數據丟失或者延遲等情況時，確保第一時間監測到。

在這里需要補充幾個關鍵的、需要解決的點：用戶去重、頁面的唯一性標識、多維度統計的處理策略，以及保證數據在各個環節中不丟失。

數據整合，提供多維指標

個推擁有強大的大數據能力，可以為應用統計產品提供豐富的數據維度。

首先，設備指紋。目前移動設備存在兼容性混亂等問題，個推則通過為應用打上唯一的設備ID標識來解決這個問題。

第二，以第三方視角提供應用留存、安裝、卸載，活躍等中立的分析數據。

第三，用戶畫像。無論是性別、年齡段等靜態標簽，還是興趣愛好等標簽，都可通過個推的大數據平臺獲得。

自動建模預測&模型評估
一個標準化的建模工作大體包含以下幾個步驟：首先選取一批正負樣本用戶；然后對其進行特征補全，把無關特征進行降維操作；之后，選擇合適的模型進行訓練，這也是一個非常消耗CPU的過程；接下來是目標預測，我們需要整理或補齊目標用戶的所有特征，再將數據投入模型中，獲得預測結果；最后是模型評估。模型評估之后，再進行下一個迭代調整，循環往復。

在建模環節，實時性是需要考慮的重要因素之一。最傳統的離線訓練是很常規的建模方式。預測可以選擇高性能的離線方式，但它的缺點是反饋太慢，有可能導致結果出來之前沒有其他的機會實施運營方案，因而我們需要提供更實時的預測功能。比如用戶新安裝或完成某個操作之后，系統實時獲得預測結果，并立即進行運營干預。

最后是實時訓練，從我個人的角度來看，這是未來發展的一個方向。

對于整個建模的基礎架構，毫無疑問我們選擇了tensorflow，目前主流的模型都可以在tensorflow下實現。它擁有諸多優點：支持分布式部署，可并發、集成擴展，可支撐集群Serving，能夠以API形式提供模型服務……因而它非常適合預測服務的技術架構。

離線建模過程如下：數據落到HDFS之后，先通過Azkaban進行任務調度，數據清洗后把應用內的統計數據收集匯總，接下來將個推擁有的大數據能力與之進行整合，形成整體的數據Cube輸入到TF集群，TF集群會根據預測事件的配置，綜合進行模型訓練，最后輸出結果。

目標預測實現方案相對簡單，只需要把模型導入到tensorflow的Serving集群即可。預測結果再通過DAPI封裝出來，給到上層業務層調用。

目標預測首先要進行特征補全。這項工作極富挑戰，需要針對每一個新用戶的要求盡快預測并完美地補全特征。

第二部分是預測結果。預測最終得到的是概率值，我們需要去評估概率值是否處在合理范圍內，概率分布是否符合我們的預期。如果不達標，我們就需要重新評估這個模型，或者認為預測是失效的。

第三部分是tensorflow集群。通過容器化部署，可以將預測服務部署到獨立的Pod上。根據不同的實時性要求，個數可通過API的形式提供對外服務，也可以提供實時回調。

模型評估是預測的關鍵步驟，評價體系不完備可能直接導致最后的結果不可用。

精準率與召回率，這兩個與預測準確度相關的基礎指標是需要重點關注的。由于精確度與閾值相關，我們也支持開發者自主調整。

Lift也是一項重要指標，它反映了我們的預測能夠產生多大的效果提升。顯而易見，篩選的人群比例越大，提升的比例會逐漸遞減。具體應用的時候，我們需要根據場景或需求來選擇一個合理的值。

ROC與AOC，這兩個指標作為模型整體評估指標，用于評估在不同閾值下模型的表現。為提升模型的區分能力，我們勢必會追求AOC最大化。AOC值是一個定量的指標，適合做模型的持續監控。此外，對模型做每日評估也是必要的，如果AOC值不能夠達到預期，我們可以及時選擇其他模型。

在監控方面，首先要確保測試用戶的選擇足夠隨機。我們每天會選擇一批測試用戶來驗證模型的效果，然后評估準確率、召回率以及AOC。除了內部校驗，我們也會把這個指標提供給開發者。同時，緩存預測結果的歷史數據，可以輔助每天的效果評估。

精準推送集成，增能實際場景

應用內埋點數據和預測結果可以通過個數傳遞到推送系統，方便開發者在推送環節直接以人群包的形式選擇目標用戶，或者下載這個人群包，上傳到廣點通等平臺做廣告投放。

個數Roadmap
個數產品在5月份已經正式對外開放，大家可以在http://www.getui.com/cn/geshu...。模型預測功能目前處于測試階段，我們希望到Q4時，能夠正式把能力對外開放出來，幫助大家認識模型、使用模型，并享受模型帶來的價值。