CRM、DMP、CDP三个平台核心作用不同，但纵向来对比，更容易理解CDP。三者之间在数据属性、数据存储、数据用途等方面都较大差异。

有几个关键区别如下：

1.CRM vs CDP

• 客户管理：CRM侧重于销售跟单；CDP更加侧重于营销。
• 触点：CRM的客户主要是电话、QQ、邮箱等；CDP还包含租户的自有媒体关联的用户账号（例如，企业自己的网站、app、公众号、小程序）。

2.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主要是功能范围不同，但是类别之间是递进关系。

2.流计算处理

传统的数据处理更多是离线计算、批量计算。离线计算就是Data at rest，Query in motion；批量计算是将数据积累到一定程度，再基于特定逻辑进行加工处理。虽然两者在数据处理数据方式也有所不同，但是从根本上来说都是批量处理，天然也就有了延迟了。

流式计算则是彻底去掉批的概念，对流数据实时处理。也就是针对无界的、动态的数据进行持续计算，可以做到毫秒级延迟。在海量数据时代竞争激烈的今天，对企业洞察来说尤为如此，越快挖掘的数据业务价值越高。

3.一体化实践

【批流一体】

在大数据处理领域，存在两个典型的架构（Lamda、Kappa、Kappa+）。Lamda架构就是批计算、实时计算走两套计算架构，导致有时候有的相同逻辑开发两套代码，容易出现数据指标不一致，也带来了维护困难。Kappa、Kappa+架构是旨在简化分布式计算架构，以实时事件处理架构为核心兼顾批流两种场景。在大多数企业实际生产架构中还是两者混合较多，因为彻底的实时架构存在很多难点，比如数据存储、某些批计算更易处理的大窗口聚合计算等。

【统一编程】

在实际业务场景中，批、流处理依然是同时存在的。考虑到随着分布式数据处理计算发展，分布式处理框架也会推陈出新，虽然Apache Flink在批流一体支持上很活跃，但还不太成熟。另外，在各个公司多个计算框架并用的情况还是普遍存在。所以统一数据处理编程范式是一个重要的编程选择，可以提高编程灵活性，做到支持批、流场景数据处理作业开发，做到一套处理程序可以执行在任意的计算框架上，这样也利于后续平台切换更优秀的计算引擎。

4.可扩展为前提

这里主要是指架构的扩展性，一个具有扩展性的架构可以在稳定服务业务的同时合理控制资源成本，才能可持续支撑业务的快速发展。

【算存分离】

在如今海量数据的大数据时代，在不同场景下有时仅需要高处理能力，有时仅需要海量数据存储。传统存算一体架构，如果要满足两种场景，就需要高配置（多核、多内存、高性能本地盘等）服务节点，显然存在资源利用不合理，也会引发集群稳定性问题，比如节点过多导致数据分散，引发数据一致性降低等。算存分离的架构才符合分布式架构的思想，针对业务场景进行计算资源、存储资源的分别控制，实现资源合理分配。也利于集群数据一致性、可靠性、扩展性、稳定性等方面的能力保证。

【动态伸缩】

动态伸缩主要为了提高资源利用率，降低企业成本。实际业务中，有时候平台需要应对在业务平稳期短时间段内的流量（实时消息量）波峰波谷需要短期扩容，比如在各个重要节日大量企业同时需要做很多营销活动，导致消息量陡升；有时候随着爱番番服务的企业量不断增长，也会导致消息量线性增加，进而需要长期扩容。针对前者，一方面不好预见，另一方面也存在很高的运维成本。所以一个可以基于时间、负载等组合规则动态扩缩容的集群资源管理能力也是架构建设的重要考虑。

三、技术选型

没有万能的框架，只有合适的取舍。需要结合自身业务特点和架构目标进行合理选型。结合RT-CDP建设目标，我们做了如下几个核心场景的组件调研、确定。

3.1 身份关系存储新尝试

在CDP中跨渠道身份打通（ID Mapping）是数据流渠道业务的核心，需要做到数据一致、实时、高性能。

传统的idmapping是怎么做/strong>

1.使用关系型数据库存储身份关系一般是将身份关系存成多表、多行进行管理。该方案存在两个问题：

