1。 背景

如何更好的瞭解使用者真實需求，為使用者提供差異化的服務，實現使用者的精細化運營，提高使用者留存和後續轉化，這都是DMP要來解決的問題。

DMP透過收集使用者各種資料，結合演算法的能力給使用者打上不同的興趣標籤，基於使用者興趣可以實現個性化的推薦、搜尋、內容導購等服務，直擊使用者真實訴求；同時可以基於標籤來組合人群做廣告和Push訊息精準投放。

貝殼於2018年5月份開始搭建自己的DMP平臺，下面將從貝殼DMP平臺的整體架構設計、搭建中遇到的挑戰、以及取得的效果等方面展開介紹。

2。 挑戰

如何做使用者歸一，唯一標示一個使用者

海量使用者行為資料如何保證資料及時產出

如何實現秒級的人群預估和分鐘級的複雜人群計算

3。 實現

3。1 整體架構

3。2 資料收集層

該部分主要是收集使用者線上、線下各種使用者行為資料，其中比較複雜的是線上行為資料的收集。如果沒有公司統一的埋點系統，DMP將無從做起。

在2018年初，公司推行了統一的埋點規範，推出了羅盤這一公司級的埋點規範管理和資料分析平臺，為資料收集打下非常好的資料基礎。有興趣的同學可以參考公共號中另外一篇文章［羅盤-貝殼流量分析平臺］。

3。3 資料加工處理層

在資料層首先需要建立主題寬表，將所有資料打平後方便後續資料處理。

在構建主題寬表中首先要解決的就是使用者碎片化資料如何歸一，比如一個使用者可能會登入多個手機，或者同時訪問鏈家和貝殼的APP，既有線上瀏覽行為又有線下帶看資料，如何精準的識別同一個使用者，打通線上線下資料是做好畫像的關鍵。

PC和M站只有在登入下才能精準的識別使用者，而對於APP使用者，可以利用手機的IMEI或者IDFA、APP自己生成的系列號、以及登入的UCID來精準的識別一個使用者。

比如使用者同時登入了兩個APP，可以根據IMEI或者IDFA來識別出。但是IMEI在Android高版本中需要使用者授權，IDFA使用者可以關閉，都有可能獲取不到，這種情況下可以使用APP自己生成的序列號來識別使用者。具體的實現邏輯如下圖所示：

在識別使用者後，會將使用者線上和線下的各種行為資料打通，並基於這些資料做各種特徵資料的抽取，最終產出三種類型的標籤資料：

透過簡單的資料統計分析產出了基礎標籤和行為標籤，比如性別、年齡、常住城市、訪問次數、關注次數、帶看次數等事實標籤

透過使用者線上線下的不同行為次數、行為權重、與時間衰減的乘積，來計算使用者在房子各個維度上的得分。由此可以得到使用者在房子上的各種偏好標籤，比如喜歡回龍觀、400W的兩居室

透過分類演算法產出業務線偏好、使用者生命週期、流失預估、商機預估、委託預估等標籤；透過聚類演算法產出工作地、居住地等標籤（挖掘類和預測類的標籤實現後面會有專門的文章來介紹）

畫像目前使用的是使用者線上180天的資料來計算各種標籤，每天參與計算的資料在百億級別，同時還要保證資料在10點產出。在如何保證資料按時產出方面，我們做了很多最佳化：

資料列裁剪，只獲取畫像感興趣的欄位

資料預聚合，使用者每天的行為資料有上億條，但是經過適當的預聚合可以將資料量減少到原來的五分之一到十分之一，同時不影響後續的各種統計分析

增量計算，每天將昨天的資料去掉最早一天的資料，再融合最新一天的資料

使用group by和count替換耗時的count distinct操作

演算法模型線上化，挖據演算法離線計算標籤的成本非常高，經常會到下午才產出資料，將模型線上化後，離線只用訓練模型，透過線上API服務來載入模型和使用者各種特徵資料實時給出挖據的結果

3。4 實時畫像

貝殼每天有10%以上的新使用者，而且使用者的需求隨著時間也會有一定的變化，如何根據使用者行為快速體現出使用者需求的變化，及時給使用者提供差異性的服務，這是我們做實時畫像的初衷。

