作者董霖，個推高級技術總監。
前言：近期，智能大數據服務商“個推”推出了應用統計產品“個數”，今天我們就和大家來談一談個數實時統計與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時，能夠正式把能力對外開放出來，幫助大家認識模型、使用模型，並享受模型帶來的價值。