没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
用户画像作为“大数据”的核心组成部分,在众多互联网公司中一直有其独
特的地位。作为国内旅游 OTA 的领头羊,携程也有着完善的用户画像平台体系。
目前用户画像广泛用于个性化推荐,猜你喜欢等;针对旅游市场,携程更将其
应用于“房型排序”“机票排序”等诸多特色领域。
本文将从目的,架构、组成等几方面,带你了解携程在该领域的实践。
1.携程为什么做用户画像
首先,先分享一下携程用户画像的初衷。一般来说,推荐算法基于两
个原理“根据人的喜好推荐对应的产品”“推荐和目标客人特征相似客人喜好的产
品”。而这两条都离不开用户画像。
根据用户信息、订单、行为等等推测出其喜好,再针对性的给出产品
可以极大提升用户感受,能避免用户被无故打扰的不适感。同时针对不同画像
的用户提供个性化的服务也是携程用户画像的出发点之一。
2.携程用户画像的架构
携程用户画像的产品架构
如下图所示,携程用户画像的产品架构大体可以总结为:
1.注册
2.采集
3.计算
4.存储/查询
5.监控
所有的用户画像都会在”UserProfile 平台”中进行注册,由专人审核,审
核通过的画像才可以在“数据仓库”中流转;之后会通过用户信息、订单、行为
等等进行信息采集,采集的目标是明确的、海量的、无序的。
信息收集的下一步是画像的计算,携程有专人制定计算公式、算法、
模型,而计算分为批量(非实时)和流式(实时)两种,经过严密的计算,画
像进入“画像仓库”中;而根据不同的使用场景,我们又会提供实时和批量两种
查询 API 供各调用方使用,实时的服务侧重高可用,批量服务侧重高吞吐;最
后所有的画像都在监控平台中得到有效的监控和评估,保证画像的准确性。
携程用户画像的技术架构
携程发展到今天规模,更强调松耦合、高内聚,实行 BU 化的管理模式。
而用户画像是一种跨 BU 的模型,故从技术架构层面,携程用户画像体系如下
图所示。
各 BU 都可以贡献有价值的画像,而基础部门也会根据 BU 的需要不断制
作新的画像。画像经过开源且经我们二次开发的 DataX 和 Storm 进入携程跨
BU 的 UserProfile 数据仓库。在仓库之上,我们会有 Redis 缓存层以保证数据
的高可用,同时有实时和借助 elasticsearch 两种方式的 API,供调用方使用。
该架构有如下关键点:
1.有异步和实时两种通道满足不同场景、不同画像的需要,事实类画
像一般采用实时计算方式,而复合类画像一般采用异步方式。
2.携程强调专人专用, 每个人做自己最适合的事。故整个是多个团队
合作完成的,其中包括但不限于各 BU 的开发、BI,基础的开发、BI 等。
3.所有 API 都是可降级、可熔断的,可以根据需要切数据流量。
4.由于用户画像极为敏感,出于数据安全的考虑,我们查询服务有严
格的权限控制方案,所有信息必须经过授权才可以访问。
5.出于对用户画像准确性负责的目的,我们有专门的 UserProfile 数据
可视化平台监控数据的一致性、可用性、正确性。
上述是用户画像的总体描述,下面我将详细分享各个细节。
携程用户画像的组成
信息采集
基础信息的采集是数据流转的开始,我们会收集 UserInfo(比如用户
个人信息、用户出行人信息、用户积分信息)、UBT(用户在 APP、网站、合
作站点的行为信息)、用户订单信息、爬虫信息、手机 APP 信息等。而上述每
个基础信息的采集又是一个专门领域。比如下图展示了用户订单信息采集流程。
画像计算
基础信息是海量的、无序的,不经加工没有太大的价值。故用户画像的
计算是数据流转的关键所在。我们的 BI 团队会制定严密的公式和模型,根据场
景的需要,制定规则和参数,对采集信息做异步计算。这样的计算由于耗时较
长,一般我们会采用 T+N 的方式异步更新,根据画像的不同,数据新鲜度的要
求亦不同。动态和组合标签大多采用异步方式计算更新。Hive、DataX 等开源
工具被使用在这个步骤中。
而有些画像是事实或对新鲜度要求比较高的,故我们会采用的流式方
案去实时更新计算。比如下图,UBT(用户行为数据)使用消息通道 Hermes
对接 Kafka+Storm 为 UserProfile 的实时计算提供了有力的支持。
信息存储
剩余32页未读,继续阅读
资源评论
007pro
- 粉丝: 15
- 资源: 11
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功