使用統一資料倉儲打破資料孤島：基於Apache Doris的CDP

隨著企業資料來源日益多樣化，資料孤島問題變得普遍。保險公司在建構客戶資料平台（CDP）時，面臨資料孤島導致的元件密集型運算層，資料儲存分散的問題。為了解決這些問題，他們採用了基於 Apache Doris 的 CDP 2.0，利用 Doris 的統一資料倉儲能力，打破資料孤島，簡化資料處理管道，提升資料處理效率。

資料孤島問題就像網路企業的關節炎，因為幾乎每個人隨著年齡的增長都會遇到這個問題。企業透過網站、行動應用程式、H5 頁面和終端設備與客戶互動。出於某種原因，整合所有這些來源的數據是一件很棘手的事情。資料保留在原處，無法相互關聯以進行進一步分析。這就是資料孤島的形成方式。您的業務規模越大，您擁有的客戶資料來源就越多樣化，您就越有可能陷入資料孤島。 

這正是我在這篇文章中要討論的保險公司所發生的情況。到2023年，他們已服務超過5億客戶，簽訂了570億份保險合約。當他們開始建立客戶資料平台（CDP）來適應如此大的資料規模時，他們使用了多個元件。 

CDP 中的資料孤島

與大多數資料平台一樣，他們的 CDP 1.0 具有批次管道和即時串流管道。離線資料透過 Spark 作業載入到 Impala，在那裡被標記並分成群組。同時，Spark 也將其發送到 NebulaGraph 進行 OneID 計算（本文稍後將詳細闡述）。另一方面，即時資料被Flink打上標籤，然後儲存在HBase中，以備查詢。

這導致了 CDP 中的元件密集型計算層：Impala、Spark、NebulaGraph 和 HBase。

結果，離線標籤、即時標籤和圖形資料分散在多個元件中。由於冗餘儲存和大量資料傳輸，將它們整合以提供進一步的資料服務成本高昂。更重要的是，由於儲存的差異，他們不得不擴大CDH叢集和NebulaGraph叢集的規模，增加了資源和維護成本。

基於 Apache Doris 的 CDP

對於CDP 2.0，他們決定引入一個統一的解決方案來收拾殘局。在CDP 2.0的運算層，Apache Doris承擔即時和離線資料儲存和運算。 

為了攝取離線數據，他們利用串流載入方法。他們的 30 線程攝取測試表明，它每秒可以執行超過 300,000 次更新插入。為了載入即時數據，他們結合了Flink-Doris-Connector和 Stream Load。此外，在需要從多個外部資料來源提取資料的即時報告中，他們利用多目錄功能進行聯合查詢。 

此 CDP 上的顧客分析工作流程如下。首先，他們整理客戶資訊，然後為每個客戶貼上標籤。他們根據標籤對客戶進行分組，進行更有針對性的分析和操作。

接下來，我將深入研究這些工作負載並向您展示 Apache Doris 如何加速它們。 

一個ID

當您的產品和服務有不同的使用者註冊系統時，您是否曾經遇到過這種情況？您可以從一個產品網頁收集使用者 ID A 的電子郵件，然後從另一個產品網頁收集使用者 ID B 的社會安全號碼。然後您會發現 UserID A 和 UserID B 實際上屬於同一個人，因為他們使用相同的電話號碼。

這就是 OneID 作為一個想法出現的原因。就是將所有業務線的使用者註冊資訊匯集到Apache Doris中一張大表中，進行整理，並確保每個使用者擁有唯一的OneID。 

這就是他們如何利用 Apache Doris 中的功能來決定哪些註冊資訊屬於相同使用者。

標籤服務

該CDP容納了5億客戶的信息，這些信息來自500多個來源表，總共附加了2000多個標籤。

依照時效性，標籤可以分為即時標籤和離線標籤。即時標籤由 Apache Flink 計算並寫入 Apache Doris 中的平面表，而離線標籤由 Apache Doris 計算，因為它們源自 Doris 中的使用者屬性表、業務表和使用者行為表。以下是該公司在資料標記方面的最佳實踐： 

1. 離線標籤

在資料寫入高峰期，由於資料規模龐大，全量更新很容易導致OOM錯誤。為了避免這種情況，他們利用Apache Doris 的INSERT INTO SELECT功能並啟用部分欄位更新。這將大大減少記憶體消耗並在資料載入過程中保持系統穩定性。

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_columns為true。

curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -testT ://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. 高並發點查詢

#以目前的業務規模，該公司正在以超過5000 QPS 的同時水準接收標籤查詢請求。他們使用策略組合來確保高性能。首先，他們採用Prepared Statement來預編譯和預執行SQL。其次，他們微調 Doris 後端和表的參數以優化儲存和執行。最後，它們啟用行快取作為面向列的 Apache Doris 的補充。

微調 Doris 的後端參數be.conf：

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.標籤計算（Join）

在實務上，許多標籤服務都是透過資料庫中的多表連接來實現的。這通常涉及 10 多個表。為了獲得最佳的運算效能，他們在Doris 中採用了共置組策略。

客戶分組

CDP 2.0 中的客戶分組管道是這樣的：Apache Doris 從客戶服務接收SQL，執行計算，並透過SELECT INTO OUTFILE 將結果集傳送到S3 物件儲存。該公司已將其客戶分為100萬組。過去在 Impala 中需要50 秒才能完成的客戶分組任務，現在在 Doris 中只需要10 秒。 

除了對客戶進行分組進行更細緻的分析外，有時他們還會進行反向分析。即針對某個客戶，找出他/她屬於哪些群體。這有助於分析師了解客戶的特徵以及不同客戶群的重疊情況。

在 Apache Doris 中，這是透過 BITMAP 函數實現的：BITMAP_CONTAINS是檢查客戶是否屬於某個群組的快速方法， 、BITMAP_OR、BITMAP_INTERSECT和BITMAP_XOR是交叉分析的選擇。 

結論

從CDP 1.0到CDP 2.0，保險公司採用統一資料倉儲Apache Doris取代Spark Impala HBase NebulaGraph。透過打破資料孤島和簡化資料處理管道，提高了資料處理效率。在CDP 3.0中，他們希望透過結合即時標籤和離線標籤來分組，以進行更多樣化和靈活的分析。 Apache Doris 社群和VeloDB團隊將繼續作為此次升級期間的支援合作夥伴。

以上是使用統一資料倉儲打破資料孤島：基於Apache Doris的CDP的詳細內容。更多資訊請關注PHP中文網其他相關文章！