共计 18873 个字符，预计需要花费 48 分钟才能阅读完成。
作者：Jimmy
随着营销 3.0 时代的到来，企业愈发须要依靠弱小 CDP 能力解决其重大的数据孤岛问题，帮忙企业加温线索、促活客户。但什么是 CDP、好的 CDP 应该具备哪些要害特色？本文在答复此问题的同时，具体讲述了爱番番租户级实时 CDP 建设实际，既有先进架构指标下的组件抉择，也有平台架构、外围模块要害实现的介绍。
一、CDP 是什么
1.1 CDP 由来
CDP (Customer Data Platform) 是近些年时髦的一个概念。随着时代倒退、大环境变动，企业在自有媒体增多的同时，客户治理、营销变难，数据孤岛问题也愈发重大，为了更好的营销客户，CDP 诞生了。纵向来看，CDP 呈现之前次要经验了两个阶段：
- CRM 时代，企业通过电话、短信、email 与现有客户和潜在客户的互动，以及执行数据分析，从而帮忙推动保留和销售；
- DMP 阶段，企业通过治理各大互联网平台进行广告投放和执行媒体宣传流动。
CRM、DMP、CDP 三个平台核心作用不同，但纵向来比照，更容易了解 CDP。三者之间在数据属性、数据存储、数据用处等方面都较大差别。
有几个要害区别如下：
CRM vs CDP
- 客户治理：CRM 侧重于销售跟单；CDP 更加侧重于营销。
- 触点：CRM 的客户次要是电话、QQ、邮箱等；CDP 还蕴含租户的自有媒体关联的用户账号 (例如，企业本人的网站、app、公众号、小程序)。
DMP vs CDP
- 数据类型：DMP 是匿名数据为主；CDP 以实名数据为主。
- 数据存储：DMP 数据只是短期存储；CDP 数据长期存储。
1.2 CDP 定义
2013 年 MarTech 分析师 David Raab 首次提出 CDP 这个概念，起初其发动的 CDP Institute 给出权威定义：packaged software that creates a persistent, unified customer database that is accessible to other systems。
这外面次要蕴含三个层面：
- Packaged software：基于企业本身资源部署，应用对立软件包部署、降级平台，不做定制开发。
- Persistent, unified customer database：抽取企业多类业务零碎数据，基于数据某些标识造成客户的对立视图，长期存储，并且能够基于客户行为进行个性化营销。
- Accessible to other systems：企业能够应用 CDP 数据分析、治理客户，并且能够通过多种形式取走重组、加工的客户数据。
1.3 CDP 分类
CDP 自身的 C (Customer) 是指 all customer-related functions, not just marketing。面向不同场景也对应不同类型的 CDP，不同类别的 CDP 次要是性能范畴不同，然而类别之间是递进关系。
次要分为四类：
- Data CDPs： 次要是客户数据管理，包含多源数据采集、身份辨认，以及对立的客户存储、访问控制等。
- Analytics CDPs： 在蕴含 Data CDPs 相干性能的同时，还包含客户细分，有时也扩大到机器学习、预测建模、支出归因剖析等。
- Campaign CDPs： 在蕴含 Analytics CDPs 相干性能的同时，还包含跨渠道的客户策略 (Customer Treatments)，比方个性化营销、内容举荐等实时交互动作。
- Delivery CDPs： 在包含 Campaign CDPs 相干性能的同时，还包含信息触达 (Message Delivery)，比方邮件、站点、APP、广告等。
Campaign CDPs、Delivery CDPs 两类较 Analytics CDPs 多出的性能，在国内更贴近 MA (Marketing Automation，营销自动化)。本文所讲的 CDP 从提供的性能范畴来说，属于 Analytics CDPs。在爱番番也有专门的 MA 零碎，本文的 CDP 为其提供数据撑持。
二、挑战与指标
2.1 面临挑战
随着营销 3.0 时代的到来，以爱番番私域产品来说，次要是借助弱小的 CDP 为企业提供线上、线下数据的买通治理的同时，企业能够应用精细化的客户分群，进行多场景的增育流动 (比方自动化营销的伎俩，节假日促销告诉，生日祝愿短信，直播流动等等)。更重要的是，企业能够基于纯实时的用户行为进行更加共性、精确、及时的二次实时营销，帮忙企业加温线索、促活客户，晋升私域营销转化成果。那如何做好实时 CDP (Real-Time CDP，缩写为 RT-CDP) 驱动下层营销业务，面临诸多挑战。
2.1.1 业务层面
企业数据渠道多，数据形态各异
一个企业除了官网、文件、App、自有零碎，还包含目前泛滥的企业自有媒体 (比方微信公众号、抖音企业号、百家号、各类小程序等) 等各种场景的数据结构不对立，如何高效接入企业数据到 RT-CDP？这也是成千上万的企业主们在客户数据交融的课题上亟需解决的系统化问题。
不同生态无奈买通，无奈 360 度洞察用户
数据扩散导致难以辨认惟一用户身份，无奈建设全面且继续更新的用户画像，导致对用户的认知碎片化片面化，洞察有余。比方在理论营销场景下，企业冀望对同时拜访官网和其小程序的同一用户发放优惠券促活时，但因为一个人的行为以不同标识扩散在各渠道数据中，无奈进行跨渠道用户行为剖析，也就无奈实现企业诉求。
人群划分规定简单
咱们不同企业的业务是不同的，所以咱们能够依据业务特点，为不同的客户打上个性化的标签，比方企业进行营销流动时，想给通过迭代旅程节点的用户、参加某个直播等等的打上不同场景的标签，这样能力对不同的人群进行细分，做更精细化的营销。
如何用一个平台服务好 B2B2C、B2C 两类企业，行业可借鉴教训少
爱番番的客户波及多类行业，有的 B2C 的也有 B2B2C 的。绝对于 B2C，B2B2C 的业务场景复杂度是指数级回升。在治理好 B、C 画像的同时，还要兼顾下层服务的逻辑里，比方身份交融策略、基于行为的圈选等。另外，在许多业务场景也存在很多业务边界不清晰的问题。
2.1.2 技术层面
全渠道实时精准辨认要求高
当今时代一个客户行为跨源跨设施跨媒体，行为轨迹碎片化重大。如果企业想营销成果好，精准、实时辨认客户、串联客户行为轨迹是重要前提。那如何在多源多身份中做到高性能的实时辨认也是个很大挑战。
须要具备实时、低提早解决海量数据的能力
当初客户可选择性多，动向度不明确，基于客户行为实时营销，以及基于客户反馈的实时二次交互是进步营销成果的要害，比方企业营销部门群发一个流动短信，客户点没点，点了有什么样进一步的动作，代表着客户不同的动向水平，企业营销、销售人员须要依据客户动作进行及时进一步的跟进。只有实时把握这些变动，能力更高效地促成营销流动的转化。如何实时处理海量数据驱动业务？
须要可扩大的架构
在多租户背景下，爱番番治理数千、万中小企业的海量数据。随着服务企业数量的一直减少，如何疾速一直晋升平台的服务能力，须要设计一个先进的技术架构。另外，如何做到高性能、低提早、可伸缩、高容错，也是很大的技术挑战。
多租户个性、性能如何兼顾
爱番番私域产品是以 Saas 服务模式服务于中小企业，那一个具备多租户个性的 CDP 是一个根本能力。尽管中小企业客户个别十万、百万量级不等，但随着企业进行的营销流动的累增，企业的数据体量也会线性增长。对于中大企业来说，其客户量级决定了其数据体量增长速度更快。另外，不同企业对于数据查问的维度各异很难做模型预热。在此前提下，如何兼顾可扩展性、服务性能是个难题。
多样部署扩展性
CDP 目前次要以 Saas 服务服务于中小企业，但不排除后续反对大客户 OP 部署 (On-Premise，本地化部署) 的需要，如何做好组件选型反对两类服务形式？
2.2 RT-CDP 建设指标
2.2.1 要害业务能力
通过剖析和业务形象，咱们感觉，一个真正好的 RT-CDP 须要做到如下几个要害特色：
- 灵便的数据对接能力： 能够对接客户各种数据结构多类数据源的客户零碎。另外，数据能够被随时拜访。
- 同时反对 B2C 和 B2B 两类数据模型： 面向不同的行业客户，用一套服务撑持。
- 对立的用户、企业画像： 蕴含属性、行为、标签 (动态、动静 ( 规定) 标签、预测标签 )、智能评分、偏好模型等等。
- 实时的全渠道身份辨认、治理： 为了突破数据孤岛，买通多渠道身份，是提供对立用户的要害，也是为了进行跨渠道用户营销的前提。
- 弱小的用户细分能力 (用户分群)： 企业能够依据用户属性特色、行为、身份、标签等进行多维度多窗口组合的用户划分，进行精准的用户营销。
- 用户的实时交互、激活： 面对用户习惯变动快，实时感知用户行为进行实时自动化营销能力尤为重要。
- 平安的用户数据管理： 数据长期、平安存储是数据管理平台的根本要求。
2.2.2 先进技术架构
明确平台业务指标的同时，一个先进的技术架构也是平台建设的指标。如何做到平台架构，咱们有如下几个外围指标：
1. 流数据驱动
在传统数据库、数据处理上，还次要是『数据被动，查问被动』。数据在数据库中处于静止状态，直到用户收回查问申请。即便数据发生变化，也必须用户被动从新收回雷同的查问以取得更新的后果。但当初数据量越来越大、数据变动及时感知要求越来越高，这种办法已无奈满足咱们与数据交互的整个范式。
当初零碎架构设计如下图，更偏向于被动驱动其余零碎的架构，比方畛域事件驱动业务。数据处理亦是须要如此：『数据被动、查问被动』。
举个例子，企业想找到拜访过企业小程序的用户进行发短信时，两种别离如何做？
- 传统形式：先将用户数据存入存储引擎，在企业发短信之前再将查问条件转换成 SQL，而后去海量数据中筛选符合条件的用户。
- 古代形式：在用户数据流入数据系统时，进行用户画像丰盛，而后基于此用户画像进行符不合乎企业查问条件的判断。它只是对单个用户数据的规定判断，而不是从海量数据筛选。
2. 流计算解决
传统的数据处理更多是离线计算、批量计算。离线计算就是 Data at rest，Query in motion；批量计算是将数据积攒到肯定水平，再基于特定逻辑进行加工解决。尽管两者在数据处理数据形式也有所不同，然而从根本上来说都是批量解决，人造也就有了提早了。
流式计算则是彻底去掉批的概念，对流数据实时处理。也就是针对无界的、动静的数据进行继续计算，能够做到毫秒级提早。在海量数据时代竞争强烈的明天，对企业洞察来说尤为如此，越快开掘的数据业务价值越高。
3. 一体化实际
批流一体
在大数据处理畛域，存在两个典型的架构 (Lamda、Kappa、Kappa+)。Lamda 架构就是批计算、实时计算走两套计算架构，导致有时候有的雷同逻辑开发两套代码，容易呈现数据指标不统一，也带来了保护艰难。Kappa、Kappa+ 架构是旨在简化分布式计算架构，以实时事件处理架构为外围兼顾批流两种场景。在大多数企业理论生产架构中还是两者混合较多，因为彻底的实时架构存在很多难点，比方数据存储、某些批计算更易解决的大窗口聚合计算等。
对立编程
对立数据处理编程范式是一个重要的编程抉择，有两个起因：
- 在理论业务场景中，批、流解决仍然是同时存在的。思考到随着分布式数据处理计算倒退，分布式解决框架也会新陈代谢；
- 在各个公司，多个计算框架并用的状况还是普遍存在。
这样就能够进步编程灵活性，做到反对批、流场景数据处理作业开发，做到一套处理程序能够执行在任意的计算框架上，这样也利于后续平台切换更优良的计算引擎。
可扩大为前提
这里次要是指架构的扩展性，一个具备扩展性的架构能够在稳固服务业务的同时正当管制资源老本，能力可继续撑持业务的疾速倒退。
算存拆散
在现在海量数据的大数据时代，在不同场景下有时仅须要高解决能力，有时仅须要海量数据存储。传统存算一体架构，如果要满足两种场景，就须要高配置（多核、多内存、高性能本地盘等）服务节点，显然存在资源利用不合理，也会引发集群稳定性问题，比方节点过多导致数据扩散，引发数据一致性升高等。算存拆散的架构才合乎分布式架构的思维，针对业务场景进行计算资源、存储资源的别离管制，实现资源正当调配。也利于集群数据一致性、可靠性、扩展性、稳定性等方面的能力保障。
动静伸缩
动静伸缩次要为了进步资源利用率，升高企业老本。理论业务中，有时候平台须要应答在业务安稳期短时间段内的流量 (实时音讯量) 波峰波谷须要短期扩容，比方在各个重要节日大量企业同时须要做很多营销流动，导致音讯量陡升；有时候随着爱番番服务的企业量一直增长，也会导致音讯量线性减少，进而须要长期扩容。针对前者，一方面不好预感，另一方面也存在很高的运维老本。所以一个能够基于工夫、负载等组合规定动静扩缩容的集群资源管理能力也是架构建设的重要思考。
三、技术选型
没有万能的框架，只有适合的取舍。须要联合本身业务特点和架构指标进行正当选型。联合 RT-CDP 建设指标，咱们做了如下几个外围场景的组件调研、确定。
3.1 身份关系存储新尝试
在 CDP 中跨渠道身份买通 (ID Mapping) 是数据流渠道业务的外围，须要做到数据统一、实时、高性能。
传统的 idmapping 是怎么做？
1. 应用关系型数据库存储身份关系个别是将身份关系存成多表、多行进行治理。该计划存在两个问题：
- 数据高并发实时写入能力无限；
- 个别身份辨认都须要多跳数据关系查问，关系型数据库要查出来冀望数据就须要屡次 Join，查问性能很低。
2. 应用 Spark GraphX 进行定时计算个别是将用户行为存入 Graph 或者 Hive，应用 Spark 定时将用户行为中身份信息一次性加载到内存，而后应用 GraphX 依据穿插关系进行用户连通性计算。该计划也存在两个问题：
- 不实时。之前更多场景是离线聚合、定时对用户做动作；
- 随着数据量减少计算耗时会越来越高，数据后果提早也会越来越高。
咱们怎么做？
随着近几年图技术的倒退，基于图解决业务问题的案例越来越多，开源图框架的产品能力、生态集成越来越欠缺，社区活跃度也越来越高。所以咱们尝鲜基于图进行身份关系建模，借助图天然的多度查问能力进行实时身份判断、交融。
图框架比照
大家也能够联合最新的图数据库的排名走势，进行重点调研。另外，对于支流图库比照案例也越来越多，能够自行参考。在分布式、开源图数据库中次要是 HugeGraph、DGraph 和 Nebula。咱们在生产环境次要应用了 DGraph 和 Nebula。因为爱番番服务都是基于云原生建设，平台建设后期抉择了 DGraph，但起初发现程度扩大受限，不得不从 DGraph 迁徙到 Nebula。
网上对 DGraph 和 Nebula 比照很少，这里简略说一下区别：
- 集群架构：DGraph 是算存一体的，其存储是 BadgerDB，go 实现的对外通明；Nebula 读写拆散，但默认是 RocksDB 存储 (除非基于源码更换存储引擎，也有公司在这么搞)，存在读写放大问题；
- 数据切分：DGraph 是基于谓词切分 (能够了解为点类型)，容易呈现数据热点，想反对多租户场景，就须要动态创建租户粒度谓词来让数据分布尽量平均 (DGraph 企业版也反对了多租户个性，但免费且仍然没思考热点问题)；Nebula 基于边切分，基于 vid 进行 partition，不存在热点问题，但图空间创立时须要估算好分区个数，不然不好批改分区数。
- 全文检索：DGraph 反对；Nebula 提供 listener 能够对接 ES。
- Query 语法：DGraph 是本人的一个查问语法；Nebula 有本身查问语法之外，还反对了 Cypher 语法 (Neo4j 的图形查询语言)，更合乎图逻辑表白。
- 事务反对：DGraph 基于 MVCC 反对事务；Nebula 不反对，其边的写事务也是最新版才反对的 (2.6.1)。
- 同步写：DGraph、Nebula 均反对异步、同步写。
- 集群稳定性：DGraph 集群更稳固；Nebula 的稳定性还有待晋升，存在特定运算下偶发 Crash 的状况。
- 生态集群：DGraph 在生态集成更成熟，比方与云原生的集成；Nebula 在生态集成范畴上更多样一些，比方 nebula-flink-connector、nebula-spark-connector 等，但在各类集成的成熟度上还有待晋升。
3.2 流式计算引擎抉择
对于支流计算框架的比照，比方 Apache Flink、Spark Streaming、Storm，网上有很多材料，大家也请自行调研就好。
抉择 Apache Flink 做为流批计算引擎
Apache Flink 是近几年倒退很快的一个用于分布式流、批处理数据处理的开源平台。它是最贴合 DataFlow 模型实现的分布式计算框架。基于流计算进行高性能计算，具备良好的容错、状态管理机制和高可用能力；其余组件于 Flink 的集成也越来越多、也日趋成熟；所以抉择咱们 Apache Flink 做为咱们的流批计算引擎。
抉择 Apache Beam 做为编程框架
分布式数据处理技术一直倒退，优良的分布式数据处理框架也会层出不穷。Apache Beam 是 Google 在 2016 年奉献给 Apache 基金会的孵化我的项目，它的指标是对立批处理和流解决的编程范式，做到企业开发的数据处理程序能够执行在任意的分布式计算引擎上。Beam 在对立编程范式的同时也提供了弱小的扩大能力，对新版本计算框架的反对也很及时。所以咱们抉择 Apache Beam 做为咱们的编程框架。
3.3 海量存储引擎取舍
在 Hadoop 生态系统存储组件中，个别用 HDFS 反对高吞吐的批处理场景、用 HBase 反对低提早，有随机读写需要的场景，但很难只应用一种组件来做到这两方面能力。另外，如何做到流式计算下的数据实时更新，也影响存储组件的抉择。Apache Kudu 是 Cloudera 开源的列式存储引擎，是一种典型的 HTAP (在线事务处理 / 在线剖析解决混合模式)。在摸索 HTAP 的方向上，TiDB、OceanBase 均在此行列，只是大家起初偏重的场景不同而已，大家也能够比照一下。ApacheKudu 的愿景是 fast analytics on fast and changing data。从 Apache Kudu 的定位，如下图可见一斑：
联合咱们的平台建设理念，实时、高吞吐的数据存储、更新是外围指标，在数据简单查问、数据利用的 QPS 上不高 (因为外围的业务场景是基于实时流的实时客户解决)，再加上 Cloudera Impala 无缝集成 Kudu，咱们最终确定 Impala + Kudu 做为平台的数据存储、查问引擎。
剖析加强：Doris
基于 Impala + Kudu 的选型，在反对 OP 部署时是齐全没有问题的，因为各个企业的数据体量、数据查问 QPS 都无限。这样企业只须要很简略的架构就能够反对其数据管理需要，进步了平台稳定性、可靠性，同时也能够升高企业运维、资源老本。但因为 Impala 并发能力无限 (当然在 Impala4.0 开始引入多线程，并发解决能力晋升不少)，爱番番的私域服务目前还是以 Saas 服务为重，想在 Saas 场景下做到高并发下的毫秒级数据分析，这种架构性能很难达标，所以咱们在剖析场景引入了剖析引擎 Doris。之所以抉择 Doris，基于 MPP 架构的 OLAP 引擎。绝对于 Druid、ClickHouse 等开源剖析引擎，Doris 具备如下特点：
- 反对多种数据模型，包含聚合模型、Uniq 模型、Duplicate 模型；
- 反对 Rollup、物化视图；
- 在单表、多表上的查问性能都体现很好；
- 反对 MySQL 协定，接入、学习成本低；
- 无需集成 Hadoop 生态，集群运维老本也低很多。
3.4 规定引擎调研
实时规定引擎次要用于客户分群，联合美团的规定比照，几个引擎 (当然还有一些其余的 URule、Easy Rules 等) 特点如下：
RT-CDP 中客户分群规定分类、组合多，规定计算简单、算子多，工夫窗口跨度大、甚至无窗口，业内没有一个能很好满足业务需要的开源规定引擎，所以咱们抉择了自研。
四、平台架构
4.1 整体架构
在爱番番私域产品中，次要分为两局部：RT-CDP 和 MA，两者叠加近似等同于 Deliver CDP 所蕴含的性能范畴。本文所讲的 RT-CDP 所蕴含的性能范畴等同于 Analytics CDPs，简略来讲，次要就是客户数据管理、数据分析洞察。
RT-CDP 也是就两局部性能进行拆分，次要蕴含五局部：数据源、数据采集、实时数仓，数据利用和公共组件，除公共组件局部是横向撑持外，其余四局部就是规范的数据对接到数据利用的四个阶段：
- 数据源： 这里的数据源不仅蕴含客户公有数据，也包含在各个生态上的自有媒体数据，比方微信公众号、微信小程序、企微线索、百度小程序、抖音企业号、第三方生态行为数据等。
- 数据采集： 大多中小企业没有研发能力或者很单薄，如何帮忙疾速将自有系统对接到爱番番 RT-CDP 是这层须要重点思考的，为此咱们封装了通用的采集 SDK 来简化企业的数据采集老本，并且兼容 uni-app 等优良前端开发框架。另外，因为数据源多种多样、数据结构不一，为了简化一直接入的新数据源，咱们建设了对立的采集服务，负责管理一直新增的数据通道，以及数据加解密、荡涤、数据转换等数据加工，这个服务次要是为了提供灵便的数据接入能力，来升高数据对接老本。
- 实时算存： 在采集到数据后就是进行跨渠道数据身份辨认，而后转换成结构化的客户对立画像。就数据管理来说，这层也蕴含企业接入到 CDP 中的碎片客户数据，为了后续企业客户剖析。通过这层解决，会造成跨渠道的客户身份关系图、对立画像，而后再通过对立视图为下层数据接口。另外，就是数仓惯例的数据品质、资源管理、作业管理、数据安全等性能。
- 数据利用： 这层次要是为企业提供客户治理、剖析洞察等产品性能，比方丰盛的潜客画像、规定自由组合的客户分群和灵便的客户剖析等。也提供了多种数据输入形式，不便各个其余零碎应用。
- 公共组件：RT-CDP 服务依靠爱番番先进的基础设施，基于云原生理念治理服务，也借助爱番番弱小的日志平台、链路追踪进行服务运维、监控。另外，也基于齐备的 CICD 能力进行 CDP 能力的疾速迭代，从开发到部署都是在麻利机制下，继续集成、继续交付。
4.2 外围模块
简略来说，RT-CDP 实现的性能就是多渠道数据的实时、定时采集，而后通过数据中身份的辨认 Identity 服务，再进行数据处理、数据进行数据映射、加工 (比方维度 Join、数据聚合、数据分层等)，而后进行结构化长久化，最初对外实时输入。
RT-CDP 次要划分为六大模块：采集服务、Connectors、Identity Service、实时计算、对立画像和实时规定引擎。上图就是从数据交互模式和数据流向的角度描述了 RT-CDP 外围模块之间的交互。从左到右是数据的支流向，代表了数据进入平台到数据输入到和平台交互的内部零碎；两头上侧是实时计算和 Identity Service、实时规定引擎和对立画像的双向数据交互。
上面联合数据处理阶段进行各个外围模块的性能阐明：
1. 数据源 & 采集
从数据源和 RT-CDP 数据交互方式上，次要分为实时流入和批次拉取。针对两种场景，咱们形象了两个模块：实时采集服务和 Connectors。
- 实时采集服务： 该模块次要是对接企业已有的自有媒体数据源，爱番番业务零碎畛域事件以及爱番番单干的第三方平台。这层次要存在不同媒体平台 API 协定、场景化行为串联时的业务参数填充、用户事件一直减少等问题，咱们在该模块形象了数据 Processor & 自定义 Processor Plugin 等来缩小新场景的人工干预。
- Connectors： 该模块次要是对接企业的自有业务零碎的数据源，比方 MySQL、Oracle、PG 等业务库，这部分不须要实时接入，只需按批次定时调度即可。这里须要解决的次要是多不同数据源类型的反对，为此咱们也形象了 Connector 和扩大能力，以及通用的调度能力来反对。针对两种场景下，存在同一个问题：如何应答多样数据结构的数据快读疾速接入？为此，咱们形象了数据定义模型 (Schema)，前面会具体介绍。
2. 数据处理
- Identity Service： 该模块提供跨渠道的客户辨认能力，是一种精准化的 ID Mapping，用于实时买通进入 RT-CDP 的客户数据。该服务长久化了客户身份相干关系图放在 Nebula 中，会依据实时数据、身份交融策略进行实时、同步更新 Nebula，而后将辨认后果填充到实时音讯。进入 CDP 数据只有通过 Identity Service 辨认后才持续往后走，它决定了营销旅程的客户交互是否合乎预期，也决定了 RT-CDP 的吞吐下限。
- 实时计算： 该模块蕴含了所有数据处理、加工、散发等批流作业。目前形象了基于 Apache Beam 的作业开发框架，尝试批流都在 Flink 上做，但有些运维 Job 还用了 Spark，会逐步去除。
- 对立画像： 该模块次要是长久化海量的潜客画像，对于热数据存储在 Kudu 中，对于温、冷的时序数据定时转存到 Parquet 中。潜客画像包含客户属性、行为、标签、所属客群、以及聚合的客户扩大数据等。尽管标签、客群是独自存在的聚合根，然而在存储层面是统一的存储机制。另外，规范 RT-CDP 还应该治理客户碎片数据，所以对立画像和数据湖数据如何交互是后续建设的重点。
- 对立查问服务： 在 RT-CDP 中，客户数据扩散在图数据库、Kudu、加强的剖析引擎和数据湖，但对用户来说只有属性、行为、标签、客群等业务对象，如何反对产品上通明应用？咱们通过对立视图、跨源查问建设了此对立查问服务，该服务反对了 Impala、Doris、MySQL、Presto、ES 等查问存储引擎以及 API 的跨源拜访。
- 实时规定引擎： 该模块次要是基于 Flink 提供实时规定判断，来反对圈群、基于规定的动态打标、规定标签等业务场景。
3. 数据输入
数据输入曾经反对多种形式，包含 OpenAPI、Webhook、音讯订阅等。一方面，也不便企业获取 CDP 交融后的潜客的实时行为，而后与自有的上游业务零碎进行用户全链治理。另一方面为下层的 MA 提供实时行为流驱动营销环路。这里非凡阐明阐明一下，MA 的旅程节点中也须要很多实时规定判断，判断口径多样，有些在节点上做内存实现艰难，所以 RT-CDP 也实现了能够为 MA 提供实时判断后果的数据输入。
4.3 要害实现
4.3.1 数据定义模型
为什么须要 Schema？
后面提到企业的多个渠道的数据特色构造各异。再加上不同租户业务特点不同，企业须要数据自定义的扩展性。RT-CDP 为了两类问题须要具备数据结构灵便定义的能力来对接企业数据。
另外，RT-CDP 自身治理两类数据：碎片化客户数据和用户对立画像。对于前者来说，不须要关系数据内容自身，利用数据湖等技术即可为企业提供数据存储、查问、剖析能力，是偏 Schemaless 的数据管理；对于后者来说，更多须要按不同维度组合查问、圈群、剖析，自身须要结构化的数据管理。后者是否通过 Schemaless 的形式提供服务呢？列举增删改查的场景，反证一下局限显著。
Schema 是什么？
Schema 是一个数据结构的形容，Schema 能够互相援用，能够对数据中字段以及字段类型、值进行束缚，也能够自定义字段。企业能够用一个对立的标准疾速接入、灵便治理本人的数据，比方企业能够依据本人的行业个性，形象不同的业务实体、属性，再给不同的业务实体定义不同的 Schema。企业能够对业务实体有交加的信息抽离新 Schema，而后多个 Schema 援用这个新 Schema；也能够对每个 Schema 自定义本人的业务字段。企业只须要按相应的 Schema 构造接入数据，就能够按特定的规范应用这些数据。
从这几个实体来阐明 Schema 的特点，如下图：
- Field：字段是最根本的数据单元，是组成 Schema 的最小粒度元素。
- Schema：是一组字段、Schema 的汇合，它自身能够蕴含多个字段 (Field)，字段能够自定义，比方字段名、类型、值列表等；也能够援用一个或多个其余 Schema，援用时也能够以数组的模式承载，比方一个 Schema 外面能够蕴含多个 Identity 构造的数据。
- Behavior：是潜客或企业的不同行为，自身也是通过 Schema 承载，不同的 Behavior 也能够自定义其特有的 Field。
在上图所示，爱番番 RT-CDP 在进行行业形象后，曾经内置了很多行业通用的 Schema，包含常见的 Identity、Profile、Behavior 等多类 Schema。在爱番番 RT-CDP 治理的对立潜客画像中，Identity、Profile、Tag、Segment 等都业务聚合根。为了反对好 B、C 两种数据模型还有一些 B 粒度聚合根存在。
Schema 如何简化数据接入？
这里须要先说一个 Dataset 的概念。Dataset 是通过 Schema 定义构造的一个数据集，企业对不同的数据源定义成不同的数据集。在数据源治理时，企业能够依据不同的数据集结构化导入的数据，一个数据集能够对应多个数据源，也能够对应一个数据源中的一类数据，个别后者应用较多。另外，一个数据集也能够蕴含多批次的数据，也就是企业能够周期性的按批次导入同一数据集数据。在数据接入时，如下图，针对不同的 Dataset，企业能够绑定不同的 Schema，每个 Schema 能够援用、复用其余子 Schema，而后通过 RT-CDP 的 Schema 解析，主动将数据长久化到存储引擎，依据数据的定义不同，会长久化到不同数据表中。对应实时的客户行为也是通过定义不同的 Schema 来定义数据结构，而后进行继续的数据接入。
扩大 1：借助字段映射解决多租户有限扩列问题
存在的问题是什么？
爱番番 RT-CDP 是一个反对多租户的平台，但在多租户下，每个企业都有本人的业务数据，个别中小企业可能有几百上千个潜客的数据字段，对于 KA 字段量更多。CDP 做为 Saas 服务，如何在一个模型中反对如此多的字段存储、剖析。个别能够有限扩列的引擎能够间接按租户 + 字段的形式打平。为了进行结构化实时存储，爱番番 CDP 抉择了 Kudu，Kudu 官网倡议单表不超过 300 列，最多也就反对上千列，那方才的形式无奈解决。
咱们的解决方案是什么？
咱们在租户隔离的前提下，采纳字段复用的形式解决该问题。在介绍 Schema 模型时图里也有体现，在理论的 Profile、Event 表里都是 attr 字段。关键点就是：
- 事实表只做无业务含意的字段；
- 在数据接入、查问时通过业务字段 (逻辑字段) 和事实字段的映射关系进行数据转换后与前端、租户交互。
4.3.2 Identity Service
这个服务也能够称之为 ID Mapping。但绝对于传统的 ID Mapping 来说，因为业务场景的不同，性能偏重也有所不同。传统意义的 ID Mapping 更多是广告场景的匿名数据的，基于简单模型的离线和预测辨认；CDP 中的 ID Mapping 是基于更精准的数据身份标识，进行更精准买通，更加要求买通率和实时性。
为此，咱们设计了反对 B2B2C、B2C 两种业务的身份关系模型。在标准化租户数据接入后，基于一直接入的数据新增继续的身份关系图谱裂变。在性能层面，咱们反对自定义身份类型以及身份权重，也反对针对不同身份租户自定义身份交融动作。另外，依据咱们对行业剖析，内置了常见的身份及交融策略，不便租户间接应用。
从架构层面，Identity Service (ID Mapping) 基于云原生 + Nebula Graph 搭建，做到了租户数据隔离、实时读写、高性能读写以及程度扩缩容。
1. 云原生 + Nebula Graph
将 Nebula Graph 部署到 K8s 下，升高运维老本。咱们次要是：
- 应用 Nebula Operator 自动化运维咱们 k8s 下的 Nebula 集群；
- 应用 Statefulset 治理 Nebula 相干有状态的节点 Pod；
- 每个节点都是应用本地 SSD 盘来保障图存储服务性能。
2. 优化读写
Identity Service 整体来说是一个读多写少的常见，但在新租户、拉新场景场景也都须要很高的写能力，读写性能须要兼顾。须要在做好并发锁的前提下优化读写：
- 设计好数据模型，尽量减少 Nebula 外部 IO 次数；
- 正当利用 Nebula 语法，防止 Graphd 多余内存操作；
- 查问上，尽量减少深度查问；更新上，管制好写粒度、升高无事务对业务的影响。
扩大 1：如何解决未登录时潜客买通问题
针对一个人多设施场景，单设施被多人应用的场景，咱们采纳离线改正的形式进行买通。
4.3.3 实时存算
4.3.3.1 流计算
爱番番 RT-CDP 外围能力都是依靠 Apache Flink + Kafka 实现。在实时流之上进行的流计算，做到毫秒的数据提早。
外围数据流如上图，简化后次要蕴含如下几局部：
- 次要采集和格式化的数据，会对立发到 cdp-ingest 的 topic；
- RT-CDP 有个对立的入口 Job (Entrance Job) 负责数据的荡涤、校验、Schema 解析以及身份辨认等，而后依据租户属性进行数据散发。因为这是 RT-CDP 入口 Job，须要反对横向扩缩，所以这个作业是无状态 Job。
- 通过数据散发，会有不同的 Job 群进行别离的数据处理、长久化，以及数据聚合等数据加工逻辑，一方面丰盛潜客画像，另一方面为更多维度的潜客圈群提供数据根底。
- 最初会将买通的数据散发到上游，上游包含内部零碎、数据分析、实时规定引擎、策略模型等多类业务模块，以便进行更多的实时驱动。
扩大 1：数据路由
为什么要做路由？
爱番番 RT-CDP 做为根底数据平台，不仅服务于百度之外的租户，也服务于百度外部甚至爱番番本人；不仅服务于中小企业，也服务于中大企业。对于前者，服务稳定性要求级别不同，如何防止内外部之间服务能力不相互影响？对于后者，不同规模企业潜客量不同，应用 RT-CDP 圈人群等耗时的资源也不同，如何防止资源不偏心调配？
咱们怎么做的？
针对上述问题，咱们通过数据路由的机制解决。咱们保护了一张租户和数据流 Topic 的映射关系，能够依据租户个性进行分流，也能够依据租户需要动静调整。而后在 Entrance Job 依据租户的映射关系进行数据分流，散发到不同资源配比的 Job 群进行别离的数据处理。做到了内外部拆散，也能够依据租户个性化需要进行资源管制。
扩大 2：自定义 Trigger 批量写
在随机读写上，Kudu 的体现绝对于 HBase 等还是绝对差一些。为了做到数十万 TPS 的写能力，咱们对 Kudu 写也做了肯定逻辑优化。次要是自定义了 Trigger (数量 + 工夫窗口两种触发)，在做到毫秒级提早的前提将单条写改为一次策略的批量。
具体计划：在在批量数据满足 > N 条、或者工夫窗口 > M 毫秒时，再触发写操作。
个别租户的一次营销流动，会集中产生一大批潜客行为，这其中包含零碎事件、用户实时行为等，这种批量写的形式，能够无效进步吞吐。
4.3.3.2 实时存储
在 RT-CDP 次要包含三局部的数据：碎片化的租户数据、对立的潜客画像和离线剖析数据。咱们次要分类两个集群进行数据存储，一个集群存储潜客对立画像和具备时序属性的热数据，另一个集群存储冷数据和用于离线计算的数据。每个集群都集成了数据湖的能力。而后咱们研发了对立的 Query Engine，反对跨源、跨集群的数据查问，对底层存储引擎通明。
扩大 1：基于数据分层加强存储
为什么须要分层？
齐全基于 Kudu 存储数据的话，一方面老本较高 (Kudu 集群都要基于 SSD 盘搭建能力有比拟好的性能体现)；另一方面在营销场景下更关注短时间段 (比方近一个月、三个月、半年等) 客户的实时行为变动，对于工夫较久的历史数据应用频次很低。
分层机制
综合考量，也从节约资源老本角度，咱们抉择 Parquet 做为扩大存储，针对存储合乎工夫序列的海量数据做冷热分层存储。
依据数据应用频率，咱们将数据分为热、温、冷三层。热数据，示意租户常常应用的数据，工夫范畴为三个月内；温数据，示意应用频率较低的数据，个别只用于个别客群的圈选，工夫范畴为三个月外到一年；冷数据，租户根本不应用的数据，工夫范畴为一年之外。为了均衡性能，咱们将热、温数据寄存在同一个集群，将冷数据放在另外集群 (和提供给策略模型的集群放在一个集群)。
具体计划：
- 在热、温、冷之上建设对立视图，下层依据视图进行数据查问。
- 而后每天定时进行热到温、温到冷的程序性的别离离线迁徙，在别离迁徙后会别离进行视图的实时更新。
扩大 2：基于潜客交融门路的映射关系治理解决数据迁徙问题
为什么须要治理映射？
潜客画像行为数据很多，也可能存在频繁交融的状况，如果在潜客交融时，每次都迁徙数据，一方面数据迁徙老本很高，另一方面，当潜客行为波及温冷数据时，是无奈进行删除操作的。业内针对相似状况，更多会有所取舍，比方只迁徙用户仅一段时间的热数据，再往前的历史不做解决。这种解决方案并不现实。
映射管理机制
为此，咱们换了种思路，通过保护潜客交融门路的形式形式解决该问题。
具体计划：
- 新增一张潜客交融关系表 (user_change_rela) 保护映射关系；
- 在交融关系表和时序表 (比方 event) 之上创立视图，做到对业务层通明。
针对交融关系表，咱们做了肯定的策略优化：不保护门路上的过程关系，而是只保护门路所有过程点到起点的间接关系。这样即使在潜客交融门路波及过多潜客时，也不会过多减少关系查问的性能。
举个例子潜客产生两次交融 (affId=1001 先交融到 1002 上，再交融到 1003 上) 时的 user_change_rela 的数据变动状况，如下图：
4.3.3.3 剖析加强
咱们抉择百度开源的 Apache Doris 做为数据加强的剖析引擎，为爱番番拓客版提供客户洞察能力，比方旅程剖析、人群、营销成果剖析、裂变剖析、直播剖析等。
为了不便后续 OP 部署时可灵便去除，咱们将 CDP 输入的数据做为加强剖析的数据源，而后基于 Flink Job 做逻辑解决，比方荡涤、维度 Join、数据打平等，最初采纳 Apache Doris 奉献的 flink-doris-connector 将数据写入 Doris。
应用 connector 形式间接写 Doris 有两个益处：
- 应用 flink-doris-connector 往 Doris 写数据，比应用 Routine Load 形式少一次 Kafka。
- 应用 flink-doris-connector 比 Routine Load 形式在数据处理上，也能更加灵便。
Flink-doris-connector 是基于 Doris 的 Stream Load 形式实现，通过 FE redirect 到 BE 进行数据导入解决。咱们理论应用 flink-doris-connector 时，是按 10s 进行一次 Flush、每批次最大可提交百万行数据的配置进行写操作。对于 Doris 来说，单批次数据多些不 flush 更频繁要敌对。
扩大 1：RoutineLoad 和 Stream Load 区别
Routine Load 形式
它是提交一个常驻 Doris 的导入工作，通过一直的订阅并生产 Kafka 中的 JSON 格局音讯，将数据写入到 Doris 中。
从实现角度来说，是 FE 负责管理导入 Task，Task 在 BE 上通过 Stream Load 形式进行数据导入。
Stream Load 形式
它利用流数据计算框架 Flink 生产 Kafka 的业务数据，应用 Stream Load 形式，以 HTTP 协定向 Doris 写入。
从实现角度来说，这种形式是框架间接通过 BE 将数据同步写入 Doris，写入胜利后由 Coordinator BE 间接返回导入状态。另外，在导入时，同一批次数据最好应用雷同的 label，这样同一批次数据的反复申请只会被承受一次，能够保障了 At-Most-Once。
4.3.4 实时规定引擎
在爱番番私域产品中，灵便的圈群能力是一个重要产品能力，如何基于潜客属性、身份、客户行为等维度进行简单、灵便规定的实时分群？此处的实时规定引擎就是为此而生。就此性能自身来说，并不新鲜，在 DMP 中就有相似能力。很多 CDP 和客户治理平台都也有相似能力，但如何在多租户、海量数据状况下，做到实时、高吞吐的规定判断是一个挑战。
在爱番番 RT-CDP 中，一方面租户数量大，Saas 服务前提如何反对多租户的高性能分群？另一方面，爱番番 RT-CDP 冀望做到真正基于实时流的实时判断。因而，咱们自研了基于多层数据的实时规定引擎。这里简略讲一下，后续会有独自文章介绍。
面临的问题是什么？
传统的实现计划次要是当租户实时或定时触发分群申请时，将规定翻译成一个简单 SQL，长期从租户的潜客数据池中进行 SQL 查问。另外，个别都会在潜客上做一层倒排索引，在租户少或者 OP 部署时，数据查问速度也尚可承受。但在基于实时流实现规定引擎须要解决如下几个问题：
- 海量数据实时判断
- 窗口粒度数据聚合的内存占用问题
- 滑动窗口下的窗口风暴
- 无窗口规定的数据聚合问题
- 潜客数据变更后的窗口数据更新
实时规定引擎实现
和很多产品相似，爱番番的规定圈群也次要是两层 And/Or 的规定组合。联合规定的特点，咱们次要分为如下图的几类规定：一般的属性运算 (P1、P2)、一般身份运算 (I1)、小窗口的行为判断 (E1)、大窗口的行为判断 (E2) 和无窗口的行为判断 (E3)。
为了规定灵便度和高效的数据处理能力，咱们定义了一套规定解析算法。而后借助 Flink 弱小的分布式计算能力和状态治理能力驱动实时规定引擎计算。下面曾经说了流数据理念，这里联合一条潜客行为进来到实时规定判断来更直观阐明数据在流中的实时填充，如下图：数据进来之后，先通过 Identity Service 补充身份 Ids，在通过数据 Job 补充潜客对应的属性信息，最初基于一个残缺的潜客数据进行实时规定判断，最初将负责规定的潜客落入 Segment 表。
另外，规定引擎是一个独立于 Segment 等业务对象的服务，能够反对圈群、打标签、MA 旅程节点等各个规定相干的业务场景。
4.3.5 扩大
4.3.5.1 弹性集群
爱番番借助云上能力，很好实现了资源的存算拆散和动静伸缩。能够自定义灵便的资源扩缩策略，依据音讯量状况进行资源增减，做到波峰时实时加大集群规模提供计算能力，波谷时缩减集群做到及时降本。
咱们的集群次要分为四类节点：Master、Core、Task、Client。具体如上图。
- Master 节点： 集群治理节点，部署 NameNode、ResourceManager 等过程，并且做到组件故障时的主动迁徙；
- Core 节点： 计算及数据存储节点，部署 DataNode、NodeManager 等过程；
- Task 节点： 计算节点，用来补充 core 节点的算力，部署 NodeManger 等过程，该节点个别不用来存储数据，反对按需动静扩容和缩容操作；
- Client 节点： 独立的集群管控节点及作业提交节点。
4.3.5.2 全链监控
RT-CDP 在建设了残缺的链路监控能力，可能实时发现集群、数据流问题，不便及时干涉、解决，为租户提供更好的数据服务能力提供保障。也建设了全链的日志收集、剖析能力，极大简化了服务问题排查老本。
具体如上图，咱们依靠爱番番弱小的技术服务能力实现了跨平台的日志采集 & 报警和全链路的延时监控：
- 日志采集： 基于爱番番奉献给 Skywalking 的 Satellite 收集全链路服务日志，反对了 K8s 下微服务的日志收集，也反对了 Flink Job 的日志采集，做到一个日志平台，会集全链服务日志。而后通过 Grafana 进行日志查问、剖析；
- 服务指标采集： 咱们通过 PushGateway 将各个微服务，Apache Flink、Impala、Kudu 等算存集群指标对立采集到爱番番 Prometheus，做到服务实时监控 & 报警。
- 全链路延时监控： 咱们也通过 Skywalking Satellite 采集 RT-CDP 全链路的数据埋点，而后通过自研的打点剖析平台进行延时剖析，做到全链路数据延时可视化和阈值报警。
五、平台成绩
5.1 资产数据化
基于 RT-CDP 解决企业数据孤岛问题，帮忙企业将数据资产数字化、多方化、智能化、平安化。
- 多方化： 集成一方数据，买通二方数据，利用三方数据，通过多方数据买通，实现更精准、深度的客户洞察。
- 数字化： 通过自定义属性、标签、模型属性等将客户信息全面数字化治理。
- 平安化： 通过数据加密、隐衷计算、多方计算实现数据安全和隐衷爱护，爱护企业数据资产。
- 智能化： 通过智能模型不断丰富客户画像，服务更多营销场景。
5.2 高效撑持业务
灵便的数据定义能力
RT-CDP 在业务层面具备了灵便的数据定义能力，来满足企业的个性化需要：
- 丰盛的自定义 API，用于能够自定义 Schema、属性、事件等不同场景的数据上报构造；
- 反对了身份类型自定义，不便企业依据本身数据特定指定潜客标识；
- 针对不同企业的不同构造的数据能够做到零开发成本接入。
服务于不同行业企业的多样营销
依靠 RT-CDP 弱小数据管理能力，爱番番营销产品已服务于法律、商务服务、教育培训、电子电工、机械设备、金融、衰弱美容、生存服务、房产家居、修建建材、印刷包装、农林牧渔、物流运输、餐饮食品等数十个行业的数千家企业，帮忙企业解决了很多营销难题。胜利的企业案例举不胜举。
5.3 架构先进
目前咱们实现 RT-CDP1.0 的建设，并且在一些外围指标上都获得了不错的成果：
5.3.1 实时高吞吐
- Identity Service 做到数十万 QPS 的关系查问，反对上万 TPS 的身份裂变。
- 实时计算做到了数十万 TPS 的实时处理、实时长久化，做到毫秒级提早。
- 反对企业海量数据、高并发下毫秒级实时剖析。
- 真正基于实时流数据实现规定判断，撑持了私域打标、实时规定判断、圈群等多个实时业务场景，让营销毫秒触达。
5.3.2 高扩展性
平台架构存算拆散，可程度扩大：
- 基于云原生 + Nebula 搭建了，可动静伸缩的图存储集群；
- 借助云上能力，搭建了存算拆散的弹性伸缩的存算集群；
- 计算集群动静伸缩，节约企业资源老本。
5.3.3 高稳定性
各个模块、各个集群稳定性指标长期维持在 99.99% 以上。
六、将来瞻望
业务层面：更多贴近行业的中台能力
- 平台目前在业务撑持上曾经具备了比拟好的定义能力。下一步将联合重点服务的企业行业，内置更多行业业务对象，进一步简化企业数据接入老本。
- 在 B2B2C 数据模型上做更多业务尝试，更好服务 ToB 企业。
业务层面：更丰盛的 AI 模型
- RT-CDP 曾经为企业提供了智能化的潜客评分能力，反对企业灵便定义评分规定。在 AI 时代，咱们将持续丰盛更多的 AI 模型来帮忙企业治理、洞察、营销客户。
架构层面：更智能化的治理、运维
- 目前 Flink 作业还是基于 Yarn 治理资源、基于 API、脚本形式流程化操作 (比方波及到 CK 的操作) 作业监控通过如流、短信、电话报警。后续咱们将作业管理、运维上做更多尝试，比方基于 K8s 治理 Flink 作业、联合如流的 Webhook 能力欠缺作业运维能力等。
- 在流数据驱动下，数据处理机制的变动让数据治理、数据查看变得更有挑战。为了提供更牢靠的数据服务，还有很多工作要做。
架构层面：湖仓一体到智能湖仓
- 国内互联网公司曾经有不少数据湖技术实际案例，的确能够解决一些原有数仓架构的痛点，比方数据不反对更新操作，无奈做到准实时的数据查问。咱们目前也在做 Flink 和 Iceberg/Hudi 集成的一些尝试，后续会逐渐落地。
