導讀：隨著營銷3.0時代的到來，企業(yè)愈發(fā)需要依托強大CDP能力解決其嚴重的數(shù)據(jù)孤島問題，幫助企業(yè)加溫線索、促活客戶。但什么是CDP、好的CDP應該具備哪些關鍵特征？本文在回答此問題的同時，詳細講述了愛番番租戶級實時CDP建設實踐，既有先進架構目標下的組件選擇，也有平臺架構、核心模塊關鍵實現(xiàn)的介紹。

全文19135字，預計閱讀時間26分鐘

一、CDP是什么

1.1 CDP由來

CDP（Customer Data Platform）是近些年時興的一個概念。隨著時代發(fā)展、大環(huán)境變化，企業(yè)在自有媒體增多的同時，客戶管理、營銷變難，數(shù)據(jù)孤島問題也愈發(fā)嚴重，為了更好的營銷客戶CDP誕生了?？v向來看，CDP出現(xiàn)之前主要經(jīng)歷了兩個階段。CRM時代，企業(yè)通過電話、短信、email與現(xiàn)有客戶和潛在客戶的互動，以及執(zhí)行數(shù)據(jù)分析，從而幫助推動保留和銷售；DMP階段，企業(yè)通過管理各大互聯(lián)網(wǎng)平臺進行廣告投放和執(zhí)行媒體宣傳活動。

CRM、DMP、CDP三個平臺核心作用不同，但縱向來對比，更容易理解CDP。三者之間在數(shù)據(jù)屬性、數(shù)據(jù)存儲、數(shù)據(jù)用途等方面都較大差異。

有幾個關鍵區(qū)別如下：

1.CRM vs CDP

客戶管理：CRM側重于銷售跟單；CDP更加側重于營銷。

觸點：CRM的客戶主要是電話、QQ、郵箱等；CDP還包含租戶的自有媒體關聯(lián)的用戶賬號（例如，企業(yè)自己的網(wǎng)站、app、公眾號、小程序）。

2.DMP vs CDP

數(shù)據(jù)類型：DMP是匿名數(shù)據(jù)為主；CDP以實名數(shù)據(jù)為主。

數(shù)據(jù)存儲：DMP數(shù)據(jù)只是短期存儲；CDP數(shù)據(jù)長期存儲。

1.2 CDP定義

2013年MarTech分析師 David Raab首次提出CDP這個概念，后來其發(fā)起的CDP Institute給出權威定義：packaged software that creates a persistent, unified customer database that is accessible to other systems。

這里面主要包含三個層面：

Packaged software：基于企業(yè)自身資源部署，使用統(tǒng)一軟件包部署、升級平臺，不做定制開發(fā)。

Persistent, unified customer database：抽取企業(yè)多類業(yè)務系統(tǒng)數(shù)據(jù)，基于數(shù)據(jù)某些標識形成客戶的統(tǒng)一視圖，長期存儲，并且可以基于客戶行為進行個性化營銷。

Accessible to other systems：企業(yè)可以使用CDP數(shù)據(jù)分析、管理客戶，并且可以通過多種形式取走重組、加工的客戶數(shù)據(jù)。

1.3 CDP分類

CDP本身的C（Customer）是指all customer-related functions, not just marketing。面向不同場景也對應不同類型的CDP，不同類別的CDP主要是功能范圍不同，但是類別之間是遞進關系。

主要分為四類：

Data CDPs：主要是客戶數(shù)據(jù)管理，包括多源數(shù)據(jù)采集、身份識別，以及統(tǒng)一的客戶存儲、訪問控制等。

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系統(tǒng)，本文的CDP為其提供數(shù)據(jù)支撐。

二、挑戰(zhàn)與目標

2.1 面臨挑戰(zhàn)

隨著營銷3.0時代的到來，以愛番番私域產(chǎn)品來說，主要是借助強大的CDP為企業(yè)提供線上、線下數(shù)據(jù)的打通管理的同時，企業(yè)可以使用精細化的客戶分群，進行多場景的增育活動（比如自動化營銷的手段，節(jié)假日促銷通知，生日祝福短信，直播活動等等）。更重要的是，企業(yè)可以基于純實時的用戶行為進行更加個性、準確、及時的二次實時營銷，幫助企業(yè)加溫線索、促活客戶，提升私域營銷轉化效果。那如何做好實時CDP（Real-Time CDP，縮寫為RT-CDP）驅動上層營銷業(yè)務，面臨諸多挑戰(zhàn)。

【業(yè)務層面】

1.企業(yè)數(shù)據(jù)渠道多，數(shù)據(jù)形態(tài)各異

一個企業(yè)除了官網(wǎng)、文件、App、自有系統(tǒng)，還包括目前眾多的企業(yè)自有媒體（比如微信公眾號、抖音企業(yè)號、百家號、各類小程序等）等各種場景的數(shù)據(jù)結構不統(tǒng)一，如何高效接入企業(yè)數(shù)據(jù)到RT-CDP？這也是成千上萬的企業(yè)主們在客戶數(shù)據(jù)融合的課題上亟需解決的系統(tǒng)化問題。

2.不同生態(tài)無法打通，無法360度洞察用戶

數(shù)據(jù)分散導致難以識別唯一用戶身份，無法建立全面且持續(xù)更新的用戶畫像，導致對用戶的認知碎片化片面化，洞察不足。比如在實際營銷場景下，企業(yè)期望對同時訪問官網(wǎng)和其小程序的同一用戶發(fā)放優(yōu)惠券促活時，但因為一個人的行為以不同標識分散在各渠道數(shù)據(jù)中，無法進行跨渠道用戶行為分析，也就無法實現(xiàn)企業(yè)訴求。

3.人群劃分規(guī)則復雜

我們不同企業(yè)的業(yè)務是不同的，所以我們可以根據(jù)業(yè)務特點，為不同的客戶打上個性化的標簽，比如企業(yè)進行營銷活動時，想給經(jīng)過迭代旅程節(jié)點的用戶、參與某個直播等等的打上不同場景的標簽，這樣才能對不同的人群進行細分，做更精細化的營銷。

4.如何用一個平臺服務好B2B2C、B2C兩類企業(yè)，行業(yè)可借鑒經(jīng)驗少

愛番番的客戶涉及多類行業(yè)，有的B2C的也有B2B2C的。相對與B2C，B2B2C的業(yè)務場景復雜度是指數(shù)級上升。在管理好B、C畫像的同時，還要兼顧上層服務的邏輯里，比如身份融合策略、基于行為的圈選等。另外，在許多業(yè)務場景也存在很多業(yè)務邊界不清晰的問題。

【技術層面】

1.全渠道實時精準識別要求高

當今時代一個客戶行為跨源跨設備跨媒體，行為軌跡碎片化嚴重。如果企業(yè)想營銷效果好，精準、實時識別客戶、串聯(lián)客戶行為軌跡是重要前提。那如何在多源多身份中做到高性能的實時識別也是個很大挑戰(zhàn)。

2.需要具有實時、低延遲處理海量數(shù)據(jù)的能力

現(xiàn)在客戶可選擇性多，意向度不明確，基于客戶行為實時營銷，以及基于客戶反饋的實時二次交互是提高營銷效果的關鍵，比如企業(yè)營銷部門群發(fā)一個活動短信，客戶點沒點，點了有什么樣進一步的動作，代表著客戶不同的意向程度，企業(yè)營銷、銷售人員需要根據(jù)客戶動作進行及時進一步的跟進。只有實時把握這些變化，才能更高效地促進營銷活動的轉化。如何實時處理海量數(shù)據(jù)驅動業(yè)務？

3.需要可擴展的架構

