湖倉分析｜浙江霖梓基于 Doris + Paimon 打造實時/離線一體化湖倉架構

導讀：浙江霖梓早期使用 CDH 產品套件搭建了大數據系統，面臨業務邏輯冗余、查詢效率低下等問題，基于 Apache Doris 進行整體架構與表結構的重構，并基于湖倉一體和查詢加速展開深度探索與實踐，打造了 Doris + Paimon 的實時/離線一體化湖倉架構，實現查詢提速 30 倍、資源成本節省 67% 等顯著成效。

浙江霖梓是一家專注于深度學習和人工智能應用的金融創新企業，自 2018 年成立以來，專注于深度學習和??智能的應? ，通過構建數據迭代能?形成結構化的數據決策產品，為企業提供精準經營決策。同時，提供基于大數據的風控能力的一系列高效便捷的金融服務產品。

然而，隨著業務的持續擴展，大數據業務系統的局限逐漸暴露：報表系統計算緩慢、運維成本持續攀升、組件間的高度耦合導致架構穩定性較差等，嚴重影響了大數據系統產出效率，因此浙江霖梓引入 Doris+Paimon 重新構建了實時/離線一體化湖倉架構，為反欺詐策略、用戶?為分析、BI 應用等若干系統提供了高效準確的服務，實現了查詢提速 30 倍、資源成本節省 67% 等顯著成效。

早期架構及痛點

下圖是早期的 CDH 架構示意圖，MySQL 數據通過 Sqoop 全量導入至 Hive，埋點數據通過 Java 程序清洗后進入 Flume 的 source 端，并最終 sink 到 Hive 的分區表中，離線數倉任務的 ETL 由 Hive 執行，批處理作業則通過 Spark SQL 運行，所有任務都從 ODS 層出發直接進入到 APP 層。數據開發與分析工作則依賴 CDH 自帶的 Hue 平臺，任務調度依賴 easyScheduler，最終與自主研發的報表平臺對接，實現數據的可視化。

早期架構及痛點.PNG

隨著業務擴展，早期架構的局限逐漸暴露：數據采集、變更及分析效率低下的同時，整體運維成本也在持續攀升，并且各組件間的高度耦合降低了架構的整體穩定性。此外，由于各部門未統一指標?徑，不同取數邏輯的分析結果存在較大差異，使得業務痛點的精準定位變得異常困難，傳統的 Hive+BI 系統已無法滿足需求。

為了解決上述痛點，浙江霖梓考察了市?上較為常?的大數據分析組件，如 HBase、ClickHouse、Apache Doris 等，最終從查詢性能、寫入性能、投?成本等??評估，最終選擇了綜合實??常突出的 Apache Doris。以下為前期技術選型調研結果：

早期架構及痛點-2.PNG

相較于其他產品，Apache Doris 的核心優勢如下：

查詢快：?持物化視圖和向量化執?引擎，并?持多種表模型以及 Rollup 、BloomFilter、倒排索引等，離線跑批速度非常快，并對查詢性能有顯著加速效果。
存儲省：通過表的優化和冷熱數據分層特性，能夠充分利用機械盤和固態盤，顯著提升資源利用率。此外，采用高效的 ZSTD 壓縮算法，壓縮比高達 10 倍，大幅降低了存儲費用。
運維簡單：不依賴外部系統，原架構一旦某個服務發生異常，與其關聯的服務都會受到影響，給運維增加了難度。? Apache Doris 的原生運維工具 Doris Manager 可以滿??常絕?多數的運維需求，再加上 Doris 架構簡單且不存在??件問題，在線擴展節點十分方便，??降低了運維難度。
便捷遷移：兼容 MySQL 協議，報表系統只需要修改源配置就可以輕松對接。
社區活躍：Apache Doris 的社區?常活躍，技術團隊解決問題的能?較強；版本迭代速度快，能很好的解決業務痛點。

基于 Apache Doris 的實時/離線一體化湖倉架構

基于 Apache Doris 的實時:離線一體化湖倉架構-1.PNG

經過七個月的設計與實施，最終完成了基于 Apache Doris 離線 / 實時一體化湖倉統一架構。如上圖所示，離線數據通過 DataX 同步、實時數據通過 Flink CDC 采集加工，這些數據最終存儲到 Doris 或 Paimon 表格式中。

目前基于 Paimon 的全量數據入湖還在持續完善，原先的部分離線數據通過 Flink CDC 實時入湖，而另一部分會直接進入 Doris 來縮短數據鏈路。這些數據經由 Doris 統一分析處理后，最終服務于自研數據服務。在這其中，Doris 集群被靈活拆分為多個資源組，分別滿足離線數倉、數據集市、實時業務監控等不同上游服務的數據處理與分析需求。Apache Doris 的引入，也帶來許多顯著收益：

