百度愛番番基於圖技術、流式計算的實時CDP建設實踐 一、CDP是什麼 二、挑戰與目標 三、技術選型 四、平臺架構 五、平臺成果 六、未來展望 七、作者

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

本文系百度愛番番技術團隊撰寫，首發於#百度Geek說#公衆號

一、CDP是什麼

1.1 CDP由來

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

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主要是功能範圍不同，但是類別之間是遞進關係。

主要分爲四類：

• Data CDPs：主要是客戶數據管理，包括多源數據採集、身份識別，以及統一的客戶存儲、訪問控制等。
• 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系統，本文的CDP爲其提供數據支撐。

二、挑戰與目標

2.1 面臨挑戰

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

【業務層面】

1.企業數據渠道多，數據形態各異

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

2.不同生態無法打通，無法360度洞察用戶

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

3.人羣劃分規則複雜

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

4.如何用一個平臺服務好B2B2C、B2C兩類企業，行業可借鑑經驗少

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

【技術層面】

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

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

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

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

3.需要可擴展的架構

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

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

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

5.多樣部署擴展性

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

2.2 RT-CDP建設目標

2.2.1 關鍵業務能力

經過分析和業務抽象，我們覺得，一個真正好的RT-CDP需要做到如下幾個關鍵特徵：

• 靈活的數據對接能力：可以對接客戶各種數據結構多類數據源的客戶系統。另外，數據可以被隨時訪問。
• 同時支持 B2C和B2B兩類數據模型：面向不同的行業客戶，用一套服務支撐。
• 統一的用戶、企業畫像：包含屬性、行爲、標籤（靜態、動態（規則）標籤、預測標籤）、智能評分、偏好模型等等。
• 實時的全渠道身份識別、管理：爲了打破數據孤島，打通多渠道身份，是提供統一用戶的關鍵，也是爲了進行跨渠道用戶營銷的前提。
• 強大的用戶細分能力（用戶分羣）：企業可以根據用戶屬性特徵、行爲、身份、標籤等進行多維度多窗口組合的用戶劃分，進行精準的用戶營銷。
• 用戶的實時交互、激活：面對用戶習慣變化快，實時感知用戶行爲進行實時自動化營銷能力尤爲重要。
• 安全的用戶數據管理：數據長期、安全存儲是數據管理平臺的基本要求。

2.2.2 先進技術架構

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

1.流數據驅動

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

現在系統架構設計如下圖，更傾向於主動驅動其他系統的架構，比如領域事件驅動業務。數據處理亦是需要如此：『數據主動、查詢被動』。

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

傳統方式：先將用戶數據存入存儲引擎，在企業發短信之前再將查詢條件轉換成sql，然後去海量數據中篩選符合條件的用戶。

現代方式：在用戶數據流入數據系統時，進行用戶畫像豐富，然後基於此用戶畫像進行符不符合企業查詢條件的判斷。它只是對單個用戶數據的規則判斷，而不是從海量數據篩選。

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是怎麼做？

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

數據高併發實時寫入能力有限；

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

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

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

隨着數據量增加計算耗時會越來越高，數據結果延遲也會越來越高。

我們怎麼做？

隨着近幾年圖技術的發展，基於圖解決業務問題的案例越來越多，開源圖框架的產品能力、生態集成越來越完善，社區活躍度也越來越高。所以我們嚐鮮基於圖進行身份關係建模，藉助圖自然的多度查詢能力進行實時身份判斷、融合。

圖框架對比

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

網上對 DGraph 和 NebulaGraph 對比很少，這裏簡單說一下區別：

