攜程 | 手把手教你用大數據打造用戶畫像

用戶畫像做爲「大數據」的核心組成部分，在衆多互聯網公司中一直有其獨特的地位。

做爲國內旅遊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