應用統計平臺架構設計：智能預測APP統計數據

前言：近期，智能大數據服務商「個推」推出了應用統計產品「個數」，今天咱們就和你們來談一談個數實時統計與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.html自由註冊並使用。模型預測功能目前處於測試階段，咱們但願到Q4時，可以正式把能力對外開放出來，幫助你們認識模型、使用模型，並享受模型帶來的價值。