百度爱番番业务部团队技术负责人李新建演讲分享

本文整理自百度爱番番业务部团队技术负责人李改建在QCon2022广州站的演说分享，主题为“百度爱番番RT-CDP构架实践”。

随着公域流量红利退去，企业格外重视私域精细化营运、营销。越来越多的企业还要基于CDP解决数据荒岛问题，帮助其更快的控温线索、促活顾客。但对于中小企业来说，在搭建强悍平台能力的同时，怎么合理化资源，最大程度减少资源费用只是一个重要课题。本次分享既有先进构架的整体介绍，还有在资效方面上的设计权衡，来最大化的帮助企业降本增效。

以下为演说实录。

我叫李改建，现今在百度工作已有七八年。我这次分享的主题是关于百度爱番番的实时CDP实践。我之前写过一篇关于这个CDP构架的文章，包括一些选型和设计实践。这次分享是为了贴合资效平衡这个主题，由于我们在这个构架的过程中有几个核心指标和主题紧密相关，因此我也出席了此次的大会。还要说明的是，这个PPT是半年前制做的，在制做过程中因为多次调整大会时间，PPT没有同步迭代。另外，牵涉业务变更的内容也没有更新到最新状态，但我觉得其中的这些技巧论、思想和目标在当前依然适用，所以我想分享给你们，让你们了解当初我们是怎样做的。

我之前写的一篇文章，早已公布并遭到了不少关注。此次的PPT缺乏一些前期背景和业务问题的具体说明，所以或许会更难理解。假如有问题，可以在最后一页的“彩蛋”中找我交流。

上次分享主要囊括几个大块，其中最重要的是介绍资效平衡实践在构架中的应用。

业务背景

简略介绍一下我们的业务和整体的价值。我们主要是在营销领域举行业务，主要服务于广告主。随着互联网的发展，公域流量的下降早已渐趋饱和，中小企业获取顾客的费用越来越高，但是未能制订紧贴顾客的营销方案，以获取更高的顾客转换率。为此，我们开始针对私域进行建设，以满足顾客的需求。对于百度来说，公私域的业务都很重要。

当初，整个营销环境的主要问题是广告费用和缺少创新的营销方案，并且顾客的需求变化十分快速。曾经，只要提供了一个产品或服务，顾客基本上就能很快地接受它，但是它们的需求变化不会太大，门坎要求也不是很高。虽然目前，因为信息量越来越大，顾客对自己的看法，包括对企业和顾客的看法变化得十分快。顾客对数据和信息变化的时效要求也越来越高。

基于多方面的需求，爱番番提供了完整的营销解决方案。这包括公共和私人领域的服务，其中包括百度的广告业务，后续的顾客转换链路以及维护环节。通过与百度的整体业务对接，产生了一个强悍的闭环系统。我今天分享的主要是关于私领域营销的内容。我们的实时CDP是与私域营销密切合作的。这包括数据剖析和整个数据链的串联，确保数据的及时性。

关于CDP，我们还要考虑两个方面。第一个方面是要确定业务的本质，而第二个方面则是须要了解标准CDP所须要满足的要求和特点。在业务层面，我们可以通过一张简图来了解我们在私域场景下为顾客和企业提供的标准能力是什么。由于我们面向多住户，因此须要在数据模型上支持ToB和ToC。例如，假若一个企业是ToB企业，我们还要管理企业和顾客数据，他们是单层的关系。其实，在国外大多数CDP场景下，ToB数据模型基本上没有得到挺好的建设，而常常是以ToC为方向来打平数据。这只是我们面临的挑战之一。

另外，我们还须要考虑多渠道营销。怎么博得营销？首先，我们提供了灵活的数据配置化画笔能力。例如，一个企业想要怎么向顾客进行营销，顾客通过访问其官网、H5或其他渠道的媒体信息，企业还要了解顾客在不同媒体之间的整体访问轨迹，于是提供灵活的触达，包括活动信息和降价券等。第三个是解决方案的链路还要多元化，由于无论是涨粉、推广还是直播，其业务需求的链路都不一样。详细的业务场景或许须要格外深入地讨论。

CDP特性

下边介绍下CDP，这是我想着重想分享几个关键点之一。首先，CDP的标准定义是何种？CDP在2013年就早已被提出来了，包括其官方定义和分类。虽然在国外，这些公司依然将其称为MA、数据洞察，并推出了太多不同的产品。并且包括我们自己的团队在做这个东西的时侯，对于CDP的理解和标准也存在巨大的差距。

假如你对CDP感兴趣，这么这一页是必需要了解的。基本上，所有现今提及的营销链路的东西都是CDP的范畴。因此，CDP对应的能力集不同，所以须要考虑业务剖析和技术指标，列举我们要做的CDP应当是何种样子的。有两个主要的细节：一是灵活支持ToB和ToC两类模型，即私有布署和适应多种业务场景；二是统一画像的储存；三是实时的多渠道打通，以保证跨渠道数据的实时同步读写。之外，考虑时效性，即跨渠道数据打通的实时性和海量数据下的实时性。为了满足某些要求，我们进行了这些调优，包括整条链的，服务链的，数据层面的和混部等。

