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

本文系百度愛番番技術(shù)團(tuán)隊撰寫，首發(fā)于#百度Geek說#公眾號

一呛梆、CDP是什么

1.1 CDP由來

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

百度愛番番實時CDP建設(shè)實踐

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

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

1. CRM vs CDP
   • 客戶管理：CRM側(cè)重于銷售跟單代兵；CDP更加側(cè)重于營銷。
   • 觸點：CRM的客戶主要是電話爷狈、QQ植影、郵箱等；CDP還包含租戶的自有媒體關(guān)聯(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給出權(quán)威定義：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è)務(wù)系統(tǒng)數(shù)據(jù)，基于數(shù)據(jù)某些標(biāo)識形成客戶的統(tǒng)一視圖翅睛，長期存儲声搁，并且可以基于客戶行為進(jìn)行個性化營銷。
• Accessible to other systems：企業(yè)可以使用CDP數(shù)據(jù)分析捕发、管理客戶酥艳，并且可以通過多種形式取走重組、加工的客戶數(shù)據(jù)爬骤。

1.3 CDP分類

CDP本身的C（Customer）是指all customer-related functions, not just marketing充石。面向不同場景也對應(yīng)不同類型的CDP，不同類別的CDP主要是功能范圍不同霞玄，但是類別之間是遞進(jìn)關(guān)系骤铃。

百度愛番番實時CDP建設(shè)實踐

主要分為四類：

• Data CDPs：主要是客戶數(shù)據(jù)管理，包括多源數(shù)據(jù)采集坷剧、身份識別惰爬，以及統(tǒng)一的客戶存儲、訪問控制等惫企。
• Analytics CDPs：在包含Data CDPs相關(guān)功能的同時撕瞧，還包括客戶細(xì)分，有時也擴(kuò)展到機(jī)器學(xué)習(xí)狞尔、預(yù)測建模丛版、收入歸因分析等。
• Campaign CDPs：在包含Analytics CDPs相關(guān)功能的同時偏序，還包括跨渠道的客戶策略（Customer Treatments）页畦，比如個性化營銷、內(nèi)容推薦等實時交互動作研儒。
• Delivery CDPs：在包括Campaign CDPs相關(guān)功能的同時豫缨，還包括信息觸達(dá)（Message Delivery）独令，比如郵件、站點好芭、App燃箭、廣告等。

Campaign CDPs舍败、Delivery CDPs兩類較Analytics CDPs多出的功能遍膜，在國內(nèi)更貼近MA（Marketing Automation，營銷自動化）瓤湘。本文所講的CDP從提供的功能范圍來說，屬于Analytics CDPs恩尾。在愛番番也有專門的MA系統(tǒng)弛说，本文的CDP為其提供數(shù)據(jù)支撐。

二翰意、挑戰(zhàn)與目標(biāo)

2.1 面臨挑戰(zhàn)

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

【業(yè)務(wù)層面】

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

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

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

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

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

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

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

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

【技術(shù)層面】

1.全渠道實時精準(zhǔn)識別要求高

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

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

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

3.需要可擴(kuò)展的架構(gòu)

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

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

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

5.多樣部署擴(kuò)展性

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

2.2 RT-CDP建設(shè)目標(biāo)

2.2.1 關(guān)鍵業(yè)務(wù)能力

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

• 靈活的數(shù)據(jù)對接能力：可以對接客戶各種數(shù)據(jù)結(jié)構(gòu)多類數(shù)據(jù)源的客戶系統(tǒng)捐康。另外仇矾，數(shù)據(jù)可以被隨時訪問。
• 同時支持 B2C和B2B兩類數(shù)據(jù)模型：面向不同的行業(yè)客戶解总，用一套服務(wù)支撐贮匕。
• 統(tǒng)一的用戶、企業(yè)畫像：包含屬性花枫、行為刻盐、標(biāo)簽（靜態(tài)、動態(tài)（規(guī)則）標(biāo)簽劳翰、預(yù)測標(biāo)簽）敦锌、智能評分、偏好模型等等佳簸。
• 實時的全渠道身份識別乙墙、管理：為了打破數(shù)據(jù)孤島，打通多渠道身份生均，是提供統(tǒng)一用戶的關(guān)鍵听想，也是為了進(jìn)行跨渠道用戶營銷的前提。
• 強(qiáng)大的用戶細(xì)分能力（用戶分群）：企業(yè)可以根據(jù)用戶屬性特征马胧、行為汉买、身份、標(biāo)簽等進(jìn)行多維度多窗口組合的用戶劃分漓雅，進(jìn)行精準(zhǔn)的用戶營銷录别。
• 用戶的實時交互朽色、激活：面對用戶習(xí)慣變化快邻吞，實時感知用戶行為進(jìn)行實時自動化營銷能力尤為重要。
• 安全的用戶數(shù)據(jù)管理：數(shù)據(jù)長期葫男、安全存儲是數(shù)據(jù)管理平臺的基本要求抱冷。

2.2.2 先進(jìn)技術(shù)架構(gòu)

明確平臺業(yè)務(wù)目標(biāo)的同時，一個先進(jìn)的技術(shù)架構(gòu)也是平臺建設(shè)的目標(biāo)梢褐。如何做到平臺架構(gòu)旺遮，我們有如下幾個核心目標(biāo)：

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

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

現(xiàn)在系統(tǒng)架構(gòu)設(shè)計如下圖铛纬，更傾向于主動驅(qū)動其他系統(tǒng)的架構(gòu)厌均，比如領(lǐng)域事件驅(qū)動業(yè)務(wù)。數(shù)據(jù)處理亦是需要如此：『數(shù)據(jù)主動告唆、查詢被動』棺弊。

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

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

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

百度愛番番實時CDP建設(shè)實踐

2.流計算處理

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

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

3.一體化實踐