• 集羣架構：DGraph是算存一體的，其存儲是BadgerDB，go實現的對外透明；NebulaGraph讀寫分離，但默認是RocksDB存儲（除非基於源碼更換存儲引擎，也有公司在這麼搞），存在讀寫放大問題；
• 數據切分：DGraph是基於謂詞切分（可以理解爲點類型），容易出現數據熱點，想支持多租戶場景，就需要動態創建租戶粒度謂詞來讓數據分佈儘量均勻（DGraph企業版也支持了多租戶特性，但收費且依然沒考慮熱點問題）；NebulaGraph基於邊切分，基於vid進行partition，不存在熱點問題，但圖空間創建時需要預算好分區個數，不然不好修改分區數。
• 全文檢索：DGraph支持；NebulaGraph提供listener可以對接ES。
• Query語法：DGraph是自己的一個查詢語法；NebulaGraph有自身查詢語法之外，還支持了Cypher語法（Neo4j的圖形查詢語言），更符合圖邏輯表達。
• 事務支持：DGraph基於MVCC支持事務；NebulaGraph不支持，其邊的寫事務也是最新版才支持的（2.6.1）。
• 同步寫：DGraph、NebulaGraph均支持異步、同步寫。
• 集羣穩定性：DGraph集羣更穩定；NebulaGraph的穩定性還有待提升，存在特定運算下偶發Crash的情況。
• 生態集羣：DGraph在生態集成更成熟，比如與雲原生的集成；NebulaGraph在生態集成範圍上更多樣一些，比如nebula-flink-connector、nebula-spark-connector等，但在各類集成的成熟度上還有待提升。

3.2 流式計算引擎選擇

對於主流計算框架的對比，比如Apache Flink、Blink、Spark Streaming、Storm，網上有很多資料，大家也請自行調研就好 ，比如如下，詳見鏈接：
https://blog.csdn.net/weixin_39478115/article/details/111316120

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

使用廣泛的Spark還是以微批的方式進行流計算。而Flink是流的方式。Apache Flink是近幾年發展很快的一個用於分佈式流、批處理數據處理的開源平臺。它是最貼合DataFlow模型實現的分佈式計算框架。基於流計算進行高性能計算，具有良好的容錯、狀態管理機制和高可用能力；其他組件與Flink的集成也越來越多、也日趨成熟；所以選擇我們Apache Flink作爲我們的流批計算引擎。

選擇Apache Beam作爲編程框架

分佈式數據處理技術不斷髮展，優秀的分佈式數據處理框架也會層出不窮。Apache Beam是Google在2016年貢獻給Apache基金會的孵化項目，它的目標是統一批處理和流處理的編程範式，做到企業開發的數據處理程序可以執行在任意的分佈式計算引擎上。Beam在統一編程範式的同時也提供了強大的擴展能力，對新版本計算框架的支持也很及時。所以我們選擇Apache Beam作爲我們的編程框架。

3.3 海量存儲引擎取捨

在Hadoop 生態系統存儲組件中，一般用HDFS支持高吞吐的批處理場景、用HBase支持低延遲，有隨機讀寫需求的場景，但很難只使用一種組件來做到這兩方面能力。另外，如何做到流式計算下的數據實時更新，也影響存儲組件的選擇。Apache Kudu 是 Cloudera 開源的列式存儲引擎，是一種典型的HTAP(在線事務處理/在線分析處理混合模式)。在探索HTAP的方向上，TiDB、Oceanbase均在此行列，只是大家起初側重的場景不同而已，大家也可以對比一下。ApacheKudu的願景是fast analytics on fast and changing data。從Apache Kudu的定位，如下圖可見一斑：

結合我們的平臺建設理念，實時、高吞吐的數據存儲、更新是核心目標，在數據複雜查詢、數據應用的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中客戶分羣規則分類、組合多，規則計算複雜、算子多，時間窗口跨度大、甚至無窗口，業內沒有一個能很好滿足業務需求的開源規則引擎，所以我們選擇了自研。

四、平臺架構

4.1 整體架構

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

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

