如何構建標籤畫像工程體系及實現方案

　　 一、前言

　　“標籤畫像”或者說“使用者畫像”體系建設是各大網際網路公司在發展過程中繞不開的話題，在阿里內部以及各大網路論壇上也有諸多分享和討論。但大多立足資料演算法或產品形態，解決方案方面並不多（尤其是工程研發實際構建角度）。本文初衷是想站在工程研發的角度，以阿里本地生活標籤畫像系統的開發經驗為基礎，分享一下構建標籤畫像體系的實踐經驗。

　　本文將按總分的結構進行展開：首先對標籤畫像的基本概念做簡單的說明；其次會從業務需求的角度出發，闡述如何構建一個可用的最小標籤畫像系統單元；而後會以這個最小單元為基礎，對部分重點模組進行擴充套件介紹；最後會進行總結，並對文中未涉及的發展方向簡要說明。希望對大家有所幫助。

　　 二、基本概念

　　便於後續文章開展，以下結合經驗，介紹了一些標籤畫像系統中的常見概念，僅供參考。

　　標籤

　　標籤（tag）通俗意義上講是對某一類群體或物件的某項特徵進行的抽象分類和概括。從資料角度來說，是對資料集的某一特徵進行的抽象描述，可以作為一個維度，也可以作為一個屬性。標籤值一般都是可分類、可窮舉的，比如使用者性別。而對一些數值類的標籤，既可以保持原有值，也可以做進一步的抽象：比如客單價，可以根據數值進一步抽象成高客單價、低客單價。

　　畫像

　　畫像（profile）是對特定人或物件的描述資訊的集合。一個使用者的畫像可以描述成“25歲，男性，在網際網路公司上班，喜歡喝可樂 等”。人群畫像分析則是對特定人群進行的畫像分析描述，比如：“荷蘭成年男性”這個人群，“身高”這個標籤，“80%高於一米八”標籤值特徵描述。以個性化推薦場景為例，畫像是基於資料刻畫使用者需求的模型，資料標籤化則是構建這個模型的方法。

　　群組（人群）

　　群組（group）是特定人和物件的集合。在標籤畫像系統中，可以透過標籤組合篩選出群組，也可以直接人工定義一個群體作為群組。群組是差異化營銷活動的物件和常見手段。

　　圈選

　　根據人或物件的特徵標籤，篩選出特定集合的過程。

　　 三、構建最小標籤畫像系統

　　本節透過實際的營銷場景，從後端研發角度，遵循構建最小可執行系統的原則，闡述從0到1實現一個標籤畫像系統的基本技術架構和中介軟體選型。

　　3.1 業務想要什麼

　　以“發優惠券”這個業務運營場景舉例，涉及標籤畫像的運營過程大體可分為四步：首先運營人員要了解目標人群數量申請預算（預估），其次圈出滿足條件的人群（圈人），然後對目標人群進行發券（投放），最後使用者在核銷的時候進行最終確認（判定）。

　　3.2 我們有什麼

　　不管是預估還是圈選，其實我們最初的材料都是一張張使用者屬性表，而使用者的每一個屬性欄位都可以作為一個“標籤”。標籤有多種分類方式，從複雜程度可以分為原子標籤、複合標籤，從時效性上又可以分為實時標籤、離線標籤等。

　　3.3 技術要實現什麼

　　第一小節已經做了基本的業務需求分析，此處我們再明確一下：

　　人群預估 —— 新建一個實時預估介面

　　人群圈選 —— 生成一張離線表（本文使用ODPS表）

　　人群投放 —— 生成一個人群檔案（本文使用OSS儲存檔案）

　　人群判定 —— 新建一個判定介面

　　3.4 技術選型

　　可以看出，當有多標籤圈選時不可避免的會有多次並表操作，且主表資料量過大（>1億行）時，比較考驗資料庫效能（尤其join運算效能）。建議使用分析型資料庫作為資料引擎，如阿里的ADB、Hologres或者ES，具體選用哪個可根據不同場景進行壓測。

　　3.4.2 圈選引擎

　　這裡的“圈選”包含生成人群表和對應檔案的過程，“引擎”則指執行的計算平臺。因而這一小節重點解決的是透過“群組生成規則”將“標籤底表”進行計算輸出的過程，基本方案如下：

