本文整理自百度愛番番業務部團隊技術負責人李改建在QCon2022廣州站的演說分享，主題為“百度愛番番RT-CDP構架實踐”。

隨著公域流量紅利退去，企業格外重視私域精細化營運、營銷。越來越多的企業還要基于CDP解決數據荒島問題，幫助其更快的控溫線索、促活顧客。但對于中小企業來說，在搭建強悍平臺能力的同時，怎么合理化資源，最大程度減少資源費用只是一個重要課題。本次分享既有先進構架的整體介紹，還有在資效方面上的設計權衡，來最大化的幫助企業降本增效。

以下為演說實錄。

我叫李改建，現今在百度工作已有七八年。我這次分享的主題是關于百度愛番番的實時CDP實踐。我之前寫過一篇關于這個CDP構架的文章，包括一些選型和設計實踐。這次分享是為了貼合資效平衡這個主題，由于我們在這個構架的過程中有幾個核心指標和主題緊密相關，因此我也出席了此次的大會。還要說明的是，這個PPT是半年前制做的，在制做過程中因為多次調整大會時間，PPT沒有同步迭代。另外，牽涉業務變更的內容也沒有更新到最新狀態，但我覺得其中的這些技巧論、思想和目標在當前依然適用，所以我想分享給你們，讓你們了解當初我們是怎樣做的。

我之前寫的一篇文章，早已公布并遭到了不少關注。此次的PPT缺乏一些前期背景和業務問題的具體說明，所以或許會更難理解。假如有問題，可以在最后一頁的“彩蛋”中找我交流。

上次分享主要囊括幾個大塊，其中最重要的是介紹資效平衡實踐在構架中的應用。

業務背景

簡略介紹一下我們的業務和整體的價值。我們主要是在營銷領域舉行業務，主要服務于廣告主。隨著互聯網的發展，公域流量的下降早已漸趨飽和，中小企業獲取顧客的費用越來越高，但是未能制訂緊貼顧客的營銷方案，以獲取更高的顧客轉換率。為此，我們開始針對私域進行建設，以滿足顧客的需求。對于百度來說，公私域的業務都很重要。

當初，整個營銷環境的主要問題是廣告費用和缺少創新的營銷方案，并且顧客的需求變化十分快速。曾經，只要提供了一個產品或服務，顧客基本上就能很快地接受它，但是它們的需求變化不會太大，門坎要求也不是很高。雖然目前，因為信息量越來越大，顧客對自己的看法，包括對企業和顧客的看法變化得十分快。顧客對數據和信息變化的時效要求也越來越高。

基于多方面的需求，愛番番提供了完整的營銷解決方案。這包括公共和私人領域的服務，其中包括百度的廣告業務，后續的顧客轉換鏈路以及維護環節。通過與百度的整體業務對接，產生了一個強悍的閉環系統。我今天分享的主要是關于私領域營銷的內容。我們的實時CDP是與私域營銷密切合作的。這包括數據剖析和整個數據鏈的串聯，確保數據的及時性。

關于CDP，我們還要考慮兩個方面。第一個方面是要確定業務的本質，而第二個方面則是須要了解標準CDP所須要滿足的要求和特點。在業務層面，我們可以通過一張簡圖來了解我們在私域場景下為顧客和企業提供的標準能力是什么。由于我們面向多住戶，因此須要在數據模型上支持ToB和ToC。例如，假若一個企業是ToB企業，我們還要管理企業和顧客數據，他們是單層的關系。其實，在國外大多數CDP場景下，ToB數據模型基本上沒有得到挺好的建設，而常常是以ToC為方向來打平數據。這只是我們面臨的挑戰之一。