• 數據源：這裏的數據源不僅包含客戶私有數據，也包括在各個生態上的自有媒體數據，比如微信公衆號、微信小程序、企微線索、百度小程序、抖音企業號、第三方生態行爲數據等。
• 數據採集：大多中小企業沒有研發能力或者很薄弱，如何幫助快速將自有系統對接到愛番番RT-CDP是這層需要重點考慮的，爲此我們封裝了通用的採集SDK來簡化企業的數據採集成本，並且兼容uni-app等優秀前端開發框架。另外，由於數據源多種多樣、數據結構不一，爲了簡化不斷接入的新數據源，我們建設了統一的採集服務，負責管理不斷新增的數據通道，以及數據加解密、清洗、數據轉換等數據加工，這個服務主要是爲了提供靈活的數據接入能力，來降低數據對接成本。
• 實時算存：在採集到數據後就是進行跨渠道數據身份識別，然後轉換成結構化的客戶統一畫像。就數據管理來說，這層也包含企業接入到CDP中的碎片客戶數據，爲了後續企業客戶分析。經過這層處理，會形成跨渠道的客戶身份關係圖、統一畫像，然後再通過統一視圖爲上層數據接口。另外，就是數倉常規的數據質量、資源管理、作業管理、數據安全等功能。
• 數據應用：這層主要是爲企業提供客戶管理、分析洞察等產品功能，比如豐富的潛客畫像、規則自由組合的客戶分羣和靈活的客戶分析等。也提供了多種數據輸出方式，方便各個其他系統使用。
• 公共組件：RT-CDP服務依託愛番番先進的基礎設施，基於雲原生理念管理服務，也藉助愛番番強大的日誌平臺、鏈路追蹤進行服務運維、監控。另外，也基於完備的CICD能力進行CDP能力的快速迭代，從開發到部署都是在敏捷機制下，持續集成、持續交付。

4.2 核心模塊

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

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

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

1.數據源&採集

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

• 實時採集服務：該模塊主要是對接企業已有的自有媒體數據源，愛番番業務系統領域事件以及愛番番合作的第三方平臺。這層主要存在不同媒體平臺API協議、場景化行爲串聯時的業務參數填充、用戶事件不斷增加等問題，我們在該模塊抽象了數據Processor&自定義Processor Plugin等來減少新場景的人工干預。
• Connectors ：該模塊主要是對接企業的自有業務系統的數據源，比如MySQL、Oracle、PG等業務庫，這部分不需要實時接入，只需按批次定時調度即可。這裏需要解決的主要是多不同數據源類型的支持，爲此我們也抽象了Connector和擴展能力，以及通用的調度能力來支持。針對兩種場景下，存在同一個問題：如何應對多樣數據結構的數據快讀快速接入？爲此，我們抽象了數據定義模型（Schema），後面會詳細介紹。

2.數據處理

• Identity Service：該模塊提供跨渠道的客戶識別能力，是一種精準化的ID Mapping,用於實時打通進入RT-CDP的客戶數據。該服務持久化了客戶身份相關關係圖放在NebulaGraph中，會根據實時數據、身份融合策略進行實時、同步更新NebulaGraph，然後將識別結果填充到實時消息。進入CDP數據只有經過Identity Service識別後才繼續往後走，它決定了營銷旅程的客戶交互是否符合預期，也決定了RT-CDP的吞吐上限。
• 實時計算：該模塊包含了所有數據處理、加工、分發等批流作業。目前抽象了基於Apache Beam的作業開發框架，嘗試批流都在Flink上做，但有些運維Job還用了Spark，會逐漸去除。
• 統一畫像：該模塊主要是持久化海量的潛客畫像，對於熱數據存儲在Kudu中，對於溫、冷的時序數據定時轉存到Parquet中。潛客畫像包括客戶屬性、行爲、標籤、所屬客羣、以及聚合的客戶擴展數據等。雖然標籤、客羣是單獨存在的聚合根，但是在存儲層面是一致的存儲機制。另外，標準RT-CDP還應該管理客戶碎片數據，所以統一畫像和數據湖數據如何交互是後續建設的重點。
• 統一查詢服務：在RT-CDP中，客戶數據分散在圖數據庫、Kudu、增強的分析引擎和數據湖，但對用戶來說只有屬性、行爲、標籤、客羣等業務對象，如何支持產品上透明使用？我們通過統一視圖、跨源查詢建設了此統一查詢服務，該服務支持了Impala、Doris、MySQL、Presto、ES等查詢存儲引擎以及API的跨源訪問。
• 實時規則引擎：該模塊主要是基於Flink提供實時規則判斷，來支持圈羣、基於規則的靜態打標、規則標籤等業務場景。

3.數據輸出

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

4.3 關鍵實現

4.3.1 數據定義模型

爲什麼需要Schema？

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

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

Schema是什麼？

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字段。關鍵點就是：

• 事實表只做無業務含義的字段；
• 在數據接入、查詢時通過業務字段（邏輯字段）和事實字段的映射關係進行數據轉換後與前端、租戶交互。

4.3.2 Identity Service

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

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