在多租戶背景下，愛番番管理數(shù)千、萬中小企業(yè)的海量數(shù)據(jù)。隨著服務企業(yè)數(shù)量的不斷增加，如何快速不斷提升平臺的服務能力，需要設計一個先進的技術架構。另外，如何做到高性能、低延遲、可伸縮、高容錯，也是很大的技術挑戰(zhàn)。

4.多租戶特性、性能如何兼顧

愛番番私域產(chǎn)品是以Saas服務形式服務于中小企業(yè)，那一個具備多租戶特性的CDP是一個基本能力。雖然中小企業(yè)客戶一般十萬、百萬量級不等，但隨著企業(yè)進行的營銷活動的累增，企業(yè)的數(shù)據(jù)體量也會線性增長。對于中大企業(yè)來說，其客戶量級決定了其數(shù)據(jù)體量增長速度更快。另外，不同企業(yè)對于數(shù)據(jù)查詢的維度各異很難做模型預熱。在此前提下，如何兼顧可擴展性、服務性能是個難題。

5.多樣部署擴展性

CDP目前主要以Saas服務服務于中小企業(yè)，但不排除后續(xù)支持大客戶OP部署（On-Premise，本地化部署）的需求，如何做好組件選型支持兩類服務方式？

2.2 RT-CDP建設目標

2.2.1 關鍵業(yè)務能力

經(jīng)過分析和業(yè)務抽象，我們覺得，一個真正好的RT-CDP需要做到如下幾個關鍵特征：

靈活的數(shù)據(jù)對接能力：可以對接客戶各種數(shù)據(jù)結構多類數(shù)據(jù)源的客戶系統(tǒng)。另外，數(shù)據(jù)可以被隨時訪問。

同時支持 B2C和B2B兩類數(shù)據(jù)模型：面向不同的行業(yè)客戶，用一套服務支撐。

統(tǒng)一的用戶、企業(yè)畫像：包含屬性、行為、標簽（靜態(tài)、動態(tài)（規(guī)則）標簽、預測標簽）、智能評分、偏好模型等等。

實時的全渠道身份識別、管理：為了打破數(shù)據(jù)孤島，打通多渠道身份，是提供統(tǒng)一用戶的關鍵，也是為了進行跨渠道用戶營銷的前提。

強大的用戶細分能力（用戶分群）：企業(yè)可以根據(jù)用戶屬性特征、行為、身份、標簽等進行多維度多窗口組合的用戶劃分，進行精準的用戶營銷。

用戶的實時交互、激活：面對用戶習慣變化快，實時感知用戶行為進行實時自動化營銷能力尤為重要。

安全的用戶數(shù)據(jù)管理：數(shù)據(jù)長期、安全存儲是數(shù)據(jù)管理平臺的基本要求。

2.2.2 先進技術架構

明確平臺業(yè)務目標的同時，一個先進的技術架構也是平臺建設的目標。如何做到平臺架構，我們有如下幾個核心目標：

1.流數(shù)據(jù)驅動

在傳統(tǒng)數(shù)據(jù)庫、數(shù)據(jù)處理上，還主要是『數(shù)據(jù)被動，查詢主動』。數(shù)據(jù)在數(shù)據(jù)庫中處于靜止狀態(tài)，直到用戶發(fā)出查詢請求。即使數(shù)據(jù)發(fā)生變化，也必須用戶主動重新發(fā)出相同的查詢以獲得更新的結果。但現(xiàn)在數(shù)據(jù)量越來越大、數(shù)據(jù)變化及時感知要求越來越高，這種方法已無法滿足我們與數(shù)據(jù)交互的整個范式。

現(xiàn)在系統(tǒng)架構設計如下圖，更傾向于主動驅動其他系統(tǒng)的架構，比如領域事件驅動業(yè)務。數(shù)據(jù)處理亦是需要如此：『數(shù)據(jù)主動、查詢被動』。

舉個例子，企業(yè)想找到訪問過企業(yè)小程序的用戶進行發(fā)短信時，兩種分別如何做？

傳統(tǒng)方式：先將用戶數(shù)據(jù)存入存儲引擎，在企業(yè)發(fā)短信之前再將查詢條件轉換成sql，然后去海量數(shù)據(jù)中篩選符合條件的用戶。

現(xiàn)代方式：在用戶數(shù)據(jù)流入數(shù)據(jù)系統(tǒng)時，進行用戶畫像豐富，然后基于此用戶畫像進行符不符合企業(yè)查詢條件的判斷。它只是對單個用戶數(shù)據(jù)的規(guī)則判斷，而不是從海量數(shù)據(jù)篩選。

2.流計算處理

傳統(tǒng)的數(shù)據(jù)處理更多是離線計算、批量計算。離線計算就是Data at rest，Query in motion；批量計算是將數(shù)據(jù)積累到一定程度，再基于特定邏輯進行加工處理。雖然兩者在數(shù)據(jù)處理數(shù)據(jù)方式也有所不同，但是從根本上來說都是批量處理，天然也就有了延遲了。

流式計算則是徹底去掉批的概念，對流數(shù)據(jù)實時處理。也就是針對無界的、動態(tài)的數(shù)據(jù)進行持續(xù)計算，可以做到毫秒級延遲。在海量數(shù)據(jù)時代競爭激烈的今天，對企業(yè)洞察來說尤為如此，越快挖掘的數(shù)據(jù)業(yè)務價值越高。

3.一體化實踐

【批流一體】

在大數(shù)據(jù)處理領域，存在兩個典型的架構（Lamda、Kappa、Kappa+）。Lamda架構就是批計算、實時計算走兩套計算架構，導致有時候有的相同邏輯開發(fā)兩套代碼，容易出現(xiàn)數(shù)據(jù)指標不一致，也帶來了維護困難。Kappa、Kappa+架構是旨在簡化分布式計算架構，以實時事件處理架構為核心兼顧批流兩種場景。在大多數(shù)企業(yè)實際生產(chǎn)架構中還是兩者混合較多，因為徹底的實時架構存在很多難點，比如數(shù)據(jù)存儲、某些批計算更易處理的大窗口聚合計算等。

【統(tǒng)一編程】

在實際業(yè)務場景中，批、流處理依然是同時存在的?？紤]到隨著分布式數(shù)據(jù)處理計算發(fā)展，分布式處理框架也會推陳出新，雖然Apache Flink在批流一體支持上很活躍，但還不太成熟。

另外，在各個公司多個計算框架并用的情況還是普遍存在。所以統(tǒng)一數(shù)據(jù)處理編程范式是一個重要的編程選擇，可以提高編程靈活性，做到支持批、流場景數(shù)據(jù)處理作業(yè)開發(fā)，做到一套處理程序可以執(zhí)行在任意的計算框架上，這樣也利于后續(xù)平臺切換更優(yōu)秀的計算引擎。

4.可擴展為前提

這里主要是指架構的擴展性，一個具有擴展性的架構可以在穩(wěn)定服務業(yè)務的同時合理控制資源成本，才能可持續(xù)支撐業(yè)務的快速發(fā)展。

【算存分離】

在如今海量數(shù)據(jù)的大數(shù)據(jù)時代，在不同場景下有時僅需要高處理能力，有時僅需要海量數(shù)據(jù)存儲。傳統(tǒng)存算一體架構，如果要滿足兩種場景，就需要高配置（多核、多內存、高性能本地盤等）服務節(jié)點，顯然存在資源利用不合理，也會引發(fā)集群穩(wěn)定性問題，比如節(jié)點過多導致數(shù)據(jù)分散，引發(fā)數(shù)據(jù)一致性降低等。算存分離的架構才符合分布式架構的思想，針對業(yè)務場景進行計算資源、存儲資源的分別控制，實現(xiàn)資源合理分配。也利于集群數(shù)據(jù)一致性、可靠性、擴展性、穩(wěn)定性等方面的能力保證。