另外，我們還須要考慮多渠道營銷。怎么博得營銷？首先，我們提供了靈活的數據配置化畫筆能力。例如，一個企業想要怎么向顧客進行營銷，顧客通過訪問其官網、H5或其他渠道的媒體信息，企業還要了解顧客在不同媒體之間的整體訪問軌跡，于是提供靈活的觸達，包括活動信息和降價券等。第三個是解決方案的鏈路還要多元化，由于無論是漲粉、推廣還是直播，其業務需求的鏈路都不一樣。詳細的業務場景或許須要格外深入地討論。

CDP特性

下邊介紹下CDP，這是我想著重想分享幾個關鍵點之一。首先，CDP的標準定義是何種？CDP在2013年就早已被提出來了，包括其官方定義和分類。雖然在國外，這些公司依然將其稱為MA、數據洞察，并推出了太多不同的產品。并且包括我們自己的團隊在做這個東西的時侯，對于CDP的理解和標準也存在巨大的差距。

假如你對CDP感興趣，這么這一頁是必需要了解的。基本上，所有現今提及的營銷鏈路的東西都是CDP的范疇。因此，CDP對應的能力集不同，所以須要考慮業務剖析和技術指標，列舉我們要做的CDP應當是何種樣子的。有兩個主要的細節：一是靈活支持ToB和ToC兩類模型，即私有布署和適應多種業務場景；二是統一畫像的儲存；三是實時的多渠道打通，以保證跨渠道數據的實時同步讀寫。之外，考慮時效性，即跨渠道數據打通的實時性和海量數據下的實時性。為了滿足某些要求，我們進行了這些調優，包括整條鏈的，服務鏈的，數據層面的和混部等。

整體構架

我們的構架指標歸納為四個：多住戶，高功耗，低費用和實時。這四個指標之間存在一些互相沖突，須要考量，我們花了巨大的力氣去實現。

我們先了解整體的數據流向，從多元數據對接到采集、處理和輸出。這個邏輯構架圖中最重要的部份是白色的三個塊，很多部份還要結合詳細的具體設計和資效平衡來了解。關注這三個部份對應的位置、功能和還要解決的問題是很重要的。其實其他塊諸如實時數據處理和統一儲存也進行了費用優化和控制，但這三個塊是更典型的。因而首先討論這三個塊。

在下邊這個圖中重點想介紹下公共組件與云原生的結合。我們部委是百度內部比較早將功能服務、微服務和數據服務全都拉到K8S生態下的部委之一。CDP平臺牽涉了許多組件選型和與K8S結合的問題。我們在做這個圖服務的時侯也遇見了巨大的問題。從遷移到Graph的過程中也踩了這些的坑。

構架/資效均衡實踐

自定義模型

現在的重點是討論三個問題：、實時的IDM和實時的規則引擎。這三個對應的問題比較典型，的關鍵詞是增加費用和提升效率，IDM是資源均衡和功耗優化，規則引擎是極至功耗和彈性伸縮。在中，我們還要將中小企業的數據用很低費用地接過來，這對于不同的企業來說是十分重要的。但是其他的數據平臺就會考慮這個問題，但這個問題的復雜程度并不小。

首先，我們面臨的是業務問題，即怎樣更快地將各類企業、各種維度的數據接入我們的CDP平臺。為了解決這個問題，我們先進行了一層具象，將數據轉化為CDP平臺中群組的標準數據。我們將這種數據具象為三類業務實體，其中兩大類是身分信息和行為軌跡，包括屬性信息、時序信息和數據變化記錄。之后，我們在這個業務具象的基礎上又做了一層外置的標準，這個針對特定行業的結構化數據，外置了標準數組，例如企業信息、企業地址和企業名稱等。

在營銷場景下，例如陌陌場景和直播場景，我們對各個場景的標準數組進行具象外置，并進行簡化，以增加效率。稍為配置一下就可以在幾分鐘內完成數據導出，而原先或許還要一十天。

