干货 | 携程国际业务动态实时标签处理平台实践

作者简介

 

Weiyi，携程资深数据开发，关注大数据相关技术，对大数据实时计算、流批一体等方面有浓厚兴趣；

Hzhou，携程资深数据开发，关注大数据相关技术，对系统架构和实时处理等方面有浓厚兴趣；

Rongjun，携程大数据架构开发，专注离线和实时大数据产品和技术。

一、背景

在国际业务上，因为面临的市场多，产品和业务复杂多样，投放渠道多，引流费用高，因此需要对业务和产品做更精细化的管理和优化，满足市场投放和运营的需要，降低成本，提升运营效率，提升转化率。为此我们提出研发携程国际业务动态实时标签处理平台（以下简称CDP），为Trip业务增长解决“Grow Revenue”和“Reduce Costs”的问题，具体如图1-1。

图1-1 CDP所需要解决的业务问题

因为Trip数据来源比较广泛，既有自身数据也有外部数据；数据形式也非常多样化，既有结构化数据，也有半结构化和非结构化数据；数据加工形式既有离线数据处理，也有在线数据处理；如何通过系统加工这些数据形成业务系统、运营、市场需要并且可以理解的数据和标签，成为了CDP平台急需解决的业务和系统问题，简单总结下来系统主要需要解决以下四个方面的问题：

数据采集与管理：主要丰富不同的数据来源，包括三个部分。第一方数据，来自自己，UBT日志，平台数据，客服处理数据，APP安装数据。第二方数据，来自集团中的其他品牌的数据，如SC、Travix等。第三方数据，来自我们合作方的网站，比如meta投放平台等。

ID匹配：不同的数据源有不同的ID标签，比如APP端来源的数据会有一个统一的ClientID的主键，与之相关联的会有一组标签。来自不同业务系统的数据都会有对应的ID以及标签与之对应。这些标签主体的ID分别来源于不同的系统和平台。平台之间的ID有的相互之间可能没有关联关系，有的有一定的关联关系，但不是一一对应的，但是业务系统使用时往往是需要相互组合使用。因此需要有一个ID从数据采集到业务标签创建，到最终使用都能串联的一个唯一ID。这个是最大的难点。如果没有，那我们需要一个非常完整的ID Mapping，在不同的ID之间可以做转换，这样用户可以串联不同实体之间的标签。

业务标签模型：一些有场景决策使用的标签，比如市场最受欢迎产品，最热门旅游目的地等等。很多公司早期在做标签时什么都想要，铺了上百个统计类标签，然而这些标签并不能直接使用。而且将上百个标签砸向产品或运营人员的时候，因为没有重点，会一下将业务人员“砸晕”。所以能提供真正有效的标签很重要。在这个过程中对业务的理解就变得尤为重要，系统需要根据业务场景建立对应的业务标签模型。

标签的使用：和使用标签的系统做对接，比如消息系统，第三方平台，站内平台。让这些业务标签，最大化帮助业务产生业绩。其中的难点是，CDP怎么和使用它的平台去做对接。

要解决以上问题，系统必须提升数据处理能力，因为处理好的数据是需要立马运用到业务系统、EMD、PUSH等等使用场景中去，对数据处理系统的时效性、准确性、稳定性以及灵活性等提出了更高的要求。

在过去我们现有CRM数据是通过数仓T+1计算，导入到ES集群存储，前端通过传入查询条件，组装ES查询条件查询符合条件的数据。目前已经上线的标签有上百个，有查询使用的超过50%，能满足一部分对数据时效性要求不高的标签数据筛选场景的需要，比如市场活动目标用户的选择。因为是离线计算，所以数据时效性差，依赖底层离线平台的计算，依赖ES的索引，查询响应速度比较慢。

基于以上这些问题，新系统希望在数据处理过程中能提升数据处理的时效性同时满足业务灵活性的要求，对于数据处理逻辑，数据更新逻辑，可以通过系统动态配置规则的方式来消费消息数据（Kafka或者QMQ）动态更新标签，业务层只需要关心数据筛选的逻辑，以及条件查询。

二、系统设计