【批流一體】

在大數(shù)據(jù)處理領(lǐng)域仔雷，存在兩個典型的架構(gòu)（Lamda蹂析、Kappa抖剿、Kappa+）滥嘴。Lamda架構(gòu)就是批計算片吊、實時計算走兩套計算架構(gòu)，導(dǎo)致有時候有的相同邏輯開發(fā)兩套代碼疮装，容易出現(xiàn)數(shù)據(jù)指標(biāo)不一致喻频，也帶來了維護(hù)困難缩宜。Kappa、Kappa+架構(gòu)是旨在簡化分布式計算架構(gòu)甥温，以實時事件處理架構(gòu)為核心兼顧批流兩種場景锻煌。在大多數(shù)企業(yè)實際生產(chǎn)架構(gòu)中還是兩者混合較多，因為徹底的實時架構(gòu)存在很多難點姻蚓，比如數(shù)據(jù)存儲宋梧、某些批計算更易處理的大窗口聚合計算等。

【統(tǒng)一編程】

在實際業(yè)務(wù)場景中狰挡，批捂龄、流處理依然是同時存在的〖尤考慮到隨著分布式數(shù)據(jù)處理計算發(fā)展倦沧，分布式處理框架也會推陳出新，雖然Apache Flink在批流一體支持上很活躍它匕，但還不太成熟展融。另外，在各個公司多個計算框架并用的情況還是普遍存在豫柬。所以統(tǒng)一數(shù)據(jù)處理編程范式是一個重要的編程選擇告希，可以提高編程靈活性，做到支持批烧给、流場景數(shù)據(jù)處理作業(yè)開發(fā)燕偶，做到一套處理程序可以執(zhí)行在任意的計算框架上，這樣也利于后續(xù)平臺切換更優(yōu)秀的計算引擎创夜。

4.可擴(kuò)展為前提

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

【算存分離】

在如今海量數(shù)據(jù)的大數(shù)據(jù)時代系奉，在不同場景下有時僅需要高處理能力檬贰，有時僅需要海量數(shù)據(jù)存儲。傳統(tǒng)存算一體架構(gòu)缺亮，如果要滿足兩種場景翁涤，就需要高配置（多核、多內(nèi)存、高性能本地盤等）服務(wù)節(jié)點葵礼，顯然存在資源利用不合理号阿，也會引發(fā)集群穩(wěn)定性問題，比如節(jié)點過多導(dǎo)致數(shù)據(jù)分散鸳粉，引發(fā)數(shù)據(jù)一致性降低等扔涧。算存分離的架構(gòu)才符合分布式架構(gòu)的思想，針對業(yè)務(wù)場景進(jìn)行計算資源届谈、存儲資源的分別控制枯夜，實現(xiàn)資源合理分配。也利于集群數(shù)據(jù)一致性艰山、可靠性湖雹、擴(kuò)展性、穩(wěn)定性等方面的能力保證曙搬。

【動態(tài)伸縮】

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

三棘劣、技術(shù)選型

沒有萬能的框架俏让，只有合適的取舍。需要結(jié)合自身業(yè)務(wù)特點和架構(gòu)目標(biāo)進(jìn)行合理選型茬暇。結(jié)合RT-CDP建設(shè)目標(biāo)首昔，我們做了如下幾個核心場景的組件調(diào)研、確定糙俗。

3.1 身份關(guān)系存儲新嘗試

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

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

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

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

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

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

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

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

我們怎么做郑原？

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

圖框架對比

大家也可以結(jié)合最新的圖數(shù)據(jù)庫的排名走勢涣澡，進(jìn)行重點調(diào)研。另外丧诺，關(guān)于主流圖庫對比案例也越來越多入桂，可以自行參考。在分布式驳阎、開源圖數(shù)據(jù)庫中主要是HugeGraph抗愁、DGraph和NebulaGraph。我們在生產(chǎn)環(huán)境主要使用了DGraph和NebulaGraph呵晚。因為愛番番服務(wù)都是基于云原生建設(shè)蜘腌，平臺建設(shè)前期選擇了DGraph，但后來發(fā)現(xiàn)水平擴(kuò)展受限劣纲，不得不從DGraph遷移到NebulaGraph（關(guān)于DGraph到NebulaGraph的遷移逢捺，坑還是挺多的谁鳍，后續(xù)會有專門文章介紹癞季，敬請期待）劫瞳。

百度愛番番實時CDP建設(shè)實踐

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

• 集群架構(gòu)：DGraph是算存一體的绷柒，其存儲是BadgerDB志于，go實現(xiàn)的對外透明；NebulaGraph讀寫分離废睦，但默認(rèn)是RocksDB存儲（除非基于源碼更換存儲引擎伺绽，也有公司在這么搞），存在讀寫放大問題嗜湃；
• 數(shù)據(jù)切分：DGraph是基于謂詞切分（可以理解為點類型）奈应，容易出現(xiàn)數(shù)據(jù)熱點，想支持多租戶場景购披，就需要動態(tài)創(chuàng)建租戶粒度謂詞來讓數(shù)據(jù)分布盡量均勻（DGraph企業(yè)版也支持了多租戶特性杖挣，但收費(fèi)且依然沒考慮熱點問題）；NebulaGraph基于邊切分刚陡，基于vid進(jìn)行partition惩妇，不存在熱點問題，但圖空間創(chuàng)建時需要預(yù)算好分區(qū)個數(shù)筐乳，不然不好修改分區(qū)數(shù)歌殃。
• 全文檢索：DGraph支持；NebulaGraph提供listener可以對接ES蝙云。
• Query語法：DGraph是自己的一個查詢語法氓皱；NebulaGraph有自身查詢語法之外，還支持了Cypher語法（Neo4j的圖形查詢語言）勃刨，更符合圖邏輯表達(dá)匀泊。
• 事務(wù)支持：DGraph基于MVCC支持事務(wù)；NebulaGraph不支持朵你，其邊的寫事務(wù)也是最新版才支持的（2.6.1）各聘。
• 同步寫：DGraph、NebulaGraph均支持異步抡医、同步寫躲因。
• 集群穩(wěn)定性：DGraph集群更穩(wěn)定；NebulaGraph的穩(wěn)定性還有待提升忌傻，存在特定運(yùn)算下偶發(fā)Crash的情況大脉。
• 生態(tài)集群：DGraph在生態(tài)集成更成熟，比如與云原生的集成水孩；NebulaGraph在生態(tài)集成范圍上更多樣一些镰矿，比如nebula-flink-connector、nebula-spark-connector等俘种，但在各類集成的成熟度上還有待提升秤标。

