使用者畫像作為“大資料”的核心組成部分，在眾多網際網路公司中一直有其獨特的地位。

作為國內旅遊OTA的領頭羊，攜程也有著完善的使用者畫像平臺體系。目前使用者畫像廣泛用於個性化推薦，猜你喜歡等;針對旅遊市場，攜程更將其應用於“房型排序”“機票排序”“客服投訴”等諸多特色領域。本文將從目的，架構、組成等幾方面，帶你瞭解攜程在該領域的實踐。

1.攜程為什麼做使用者畫像

首先，先分享一下攜程使用者畫像的初衷。一般來說，推薦演算法基於兩個原理“根據人的喜好推薦對應的產品”“推薦和目標客人特徵相似客人喜好的產品”。而這兩條都離不開使用者畫像。

根據使用者資訊、訂單、行為等等推測出其喜好，再針對性的給出產品可以極大提升使用者感受，能避免使用者被無故打擾的不適感。同時針對不同畫像的使用者提供個性化的服務也是攜程使用者畫像的出發點之一。

2.攜程使用者畫像的架構

2.1.攜程使用者畫像的產品架構

如上圖所示，攜程使用者畫像的產品架構大體可以總結為:

註冊

採集

計算

儲存/查詢

監控

所有的使用者畫像都會在”UserProfile平臺”中進行註冊，由專人稽核，稽核通過的畫像才可以在“資料倉庫”中流轉;之後會通過使用者資訊、訂單、行為等等進行資訊採集，採集的目標是明確的、海量的、無序的。

資訊收集的下一步是畫像的計算，攜程有專人制定計算公式、演算法、模型，而計算分為批量(非實時)和流式(實時)兩種，經過嚴密的計算，畫像進入“畫像倉庫”中;而根據不同的使用場景，我們又會提供實時和批量兩種查詢API供各呼叫方使用，實時的服務側重高可用，批量服務側重高吞吐;最後所有的畫像都在監控平臺中得到有效的監控和評估，保證畫像的準確性。

2.2.攜程使用者畫像的技術架構

攜程發展到今天規模，更強調鬆耦合、高內聚，實行BU化的管理模式。而使用者畫像是一種跨BU的模型，故從技術架構層面，攜程使用者畫像體系如上圖所示。

各BU都可以貢獻有價值的畫像，而基礎部門也會根據BU的需要不斷製作新的畫像。畫像經過開源且經我們二次開發的DataX和Storm進入攜程跨BU的UserProfile資料倉庫。在倉庫之上，我們會有Redis快取層以保證資料的高可用，同時有實時和藉助elasticsearch兩種方式的API，供呼叫方使用。

該架構有如下關鍵點：

1.有非同步和實時兩種通道滿足不同場景、不同畫像的需要，事實類畫像一般採用實時計算方式，而複合類畫像一般採用非同步方式。

2.攜程強調專人專用，每個人做自己最適合的事。故整個UserProfile是多個團隊合作完成的，其中包括但不限於各BU的開發、BI，基礎的開發、BI等。

3.所有API都是可降級、可熔斷的，可以根據需要切資料流量。

4.由於使用者畫像極為敏感，出於資料安全的考慮，我們查詢服務有嚴格的許可權控制方案，所有資訊必須經過授權才可以訪問。

5.出於對使用者畫像準確性負責的目的，我們有專門的UserProfile資料視覺化平臺監控資料的一致性、可用性、正確性。

上述是使用者畫像的總體描述，下面我將詳細分享各個細節。

如上圖所示，使用者畫像的註冊在一個典型的Mis系統中完成，UserProfile資料的提供方在這裡申請，由專人稽核。申請時，必須填寫畫像的含義、計算方式、可能的值等。

3.攜程使用者畫像的組成

3.1.資訊採集

基礎資訊的採集是資料流轉的開始，我們會收集UserInfo(比如使用者個人資訊、使用者出行人資訊、使用者積分資訊)、UBT(使用者在APP、網站、合作站點的行為資訊)、使用者訂單資訊、爬蟲資訊、手機APP資訊等。而上述每個基礎資訊的採集又是一個專門領域。比如下圖展示了使用者訂單資訊採集流程。

3.2.畫像計算

基礎資訊是海量的、無序的，不經加工沒有太大的價值。故使用者畫像的計算是資料流轉的關鍵所在。我們的BI團隊會制定嚴密的公式和模型，根據場景的需要，制定規則和引數，對採集資訊做非同步計算。這樣的計算由於耗時較長，一般我們會採用T+N的方式非同步更新，根據畫像的不同，資料新鮮度的要求亦不同。動態和組合標籤大多采用非同步方式計算更新。Hive、DataX等開源工具被使用在這個步驟中。

而有些畫像是事實或對新鮮度要求比較高的，故我們會採用Kafka+Storm的流式方案去實時更新計算。比如下圖，UBT(使用者行為資料)使用訊息通道Hermes對接Kafka+Storm為UserProfile的實時計算提供了有力的支援。

3.3.資訊儲存

使用者畫像的資料是海量的，被稱作最典型的”大資料”，故Sharding分散式儲存、分片技術、快取技術被必然的引入進來。

攜程的使用者畫像倉庫一共有160個數據分片，分佈在4個物理資料叢集中，同時採用跨IDC熱備、一主多備、SSD等主流軟硬體技術，保證資料的高可用、高安全。

由於使用者畫像的的使用場景非常多、呼叫量也異常龐大，這就要求使用者畫像的查詢服務一定要做到高可用。故我們採用自降級、可熔斷、可切流量等方案，在倉庫前端增加快取。如下圖所示，資料倉庫和快取的儲存目的不同，故是異構的。

3.4.高可用查詢

響應時間和TPS是衡量服務可用性的關鍵指標，攜程要求所有API響應時間低於250ms(包括網路和框架埋點消耗)，而我們使用者畫像實時服務採用自降級、可熔斷、自短路等技術，服務平均響應時間控制在8ms(包括網路和框架埋點消耗)，99%響應時間控制在11ms。

大部分場景都是通過單個使用者獲取使用者畫像，但部分營銷場景則需要滿足特定畫像的使用者群體，比如獲取年齡大於30歲、消費能力強、有親子偏好的女性。這種情況下會返回大量使用者，此時就需要藉助批量查詢工具。經過多次技術選型，我們決定採用elasticsearch作為批查詢的平臺，封裝成API後很好的支援上述場景。

3.5.監控和跟蹤

在資料流轉的最後，資料的準確性是衡量使用者畫像價值的關鍵指標。基於高質量資訊優於大數量資訊的基調，我們設定了多層監控平臺。從多個維度衡量資料的準確性。比如就使用者消費能力這個畫像，我們從使用者等級、使用者酒店星級、使用者機票兩艙等多個維度進行驗證和斧正。同時我們還要監控資料的環比和同比表現，出現較大標準差、方差波動的資料，我們會重新評估演算法。

上述所有環節組成了攜程跨BU使用者畫像平臺。當然技術日新月異，我們也在不斷更新和區域性創新，或許明年又會有很多新的技術被引入到我們使用者畫像中，希望我的分享對你有所幫助。 作者介紹周源，攜程技術中心基礎業務研發部高階研發經理，從事軟體開發10餘年。2012年加入攜程，先後參與支付、營銷、客服、使用者中心的設計和研發。

轉載自36大資料

詳情請諮詢線上客服！

客服熱線：023-66090381