【動態(tài)伸縮】

動態(tài)伸縮主要為了提高資源利用率，降低企業(yè)成本。實際業(yè)務中，有時候平臺需要應對在業(yè)務平穩(wěn)期短時間段內的流量（實時消息量）波峰波谷需要短期擴容，比如在各個重要節(jié)日大量企業(yè)同時需要做很多營銷活動，導致消息量陡升；有時候隨著愛番番服務的企業(yè)量不斷增長，也會導致消息量線性增加，進而需要長期擴容。針對前者，一方面不好預見，另一方面也存在很高的運維成本。所以一個可以基于時間、負載等組合規(guī)則動態(tài)擴縮容的集群資源管理能力也是架構建設的重要考慮。

三、技術選型

沒有萬能的框架，只有合適的取舍。需要結合自身業(yè)務特點和架構目標進行合理選型。結合RT-CDP建設目標，我們做了如下幾個核心場景的組件調研、確定。

3.1 身份關系存儲新嘗試

在CDP中跨渠道身份打通（ID Mapping）是數(shù)據(jù)流渠道業(yè)務的核心，需要做到數(shù)據(jù)一致、實時、高性能。

傳統(tǒng)的idmapping是怎么做？

1.使用關系型數(shù)據(jù)庫存儲身份關系一般是將身份關系存成多表、多行進行管理。該方案存在兩個問題：

數(shù)據(jù)高并發(fā)實時寫入能力有限；

一般身份識別都需要多跳數(shù)據(jù)關系查詢，關系型數(shù)據(jù)庫要查出來期望數(shù)據(jù)就需要多次Join，查詢性能很低。

2.使用Spark GraphX進行定時計算一般是將用戶行為存入Graph或者Hive，使用Spark定時將用戶行為中身份信息一次性加載到內存，然后使用GraphX根據(jù)交叉關系進行用戶連通性計算。該方案也存在兩個問題：

不實時。之前更多場景是離線聚合、定時對用戶做動作；

隨著數(shù)據(jù)量增加計算耗時會越來越高，數(shù)據(jù)結果延遲也會越來越高。

我們怎么做？

隨著近幾年圖技術的發(fā)展，基于圖解決業(yè)務問題的案例越來越多，開源圖框架的產(chǎn)品能力、生態(tài)集成越來越完善，社區(qū)活躍度也越來越高。所以我們嘗鮮基于圖進行身份關系建模，借助圖自然的多度查詢能力進行實時身份判斷、融合。

圖框架對比

大家也可以結合最新的圖數(shù)據(jù)庫的排名走勢，進行重點調研。另外，關于主流圖庫對比案例也越來越多，可以自行參考。在分布式、開源圖數(shù)據(jù)庫中主要是HugeGraph、DGraph和Nebula。我們在生產(chǎn)環(huán)境主要使用了DGraph和Nebula。因為愛番番服務都是基于云原生建設，平臺建設前期選擇了DGraph，但后來發(fā)現(xiàn)水平擴展受限，不得不從DGraph遷移到Nebula（關于DGraph到Nebula的遷移，坑還是挺多的，后續(xù)會有專門文章介紹，敬請期待）。

網(wǎng)上對DGraph和Nebula對比很少，這里簡單說一下區(qū)別：

集群架構：DGraph是算存一體的，其存儲是BadgerDB，go實現(xiàn)的對外透明；Nebula讀寫分離，但默認是RocksDB存儲（除非基于源碼更換存儲引擎，也有公司在這么搞），存在讀寫放大問題；

數(shù)據(jù)切分：DGraph是基于謂詞切分（可以理解為點類型），容易出現(xiàn)數(shù)據(jù)熱點，想支持多租戶場景，就需要動態(tài)創(chuàng)建租戶粒度謂詞來讓數(shù)據(jù)分布盡量均勻（DGraph企業(yè)版也支持了多租戶特性，但收費且依然沒考慮熱點問題）；Nebula基于邊切分，基于vid進行partition，不存在熱點問題，但圖空間創(chuàng)建時需要預算好分區(qū)個數(shù)，不然不好修改分區(qū)數(shù)。

全文檢索：DGraph支持；Nebula提供listener可以對接ES。

Query語法：DGraph是自己的一個查詢語法；Nebula有自身查詢語法之外，還支持了Cypher語法（Neo4j的圖形查詢語言），更符合圖邏輯表達。

事務支持：DGraph基于MVCC支持事務；Nebula不支持，其邊的寫事務也是最新版才支持的（2.6.1）。

同步寫：DGraph、Nebula均支持異步、同步寫。

集群穩(wěn)定性：DGraph集群更穩(wěn)定；Nebula的穩(wěn)定性還有待提升，存在特定運算下偶發(fā)Crash的情況。

生態(tài)集群：DGraph在生態(tài)集成更成熟，比如與云原生的集成；Nebula在生態(tài)集成范圍上更多樣一些，比如nebula-flink-connector、nebula-spark-connector等，但在各類集成的成熟度上還有待提升。

3.2 流式計算引擎選擇

對于主流計算框架的對比，比如Apache Flink、Blink、Spark Streaming、Storm，網(wǎng)上有很多資料，大家也請自行調研就好 ，比如如下，詳見鏈接：

https://blog.csdn.net/weixin_39478115/article/details/111316120

選擇Apache Flink做為流批計算引擎

使用廣泛的Spark還是以微批的方式進行流計算。而Flink是流的方式。Apache Flink是近幾年發(fā)展很快的一個用于分布式流、批處理數(shù)據(jù)處理的開源平臺。它是最貼合DataFlow模型實現(xiàn)的分布式計算框架?；诹饔嬎氵M行高性能計算，具有良好的容錯、狀態(tài)管理機制和高可用能力；其他組件于Flink的集成也越來越多、也日趨成熟；所以選擇我們Apache Flink做為我們的流批計算引擎。

選擇Apache Beam做為編程框架

分布式數(shù)據(jù)處理技術不斷發(fā)展，優(yōu)秀的分布式數(shù)據(jù)處理框架也會層出不窮。Apache Beam是Google在2016年貢獻給Apache基金會的孵化項目，它的目標是統(tǒng)一批處理和流處理的編程范式，做到企業(yè)開發(fā)的數(shù)據(jù)處理程序可以執(zhí)行在任意的分布式計算引擎上。Beam在統(tǒng)一編程范式的同時也提供了強大的擴展能力，對新版本計算框架的支持也很及時。所以我們選擇Apache Beam做為我們的編程框架。

3.3 海量存儲引擎取舍

在Hadoop 生態(tài)系統(tǒng)存儲組件中，一般用HDFS支持高吞吐的批處理場景、用HBase支持低延遲，有隨機讀寫需求的場景，但很難只使用一種組件來做到這兩方面能力。另外，如何做到流式計算下的數(shù)據(jù)實時更新，也影響存儲組件的選擇。

Apache Kudu 是 Cloudera 開源的列式存儲引擎，是一種典型的HTAP(在線事務處理/在線分析處理混合模式)。在探索HTAP的方向上，TiDB、Oceanbase均在此行列，只是大家起初側重的場景不同而已，大家也可以對比一下。ApacheKudu的愿景是fast analytics on fast and changing data。從Apache Kudu的定位，如下圖可見一斑：

結合我們的平臺建設理念，實時、高吞吐的數(shù)據(jù)存儲、更新是核心目標，在數(shù)據(jù)復雜查詢、數(shù)據(jù)應用的QPS上不高（因為核心的業(yè)務場景是基于實時流的實時客戶處理），再加上Cloudera Impala無縫集成Kudu，我們最終確定Impala+Kudu做為平臺的數(shù)據(jù)存儲、查詢引擎。