3.2 流式計算引擎選擇

對于主流計算框架的對比绝淡，比如Apache Flink、Blink苍姜、Spark Streaming牢酵、Storm，網(wǎng)上有很多資料衙猪，大家也請自行調(diào)研就好 馍乙，比如如下，詳見鏈接：
https://blog.csdn.net/weixin_39478115/article/details/111316120

百度愛番番實時CDP建設(shè)實踐

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

使用廣泛的Spark還是以微批的方式進(jìn)行流計算垫释。而Flink是流的方式丝格。Apache Flink是近幾年發(fā)展很快的一個用于分布式流、批處理數(shù)據(jù)處理的開源平臺棵譬。它是最貼合DataFlow模型實現(xiàn)的分布式計算框架铁追。基于流計算進(jìn)行高性能計算茫船，具有良好的容錯琅束、狀態(tài)管理機(jī)制和高可用能力；其他組件與Flink的集成也越來越多算谈、也日趨成熟涩禀；所以選擇我們Apache Flink作為我們的流批計算引擎。

選擇Apache Beam作為編程框架

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

百度愛番番實時CDP建設(shè)實踐

3.3 海量存儲引擎取舍

在Hadoop 生態(tài)系統(tǒng)存儲組件中，一般用HDFS支持高吞吐的批處理場景带欢、用HBase支持低延遲运授，有隨機(jī)讀寫需求的場景，但很難只使用一種組件來做到這兩方面能力乔煞。另外吁朦，如何做到流式計算下的數(shù)據(jù)實時更新，也影響存儲組件的選擇渡贾。Apache Kudu 是 Cloudera 開源的列式存儲引擎逗宜，是一種典型的HTAP(在線事務(wù)處理/在線分析處理混合模式)。在探索HTAP的方向上，TiDB纺讲、Oceanbase均在此行列擂仍，只是大家起初側(cè)重的場景不同而已，大家也可以對比一下刻诊。ApacheKudu的愿景是fast analytics on fast and changing data防楷。從Apache Kudu的定位牺丙，如下圖可見一斑：

百度愛番番實時CDP建設(shè)實踐

結(jié)合我們的平臺建設(shè)理念则涯，實時、高吞吐的數(shù)據(jù)存儲冲簿、更新是核心目標(biāo)粟判，在數(shù)據(jù)復(fù)雜查詢、數(shù)據(jù)應(yīng)用的QPS上不高（因為核心的業(yè)務(wù)場景是基于實時流的實時客戶處理）峦剔，再加上Cloudera Impala無縫集成Kudu档礁，我們最終確定Impala+Kudu作為平臺的數(shù)據(jù)存儲、查詢引擎吝沫。

分析增強(qiáng)：Doris

基于Impala+Kudu的選型呻澜，在支持OP部署時是完全沒有問題的，因為各個企業(yè)的數(shù)據(jù)體量惨险、數(shù)據(jù)查詢QPS都有限羹幸。這樣企業(yè)只需要很簡單的架構(gòu)就可以支持其數(shù)據(jù)管理需求，提高了平臺穩(wěn)定性辫愉、可靠性栅受，同時也可以降低企業(yè)運(yùn)維、資源成本恭朗。但由于Impala并發(fā)能力有限（當(dāng)然在Impala4.0開始引入多線程屏镊，并發(fā)處理能力提升不少），愛番番的私域服務(wù)目前還是以Saas服務(wù)為重痰腮，想在Saas場景下做到高并發(fā)下的毫秒級數(shù)據(jù)分析而芥，這種架構(gòu)性能很難達(dá)標(biāo)，所以我們在分析場景引入了分析引擎Doris膀值。之所以選擇Doris蔚出，基于 MPP 架構(gòu)的 OLAP 引擎。相對于Druid虫腋、ClickHouse等開源分析引擎骄酗，Doris具有如下特點：l支持多種數(shù)據(jù)模型，包括聚合模型悦冀、Uniq模型趋翻、Duplicate模型；l支持Rollup盒蟆、物化視圖踏烙；l在單表师骗、多表上的查詢性能都表現(xiàn)很好；l支持MySQL協(xié)議讨惩，接入辟癌、學(xué)習(xí)成本低；l無需集成Hadoop生態(tài)荐捻，集群運(yùn)維成本也低很多黍少。

3.4 規(guī)則引擎調(diào)研

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

百度愛番番實時CDP建設(shè)實踐

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

四海铆、平臺架構(gòu)

4.1 整體架構(gòu)

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

百度愛番番實時CDP建設(shè)實踐

RT-CDP也是就兩部分功能進(jìn)行拆分唇辨，主要包含五部分：數(shù)據(jù)源廊酣、數(shù)據(jù)采集、實時數(shù)倉赏枚，數(shù)據(jù)應(yīng)用和公共組件亡驰，除公共組件部分是橫向支撐外，其他四部分就是標(biāo)準(zhǔn)的數(shù)據(jù)對接到數(shù)據(jù)應(yīng)用的四個階段：