• 数据高并发实时写入能力有限；
• 一般身份识别都需要多跳数据关系查询，关系型数据库要查出来期望数据就需要多次Join，查询性能很低。

2.使用Spark GraphX进行定时计算一般是将用户行为存入Graph或者Hive，使用Spark定时将用户行为中身份信息一次性加载到内存，然后使用GraphX根据交叉关系进行用户连通性计算。该方案也存在两个问题：

• 不实时。之前更多场景是离线聚合、定时对用户做动作；
• 随着数据量增加计算耗时会越来越高，数据结果延迟也会越来越高。

我们怎么做/strong>

随着近几年图技术的发展，基于图解决业务问题的案例越来越多，开源图框架的产品能力、生态集成越来越完善，社区活跃度也越来越高。所以我们尝鲜基于图进行身份关系建模，借助图自然的多度查询能力进行实时身份判断、融合。

图框架对比

大家也可以结合最新的图数据库的排名走势，进行重点调研。另外，关于主流图库对比案例也越来越多，可以自行参考。在分布式、开源图数据库中主要是HugeGraph、DGraph和Nebula。我们在生产环境主要使用了DGraph和Nebula。因为爱番番服务都是基于云原生建设，平台建设前期选择了DGraph，但后来发现水平扩展受限，不得不从DGraph迁移到Nebula（关于DGraph到Nebula的迁移，坑还是挺多的，后续会有专门文章介绍，敬请期待）。

选择Apache Flink做为流批计算引擎

使用广泛的Spark还是以微批的方式进行流计算。而Flink是流的方式。Apache Flink是近几年发展很快的一个用于分布式流、批处理数据处理的开源平台。它是最贴合DataFlow模型实现的分布式计算框架。基于流计算进行高性能计算，具有良好的容错、状态管理机制和高可用能力；其他组件于Flink的集成也越来越多、也日趋成熟；所以选择我们Apache Flink做为我们的流批计算引擎。

选择Apache Beam做为编程框架

分布式数据处理技术不断发展，优秀的分布式数据处理框架也会层出不穷。Apache Beam是Google在2016年贡献给Apache基金会的孵化项目，它的目标是统一批处理和流处理的编程范式，做到企业开发的数据处理程序可以执行在任意的分布式计算引擎上。Beam在统一编程范式的同时也提供了强大的扩展能力，对新版本计算框架的支持也很及时。所以我们选择Apache Beam做为我们的编程框架。

结合我们的平台建设理念，实时、高吞吐的数据存储、更新是核心目标，在数据复杂查询、数据应用的QPS上不高（因为核心的业务场景是基于实时流的实时客户处理），再加上Cloudera Impala无缝集成Kudu，我们最终确定Impala+Kudu做为平台的数据存储、查询引擎。

分析增强：Doris

基于Impala+Kudu的选型，在支持OP部署时是完全没有问题的，因为各个企业的数据体量、数据查询QPS都有限。这样企业只需要很简单的架构就可以支持其数据管理需求，提高了平台稳定性、可靠性，同时也可以降低企业运维、资源成本。但由于Impala并发能力有限（当然在Impala4.0开始引入多线程，并发处理能力提升不少），爱番番的私域服务目前还是以Saas服务为重，想在Saas场景下做到高并发下的毫秒级数据分析，这种架构性能很难达标，所以我们在分析场景引入了分析引擎Doris。之所以选择Doris，基于 MPP 架构的 OLAP 引擎。相对于Druid、ClickHouse等开源分析引擎，Doris具有如下特点：l支持多种数据模型，包括聚合模型、Uniq模型、Duplicate模型；l支持Rollup、物化视图；l在单表、多表上的查询性能都表现很好；l支持MySQL协议，接入、学习成本低；l无需集成Hadoop生态，集群运维成本也低很多。

3.4 规则引擎调研

实时规则引擎主要用于客户分群，结合美团的规则对比，几个引擎（当然还有一些其他的URule、Easy Rules等）特点如下：

RT-CDP也是就两部分功能进行拆分，主要包含五部分：数据源、数据采集、实时数仓，数据应用和公共组件，除公共组件部分是横向支撑外，其他四部分就是标准的数据对接到数据应用的四个阶段：

