共计 1424 个字符，预计需要花费 4 分钟才能阅读完成。
业务挑战
在国内业务上，因为面临的市场多，产品和业务简单多样，投放渠道多，引流费用高，因而须要对业务和产品做出更精细化的治理和优化，满足市场投放和经营须要，升高整体老本，进步经营效率与转化率。为此，携程专门研发了国内业务动静实时标签化解决平台（以下简称 CDP）。
携程旅行的数据具备起源宽泛、形式多样、离线数据处理与在线数据处理兼有等特点，如何通过系统对这些数据进行采集、治理、加工，造成满足业务零碎、经营、市场需求的数据和标签。解决好的数据须要立即使用到业务零碎、EMD、PUSH 等应用场景中，对数据处理系统的时效性、准确性、稳定性以及灵活性提出了更高要求。
为了解决以上问题，CDP 零碎必须晋升数据处理能力。过来传统计划是通过数仓进行 T+1 计算，再导入 ES 集群存储，前端通过传入查问条件，组装 ES 查问条件查问符合条件的数据。携程曾经上线的标签有上百个，有查问应用的超过 50%，因为该计划是离线计算，所以数据时效性差，依赖底层离线平台计算和 ES 索引，查问响应速度较慢。
解决方案
CDP 心愿在数据处理的过程中能晋升数据处理时效性，同时满足业务灵活性的要求，对于数据处理逻辑、数据更新逻辑，能够通过零碎动静配置规定的形式来生产音讯数据（Kafka 或 QMQ）动静更新标签，业务层只需关怀数据筛选逻辑及条件查问。依据业务需要，业务数据标签筛选次要分为两大场景：
实时触发场景。依据业务须要，配置动静规定，实时订阅业务零碎的变更音讯，筛选出满足动静规定条件的数据，通过音讯的形式推送到上游业务方；
标签长久化场景。将业务零碎的实时业务变更音讯依照业务须要，加工成业务相干的特色数据，长久化存储到存储引擎。业务依据须要组装查问条件查问引擎数据，次要有 OLAP（剖析类）与 OLTP（在线查问）两大类查问。
基于以上需要，CDP 流式数据采纳类 Kappa 架构，标签长久化采纳类 Lambda 架构，如下图所示：
其中，标签长久化场景须要解决业务标签的长久化存储、更新、查问服务，携程采纳了 TiDB 来存储业务长久化的标签，并采纳实时触发场景中的动静规定配置形式生产业务零碎数据变更音讯，保障业务长久化标签的时效性，通过 TiDB 对 OLTP 和 OLAP 不同场景查问个性的反对，来满足不同业务场景中拜访业务特色数据的须要。
零碎借鉴了 Lambda 数据处理架构的思维，新增数据依据起源不同别离发送到不同的通道中，历史全量数据通过数据批处理引擎（如 Spark）转换完，批量写入到数据长久化存储引擎 TiDB 中。增量数据业务利用以音讯模式发送到 Kafka 或 QMQ 音讯队列，将数据依照标签长久化的逻辑规定解决实现，增量写入到长久化存储引擎 TiDB，以此解决数据的时效性问题。
TiDB 同时具备两大长久化存储形式，一种是行存 TiKV，能够反对 OLTP 场景，另一种是列存 TiFlash，能够反对 OLAP 场景。TiDB 数据存储外部主动解决这两个引擎的数据同步问题，客户端查问依据本身须要抉择查问形式。同时，TiDB 还能保障两种形式有着良好的隔离性，并兼顾数据强一致性，杰出地解决了 HTAP 场景的隔离性及列存同步问题。
目前，CDP 曾经与携程各个业务零碎进行深度整合买通，为国内业务增长提供业务特色标签库的数据与服务反对。
利用价值
HTAP 混合负载：完满撑持 OLTP + OLAP 混合负载，简化 IT 零碎架构，大幅晋升业务的实时查问性能。
程度弹性扩大：解脱 MySQL 分库分表难题，帮忙携程随时依据业务增长状况进行程度弹性扩大。