分析增強：Doris

基于Impala+Kudu的選型，在支持OP部署時是完全沒有問題的，因為各個企業(yè)的數(shù)據(jù)體量、數(shù)據(jù)查詢QPS都有限。

這樣企業(yè)只需要很簡單的架構就可以支持其數(shù)據(jù)管理需求，提高了平臺穩(wěn)定性、可靠性，同時也可以降低企業(yè)運維、資源成本。但由于Impala并發(fā)能力有限（當然在Impala4.0開始引入多線程，并發(fā)處理能力提升不少），愛番番的私域服務目前還是以Saas服務為重，想在Saas場景下做到高并發(fā)下的毫秒級數(shù)據(jù)分析，這種架構性能很難達標，所以我們在分析場景引入了分析引擎Doris。之所以選擇Doris，基于 MPP 架構的 OLAP 引擎。

相對于Druid、ClickHouse等開源分析引擎，Doris具有如下特點：l支持多種數(shù)據(jù)模型，包括聚合模型、Uniq模型、Duplicate模型；l支持Rollup、物化視圖；l在單表、多表上的查詢性能都表現(xiàn)很好；l支持MySQL協(xié)議，接入、學習成本低；l無需集成Hadoop生態(tài)，集群運維成本也低很多。

3.4 規(guī)則引擎調研

實時規(guī)則引擎主要用于客戶分群，結合美團的規(guī)則對比，幾個引擎（當然還有一些其他的URule、Easy Rules等）特點如下：

RT-CDP中客戶分群規(guī)則分類、組合多，規(guī)則計算復雜、算子多，時間窗口跨度大、甚至無窗口，業(yè)內沒有一個能很好滿足業(yè)務需求的開源規(guī)則引擎，所以我們選擇了自研。

四、平臺架構

4.1 整體架構

在愛番番私域產(chǎn)品中，主要分為兩部分：RT-CDP和MA，兩者疊加近似等同于Deliver CDP所包含的功能范圍。本文所講的RT-CDP所包含的功能范圍等同于Analytics CDPs，簡單來講，主要就是客戶數(shù)據(jù)管理、數(shù)據(jù)分析洞察。

RT-CDP也是就兩部分功能進行拆分，主要包含五部分：數(shù)據(jù)源、數(shù)據(jù)采集、實時數(shù)倉，數(shù)據(jù)應用和公共組件，除公共組件部分是橫向支撐外，其他四部分就是標準的數(shù)據(jù)對接到數(shù)據(jù)應用的四個階段：

數(shù)據(jù)源：這里的數(shù)據(jù)源不僅包含客戶私有數(shù)據(jù)，也包括在各個生態(tài)上的自有媒體數(shù)據(jù)，比如微信公眾號、微信小程序、企微線索、百度小程序、抖音企業(yè)號、第三方生態(tài)行為數(shù)據(jù)等。

數(shù)據(jù)采集：大多中小企業(yè)沒有研發(fā)能力或者很薄弱，如何幫助快速將自有系統(tǒng)對接到愛番番RT-CDP是這層需要重點考慮的，為此我們封裝了通用的采集SDK來簡化企業(yè)的數(shù)據(jù)采集成本，并且兼容uni-app等優(yōu)秀前端開發(fā)框架。另外，由于數(shù)據(jù)源多種多樣、數(shù)據(jù)結構不一，為了簡化不斷接入的新數(shù)據(jù)源，我們建設了統(tǒng)一的采集服務，負責管理不斷新增的數(shù)據(jù)通道，以及數(shù)據(jù)加解密、清洗、數(shù)據(jù)轉換等數(shù)據(jù)加工，這個服務主要是為了提供靈活的數(shù)據(jù)接入能力，來降低數(shù)據(jù)對接成本。

實時算存：在采集到數(shù)據(jù)后就是進行跨渠道數(shù)據(jù)身份識別，然后轉換成結構化的客戶統(tǒng)一畫像。就數(shù)據(jù)管理來說，這層也包含企業(yè)接入到CDP中的碎片客戶數(shù)據(jù)，為了后續(xù)企業(yè)客戶分析。經(jīng)過這層處理，會形成跨渠道的客戶身份關系圖、統(tǒng)一畫像，然后再通過統(tǒng)一視圖為上層數(shù)據(jù)接口。另外，就是數(shù)倉常規(guī)的數(shù)據(jù)質量、資源管理、作業(yè)管理、數(shù)據(jù)安全等功能。

數(shù)據(jù)應用：這層主要是為企業(yè)提供客戶管理、分析洞察等產(chǎn)品功能，比如豐富的潛客畫像、規(guī)則自由組合的客戶分群和靈活的客戶分析等。也提供了多種數(shù)據(jù)輸出方式，方便各個其他系統(tǒng)使用。

公共組件：RT-CDP服務依托愛番番先進的基礎設施，基于云原生理念管理服務，也借助愛番番強大的日志平臺、鏈路追蹤進行服務運維、監(jiān)控。另外，也基于完備的CICD能力進行CDP能力的快速迭代，從開發(fā)到部署都是在敏捷機制下，持續(xù)集成、持續(xù)交付。

4.2 核心模塊

簡單來說，RT-CDP實現(xiàn)的功能就是多渠道數(shù)據(jù)的實時、定時采集，然后經(jīng)過數(shù)據(jù)中身份的識別Identity服務，再進行數(shù)據(jù)處理、數(shù)據(jù)進行數(shù)據(jù)映射、加工（比如維度Join、數(shù)據(jù)聚合、數(shù)據(jù)分層等），然后進行結構化持久化，最后對外實時輸出。

RT-CDP主要劃分為六大模塊：采集服務、Connectors、Identity Service、實時計算、統(tǒng)一畫像和實時規(guī)則引擎。上圖就是從數(shù)據(jù)交互形式和數(shù)據(jù)流向的角度描繪了RT-CDP核心模塊之間的交互。從左到右是數(shù)據(jù)的主流向，代表了數(shù)據(jù)進入平臺到數(shù)據(jù)輸出到和平臺交互的外部系統(tǒng)；中間上側是實時計算和Identity Service、實時規(guī)則引擎和統(tǒng)一畫像的雙向數(shù)據(jù)交互。

下面結合數(shù)據(jù)處理階段進行各個核心模塊的功能說明：

1.數(shù)據(jù)源&采集

從數(shù)據(jù)源和RT-CDP數(shù)據(jù)交互方式上，主要分為實時流入和批次拉取。針對兩種場景，我們抽象了兩個模塊：實時采集服務和Connectors。

實時采集服務：該模塊主要是對接企業(yè)已有的自有媒體數(shù)據(jù)源，愛番番業(yè)務系統(tǒng)領域事件以及愛番番合作的第三方平臺。這層主要存在不同媒體平臺API協(xié)議、場景化行為串聯(lián)時的業(yè)務參數(shù)填充、用戶事件不斷增加等問題，我們在該模塊抽象了數(shù)據(jù)Processor&自定義Processor Plugin等來減少新場景的人工干預。

Connectors ：該模塊主要是對接企業(yè)的自有業(yè)務系統(tǒng)的數(shù)據(jù)源，比如MySQL、Oracle、PG等業(yè)務庫，這部分不需要實時接入，只需按批次定時調度即可。這里需要解決的主要是多不同數(shù)據(jù)源類型的支持，為此我們也抽象了Connector和擴展能力，以及通用的調度能力來支持。針對兩種場景下，存在同一個問題：如何應對多樣數(shù)據(jù)結構的數(shù)據(jù)快讀快速接入？為此，我們抽象了數(shù)據(jù)定義模型（Schema），后面會詳細介紹。

