CRM、DMP、CDP三个平台核心作用不同，但纵向来对比，更容易理解CDP。三者之间在数据属性、数据存储、数据用途等方面都较大差异。
有几个关键区别如下：
1.CRMvsCDP
2.DMPvsCDP
2013年MarTech分析师DavidRaab首次提出CDP这个概念，后来其发起的CDPInstitute给出权威定义：packagedsoftwarethatcreatesapersistent,unifiedcustomerdatabasethatisaccessibletoothersystems。
这里面主要包含三个层面：
CDP本身的C（Customer）是指allcustomer-relatedfunctions,notjustmarketing。面向不同场景也对应不同类型的CDP，不同类别的CDP主要是功能范围不同，但是类别之间是递进关系。
主要分为四类：
CampaignCDPs、DeliveryCDPs两类较AnalyticsCDPs多出的功能，在国内更贴近MA（MarketingAutomation，营销自动化）。本文所讲的CDP从提供的功能范围来说，属于AnalyticsCDPs。在爱番番也有专门的MA系统，本文的CDP为其提供数据支撑。
随着营销3.0时代的到来，以爱番番私域产品来说，主要是借助强大的CDP为企业提供线上、线下数据的打通管理的同时，企业可以使用精细化的客户分群，进行多场景的增育活动（比如自动化营销的手段，节假日促销通知，生日祝福短信，直播活动等等）。更重要的是，企业可以基于纯实时的用户行为进行更加个性、准确、及时的二次实时营销，帮助企业加温线索、促活客户，提升私域营销转化效果。那如何做好实时CDP（Real-TimeCDP，缩写为RT-CDP）驱动上层营销业务，面临诸多挑战。
【业务层面】
1.企业数据渠道多，数据形态各异
2.不同生态无法打通，无法360度洞察用户
数据分散导致难以识别唯一用户身份，无法建立全面且持续更新的用户画像，导致对用户的认知碎片化片面化，洞察不足。比如在实际营销场景下，企业期望对同时访问官网和其小程序的同一用户发放优惠券促活时，但因为一个人的行为以不同标识分散在各渠道数据中，无法进行跨渠道用户行为分析，也就无法实现企业诉求。
3.人群划分规则复杂
我们不同企业的业务是不同的，所以我们可以根据业务特点，为不同的客户打上个性化的标签，比如企业进行营销活动时，想给经过迭代旅程节点的用户、参与某个直播等等的打上不同场景的标签，这样才能对不同的人群进行细分，做更精细化的营销。
4.如何用一个平台服务好B2B2C、B2C两类企业，行业可借鉴经验少
爱番番的客户涉及多类行业，有的B2C的也有B2B2C的。相对与B2C，B2B2C的业务场景复杂度是指数级上升。在管理好B、C画像的同时，还要兼顾上层服务的逻辑里，比如身份融合策略、基于行为的圈选等。另外，在许多业务场景也存在很多业务边界不清晰的问题。
【技术层面】
1.全渠道实时精准识别要求高
当今时代一个客户行为跨源跨设备跨媒体，行为轨迹碎片化严重。如果企业想营销效果好，精准、实时识别客户、串联客户行为轨迹是重要前提。那如何在多源多身份中做到高性能的实时识别也是个很大挑战。
2.需要具有实时、低延迟处理海量数据的能力
现在客户可选择性多，意向度不明确，基于客户行为实时营销，以及基于客户反馈的实时二次交互是提高营销效果的关键，比如企业营销部门群发一个活动短信，客户点没点，点了有什么样进一步的动作，代表着客户不同的意向程度，企业营销、销售人员需要根据客户动作进行及时进一步的跟进。只有实时把握这些变化，才能更高效地促进营销活动的转化。如何实时处理海量数据驱动业务？
3.需要可扩展的架构
在多租户背景下，爱番番管理数千、万中小企业的海量数据。随着服务企业数量的不断增加，如何快速不断提升平台的服务能力，需要设计一个先进的技术架构。另外，如何做到高性能、低延迟、可伸缩、高容错，也是很大的技术挑战。
4.多租户特性、性能如何兼顾
爱番番私域产品是以Saas服务形式服务于中小企业，那一个具备多租户特性的CDP是一个基本能力。虽然中小企业客户一般十万、百万量级不等，但随着企业进行的营销活动的累增，企业的数据体量也会线性增长。对于中大企业来说，其客户量级决定了其数据体量增长速度更快。另外，不同企业对于数据查询的维度各异很难做模型预热。在此前提下，如何兼顾可扩展性、服务性能是个难题。
5.多样部署扩展性
CDP目前主要以Saas服务服务于中小企业，但不排除后续支持大客户OP部署（On-Premise，本地化部署）的需求，如何做好组件选型支持两类服务方式？
经过分析和业务抽象，我们觉得，一个真正好的RT-CDP需要做到如下几个关键特征：
明确平台业务目标的同时，一个先进的技术架构也是平台建设的目标。如何做到平台架构，我们有如下几个核心目标：
1.流数据驱动
在传统数据库、数据处理上，还主要是『数据被动，查询主动』。数据在数据库中处于静止状态，直到用户发出查询请求。即使数据发生变化，也必须用户主动重新发出相同的查询以获得更新的结果。但现在数据量越来越大、数据变化及时感知要求越来越高，这种方法已无法满足我们与数据交互的整个范式。
现在系统架构设计如下图，更倾向于主动驱动其他系统的架构，比如领域事件驱动业务。数据处理亦是需要如此：『数据主动、查询被动』。
举个例子，企业想找到访问过企业小程序的用户进行发短信时，两种分别如何做？
2.流计算处理
传统的数据处理更多是离线计算、批量计算。离线计算就是Dataatrest，Queryinmotion；批量计算是将数据积累到一定程度，再基于特定逻辑进行加工处理。虽然两者在数据处理数据方式也有所不同，但是从根本上来说都是批量处理，天然也就有了延迟了。
流式计算则是彻底去掉批的概念，对流数据实时处理。也就是针对无界的、动态的数据进行持续计算，可以做到毫秒级延迟。在海量数据时代竞争激烈的今天，对企业洞察来说尤为如此，越快挖掘的数据业务价值越高。
3.一体化实践
【批流一体】
在大数据处理领域，存在两个典型的架构（Lamda、Kappa、Kappa+）。Lamda架构就是批计算、实时计算走两套计算架构，导致有时候有的相同逻辑开发两套代码，容易出现数据指标不一致，也带来了维护困难。Kappa、Kappa+架构是旨在简化分布式计算架构，以实时事件处理架构为核心兼顾批流两种场景。在大多数企业实际生产架构中还是两者混合较多，因为彻底的实时架构存在很多难点，比如数据存储、某些批计算更易处理的大窗口聚合计算等。
【统一编程】
在实际业务场景中，批、流处理依然是同时存在的。考虑到随着分布式数据处理计算发展，分布式处理框架也会推陈出新，虽然ApacheFlink在批流一体支持上很活跃，但还不太成熟。另外，在各个公司多个计算框架并用的情况还是普遍存在。所以统一数据处理编程范式是一个重要的编程选择，可以提高编程灵活性，做到支持批、流场景数据处理作业开发，做到一套处理程序可以执行在任意的计算框架上，这样也利于后续平台切换更优秀的计算引擎。
4.可扩展为前提
这里主要是指架构的扩展性，一个具有扩展性的架构可以在稳定服务业务的同时合理控制资源成本，才能可持续支撑业务的快速发展。
【算存分离】
在如今海量数据的大数据时代，在不同场景下有时仅需要高处理能力，有时仅需要海量数据存储。传统存算一体架构，如果要满足两种场景，就需要高配置（多核、多内存、高性能本地盘等）服务节点，显然存在资源利用不合理，也会引发集群稳定性问题，比如节点过多导致数据分散，引发数据一致性降低等。算存分离的架构才符合分布式架构的思想，针对业务场景进行计算资源、存储资源的分别控制，实现资源合理分配。也利于集群数据一致性、可靠性、扩展性、稳定性等方面的能力保证。
【动态伸缩】
没有万能的框架，只有合适的取舍。需要结合自身业务特点和架构目标进行合理选型。结合RT-CDP建设目标，我们做了如下几个核心场景的组件调研、确定。
在CDP中跨渠道身份打通（IDMapping）是数据流渠道业务的核心，需要做到数据一致、实时、高性能。
传统的idmapping是怎么做？
1.使用关系型数据库存储身份关系一般是将身份关系存成多表、多行进行管理。该方案存在两个问题：
2.使用SparkGraphX进行定时计算一般是将用户行为存入Graph或者Hive，使用Spark定时将用户行为中身份信息一次性加载到内存，然后使用GraphX根据交叉关系进行用户连通性计算。该方案也存在两个问题：
我们怎么做？
随着近几年图技术的发展，基于图解决业务问题的案例越来越多，开源图框架的产品能力、生态集成越来越完善，社区活跃度也越来越高。所以我们尝鲜基于图进行身份关系建模，借助图自然的多度查询能力进行实时身份判断、融合。
图框架对比
网上对DGraph和Nebula对比很少，这里简单说一下区别：
对于主流计算框架的对比，比如ApacheFlink、Blink、SparkStreaming、Storm，网上有很多资料，大家也请自行调研就好，比如如下，详见链接：
选择ApacheFlink做为流批计算引擎
使用广泛的Spark还是以微批的方式进行流计算。而Flink是流的方式。ApacheFlink是近几年发展很快的一个用于分布式流、批处理数据处理的开源平台。它是最贴合DataFlow模型实现的分布式计算框架。基于流计算进行高性能计算，具有良好的容错、状态管理机制和高可用能力；其他组件于Flink的集成也越来越多、也日趋成熟；所以选择我们ApacheFlink做为我们的流批计算引擎。
选择ApacheBeam做为编程框架
分布式数据处理技术不断发展，优秀的分布式数据处理框架也会层出不穷。ApacheBeam是Google在2016年贡献给Apache基金会的孵化项目，它的目标是统一批处理和流处理的编程范式，做到企业开发的数据处理程序可以执行在任意的分布式计算引擎上。Beam在统一编程范式的同时也提供了强大的扩展能力，对新版本计算框架的支持也很及时。所以我们选择ApacheBeam做为我们的编程框架。
在Hadoop生态系统存储组件中，一般用HDFS支持高吞吐的批处理场景、用HBase支持低延迟，有随机读写需求的场景，但很难只使用一种组件来做到这两方面能力。另外，如何做到流式计算下的数据实时更新，也影响存储组件的选择。ApacheKudu是Cloudera开源的列式存储引擎，是一种典型的HTAP(在线事务处理/在线分析处理混合模式)。在探索HTAP的方向上，TiDB、Oceanbase均在此行列，只是大家起初侧重的场景不同而已，大家也可以对比一下。ApacheKudu的愿景是fastanalyticsonfastandchangingdata。从ApacheKudu的定位，如下图可见一斑：
结合我们的平台建设理念，实时、高吞吐的数据存储、更新是核心目标，在数据复杂查询、数据应用的QPS上不高（因为核心的业务场景是基于实时流的实时客户处理），再加上ClouderaImpala无缝集成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生态，集群运维成本也低很多。
实时规则引擎主要用于客户分群，结合美团的规则对比，几个引擎（当然还有一些其他的URule、EasyRules等）特点如下：
在爱番番私域产品中，主要分为两部分：RT-CDP和MA，两者叠加近似等同于DeliverCDP所包含的功能范围。本文所讲的RT-CDP所包含的功能范围等同于AnalyticsCDPs，简单来讲，主要就是客户数据管理、数据分析洞察。
RT-CDP也是就两部分功能进行拆分，主要包含五部分：数据源、数据采集、实时数仓，数据应用和公共组件，除公共组件部分是横向支撑外，其他四部分就是标准的数据对接到数据应用的四个阶段：
简单来说，RT-CDP实现的功能就是多渠道数据的实时、定时采集，然后经过数据中身份的识别Identity服务，再进行数据处理、数据进行数据映射、加工（比如维度Join、数据聚合、数据分层等），然后进行结构化持久化，最后对外实时输出。
RT-CDP主要划分为六大模块：采集服务、Connectors、IdentityService、实时计算、统一画像和实时规则引擎。上图就是从数据交互形式和数据流向的角度描绘了RT-CDP核心模块之间的交互。从左到右是数据的主流向，代表了数据进入平台到数据输出到和平台交互的外部系统；中间上侧是实时计算和IdentityService、实时规则引擎和统一画像的双向数据交互。
下面结合数据处理阶段进行各个核心模块的功能说明：
从数据源和RT-CDP数据交互方式上，主要分为实时流入和批次拉取。针对两种场景，我们抽象了两个模块：实时采集服务和Connectors。
2.数据处理
3.数据输出
数据输出已经支持多种方式，包括OpenAPI、Webhook、消息订阅等。一方面，也方便企业获取CDP融合后的潜客的实时行为，然后与自有的下游业务系统进行用户全链管理。另一方面为上层的MA提供实时行为流驱动营销环路。这里特殊说明说明一下，MA的旅程节点中也需要很多实时规则判断，判断口径多样，有些在节点上做内存实现困难，所以RT-CDP也实现了可以为MA提供实时判断结果的数据输出。
为什么需要Schema？
前面提到企业的多个渠道的数据特征结构各异。再加上不同租户业务特点不同，企业需要数据自定义的扩展性。RT-CDP为了两类问题需要具备数据结构灵活定义的能力来对接企业数据。
另外，RT-CDP本身管理两类数据：碎片化客户数据和用户统一画像。对于前者来说，不需要关系数据内容本身，利用数据湖等技术即可为企业提供数据存储、查询、分析能力，是偏Schemaless的数据管理；对于后者来说，更多需要按不同维度组合查询、圈群、分析，本身需要结构化的数据管理。后者能否通过Schemaless的方式提供服务呢？罗列增删改查的场景，反证一下局限明显。
Schema是什么？
Schema是一个数据结构的描述，Schema可以相互引用，可以对数据中字段以及字段类型、值进行约束，也可以自定义字段。企业可以用一个统一的规范快速接入、灵活管理自己的数据，比如企业可以根据自己的行业特性，抽象不同的业务实体、属性，再给不同的业务实体定义不同的Schema。企业可以对业务实体有交集的信息抽离新Schema，然后多个Schema引用这个新Schema；也可以对每个Schema自定义自己的业务字段。企业只需要按相应的Schema结构接入数据，就可以按特定的标准使用这些数据。
从这几个实体来说明Schema的特点，如下图：
在上图所示，爱番番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来定义数据结构，然后进行持续的数据接入。
爱番番RT-CDP是一个支持多租户的平台，但在多租户下，每个企业都有自己的业务数据，一般中小企业可能有几百上千个潜客的数据字段，对于KA字段量更多。CDP做为Saas服务，如何在一个模型中支持如此多的字段存储、分析。一般可以无限扩列的引擎可以直接按租户+字段的方式打平。为了进行结构化实时存储，爱番番CDP选择了Kudu，Kudu官方建议单表不超过300列，最多也就支持上千列，那刚才的方式无法解决。
我们的解决方案是什么？
我们在租户隔离的前提下，采用字段复用的方式解决该问题。在介绍Schema模型时图里也有体现，在实际的Profile、Event表里都是attr字段。关键点就是：
为此，我们设计了支持B2B2C、B2C两种业务的身份关系模型。在标准化租户数据接入后，基于不断接入的数据新增持续的身份关系图谱裂变。在功能层面，我们支持自定义身份类型以及身份权重，也支持针对不同身份租户自定义身份融合动作。另外，根据我们对行业分析，内置了常见的身份及融合策略，方便租户直接使用。
从架构层面，IdentityService（IDMapping）基于云原生+NebulaGraph搭建，做到了租户数据隔离、实时读写、高性能读写以及水平扩缩容。
1.云原生+NebulaGraph
将NebulaGraph部署到K8s下，降低运维成本。我们主要是：
2.优化读写
IdentityService整体来说是一个读多写少的常见，但在新租户、拉新场景场景也都需要很高的写能力，读写性能需要兼顾。需要在做好并发锁的前提下优化读写：
针对一个人多设备场景，单设备被多人使用的场景，我们采用离线矫正的方式进行打通。
爱番番RT-CDP核心能力都是依托ApacheFlink+Kafka实现。在实时流之上进行的流计算，做到毫秒的数据延迟。
核心数据流如上图，简化后主要包含如下几部分：
为什么要做路由？
爱番番RT-CDP做为基础数据平台，不仅服务于百度之外的租户，也服务于百度内部甚至爱番番自己；不仅服务于中小企业，也服务于中大企业。对于前者，服务稳定性要求级别不同，如何避免内外部之间服务能力不相互影响？对于后者，不同规模企业潜客量不同，使用RT-CDP圈人群等耗时的资源也不同，如何避免资源不公平分配？
我们怎么做的？
针对上述问题，我们通过数据路由的机制解决。我们维护了一张租户和数据流Topic的映射关系，可以根据租户特性进行分流，也可以根据租户需求动态调整。然后在EntranceJob根据租户的映射关系进行数据分流，分发到不同资源配比的Job群进行分别的数据处理。做到了内外部分离，也可以根据租户个性化需求进行资源控制。
一般租户的一次营销活动，会集中产生一大批潜客行为，这其中包括系统事件、用户实时行为等，这种批量写的方式，可以有效提高吞吐。
在RT-CDP主要包括三部分的数据：碎片化的租户数据、统一的潜客画像和离线分析数据。我们主要分类两个集群进行数据存储，一个集群存储潜客统一画像和具有时序属性的热数据，另一个集群存储冷数据和用于离线计算的数据。每个集群都集成了数据湖的能力。然后我们研发了统一的QueryEngine，支持跨源、跨集群的数据查询，对底层存储引擎透明。
为什么需要分层？
分层机制
具体方案：
为什么需要管理映射？
映射管理机制
为此，我们换了种思路，通过维护潜客融合路径的方式方式解决该问题。
针对融合关系表，我们做了一定的策略优化：不维护路径上的过程关系，而是只维护路径所有过程点到终点的直接关系。这样即便在潜客融合路径涉及过多潜客时，也不会过多增加关系查询的性能。
举个例子潜客发生两次融合（affId=1001先融合到1002上，再融合到1003上）时的user_change_rela的数据变化情况，如下图：
我们选择百度开源的ApacheDoris做为数据增强的分析引擎，为爱番番拓客版提供客户洞察能力，比如旅程分析、人群、营销效果分析、裂变分析、直播分析等。
为了方便后续OP部署时可灵活去除，我们将CDP输出的数据做为增强分析的数据源，然后基于FlinkJob做逻辑处理，比如清洗、维度Join、数据打平等，最后采用ApacheDoris贡献的flink-doris-connector将数据写入Doris。
使用connector方式直接写Doris有两个好处：
Flink-doris-connector是基于Doris的StreamLoad方式实现，通过FEredirect到BE进行数据导入处理。我们实际使用flink-doris-connector时，是按10s进行一次Flush、每批次最大可提交百万行数据的配置进行写操作。对于Doris来说，单批次数据多些不flush更频繁要友好。
RoutineLoad方式
它是提交一个常驻Doris的导入任务，通过不断的订阅并消费Kafka中的JSON格式消息，将数据写入到Doris中。
从实现角度来说，是FE负责管理导入Task，Task在BE上通过StreamLoad方式进行数据导入。
StreamLoad方式
它利用流数据计算框架Flink消费Kafka的业务数据，使用StreamLoad方式，以HTTP协议向Doris写入。
从实现角度来说，这种方式是框架直接通过BE将数据同步写入Doris，写入成功后由CoordinatorBE直接返回导入状态。另外，在导入时，同一批次数据最好使用相同的label，这样同一批次数据的重复请求只会被接受一次，可以保证了At-Most-Once。
在爱番番私域产品中，灵活的圈群能力是一个重要产品能力，如何基于潜客属性、身份、客户行为等维度进行复杂、灵活规则的实时分群？此处的实时规则引擎就是为此而生。就此功能本身来说，并不新颖，在DMP中就有类似能力。很多CDP和客户管理平台都也有类似能力，但如何在多租户、海量数据情况下，做到实时、高吞吐的规则判断是一个挑战。
面临的问题是什么？
传统的实现方案主要是当租户实时或定时触发分群请求时，将规则翻译成一个复杂SQL，临时从租户的潜客数据池中进行SQL查询。另外，一般都会在潜客上做一层倒排索引，在租户少或者OP部署时，数据查询速度也尚可接受。但在基于实时流实现规则引擎需要解决如下几个问题：
实时规则引擎实现
和很多产品类似，爱番番的规则圈群也主要是两层And/Or的规则组合。结合规则的特点，我们主要分为如下图的几类规则：普通的属性运算（P1、P2）、普通身份运算（I1）、小窗口的行为判断（E1）、大窗口的行为判断（E2）和无窗口的行为判断（E3）。
为了规则灵活度和高效的数据处理能力，我们定义了一套规则解析算法。然后借助Flink强大的分布式计算能力和状态管理能力驱动实时规则引擎计算。上面已经说了流数据理念，这里结合一条潜客行为进来到实时规则判断来更直观说明数据在流中的实时填充，如下图：数据进来之后，先经过IdentityService补充身份Ids，在经过数据Job补充潜客对应的属性信息，最后基于一个完整的潜客数据进行实时规则判断，最后将负责规则的潜客落入Segment表。
爱番番RT-CDP的计算、存储集群基于百度云搭建，借助云上能力，很好实现了资源的存算分离和动态伸缩。我们可以自定义灵活的资源扩缩策略，根据消息量情况进行资源增减，做到波峰时实时加大集群规模提供计算能力，波谷时缩减集群做到及时降本。
我们的集群主要分为四类节点：Master、Core、Task、Client。具体如上图。
RT-CDP在建设了完整的链路监控能力，能够实时发现集群、数据流问题，方便及时干预、处理，为租户提供更好的数据服务能力提供保证。也建设了全链的日志收集、分析能力，极大简化了服务问题排查成本。
基于RT-CDP解决企业数据孤岛问题，帮助企业将数据资产数字化、多方化、智能化、安全化。
1.灵活的数据定义能力
RT-CDP在业务层面具备了灵活的数据定义能力，来满足企业的个性化需求：
2.服务于不同行业企业的多样营销
依托RT-CDP强大数据管理能力，爱番番营销产品已服务于法律、商务服务、教育培训、电子电工、机械设备、金融、健康美容、生活服务、房产家居、建筑建材、印刷包装、农林牧渔、物流运输、餐饮食品等数十个行业的数千家企业，帮助企业解决了很多营销难题。成功的企业案例不胜枚举。
目前我们完成RT-CDP1.0的建设，并且在一些核心指标上都取得了不错的效果：