導讀：隨著營銷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 使用者一起交流圖資料庫技術和應用技能，留下「你的名片」一起玩耍呀~