攜程如何從海量數(shù)據(jù)中構(gòu)建精準(zhǔn)用戶畫像扬霜？ - 51CTO.COM http://bigdata.51cto.com/art/201702/530372.htm?utm_source=tuicool&utm_medium=referral
- Github項目: awesome-coder-resources：編程/學(xué)習(xí)/閱讀資源（開源項目,面試題,網(wǎng)站,書,博客,教程等等）......【歡迎Star,歡迎圍觀】......
//畫像倉庫（Mis）
畫像進入“畫像倉庫”中
如上圖所示粘招，用戶畫像的注冊在一個典型的Mis系統(tǒng)中完成，UserProfile數(shù)據(jù)的提供方在這里申請栅贴，由專人審核斟湃。申請時，必須填寫畫像的含義檐薯、計算方式凝赛、可能的值等。
//查詢（elasticsearch）
由于用戶畫像的的使用場景非常多坛缕、調(diào)用量也異常龐大墓猎，這就要求用戶畫像的查詢服務(wù)一定要做到高可用。
大部分場景都是通過單個用戶獲取用戶畫像赚楚，但部分營銷場景則需要滿足特定畫像的用戶群體毙沾，比如獲取年齡大于30歲、消費能力強宠页、有親子偏好的女性左胞。這種情況下會返回大量用戶，此時就需要借助批量查詢工具勇皇。經(jīng)過多次技術(shù)選型罩句，我們決定采用elasticsearch作為批查詢的平臺，封裝成API后很好的支持上述場景敛摘。
作為國內(nèi)旅游OTA的領(lǐng)頭羊门烂，攜程也有著完善的用戶畫像平臺體系。目前用戶畫像廣泛用于個性化推薦兄淫，猜你喜歡等;針對旅游市場屯远，攜程更將其應(yīng)用于“房型排序”“機票排序”“客服投訴”等諸多特色領(lǐng)域。本文將從目的捕虽，架構(gòu)慨丐、組成等幾方面，帶你了解攜程在該領(lǐng)域的實踐泄私。
作者：周源來源：大數(shù)據(jù)雜談|2017-02-09 11:05
移動端
收藏
分享
用戶畫像作為“大數(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é)為
注冊
采集
計算
存儲/查詢
監(jiān)控
所有的用戶畫像都會在”UserProfile平臺”中進行注冊巫湘，由專人審核装悲，審核通過的畫像才可以在“數(shù)據(jù)倉庫”中流轉(zhuǎn);之后會通過用戶信息、訂單尚氛、行為等等進行信息采集诀诊，采集的目標(biāo)是明確的、海量的阅嘶、無序的属瓣。
信息收集的下一步是畫像的計算，攜程有專人制定計算公式讯柔、算法抡蛙、模型，而計算分為批量(非實時)和流式(實時)兩種魂迄，經(jīng)過嚴(yá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都可以貢獻有價值的畫像，而基礎(chǔ)部門也會根據(jù)BU的需要不斷制作新的畫像厢呵。畫像經(jīng)過開源且經(jīng)我們二次開發(fā)的DataX和Storm進入攜程跨BU的UserProfile數(shù)據(jù)倉庫窝撵。在倉庫之上，我們會有Redis緩存層以保證數(shù)據(jù)的高可用襟铭，同時有實時和借助elasticsearch兩種方式的API碌奉，供調(diào)用方使用。
該架構(gòu)有如下關(guān)鍵點：
1.有異步和實時兩種通道滿足不同場景寒砖、不同畫像的需要赐劣，事實類畫像一般采用實時計算方式，而復(fù)合類畫像一般采用異步方式哩都。
2.攜程強調(diào)專人專用魁兼，每個人做自己最適合的事。故整個UserProfile是多個團隊合作完成的漠嵌，其中包括但不限于各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團隊會制定嚴(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ù)被必然的引入進來晶衷。
攜程的用戶畫像倉庫一共有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)確性刁笙。比如就用戶消費能力這個畫像，我們從用戶等級、用戶酒店星級疲吸、用戶機票兩艙等多個維度進行驗證和斧正座每。同時我們還要監(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ù)被引入到我們用戶畫像中口四，希望我的分享對你有所幫助孵运。
作者介紹
周源，攜程技術(shù)中心基礎(chǔ)業(yè)務(wù)研發(fā)部高級研發(fā)經(jīng)理蔓彩，從事軟件開發(fā)10余年治笨。2012年加入攜程，先后參與支付赤嚼、營銷旷赖、客服、用戶中心的設(shè)計和研發(fā)更卒。