2.數(shù)據(jù)處理

Identity Service：該模塊提供跨渠道的客戶識別能力，是一種精準化的ID Mapping,用于實時打通進入RT-CDP的客戶數(shù)據(jù)。該服務持久化了客戶身份相關關系圖放在Nebula中，會根據(jù)實時數(shù)據(jù)、身份融合策略進行實時、同步更新Nebula，然后將識別結果填充到實時消息。進入CDP數(shù)據(jù)只有經(jīng)過Identity Service識別后才繼續(xù)往后走，它決定了營銷旅程的客戶交互是否符合預期，也決定了RT-CDP的吞吐上限。

實時計算：該模塊包含了所有數(shù)據(jù)處理、加工、分發(fā)等批流作業(yè)。目前抽象了基于Apache Beam的作業(yè)開發(fā)框架，嘗試批流都在Flink上做，但有些運維Job還用了Spark，會逐漸去除。

統(tǒng)一畫像：該模塊主要是持久化海量的潛客畫像，對于熱數(shù)據(jù)存儲在Kudu中，對于溫、冷的時序數(shù)據(jù)定時轉存到Parquet中。潛客畫像包括客戶屬性、行為、標簽、所屬客群、以及聚合的客戶擴展數(shù)據(jù)等。雖然標簽、客群是單獨存在的聚合根，但是在存儲層面是一致的存儲機制。另外，標準RT-CDP還應該管理客戶碎片數(shù)據(jù)，所以統(tǒng)一畫像和數(shù)據(jù)湖數(shù)據(jù)如何交互是后續(xù)建設的重點。

統(tǒng)一查詢服務：在RT-CDP中，客戶數(shù)據(jù)分散在圖數(shù)據(jù)庫、Kudu、增強的分析引擎和數(shù)據(jù)湖，但對用戶來說只有屬性、行為、標簽、客群等業(yè)務對象，如何支持產(chǎn)品上透明使用？我們通過統(tǒng)一視圖、跨源查詢建設了此統(tǒng)一查詢服務，該服務支持了Impala、Doris、MySQL、Presto、ES等查詢存儲引擎以及API的跨源訪問。

實時規(guī)則引擎：該模塊主要是基于Flink提供實時規(guī)則判斷，來支持圈群、基于規(guī)則的靜態(tài)打標、規(guī)則標簽等業(yè)務場景。

3.數(shù)據(jù)輸出

數(shù)據(jù)輸出已經(jīng)支持多種方式，包括OpenAPI、Webhook、消息訂閱等。一方面，也方便企業(yè)獲取CDP融合后的潛客的實時行為，然后與自有的下游業(yè)務系統(tǒng)進行用戶全鏈管理。另一方面為上層的MA提供實時行為流驅動營銷環(huán)路。這里特殊說明說明一下， MA的旅程節(jié)點中也需要很多實時規(guī)則判斷，判斷口徑多樣，有些在節(jié)點上做內存實現(xiàn)困難，所以RT-CDP也實現(xiàn)了可以為MA提供實時判斷結果的數(shù)據(jù)輸出。

4.3 關鍵實現(xiàn)

4.3.1 數(shù)據(jù)定義模型

為什么需要Schema？

前面提到企業(yè)的多個渠道的數(shù)據(jù)特征結構各異。再加上不同租戶業(yè)務特點不同，企業(yè)需要數(shù)據(jù)自定義的擴展性。RT-CDP為了兩類問題需要具備數(shù)據(jù)結構靈活定義的能力來對接企業(yè)數(shù)據(jù)。

另外，RT-CDP本身管理兩類數(shù)據(jù)：碎片化客戶數(shù)據(jù)和用戶統(tǒng)一畫像。對于前者來說，不需要關系數(shù)據(jù)內容本身，利用數(shù)據(jù)湖等技術即可為企業(yè)提供數(shù)據(jù)存儲、查詢、分析能力，是偏Schemaless的數(shù)據(jù)管理；對于后者來說，更多需要按不同維度組合查詢、圈群、分析，本身需要結構化的數(shù)據(jù)管理。后者能否通過Schemaless的方式提供服務呢？羅列增刪改查的場景，反證一下局限明顯。

Schema是什么？

Schema是一個數(shù)據(jù)結構的描述，Schema可以相互引用，可以對數(shù)據(jù)中字段以及字段類型、值進行約束，也可以自定義字段。企業(yè)可以用一個統(tǒng)一的規(guī)范快速接入、靈活管理自己的數(shù)據(jù)，比如企業(yè)可以根據(jù)自己的行業(yè)特性，抽象不同的業(yè)務實體、屬性，再給不同的業(yè)務實體定義不同的Schema。企業(yè)可以對業(yè)務實體有交集的信息抽離新Schema，然后多個Schema引用這個新Schema；也可以對每個Schema自定義自己的業(yè)務字段。企業(yè)只需要按相應的Schema結構接入數(shù)據(jù)，就可以按特定的標準使用這些數(shù)據(jù)。

從這幾個實體來說明Schema的特點，如下圖：

Field：字段是最基本的數(shù)據(jù)單元，是組成Schema的最小粒度元素。

Schema：是一組字段、Schema的集合，它本身可以包含多個字段（Field），字段可以自定義，比如字段名、類型、值列表等；也可以引用一個或多個其他Schema，引用時也可以以數(shù)組的形式承載，比如一個Schema里面可以包含多個Identity結構的數(shù)據(jù)。

Behavior：是潛客或企業(yè)的不同行為，本身也是通過Schema承載，不同的Behavior也可以自定義其特有的Field。

在上圖所示，愛番番RT-CDP在進行行業(yè)抽象后，已經(jīng)內置了很多行業(yè)通用的Schema，包括常見的Identity、Profile、Behavior等多類Schema。在愛番番RT-CDP管理的統(tǒng)一潛客畫像中，Identity、Profile、Tag、Segment等都業(yè)務聚合根。為了支持好B、C兩種數(shù)據(jù)模型還有一些B粒度聚合根存在。

Schema如何簡化數(shù)據(jù)接入？

這里需要先說一個Dataset的概念。Dataset是通過Schema定義結構的一個數(shù)據(jù)集，企業(yè)對不同的數(shù)據(jù)源定義成不同的數(shù)據(jù)集。在數(shù)據(jù)源管理時，企業(yè)可以根據(jù)不同的數(shù)據(jù)集結構化導入的數(shù)據(jù)，一個數(shù)據(jù)集可以對應多個數(shù)據(jù)源，也可以對應一個數(shù)據(jù)源中的一類數(shù)據(jù)，一般后者使用較多。

另外，一個數(shù)據(jù)集也可以包含多批次的數(shù)據(jù)，也就是企業(yè)可以周期性的按批次導入同一數(shù)據(jù)集數(shù)據(jù)。在數(shù)據(jù)接入時，如下圖，針對不同的Dataset，企業(yè)可以綁定不同的Schema，每個Schema可以引用、復用其他子Schema，然后經(jīng)過RT-CDP的Schema解析，自動將數(shù)據(jù)持久化到存儲引擎，根據(jù)數(shù)據(jù)的定義不同，會持久化到不同數(shù)據(jù)表中。對應實時的客戶行為也是通過定義不同的Schema來定義數(shù)據(jù)結構，然后進行持續(xù)的數(shù)據(jù)接入。

擴展1：借助字段映射解決多租戶無限擴列問題

存在的問題是什么？