查詢效率提升：Hive ?對復雜的?數據量跑批任務時，耗時往往超過 20min，億級別的?表 Join 甚至需要花費 35-50min，? Apache Doris 在未經優化的初次跑批中耗時 7min ，經過基礎優化后縮減至 40s-90s，查詢速度提升近 30 倍。
開發效率提高：原架構使用 Spark 進行 ETL 之后導入數倉，業務開發需要結合 Spark、Hive、Kafka 等多組件；切換至 Doris 后，只需專注 Doris SQL 的開發與優化，開發工作大大簡化。此外，Doris 與 Kafka、DataX、Flink 等組件兼容性較高且包含豐富的插件庫，進一步提高了開發效率。
負載隔離：利? Workload Group 、Resource Group 等配置代替 Yarn，實現更加合理的資源隔離。
更低使用成本：依賴 Doris 極致的壓縮與計算性能，原架構的 27 臺服務器精簡至 10 臺左右，總體資源開銷降低至原來的 1/3（節省了 67%），為?后 PB 級別的數據量提供了更優的成本方案。
運維更加便捷：通過 Doris Manager 輕松部署和接管 Doris 集群，實時查看集群的運行狀態和詳情，快捷地對集群進行擴縮容、升級及重啟操作，數據管理更流暢、更高效。

詳細可參考 Doris Manager 介紹文檔與安裝手冊

架構升級實踐與調優

01 數據接?

離線數據處理：將 Sqoop+Flume 替換成 DataX，并新增了 Data X Doris Json 一鍵生成功能，利用主鍵模型的 Replace 特性，將全量同步優化為增量同步。改造后，數據采集時間從原來的 5h 縮短至 1.5h，處理效率提升 70%。
第三方埋點數據：之前需要通過大數據后端項目的接口 ETL 后傳輸到 Flume，改造后，ETL 邏輯依靠 Doris 實現，以 StreamLoad 的方式直接接入埋點數據。
后端日志數據遷移：由于后端日志打印頻繁，MySQL 存儲壓力較大，影響業務分析效率。改造后通過 Routine Load 對接 Kafka 消費日志數據，并設置了 TTL，此外還根據業務開發側的需求進行了簡單的數據清洗，實現高性能的日志檢索功能。
風控業務的實時命中策略與反欺詐實時指標處理：Flink 負責將 ETL 處理后的數據寫入 Paimon，通過結合 Doris 的湖分析能力接入 Paimon，憑借 Doris 的統一查詢入口為業務決策系統和數據分析提供數據服務。這一優化確保了業務問題能夠迅速被發現并解決，有效避免了以往 T+1 數據模式下因數據滯后和業務感知延遲所帶來的問題。

02 基于 Doris 的數倉建模

在構建新架構的同時，對數據表也進行了深度重構。基于 OneData 理論和 Apache Doris 的表模型設計，我們從底層建表邏輯出發，精心整理了以下內容，現與大家分享：

ODS 貼源層：使用主鍵模型備份 MySQL 的原始數據，可以接受 MySQL 歷史數據的物理刪除，從?減輕業務壓?，降低云上存儲成本。

DWD 明細層：主要使用主鍵模型，為了確保明細數據的準確性，也可以采用其他模型進行校驗。在此層將屏蔽 ODS 層的數據，以提高數據表的復用性。

DWS 匯總層：采用聚合模型來匯集不同維度的表數據，形成若?張 Base 表，后續基于 Base 表進?維度上卷或 BI 分析，使 SQL 語句更加簡潔、批處理性能得到提升。

APP 報表層：對接報表系統并定期通過郵件或辦公軟件發送至業務?，以供業務監控與業務決策。由于該層涉及到基于不同時間字段維度以及維度上卷，因此選用明細模型。

02 基于 Doris 的數倉建模.png

重構后的數據表結構更加簡潔，顯著提升了 SQL 語句的可讀性，也使得數據同步性能，有效減輕了大規模數據全量同步所帶來的沉重負擔，從而避免業務阻塞。

03 結算系統數據回流

早期業務結算系統的核心數據難以復用，資源浪費的同時，數據批處理的效率也較為低下。引入 Doris 后，基于 Doris 的數倉建模復用了 DM 層的數據，有效支撐了結算代償、回購對賬、賬戶管理等核心業務需求的及時處理。此外還接入了風控決策引擎，為其提供了實時反欺詐數據指標，實現了高效實時計算和核心數據回流。

得益于 Doris 出色的即席查詢和實時寫入能力，數據回流的調度執行耗時平均不超過 2 秒，業務系統的靈活性和數據響應速度相比之前提高了 8-12 倍。

03 結算系統數據回流.png

04 資源管理與權限控制

改造初期，由于資源管理配置不當，集群性能未達預期，可以通過調整 Workload Group 的并?查詢數量、等待隊列容量和超時時間，避免多條 SQL 語句搶占資源從?降低集群整體性能，此外，調整 Workload Group 的 max_concurrency、max_queue_size、queue_timeout 等參數，避免查詢超時。

Workload Group 相關數據開發的邏輯概念如下：

04 資源管理與權限控制.png

05 基礎性能優化項

早期架構由于缺乏系統性的架構設計理論依據，導致了組件開發與維護工作十分復雜，既未設置合理的數據分區，也未對存儲效率、查詢索引等數據管理機制進行合理規劃，所以在升級成為新架構時，浙江霖梓全面梳理并提煉業務關鍵指標，并針對 Doris 的各項基礎性能進一步優化，有效提高了離線 / 實時一體化數倉的數據處理效率。

