文 | 周源

作者介紹周源，攜程技術中心基礎業(yè)務研發(fā)部高級研發(fā)經(jīng)理，從事軟件開發(fā)10余年。2012年加入攜程，先后參與支付、營銷、客服、用戶中心的設計和研發(fā)。用戶畫像作為“大數(shù)據(jù)”的核心組成部分，在眾多互聯(lián)網(wǎng)公司中一直有其獨特的地位。

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

1.攜程為什么做用戶畫像

首先，先分享一下攜程用戶畫像的初衷。一般來說，推薦算法基于兩個原理“根據(jù)人的喜好推薦對應的產(chǎn)品”“推薦和目標客人特征相似客人喜好的產(chǎn)品”。而這兩條都離不開用戶畫像。

根據(jù)用戶信息、訂單、行為等等推測出其喜好，再針對性的給出產(chǎn)品可以極大提升用戶感受，能避免用戶被無故打擾的不適感。同時針對不同畫像的用戶提供個性化的服務也是攜程用戶畫像的出發(fā)點之一。

2.攜程用戶畫像的架構(gòu)

2.1.攜程用戶畫像的產(chǎn)品架構(gòu)

如上圖所示，攜程用戶畫像的產(chǎn)品架構(gòu)大體可以總結(jié)為:

1. 注冊
2. 采集
3. 計算
4. 存儲/查詢
5. 監(jiān)控

所有的用戶畫像都會在”UserProfile平臺”中進行注冊，由專人審核，審核通過的畫像才可以在“數(shù)據(jù)倉庫”中流轉(zhuǎn);之后會通過用戶信息、訂單、行為等等進行信息采集，采集的目標是明確的、海量的、無序的。

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

2.2.攜程用戶畫像的技術架構(gòu)

攜程發(fā)展到今天規(guī)模，更強調(diào)松耦合、高內(nèi)聚，實行BU化的管理模式。而用戶畫像是一種跨BU的模型，故從技術架構(gòu)層面，攜程用戶畫像體系如上圖所示。

各BU都可以貢獻有價值的畫像，而基礎部門也會根據(jù)BU的需要不斷制作新的畫像。畫像經(jīng)過開源且經(jīng)我們二次開發(fā)的DataX和Storm進入攜程跨BU的UserProfile數(shù)據(jù)倉庫。在倉庫之上，我們會有Redis緩存層以保證數(shù)據(jù)的高可用，同時有實時和借助elasticsearch兩種方式的API，供調(diào)用方使用。

該架構(gòu)有如下關鍵點：

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

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

3.所有API都是可降級、可熔斷的，可以根據(jù)需要切數(shù)據(jù)流量。

4.由于用戶畫像極為敏感，出于數(shù)據(jù)安全的考慮，我們查詢服務有嚴格的權限控制方案，所有信息必須經(jīng)過授權才可以訪問。

5.出于對用戶畫像準確性負責的目的，我們有專門的UserProfile數(shù)據(jù)可視化平臺監(jiān)控數(shù)據(jù)的一致性、可用性、正確性。

上述是用戶畫像的總體描述，下面我將詳細分享各個細節(jié)。

如上圖所示，用戶畫像的注冊在一個典型的Mis系統(tǒng)中完成，UserProfile數(shù)據(jù)的提供方在這里申請，由專人審核。申請時，必須填寫畫像的含義、計算方式、可能的值等。

3.攜程用戶畫像的組成

3.1.信息采集

基礎信息的采集是數(shù)據(jù)流轉(zhuǎn)的開始，我們會收集UserInfo(比如用戶個人信息、用戶出行人信息、用戶積分信息)、UBT(用戶在APP、網(wǎng)站、合作站點的行為信息)、用戶訂單信息、爬蟲信息、手機APP信息等。而上述每個基礎信息的采集又是一個專門領域。比如下圖展示了用戶訂單信息采集流程。

3.2.畫像計算

基礎信息是海量的、無序的，不經(jīng)加工沒有太大的價值。故用戶畫像的計算是數(shù)據(jù)流轉(zhuǎn)的關鍵所在。我們的BI團隊會制定嚴密的公式和模型，根據(jù)場景的需要，制定規(guī)則和參數(shù)，對采集信息做異步計算。這樣的計算由于耗時較長，一般我們會采用T+N的方式異步更新，根據(jù)畫像的不同，數(shù)據(jù)新鮮度的要求亦不同。動態(tài)和組合標簽大多采用異步方式計算更新。Hive、DataX等開源工具被使用在這個步驟中。

而有些畫像是事實或?qū)π迈r度要求比較高的，故我們會采用Kafka+Storm的流式方案去實時更新計算。比如下圖，UBT(用戶行為數(shù)據(jù))使用消息通道Hermes對接Kafka+Storm為UserProfile的實時計算提供了有力的支持。

3.3.信息存儲

用戶畫像的數(shù)據(jù)是海量的，被稱作最典型的”大數(shù)據(jù)”，故Sharding分布式存儲、分片技術、緩存技術被必然的引入進來。

攜程的用戶畫像倉庫一共有160個數(shù)據(jù)分片，分布在4個物理數(shù)據(jù)集群中，同時采用跨IDC熱備、一主多備、SSD等主流軟硬件技術，保證數(shù)據(jù)的高可用、高安全。

由于用戶畫像的的使用場景非常多、調(diào)用量也異常龐大，這就要求用戶畫像的查詢服務一定要做到高可用。故我們采用自降級、可熔斷、可切流量等方案，在倉庫前端增加緩存。如下圖所示，數(shù)據(jù)倉庫和緩存的存儲目的不同，故是異構(gòu)的。

3.4.高可用查詢

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

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

3.5.監(jiān)控和跟蹤

在數(shù)據(jù)流轉(zhuǎn)的最后，數(shù)據(jù)的準確性是衡量用戶畫像價值的關鍵指標。基于高質(zhì)量信息優(yōu)于大數(shù)量信息的基調(diào)，我們設置了多層監(jiān)控平臺。從多個維度衡量數(shù)據(jù)的準確性。比如就用戶消費能力這個畫像，我們從用戶等級、用戶酒店星級、用戶機票兩艙等多個維度進行驗證和斧正。同時我們還要監(jiān)控數(shù)據(jù)的環(huán)比和同比表現(xiàn)，出現(xiàn)較大標準差、方差波動的數(shù)據(jù)，我們會重新評估算法。

上述所有環(huán)節(jié)組成了攜程跨BU用戶畫像平臺。當然技術日新月異，我們也在不斷更新和局部創(chuàng)新，或許明年又會有很多新的技術被引入到我們用戶畫像中，希望我的分享對你有所幫助。

本文轉(zhuǎn)載自：36大數(shù)據(jù)