• 數(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ù)結(jié)構(gòu)不一芒篷，為了簡化不斷接入的新數(shù)據(jù)源，我們建設(shè)了統(tǒng)一的采集服務(wù)膀斋，負(fù)責(zé)管理不斷新增的數(shù)據(jù)通道梭伐，以及數(shù)據(jù)加解密痹雅、清洗仰担、數(shù)據(jù)轉(zhuǎn)換等數(shù)據(jù)加工，這個服務(wù)主要是為了提供靈活的數(shù)據(jù)接入能力绩社，來降低數(shù)據(jù)對接成本摔蓝。
• 實時算存：在采集到數(shù)據(jù)后就是進(jìn)行跨渠道數(shù)據(jù)身份識別，然后轉(zhuǎn)換成結(jié)構(gòu)化的客戶統(tǒng)一畫像愉耙。就數(shù)據(jù)管理來說贮尉，這層也包含企業(yè)接入到CDP中的碎片客戶數(shù)據(jù)，為了后續(xù)企業(yè)客戶分析朴沿。經(jīng)過這層處理猜谚，會形成跨渠道的客戶身份關(guān)系圖、統(tǒng)一畫像赌渣，然后再通過統(tǒng)一視圖為上層數(shù)據(jù)接口魏铅。另外，就是數(shù)倉常規(guī)的數(shù)據(jù)質(zhì)量坚芜、資源管理览芳、作業(yè)管理、數(shù)據(jù)安全等功能鸿竖。
• 數(shù)據(jù)應(yīng)用：這層主要是為企業(yè)提供客戶管理沧竟、分析洞察等產(chǎn)品功能，比如豐富的潛客畫像缚忧、規(guī)則自由組合的客戶分群和靈活的客戶分析等悟泵。也提供了多種數(shù)據(jù)輸出方式，方便各個其他系統(tǒng)使用闪水。
• 公共組件：RT-CDP服務(wù)依托愛番番先進(jìn)的基礎(chǔ)設(shè)施糕非，基于云原生理念管理服務(wù)，也借助愛番番強(qiáng)大的日志平臺、鏈路追蹤進(jìn)行服務(wù)運(yùn)維峰弹、監(jiān)控店量。另外，也基于完備的CICD能力進(jìn)行CDP能力的快速迭代鞠呈，從開發(fā)到部署都是在敏捷機(jī)制下融师，持續(xù)集成、持續(xù)交付蚁吝。

4.2 核心模塊

簡單來說旱爆，RT-CDP實現(xiàn)的功能就是多渠道數(shù)據(jù)的實時、定時采集窘茁，然后經(jīng)過數(shù)據(jù)中身份的識別Identity服務(wù)怀伦，再進(jìn)行數(shù)據(jù)處理、數(shù)據(jù)進(jìn)行數(shù)據(jù)映射山林、加工（比如維度Join懂版、數(shù)據(jù)聚合羊苟、數(shù)據(jù)分層等），然后進(jìn)行結(jié)構(gòu)化持久化，最后對外實時輸出饮亏。

百度愛番番實時CDP建設(shè)實踐

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

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

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

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

• 實時采集服務(wù)：該模塊主要是對接企業(yè)已有的自有媒體數(shù)據(jù)源次员，愛番番業(yè)務(wù)系統(tǒng)領(lǐng)域事件以及愛番番合作的第三方平臺。這層主要存在不同媒體平臺API協(xié)議王带、場景化行為串聯(lián)時的業(yè)務(wù)參數(shù)填充淑蔚、用戶事件不斷增加等問題，我們在該模塊抽象了數(shù)據(jù)Processor&自定義Processor Plugin等來減少新場景的人工干預(yù)愕撰。
• Connectors ：該模塊主要是對接企業(yè)的自有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源刹衫，比如MySQL醋寝、Oracle、PG等業(yè)務(wù)庫带迟，這部分不需要實時接入音羞，只需按批次定時調(diào)度即可。這里需要解決的主要是多不同數(shù)據(jù)源類型的支持仓犬，為此我們也抽象了Connector和擴(kuò)展能力嗅绰，以及通用的調(diào)度能力來支持。針對兩種場景下搀继，存在同一個問題：如何應(yīng)對多樣數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)快讀快速接入窘面？為此，我們抽象了數(shù)據(jù)定義模型（Schema）叽躯，后面會詳細(xì)介紹财边。

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

