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

前言：近期，智能大數(shù)據(jù)服務商“個推”推出了應用統(tǒng)計產(chǎn)品“個數(shù)”，今天我們就和大家來談一談個數(shù)實時統(tǒng)計與AI數(shù)據(jù)智能平臺整合架構(gòu)設(shè)計。

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

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

其二是地利。個推經(jīng)過多年的積累，擁有了堅實的數(shù)據(jù)基礎(chǔ)；另外，個推基礎(chǔ)架構(gòu)也非常成熟，并在諸多垂直領(lǐng)域?qū)崒嵲谠谔峁┝撕芏鄶?shù)據(jù)服務。

第三是人和。內(nèi)部的研發(fā)人員在實戰(zhàn)中積累了豐富的經(jīng)驗，公司與外部應用開發(fā)者和合作伙伴建立了長期緊密的聯(lián)系。

正是在這樣的背景下，我們推出了這一款應用統(tǒng)計產(chǎn)品“個數(shù)”。

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

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

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

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

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

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

技術(shù)架構(gòu)：業(yè)務域+數(shù)據(jù)域

個數(shù)的整體架構(gòu)分為業(yè)務域與數(shù)據(jù)域。其中，數(shù)據(jù)域分為三個層面：數(shù)據(jù)網(wǎng)關(guān)層、數(shù)據(jù)業(yè)務層和數(shù)據(jù)平臺層。

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

業(yè)務域部分包括了傳統(tǒng)的微服務及相應的存儲模塊。

第一，這兩層之間的數(shù)據(jù)防火墻非常重要，二級數(shù)據(jù)防火墻可確保系統(tǒng)內(nèi)部數(shù)據(jù)的有效隔離。

第二，數(shù)據(jù)域的分層。對此，個數(shù)架構(gòu)上設(shè)立的三層對應三個不同的職能團隊，數(shù)據(jù)網(wǎng)管層—數(shù)據(jù)運維，數(shù)據(jù)業(yè)務層—業(yè)務線的研發(fā)團隊，數(shù)據(jù)平臺層—數(shù)據(jù)部門，這樣的職能劃分可以有效提升業(yè)務線產(chǎn)品研發(fā)效率。

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

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

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

實時多維統(tǒng)計架構(gòu)解析

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

在離線統(tǒng)計方面，個數(shù)可支持到小時級別。同時，我們會全流程監(jiān)控數(shù)據(jù)的流轉(zhuǎn)情況，當出現(xiàn)數(shù)據(jù)丟失或者延遲等情況時，確保第一時間監(jiān)測到。

在這里需要補充幾個關(guān)鍵的、需要解決的點：用戶去重、頁面的唯一性標識、多維度統(tǒng)計的處理策略，以及保證數(shù)據(jù)在各個環(huán)節(jié)中不丟失。

數(shù)據(jù)整合，提供多維指標

個推擁有強大的大數(shù)據(jù)能力，可以為應用統(tǒng)計產(chǎn)品提供豐富的數(shù)據(jù)維度。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

應用內(nèi)埋點數(shù)據(jù)和預測結(jié)果可以通過個數(shù)傳遞到推送系統(tǒng)，方便開發(fā)者在推送環(huán)節(jié)直接以人群包的形式選擇目標用戶，或者下載這個人群包，上傳到廣點通等平臺做廣告投放。

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