| 编辑推荐: |
本文将主要围绕画像数据流转结构设计与画像查询服务架构设计两个方面探讨用户画像在携程商旅的实践，了解更多请阅读下文。
本文来自于携程技术
，由火龙果软件Alice编辑、推荐。 |
|
一、用户画像
用户画像这一概念最早源于交互设计领域，由交互设计之父Alan Cooper提出。其指出用户画像是真实用户的虚拟代表，是建立在真实数据之上的目标用户模型。具体而言，在互联网用户分析领域，用户画像可以简单描述为用户信息标签化，即通过收集并分析用户的社会属性、生活习惯、消费偏好等各维度的数据，从而抽象出用户的全方位多视角的特征全貌，最终就是让用户画像比用户更了解自己。
用户画像作为让大数据“走出”数据仓库的典型落地应用之一，是企业精细化运营和精准营销服务的基础服务设施。
图片为某公司用户画像 dashboard 示例，涉及数据为脱敏数据
二、携程商旅用户画像标签体系
深刻理解 To B 和 To C 的场景差异有助于指导后期标签建模。
To B 场景下用户画像是由公司（corp id）和用户（user id）共同构成的画像，主要包括公司维度的画像，用户维度的画像。To C 场景下，一个 user id 就是一个用户，用户与用户之间大部分场景下的行为是相对独立的。To B 场景下，一个corp id 对应一个公司，一个corp id 包含多个 user id，user 与 user 之间的行为信息很多时候是可以互补的。
具体来说，主要有如下区别：
- To B 场景下用户的需求更加明确。因为是商务出行，去哪，如何去，住哪里等，没有太多犹豫空间，买完即走。和C端看了又看，逛了再逛有明显的区别。
- To B 场景下用户消费模式更加稳定。由于一家公司的业务不会在短期内发生剧变，所以消费模式也更加稳定。比如在解决机酒交叉推荐中的冷启动问题，corp id 下的新用户在搜索机票的时候，这个 corp id 下其他员工在同一目的地的经常预定的酒店信息是可以互补的。To B 场景下去了还会再去，并且一直稳定在一定出行范围，C端去了又去的概率显著降低。
- To B 场景下用户个性化意愿减弱。由于商务出行属性以及公司差旅标准所限，用户的消费行为更多是公司政策的体现，而不是依用户个性化意愿所作出的决策。如同一公司下用户A和用户B即使在基本人口属性、个人消费能力上有所差异，但如果一同出差，用户A与用户B的差旅标准是一样的，那么他们的选择空间也就一样。
- To C 场景下通常一个自然人对应多个 user id，而在 To B 场景下，通常一个user id 对应一家 corp id。为了最大化利用数据，To C 场景下一般需要用自然人模型来唯一标识 user id 。
以携程商旅用户画像（公司维度）为例，根据业务需求主要分为五大类标签，分别为基本属性、客户关系管理类标签、消费偏好类标签、风控类标签、实时类标签，下面列举一些常用标签。
1）基本属性
主要包括：公司ID、公司名称、所在城市、所属行业、注册时间、注册渠道、公司规模、公司类型等。
2）CRM类标签
生命周期：活跃时长、沉默时长、是否新用户等。
业绩服务：退票率、投诉量、订单量、成交额等。
用户价值：会员等级、消费频率等。
3）偏好类标签
产品偏好：机票酒店占比等。
出行偏好：热门出发城市、到达城市、酒店星级偏好、飞机舱位偏好等。
增值服务：保险偏好等。
4）实时类 标签
过去十分钟查询预订占比、过去十分钟页面浏览量等。
5）风控类 标签
账户逾期金额、酒店入住城市离散度、历史逾期次数、信用评分等。
三、携程商旅用户画像数据流转结构
用户画像数据的生产与消费通常涉及数据收集、数据清洗、特征生成、标签建模、标签应用等多个环节。整个工程实现方案中离线计算主要涉及Spark、Hive等框架 ，实时计算采用的是Flink、Kafka等框架，数据存储主要涉及Hive、Redis、MongoDB。下图为携程商旅用户画像的数据流转整体结构图。
1）数据收集
携程商旅用户画像数据主要来源于离线数据和线上实时埋点数据。离线数据主要存储在Hive数据仓库，包括业务数据、日志数据、其他BU共享的三方数据。线上实时埋点数据主要推送到Kafka集群，如用户点击数据、浏览数据等。
2）特征计算
特征计算也就是将数据仓库的数据清洗转换成特征的过程，主要为标签建模服务，特征的质量直接决定标签建模的上限，所以这一步至关重要。
数据清洗转换主要包括异常值处理、数据平滑归一、数据聚合统计、缺失值处理、数据校验等。离线数据处理的主要借助 Spark SQL 和 Spark UDF 完成数据清洗转换，在线数据处理主要借助 Flink 计算框架完成。
最后清洗转换后的数据库流入到特征库，作为后续标签建模的特征使用。
3）标签建模
标签建模主要采用了三种方法：
这类标签具有强业务属性，需要运营人员或特定应用场景的需求方根据专业经验来定义，不同场景下对同一个标签的定义可能不同。如在客户管理场景下，“最近一次消费日期距离当前日期>30天”则定义为沉默用户，“最近一次消费日期距离当前日期>90天”则定义为流失用户。而在个性化优惠券发放场景下（精细化营销）对沉默用户发放优惠券拉动消费，那么“最近一次消费日期距离当前日期>14天”则定义为沉默用户。
这类标签具有时间窗口周期，根据一定的统计学原理来对窗口周期内的数据建模。
离线数据周期通常以过去一周、一个月、一年为窗口大小，如用RFM模型对用户过去半年消费行为数据建模，对不同群分客户实时不同的优惠策略。再如风控场景下计算窗口周期内用户出差城市的离散度，商务出行场景下，高频出发地和目的地一般稳定在一个空间范围内，如果离散度高则有一定的非商务出行风险。
实时数据往往以一次会话、过去15分钟、一小时等为窗口大小，如"过去15分钟查订比“这个统计标签，也属于统计类标签，查订比太低有一定的爬虫风险。
这类标签需要通过机器学习算法进行建模挖掘产生，如对用户的某些属性或者行为进行预测判断。如根据历史消费行为和账户逾期情况进行信用等级判定，就属于机器学习领域中的分类问题。再如对公司未来三个月消费金额进行预测，就属于机器学习领域的回归问题。此类标签的模型训练通常需要用到各种机器学习、深度学习框架，如Spark MLlib、Scikit-learn、Pytorch、TensorFlow、XGBoost等框架。
4）标签接口
离线标签数据主要存储在 Hive 里，生产数据主要存储在 MongoDB 和 Redis 中以提高接口的响应速度和服务的可用性，具体架构参考下文。
5）数据监控
整个数据的流程监控调度主要借助于 Zeus 数据管理平台和 Grafan 监控系统完成，数据监控贯穿数据生产消费的整个生命周期，监控报警方式有邮件通知、IM通知等手段。
具体来说主要有以下四个方面的监控：
- 在数据收集阶段，需要监控上游数据源是否成功生产、数据量大小波动是否异常、各个任务之间依赖调度是否失败，失败任务是否需要重试。
- 在特征计算阶段，需要监控各数值特征的统计值（最大值、最小值、均值、标准差等）是否在合理区间内、类别特征是否不在枚举范围内、特征重要性（方差、卡方、信息增益）监控。如一个指标在前三个月属于重要性的指标，随着业务变化，该指标的重要性已经降低了，以此来指导模型迭代（特征选择、超参数调整）。
- 标签建模阶段，需要监控机器学习模型的准确率、召回率、AUC等模型指标，以保证模型的泛化能力。
- 标签接口服务层，需要监控接口的响应时长、健康状态等。
四、携程商旅用户画像查询服务架构
用户画像查询服务作为基础数据服务，由于被业务运营、风控、算法等多个需求方依赖调用，对响应时间和服务可用性都提出了非常高的要求。
4.1 Lambda三层架构设计
画像标签数据来源主要有批计算生产的离线历史数据和流计算产生的实时数据，如果只利用历史数据无法满足实时性的需求，如果只利用实时数据则很难充分利用历史数据的完整价值，如何对历史数据和实时进行融合，既能保证准确性又能保证实时性。
针对这个问题，我们参考了 Storm 的作者 Nathan Marz 提出的 Lambda 三层架构，包括批处理层 （Batch Layer） 、流数据层（Speed Laye）、服务层（Serving Layer）。
Lambda 架构的设计是为了在处理大规模数据时，同时发挥流处理和批处理的优势。通过批处理提供全面、准确的数据，通过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。这三层架构，应该可以覆盖绝大多数的大数据团队架构的场景。
- Batch Layer 批处理层 ，对历史数据进行批计算，数据可以T+1生产。由于批处理是基于完整的历史数据集，对用户画像的刻画更加完备准确，所以准确性是可以保证的。批处理无法满足实时性要求，对最近那一次运行之后产生的数据就无能为力。
- Speed Layer 流处理层 ，处理实时的增量数据，这一层的优点在于低延迟，弥补 Batch Layer 由于高延迟导致的数据空白。
- Serving Layer 服务层 ，合并批处理层和流处理层的数据，对外提供最终的输出结果。
4.2 组件选择
Lambda三层架构只是一个思想，具体的实施还是要根据业务进行灵活变通，不能生搬硬套，我们可以根据自己的应用场景，自由选择技术框架组件来实现每一层的功能。以携程商旅画像查询服务为例，下图为Lambda三层架构的具体实现。
批处理层我们主要选择了 Spark、Hive 进行离线数据处理，得到批数据视图，流处理层我们选用了 Flink 进行实时计算，得到实时数据视图，分别存储在 MongoDB 和 Redis 数据库中。其中对于 MongoDB 中的热数据我们也增加了持久化缓存层，以进一步提高数据查询性能，MongoDB 对于冷数据也具备高效的读写性能。
五、小结
用户画像标签体系的构建是一项系统工程，踩过很多的坑。许多标签和业务强相关，研发同学需要深刻理解业务场景才能做好画像，此外为保障服务的可用性，双IDC部署，服务熔断、服务降级都是必须要做的。
目前我们正在推进C端和B端的用户数据共享，用户在携程商旅属于B端用户，在携程C端有自己的因私消费行为，两端数据的打通可以解决某些场景下的冷启动问题，这个问题的解决主要依赖自然人模型。
用户画像在B端应用场景主要有反弊行为识别、产品个性化推荐排序、客户精细化运营管理等，应用的上线可以检验画像标签是否合理完善，但目前我们整个标签体系没有实现闭环，这是后期需要考虑解决的问题。
|