整体构架

我们的构架指标归纳为四个：多住户，高功耗，低费用和实时。这四个指标之间存在一些互相冲突，须要考量，我们花了巨大的力气去实现。

我们先了解整体的数据流向，从多元数据对接到采集、处理和输出。这个逻辑构架图中最重要的部份是白色的三个块，很多部份还要结合详细的具体设计和资效平衡来了解。关注这三个部份对应的位置、功能和还要解决的问题是很重要的。其实其他块诸如实时数据处理和统一储存也进行了费用优化和控制，但这三个块是更典型的。因而首先讨论这三个块。

在下边这个图中重点想介绍下公共组件与云原生的结合。我们部委是百度内部比较早将功能服务、微服务和数据服务全都拉到K8S生态下的部委之一。CDP平台牵涉了许多组件选型和与K8S结合的问题。我们在做这个图服务的时侯也遇见了巨大的问题。从迁移到Graph的过程中也踩了这些的坑。

构架/资效均衡实践

自定义模型

现在的重点是讨论三个问题：、实时的IDM和实时的规则引擎。这三个对应的问题比较典型，的关键词是增加费用和提升效率，IDM是资源均衡和功耗优化，规则引擎是极至功耗和弹性伸缩。在中，我们还要将中小企业的数据用很低费用地接过来，这对于不同的企业来说是十分重要的。但是其他的数据平台就会考虑这个问题，但这个问题的复杂程度并不小。

首先，我们面临的是业务问题，即怎样更快地将各类企业、各种维度的数据接入我们的CDP平台。为了解决这个问题，我们先进行了一层具象，将数据转化为CDP平台中群组的标准数据。我们将这种数据具象为三类业务实体，其中两大类是身分信息和行为轨迹，包括属性信息、时序信息和数据变化记录。之后，我们在这个业务具象的基础上又做了一层外置的标准，这个针对特定行业的结构化数据，外置了标准数组，例如企业信息、企业地址和企业名称等。

在营销场景下，例如陌陌场景和直播场景，我们对各个场景的标准数组进行具象外置，并进行简化，以增加效率。稍为配置一下就可以在几分钟内完成数据导出，而原先或许还要一十天。

在我们做这个具象以后，将其转化为一个简略的模型，这个模型可以处理多个实体之间的1对n的关系，以及一个实体原本的1对n的关系，可以复制承继并在多机上使用，最终将其转化为一个结构化的JSON，带有一些业务含意。当企业使用时，我们将其原始数据攻入我们的库中。企业在扩充时，主要是通过子进行扩充，最后统一储存。至于其他模块牵涉到业务分拆，不再细说。

对于，我们面临两个问题。首先是多住户的支持，怎样统一储存而不会造成建表量非常多？第二个问题是，假如表量不多，怎么储存很多数组？对于第一个问题，我们还要保证建表量不会过多，以减少维护费用。对于第二个问题，假若选用大宽表的形式进行储存，但是在数据剖析时或许会有一个聚合的大宽表，但对于多住户的状况，数据会特别离散，这对于查询费用来说是不实惠的。因而，在数据处理方面，我们通过对原始数据结构的映射，将无业务概念的数据数组具象为数值型、字符型等几类，下层通过进行查询和SQL转化。有了这一制度，我们只需在企业的数组数目少于外置数组限制时才须要干预，添加几个外置数组并手动进行映射转化。在我们底层统一储存使用的Kudu，数组数目官方建议有几百个限制。

万级QPS实时IDM

我们也在功耗和实时QPS调优方面作出了一定的努力。其实我们在万级QPS的场景下进行了检测，但这还要在3-6个pod的状况下进行，且储存是读写分离的，包含3个储存节点和3个查询节点。考虑到数据处理过程是基于图结构且深度为4，我们才能处理几万QBS的数据量级，这阐明它具有了很强的功耗。

从模型的视角来看，IDM就是ID的关联，在我们的场景中代表着顾客从官网访问后，在陌陌上登陆小程序后还要进行关联。当访问官网时，怎样营销和触达顾客是一个重要的问题。官网的数据一般只有临时数据，如ID，且他们是设备细度的。陌陌授权或许使用的是百度的，这种数据是花絮化的。解决这个问题的关键是怎样将顾客数据打通，并在多个渠道上进行营销。这一般牵涉到在不同媒体上公布的数据，并使用图的方法来处理这种数据。

大多数企业一般倾向于使用结构化的数据表进行离线估算，以荣获历史关系数据。与这些步骤的差别在于，我们的关系是实时打通的，这是由于假如不实时打通顾客，但是在同一个媒介下，也或许难以确定应当归属于那个人，在统一结构后来，它们会有一个CDP惟一标志。