• 数据源：这里的数据源不仅包含客户私有数据，也包括在各个生态上的自有媒体数据，比如微信公众号、微信小程序、企微线索、百度小程序、抖音企业号、第三方生态行为数据等。
• 数据采集：大多中小企业没有研发能力或者很薄弱，如何帮助快速将自有系统对接到爱番番RT-CDP是这层需要重点考虑的，为此我们封装了通用的采集SDK来简化企业的数据采集成本，并且兼容uni-app等优秀前端开发框架。另外，由于数据源多种多样、数据结构不一，为了简化不断接入的新数据源，我们建设了统一的采集服务，负责管理不断新增的数据通道，以及数据加解密、清洗、数据转换等数据加工，这个服务主要是为了提供灵活的数据接入能力，来降低数据对接成本。
• 实时算存：在采集到数据后就是进行跨渠道数据身份识别，然后转换成结构化的客户统一画像。就数据管理来说，这层也包含企业接入到CDP中的碎片客户数据，为了后续企业客户分析。经过这层处理，会形成跨渠道的客户身份关系图、统一画像，然后再通过统一视图为上层数据接口。另外，就是数仓常规的数据质量、资源管理、作业管理、数据安全等功能。
• 数据应用：这层主要是为企业提供客户管理、分析洞察等产品功能，比如丰富的潜客画像、规则自由组合的客户分群和灵活的客户分析等。也提供了多种数据输出方式，方便各个其他系统使用。
• 公共组件：RT-CDP服务依托爱番番先进的基础设施，基于云原生理念管理服务，也借助爱番番强大的日志平台、链路追踪进行服务运维、监控。另外，也基于完备的CICD能力进行CDP能力的快速迭代，从开发到部署都是在敏捷机制下，持续集成、持续交付。

4.2 核心模块

简单来说，RT-CDP实现的功能就是多渠道数据的实时、定时采集，然后经过数据中身份的识别Identity服务，再进行数据处理、数据进行数据映射、加工（比如维度Join、数据聚合、数据分层等），然后进行结构化持久化，最后对外实时输出。

在上图所示，爱番番RT-CDP在进行行业抽象后，已经内置了很多行业通用的Schema，包括常见的Identity、Profile、Behavior等多类Schema。在爱番番RT-CDP管理的统一潜客画像中，Identity、Profile、Tag、Segment等都业务聚合根。为了支持好B、C两种数据模型还有一些B粒度聚合根存在。

Schema如何简化数据接入/strong>

这里需要先说一个Dataset的概念。Dataset是通过Schema定义结构的一个数据集，企业对不同的数据源定义成不同的数据集。在数据源管理时，企业可以根据不同的数据集结构化导入的数据，一个数据集可以对应多个数据源，也可以对应一个数据源中的一类数据，一般后者使用较多。另外，一个数据集也可以包含多批次的数据，也就是企业可以周期性的按批次导入同一数据集数据。在数据接入时，如下图，针对不同的Dataset，企业可以绑定不同的Schema，每个Schema可以引用、复用其他子Schema，然后经过RT-CDP的Schema解析，自动将数据持久化到存储引擎，根据数据的定义不同，会持久化到不同数据表中。对应实时的客户行为也是通过定义不同的Schema来定义数据结构，然后进行持续的数据接入。

为此，我们设计了支持B2B2C、B2C两种业务的身份关系模型。在标准化租户数据接入后，基于不断接入的数据新增持续的身份关系图谱裂变。在功能层面，我们支持自定义身份类型以及身份权重，也支持针对不同身份租户自定义身份融合动作。另外，根据我们对行业分析，内置了常见的身份及融合策略，方便租户直接使用。

4.3.3 实时存算

4.3.3.1 流计算

爱番番RT-CDP核心能力都是依托Apache Flink+Kafka实现。在实时流之上进行的流计算，做到毫秒的数据延迟。

扩展1：基于数据分层增强存储

为什么需要分层/strong>

完全基于Kudu存储数据的话，一方面成本较高（Kudu集群都要基于SSD盘搭建才能有比较好的性能表现）；另一方面在营销场景下更关注短时间段（比如近一个月、三个月、半年等）客户的实时行为变化，对于时间较久的历史数据使用频次很低。

分层机制

综合考量，也从节约资源成本角度，我们选择Parquet做为扩展存储，针对存储符合时间序列的海量数据做冷热分层存储。

