導讀：隨著業務在金融、保險和商城領域的不斷擴充套件，眾安保險建設 CDP 平臺以提供自動化營銷資料支援。早期 CDP 平臺依賴於 Spark + Impala + Hbase + Nebula 複雜的技術組合，這不僅導致資料分析形成資料孤島，還帶來高昂的管理及維護成本。為解決該問題，眾安保險引入 Apache Doris，替換了早期複雜的技術組合，不僅降低了系統的複雜性，打破了資料孤島，更提升了資料處理的效率。
眾安線上財產保險股份有限公司是中國首家網際網路保險公司，由螞蟻金服、中國平安和騰訊於 2013 年聯合發起設立。眾安專注於應用新技術重塑保險價值鏈，圍繞健康、數字生活、消費金融、汽車四大生態，以科技服務新生代，為其提供個性化、定製化、智慧化的新保險。業務和關聯公司的業務包括：眾安保險、眾安醫療、眾安小貸、眾安科技、眾安經紀、眾安國際、眾安銀行等。截至 2023 年中，眾安服務超過 5 億使用者，累計出具約 574 億張保單。
然而，隨著業務在金融、保險和商城領域的不斷擴充套件，眾安保險面臨使用者資料管理的挑戰。使用者資訊來源於公眾號、小程式和 APP 等多個渠道，這些資料不僅碎片化，而且多樣化。同時，運營渠道也涵蓋了自營、聯營和外部投放等多種途徑，導致資料進一步分散。這種資料孤島現象使得眾安保險難以形成完整的使用者融合體系，從而無法實現對使用者的精準識別和實時營銷。
CDP 建設目標及方案
為了解決這一問題，眾安保險建設了 CDP 平臺。該平臺的核心職責是整合所有使用者資料，構建全面的使用者標籤和客群體系，並利用其強大的資料分析能力為自動化營銷提供資料支援。
CDP 平臺的建設目標主要包括以下幾點：
- 快速資料整合： CDP 需支援整合常見的關係性資料庫（如 MySQL、PG 等 ）和資料倉儲同（如 Hive、MaxCompute 等），同時還需要整合實時資料流（如 Kafka 等）。
- 精準使用者識別：在複雜的業務體系中，CDP 平臺需能夠靈活整合多種 ID 型別，形成統一的使用者檢視，為下游的實時營銷場景提供支撐。
- 靈活的使用者標籤和強大的分群能力：這是 CDP 平臺的核心建設目標，旨在提供全面、深度的使用者洞察，精準滿足使用者需求。
- 多維度實時分析：支援對使用者畫像、使用者旅程和營銷效果的實時跟蹤與回收。為最佳化營銷策略和提升使用者參與度提供有力的支援。
基於上述建設目標，眾安保險目前已形成了完整的 CDP 解決方案，該方案包括以下幾個關鍵步驟：
- 全域資料採集：CDP 平臺透過實時和離線資料採集方式，實現對全域資料的整合。利用 Flink 進行實時資料採集，同時建設離線數倉以整合多渠道資料，確保高質量的資料資產沉澱。
- 使用者資料融合：透過 ID Mapping 技術，可將現有的使用者資料進行融合，打破資料孤島。即將使用者手機、使用者身份證、裝置指紋、OpenID 等使用者身份進行融合，形成統一的使用者標識（OneID）。
- 標籤和客群管理：CDP 平臺支援多維度標籤的建設，包含使用者屬性、使用者行為、業務交易狀態等。同時，透過規則客群的圈選能力實力客群的精細劃分。
- 使用者資料分析：基於豐富的使用者標籤資料，CDP 平臺提供使用者畫像洞察功能，支援實時效果評估和營銷漏斗分析。
- 使用者資料服務：CDP 平臺提供多維度的資料介面服務能力，包括使用者標籤、客群、分層和實時事件等，賦能使用者全鏈路智慧營銷。
CDP 平臺架構的演進歷程
在初步瞭解了 CDP 平臺的建設初衷和解決方案之後，我們將深入挖掘其演進歷程，探索它如何逐步蛻變為眾安保險統一、高效且不可或缺的核心基礎設施。本文將重點分享 CDP 平臺的建設過程及其在實際生產中的應用實踐。
CDP 產品架構如上圖所示。全域資料接入之後，這些資料就可以搭建使用者資料中心、實時事件中心、客群畫像以及營銷流程。使用者資料中心是客群畫像的基石，並與客群畫像、實時事件中心一同支撐營銷流程的資料需求。資料服務層則包括使用者資料服務、客群圈選、營銷策略、實時事件、 AB 實驗和實時效果分析回收在內的全方位資料服務，滿足各業務場景的資料需求。
架構 1.0：多個技術棧，形成資料孤島
CDP 平臺架構 1.0 如上圖所示，離線資料和實時資料的處理流程如下：
- 離線資料：透過 ETL 方式整合各業務線的資料庫資料，包括行為埋點資料、日誌資料等，並將這些資料抽取數倉 DWS 層。隨後，利用 Spark 作業將 DWS 層資料抽取到 Impala 中，進行離線的標籤計算和客群的圈選。同時，我們還透過 Spark 抽取 DWS 層業務體系裡的使用者點邊關係，並將其整合到 Nebula 圖資料庫中，提供全面的點邊關係計算、邊距計算以及 One ID 計算功能。
- 實時資料：採用 Kafka 實時回收所有的業務線的 Binlog 資料、行為埋點資料以及各業務線的事件上報資料，在 Flink 中實現實時標籤的配置化計算，並透過 Flink Checkpoint 進行復雜的實時指標計算和事件組合。最終將實時標籤儲存在 Hbase 中，以便為各業務線提供點查服務。
然而，從架構圖中可以明顯看出，標籤計算和 ID 圖譜計算這一層涉及了非常多的技術棧，包含 Impala、Spark、Nebula 以及 Hbase。這些過多的元件導致了離線標籤、實時標籤以及圖資料儲存的不統一、各場景資料分散儲存，形成了資料孤島。
在這種情況下，當需進行整體檢視計算或為上層提供服務時，就需要打通所有的資料，這無疑增加了大量資料傳輸和資料重複儲存的成本。此外，由於各類資料儲存方案的差異，還需要使用較大的 CDH 叢集和 Nebula 圖資料庫叢集，進一步提高了叢集資源與維護成本。
架構 2.0：統一技術棧，打破資料孤島
為了解決資料儲存的不一致性和高昂成本問題，我們決定進行架構升級，並選擇 Apache Doris 作為核心元件。我們的升級目標是希望透過引入 Doris 來統一技術棧，實現實時和離線資料儲存和計算的整合，從而打破資料孤島，大幅度降低資料儲存和資源維護的成本。在實際的應用中，Doris 完美地滿足了我們的需求，使得整體架構變得更精簡高效。
對於離線資料，我們採用了 Doris 的 Stream Load 功能，輕鬆地從離線數倉中將資料抽取到 Doris 中。而對於實時資料，則透過 Flink Connector 與 Stream Load 的結合，將實時事件和實時標籤無縫匯入到 Doris 中。基於 Doris 強大的向量化計算引擎，我們不僅實現了 One ID 計算、離線/實時標籤的儲存和計算、客群圈選、實時事件儲存，還支援了實時分析等多樣化需求，真正實現了技術棧的統一。
引入 Doris 後，我們還收穫了以下顯著的收益：
- 架構簡潔，運維成本降低 ：引入 Doris 之前，我們需要額外維護 CDH 叢集和 Nebula 叢集。而現在，僅憑一個 Doris 叢集就可以完成所有的工作，顯著降低運維成本。此外，Doris 還提供的完善叢集監控設施也極大方便了我們對叢集的便捷管理。
- 支援 SQL，快速上手 ： Doris 相容 MySQL 協議，這意味著對於已經熟悉 MySQL 的開發者來說，無需額外的學習成本就能快速上手操作。
- 豐富的資料匯入形式 ：Doris 提供了豐富且便捷的資料匯入方式，使資料庫遷移和資料匯入變得高效和方便。使用者可以根據實際需求選擇適合的匯入方式，以快速完成資料遷移和匯入操作。
Doris for CDP 在業務場景中的實踐
全域資料採集
為滿足不同場景的資料整合需求，CDP 平臺主要分為三個板塊：
- 離線資料匯入：針對標籤計算、實時客群預估與圈選，以及標籤和客群多維畫像分析等場景，我們採用 DataX 工具，透過 Stream Load 方式將離線資料高效寫入到 Doris 裡。為確保 Stream Load 的穩定性，我們線上上對 30 多個執行緒併發匯入進行測試，結果顯示，每秒 Upsert （寫入或更新） 數量高達 30+ 萬條。對於我們當前的一級使用者量來說，匯入效果可以很好滿足我們的需求。
- 部分列更新：在實時寫入場景中，當使用 Flink 實時寫入標籤資料時，需要精確到單個使用者和標籤的實時更新和插入，流程相對複雜。而 Doris Stream Load 可以開啟部分列更新 partial_columns=true 來滿足這一需求，確保每個使用者和標籤都能得到及時、準確的更新。
- 外部資料來源對接：在實時分析報表場景中，經常需要跨多個資料來源的交叉分析。Doris 的 Multi-Catalog 功能可以更方便對接外部資料目錄，無需進行資料遷移或匯入，即可進行外部資料來源的聯邦查詢。無論是基於 Hive 或 MaxCompute 的查詢，還是 JDBC 業務線的資料查詢，都能迅速獲得精準的分析結果，極大提升了查詢效率。
OneID
1. 構建 ID 圖譜
我們在現有系統中配置了 ID 圖譜的點關係，這些關係以使用者為中心，形成了複雜的網路結構。舉例說明：假設某使用者在體系 A 擁有使用者 ID，並且繫結的公眾號，這樣就形成了 Open ID 繫結關係。隨著使用者的使用，他可能註冊了手機號，那麼手機號跟體系 A 使用者 ID 之間便建立了繫結關係。如果使用者在體系 A 也進行了實名，那麼身份證和註冊手機號也會建立繫結關係。
隨著時間的推移，該使用者可能進入到體系 B 中，並註冊體系 B 賬戶。這時，與該使用者相關的體系 A 使用者 ID、手機號、身份證和體系 B 賬戶之間都會形成關聯。在如上圖右側系統裡，我們可以配置使用者 ID、OpenID、手機號、身份證這些點的屬性、物理表及關聯關係，形成 ID 圖譜。那麼結合 ID 圖譜，就可以基於 Doris 進行 OneID 的構建。
2. 構建 OneID
基於使用者各個業務線之間點和邊的關係，我們會將使用者在不同業務線中的資訊全部抽取出來，放入一張大表裡面進行 Union All 操作。這張表包含了手機號、體系 A 使用者 ID、體系 B 使用者 ID、身份證號和 Open ID 關鍵資訊。OneID 的構建流程如下：
- 首先，利用 Doris 提供的
row number視窗函式生成完整的全域性行順序。然後對所有 ID 關係資料進行 Union All 操作。 - 接著，使用視窗函式
dense rank和row number的複數生成為空/不為空時的首列 Rank 值。 - 最後，透過迴圈迭代計算每一列最小距離，並不斷迭代 Rank 值，直到當前列與上一迭代結果全域性匹配。當所有資料連續匹配滿 5 次後，就以最終 Rank 值為準進行使用者分組，從而得使用者唯一標識 OneID。
結合上圖以及構建流程，可以得出結論： 1 - 4 行是使用者 1，5 - 6 行是使用者 2。
標籤體系
我們的標籤體系由實時標籤和離線標籤兩部分組成，目前該體系擁有超過 2000 個標籤，涉及 50 餘張來源表，服務使用者量已達億級。
在標籤體系中，有一些簡單的配置規則：
- 離線標籤：在 Doris 中抽象出三種業務型別表，分別是使用者資料表、業務明細表和行為事件表。根據上方標籤配置規則，透過 DSL 動態語義生成 SQL，然後在 Doris 中進行計算，並將計算結果儲存在 Doris 中，形成一張離線標籤寬表。
- 實時標籤：基於 Flink 接收 Kafka 、 CDC 訊息，並根據實時標籤配置後設資料，在 Flink 中計算出實時標籤，並將最終結果寫入 Doris 的實時標籤寬表中。
Apache Doris 在標籤體系中的應用主要包含以下四個方面：
1.離線標籤處理： 由於擁有 2000+ 較大量級的標籤一級使用者，當遇到高峰期併發寬表寫入時，全量更新所有列可能會出現記憶體不足的問題。為避免該問題，我們利用 Doris 的 Insert Into Select 功能，在 session 變數中開啟部分列更新開關，只更新目標表中需要修改的列，這樣可顯著減少記憶體消耗，以提升全量匯入的穩定性。
set enable_unique_key_partial_update=true;
insert into tb_label_result(one_id, labelxx)
select one_id, label_value as labelxx
from .....
2.實時標籤處理： 在實時標籤寫入時，不同的實時標籤欄位更新時間不一樣，而部分列更新能力可以滿足此更新需求。只需開啟 Partial Column，並將其設定為 True，就可以實現實時標籤的部分列更新。
curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load
3.標籤點查： 隨著線上業務量的不斷增長，我們面臨著處理超過 5000 QPS 標籤請求的挑戰。為滿足這一需求，我們採用多種策略來確保高效的點查效能。首先，透過利用 PrepareStatement 技術，預編譯和執行 SQL 查詢，從而提高查詢效率。其次，精細調整了 Backend（BE）引數和表引數，以最佳化資料儲存和查詢效能。同時，我們開啟了行存，進一步提升系統在高併發場景下的處理能力。
- 在 be.conf 中調整 BE 引數：
disable_storage_row_cache = false
storage_page_cache_limit=40%
- 在建表時調整表屬性：
enable_unique_key_merge_on_write = true
store_row_column = true
light_schema_change = true
4.標籤計算：為了滿足使用者對於標籤配置的靈活需求，系統允許在 DSL 生成的語義中進行多表 Join 操作，而這就可能會涉及十幾張表的 Join 操作。為了確保標籤計算效能最優，我們充分運用 Doris Colocation Group 策略，對所有分桶列的型別、數量和副本進行統一，並優先滿足 Colocation Join 和本地的 Hash Join。線上上環境中，也可以開啟Colocate With開關，指定一個 Group，確保全域性表的分片與副本策略一致。
客群圈選
在架構 1.0 中，客群服務先生成動態 SQL，然後將其傳輸到 Impala 中進行客群圈選。完成圈選後，結果集需被重新讀取回客群服務，並由其上傳到物件儲存中。這一連串的操作使得資料處理鏈路相對冗長，影響了整體效率。而在架構 2.0 中，我們可以在 Doris 中使用基於 Select 語句的結果集，並透過 Select Into Outfile 功能，將資料無縫匯入到 S3 協議的物件儲存中，這種方式極大縮短了資料處理鏈路。
在實際的業務中，線上約有 100 萬個客群，單個客群生成所需時間從 50 秒縮短至 10 秒，極大提升了客群圈選效率。 若需要進一步提高效能，可以選擇開啟併發匯出開關，進一步提高資料匯出效能。
客群歸屬
在我們的業務系統中，客群歸屬扮演著至關重要的角色，特別是在實時智慧營銷和千人千面的識別場景中。我們經常需要判斷某個使用者是否隸屬於特定的客群，或者確定其屬於哪些客群。這種全域性性的判斷有助於我們深入理解多個客群之間的使用者重疊關係。
為了滿足這一需求，我們可以藉助 Bitmap 來實現。在 Bitmap 中，使用 Bitmap Contains 可以快速識別某個使用者是否存在於特定客群中，也可以透過 Bitmap OR、Bitmap Intersect 或 Bitmap XOR 來實現客群全量、多版本之間的交併叉分析，從而提供更為精準和高效的營銷策略。
總結與展望
在架構 1.0 中採用了複雜的技術組合，以實現標籤、客群以及 OneID 的計算。這一架構元件眾多，導致資料處理鏈路冗長、造成資料孤島，且有著較高的管理和維護成本。透過引入 Apache Doris ，替換了 Spark + Impala + Hbase + Nebula，成功實現儲存與計算的統一，簡化了資料處理的流程，不僅降低了系統的複雜性，更提升了資料處理的效率，滿足了更豐富的資料處理需求。 隨著業務的發展，實時營銷場景對實時性的要求日益提升。未來，我們計劃在 3.0 版本中，實現離線標籤和實時標籤的混合圈選功能，並依託 Doris 進行 OneID 實時計算。這將使我們能夠更快速、準確地識別增量的使用者，並在多使用者體系中實現精準的使用者識別，以滿足不斷變化的業務需求，推動實時智慧營銷和個性化識別場景的持續創新與發展。 最後，我們衷心感謝 SelectDB 技術團隊 所提供的技術支援，未來我們期待與社群更緊密的合作，為社群貢獻力所能及的力量，共同推動技術的發展與進步。