導讀：
本次分享題目為基於Doris的知乎DMP系統架構與實踐，由知乎使用者理解&資料賦能研發Leader 侯容老師帶來經驗分享，主要圍繞四個方面展開介紹：
背景：知乎DMP的業務背景、流程、特徵及功能介紹
架構與實現：知乎DMP的架構設計和實現
難點及解決方案：知乎DMP平臺建設的難點和解決方案
未來展望：知乎DMP平臺下一步迭代方向
01
背景
DMP本身是個老生常談的業務領域，在廣告系統出現的時候就有了類似DMP平臺的系統。業界做得比較好的有騰訊廣點通、阿里達摩盤。
知乎搭建DMP的原因可簡單概括為
：知乎存在大量站內運營的業務需要，搭建DMP平臺需要支援同知乎內部系統的對接，搭建DMP存在一定量的知乎定製化需求，需要適配知乎的內部運營流程。
1. DMP業務背景
首先，丟擲問題：知乎業務中具體存在哪些問題需要解決？為什麼要建立DMP平臺來解決這些問題？
下面圍繞
業務模式
、
業務場景
、
業務需求
等三個主要方面，來具體說明建設DMP平臺的必要性和功能定位。
（1）業務模式
如何找出核心客戶，圍繞某個客戶應該如何運營、如何適配營銷操作、以及廣告投放，如何進行人和業務的匹配，都需要完成對人的定向、對人的畫像洞察，以及對人的理解和運營操作，這些都是DMP的主要業務定位。
知乎DMP主要包括三種業務模式：
站外轉站內
，典型的場景是，在廣告側有廣告主在知乎平臺投放廣告，觸發站外人群，如何透過一個Mapping將站外人群承接到站內，且在站內的各個系統上能夠承接這些使用者包。
站內轉站外
，典型的場景是，增長投放方面，如何在知乎平臺找到一個定向價值使用者群，再針對這些使用者包到三方平臺進行廣告投放。
站內自閉環
，主要是知乎內部運營，包括內容運營、使用者運營、活動運營等，一方面增加內容宣傳和營銷；一方面完成客戶的定位及客群分析，解決一些客戶問題；策劃一些活動，促成客戶價值提升和針對營銷效果達成。
（2）業務場景
針對上述三種業務模式，知乎DMP適配了多種業務場景：
資訊流
，比如推薦場景，有一些定向推薦、定向提權等訴求，把某些內容推給誰，某些內容針對特定客戶進行定向提權，去重新打分等。
廣告
，比如實時競價，基於一個客戶身上掛的廣告特徵，進行實時競價，排序篩選最合適的廣告推送。
詳情頁
，比如彈窗提示，當用戶進入詳情頁，根據觸發的規則條件情況，進行相關的訪問引導。
活動平臺
，比如目標使用者，對該活動是否可見？哪些活動可見？等進行管理適配。
觸達系統
，比如推送、訊息、彈窗、簡訊等，針對具體的客群進行Push、站內信等觸達。
站外投放
，比如站外廣告，面向特定的人群，進行站外廣告觸達。
（3）業務需求
基於三種業務模式、六種業務場景的拆解分析，提煉出
人群管理的功能需求
主要包括：
人群對接
，主要是對接系統，無論是站外系統還是站內系統，基礎需求是使用者命中了哪些人群包——以廣告系統為例，人群包的ID可以Mapping為一則廣告，即一個使用者身上可以掛哪些廣告；其次是人群包（內部），把人群推薦給誰，或者把哪些內容推送給該人群；最後是人群包（外部），主要圍繞外部廣告投放場景，提供人群包服務。後兩種主要在內部統一ID和外部多平臺ID等管理存在差異。
人群定向
，主要包括匯入、匯出、標籤圈選、人群泛化、人群使用者量預估等基礎功能。
人群洞察
，包括人群包內部畫像洞察、不同人群包之間的差異對比分析等。
2. DMP業務流程
基於知乎DMP業務模式提煉、業務場景刻畫、業務需求澄清等背景梳理，結合站內系統、站外系統互動協同，形成了一套業務流程。
概括為
四大核心功能模組
：
人群定向模組
，包括人群圈選、人群泛化、使用者匯入等；
目標使用者ID-Mapping模組
，包括站外Mapping、站內Mapping等對接適配；
使用者洞察（效果評估）模組
，包括構成分析、對比分析等；
ABTest（活動最佳化）模組
，包括策略設定、實驗組織等。
圍繞站內運營自閉環、站內向站外投放閉環、站外向站內廣告閉環等人群運營，可以靈活適配活動落地。
3.DMP畫像特徵
在人群定向模組，存在大量的人群標籤篩選、組合標籤篩選的應用要求，對DMP平臺的畫像特徵庫提出很高的要求。
知乎DMP按照三層結構進行
畫像特徵分類設計
：
第一層分類：按主題分組
，目前主要包括個體資訊、消費特徵、創作、興趣、圖文等8組。
第二層分類：按屬性分組
，比如個體資訊主題包括基礎特徵、裝置屬性、社會屬性等，知乎DMP目前有40組屬性特徵分組。
第三層分類：按標籤類分組
，比如性別類、手機品牌類、話題類等，目前有120類標籤。
基於以上三層特徵設計，知乎DMP畫像特徵庫已有標籤（標籤值）超過250萬。
4.DMP功能梳理
按照業務功能和特徵管理兩大能力進行說明：
業務功能主要服務於運營、營銷、站內應用系統等，包括人群定向、人群洞察、ID-Mapping等。
特徵管理的核心是特徵應用接入，在大規模標籤特徵基礎上，結合使用者群體關聯、以及實時特徵要求，這部分技術支撐依賴比較重。
詳細的功能分佈參見下圖：
——
02
架構與實現
一套好的架構設計，能夠有效降低業務功能實現的複雜度；能夠支撐業務功能動態擴充套件與迭代；對於有外部互動的系統，能夠保障系統的相容性和開放性；能夠保持系統運維的便捷性。
1.DMP平臺架構
知乎DMP平臺的整體架構，不同模組進行差異化設計：
對外模組：
lDMP介面：高穩定性、高併發高吞吐。
lDMP前臺：操作簡單，低運營使用成本。
lDMP後臺：日常開發工作配置化，降低開發成本。
業務模組：
人群圈選：可擴充套件。新增特徵0成本，新增規則低成本。
人群洞察：可擴充套件。新增特徵0成本，新增洞察方式低成本。
人群泛化：可擴充套件。新增泛化方式低成本。
特徵生產：擴充套件成本低。原子特徵低成本生產，派生特徵通過後臺可配置。
ID-Mapping：遮蔽ID打通邏輯。
計算任務運維：遮蔽機器資源和任務依賴的邏輯。
儲存：可擴充套件可持續，不因業務成長而導致成本大幅增加。
架構分佈詳情
，如下圖示：
2.DMP平臺功能盤點
按照業務向、基礎向兩部分進行特徵功能介紹。
（1）業務向功能
核心功能為人群定向、人群洞察兩部分，分別支撐業務應用側和價值運營側服務。
知乎DMP業務向功能上線運營情況介紹：
支援了5。2萬人群定向；
支援340次人群洞察；
支援59次人群泛化。
（2）基礎向功能
主要包括特徵建設、ID-Mapping能力、計算任務運維等三部分工作，形成三組專業小組分工協同。
知乎DMP基礎向功能運營情況介紹：
每日2。0+TB共5日11TB（離線、實時）特徵——Doris。
120個離線生產任務和5個實時生產任務。
每日6100次人群評估，300個人群圈選，1-2個人群洞察，1個人群泛化任務。
3.DMP特徵資料鏈路及儲存
資料匯入/儲存、快速查詢/讀取，是DMP平臺關鍵的資料技術環節。
DMP的批次、流式特徵如何建設並落地到相應的儲存？
（1）離線標籤鏈路（Spark批處理計算過程）
基於Hive中的各類業務資料，進行SQL批次計算，生成tag表（落地Hive表）；
基於tag表再進行Mapping計算——主要透過使用者/裝置核心完成的統一ID計算，生成連續的自動ID，同時完成ID、Imei、IDsa等統一轉換和唯一繫結；
如果是一個新使用者，則生成一個新ID，如果是一個老使用者，則直接獲取已有ID，這個過程維護了一張ID-Mapping表，繼而附加各類MD5加密等處理過程，形成使用者唯一ID、各類ID對映關係表。知乎DMP中的ID-Mapping表已儲存約8。5億的ID轉化寬表資料。
（2）實時標籤鏈路（Flink實時計算處理過程）
基於Kafka中的各類業務資料，進行流式特徵計算，生成實時tag表（Kafka資料）；
基於tag表進行流式Mapping計算，透過使用者/裝置核心完成統一ID計算（過程同上）。
（3）列舉採集
即250萬標籤的應用服務能力。
知乎DMP平臺現有的125個標籤類分組，分別由120個離線業務儲存過程和5個實時業務事件過程計算完成，已經生成了各類原子標籤。
ES標籤搜尋儲存：
在面向標籤篩選應用環節，大規模標籤錄入操作成本太高，所有選擇使用Bulk Load自動寫入ES，生成標籤列舉表tag_group表（儲存標籤中文資訊及搜尋，約250萬記錄），生成連續自增ID；
Doris中核心儲存：
根據ES中的連續自增ID，可以對映到Doris中使用者標籤表tag_map表（倒排表，使用者和標籤組合表，約有1100億資料），Doris中還存在第三張表即使用者行為表，是基於實時數倉夠賤的，這裡不做擴充套件介紹。
基於這三張表，給客戶洞察、人群定向提供了相應的資料支撐基礎。
4.人群定向流程
基於上個環節生成的ES-標籤列舉表、Doris-使用者標籤表、Doris-ID轉換對映表，進行人群定向流程解讀。
場景一：
透過購物車圈選人群標籤，生成人群包，進行人群預估、繼而完成人群圈選，最後寫入Redis的過程。
第一步：標籤搜尋（相關標籤、標籤組合等設定，購物車生成）
第二步：人群預估（潛在人群包的動態評估，根據標籤組合聯動調整購物車配置，完成目標事件的人群匹配）
第三步：生成人群包，關聯原資料、ID-Mapping 關聯轉換（站外）；將人群包ID和人群ID寫入Redis，支援高併發查詢使用。若非高併發場景，可以寫入離線儲存機制使用。
場景二：
種子人群泛化場景，依託AI平臺完成模型訓練和人群推理泛化，透過置信度去選擇，打上人群標籤和人群包，最後寫會Doris的過程。
該場景包括歷史效果人群泛化、圈選人群的特徵泛化等。
日常業務運營過程中，對標籤、歷史人群進行組合、泛化，再限制條件進行圈選、洞察，最後再調整等靈活組合、交叉應用模式。
——
03
難點及解決方案
本部分主要圍繞人群定向方面做進行總結分享。
1.人群定向效能最佳化的痛點
知乎DMP平臺關鍵應用模組包括人群定向和客戶洞察，都依賴基礎的畫像特徵。基於當前250萬的標籤特徵資料基礎，如何解決以下兩個場景痛點：
人群定向方面關注痛點問題一：
人群預估（秒級響應）——針對投放和營銷場景，對人群數量期望是一定的，透過類似購物車的模式，動態調整使用者特徵，如何能保障快速看到預計匹配的人數？
人群定向方面關注痛點問題二：
人群圈選（分鐘級響應）——熱點運營，當熱點事件發生後，快速進行人群包圈選搶事件，對人群包時間有很高要求。
2.人群定向效能最佳化的思路（第一版）
解決上述效能問題的主要思路：
①倒排索引，將資料表變為bitmap。
②查詢條件的與或非轉變為bitmap的交併差。
③附帶完成連續數值轉變為離散標籤，即發揮離散計算的效能優勢，又提高了業務場景應用適配性。
倒排序索引，示例如下圖（左）所示：
ID-Mapping適配，基於倒排序索引最佳化結果，在匯入的過程中，完成ID-Mapping的生成（支援bitmap），實現使用者ID的連續自增。如下圖（右）所示：
結合倒排序索引儲存方式最佳化調整，查詢邏輯變化示例如下：
經過上述最佳化，仍存在單一bitmap過大的問題，導致shuffle過程網路IO過大，交換過程中資料堆積Doris出現brpc傳輸擁堵報錯，上百兆的bitmap間進行交併差計算效能低等情況；以及bitmap空間分佈分散，導致每次查詢都會有大量的資料交換，網路負載高，速度慢等特點。
3.人群定向效能最佳化的思路（第二版）
基於人群預估分鐘級、人群圈選10分鐘級的最佳化結果，再最佳化的核心思路是分而治之。
第二版最佳化的解決思路：
基於全站ID的交併差等價於將全站ID分組後的交併差結果的合併，故分而治之思路可行；考慮利用Doris的colocate group特性，將分組所有tag的bitmap閾值在同一臺物理機上，避免網路開銷；同時，升級Doris新版本，利用bitmap_and_not_count等組合函式，效能優於多函式巢狀等特性。
適配第二版最佳化的解決方案：
查詢過程調整，變更預估和圈人的查詢邏輯實現；發揮多執行緒查詢計算能力；查詢程式碼巢狀條件最佳化；寫入過程調整，進行百萬人群寫入分組，設定分組key；資料表設定colocate group。
分而治之方案的具體最佳化邏輯，如下圖所示：
最佳化前後的bitmap邏輯計算複雜度對比如下圖所示：
透過上述兩版本最佳化，實現人群定向秒級響應，人群圈選分鐘級響應效果。知乎DMP平臺達到運營投產目標。
——
04
知乎DMP平臺下一步迭代方向
1.業務運營最佳化
從DMP平臺的多核心模組整體運營協同考慮，將目前松耦合的目標結果管理模組，同平臺進行強繫結；將依賴流程繫結的A/B實驗能力，與平臺進行邏輯繫結。
2.技術迭代最佳化
技術層面，主要結合平臺日常運營圈選操作特點分析，實現以下兩方面的提升：
查詢效率提升：
自動探查SQL複雜查詢條件，預先合併成一個派生特徵的bitmap，預測和圈選時對複雜條件SQL重寫為派生特徵。
匯入效率提升：
將每天2TB的資料匯入，每15天大約會存11TB的資料，匯入過程中加速策略——結合業界的Spark寫OLTP引擎，考慮能否透過Spark直接寫Doris Tablet檔案，並掛載到FE。
今天的分享就到這裡，謝謝大家。
分享嘉賓：侯容 知乎
編輯整理：李挺 上海琢學
出品平臺：DataFunTalk
01/分享嘉賓
侯容｜知乎
使用者理解&資料賦能研發 Leader
畢業於北京化工大學，2018 年初入職知乎，在社群業務線完成多方向的業務流程建設和架構的搭建，2021 年開始負責知乎使用者理解&資料賦能方向的研發團隊管理，主要涵蓋使用者理解和實時資料的工程和業務研發。2021 年在知乎帶領團隊完成了實時資料系統從基建到業務層從 0 到 1 的建設及重寫升級使用者理解應用，形成「資料來源於業務，資料賦能於業務」的閉環，建設了相應的基建，提升了使用者理解和實時資料的業務迭代效率，最終賦能業務拿到了不錯的業務效果。
02/關於我們
DataFun：
專注於大資料、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章800+，百萬+閱讀，14萬+精準粉絲。