愛番番RT-CDP是一個支持多租戶的平臺，但在多租戶下，每個企業(yè)都有自己的業(yè)務數(shù)據(jù)，一般中小企業(yè)可能有幾百上千個潛客的數(shù)據(jù)字段，對于KA字段量更多。CDP做為Saas服務，如何在一個模型中支持如此多的字段存儲、分析。一般可以無限擴列的引擎可以直接按租戶+字段的方式打平。為了進行結構化實時存儲，愛番番CDP選擇了Kudu，Kudu官方建議單表不超過300列，最多也就支持上千列，那剛才的方式無法解決。

我們的解決方案是什么？

我們在租戶隔離的前提下，采用字段復用的方式解決該問題。在介紹Schema模型時圖里也有體現(xiàn)，在實際的Profile、Event表里都是attr字段。關鍵點就是：

事實表只做無業(yè)務含義的字段；

在數(shù)據(jù)接入、查詢時通過業(yè)務字段（邏輯字段）和事實字段的映射關系進行數(shù)據(jù)轉換后與前端、租戶交互。

4.3.2 Identity Service

這個服務也可以稱之為ID Mapping。但相對于傳統(tǒng)的ID Mapping來說，因為業(yè)務場景的不同，功能側重也有所不同。傳統(tǒng)意義的ID Mapping更多是廣告場景的匿名數(shù)據(jù)的，基于復雜模型的離線和預測識別；CDP中的ID Mapping是基于更精準的數(shù)據(jù)身份標識，進行更精準打通，更加要求打通率和實時性。

為此，我們設計了支持B2B2C、B2C兩種業(yè)務的身份關系模型。在標準化租戶數(shù)據(jù)接入后，基于不斷接入的數(shù)據(jù)新增持續(xù)的身份關系圖譜裂變。在功能層面，我們支持自定義身份類型以及身份權重，也支持針對不同身份租戶自定義身份融合動作。另外，根據(jù)我們對行業(yè)分析，內置了常見的身份及融合策略，方便租戶直接使用。

從架構層面，Identity Service（ID Mapping）基于云原生+Nebula Graph搭建，做到了租戶數(shù)據(jù)隔離、實時讀寫、高性能讀寫以及水平擴縮容。

1.云原生+Nebula Graph

將Nebula Graph部署到K8s下，降低運維成本。我們主要是：

使用Nebula Operator自動化運維我們k8s下的Nebula集群；

使用Statefulset管理Nebula相關有狀態(tài)的節(jié)點Pod；

每個節(jié)點都是使用本地SSD盤來保證圖存儲服務性能。

2.優(yōu)化讀寫

Identity Service整體來說是一個讀多寫少的常見，但在新租戶、拉新場景場景也都需要很高的寫能力，讀寫性能需要兼顧。需要在做好并發(fā)鎖的前提下優(yōu)化讀寫：

設計好數(shù)據(jù)模型，盡量減少Nebula內部IO次數(shù)；

合理利用Nebula語法，避免Graphd多余內存操作；

查詢上，盡量減少深度查詢；更新上，控制好寫粒度、降低無事務對業(yè)務的影響。

擴展1：如何解決未登錄時潛客打通問題

針對一個人多設備場景，單設備被多人使用的場景，我們采用離線矯正的方式進行打通。

4.3.3 實時存算

4.3.3.1 流計算

愛番番RT-CDP核心能力都是依托Apache Flink+Kafka實現(xiàn)。在實時流之上進行的流計算，做到毫秒的數(shù)據(jù)延遲。

核心數(shù)據(jù)流如上圖，簡化后主要包含如下幾部分：

主要采集和格式化的數(shù)據(jù)，會統(tǒng)一發(fā)到cdp-ingest的topic；

RT-CDP有個統(tǒng)一的入口Job（Entrance Job）負責數(shù)據(jù)的清洗、校驗、Schema解析以及身份識別等，然后根據(jù)租戶屬性進行數(shù)據(jù)分發(fā)。因為這是RT-CDP入口Job，需要支持橫向擴縮，所以這個作業(yè)是無狀態(tài)Job。

經(jīng)過數(shù)據(jù)分發(fā)，會有不同的Job群進行分別的數(shù)據(jù)處理、持久化，以及數(shù)據(jù)聚合等數(shù)據(jù)加工邏輯，一方面豐富潛客畫像，另一方面為更多維度的潛客圈群提供數(shù)據(jù)基礎。

最后會將打通的數(shù)據(jù)分發(fā)到下游，下游包括外部系統(tǒng)、數(shù)據(jù)分析、實時規(guī)則引擎、策略模型等多類業(yè)務模塊，以便進行更多的實時驅動。

擴展1：數(shù)據(jù)路由

為什么要做路由？

愛番番RT-CDP做為基礎數(shù)據(jù)平臺，不僅服務于百度之外的租戶，也服務于百度內部甚至愛番番自己；不僅服務于中小企業(yè)，也服務于中大企業(yè)。對于前者，服務穩(wěn)定性要求級別不同，如何避免內外部之間服務能力不相互影響？對于后者，不同規(guī)模企業(yè)潛客量不同，使用RT-CDP圈人群等耗時的資源也不同，如何避免資源不公平分配？

我們怎么做的？

針對上述問題，我們通過數(shù)據(jù)路由的機制解決。我們維護了一張租戶和數(shù)據(jù)流Topic的映射關系，可以根據(jù)租戶特性進行分流，也可以根據(jù)租戶需求動態(tài)調整。然后在Entrance Job根據(jù)租戶的映射關系進行數(shù)據(jù)分流，分發(fā)到不同資源配比的Job群進行分別的數(shù)據(jù)處理。做到了內外部分離，也可以根據(jù)租戶個性化需求進行資源控制。

擴展2：自定義Trigger批量寫

在隨機讀寫上，Kudu的表現(xiàn)相對于HBase等還是相對差一些。為了做到數(shù)十萬TPS的寫能力，我們對Kudu寫也做了一定邏輯優(yōu)化。主要是自定義了Trigger（數(shù)量+時間窗口兩種觸發(fā)），在做到毫秒級延遲的前提將單條寫改為一次策略的批量。

具體方案：在在批量數(shù)據(jù)滿足>N條、或者時間窗口>M毫秒時，再觸發(fā)寫操作。

一般租戶的一次營銷活動，會集中產(chǎn)生一大批潛客行為，這其中包括系統(tǒng)事件、用戶實時行為等，這種批量寫的方式，可以有效提高吞吐。

4.3.3.2 實時存儲

在RT-CDP主要包括三部分的數(shù)據(jù)：碎片化的租戶數(shù)據(jù)、統(tǒng)一的潛客畫像和離線分析數(shù)據(jù)。我們主要分類兩個集群進行數(shù)據(jù)存儲，一個集群存儲潛客統(tǒng)一畫像和具有時序屬性的熱數(shù)據(jù)，另一個集群存儲冷數(shù)據(jù)和用于離線計算的數(shù)據(jù)。每個集群都集成了數(shù)據(jù)湖的能力。然后我們研發(fā)了統(tǒng)一的Query Engine，支持跨源、跨集群的數(shù)據(jù)查詢，對底層存儲引擎透明。

擴展1：基于數(shù)據(jù)分層增強存儲

為什么需要分層？

完全基于Kudu存儲數(shù)據(jù)的話，一方面成本較高（Kudu集群都要基于SSD盤搭建才能有比較好的性能表現(xiàn)）；另一方面在營銷場景下更關注短時間段（比如近一個月、三個月、半年等）客戶的實時行為變化，對于時間較久的歷史數(shù)據(jù)使用頻次很低。

分層機制

綜合考量，也從節(jié)約資源成本角度，我們選擇Parquet做為擴展存儲，針對存儲符合時間序列的海量數(shù)據(jù)做冷熱分層存儲。