在我們做這個具象以后，將其轉化為一個簡略的模型，這個模型可以處理多個實體之間的1對n的關系，以及一個實體原本的1對n的關系，可以復制承繼并在多機上使用，最終將其轉化為一個結構化的JSON，帶有一些業務含意。當企業使用時，我們將其原始數據攻入我們的庫中。企業在擴充時，主要是通過子進行擴充，最后統一儲存。至于其他模塊牽涉到業務分拆，不再細說。

對于，我們面臨兩個問題。首先是多住戶的支持，怎樣統一儲存而不會造成建表量非常多？第二個問題是，假如表量不多，怎么儲存很多數組？對于第一個問題，我們還要保證建表量不會過多，以減少維護費用。對于第二個問題，假若選用大寬表的形式進行儲存，但是在數據剖析時或許會有一個聚合的大寬表，但對于多住戶的狀況，數據會特別離散，這對于查詢費用來說是不實惠的。因而，在數據處理方面，我們通過對原始數據結構的映射，將無業務概念的數據數組具象為數值型、字符型等幾類，下層通過進行查詢和SQL轉化。有了這一制度，我們只需在企業的數組數目少于外置數組限制時才須要干預，添加幾個外置數組并手動進行映射轉化。在我們底層統一儲存使用的Kudu，數組數目官方建議有幾百個限制。

萬級QPS實時IDM

我們也在功耗和實時QPS調優方面作出了一定的努力。其實我們在萬級QPS的場景下進行了檢測，但這還要在3-6個pod的狀況下進行，且儲存是讀寫分離的，包含3個儲存節點和3個查詢節點。考慮到數據處理過程是基于圖結構且深度為4，我們才能處理幾萬QBS的數據量級，這闡明它具有了很強的功耗。

從模型的視角來看，IDM就是ID的關聯，在我們的場景中代表著顧客從官網訪問后，在陌陌上登陸小程序后還要進行關聯。當訪問官網時，怎樣營銷和觸達顧客是一個重要的問題。官網的數據一般只有臨時數據，如ID，且他們是設備細度的。陌陌授權或許使用的是百度的，這種數據是花絮化的。解決這個問題的關鍵是怎樣將顧客數據打通，并在多個渠道上進行營銷。這一般牽涉到在不同媒體上公布的數據，并使用圖的方法來處理這種數據。

大多數企業一般傾向于使用結構化的數據表進行離線估算，以榮獲歷史關系數據。與這些步驟的差別在于，我們的關系是實時打通的，這是由于假如不實時打通顧客，但是在同一個媒介下，也或許難以確定應當歸屬于那個人，在統一結構后來，它們會有一個CDP惟一標志。

在使用圖數據庫時，還要考慮使用實體屬性值還是實體關系和實體結構來儲存數據，由于不同的數據庫的數據切分形式是不同的。在實現圖數據庫時，最初選用了點切分的方法，但因為數據模型下的節點類別有限，加上多住戶的需求，造成數據傾斜問題嚴重。為解決這個問題，系統選用了邊切分的方法，并使用了國外的Graph數據庫進行儲存。Graph相對于美國的更加成熟，且有較差的發展前景。

由于天然的圖數據庫擁有適宜的構架，無論是在估算儲存還是底層分布式儲存方面都有特點，所以它天然具有伸縮能力。在分布式系統中，有一個常見的小點適于控制Redis的伸縮，這是一個參考。

在邏輯處理方面，我們對鎖和連結池進行了優化，并對查詢的SQL進行了調優。我們與圖數庫的人合作做了太多配合，療效顯著，無論是在型號穩定性還是功耗方面，對于資源消耗都有巨大提高。

最后一個部份是IDM布署，提及布署是由于它與水平伸縮和布署模式相關，對費用和資源有天然的優勢。我們對儲存估算節點的布署，在混部模式、網絡和負載方面以及硬盤上做了太多

優化，才達到了之前提到的療效。

實時規則引擎（RTRE）三次變革

