用戶畫像實踐：神策標簽生產(chǎn)引擎架構
點擊上方“數(shù)據(jù)管道”，選擇“置頂星標”公眾號
干貨福利，第一時間送達
分享嘉賓：王琛@神策數(shù)據(jù)
編輯整理：馮露
出品平臺：DataFunTalk
用戶標簽及其應用場景
標簽生產(chǎn)平臺的需求
批流一體的標簽生產(chǎn)架構
總結
1.?什么是用戶標簽
簡單說，就是對用戶的某個維度特征的描述。對一群用戶而言，我們?yōu)榱四茏寴I(yè)務做的更好，就想知道他們的很多特征。比如說，我現(xiàn)在有個10萬塊錢的活動預算，那這個錢應該集中花在哪里呢？針對這個問題，我們希望對給定的用戶群體，能知道他們的商業(yè)價值，對他們的商業(yè)價值有一個很好的描述。知道里面哪些人才是我們重點要服務的對象。
2.?用戶標簽的應用價值
用戶標簽的應用主要是四種場景：
用戶特征洞察：
輔助用戶分析和用戶洞察，用戶標簽可以幫助業(yè)務人員快速的對用戶有一個認知，然后發(fā)現(xiàn)里面顯著的特征，獲得一些商業(yè)靈感。
增強數(shù)據(jù)分析：
標簽還可以豐富數(shù)據(jù)的維度。對我們的業(yè)務數(shù)據(jù)，有更深層次的對比分析，而分析洞察得到的靈感以后，可以輔助業(yè)務落地。
精細化運營：
一方面，可以將用戶群體，切割成更細粒度的群組，使得運營從粗放化到精細化，用多種不同的手段，不同的渠道去觸達，比如說短信、推送、郵件等等，對于用戶進行驅動或召回，從而達到事半功倍的效果。
數(shù)據(jù)產(chǎn)品應用：
另一方面，除了驅動人工的業(yè)務以外，用戶標簽還可以成為其他數(shù)據(jù)產(chǎn)品的基礎，比如個性化推薦系統(tǒng)，廣告系統(tǒng)，CRM等這些系統(tǒng)。自動化的業(yè)務系統(tǒng)能更有效的利用這些用戶標簽，從而發(fā)揮更巨大的威力。
3. 為什么常見的標簽體系用不起來？
用戶標簽其實已經(jīng)不是新概念，十幾年前，就已經(jīng)有各種各樣的標簽系統(tǒng)，但是在我們這幾年的實踐過程中，其實發(fā)現(xiàn)，很多的標簽系統(tǒng)在實際落地的過程中，都會多多少少的遇到一些問題。這里面主要是兩大類問題。
難全面覆蓋：
在創(chuàng)建標簽的過程中，數(shù)據(jù)的提供方希望盡可能滿足各種各樣業(yè)務的需求，就會有一些發(fā)散性的構思，但是實際上在操作中很難覆蓋特別的全面，業(yè)務是一直變化的，不能預知一年以后這個業(yè)務發(fā)展成什么樣子，所以很難覆蓋全。
難落地應用：
另外一大類問題，業(yè)務方在使用的時候，面對的是成百上千的甚至上萬的標簽，他們也比較懵，不知道怎么使用，也不知道標簽的統(tǒng)計口徑是什么，用戶分層的切割規(guī)則等等這些，從而導致了不會用或者不好用，用不起來。
1.?應用驅動的標簽構建
我們的解決方案其實是基于標簽的應用流程，去反向去反推這個標簽體系的構思和建設。
這個反推，其實是一個比較需要業(yè)務經(jīng)驗的事情，根據(jù)我們的經(jīng)驗，大部分情況下，產(chǎn)品部門和運營部門，都會有一些不同的標簽使用方式。比如運營部門，一般是用于做活動，他們關心的問題是，怎么樣做一個活動才能夠提高客戶的轉化。而產(chǎn)品則是負責對某一個問題提供解決方案，他們需要觀察的是客戶的特征，去決定如何設計才能解決大多數(shù)的問題。
2.?根據(jù)標簽的使用目的，體系化梳理標簽
總體來說，無論是產(chǎn)品還是運營，我們都把它叫做業(yè)務部門，他們應用標簽的流程實際上一般來講就分三步。
目標人群是誰？
其實是一個戰(zhàn)略性的問題，定位的目標人群，這里其實往往應該先看，比如說商業(yè)價值類的標簽，然后去幫助我們的業(yè)務人員發(fā)現(xiàn)商業(yè)價值最大的那個人群。
他們喜歡什么？
如果目標人群是有比較明確的行為數(shù)據(jù)的，比如說他們是活躍用戶，這時候應該去看他的用戶偏好類型的這個標簽，比如他喜歡做什么，然后他的興趣愛好是什么等等這些。
如果目標人群行為數(shù)據(jù)比較少，比如說他是新用戶，或者是一些靜默用戶，那這個時候就應該從他們所屬的生命周期標簽出發(fā)，去計劃構建促進轉化或者是召回的策略。
如何執(zhí)行策略？
就是我們應該做什么，做一個什么樣的策略，這個策略怎么落地？然后當策略方向有了以后，還需要一些具體的參考信息，比如推送什么時間發(fā)這種問題，需要有一些具體的營銷時機類的標簽，比如說用戶一般的活躍時間段，然后來幫助整個計劃的這個落地。
3.?標簽類型
回到整個我們的標簽平臺本身，我們認為首先作為一個標簽平臺，它需要具有非常靈活的標簽創(chuàng)建的能力，從而才能適應不斷變化的業(yè)務需求。
具體來說，我們是把需要創(chuàng)建的這個標簽分成了三個大類。
數(shù)值聚合型標簽：
這類的標簽就是主要是在用戶維度的數(shù)值計算，主要是彌補在數(shù)據(jù)采集當中未能及時補全的一些信息。如：每個?戶最近半年消費次數(shù)、最后?次消費時間、近?周消費的商品類別
還有一種數(shù)值聚合是實時標簽，類似這種標簽一般都是用于運營活動的受眾的篩選。如：某活動開始時間到當前時間，?戶的下單?額
分群標簽：
顧名思義就是給一群人，給他們打上一個標簽。
如：將累計充值?額超過 10000 元的?戶標記為 「?價值?戶」
如：X運營活動開始后，通過運營?注冊下單的?戶，則標記為 「X活動轉化?戶」
狀態(tài)轉化標簽：
這個是我們在我們定義里面是邏輯相對來說比較復雜的一類標簽，這類標簽通常來說都是實時標簽，對于實時性的要求都會比較高，要求是秒級分鐘級的。如：通過?為來標記新?戶是否為??黨。
另外一類呢就是還有一些比較復雜的運營活動，或者是從控制成本的角度來做一些運營活動。如：在規(guī)定時間內(nèi)，完成運營活動中的?少 3 項任務，并完成領券下單轉化的，則標記為「價格敏感型?戶」。
4.?標簽平臺的技術需求
靈活可拓展的標簽創(chuàng)建規(guī)則：我們需要有非常靈活可擴展的標簽的規(guī)則的定義。
在有限的資源條件下支持億級用戶基數(shù)的標簽生產(chǎn)：在相對比較有限的條件下，能夠支持相對比較大的用戶基數(shù)的標簽生產(chǎn)，需要對計算或者存儲方面有比較高的優(yōu)化，對于系統(tǒng)架構來說，平臺的伸縮性和這種適應性都會要求相對高一些。
離線標簽按天更新，實時標簽秒級延遲：對于業(yè)務，我們一般的標簽可能是按天更新的，例行標簽。另外有一種就是實時活動，計算的響應要求比較高，實時標簽的計算要在秒級之內(nèi)完成，可能秒級之內(nèi)還要后面做推送，然后觸達到用戶。?
1.?基礎數(shù)據(jù)流
下面主要講講技術問題，首先，在我們的理解當中，標簽平臺是一個中間層的服務，為前臺服務提供一個數(shù)據(jù)支持，然后另外一方面，標簽平臺它所用到的數(shù)據(jù)其實是依賴于底層的基礎數(shù)據(jù)平臺的原始數(shù)據(jù)。
這張圖就展現(xiàn)了神策基礎數(shù)據(jù)流平臺的架構。數(shù)據(jù)流是從左到右的，最左邊是所有的采集的方式，各種SDK采集了數(shù)據(jù)之后，經(jīng)過數(shù)據(jù)接收系統(tǒng)、導入系統(tǒng)和存儲系統(tǒng)，然后查詢系統(tǒng)，最后展現(xiàn)。?
2.?簡化的數(shù)據(jù)模型
在這個流里，數(shù)據(jù)模型其實是非常簡單的，基本會分成兩大類：用戶行為數(shù)據(jù)、用戶屬性數(shù)據(jù)。
用戶行為表：
其實是個寬表，它里面是幾個常用的維度，主要描述了什么人在什么時間，做了一件什么事。所以主要字段就是：時間、用戶ID、事件、渠道、搜索關鍵詞、商品價格等。
用戶屬性表：
用戶屬性表，主要描述用戶的屬性情況，相對變化不大。主要字段有：用戶ID、性別、注冊渠道、會員等級等。
3.?基于有限流的標簽計算
所以在我們的系統(tǒng)里面，首先會做一套批量離線的標簽處理引擎，依賴的是我們底層比較穩(wěn)定的數(shù)據(jù)結構。這個標簽引擎一邊讀事件數(shù)據(jù)，一邊讀用戶的屬性數(shù)據(jù)，再配合上特定的標簽規(guī)則，做一個批量計算，最后生成用戶標簽。
有限流：
Event-User 數(shù)據(jù)可以理解為永不停?的數(shù)據(jù)流。只要業(yè)務在用，就有不斷的數(shù)據(jù)進來。
批量離線計算開始時，參與計算的數(shù)據(jù)已完全?庫。不會有還沒有入庫的數(shù)據(jù)。
在有限流的情況下，數(shù)據(jù)是穩(wěn)定的，計算具有冪等性，不會頻繁變化。與之相對的就是基于無限流的實時計算標簽，在計算啟動的時刻，數(shù)據(jù)還在源源不斷的進來，計算不具有冪等性。所以批量標簽引擎實際上跟一些離線數(shù)據(jù)倉庫和離線引擎一樣，最核心的兩部分，一個是調(diào)度器，一個是計算引擎。
實現(xiàn)?式：
使? Impala + HDFS(parquet) 為底層計算引擎
標簽規(guī)則引擎負責將標簽定義翻譯為?效 SQL
使? impala 分析函數(shù)實現(xiàn)特定的規(guī)則
通?調(diào)度器負責例?任務的調(diào)度
4.?非實時標簽數(shù)據(jù)存儲格式
數(shù)據(jù)存儲方面，我們采取的方式是每個標簽都存一張物理的表，以時間作為分區(qū)，因為離線計算一般都是按天調(diào)度的，所以就按天存儲，每日的結果存為一個partition，然后這個partition下面存的都是parquet類型的文件，并且用gzip來壓縮。我們這個單表里面每一行是一個用戶的ID，然后后面有一列跟的是它的這個標簽的值，在這種結構下用gzip一壓，其實壓縮比還是比較高的，比較可觀。
5.?標簽寬表加速查詢
每個標簽存一張物理表，其實也是有比較大的問題。這個表雖然在數(shù)據(jù)更新的時候很好處理，能夠保持更新時的數(shù)據(jù)的一致性，但是對于查詢端其實并不是很友好，尤其是在做多條件過濾的時候，需要將底層的多張表進行 join 操作，計算代價很大。為了提高性能，我們在后臺會有一個例行任務，定時將這些已經(jīng)固化下來的標簽編號，把它合并成一張寬表，主要依據(jù)標簽的離線計算，基本上每天都更新一次，更新完了以后這個數(shù)據(jù)基本上就固定保持穩(wěn)定了。
標簽單表：
數(shù)據(jù)更新代價低，可保證數(shù)據(jù)?致性
問題：查詢需要多張表 join，性能堪憂?
標簽寬表的實現(xiàn)?式：
標簽寬表是?個所有單表 join 的 view
每當單表數(shù)據(jù)更新時，更新該 view
定時將 view 固化為物理表
遺留問題：parquet 在列數(shù)過多的情況下，性能會有所下降
6.?用bitmap優(yōu)化人群篩選
另外就是使用bitmap來做人群篩選優(yōu)化，部分標簽值所對應的?群使?頻次更?，如「?價值?戶」、「活躍?戶」等。使?標簽篩選?戶，可以理解成針對?群包的集合操作。
bitmap 過濾的實現(xiàn)?式：
將標簽值對應的?群包構建 RoaringBitmap
?群篩選時，先通過 bitmap 的交并差運算得到過濾?的 bitmap
impala 使? bitmap 做最終的過濾器，得到?群包（包含太多元素的 bitmap 體積太?，反?影響效率）
7.?基于無限流的標簽計算
大部分業(yè)務場景實際上是離線的部分就能滿足了，實時的部分主要是要滿足一些運營活動的一些需求。我們這個實時標簽引擎其實也并不復雜，輸入的數(shù)據(jù)就是我們實時流的事件數(shù)據(jù)，根據(jù)標簽規(guī)則，還有用戶屬性，用戶標簽對他做在線的一個計算，從而輸出的是一個標簽狀態(tài)的變更，最后得到這個標簽結果。
8.?實時標簽引擎
實現(xiàn)?式：
實時標簽計算使? Flink
Flink job 監(jiān)聽 Kafka 的 event topic，計算由事件觸發(fā)
計算過程就是實現(xiàn)?個狀態(tài)機
計算的中間狀態(tài)存儲在 Flink State 和 KV 存儲中
實時計算能使?的離線標簽，需要先訂閱到 KV 存儲中
標簽結果輸出到 Kafka 的 tag topic
9.?批流一體的架構
整體的架構就像這張圖一樣，在我們的標簽管理控制臺這一層，其實是對標簽規(guī)則做了一個劃分，在這里會識別當前要算的這個標簽，到底是一個離線標簽還是一個實時標簽比較好？如果它是實時標簽，它要對哪些離線標簽進行訂閱，也是在這里處理的。離線標簽就做離線的計算，然后在最下面有一個數(shù)據(jù)同步服務，會把離線標簽計算的結果同步到kv里面，這里面其實也不會依賴特別多，我們不會給他做一些特別復雜的計算，然后依賴特別多的數(shù)據(jù)，因為kv里面也會有性能問題。然后Flink State實際上是kv存儲的半個緩存，實際上計算由Flink Job來進行。
最后總結一下，我們所理解的標簽平臺，實際上是以應用為目標來構建的標準體系。我們認為在這個平臺里面標簽規(guī)則一定是要靈活的，要讓真正做業(yè)務的技術小白，也能夠靈活的自主配置，然后能夠自己搭建這個標準體系，能夠自己改規(guī)則。在技術層面，標簽平臺它是依賴于底層特別穩(wěn)定的數(shù)據(jù)模型和數(shù)據(jù)流的，然后標簽平臺本身它的技術架構實際上是批流一體，因為批量相對來說計算性能更高，代價更小，然后流式是實時性更高，兩邊一起組合而成的標簽生產(chǎn)體系。
1. 有不少的標簽計算邏輯是相似的，怎么合并這一類的相似標簽生產(chǎn)，怎么提高效率？
首先我們的邏輯是，只要單個計算足夠快，就可以不合并，所以大部分情況優(yōu)化的是單個計算的性能。相似標簽只在 SQL 級別做了個結果的緩存，但實際效果還不太明顯。更有效的方式可能是人工介入。
2. 運營圈人的時候能否支持實時標簽和離線標簽的整合圈人？
這個其實是可以的，我們這個實時標簽，它的輸出的結果實際上到Kafka里面，Kafka后面的消費端是可以把它存到hdfs上的，然后就跟離線標簽算出來的結果實際上是一樣，并沒有什么太多的區(qū)別。
3. 現(xiàn)在的實時標簽目前占比大概多少？是不是不同的企業(yè)會根據(jù)業(yè)務去做一些調(diào)整？
其實在系統(tǒng)規(guī)劃里面實時標簽的占比并不高，或者說應該是比較低。一方面是從計算資源的角度來考慮，實時計算的成本會比較高。另外也是從需求方面考慮，大部分可以通過合理規(guī)劃，將部分計算轉為離線 & 實時相結合的方式來處理。
王琛
神策數(shù)據(jù) |?用戶畫像研發(fā)部 & 武漢研發(fā)中心負責人
加入神策數(shù)據(jù)之前，王琛先生曾任職于百度大數(shù)據(jù)部高級研發(fā)工程師，參與百度日志平臺、用戶數(shù)據(jù)倉庫、新日志標準化、Impala 查詢優(yōu)化等項目；曾擔任百納信息 ( 海豚瀏覽器 ) 研發(fā)總監(jiān)、人工智能實驗室負責人。王琛先生有 7 年以上大數(shù)據(jù)從業(yè)經(jīng)驗，碩士畢業(yè)于英國愛丁堡大學人工智能專業(yè)。