根據(jù)數(shù)據(jù)使用頻率，我們將數(shù)據(jù)分為熱、溫、冷三層。熱數(shù)據(jù)，表示租戶經(jīng)常使用的數(shù)據(jù)，時間范圍為三個月內；溫數(shù)據(jù)，表示使用頻率較低的數(shù)據(jù)，一般只用于個別客群的圈選，時間范圍為三個月外到一年；冷數(shù)據(jù)，租戶基本不使用的數(shù)據(jù)，時間范圍為一年之外。為了平衡性能，我們將熱、溫數(shù)據(jù)存放在同一個集群，將冷數(shù)據(jù)放在另外集群（和提供給策略模型的集群放在一個集群）。

具體方案：

在熱、溫、冷之上建立統(tǒng)一視圖，上層根據(jù)視圖進行數(shù)據(jù)查詢。

然后每天定時進行熱到溫、溫到冷的順序性的分別離線遷移，在分別遷移后會分別進行視圖的實時更新。

擴展2：基于潛客融合路徑的映射關系管理解決數(shù)據(jù)遷移問題

為什么需要管理映射？

潛客畫像行為數(shù)據(jù)很多，也可能存在頻繁融合的情況，如果在潛客融合時，每次都遷移數(shù)據(jù)，一方面數(shù)據(jù)遷移成本很高，另一方面，當潛客行為涉及溫冷數(shù)據(jù)時，是無法進行刪除操作的。業(yè)內針對類似情況，更多會有所取舍，比如只遷移用戶僅一段時間的熱數(shù)據(jù)，再往前的歷史不做處理。這種解決方案并不理想。

映射管理機制

為此，我們換了種思路，通過維護潛客融合路徑的方式方式解決該問題。

具體方案：

新增一張潛客融合關系表（user_change_rela）維護映射關系；

在融合關系表和時序表（比如event）之上創(chuàng)建視圖，做到對業(yè)務層透明。

針對融合關系表，我們做了一定的策略優(yōu)化：不維護路徑上的過程關系，而是只維護路徑所有過程點到終點的直接關系。這樣即便在潛客融合路徑涉及過多潛客時，也不會過多增加關系查詢的性能。

舉個例子潛客發(fā)生兩次融合（affId=1001先融合到1002上，再融合到1003上）時的user_change_rela的數(shù)據(jù)變化情況，如下圖：

4.3.3.3 分析增強

我們選擇百度開源的Apache Doris做為數(shù)據(jù)增強的分析引擎，為愛番番拓客版提供客戶洞察能力，比如旅程分析、人群、營銷效果分析、裂變分析、直播分析等。

為了方便后續(xù)OP部署時可靈活去除，我們將CDP輸出的數(shù)據(jù)做為增強分析的數(shù)據(jù)源，然后基于Flink Job做邏輯處理，比如清洗、維度Join、數(shù)據(jù)打平等，最后采用Apache Doris貢獻的flink-doris-connector將數(shù)據(jù)寫入Doris。

使用connector方式直接寫Doris有兩個好處：

使用flink-doris-connector往Doris寫數(shù)據(jù)，比使用Routine Load方式少一次Kafka。

使用flink-doris-connector比Routine Load方式在數(shù)據(jù)處理上，也能更加靈活。

Flink-doris-connector是基于Doris的Stream Load方式實現(xiàn)，通過FE redirect到BE進行數(shù)據(jù)導入處理。我們實際使用flink-doris-connector時，是按10s進行一次Flush、每批次最大可提交百萬行數(shù)據(jù)的配置進行寫操作。對于Doris來說，單批次數(shù)據(jù)多些不flush更頻繁要友好。

如果想了解更多Doris在愛番番中的實踐，可以閱讀『百度愛番番數(shù)據(jù)分析體系的架構與實踐』。

擴展1：RoutineLoad和Stream Load區(qū)別

Routine Load方式

它是提交一個常駐Doris的導入任務，通過不斷的訂閱并消費Kafka中的JSON格式消息，將數(shù)據(jù)寫入到Doris中。

從實現(xiàn)角度來說，是FE負責管理導入Task，Task在BE上通過Stream Load方式進行數(shù)據(jù)導入。

Stream Load方式

它利用流數(shù)據(jù)計算框架Flink 消費Kafka的業(yè)務數(shù)據(jù)，使用Stream Load 方式，以HTTP協(xié)議向Doris寫入。

從實現(xiàn)角度來說，這種方式是框架直接通過BE將數(shù)據(jù)同步寫入Doris，寫入成功后由Coordinator BE直接返回導入狀態(tài)。另外，在導入時，同一批次數(shù)據(jù)最好使用相同的 label，這樣同一批次數(shù)據(jù)的重復請求只會被接受一次，可以保證了At-Most-Once。

4.3.4 實時規(guī)則引擎

在愛番番私域產(chǎn)品中，靈活的圈群能力是一個重要產(chǎn)品能力，如何基于潛客屬性、身份、客戶行為等維度進行復雜、靈活規(guī)則的實時分群？此處的實時規(guī)則引擎就是為此而生。就此功能本身來說，并不新穎，在DMP中就有類似能力。很多CDP和客戶管理平臺都也有類似能力，但如何在多租戶、海量數(shù)據(jù)情況下，做到實時、高吞吐的規(guī)則判斷是一個挑戰(zhàn)。

在愛番番RT-CDP中，一方面租戶數(shù)量大，Saas服務前提如何支持多租戶的高性能分群？另一方面，愛番番RT-CDP期望做到真正基于實時流的實時判斷。因此，我們自研了基于多層數(shù)據(jù)的實時規(guī)則引擎。這里簡單講一下，后續(xù)會有單獨文章介紹。

面臨的問題是什么？

傳統(tǒng)的實現(xiàn)方案主要是當租戶實時或定時觸發(fā)分群請求時，將規(guī)則翻譯成一個復雜SQL，臨時從租戶的潛客數(shù)據(jù)池中進行SQL查詢。另外，一般都會在潛客上做一層倒排索引，在租戶少或者OP部署時，數(shù)據(jù)查詢速度也尚可接受。但在基于實時流實現(xiàn)規(guī)則引擎需要解決如下幾個問題：

海量數(shù)據(jù)實時判斷

窗口粒度數(shù)據(jù)聚合的內存占用問題

滑動窗口下的窗口風暴

無窗口規(guī)則的數(shù)據(jù)聚合問題

潛客數(shù)據(jù)變更后的窗口數(shù)據(jù)更新

實時規(guī)則引擎實現(xiàn)

和很多產(chǎn)品類似，愛番番的規(guī)則圈群也主要是兩層And/Or的規(guī)則組合。結合規(guī)則的特點，我們主要分為如下圖的幾類規(guī)則：普通的屬性運算（P1、P2）、普通身份運算（I1）、小窗口的行為判斷（E1）、大窗口的行為判斷（E2）和無窗口的行為判斷（E3）。

為了規(guī)則靈活度和高效的數(shù)據(jù)處理能力，我們定義了一套規(guī)則解析算法。然后借助Flink強大的分布式計算能力和狀態(tài)管理能力驅動實時規(guī)則引擎計算。上面已經(jīng)說了流數(shù)據(jù)理念，這里結合一條潛客行為進來到實時規(guī)則判斷來更直觀說明數(shù)據(jù)在流中的實時填充，如下圖：數(shù)據(jù)進來之后，先經(jīng)過Identity Service補充身份Ids，在經(jīng)過數(shù)據(jù)Job補充潛客對應的屬性信息，最后基于一個完整的潛客數(shù)據(jù)進行實時規(guī)則判斷，最后將負責規(guī)則的潛客落入Segment表。

另外，規(guī)則引擎是一個獨立于Segment等業(yè)務對象的服務，可以支持圈群、打標簽、MA旅程節(jié)點等各個規(guī)則相關的業(yè)務場景。

