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