導讀：隨著大資料的快速發展，大資料應用已經融入各行各業。在很多場景中得到了商業化實踐。今天和大家分享下58同城商業站內DMP平臺架構與實踐，介紹如何在大資料量的情況下進行實時資料探勘併為線上廣告系統應用提供物料等資料支援。
主要內容包括：
- DMP 平臺簡介
- DMP架構及實現
- DMP應用
- 未來規劃
01
DMP平臺簡介
DMP 其實是一個數據管理平臺，是把分散的多方資料進行整合納入統一的技術平臺，並對這些資料進行標準化和細分，讓使用者可以把這些細分結果推向現有的互動營銷環境裡的平臺。
業界代表性的產品有騰訊廣點通和阿里達摩盤。它們主要提供建立細分人群、分析使用者畫像、種子使用者群體拓展（lookalike）、再營銷、分析投放管理、流量採買和第三方資料接入等功能。
下面和大家分享下58商業對DMP平臺的需求。
1. 業務需求
58商業產品技術部主要負責整個58的商業變現，最核心的OKR其實是如何將有效的流量進行變現。
我們需要把點選廣告的使用者特徵、上下文特徵和我們自己的廣告庫特徵進行加工整合後，再提供給線上廣告推薦的觸發、排序和裝飾。其次還要支撐其他部門的商業營銷、商家平臺以及微聊系統。
2. 特徵需求
特徵需求主要是特徵的挖掘和特徵的使用。
特徵挖掘需滿足：
- 快速、便捷定義特徵挖掘邏輯
- 一定時限內的歷史特徵+ 實時特徵(s 級)融合
- 快速上線生效
- 實驗迭代
特徵使用應提供如下功能：
- 豐富的特徵資料、有序的特徵體系、統一的元資料管理體系
- 便捷、穩定的線上服務
- 便捷、可靠的離線特徵倉庫
- 實驗迭代
02
DMP平臺架構
1. 商業DMP定位
首先，結合我們的需求，介紹下商業DMP定位，這裡介紹的商業DMP主要是指我們商業站內的，主要提供特徵挖掘和特徵資料服務的能力。
對於開發者，特徵挖掘平臺提供了簡潔、易用的開發SDK，遮蔽實時計算、批次計算、海量儲存、高併發服務、各底層分散式系統部署等細節。提供TB級別（N天）行為資料探勘和秒級別延時實時特徵挖掘，支援特徵挖掘實驗、水平擴充套件。
對於特徵資料服務平臺，提供豐富的特徵資料（TB級別）和元資料管理，能夠提供線上和離線特徵資料服務。對於線上，提供穩定的線上特徵資料服務，支撐線上推薦系統；對於離線，提供靈活的多維查詢，支援按人群特徵進行營銷活動。
2. 平臺業務架構
從資料的產生到標籤的加工再到業務應用，在這完整的資料流中，DMP平臺其實是起著承上啟下的作用，可以把它看做是一個數據工廠，對資料特徵進行統一、清洗、加工、轉化、提煉，再對外提供相應的資料服務。DMP平臺主要包括特徵挖掘平臺、dmp service、標籤元資料管理、監控等模組。
3. 平臺邏輯架構
平臺邏輯架構主要分為資料層、儲存層、計算層、服務層和監控層。
資料層：提供Kafka、ESB、HDFS、Api等多種異構資料來源，透過importer層將資料進行統一的清洗轉化，對下形成統一的資料來源，從而遮蔽底層的異構資料來源。
儲存層：我們實現了儲存介面、序列化模組、壓縮模組。由於線上推薦特徵挖掘提供基於KV鍵值儲存就能滿足需求，故底層儲存主要提供Redis和自研的wtable等。
計算層：提供了storm、spark、sparkstreaming、flink等多種計算引擎。在operator模組提供讓特徵挖掘使用者自己實現對應的SDK即可，簡便高效，同時對於使用者來說遮蔽掉了異構計算。
服務層：主要提供IDMapping、路由、實驗、process四個模組。IDMapping主要是為了打通資料孤島；路由模組主要是解決流量分發問題；實驗模組主要是進行分流實驗；process模組主要是提供業務解耦能力。
監控層：對服務、任務、儲存等進行監控，對多環節快速發現定位並解決問題。
4. 平臺功能
平臺目前提供行為引入、特徵儲存、特徵挖掘和特徵服務四大模組。
行為引入：提供ID-Mapping服務、實驗分流、統一Behavior結構，支援Behavior結構實時離線複用和相容，支援實時批次匯出Behavior資料。
特徵挖掘：支援實時挖掘和批次挖掘，並支援線上加工，統一特徵和屬性結構，為解析使用者行為提供相應的SDK。
特徵儲存：支援隨機和批次的高併發讀寫，提供TB級別的特徵儲存能力，同時提供實時特徵和歷史特徵的融合，支援多版本的特徵迭代。
特徵服務：對外提供統一的訪問介面，許可權控制，元資料管理和實驗分流。
5. 元資料管理
商業DMP標籤體系主要分為C端標籤和B端標籤兩類。C端主要是流量相關的標籤，可以給予人口屬性、行業標籤、地理位置等做進一步細分。B端主要是廣告主相關的標籤。
6. 特徵挖掘流程
特徵挖掘主要分實時特徵挖掘和離線特徵挖掘兩大塊。我們提供了Importer（對資料來源的解析）和Operator SDK（融合資料探勘的介面），可以對使用者提供SDK開放介面，達到一處編寫，多處執行的能力，並且支援外掛化部署，利於服務解耦和維護。
- 離線特徵挖掘的場景是一般基於單日行為的批次挖掘，再向前回溯n日的特徵，然後進行多日特徵合併。首次進行全量匯入特徵庫，後續每日做增量特徵匯入，是通過當日全量與昨日全量做特徵diff，然後得到增量特徵在匯入特徵庫。
- 實時特徵挖掘是透過Importer和解析使用者挖掘的SDK在寫入實時特徵庫，最後在DMP服務會對實時特徵庫和離線特徵庫進行合併，再對外提供服務。
7. 計算框架
計算框架大致分NODE、Module和Operator三部分：
- NODE：對使用者遮蔽了異構資料和異構計算。提供Spark、Hive、SparkStreaming和Flink計算引擎，底層資料來源支援HDFS、Kafka和ESB，透過behavior資料結構，對58商業流量資料抽象定義，從而相容多種異構資料來源，提供統一的資料結構。
- Module：Topo主要是對Operator解析和呼叫。
- Operator：對使用者暴露了behavior2Feature、mergeFeature和 featue2Attribue三個介面。behavior2Feature是對schema資料轉換成使用者需要的標準化的特徵；mergeFeature提供使用者自定義的特徵融合功能；featue2Attribue是對外提供特徵查詢的介面服務。
8. 實時計算
① 遇到的問題
- 穩定性問題：由於流量洪峰導致的任務處理資料量變大、記憶體溢位、資料積壓等問題；由於任務頻繁提交到故障機器導致任務失敗問題；由於部分任務執行耗時導致整個任務執行時間過長，從而產生資料積壓的問題；由於網路shuffle耗時導致任務效能變差；由於Spark和Flink自身的監控不能滿足業務需要，導致不能及時發現異常問題等。
- Flink框架問題：分散式快取不生效、Taskmanager超時失敗、Flink框架空指標異常等。
- 資料流傳輸問題：flume採集資料傳輸延遲，導致使用者行為實時轉化不及時。
- 監控問題：由於監控時間粒度太小導致監控覆蓋不全。
② 解決方案
- 穩定性：利用Spark和Flink自帶的反壓機制解決流量洪峰問題；對於機器故障問題採用黑名單機制和推測執行機制來解決；透過定製化任務監控來及時發問題。
- 容錯性：主要採用Spark和Flink自帶的checkpoint機制。
- 高效能：運算元最佳化、shuffle最佳化、引數調優等。
- Flink問題：向Flink社群反饋問題,藉助HDFS我們實現了分散式快取功能。
- 資料傳輸：藉助公司力量，推動Flume傳輸架構最佳化升級。
- 監控：開發自定義監控系統，並結合Flink，Spark自帶監控。
③ 定製化監控
我們的監控平臺主要結合Flink，Spark自帶監控進行一個補充，主要針對task執行，重試次數和失敗次數的監控和一些其他維度的監控，透過告警層，配置告警相關規則，將監控的異常資訊及時通知告警人並處理。
9. 儲存系統選型
針對上述對比結合58內部以及業界常見KV儲存查詢，我們選擇Redis和wtable這兩種KV儲存系統。針對要求高效能高併發讀寫的場景我們選用redis，針對併發讀效能要求高，併發寫效能相對較低的場景則選用wtable。
10. 儲存最佳化
① 讀寫合併最佳化
由於實時離線特徵資料量太大，資料庫的讀寫次數幾乎等於流量日誌的數量。我們做了如下最佳化：
- 離線特徵先在記憶體中合併單個使用者當日的所有特徵，再合併所有RDD中包含該使用者特徵的資料，最後再把生成的特徵資料同特徵庫中的歷史特徵資料進行合併（從n到1）；
- 實時特徵在寫入特徵庫之前先進行視窗內聚合，透過犧牲時效性從而減輕特徵庫的讀寫壓力；
- 將IDMap與離線特徵加入本地快取中。
最佳化結果：超時機率從之前的3%左右降到了0.1%以下。
② 離線實時特徵拆庫
由於之前離線實時特徵庫為同一個庫，大量離線寫入會對線上讀請求有影響，造成服務超時及離線資料匯入時間較長。針對此現象我們將離線特徵單獨儲存，並將資料匯入方式從單條匯入修改為bulkload匯入的方式。
最佳化結果：離線資料匯入由3小時降至0.5小時，同時DMP對外查詢服務保證在50ms之內。
③ 耗時最佳化
遇到問題：
- 獲取單個使用者請求時需要經過IDMap查詢、兩次實時特徵查詢和一次離線特徵查詢，總共四次服務呼叫，序列執行很容易超時；
- 入庫的時候都做了壓縮和序列化，如何提高壓縮耗時與壓縮比；
- DMP平臺採用Java服務懶載入方式從而導致服務啟動耗時。
最佳化方法：
- 對於沒有依賴關係的服務呼叫採用並行處理；
- IDMapping增加快取，保證服務的響應時間；
- 壓縮加入壓縮頭，支援多種序列化與壓縮方式，保留最佳化空間；
- 修改懶載入方式
最佳化結果：服務呼叫耗時從原來的各服務呼叫時間之和變成各服務呼叫耗時最大值。
11. DMP實驗平臺
如圖所示為DMP分流實驗架構參照的是google分層實驗框架，整個流程大致如下：
- DMP流量經過IDM模組後根據condition條件進入相應的block。
- DMP流量按照相應的分流方式進行分流。
- 根據分流實驗標記進行不同的實驗邏輯處理
- Sink實驗標記回傳方便業務線做相關的資料統計分析
03
DMP應用
1. 線上推薦系統二手車Feed流
Feed流是實時的個性化推薦，從而實現使用者體驗和商業價值的提升。這就要求我們能快速捕捉到使用者的行為變化並提取使用者特徵。DMP需要能對使用者行為資料的採集清洗轉換到特徵加工等達到秒級加工能力，從而保障Feed流系統的實時性。
2. 人群服務
人群服務主要是給營銷產品提供人群圈選的功能，用來做智慧營銷的場景，主要包括建立人群包和透過人群來查詢相關的使用者即基於多個維度的標籤屬性篩選分析使用者特點。目前建立人群包主要支援標籤組合和自定義上傳兩種模式。
建立人群的具體流程如下：
建立完人群包之後，即可根據建立的人群包進行相關的人群圈選功能。具體流程如下：
在整個查詢過程中，透過人群包進行人群圈選直接查詢es的效能會有一定延遲，為此我們進行了架構的最佳化和調整：
- 對於t+1之前已經建立的人群包，每天離線資料匯入的時候會將相關人群包對於的圈選人群直接圈選出來持久化到redis中，從而滿足線上場景的實時查詢。
- 對於新建立的人群包，按照上述流程進行查詢，同時將查詢結果快取到redis中，方便後續的重複查詢。
04
未來規劃
未來我們希望可以藉助商業DMP的能力，進一步為公司賦能提效：
1. 構建OneService
透過服務升級，能夠對外提供統一的使用者畫像服務、標籤管理、統一開放API、人群管理。
2. 引入Doris
引入Doris計算引擎，支援人群包更實時和靈活的多維度分析功能。
今天的分享就到這裡，謝謝大家。
在文末分享、點贊、在看，給個三連擊唄~~
分享嘉賓：
林鵬
58同城 | 大資料架構師
58同城，商業產品技術部大資料架構師，2019年加入58同城。主要負責58同城站內DMP平臺和客戶資料建設的專案管理和研發工作，對實時計算、OLAP分析有一定研究，曾先後在百度、去哪、小米任職。
分享嘉賓：林鵬 58同城 大資料架構師
編輯整理：張磊
出品平臺：DataFunTalk