　　注：本文使用阿里雲的MaxCompute平臺作為離線圈選引擎，配套使用的數倉底表（ODPS）、資料開發節點（DataStudio）、檔案儲存（OSS）均為同系列產品。

　　3.4.2 判定介面

　　群組判定介面直接面對業務方，QPS與使用者數、營銷活動數成正比，需要滿足三個基本條件：大資料量（使用者多&群組多），高QPS（使用者多&營銷場景多），低RT（ms級）。因而在資料庫選型上，建議使用KV型儲存。常見的選型可以是Redis或者Hbase，本文使用的阿里雲的Lindorm。各中效能差異不再贅述，可按需選擇。

　　3.5 完整方案

　　基於以上分析，我們基本釐清了標籤“從哪裡來”再到“到哪裡去”的問題。我們對圈選引擎小節中的流程圖稍加豐富，形成如下鏈路：　　

　　以上，分享了以標籤資料來源、群組圈選規則為原始資料，構建用於“預估”的查詢介面、用於“圈人”的ODPS結果表、用於“投放”的OSS檔案和用於“判定”的群組查詢介面的技術實現流程和選型。接下來，將會對一些重點模組的設計進行詳細說明。

　　 四、核心模組設計

　　4.1 圈選排程

　　一個標籤畫像系統每天可能面臨數以萬計的群組圈選任務，因而需要一個相對獨立的圈選模組控制每天任務的執行排程。　　

　　圈選引擎主要由圈選任務池、任務排程、任務執行、依賴檢測四個子模組構成。任務池負責維護所有任務的執行狀態（init、ready、running、success/failure）；任務排程模組居中排程，負責對圈選任務送檢依賴、派發執行、失敗重試，並控制整個引擎排程速率；任務執行模組將直接與資料中介軟體（ODPS/ADB/Lindorm/OSS）進行互動，包括提交圈選SQL、監測圈選狀態、推送圈選結果 等；依賴檢測模組負責檢驗圈選任務的前置依賴，根據群組型別不同會有不同的差異，下一小節單獨說明。

　　4.2 依賴檢測　　

　　以上，列出了常見的六種群組依賴方式，概括一下可分為四種：首先是最常見的標籤底表依賴；其次是有些使用者已經自定義圈出了一個群組（檔案/ODPS表），那麼對對應的人群底表有依賴；然後是外部群組依賴，這裡的外部也可以擴充套件理解為“其他”，就是本體系之外的系統透過某種方式生成群組來進行系統對接，需要定製化檢測依賴；最後就是以上幾種方式的組合，群組與群組之間、標籤與群組之間可以進行二次交併差，因而會有父群組依賴。

　　4.3 ID對映　　

　　上圖回顧了從群組建立到生成可消費資料的過程。群組在建立完成後，平臺將會根據群組的生效時間生成日滾任務並執行排程。但是在通用圈選引擎計算完成之後，增加了一個ID對映的模組：狹義的ID對映可直接理解為ID型別轉換。以在常見的電商環境為例，可運營實體包含了消費者、商戶、商品。但在實際圈選時，圈的主體未必是要運營的主體。比如運營想圈出所有賣“小龍蝦”這個商品的商戶，加入“小龍蝦節”活動。那麼運營在圈的時候可能圈的是所有包含“小龍蝦”關鍵字的商品，系統要做的就是提供一個通用能力把包含這些商品的商戶也圈出來。這就是ID對映的基本功能和應用場景。　　

　　廣義的ID對映是指在這一環節，系統所能提供支援的衍生處理能力。還是剛才的例子，運營在圈出所有賣小龍蝦的商戶後，還想知道這些商戶在哪個城市，註冊的聯絡方式是什麼。那麼系統就要在商戶列表中再查詢新增城市和聯絡方式兩個欄位，方便進一步使用。

　　 五、總結

　　以上，以阿里本地生活標籤畫像系統的開發經驗為基礎，分享了一些基本的標籤畫像系統工程實現方案，挑選了部分核心模組做了細化分享。而當系統消費達到一定體量時，還有諸多可擴充套件的點：系統架構方面，包括生產側的標籤生產管理、消費側的租戶化以及整個生產消費過程中監控運維體系 等；系統應用擴充套件方面，則包括群組洞察分析、場景化運營策略以及運營投放過程中的效果回收/診斷/推薦 等。後續有機會再進行分享。

　　文中的的一些技術架構和選型，都是結合自身業務發展需求所做的選擇，遇到類似場景可參考。