從架構層面，Identity Service（ID Mapping）基於雲原生+NebulaGraph搭建，做到了租戶數據隔離、實時讀寫、高性能讀寫以及水平擴縮容。

1.雲原生+NebulaGraph

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

• 使用Nebula Operator自動化運維我們k8s下的NebulaGraph集羣；
• 使用Statefulset管理NebulaGraph相關有狀態的節點Pod；
• 每個節點都是使用本地SSD盤來保證圖存儲服務性能。

2.優化讀寫

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

• 設計好數據模型，儘量減少NebulaGraph內部IO次數；
• 合理利用NebulaGraph語法，避免Graphd多餘內存操作；
• 查詢上，儘量減少深度查詢；更新上，控制好寫粒度、降低無事務對業務的影響。

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

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

4.3.3 實時存算

4.3.3.1 流計算

愛番番RT-CDP核心能力都是依託Apache Flink+Kafka實現。在實時流之上進行的流計算，做到毫秒的數據延遲。

核心數據流如上圖，簡化後主要包含如下幾部分：

• 主要採集和格式化的數據，會統一發到cdp-ingest的topic；
• RT-CDP有個統一的入口Job（Entrance Job）負責數據的清洗、校驗、Schema解析以及身份識別等，然後根據租戶屬性進行數據分發。因爲這是RT-CDP入口Job，需要支持橫向擴縮，所以這個作業是無狀態Job。
• 經過數據分發，會有不同的Job羣進行分別的數據處理、持久化，以及數據聚合等數據加工邏輯，一方面豐富潛客畫像，另一方面爲更多維度的潛客圈羣提供數據基礎。
• 最後會將打通的數據分發到下游，下游包括外部系統、數據分析、實時規則引擎、策略模型等多類業務模塊，以便進行更多的實時驅動。

擴展1：數據路由

爲什麼要做路由？

愛番番RT-CDP作爲基礎數據平臺，不僅服務於百度之外的租戶，也服務於百度內部甚至愛番番自己；不僅服務於中小企業，也服務於中大企業。對於前者，服務穩定性要求級別不同，如何避免內外部之間服務能力不相互影響？對於後者，不同規模企業潛客量不同，使用RT-CDP圈人羣等耗時的資源也不同，如何避免資源不公平分配？

我們怎麼做的？

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

擴展2：自定義Trigger批量寫

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

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

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

4.3.3.2 實時存儲

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

擴展1：基於數據分層增強存儲

爲什麼需要分層？

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

分層機制

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

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

具體方案：

• 在熱、溫、冷之上建立統一視圖，上層根據視圖進行數據查詢。
• 然後每天定時進行熱到溫、溫到冷的順序性的分別離線遷移，在分別遷移後會分別進行視圖的實時更新。

擴展2：基於潛客融合路徑的映射關係管理解決數據遷移問題

爲什麼需要管理映射？

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

映射管理機制

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

具體方案：

• 新增一張潛客融合關係表（user_change_rela）維護映射關係；
• 在融合關係表和時序表（比如event）之上創建視圖，做到對業務層透明。

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

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

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-doris-connector是基於Doris的Stream Load方式實現，通過FE redirect到BE進行數據導入處理。我們實際使用flink-doris-connector時，是按10s進行一次Flush、每批次最大可提交百萬行數據的配置進行寫操作。對於 DorisDB 來說，對單次導入大量數據比小批量 flush多次導入數據更友好。

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

擴展1：RoutineLoad和Stream Load區別

Routine Load方式

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

從實現角度來說，是FE負責管理導入Task，Task在BE上通過Stream Load方式進行數據導入。

Stream Load方式

它利用流數據計算框架Flink 消費Kafka的業務數據，使用Stream Load 方式，以HTTP協議向Doris寫入。

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

4.3.4 實時規則引擎

在愛番番私域產品中，靈活的圈羣能力是一個重要產品能力，如何基於潛客屬性、身份、客戶行爲等維度進行復雜、靈活規則的實時分羣？此處的實時規則引擎就是爲此而生。就此功能本身來說，並不新穎，在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旅程節點等各個規則相關的業務場景。

4.3.5 擴展

4.3.5.1 彈性集羣

