本文由携程技术团队撰写，介绍了携程自研的国内业务动静实时标签解决平台。其中标签长久化的场景须要解决业务标签的长久化存储、更新、查问服务，TiDB 通过对于不同场景查问个性的反对满足了不同业务场景拜访业务特色数据的须要。
作者介绍
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）动静更新标签，业务层只须要关怀数据筛选的逻辑，以及条件查问。
二、零碎设计
基于业务须要，咱们将业务数据标签筛选的场景分为两大类：
实时触发场景
依据业务须要，配置动静规定，实时订阅业务零碎的变更音讯，筛选出满足动静规定条件的数据，通过音讯的形式推送到上游业务方。
标签长久化场景
将业务零碎的实时业务变更音讯依照业务须要加工成业务相干的特色数据长久化存储到存储引擎，业务依据须要组装查问条件查问引擎数据，次要是 OLAP（剖析类）和 OLTP（在线查问）两大类查问。
为了解决以上问题，咱们设计开发了一套“实时动静标签解决零碎”，业务方只须要依照根本算子规定配置提交工作，零碎就会主动解释执行规定，依照配置要求执行数据处理操作，目前反对的根本算子有 Stream（流式数据接入目前反对 QMQ 和 Kafka）、Priority（优先级判断）、Join、Filter（过滤）、Sink（数据输入，目前反对 TiDB、Redis、QMQ）等等，这些在整体设计外面会具体介绍，通过规定和动静计算的形式晋升数据处理和开发效率，升高开发成本。
流式数据采纳类 Kappa 架构，标签长久化采纳类 Lambda 架构，零碎架构如
图 2-1。
图 2-1 CDP 零碎架构
系统对公司内输入次要是对接站内的自经营渠道，比方音讯零碎，发送短信，邮箱，广告。站内主流程依据 CDP 的特色组装前端业务流程。
三、实时触发
针对动静触发的场景须要解决动静规定配置，规定解析，规定内动静计算节点（算子，之后都简称为算子）的生成，算子的相互依赖关系（DAG），以及数据 join 的解决。
为了解决实时流式数据处理，咱们引入了相似于 Kappa 架构的数据处理形式，做了一些调整，采纳被动 Push 形式，因为这个场景的数据次要是利用于 Push/EDM 等被动触达的场景，后果数据不须要落地，咱们间接通过 QMQ 音讯渠道推送到利用订阅的音讯队列。
图 3 -1 Kappa 数据处理架构
这样解决了音讯时效性的问题，同时也解决了规定时效性的问题，批改规定不须要重启工作即可失效。计算结果采纳被动推送的形式，省去了数据存储和查问的过程，晋升了数据的时效性，节俭了存储空间。
图 3-2 CDP 实时触发数据处理架构
规定引擎设计采纳 Json 格局传参，算子设计为两层，下层为固定业务逻辑反对的动静业务算子，次要蕴含 Stream、Priority、Join、Filter、Sink，上层为固定业务算子应用的一些根底算子，能够自由组合，以满足音讯实时处理业务逻辑解决的须要。
对于规定引擎所波及的一些基本概念形容如下：
Stream
音讯源接入，次要是 Kafka 和 QMQ，结构化 Json 数据，所有的接入音讯源的数据结构、数据类型、起源都须要录入治理，借用公司的 Kafka 和 QMQ 音讯注册管理机制，实现全流程买通。
Priority
优先级判断，比方主流程个别依照搜寻页，列表页，填写页，领取页秩序排列，因为流量是一层一层缩小，所以越到前面流量越重要，在一些业务场景中须要依据这些流量的重要水平排序，优先级判断能够满足这些业务场景的须要。
Join
Join 算子，目前只反对应用 Redis 作为 Join 右表，如果 Join 条件不满足右表数据都为 NULL，默认输入左表数据，如果须要右表数据须要指定输入的字段。
Filter
过滤算子，能够间接过滤上游数据，也能够过滤上游数据与 Redis Join 后的数据。只有通过的数据才会流入前面算子，否则该条数据处理完结。
Sink
计算结果输入，反对配置化形式，目前反对音讯队列模式（QMQ），数据库（TiDB、MySQL 等等）。
根底算子
根底的原子算子，不可再拆分，如 +、-、*、/、>、<、=、>=、<= 以及 in，not in，like，rlike，IS_NULL，IS_NOT_NULL 等。
自定义函数
反对计算过程中应用自定义函数，用户能够自定义数据处理函数并注册到生产零碎，目前反对的函数如下：
字符串函数：CONCAT、CONCAT_WS、HASH、IFNULL、IS_NOT_BLANK、IS_NOT_NULL、IS_NULL、LIKE、LOWER、UPPER、REGEXP、REPLACE、SUBSTR、UPPER、URL_EXTRACT_PARAMETER 等
工夫函数：CURRENT_TIMESTAMP、FROM_UNIXTIME
JSON 函数：JSON_EXTRACT
DAG
DAG 是一种“图”，图计算模型的利用由来已久，早在上个世纪就被利用于数据库系统（Graph databases）的实现中。任何一个图都蕴含两种根本元素：节点（Vertex）和边（Edge），节点通常用于示意实体，而边则代表实体间的关系。
因为 DAG 计算是一套非常复杂的体系，咱们次要借鉴了 Spark 的 DAG 计算思维，简化了 DAG 计算流程从而满足咱们实时计算业务场景的须要，在介绍 DAG 计算形式之前，先介绍一下 Spark 中 DAG 计算的根本思维和概念。
在 Spark 中 DAG 是分布式计算模型的形象，专业术语称之为 Lineage —— 血统，RDD 通过 dependencies 和 compute 属性形成首尾相连的计算门路。
Dependencies 分为两大类，Narrow Dependencies 和 Wide Dependencies（如图 3-3）。
Narrow Dependencies 是指父 RDD 的每一个分区最多被一个子 RDD 的分区所用，体现为一个父 RDD 的分区对应于一个子 RDD 的分区或多个父 RDD 的分区对应于一个子 RDD 的分区，也就是说一个父 RDD 的一个分区不可能对应一个子 RDD 的多个分区。
Wide Dependencies 是指子 RDD 的分区依赖于父 RDD 的多个分区或所有分区，也就是说存在一个父 RDD 的一个分区对应一个子 RDD 的多个分区。在 Spark 外面须要 shuffle，Spark 称之为 Shuffle Dependency，做为划分 stage 根据。
图 3-3 Narrow Dependencies 与 Wide Dependencies
在 Spark 中 Stage 划分形式是从后往前推算，遇到 ShuffleDependency 就断开，遇到 NarrowDependency 就将其退出该 stage。每个 stage 外面 task 的数目由该 stage 最初一个 RDD 中的 partition 个数决定。如图 3-4。
图 3-4 Spark Stage 划分形式
在 Spark 中 RDD 的算子分为两大类：
Transformations：数据转换，如 map、filter、flatMap、join、groupByKey、reduceByKey、sortByKey、repartition 等等，该类型算子采纳 lazy evaluation（惰性求值），即 Transformation 操作不会开始就真正的计算，只有在执行 Action 操作的时候 Spark 才会真正开始计算。转化操作不会立即执行，而是在外部记录下所要执行的操作的相干信息，必要时再执行。
Actions：数据物化操作，计算触发，如 collect、count、foreach、first、saveAsHadoopFile 等等。
每个 Stage 内蕴含一组 TaskSet，Task 之间传递数据是 Pipeline 的形式。
依据业务标签数据处理须要，借鉴 Spark 的思维，CDP 对 DAG 计算做了一些简化，具体如下：
在 CDP 的 DAG 中，DAG 的拆分是间接从前往后推算，不须要拆分 Stage，所有的 DAG Task 都在同一个 stage 中（All in one Stage）如图 3-5，并且是并发可扩大，不须要 DAGScheduler。
在 CDP 中算子分为两大类：
Operator：数据处理操作算子，如 Stream、Priority、Join、Filter、Sink，是由根底的原子算子配置而来，该类型算子采纳 eagerevaluation（及早求值），即 Operator 在数据一旦进入就会触发数据处理操作，这样不须要缓存状态数据，能无效晋升数据处理效率。
Edge：形容 Operator 之间的关系，即拓扑关系。
图 3-5 CDP All in one Stage
四、标签长久化
标签长久化的场景须要解决业务标签的长久化存储、更新、查问服务，采纳分布式高可用关系型数据库（TiDB）存储业务长久化的标签，采纳实时触发场景中的动静规定配置的形式生产业务零碎数据变更音讯，应用本文第三节中提到的实时触发的形式解决后更新长久化标签存储数据，保障业务长久化标签的时效性，通过 TiDB 对于不同场景查问个性（次要是 OLAP 和 OLTP）的反对来满足不同业务场景拜访业务特色数据的须要。
为了解决标签长久化场景的需要，借鉴 Lambda 数据处理架构的思维，新增数据依据起源不同别离发送到不同的通道中去，历史全量数据通过数据批处理引擎（如 Spark）转换实现当前批量写入到数据长久化存储引擎（TiDB）。增量数据业务利用以音讯的模式发送到 Kafka 或者 QMQ 音讯队列，通过本文第三节实时触发场景中提到的实时数据处理办法，将数据依照标签长久化的逻辑规定解决实现之后增量写入到长久化存储引擎（TiDB），这样解决数据的时效性问题。
TiDB 有两大长久化存储形式，一种是 Row 模式的 TiKV，对于实时在线查问场景（OLTP）反对的比拟好，一种 Column 模式的 TiFlash，对于剖析类查问场景（OLAP）反对的比拟好，TiDB 数据存储外部主动解决这两个引擎的数据同步问题，客户端查问依据本身须要抉择查问形式。
图 4-1 Lambda 架构
图 4-2 CDP 长久化流程
长久标签的拜访次要场景有两个，一种是跟现有 CRM 零碎对接，在线依据业务的特色圈选符合条件的业务数据，这种场景的查问条件不固定，返回后果集因筛选条件而定，对于数据存储引擎的数据计算和解决能力要求比拟高，即咱们在数据处理畛域常常提到的 OLAP 的场景。另一种场景是线上业务依据前端传入的业务标签相干的惟一标识来查问是否满足特定业务要求，或者返回指定特征值，满足业务解决的须要，须要 ms 级响应，对应的是 OLTP 场景。
五、业务利用
5.1 实时触发场景利用
在 Trip 的很多业务场景中，须要对多条业务输出数据做荡涤、整合、计算加工解决之后再反馈利用到业务场景中去，促成业务增长。比方 Trip 一些产品线的促回访、促首单、促复购、优惠券过期、APP 新用户触达等 App Push 和 Email 邮件营销和音讯等场景，晋升 Trip 产品曝光和转化效率。
以 Trip 某产品促回访 APP Push 推送音讯为例，从页面的浏览行为到触发发送的流程能够分为几个局部：
1）产生浏览行为；
2）CDP 实时获取和解决指标行为日志数据，发送给发送通道；
3）发送通道实现音讯发送前解决；
4）依据针对该产品的不同浏览行为发送不同内容的音讯。
依据该产品实时促回访场景业务须要，以及 CDP 实时触发场景反对的算子，配置过滤工作从而动静过滤出该产品促回访场景须要的数据，依据不同的浏览深度打上不同的标签，推送通道依据深度标签给不同的客户端推送不同的内容，具体的 CDP 配置算子业务逻辑如图 5-2。
图 5-2 CDP 某 Trip 产品促回访触发逻辑示意图
通过 CDP 实时触发场景配置，零碎能够依据配置动静生成工作，不须要额定的代码开发，并且配置能够动静批改，动静失效，不须要编译、重启工作。目前这种形式从运行成果来看时效性更高，更灵便，更稳固，开发测试老本更低，不须要走代码开发、编译、测试、公布的流程。
5.2 标签长久化
在第一节中咱们提到来自不同业务零碎的数据都会有对应的 ID 及标签与之对应，咱们在长久化这些标签的同时依据业务须要建设这些 ID 之间的 Mapping 关系，如果是一一映射咱们会间接存储 Mapping 关系，如果是多对多的关系咱们会依据业务须要，依照首次、最近、全副映射关系等等形式落地 ID Mapping 关系，不便用户筛选时串联不同 ID 的特色。
目前 CDP 曾经上线跟携程国内业务相干的业务零碎通过实时荡涤、转换和整合解决后落地的业务特色标签库，零碎通过 API 的形式对外提供相干数据查问和计算服务。目前 CDP 在跟 Trip 各个业务零碎深度整合买通，为国内业务增长提供业务特色标签库的数据和服务反对。