在使用图数据库时，还要考虑使用实体属性值还是实体关系和实体结构来储存数据，由于不同的数据库的数据切分形式是不同的。在实现图数据库时，最初选用了点切分的方法，但因为数据模型下的节点类别有限，加上多住户的需求，造成数据倾斜问题严重。为解决这个问题，系统选用了边切分的方法，并使用了国外的Graph数据库进行储存。Graph相对于美国的更加成熟，且有较差的发展前景。

由于天然的图数据库拥有适宜的构架，无论是在估算储存还是底层分布式储存方面都有特点，所以它天然具有伸缩能力。在分布式系统中，有一个常见的小点适于控制Redis的伸缩，这是一个参考。

在逻辑处理方面，我们对锁和连结池进行了优化，并对查询的SQL进行了调优。我们与图数库的人合作做了太多配合，疗效显著，无论是在型号稳定性还是功耗方面，对于资源消耗都有巨大提高。

最后一个部份是IDM布署，提及布署是由于它与水平伸缩和布署模式相关，对费用和资源有天然的优势。我们对储存估算节点的布署，在混部模式、网络和负载方面以及硬盘上做了太多

优化，才达到了之前提到的疗效。

实时规则引擎（RTRE）三次变革

在实时规则引擎方面，一个问题是数据量巨大，储存的原生数据海量。另一个问题是对于多住户，实时流入的数据量也巨大，在实时IDM的前提下，每条数据都还要实现实时读写，实时关系打通并进行处理。我们进行了两三次迭代，最终达到了预期，在功耗和资源伸缩方面都有所提高。

我们的实时规则引擎主要应适于营销场景，而且还要配置对话步骤。简而言之，当顾客触发这些规则时，我们将采取相应的举措。这种规则相对复杂，比如，在企业的7天内，顾客未打电话，且之前提供了相机号码但没有提供陌陌号码；在近期的3分钟内访问过企业的H5页面等。这种条件须要进行组合，包括两组和三组条件，ANDOR关系，所以相对复杂。再者，即便步骤配置完成，我们希望还能实时触发，即在一条数据抵达后的微秒级别内进行响应和触达。虽然规则试验是相似的，但在时效性和数据量方面却有所不同。

接下去介绍一个关键点，就是数据查询中是主动还是被动的。传统的数据平台会在设计一堆规则后来，通过查询句子来搜索海量数据。而我们的思路是数据主动查询，在数据流的关键阶段进行重要数据的补充，以确保在进行规则判定时有足够的数据，并进行结果处理。之外，现在也有一些流式数据库，只是极其重要的方向和思路。

在实现这个引擎时，我们持续迭代了实现模式。第一版实现比较粗糙，基于Flink进行实现，还要健全许多Flink的job，并使用FlinkSQL进行编撰。但我们那时遇见的问题是窗口风暴，这意味着处理每分钟数据与近一分钟数据的试验处理方法不同。当滑动窗口巨大时，比如几天或几个月，使用Flink消耗资源和实现程度都面临巨大挑战和问题。Flink提供了复杂风波组合处理的标准组件，但现在它主要适用于固定窗口和小滑动窗口场景，诸如实时监控日志报案。

基于这种前提，我们再次自研了一套实时规则引擎，并进行了分拆和多样化策略以更好地与抽样SQL解读和规则引擎对接。我们还优化了片断规则的结果复用和资源控制。

在布署资源时实时分析程序考虑，我们面临多住户的状况，每位job都占用太多CPU和显存资源。对于数据高峰，我们对处理节点进行了分类，有些偏管理，有些偏数据估算和储存，也有些是纯估算。那样，当高峰过去时，我们可以迅速清除或解除纯估算节点。第二次变迁，我们在百度云的基础上升级了估算平台搭建。我们支持的伸缩策略可以分为两类：一类是固定时间段的，缺少动态性；另一类是基于指标的，这与在云原生场景下的状况十分相像。

第三次变革是迁移到云原生，由于在最初建设估算平台时，云原生链路仍未完全确立，如今有了以后，可以在多住户场景下逐步扩充资源，主要考虑顾客费用和维保方面的诱因，尤其是在线业务链路方面，长时间的响应带宽是不可接受的。在云原生上，我们就能实现的主要是集群力度和服务力度的伸缩，以及通过虚拟化场景下的预pod管理来提高pod启动带宽。如右图，通过AP、CA、HPA三个圈来代表那些方面。

在这三类前提下，我们将所有的Flink作业迁移到云上。在云上，我们依照官方实践，将Flink作业运行在高可用机制下。目前实时分析程序考虑，我们的几百个作业可以通过几个地理机承载，使得才能挺好地进行伸缩。我们可以将这种资源与其他业务的pod进行整体的复用和资源均衡，并且估算集群所占用的资源十分少。

小结与展望

右图整理了平台才能实现的能力和后来想要实现的一些功能。我们的CDP平台是一个数据平台，主要关注流批一体的数据处理。因此，与智能湖仓相比，我们也有巨大的差异，这是我们未来想要探求的方向。

以上是我们平台的一些内容，假若您有任何问题，随时可以联系我们进行交流。感谢！