• Identity Service：該模塊提供跨渠道的客戶識別能力，是一種精準(zhǔn)化的ID Mapping,用于實時打通進(jìn)入RT-CDP的客戶數(shù)據(jù)点骑。該服務(wù)持久化了客戶身份相關(guān)關(guān)系圖放在NebulaGraph中酣难，會根據(jù)實時數(shù)據(jù)、身份融合策略進(jìn)行實時畔况、同步更新NebulaGraph鲸鹦，然后將識別結(jié)果填充到實時消息慧库。進(jìn)入CDP數(shù)據(jù)只有經(jīng)過Identity Service識別后才繼續(xù)往后走跷跪，它決定了營銷旅程的客戶交互是否符合預(yù)期，也決定了RT-CDP的吞吐上限齐板。
• 實時計算：該模塊包含了所有數(shù)據(jù)處理吵瞻、加工、分發(fā)等批流作業(yè)甘磨。目前抽象了基于Apache Beam的作業(yè)開發(fā)框架橡羞，嘗試批流都在Flink上做，但有些運(yùn)維Job還用了Spark济舆，會逐漸去除卿泽。
• 統(tǒng)一畫像：該模塊主要是持久化海量的潛客畫像，對于熱數(shù)據(jù)存儲在Kudu中滋觉，對于溫签夭、冷的時序數(shù)據(jù)定時轉(zhuǎn)存到Parquet中。潛客畫像包括客戶屬性椎侠、行為第租、標(biāo)簽、所屬客群我纪、以及聚合的客戶擴(kuò)展數(shù)據(jù)等慎宾。雖然標(biāo)簽丐吓、客群是單獨存在的聚合根，但是在存儲層面是一致的存儲機(jī)制趟据。另外券犁，標(biāo)準(zhǔn)RT-CDP還應(yīng)該管理客戶碎片數(shù)據(jù)，所以統(tǒng)一畫像和數(shù)據(jù)湖數(shù)據(jù)如何交互是后續(xù)建設(shè)的重點汹碱。
• 統(tǒng)一查詢服務(wù)：在RT-CDP中族操，客戶數(shù)據(jù)分散在圖數(shù)據(jù)庫、Kudu比被、增強(qiáng)的分析引擎和數(shù)據(jù)湖色难，但對用戶來說只有屬性、行為等缀、標(biāo)簽枷莉、客群等業(yè)務(wù)對象，如何支持產(chǎn)品上透明使用尺迂？我們通過統(tǒng)一視圖笤妙、跨源查詢建設(shè)了此統(tǒng)一查詢服務(wù)，該服務(wù)支持了Impala噪裕、Doris蹲盘、MySQL、Presto膳音、ES等查詢存儲引擎以及API的跨源訪問召衔。
• 實時規(guī)則引擎：該模塊主要是基于Flink提供實時規(guī)則判斷，來支持圈群祭陷、基于規(guī)則的靜態(tài)打標(biāo)苍凛、規(guī)則標(biāo)簽等業(yè)務(wù)場景。

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

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

4.3 關(guān)鍵實現(xiàn)

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

為什么需要Schema今阳？

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

另外，RT-CDP本身管理兩類數(shù)據(jù)：碎片化客戶數(shù)據(jù)和用戶統(tǒng)一畫像妖谴。對于前者來說窿锉，不需要關(guān)系數(shù)據(jù)內(nèi)容本身，利用數(shù)據(jù)湖等技術(shù)即可為企業(yè)提供數(shù)據(jù)存儲膝舅、查詢嗡载、分析能力，是偏Schemaless的數(shù)據(jù)管理仍稀；對于后者來說洼滚，更多需要按不同維度組合查詢、圈群技潘、分析遥巴，本身需要結(jié)構(gòu)化的數(shù)據(jù)管理。后者能否通過Schemaless的方式提供服務(wù)呢享幽？羅列增刪改查的場景铲掐，反證一下局限明顯。

Schema是什么值桩？

Schema是一個數(shù)據(jù)結(jié)構(gòu)的描述摆霉，Schema可以相互引用，可以對數(shù)據(jù)中字段以及字段類型颠毙、值進(jìn)行約束斯入，也可以自定義字段。企業(yè)可以用一個統(tǒng)一的規(guī)范快速接入蛀蜜、靈活管理自己的數(shù)據(jù)，比如企業(yè)可以根據(jù)自己的行業(yè)特性增蹭，抽象不同的業(yè)務(wù)實體滴某、屬性，再給不同的業(yè)務(wù)實體定義不同的Schema滋迈。企業(yè)可以對業(yè)務(wù)實體有交集的信息抽離新Schema霎奢，然后多個Schema引用這個新Schema；也可以對每個Schema自定義自己的業(yè)務(wù)字段饼灿。企業(yè)只需要按相應(yīng)的Schema結(jié)構(gòu)接入數(shù)據(jù)幕侠，就可以按特定的標(biāo)準(zhǔn)使用這些數(shù)據(jù)。

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

• Field：字段是最基本的數(shù)據(jù)單元晤硕，是組成Schema的最小粒度元素悼潭。
• Schema：是一組字段、Schema的集合舞箍，它本身可以包含多個字段（Field）舰褪，字段可以自定義，比如字段名疏橄、類型占拍、值列表等；也可以引用一個或多個其他Schema捎迫，引用時也可以以數(shù)組的形式承載晃酒，比如一個Schema里面可以包含多個Identity結(jié)構(gòu)的數(shù)據(jù)。
• Behavior：是潛客或企業(yè)的不同行為窄绒，本身也是通過Schema承載掖疮，不同的Behavior也可以自定義其特有的Field。

百度愛番番實時CDP建設(shè)實踐

在上圖所示颗祝，愛番番RT-CDP在進(jìn)行行業(yè)抽象后浊闪，已經(jīng)內(nèi)置了很多行業(yè)通用的Schema，包括常見的Identity螺戳、Profile搁宾、Behavior等多類Schema。在愛番番RT-CDP管理的統(tǒng)一潛客畫像中倔幼，Identity盖腿、Profile、Tag损同、Segment等都業(yè)務(wù)聚合根翩腐。為了支持好B、C兩種數(shù)據(jù)模型還有一些B粒度聚合根存在膏燃。

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

這里需要先說一個Dataset的概念。Dataset是通過Schema定義結(jié)構(gòu)的一個數(shù)據(jù)集组哩，企業(yè)對不同的數(shù)據(jù)源定義成不同的數(shù)據(jù)集等龙。在數(shù)據(jù)源管理時，企業(yè)可以根據(jù)不同的數(shù)據(jù)集結(jié)構(gòu)化導(dǎo)入的數(shù)據(jù)伶贰，一個數(shù)據(jù)集可以對應(yīng)多個數(shù)據(jù)源蛛砰，也可以對應(yīng)一個數(shù)據(jù)源中的一類數(shù)據(jù)，一般后者使用較多黍衙。另外泥畅，一個數(shù)據(jù)集也可以包含多批次的數(shù)據(jù)，也就是企業(yè)可以周期性的按批次導(dǎo)入同一數(shù)據(jù)集數(shù)據(jù)琅翻。在數(shù)據(jù)接入時位仁，如下圖柑贞，針對不同的Dataset，企業(yè)可以綁定不同的Schema障癌，每個Schema可以引用凌外、復(fù)用其他子Schema，然后經(jīng)過RT-CDP的Schema解析涛浙，自動將數(shù)據(jù)持久化到存儲引擎康辑，根據(jù)數(shù)據(jù)的定義不同，會持久化到不同數(shù)據(jù)表中轿亮。對應(yīng)實時的客戶行為也是通過定義不同的Schema來定義數(shù)據(jù)結(jié)構(gòu)疮薇，然后進(jìn)行持續(xù)的數(shù)據(jù)接入。