在實時規則引擎方面，一個問題是數據量巨大，儲存的原生數據海量。另一個問題是對于多住戶，實時流入的數據量也巨大，在實時IDM的前提下，每條數據都還要實現實時讀寫，實時關系打通并進行處理。我們進行了兩三次迭代，最終達到了預期，在功耗和資源伸縮方面都有所提高。

我們的實時規則引擎主要應適于營銷場景，而且還要配置對話步驟。簡而言之，當顧客觸發這些規則時，我們將采取相應的舉措。這種規則相對復雜，比如，在企業的7天內，顧客未打電話，且之前提供了相機號碼但沒有提供陌陌號碼；在近期的3分鐘內訪問過企業的H5頁面等。這種條件須要進行組合，包括兩組和三組條件，ANDOR關系，所以相對復雜。再者，即便步驟配置完成，我們希望還能實時觸發，即在一條數據抵達后的微秒級別內進行響應和觸達。雖然規則試驗是相似的，但在時效性和數據量方面卻有所不同。

接下去介紹一個關鍵點，就是數據查詢中是主動還是被動的。傳統的數據平臺會在設計一堆規則后來，通過查詢句子來搜索海量數據。而我們的思路是數據主動查詢，在數據流的關鍵階段進行重要數據的補充，以確保在進行規則判定時有足夠的數據，并進行結果處理。之外，現在也有一些流式數據庫，只是極其重要的方向和思路。

在實現這個引擎時，我們持續迭代了實現模式。第一版實現比較粗糙，基于Flink進行實現，還要健全許多Flink的job，并使用FlinkSQL進行編撰。但我們那時遇見的問題是窗口風暴，這意味著處理每分鐘數據與近一分鐘數據的試驗處理方法不同。當滑動窗口巨大時，比如幾天或幾個月，使用Flink消耗資源和實現程度都面臨巨大挑戰和問題。Flink提供了復雜風波組合處理的標準組件，但現在它主要適用于固定窗口和小滑動窗口場景，諸如實時監控日志報案。

基于這種前提，我們再次自研了一套實時規則引擎，并進行了分拆和多樣化策略以更好地與抽樣SQL解讀和規則引擎對接。我們還優化了片斷規則的結果復用和資源控制。

在布署資源時實時分析程序考慮，我們面臨多住戶的狀況，每位job都占用太多CPU和顯存資源。對于數據高峰，我們對處理節點進行了分類，有些偏管理，有些偏數據估算和儲存，也有些是純估算。那樣，當高峰過去時，我們可以迅速清除或解除純估算節點。第二次變遷，我們在百度云的基礎上升級了估算平臺搭建。我們支持的伸縮策略可以分為兩類：一類是固定時間段的，缺少動態性；另一類是基于指標的，這與在云原生場景下的狀況十分相像。

第三次變革是遷移到云原生，由于在最初建設估算平臺時，云原生鏈路仍未完全確立，如今有了以后，可以在多住戶場景下逐步擴充資源，主要考慮顧客費用和維保方面的誘因，尤其是在線業務鏈路方面，長時間的響應帶寬是不可接受的。在云原生上，我們就能實現的主要是集群力度和服務力度的伸縮，以及通過虛擬化場景下的預pod管理來提高pod啟動帶寬。如右圖，通過AP、CA、HPA三個圈來代表那些方面。

在這三類前提下，我們將所有的Flink作業遷移到云上。在云上，我們依照官方實踐，將Flink作業運行在高可用機制下。目前實時分析程序考慮，我們的幾百個作業可以通過幾個地理機承載，使得才能挺好地進行伸縮。我們可以將這種資源與其他業務的pod進行整體的復用和資源均衡，并且估算集群所占用的資源十分少。

小結與展望

右圖整理了平臺才能實現的能力和后來想要實現的一些功能。我們的CDP平臺是一個數據平臺，主要關注流批一體的數據處理。因此，與智能湖倉相比，我們也有巨大的差異，這是我們未來想要探求的方向。

以上是我們平臺的一些內容，假若您有任何問題，隨時可以聯系我們進行交流。感謝！