使用广泛的Spark还是以微批的方式进行流计算。而Flink是流的方式。Apache Flink是近几年发展很快的一个用于分布式流、批处理数据处理的开源平台。它是最贴合DataFlow模型实现的分布式计算框架。基于流计算进行高性能计算，具有良好的容错、状态管理机制和高可用能力；其他组件于Flink的集成也越来越多、也日趋成熟；所以选择我们Apache Flink做为我们的流批计算引擎。
分布式数据处理技术不断发展，优秀的分布式数据处理框架也会层出不穷。Apache Beam是Google在2016年贡献给Apache基金会的孵化项目，它的目标是统一批处理和流处理的编程范式，做到企业开发的数据处理程序可以执行在任意的分布式计算引擎上。Beam在统一编程范式的同时也提供了强大的扩展能力，对新版本计算框架的支持也很及时。所以我们选择Apache Beam做为我们的编程框架。
3.3 海量存储引擎取舍
在Hadoop 生态系统存储组件中，一般用HDFS支持高吞吐的批处理场景、用HBase支持低延迟，有随机读写需求的场景，但很难只使用一种组件来做到这两方面能力。另外，如何做到流式计算下的数据实时更新，也影响存储组件的选择。
Kudu的定位，如下图可见一斑：
结合我们的平台建设理念，实时、高吞吐的数据存储、更新是核心目标，在数据复杂查询、数据应用的QPS上不高（因为核心的业务场景是基于实时流的实时客户处理），再加上Cloudera Impala无缝集成Kudu，我们最终确定Impala+Kudu做为平台的数据存储、查询引擎。
基于Impala+Kudu的选型，在支持OP部署时是完全没有问题的，因为各个企业的数据体量、数据查询QPS都有限。
这样企业只需要很简单的架构就可以支持其数据管理需求，提高了平台稳定性、可靠性，同时也可以降低企业运维、资源成本。但由于Impala并发能力有限（当然在Impala4.0开始引入多线程，并发处理能力提升不少），爱番番的私域服务目前还是以Saas服务为重，想在Saas场景下做到高并发下的毫秒级数据分析，这种架构性能很难达标，所以我们在分析场景引入了分析引擎Doris。之所以选择Doris，基于
相对于Druid、ClickHouse等开源分析引擎，Doris具有如下特点：l支持多种数据模型，包括聚合模型、Uniq模型、Duplicate模型；l支持Rollup、物化视图；l在单表、多表上的查询性能都表现很好；l支持MySQL协议，接入、学习成本低；l无需集成Hadoop生态，集群运维成本也低很多。
实时规则引擎主要用于客户分群，结合美团的规则对比，几个引擎（当然还有一些其他的URule、Easy Rules等）特点如下：
RT-CDP中客户分群规则分类、组合多，规则计算复杂、算子多，时间窗口跨度大、甚至无窗口，业内没有一个能很好满足业务需求的开源规则引擎，所以我们选择了自研。
在爱番番私域产品中，主要分为两部分：RT-CDP和MA，两者叠加近似等同于Deliver CDP所包含的功能范围。本文所讲的RT-CDP所包含的功能范围等同于Analytics CDPs，简单来讲，主要就是客户数据管理、数据分析洞察。
RT-CDP也是就两部分功能进行拆分，主要包含五部分：数据源、数据采集、实时数仓，数据应用和公共组件，除公共组件部分是横向支撑外，其他四部分就是标准的数据对接到数据应用的四个阶段：
数据源：这里的数据源不仅包含客户私有数据，也包括在各个生态上的自有媒体数据，比如微信公众号、微信小程序、企微线索、百度小程序、抖音企业号、第三方生态行为数据等。
数据采集：大多中小企业没有研发能力或者很薄弱，如何帮助快速将自有系统对接到爱番番RT-CDP是这层需要重点考虑的，为此我们封装了通用的采集SDK来简化企业的数据采集成本，并且兼容uni-app等优秀前端开发框架。另外，由于数据源多种多样、数据结构不一，为了简化不断接入的新数据源，我们建设了统一的采集服务，负责管理不断新增的数据通道，以及数据加解密、清洗、数据转换等数据加工，这个服务主要是为了提供灵活的数据接入能力，来降低数据对接成本。
实时算存：在采集到数据后就是进行跨渠道数据身份识别，然后转换成结构化的客户统一画像。就数据管理来说，这层也包含企业接入到CDP中的碎片客户数据，为了后续企业客户分析。经过这层处理，会形成跨渠道的客户身份关系图、统一画像，然后再通过统一视图为上层数据接口。另外，就是数仓常规的数据质量、资源管理、作业管理、数据安全等功能。
数据应用：这层主要是为企业提供客户管理、分析洞察等产品功能，比如丰富的潜客画像、规则自由组合的客户分群和灵活的客户分析等。也提供了多种数据输出方式，方便各个其他系统使用。
公共组件：RT-CDP服务依托爱番番先进的基础设施，基于云原生理念管理服务，也借助爱番番强大的日志平台、链路追踪进行服务运维、监控。另外，也基于完备的CICD能力进行CDP能力的快速迭代，从开发到部署都是在敏捷机制下，持续集成、持续交付。
简单来说，RT-CDP实现的功能就是多渠道数据的实时、定时采集，然后经过数据中身份的识别Identity服务，再进行数据处理、数据进行数据映射、加工（比如维度Join、数据聚合、数据分层等），然后进行结构化持久化，最后对外实时输出。
RT-CDP主要划分为六大模块：采集服务、Connectors、Identity Service、实时计算、统一画像和实时规则引擎。上图就是从数据交互形式和数据流向的角度描绘了RT-CDP核心模块之间的交互。从左到右是数据的主流向，代表了数据进入平台到数据输出到和平台交互的外部系统；中间上侧是实时计算和Identity Service、实时规则引擎和统一画像的双向数据交互。
下面结合数据处理阶段进行各个核心模块的功能说明：
从数据源和RT-CDP数据交互方式上，主要分为实时流入和批次拉取。针对两种场景，我们抽象了两个模块：实时采集服务和Connectors。
实时采集服务：该模块主要是对接企业已有的自有媒体数据源，爱番番业务系统领域事件以及爱番番合作的第三方平台。这层主要存在不同媒体平台API协议、场景化行为串联时的业务参数填充、用户事件不断增加等问题，我们在该模块抽象了数据Processor&自定义Processor Plugin等来减少新场景的人工干预。
：该模块主要是对接企业的自有业务系统的数据源，比如MySQL、Oracle、PG等业务库，这部分不需要实时接入，只需按批次定时调度即可。这里需要解决的主要是多不同数据源类型的支持，为此我们也抽象了Connector和扩展能力，以及通用的调度能力来支持。针对两种场景下，存在同一个问题：如何应对多样数据结构的数据快读快速接入？为此，我们抽象了数据定义模型（Schema），后面会详细介绍。
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提供实时规则判断，来支持圈群、基于规则的静态打标、规则标签等业务场景。
数据输出已经支持多种方式，包括OpenAPI、Webhook、消息订阅等。一方面，也方便企业获取CDP融合后的潜客的实时行为，然后与自有的下游业务系统进行用户全链管理。另一方面为上层的MA提供实时行为流驱动营销环路。这里特殊说明说明一下， MA的旅程节点中也需要很多实时规则判断，判断口径多样，有些在节点上做内存实现困难，所以RT-CDP也实现了可以为MA提供实时判断结果的数据输出。
前面提到企业的多个渠道的数据特征结构各异。再加上不同租户业务特点不同，企业需要数据自定义的扩展性。RT-CDP为了两类问题需要具备数据结构灵活定义的能力来对接企业数据。
另外，RT-CDP本身管理两类数据：碎片化客户数据和用户统一画像。对于前者来说，不需要关系数据内容本身，利用数据湖等技术即可为企业提供数据存储、查询、分析能力，是偏Schemaless的数据管理；对于后者来说，更多需要按不同维度组合查询、圈群、分析，本身需要结构化的数据管理。后者能否通过Schemaless的方式提供服务呢？罗列增删改查的场景，反证一下局限明显。
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字段。关键点就是：
事实表只做无业务含义的字段；
在数据接入、查询时通过业务字段（逻辑字段）和事实字段的映射关系进行数据转换后与前端、租户交互。
这个服务也可以称之为ID Mapping。但相对于传统的ID Mapping来说，因为业务场景的不同，功能侧重也有所不同。传统意义的ID Mapping更多是广告场景的匿名数据的，基于复杂模型的离线和预测识别；CDP中的ID Mapping是基于更精准的数据身份标识，进行更精准打通，更加要求打通率和实时性。
为此，我们设计了支持B2B2C、B2C两种业务的身份关系模型。在标准化租户数据接入后，基于不断接入的数据新增持续的身份关系图谱裂变。在功能层面，我们支持自定义身份类型以及身份权重，也支持针对不同身份租户自定义身份融合动作。另外，根据我们对行业分析，内置了常见的身份及融合策略，方便租户直接使用。
从架构层面，Identity Service（ID Mapping）基于云原生+Nebula Graph搭建，做到了租户数据隔离、实时读写、高性能读写以及水平扩缩容。
将Nebula Graph部署到K8s下，降低运维成本。我们主要是：
每个节点都是使用本地SSD盘来保证图存储服务性能。
Identity Service整体来说是一个读多写少的常见，但在新租户、拉新场景场景也都需要很高的写能力，读写性能需要兼顾。需要在做好并发锁的前提下优化读写：
设计好数据模型，尽量减少Nebula内部IO次数；
合理利用Nebula语法，避免Graphd多余内存操作；
查询上，尽量减少深度查询；更新上，控制好写粒度、降低无事务对业务的影响。
扩展1：如何解决未登录时潜客打通问题
针对一个人多设备场景，单设备被多人使用的场景，我们采用离线矫正的方式进行打通。
爱番番RT-CDP核心能力都是依托Apache Flink+Kafka实现。在实时流之上进行的流计算，做到毫秒的数据延迟。
核心数据流如上图，简化后主要包含如下几部分：
主要采集和格式化的数据，会统一发到cdp-ingest的topic；
RT-CDP有个统一的入口Job（Entrance Job）负责数据的清洗、校验、Schema解析以及身份识别等，然后根据租户属性进行数据分发。因为这是RT-CDP入口Job，需要支持横向扩缩，所以这个作业是无状态Job。
经过数据分发，会有不同的Job群进行分别的数据处理、持久化，以及数据聚合等数据加工逻辑，一方面丰富潜客画像，另一方面为更多维度的潜客圈群提供数据基础。
最后会将打通的数据分发到下游，下游包括外部系统、数据分析、实时规则引擎、策略模型等多类业务模块，以便进行更多的实时驱动。
爱番番RT-CDP做为基础数据平台，不仅服务于百度之外的租户，也服务于百度内部甚至爱番番自己；不仅服务于中小企业，也服务于中大企业。对于前者，服务稳定性要求级别不同，如何避免内外部之间服务能力不相互影响？对于后者，不同规模企业潜客量不同，使用RT-CDP圈人群等耗时的资源也不同，如何避免资源不公平分配？
针对上述问题，我们通过数据路由的机制解决。我们维护了一张租户和数据流Topic的映射关系，可以根据租户特性进行分流，也可以根据租户需求动态调整。然后在Entrance Job根据租户的映射关系进行数据分流，分发到不同资源配比的Job群进行分别的数据处理。做到了内外部分离，也可以根据租户个性化需求进行资源控制。
扩展2：自定义Trigger批量写
在随机读写上，Kudu的表现相对于HBase等还是相对差一些。为了做到数十万TPS的写能力，我们对Kudu写也做了一定逻辑优化。主要是自定义了Trigger（数量+时间窗口两种触发），在做到毫秒级延迟的前提将单条写改为一次策略的批量。
具体方案：在在批量数据满足>N条、或者时间窗口>M毫秒时，再触发写操作。
一般租户的一次营销活动，会集中产生一大批潜客行为，这其中包括系统事件、用户实时行为等，这种批量写的方式，可以有效提高吞吐。
在RT-CDP主要包括三部分的数据：碎片化的租户数据、统一的潜客画像和离线分析数据。我们主要分类两个集群进行数据存储，一个集群存储潜客统一画像和具有时序属性的热数据，另一个集群存储冷数据和用于离线计算的数据。每个集群都集成了数据湖的能力。然后我们研发了统一的Query Engine，支持跨源、跨集群的数据查询，对底层存储引擎透明。
扩展1：基于数据分层增强存储
完全基于Kudu存储数据的话，一方面成本较高（Kudu集群都要基于SSD盘搭建才能有比较好的性能表现）；另一方面在营销场景下更关注短时间段（比如近一个月、三个月、半年等）客户的实时行为变化，对于时间较久的历史数据使用频次很低。
综合考量，也从节约资源成本角度，我们选择Parquet做为扩展存储，针对存储符合时间序列的海量数据做冷热分层存储。
根据数据使用频率，我们将数据分为热、温、冷三层。热数据，表示租户经常使用的数据，时间范围为三个月内；温数据，表示使用频率较低的数据，一般只用于个别客群的圈选，时间范围为三个月外到一年；冷数据，租户基本不使用的数据，时间范围为一年之外。为了平衡性能，我们将热、温数据存放在同一个集群，将冷数据放在另外集群（和提供给策略模型的集群放在一个集群）。
在热、温、冷之上建立统一视图，上层根据视图进行数据查询。
然后每天定时进行热到温、温到冷的顺序性的分别离线迁移，在分别迁移后会分别进行视图的实时更新。
扩展2：基于潜客融合路径的映射关系管理解决数据迁移问题
潜客画像行为数据很多，也可能存在频繁融合的情况，如果在潜客融合时，每次都迁移数据，一方面数据迁移成本很高，另一方面，当潜客行为涉及温冷数据时，是无法进行删除操作的。业内针对类似情况，更多会有所取舍，比如只迁移用户仅一段时间的热数据，再往前的历史不做处理。这种解决方案并不理想。
为此，我们换了种思路，通过维护潜客融合路径的方式方式解决该问题。
新增一张潜客融合关系表（user_change_rela）维护映射关系；
在融合关系表和时序表（比如event）之上创建视图，做到对业务层透明。
针对融合关系表，我们做了一定的策略优化：不维护路径上的过程关系，而是只维护路径所有过程点到终点的直接关系。这样即便在潜客融合路径涉及过多潜客时，也不会过多增加关系查询的性能。
举个例子潜客发生两次融合（affId=1001先融合到1002上，再融合到1003上）时的user_change_rela的数据变化情况，如下图：
我们选择百度开源的Apache Doris做为数据增强的分析引擎，为爱番番拓客版提供客户洞察能力，比如旅程分析、人群、营销效果分析、裂变分析、直播分析等。
为了方便后续OP部署时可灵活去除，我们将CDP输出的数据做为增强分析的数据源，然后基于Flink Job做逻辑处理，比如清洗、维度Join、数据打平等，最后采用Apache Doris贡献的flink-doris-connector将数据写入Doris。
如果想了解更多Doris在爱番番中的实践，可以阅读『百度爱番番数据分析体系的架构与实践』。
它是提交一个常驻Doris的导入任务，通过不断的订阅并消费Kafka中的JSON格式消息，将数据写入到Doris中。
从实现角度来说，是FE负责管理导入Task，Task在BE上通过Stream Load方式进行数据导入。
从实现角度来说，这种方式是框架直接通过BE将数据同步写入Doris，写入成功后由Coordinator BE直接返回导入状态。另外，在导入时，同一批次数据最好使用相同的 label，这样同一批次数据的重复请求只会被接受一次，可以保证了At-Most-Once。
在爱番番私域产品中，灵活的圈群能力是一个重要产品能力，如何基于潜客属性、身份、客户行为等维度进行复杂、灵活规则的实时分群？此处的实时规则引擎就是为此而生。就此功能本身来说，并不新颖，在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旅程节点等各个规则相关的业务场景。
爱番番RT-CDP的计算、存储集群基于百度云搭建，借助云上能力，很好实现了资源的存算分离和动态伸缩。我们可以自定义灵活的资源扩缩策略，根据消息量情况进行资源增减，做到波峰时实时加大集群规模提供计算能力，波谷时缩减集群做到及时降本。
我们的集群主要分为四类节点：Master、Core、Task、Client。具体如上图。
Master节点：集群管理节点，部署 NameNode、ResourceManager等进程，并且做到组件故障时的自动迁移；
Task节点：计算节点，用来补充core节点的算力，部署 NodeManger等进程，该节点一般不用来存储数据，支持按需动态扩容和缩容操作；
Client节点：独立的集群管控节点及作业提交节点。
RT-CDP在建设了完整的链路监控能力，能够实时发现集群、数据流问题，方便及时干预、处理，为租户提供更好的数据服务能力提供保证。也建设了全链的日志收集、分析能力，极大简化了服务问题排查成本。
具体如上图，我们依托爱番番强大的技术服务能力完成了跨平台的日志采集&报警和全链路的延时监控：
日志采集：基于爱番番贡献给Skywalking的Satellite收集全链路服务日志，支持了K8s下微服务的日志收集，也支持了Flink Job的日志采集，做到一个日志平台，汇集全链服务日志。然后通过Grafana进行日志查询、分析；
全链路延时监控：我们也通过Skywalking Satellite采集RT-CDP全链路的数据埋点，然后通过自研的打点分析平台进行延时分析，做到全链路数据延时可视化和阈值报警。
基于RT-CDP解决企业数据孤岛问题，帮助企业将数据资产数字化、多方化、智能化、安全化。
多方化：集成一方数据，打通二方数据，利用三方数据，通过多方数据打通，实现更精准、深度的客户洞察。
数字化：通过自定义属性、标签、模型属性等将客户信息全面数字化管理。
安全化：通过数据加密、隐私计算、多方计算实现数据安全和隐私保护，保护企业数据资产。
智能化：通过智能模型不断丰富客户画像，服务更多营销场景。
1.灵活的数据定义能力
RT-CDP在业务层面具备了灵活的数据定义能力，来满足企业的个性化需求：
丰富的自定义API，用于可以自定义Schema、属性、事件等不同场景的数据上报结构；
支持了身份类型自定义，方便企业根据自身数据特定指定潜客标识；
针对不同企业的不同结构的数据可以做到零开发成本接入。
2.服务于不同行业企业的多样营销
依托RT-CDP强大数据管理能力，爱番番营销产品已服务于法律、商务服务、教育培训、电子电工、机械设备、金融、健康美容、生活服务、房产家居、建筑建材、印刷包装、农林牧渔、物流运输、餐饮食品等数十个行业的数千家企业，帮助企业解决了很多营销难题。成功的企业案例不胜枚举。
目前我们完成RT-CDP1.0的建设，并且在一些核心指标上都取得了不错的效果：
实时计算做到了数十万TPS的实时处理、实时持久化，做到毫秒级延迟。
支持企业海量数据、高并发下毫秒级实时分析。
真正基于实时流数据实现规则判断，支撑了私域打标、实时规则判断、圈群等多个实时业务场景，让营销毫秒触达。
平台架构存算分离，可水平扩展：
基于云原生+Nebula搭建了，可动态伸缩的图存储集群；
借助百度云原生CCE、BMR等云上能力，搭建了存算分离的弹性伸缩的存算集群；
计算集群动态伸缩，节约企业资源成本。
各个模块、各个集群稳定性指标长期维持在99.99%以上。
1.【业务层面】更多贴近行业的中台能力
平台目前在业务支撑上已经具备了比较好的定义能力。下一步将结合重点服务的企业行业，内置更多行业业务对象，进一步简化企业数据接入成本。
在B2B2C数据模型上做更多业务尝试，更好服务ToB企业。
2.【业务层面】更丰富的AI模型
RT-CDP已经为企业提供了智能化的潜客评分能力，支持企业灵活定义评分规则。在AI时代，我们将继续丰富更多的AI模型来帮助企业管理、洞察、营销客户。
3.【架构层面】更智能化的治理、运维
目前Flink作业还是基于Yarn管理资源、基于API、脚本方式流程化操作（比如涉及到CK的操作）作业监控通过如流、短信、电话报警。后续我们将作业管理、运维上做更多尝试，比如基于K8s管理Flink作业、结合如流的Webhook能力完善作业运维能力等。
在流数据驱动下，数据处理机制的变化让数据治理、数据检查变得更有挑战。为了提供更可靠的数据服务，还有很多工作要做。
4.【架构层面】湖仓一体到智能湖仓
国内互联网公司已经有不少数据湖技术实践案例，确实可以解决一些原有数仓架构的痛点，比如数据不支持更新操作，无法做到准实时的数据查询。我们目前也在做Flink 和 Iceberg/Hudi 集成的一些尝试，后续会逐步落地。
Jimmy：带着团队为爱番番奔走的资深工程师。