百度愛番番實時CDP建設(shè)實踐

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

存在的問題是什么我注？

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

我們的解決方案是什么抱怔？

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

• 事實表只做無業(yè)務(wù)含義的字段绕沈；
• 在數(shù)據(jù)接入、查詢時通過業(yè)務(wù)字段（邏輯字段）和事實字段的映射關(guān)系進(jìn)行數(shù)據(jù)轉(zhuǎn)換后與前端帮寻、租戶交互乍狐。

4.3.2 Identity Service

這個服務(wù)也可以稱之為ID Mapping。但相對于傳統(tǒng)的ID Mapping來說固逗，因為業(yè)務(wù)場景的不同浅蚪，功能側(cè)重也有所不同藕帜。傳統(tǒng)意義的ID Mapping更多是廣告場景的匿名數(shù)據(jù)的，基于復(fù)雜模型的離線和預(yù)測識別惜傲；CDP中的ID Mapping是基于更精準(zhǔn)的數(shù)據(jù)身份標(biāo)識洽故，進(jìn)行更精準(zhǔn)打通，更加要求打通率和實時性盗誊。

百度愛番番實時CDP建設(shè)實踐

為此时甚，我們設(shè)計了支持B2B2C、B2C兩種業(yè)務(wù)的身份關(guān)系模型哈踱。在標(biāo)準(zhǔn)化租戶數(shù)據(jù)接入后荒适，基于不斷接入的數(shù)據(jù)新增持續(xù)的身份關(guān)系圖譜裂變。在功能層面开镣，我們支持自定義身份類型以及身份權(quán)重刀诬，也支持針對不同身份租戶自定義身份融合動作。另外邪财，根據(jù)我們對行業(yè)分析陕壹，內(nèi)置了常見的身份及融合策略，方便租戶直接使用树埠。

百度愛番番實時CDP建設(shè)實踐

從架構(gòu)層面糠馆，Identity Service（ID Mapping）基于云原生+NebulaGraph搭建，做到了租戶數(shù)據(jù)隔離弥奸、實時讀寫榨惠、高性能讀寫以及水平擴(kuò)縮容。

1.云原生+NebulaGraph

將NebulaGraph部署到K8s下盛霎，降低運(yùn)維成本赠橙。我們主要是：

• 使用Nebula Operator自動化運(yùn)維我們k8s下的NebulaGraph集群；
• 使用Statefulset管理NebulaGraph相關(guān)有狀態(tài)的節(jié)點Pod愤炸；
• 每個節(jié)點都是使用本地SSD盤來保證圖存儲服務(wù)性能期揪。

2.優(yōu)化讀寫

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

• 設(shè)計好數(shù)據(jù)模型诞仓，盡量減少NebulaGraph內(nèi)部IO次數(shù)缤苫；
• 合理利用NebulaGraph語法，避免Graphd多余內(nèi)存操作墅拭；
• 查詢上活玲，盡量減少深度查詢；更新上，控制好寫粒度舒憾、降低無事務(wù)對業(yè)務(wù)的影響镀钓。

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

針對一個人多設(shè)備場景，單設(shè)備被多人使用的場景镀迂，我們采用離線矯正的方式進(jìn)行打通丁溅。

百度愛番番實時CDP建設(shè)實踐

4.3.3 實時存算

4.3.3.1 流計算

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

百度愛番番實時CDP建設(shè)實踐

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

• 主要采集和格式化的數(shù)據(jù)别凤，會統(tǒng)一發(fā)到cdp-ingest的topic饰序；
• RT-CDP有個統(tǒng)一的入口Job（Entrance Job）負(fù)責(zé)數(shù)據(jù)的清洗、校驗规哪、Schema解析以及身份識別等求豫，然后根據(jù)租戶屬性進(jìn)行數(shù)據(jù)分發(fā)。因為這是RT-CDP入口Job诉稍，需要支持橫向擴(kuò)縮蝠嘉，所以這個作業(yè)是無狀態(tài)Job。
• 經(jīng)過數(shù)據(jù)分發(fā)杯巨，會有不同的Job群進(jìn)行分別的數(shù)據(jù)處理蚤告、持久化，以及數(shù)據(jù)聚合等數(shù)據(jù)加工邏輯服爷，一方面豐富潛客畫像杜恰，另一方面為更多維度的潛客圈群提供數(shù)據(jù)基礎(chǔ)。
• 最后會將打通的數(shù)據(jù)分發(fā)到下游仍源，下游包括外部系統(tǒng)心褐、數(shù)據(jù)分析、實時規(guī)則引擎笼踩、策略模型等多類業(yè)務(wù)模塊逗爹，以便進(jìn)行更多的實時驅(qū)動。

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

為什么要做路由嚎于？

愛番番RT-CDP作為基礎(chǔ)數(shù)據(jù)平臺掘而，不僅服務(wù)于百度之外的租戶，也服務(wù)于百度內(nèi)部甚至愛番番自己于购；不僅服務(wù)于中小企業(yè)袍睡，也服務(wù)于中大企業(yè)。對于前者肋僧，服務(wù)穩(wěn)定性要求級別不同覆山，如何避免內(nèi)外部之間服務(wù)能力不相互影響钢颂？對于后者锯仪，不同規(guī)模企業(yè)潛客量不同蜒简，使用RT-CDP圈人群等耗時的資源也不同锡凝，如何避免資源不公平分配芍秆？