4.3.5 擴展

4.3.5.1 彈性集群

愛番番RT-CDP的計算、存儲集群基于百度云搭建，借助云上能力，很好實現(xiàn)了資源的存算分離和動態(tài)伸縮。我們可以自定義靈活的資源擴縮策略，根據(jù)消息量情況進行資源增減，做到波峰時實時加大集群規(guī)模提供計算能力，波谷時縮減集群做到及時降本。

我們的集群主要分為四類節(jié)點：Master、Core、Task、Client。具體如上圖。

Master節(jié)點：集群管理節(jié)點，部署 NameNode、ResourceManager等進程，并且做到組件故障時的自動遷移；

Core節(jié)點：計算及數(shù)據(jù)存儲節(jié)點，部署 DataNode、NodeManager等進程；

Task節(jié)點：計算節(jié)點，用來補充core節(jié)點的算力，部署 NodeManger等進程，該節(jié)點一般不用來存儲數(shù)據(jù)，支持按需動態(tài)擴容和縮容操作；

Client節(jié)點：獨立的集群管控節(jié)點及作業(yè)提交節(jié)點。

4.3.5.2 全鏈監(jiān)控

RT-CDP在建設了完整的鏈路監(jiān)控能力，能夠實時發(fā)現(xiàn)集群、數(shù)據(jù)流問題，方便及時干預、處理，為租戶提供更好的數(shù)據(jù)服務能力提供保證。也建設了全鏈的日志收集、分析能力，極大簡化了服務問題排查成本。

具體如上圖，我們依托愛番番強大的技術服務能力完成了跨平臺的日志采集&報警和全鏈路的延時監(jiān)控：

日志采集：基于愛番番貢獻給Skywalking的Satellite收集全鏈路服務日志，支持了K8s下微服務的日志收集，也支持了Flink Job的日志采集，做到一個日志平臺，匯集全鏈服務日志。然后通過Grafana進行日志查詢、分析；

服務指標采集：我們通過PushGateway將各個微服務，Apache Flink、Impala、Kudu等算存集群指標統(tǒng)一采集到愛番番Prometheus，做到服務實時監(jiān)控&報警。

全鏈路延時監(jiān)控：我們也通過Skywalking Satellite采集RT-CDP全鏈路的數(shù)據(jù)埋點，然后通過自研的打點分析平臺進行延時分析，做到全鏈路數(shù)據(jù)延時可視化和閾值報警。

五、平臺成果

5.1 資產(chǎn)數(shù)據(jù)化

基于RT-CDP解決企業(yè)數(shù)據(jù)孤島問題，幫助企業(yè)將數(shù)據(jù)資產(chǎn)數(shù)字化、多方化、智能化、安全化。

多方化：集成一方數(shù)據(jù)，打通二方數(shù)據(jù)，利用三方數(shù)據(jù)，通過多方數(shù)據(jù)打通，實現(xiàn)更精準、深度的客戶洞察。

數(shù)字化：通過自定義屬性、標簽、模型屬性等將客戶信息全面數(shù)字化管理。

安全化：通過數(shù)據(jù)加密、隱私計算、多方計算實現(xiàn)數(shù)據(jù)安全和隱私保護，保護企業(yè)數(shù)據(jù)資產(chǎn)。

智能化：通過智能模型不斷豐富客戶畫像，服務更多營銷場景。

5.2 高效支撐業(yè)務

1.靈活的數(shù)據(jù)定義能力

RT-CDP在業(yè)務層面具備了靈活的數(shù)據(jù)定義能力，來滿足企業(yè)的個性化需求：

豐富的自定義API，用于可以自定義Schema、屬性、事件等不同場景的數(shù)據(jù)上報結構；

支持了身份類型自定義，方便企業(yè)根據(jù)自身數(shù)據(jù)特定指定潛客標識；

針對不同企業(yè)的不同結構的數(shù)據(jù)可以做到零開發(fā)成本接入。

2.服務于不同行業(yè)企業(yè)的多樣營銷

依托RT-CDP強大數(shù)據(jù)管理能力，愛番番營銷產(chǎn)品已服務于法律、商務服務、教育培訓、電子電工、機械設備、金融、健康美容、生活服務、房產(chǎn)家居、建筑建材、印刷包裝、農(nóng)林牧漁、物流運輸、餐飲食品等數(shù)十個行業(yè)的數(shù)千家企業(yè)，幫助企業(yè)解決了很多營銷難題。成功的企業(yè)案例不勝枚舉。

5.3 架構先進

目前我們完成RT-CDP1.0的建設，并且在一些核心指標上都取得了不錯的效果：

5.3.1 實時高吞吐

Identity Service做到數(shù)十萬QPS的關系查詢，支持上萬TPS的身份裂變。

實時計算做到了數(shù)十萬TPS的實時處理、實時持久化，做到毫秒級延遲。

支持企業(yè)海量數(shù)據(jù)、高并發(fā)下毫秒級實時分析。

真正基于實時流數(shù)據(jù)實現(xiàn)規(guī)則判斷，支撐了私域打標、實時規(guī)則判斷、圈群等多個實時業(yè)務場景，讓營銷毫秒觸達。

5.3.2 高擴展性

平臺架構存算分離，可水平擴展：

基于云原生+Nebula搭建了，可動態(tài)伸縮的圖存儲集群；

借助百度云原生CCE、BMR等云上能力，搭建了存算分離的彈性伸縮的存算集群；

計算集群動態(tài)伸縮，節(jié)約企業(yè)資源成本。

5.3.3 高穩(wěn)定性

各個模塊、各個集群穩(wěn)定性指標長期維持在99.99%以上。

六、未來展望

1.【業(yè)務層面】更多貼近行業(yè)的中臺能力

平臺目前在業(yè)務支撐上已經(jīng)具備了比較好的定義能力。下一步將結合重點服務的企業(yè)行業(yè)，內置更多行業(yè)業(yè)務對象，進一步簡化企業(yè)數(shù)據(jù)接入成本。

在B2B2C數(shù)據(jù)模型上做更多業(yè)務嘗試，更好服務ToB企業(yè)。

2.【業(yè)務層面】更豐富的AI模型

RT-CDP已經(jīng)為企業(yè)提供了智能化的潛客評分能力，支持企業(yè)靈活定義評分規(guī)則。在AI時代，我們將繼續(xù)豐富更多的AI模型來幫助企業(yè)管理、洞察、營銷客戶。

3.【架構層面】更智能化的治理、運維

目前Flink作業(yè)還是基于Yarn管理資源、基于API、腳本方式流程化操作（比如涉及到CK的操作）作業(yè)監(jiān)控通過如流、短信、電話報警。后續(xù)我們將作業(yè)管理、運維上做更多嘗試，比如基于K8s管理Flink作業(yè)、結合如流的Webhook能力完善作業(yè)運維能力等。

在流數(shù)據(jù)驅動下，數(shù)據(jù)處理機制的變化讓數(shù)據(jù)治理、數(shù)據(jù)檢查變得更有挑戰(zhàn)。為了提供更可靠的數(shù)據(jù)服務，還有很多工作要做。

4.【架構層面】湖倉一體到智能湖倉

國內互聯(lián)網(wǎng)公司已經(jīng)有不少數(shù)據(jù)湖技術實踐案例，確實可以解決一些原有數(shù)倉架構的痛點，比如數(shù)據(jù)不支持更新操作，無法做到準實時的數(shù)據(jù)查詢。我們目前也在做Flink 和 Iceberg/Hudi 集成的一些嘗試，后續(xù)會逐步落地。

七、作者

Jimmy：帶著團隊為愛番番奔走的資深工程師。