下面是實時畫像的架構設計：

透過spark streaming實時消費使用者線上行為資料，並將行為資料儲存在HBase中；

HBase採用寬表的設計思想，將一個使用者的各種行為和偏好資料儲存在列中；

透過HBase的increment操作來原子性的更新行為次數，同時大量使用HBase的批次操作來加速每個批次的處理速度；

目前可以在秒級計算出使用者實時偏好資料，並將偏好資料儲存到Redis對外提供API服務。

3。5 應用資料儲存層

倉庫中的資料無法直接面嚮應用使用，需要一個應用層的儲存系統來為應用層服務。基於不同的應用，DMP使用了ClickHouse、Mongodb以及HBase作為資料儲存。具體的資料流如下：

1）Spark任務

透過Spark任務每天將Hive中的資料匯入到ClickHouse，同時利用ClickHouse的點陣圖儲存和點陣圖運算，將複雜的SQL運算轉換成位圖裡面的與或非，來實現任意拖拽標籤、秒級人群預估和分鐘級人群計算。關於透過CK點陣圖來實現圈包後面會有專門的文章來介紹。

2）對於Push訊息類的服務

需要透過介面獲取人群中的資料用於訊息傳送。由於ClickHouse定位還是OLAP，不適合大量地線上呼叫，所以需要將人群的資料匯入到Mongodb中來提供線上服務呼叫。

為最佳化分頁查詢帶來的效能問題，在匯入Mongodb時為每個版本的每條資料生成一個自增的ID，同時對這個ID建立索引，在查詢時根據頁數計算出每一頁資料的ID範圍，然後再根據索引來查詢資料，能保證千萬級的分頁查詢平均響應時間在100ms以內。

3）對於線上的個性化服務

需要實時地呼叫畫像服務來支援推薦、搜尋、首頁個性化排版等需求。這種場景需要一個支援海量資料儲存、高併發、短延遲的儲存服務。

在這種場景下，我們將Hive中的畫像資料透過BulkLoad匯入到HBase，對核心的畫像資料在HBase做了資源隔離和SSD儲存，同時將最近的畫像資料匯入Redis做熱快取。這樣就保證了畫像介面服務在每天4億的呼叫量下，平均響應時間只有5ms左右。

整個資料儲存層，我們會有一個專門的DP專案組來負責整個資料的流轉以及人群資料的計算。

3。6 應用層

1）人群圈定

根據標籤來圈定目標使用者，可以實現不同標籤間的與或非，以及人群之間的交併差運算，來實現秒級的人群預估和分鐘級的人群包資料生成。

2）人群洞察

分析目標使用者特點，快速瞭解目標使用者，該部分查詢直接透過SQL跟ClickHouse實時互動。

3）標籤管理

快速上下線標籤，管理標籤層級結構。

4）標籤集市

主要解決快速瞭解標籤體系和查詢標籤的問題。

5）人群擴充套件

採用強大lookalike演算法透過少量種子人群擴充套件海量目標使用者。

6）訊息Push

支援APP外顯Push和公眾號訊息Push，可以傳送手工Push也可以傳送基於畫像的精準導購Push，同時支援到商機的效果追蹤。

4。 效果

5。 總結

透過兩年的發展和迭代，目前貝殼DMP的平臺能力已經基本搭建完成。從站外的DSP廣告、訊息Push，到站內的推薦、搜尋、首頁個性化排版、內容導購、商機前的潛客引導、商機後的小貝助手和小貝手環、委託後的客源解讀、帶看後的裝修高潛使用者挖掘等各個場景下都得到了很好的應用，有效地幫助業務來實現了個性化服務和精細化運營。

6。 展望

1）畫像深度和覆蓋率的提升

目前畫像還是以事實類的標籤為主，後面會基於對資料的理解以及業務方的需求，透過模型來產出更多挖掘和預測類的標籤；同時透過挖據的手段推斷出沒有關鍵行為的使用者偏好。

2）效果的持續提升和最佳化

跟業務方更加緊密的結合，在使用者生命週期的各個階段來持續提升和最佳化效果。

3）平臺化的持續建設