文 | 周源

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.攜程用戶畫像的組成

3.1.信息采集

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

3.2.畫像計算

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

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

3.3.信息存儲

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

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

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

3.4.高可用查詢

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

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

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

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

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

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