我們怎么做的？

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

擴(kuò)展2：自定義Trigger批量寫

在隨機(jī)讀寫上愿吹，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ù)捷沸。我們主要分類兩個集群進(jìn)行數(shù)據(jù)存儲，一個集群存儲潛客統(tǒng)一畫像和具有時序?qū)傩缘臒釘?shù)據(jù)狐史，另一個集群存儲冷數(shù)據(jù)和用于離線計算的數(shù)據(jù)痒给。每個集群都集成了數(shù)據(jù)湖的能力说墨。然后我們研發(fā)了統(tǒng)一的Query Engine，支持跨源苍柏、跨集群的數(shù)據(jù)查詢尼斧，對底層存儲引擎透明。

百度愛番番實時CDP建設(shè)實踐

擴(kuò)展1：基于數(shù)據(jù)分層增強(qiáng)存儲

為什么需要分層序仙？

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

分層機(jī)制

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

根據(jù)數(shù)據(jù)使用頻率柜裸，我們將數(shù)據(jù)分為熱缕陕、溫、冷三層疙挺。熱數(shù)據(jù)扛邑，表示租戶經(jīng)常使用的數(shù)據(jù)，時間范圍為三個月內(nèi)铐然；溫數(shù)據(jù)蔬崩，表示使用頻率較低的數(shù)據(jù)愿伴，一般只用于個別客群的圈選胞此，時間范圍為三個月外到一年；冷數(shù)據(jù)哪痰，租戶基本不使用的數(shù)據(jù)自点，時間范圍為一年之外桐罕。為了平衡性能，我們將熱桂敛、溫數(shù)據(jù)存放在同一個集群功炮，將冷數(shù)據(jù)放在另外集群（和提供給策略模型的集群放在一個集群）。

具體方案：

• 在熱埠啃、溫死宣、冷之上建立統(tǒng)一視圖，上層根據(jù)視圖進(jìn)行數(shù)據(jù)查詢碴开。
• 然后每天定時進(jìn)行熱到溫毅该、溫到冷的順序性的分別離線遷移博秫，在分別遷移后會分別進(jìn)行視圖的實時更新。

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

為什么需要管理映射眶掌？

潛客畫像行為數(shù)據(jù)很多挡育，也可能存在頻繁融合的情況，如果在潛客融合時朴爬，每次都遷移數(shù)據(jù)即寒，一方面數(shù)據(jù)遷移成本很高，另一方面召噩，當(dāng)潛客行為涉及溫冷數(shù)據(jù)時母赵，是無法進(jìn)行刪除操作的。業(yè)內(nèi)針對類似情況具滴，更多會有所取舍凹嘲，比如只遷移用戶僅一段時間的熱數(shù)據(jù)，再往前的歷史不做處理构韵。這種解決方案并不理想周蹭。

映射管理機(jī)制

為此，我們換了種思路疲恢，通過維護(hù)潛客融合路徑的方式方式解決該問題凶朗。

具體方案：

• 新增一張潛客融合關(guān)系表（user_change_rela）維護(hù)映射關(guān)系；
• 在融合關(guān)系表和時序表（比如event）之上創(chuàng)建視圖显拳，做到對業(yè)務(wù)層透明棚愤。

百度愛番番實時CDP建設(shè)實踐

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

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

百度愛番番實時CDP建設(shè)實踐

4.3.3.3 分析增強(qiáng)

我們選擇百度開源的Apache Doris作為數(shù)據(jù)增強(qiáng)的分析引擎羊精，為愛番番拓客版提供客戶洞察能力斯够，比如旅程分析、人群喧锦、營銷效果分析读规、裂變分析、直播分析等燃少。

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

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

• 使用flink-doris-connector往Doris寫數(shù)據(jù)揣炕，比使用Routine Load方式少一次Kafka。
• 使用flink-doris-connector比Routine Load方式在數(shù)據(jù)處理上东跪，也能更加靈活畸陡。

百度愛番番實時CDP建設(shè)實踐

Flink-doris-connector是基于Doris的Stream Load方式實現(xiàn)，通過FE redirect到BE進(jìn)行數(shù)據(jù)導(dǎo)入處理虽填。我們實際使用flink-doris-connector時丁恭，是按10s進(jìn)行一次Flush、每批次最大可提交百萬行數(shù)據(jù)的配置進(jìn)行寫操作卤唉。對于 DorisDB 來說涩惑，對單次導(dǎo)入大量數(shù)據(jù)比小批量 flush多次導(dǎo)入數(shù)據(jù)更友好。

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

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

Routine Load方式

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

從實現(xiàn)角度來說赊级，是FE負(fù)責(zé)管理導(dǎo)入Task押框，Task在BE上通過Stream Load方式進(jìn)行數(shù)據(jù)導(dǎo)入。

Stream Load方式

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

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

4.3.4 實時規(guī)則引擎

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

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

面臨的問題是什么弱左？

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

• 海量數(shù)據(jù)實時判斷
• 窗口粒度數(shù)據(jù)聚合的內(nèi)存占用問題
• 滑動窗口下的窗口風(fēng)暴
• 無窗口規(guī)則的數(shù)據(jù)聚合問題
• 潛客數(shù)據(jù)變更后的窗口數(shù)據(jù)更新
• 實時規(guī)則引擎實現(xiàn)

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

百度愛番番實時CDP建設(shè)實踐

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

百度愛番番實時CDP建設(shè)實踐

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

4.3.5 擴(kuò)展

4.3.5.1 彈性集群

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

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