根据数据使用频率，我们将数据分为热、温、冷三层。热数据，表示租户经常使用的数据，时间范围为三个月内；温数据，表示使用频率较低的数据，一般只用于个别客群的圈选，时间范围为三个月外到一年；冷数据，租户基本不使用的数据，时间范围为一年之外。为了平衡性能，我们将热、温数据存放在同一个集群，将冷数据放在另外集群（和提供给策略模型的集群放在一个集群）。

具体方案：

• 在热、温、冷之上建立统一视图，上层根据视图进行数据查询。
• 然后每天定时进行热到温、温到冷的顺序性的分别离线迁移，在分别迁移后会分别进行视图的实时更新。

扩展2：基于潜客融合路径的映射关系管理解决数据迁移问题

为什么需要管理映射/strong>

潜客画像行为数据很多，也可能存在频繁融合的情况，如果在潜客融合时，每次都迁移数据，一方面数据迁移成本很高，另一方面，当潜客行为涉及温冷数据时，是无法进行删除操作的。业内针对类似情况，更多会有所取舍，比如只迁移用户仅一段时间的热数据，再往前的历史不做处理。这种解决方案并不理想。

映射管理机制

为此，我们换了种思路，通过维护潜客融合路径的方式方式解决该问题。

具体方案：

• 新增一张潜客融合关系表（user_change_rela）维护映射关系；
• 在融合关系表和时序表（比如event）之上创建视图，做到对业务层透明。

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强大的分布式计算能力和状态管理能力驱动实时规则引擎计算。上面已经说了流数据理念，这里结合一条潜客行为进来到实时规则判断来更直观说明数据在流中的实时填充，如下图：数据进来之后，先经过Identity Service补充身份Ids，在经过数据Job补充潜客对应的属性信息，最后基于一个完整的潜客数据进行实时规则判断，最后将负责规则的潜客落入Segment表。

我们的集群主要分为四类节点：Master、Core、Task、Client。具体如上图。

• Master节点：集群管理节点，部署 NameNode、ResourceManager等进程，并且做到组件故障时的自动迁移；
• Core节点：计算及数据存储节点，部署 DataNode、NodeManager等进程；
• Task节点：计算节点，用来补充core节点的算力，部署 NodeManger等进程，该节点一般不用来存储数据，支持按需动态扩容和缩容操作；
• Client节点：独立的集群管控节点及作业提交节点。

4.3.5.2 全链监控

RT-CDP在建设了完整的链路监控能力，能够实时发现集群、数据流问题，方便及时干预、处理，为租户提供更好的数据服务能力提供保证。也建设了全链的日志收集、分析能力，极大简化了服务问题排查成本。

5.3 架构先进

目前我们完成RT-CDP1.0的建设，并且在一些核心指标上都取得了不错的效果：

5.3.1 实时高吞吐

• Identity Service做到数十万QPS的关系查询，支持上万TPS的身份裂变。
• 实时计算做到了数十万TPS的实时处理、实时持久化，做到毫秒级延迟。
• 支持企业海量数据、高并发下毫秒级实时分析。
• 真正基于实时流数据实现规则判断，支撑了私域打标、实时规则判断、圈群等多个实时业务场景，让营销毫秒触达。

5.3.2 高扩展性

平台架构存算分离，可水平扩展：

• 基于云原生+Nebula搭建了，可动态伸缩的图存储集群；
• 借助百度云原生CCE、BMR等云上能力，搭建了存算分离的弹性伸缩的存算集群；
• 计算集群动态伸缩，节约企业资源成本。

5.3.3 高稳定性

各个模块、各个集群稳定性指标长期维持在99.99%以上。

六、未来展望

1.【业务层面】更多贴近行业的中台能力

• 平台目前在业务支撑上已经具备了比较好的定义能力。下一步将结合重点服务的企业行业，内置更多行业业务对象，进一步简化企业数据接入成本。
• 在B2B2C数据模型上做更多业务尝试，更好服务ToB企业。

2.【业务层面】更丰富的AI模型

• RT-CDP已经为企业提供了智能化的潜客评分能力，支持企业灵活定义评分规则。在AI时代，我们将继续来源：百度Geek说