用戶畫像作為“”的核心組成部分，在眾多互聯網公司中一直有其獨特的地位。

作為國內旅游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