• Master節(jié)點：集群管理節(jié)點务甥，部署 NameNode牡辽、ResourceManager等進(jìn)程，并且做到組件故障時的自動遷移敞临；
• Core節(jié)點：計算及數(shù)據(jù)存儲節(jié)點态辛，部署 DataNode、NodeManager等進(jìn)程挺尿；
• Task節(jié)點：計算節(jié)點奏黑，用來補(bǔ)充core節(jié)點的算力，部署 NodeManger等進(jìn)程编矾，該節(jié)點一般不用來存儲數(shù)據(jù)熟史，支持按需動態(tài)擴(kuò)容和縮容操作；
• Client節(jié)點：獨立的集群管控節(jié)點及作業(yè)提交節(jié)點窄俏。

4.3.5.2 全鏈監(jiān)控

RT-CDP在建設(shè)了完整的鏈路監(jiān)控能力蹂匹，能夠?qū)崟r發(fā)現(xiàn)集群、數(shù)據(jù)流問題凹蜈，方便及時干預(yù)限寞、處理忍啸，為租戶提供更好的數(shù)據(jù)服務(wù)能力提供保證。也建設(shè)了全鏈的日志收集履植、分析能力计雌，極大簡化了服務(wù)問題排查成本。

百度愛番番實時CDP建設(shè)實踐

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

• 日志采集：基于愛番番貢獻(xiàn)給Skywalking的Satellite收集全鏈路服務(wù)日志凿滤，支持了K8s下微服務(wù)的日志收集，也支持了Flink Job的日志采集鼠渺，做到一個日志平臺鸭巴，匯集全鏈服務(wù)日志。然后通過Grafana進(jìn)行日志查詢拦盹、分析鹃祖；
• 服務(wù)指標(biāo)采集：我們通過PushGateway將各個微服務(wù)，Apache Flink普舆、Impala恬口、Kudu等算存集群指標(biāo)統(tǒng)一采集到愛番番Prometheus，做到服務(wù)實時監(jiān)控&報警沼侣。
• 全鏈路延時監(jiān)控：我們也通過Skywalking Satellite采集RT-CDP全鏈路的數(shù)據(jù)埋點祖能，然后通過自研的打點分析平臺進(jìn)行延時分析，做到全鏈路數(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)更精準(zhǔn)、深度的客戶洞察熔任。
• 數(shù)字化：通過自定義屬性褒链、標(biāo)簽、模型屬性等將客戶信息全面數(shù)字化管理笋敞。
• 安全化：通過數(shù)據(jù)加密碱蒙、隱私計算、多方計算實現(xiàn)數(shù)據(jù)安全和隱私保護(hù)，保護(hù)企業(yè)數(shù)據(jù)資產(chǎn)赛惩。
• 智能化：通過智能模型不斷豐富客戶畫像哀墓，服務(wù)更多營銷場景。

5.2 高效支撐業(yè)務(wù)

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

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

• 豐富的自定義API篮绰，用于可以自定義Schema、屬性季惯、事件等不同場景的數(shù)據(jù)上報結(jié)構(gòu)吠各；
• 支持了身份類型自定義，方便企業(yè)根據(jù)自身數(shù)據(jù)特定指定潛客標(biāo)識勉抓；
• 針對不同企業(yè)的不同結(jié)構(gòu)的數(shù)據(jù)可以做到零開發(fā)成本接入贾漏。

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

依托RT-CDP強(qiáng)大數(shù)據(jù)管理能力，愛番番營銷產(chǎn)品已服務(wù)于法律藕筋、商務(wù)服務(wù)纵散、教育培訓(xùn)、電子電工隐圾、機(jī)械設(shè)備伍掀、金融、健康美容暇藏、生活服務(wù)蜜笤、房產(chǎn)家居、建筑建材盐碱、印刷包裝把兔、農(nóng)林牧漁、物流運(yùn)輸瓮顽、餐飲食品等數(shù)十個行業(yè)的數(shù)千家企業(yè)垛贤，幫助企業(yè)解決了很多營銷難題。成功的企業(yè)案例不勝枚舉趣倾。

image.png

5.3 架構(gòu)先進(jìn)

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

5.3.1 實時高吞吐

• Identity Service做到數(shù)十萬QPS的關(guān)系查詢某饰，支持上萬TPS的身份裂變儒恋。
• 實時計算做到了數(shù)十萬TPS的實時處理、實時持久化黔漂，做到毫秒級延遲诫尽。
• 支持企業(yè)海量數(shù)據(jù)、高并發(fā)下毫秒級實時分析炬守。
• 真正基于實時流數(shù)據(jù)實現(xiàn)規(guī)則判斷牧嫉，支撐了私域打標(biāo)、實時規(guī)則判斷、圈群等多個實時業(yè)務(wù)場景酣藻，讓營銷毫秒觸達(dá)曹洽。

5.3.2 高擴(kuò)展性

平臺架構(gòu)存算分離，可水平擴(kuò)展：

• 基于云原生+NebulaGraph搭建了辽剧，可動態(tài)伸縮的圖存儲集群送淆；
• 借助百度云原生CCE、BMR等云上能力怕轿，搭建了存算分離的彈性伸縮的存算集群偷崩；
• 計算集群動態(tài)伸縮，節(jié)約企業(yè)資源成本撞羽。

5.3.3 高穩(wěn)定性

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

六诀紊、未來展望

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

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

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

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

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

3.【架構(gòu)層面】更智能化的治理董朝、運(yùn)維

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

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

4.【架構(gòu)層面】湖倉一體到智能湖倉

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

七碘箍、作者

Jimmy：帶著團(tuán)隊為愛番番奔走的資深工程師遵馆。

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

如果你想嘗鮮圖數(shù)據(jù)庫 NebulaGraph，記得去 GitHub 下載丰榴、使用货邓、(^з)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用戶一起交流圖數(shù)據(jù)庫技術(shù)和應(yīng)用技能四濒，留下「你的名片」一起玩耍呀~