愛番番RT-CDP的計算、存儲集羣基於百度雲搭建，藉助雲上能力，很好實現了資源的存算分離和動態伸縮。我們可以自定義靈活的資源擴縮策略，根據消息量情況進行資源增減，做到波峯時實時加大集羣規模提供計算能力，波谷時縮減集羣做到及時降本。
圖片

我們的集羣主要分爲四類節點：Master、Core、Task、Client。具體如上圖。

• Master節點：集羣管理節點，部署 NameNode、ResourceManager等進程，並且做到組件故障時的自動遷移；
• Core節點：計算及數據存儲節點，部署 DataNode、NodeManager等進程；
• Task節點：計算節點，用來補充core節點的算力，部署 NodeManger等進程，該節點一般不用來存儲數據，支持按需動態擴容和縮容操作；
• Client節點：獨立的集羣管控節點及作業提交節點。

4.3.5.2 全鏈監控

RT-CDP在建設了完整的鏈路監控能力，能夠實時發現集羣、數據流問題，方便及時干預、處理，爲租戶提供更好的數據服務能力提供保證。也建設了全鏈的日誌收集、分析能力，極大簡化了服務問題排查成本。

具體如上圖，我們依託愛番番強大的技術服務能力完成了跨平臺的日誌採集&報警和全鏈路的延時監控：

• 日誌採集：基於愛番番貢獻給Skywalking的Satellite收集全鏈路服務日誌，支持了K8s下微服務的日誌收集，也支持了Flink Job的日誌採集，做到一個日誌平臺，彙集全鏈服務日誌。然後通過Grafana進行日誌查詢、分析；
• 服務指標採集：我們通過PushGateway將各個微服務，Apache Flink、Impala、Kudu等算存集羣指標統一採集到愛番番Prometheus，做到服務實時監控&報警。
• 全鏈路延時監控：我們也通過Skywalking Satellite採集RT-CDP全鏈路的數據埋點，然後通過自研的打點分析平臺進行延時分析，做到全鏈路數據延時可視化和閾值報警。

五、平臺成果

5.1 資產數據化

基於RT-CDP解決企業數據孤島問題，幫助企業將數據資產數字化、多方化、智能化、安全化。

• 多方化：集成一方數據，打通二方數據，利用三方數據，通過多方數據打通，實現更精準、深度的客戶洞察。
• 數字化：通過自定義屬性、標籤、模型屬性等將客戶信息全面數字化管理。
• 安全化：通過數據加密、隱私計算、多方計算實現數據安全和隱私保護，保護企業數據資產。
• 智能化：通過智能模型不斷豐富客戶畫像，服務更多營銷場景。

5.2 高效支撐業務

1.靈活的數據定義能力

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

• 豐富的自定義API，用於可以自定義Schema、屬性、事件等不同場景的數據上報結構；
• 支持了身份類型自定義，方便企業根據自身數據特定指定潛客標識；
• 針對不同企業的不同結構的數據可以做到零開發成本接入。

2.服務於不同行業企業的多樣營銷

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

5.3 架構先進

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

5.3.1 實時高吞吐

• Identity Service做到數十萬QPS的關係查詢，支持上萬TPS的身份裂變。
• 實時計算做到了數十萬TPS的實時處理、實時持久化，做到毫秒級延遲。
• 支持企業海量數據、高併發下毫秒級實時分析。
• 真正基於實時流數據實現規則判斷，支撐了私域打標、實時規則判斷、圈羣等多個實時業務場景，讓營銷毫秒觸達。

5.3.2 高擴展性

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

• 基於雲原生+NebulaGraph搭建了，可動態伸縮的圖存儲集羣；
• 藉助百度雲原生CCE、BMR等雲上能力，搭建了存算分離的彈性伸縮的存算集羣；
• 計算集羣動態伸縮，節約企業資源成本。

5.3.3 高穩定性

各個模塊、各個集羣穩定性指標長期維持在99.99%以上。

六、未來展望

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

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

在B2B2C數據模型上做更多業務嘗試，更好服務ToB企業。

2.【業務層面】更豐富的AI模型

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

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

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

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

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

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

七、作者

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

---

謝謝你讀完本文 (///▽///)

如果你想嚐鮮圖數據庫 NebulaGraph，記得去 GitHub 下載、使用、(^з)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用戶一起交流圖數據庫技術和應用技能，留下「你的名片」一起玩耍呀~