分區分桶

在建表時設置合理的分區分桶字段，其??根據業務查詢時間區間與數據體量決定，原理與 Hive 分區分桶基本—致，需要注意的是，業務變更頻率較?的場景，不建議使??動分區。我們綜合考慮表數據量、增?趨勢、表使??法等情況，設置了動態分區，建表示例 SQL 如下：

PARTITION BY RANGE(k1) () 
DISTRIBUTED BY HASH(k1) 
PROPERTIES 
( "dynamic_partition.enable" = "true", "dynamic_partition.time_unit" = "DAY", "dynamic_partition.start" = "-7", "dynamic_partition.end" = "3", "dynamic_partition.prefix" = "p", "dynamic_partition.buckets" = "32" 
);

前綴索引

Apache Doris 的前綴索引屬于稀疏索引，表中按照相應的?數的數據構成—個邏輯數據塊（ Data Block），每個邏輯數據塊在前綴索引表中存儲—個索引項，其?度不超過 36 字節，查找前綴索引表時，可以幫助確定該?數據所在邏輯數據塊的起始?號。由于前綴索引內存占?較?，可以全量在內存緩存，并快速定位數據塊。設計原則?般遵循：<時間字段> + <分桶鍵> + <主鍵 id> ，對于 ODS 表，要確保這些字段不存在 NULL 值，否則會導致輸出數據不?致。

倒排索引

主要?于規則明細表與?志表中，?于快速統計規則路由情況以及關鍵詞出現頻次，減少資源占?率。Table 中的?對應?檔、列對應?檔中的某個字段，可以根據關鍵詞快速定位其所在?，達到 WHERE ?句加速的?的。

BitMap 去重

BITMAP 類型的列可以在 Aggregate 表、Unique 表或 Duplicate 表中使? ，針對—些特定的場景如 UV 、規則命中次數進?查詢加速。SQL 示例如下：

#建表 
create table metric_table ( dt int, hour int, device_id bitmap BITMAP_UNION 
) 
aggregate key (dt, hour) 
distributed by hash(dt, hour) buckets 1 
properties( "replication_num" = "1" 
); 
#查詢 
select hour, BITMAP_UNION_COUNT(pv) over(order by hour) uv from( select hour, BITMAP_UNION(device_id) as pv from metric_table -- 查詢每?時的累計UV where dt=xxx 
group by hour order by 1 
) res;

開啟執行優化器

在 Doris 2.1.x 版本中，建議啟用 Pipeline X 和 local shuffle，以進一步提升復雜查詢的執行效率。經過壓測，開啟 Pipeline X 優化器之后，性能提升了 20-30%。以下是 Pipeline X 優化器開啟狀態確認步驟：

#查看新優化器是否開啟
#確保值全為true 
show variables like '%enable_nereids_dml%'; 
show variables like '%experimental_enable_nereids_dml_with_pipeline%'; 
show variables like '%experimental_enable_nereids_planner%'; 
#默認 30，根據實際情況調整 
show variables like '%nereids_timeout_second%';

此時對 Doris 、Hive 、Spark 進行壓測，具體是對 15 個大表執行 join 操作，每張大表的平均數量約 13 億條，測試過程中還涉及了 2 個表之間的笛卡爾積計算。根據執行結果，Doris 平均耗時只需 6 分鐘。相比之下，Hive 執行相同任務耗時長達 2 小時，而 Spark 則執行失敗。

報表優化

ADS 報表層在建表時開啟 Merge-On-Write，以提升報表數據響應性能，同時開啟?列混存以及查詢緩存，避免刷新導致靜態數據重復查詢，影響集群性能。

#開啟?存
"store_row_column" = "true"

總結與規劃

截至目前，基于 Doris + Paimon 的實時/離線一體化湖倉架構已為反欺詐策略、用戶?為分析、業務監控、 BI 應用等若干系統提供了服務，實現查詢提速 30 倍、資源成本節省 67% 等顯著成效。未來，浙江霖梓將持續擴大 Apache Doris 在內部系統的使用范圍，并將對數據湖能力、智能實時應用進行探索及應用：

全面接入數據湖：逐漸擴大 Doris + Paimon 湖倉?體化架構的應用范圍，打通存量數據湖與 Doris 數倉的對接，為日后 PB 級數據的分析做好充分準備。
打造實時智能金融客服：推動 Doris App 報表豐富度的提升，將 Doris 數據導出到 Elasticsearch 做知識庫并接入?模型，通過 Prompt 與 GraphRAG 增強智能檢索落地智能?融問答系統。
打造智能營銷系統：將 Doris 作為知識庫做實現精準營銷，節約人力并且降低?為決策誤差，深度挖掘數據潛在價值。

最后，衷?感謝 SelectDB 與 Apache Doris 社區伙伴的相攜相伴，我們也會基于 Doris 進?離線 / 實時湖倉構建中持續挖掘，力求找到更優的問題解決方案，并回饋至社區。