作者簡介

Hao Yu，攜程資深大數據平臺開發工程師，關注實時計算、湖倉和大數據分布式計算等領域。

本文首先闡述了該方案的整體架構設計，重點介紹了為滿足生產環境約束而構建的兩階段 CDC 數據入湖機制，并詳細闡述了如何通過性能優化、動態更新和引擎改造等一系列實踐，攻克了生產環境中的關鍵挑戰。最終，通過在國際化營銷、廣告歸因等場景的應用，方案實現了端到端分鐘級延遲，驗證了其在降本增效和驅動業務敏捷決策上的顯著價值。

一、引言

二、架構設計：構建基于Flink和Paimon的近實時湖倉

2.1 近實時系統架構

2.2 ODS層數據入湖

2.3 增量計算

三、應用實踐：核心業務的價值實現

3.1 業務A：跨時區業績數據的準實時統一化方案

3.2 業務B：準實時聚合驅動的營銷決策看板

3.3 業務C：訂單分鐘級準實時歸因

四、成果總結

五、未來規劃

一、引言：從 T+1 到分鐘級，數據有效性的挑戰和機遇

攜程原有數據體系已構建了成熟的離線批處理鏈路，能夠支撐大部分 T+1（天級）或 T+1H（小時級）的數據分析場景。然而，隨著業務的持續增長與精細化運營的需求，數據新鮮度與計算成本之間的矛盾日益凸顯。

• 傳統離線數倉：雖具備成熟生態與成本優勢，但其核心瓶頸在于時效性低。
• 純實時計算：雖能實現秒級延遲，但在處理大規模數據時，面臨狀態管理成本高昂、消息中間件存儲開銷巨大等問題，導致總成本顯著增加。
• Lambda 架構：因實時與離線鏈路物理割裂，在面對融合分析需求時，往往需要雙團隊協同開發，涉及大量數據口徑對齊工作，造成高昂的人力協調成本，阻礙了業務敏捷響應。

為應對上述挑戰，業務亟需一個低門檻、低成本、端到端具備分鐘級延遲（目標 5-30 分鐘）的流批一體數據解決方案。該方案旨在統一數據處理鏈路，顯著提升端到端時效性，同時降低開發、運維負擔與總體運行成本。為此，我們選擇了 Flink + Paimon 的技術棧，并設計了一套創新的數據入湖架構來解決數據同步與數據應用，旨在從根源上解決這些挑戰。

二、 架構設計：構建基于 Flink 和 Paimon 的近實時湖倉

2.1 近實時系統架構

為實現上述目標，我們構建了如圖 1 所示的近實時數據處理架構。該架構以 Flink作為核心計算引擎， Paimon 作為湖倉存儲底座。數據通過 Flink CDC 從 MySQL 等業務數據庫捕獲變更數據流，實時寫入 ODS 層的 Paimon 表中。下游應用可根據需求，選擇多種消費與分析路徑：

• 實時/準實時 ETL：通過 Flink 作業持續消費上游 Paimon 表的增量數據，進行實時流式處理。
• 高速 OLAP 查詢：將計算結果物化或直接接入 StarRocks，滿足高性能、交互式的分析查詢需求。
• 靈活的 Ad-hoc 查詢與離線分析：借助 Trino 或 Apache Spark 引擎，對湖內數據進行靈活的即席查詢與大規模批處理分析。

通過該架構，我們為不同業務方提供了統一、多樣的近實時數據服務，實現了計算與存儲的高效協同。

圖 1：系統架構圖

2.2 ODS 層數據入湖

在技術選型上，我們選擇 Paimon 作為核心存儲底座，主要基于其與 Flink 生態的深度原生集成、靈活的 Merge Engine 機制（如 partial-update、aggregation）以及 LSM 樹結構的存儲模型。相比 Hudi 或 Iceberg，Paimon 在我們的 Upsert 密集型場景中展現了更優的寫入性能和更低的維護成本，有力支撐了近實時湖倉的構建。

2.2.1 兩階段 CDC 入湖架構設計

攜程大量業務數據存儲于 MySQL 中，其線上部署遵循 master-slave-slavedr 模式。為了保障線上數據庫的穩定性，我們對同步任務有一些限制策略：

• 讀取節點限制：數據同步任務只能從 Slave 節點讀取數據。
• Binlog 讀取限制：每個 MySQL 物理實例（Instance）僅允許一個線程讀取其 binlog，以避免并發讀取對 binlog 歸檔產生干擾。
• 連接數限制：單個賬戶對數據庫的最大連接數受限（不超過 40）。

上述單實例單線程讀取 binlog 的約束，是催生我們設計“共享 Source，獨立 Sink”兩階段 CDC 架構的根本原因。若為每個用戶的同步任務單獨啟動一個完整的 CDC 作業，將占用實例的唯一 binlog 讀取進程。因此，我們設計的 CDC 同步流程（如圖 2 所示）分為兩個獨立的階段：

  圖 2：cdc 同步流程圖

我們將 CDC 同步 Flink 任務主要分為兩大類：

第一階段（source 任務）：由平臺統一管理的共享 Flink 作業。該任務負責從指定 MySQL 實例讀取 binlog，并將增量數據分發至 Kafka。此任務對普通用戶透明且不可操作，確保了對核心 DB 資源的合規、高效復用。

第二階段（sink 任務）：由用戶自行管理的 Flink 作業。該任務從 Kafka 消費數據，并寫入目標 Paimon 表。用戶可對此任務進行啟停、配置等操作。

該架構支持單庫單表、單庫分表、分庫分表等多種同步模式，并通過平臺化的管理，實現了對復雜 DB 環境的有效適配。Sink 任務支持多種運行模式：

• 全量+增量一體化模式：首次啟動時，作業自動執行全量數據快照同步，完成后無縫切換至 Kafka 的指定位點，開始消費增量數據。
• 純增量模式：僅對增量數據感興趣的場景，作業直接從 Kafka 消費。
• 數據回補模式：用于異?；謴停举|是帶過濾條件的全量+增量一體化同步。

2.2.2 生產實踐優化與挑戰

1）同步鏈路性能優化

挑戰：我們的一階段任務是將 binlog 的增量數據同步至 Kafka，在最初上線的時候我們發現同步的速率較慢， 延遲較高，無法滿足分鐘級別的需求。

分析：分析發現主要有以下兩點原因：

• 單線程反序列化：從 MySQL 拉取數據后的反序列化操作在 Flink CDC Source 算子內部是單線程執行的。
• 單線程寫入 Kafka：由于 Source 算子與 Kafka Sink 算子默認 chain 在一起，導致寫入 Kafka 的操作亦為單線程，成為主要瓶頸。

如下圖 3 所示，即使你設置了并行度為 16， 實際的工作線程其實為 1。 這個環節存在較大的性能瓶頸。

解法： 為了優化這個問題， 我們在反序列化環節增加了埋點。通過數據分析，發現耗時更高的實際上是單線程寫 Kafka 這一塊，因此后面我們通過 db.table.primary_key 作為 Kafka key 來進行數據分發，這樣只需要做到主鍵之間的數據有序即可。這樣可以將解析 binlog 和寫 Kafka 進行解耦， 如下圖 1 所示。通過這種方式，數據處理吞吐量提升了近 10 倍。

  圖 3：Flink Source 任務優化前后拓撲對比

2）穩定性保障，支持數據回補

挑戰：數據可能因為作業異常而丟失， 如果每次出錯都需要全量回刷成本較高，必須具備可靠的數據回補（補數）機制。

分析：數據回補機制是保障數據質量的關鍵環節。我們探討了兩種方案，如圖 4 所示：

方案一：基于歸檔的 binlog 文件回放，優點在于可以完整還原增刪改操作，不依賴業務表結構；但這種方式依賴公司數據庫管理員（DBA）的支持。另外，由于公司不同的數據庫可能部署在同一臺物理機上，可能存在越權訪問非目標 DB 的問題。

方案二：基于時間戳字段回溯，依賴業務表中的 DataLastChange_time 等更新時間字段，通過篩選時間范圍來拉取數據。優點是實現簡單、依賴少。缺點是無法還原物理刪除操作，且強依賴表結構和時間字段的可靠性。

  圖 4：數據回補鏈路示意圖

鑒于攜程數據庫 MySQL binlog 中涉及到了大量的線上數據，基于安全考慮無法重放，因此我們主要采用的是第二種方案。用戶可在平臺上配置起始時間，一鍵啟動 Sink 任務。此模式下，作業會先拉取指定時間范圍的歷史數據，完成后自動切換到增量消費模式。

  圖 5：數據同步流程示意圖

解法：我們開發了帶有時間戳過濾的全增量一體的補數方案， 如圖 5 所示。用戶可以通過配置，可以進行一鍵補數。其核心是帶有時間戳過濾的全增量一體同步。但是這個方案存在一個局限：就是會導致 MySQL 一些被刪除的數據無法同步到 Paimon 中刪除。即在異常期間，源端數據庫已刪除的數據，其刪除操作未能同步到 Paimon，導致這些數據在 Paimon 中仍然存在。

另外，由于有一些作業存在特殊的邏輯，因此我們也開發了一些接口給用戶進行特殊補數。特殊補數可以通過用戶指定 sql 條件來進行補數。例如，線上有些邏輯刪除是通過將表中的 時間戳指定到一個特殊的年份來表示刪除，對于這些邏輯刪除的數據，如果用戶在補數時不希望同步它們，可以指定如下過濾條件：--data_backfill_condition mysql_db.mysql_table=not createtime<=>'2000-01-01'。支持補數的前提是因為我們的 Paimon 都是主鍵表，同步數據的操作是冪等操作。所以不會有數據的丟失。無論是基于時間戳的補數，還是帶有條件的特殊補數，cdc 二階段的作業都會在補數完成之后自動切換到增量消費的模式。

新的挑戰：補數模式隨之引入新麻煩，作業切完增量重啟后無法從 Checkpoint 恢復。補數參數會影響 Hybrid Source 中 Source 的數量。一旦補數完成、作業切換到增量消費模式后，若此時重啟作業，就會因為 Source 結構不一致導致無法從 checkpoint 正常恢復（即 Source State 無法恢復）。

新的解法：為了解決這一問題，我們在 flink 引擎側新增了一個配置項，允許 Flink 在恢復時直接從 Hybrid Source 中的最后一個 Kafka Source 啟動。這樣一來，無論是補數模式還是增量模式，作業都能平滑切換，徹底解決了兩種模式下的 checkpoint 兼容問題。

3）提升效率，平臺更好用

挑戰：當鏈路穩定運行之后，為實現平臺化，我們面臨一個問題：每當有新用戶需要同步新表時，都必須重啟共享的 Source 任務，這會引發下游所有消費任務的抖動。最初，我們嘗試同步一個 database 下的所有表，但很快發現這會向 Kafka 寫入大量非必要數據，且非目標表的批量操作（業務如凌晨刷數、歸檔等）會導致 binlog 暴增。

解法：為解決此問題，我們開發了 table-name 參數的熱更新功能， 如圖 6 所示。Source 任務僅同步用戶明確指定的表。當有新的同步鏈路加入時，數據平臺通過向 JobManager 發送請求，將新表名動態傳遞給運行中的 Source 算子。算子接收到新參數后，無需重啟作業即可開始監聽新表。該功能極大地減少了寫入 Kafka 的數據量，并避免了因任務重啟給下游帶來的抖動。

  圖 6：Flink Source 作業熱更新機制

新挑戰：對于數據量巨大或存在批量操作的源表，所有數據匯入單一 Kafka Topic，下游多個作業同時消費同一個 Topic，會導致 Topic 流量過載（峰值可達數十 GB/s），可能耗盡特定 Broker 節點的網絡帶寬，影響整個 Kafka 集群的穩定性。

最終解法：我們實現了 Topic 分流功能。用戶可通過配置路由表，將不同表的數據自動路由到不同的 Topic 中，下游 Sink 任務再根據路由信息消費對應 Topic，有效分散了流量壓力。

4）引擎側優化

a）Paimon bit 字段類型轉化優化 

在實際生產實踐中，根據不同的問題對引擎側做了一些優化。比如，我們發現在某些場景下，Paimon 對于 float 小數轉化存在錯誤。以及業務方需要基于 bit 類型轉化為 boolean（此功能后面在社區已經支持）。

b） Paimon schema 緩存優化 

另外在分庫分表同步中，作業啟動的時候，每一個 flink subtask 對于每一張表都需要對 Paimon 中進行 schema 驗證。如圖 7 所示，process 算子實際上是做 schema 變更的。在啟動初始化時收到了 1024 條數據。這一步通過 HDFS 來獲取 schema 文件速度較慢，會降低 flink 作業從 checkpoint 恢復速度，甚至會導致 checkpoint 失敗。因此我們開發了基于時間的 schema 緩存機制，在啟動時獲取一次 Paimon 的 schema 之后會緩存一分鐘。這大大縮短了作業啟動耗時。

  圖 7: Fink sink 任務 Paimon schema 緩存

c） Flink Hybrid Source 快速切換 

我們的全量同步和補數都是基于 Hybrid Source 來實現全量和增量自動切換的。在原生的 cdc 同步過程中為了保障 exactly once 語義，在讀取 MySQL snapshot 的時候會進行 binlog 數據的 merge。我們開啟了 scan.incremental.snapshot.backfill.skip 參數，加快了讀取速度。這樣處理雖提高了讀取速度，但整個鏈路僅能保障 At-Least-Once 語義。

另外我們支持了 only-snapshot 模式。這是因為，在某些分庫分表的場景下，我們遇到過 Hybrid source 中存在 180 個 source（批模式），這些 source 之間的切換是依賴一個 checkpoint 完成的。因此有時候可能補數本身運行時間是比較短的，大部分時間在等待 checkpoint 完成。此模式可以不必等待 checkpoint 完成，大大提高了補數的效率。

d）Paimon Bucket 動態步長 

Paimon 主鍵表的 bucket 數是一個比較重要的配置 ，Paimon 社區對于 bucket 數推薦是 每個 bucket 大約 200MB - 1GB 數據量。生產中我們發現 dynamic bucket 對于大量的數據而言，寫入性能不如 fixed bucket。某些場景下，我們支持了固定步長的 bucket 模式。支持業務方可以通過配置，比如根據數據大小，每增長 100 萬條數據增加一個 bucket。

5）全鏈路監控

我們建立了覆蓋全鏈路的表級別監控體系。通過內置的批流切換事件通知， 如圖 8 所示，用戶可以清晰地了解作業當前狀態（全量/增量/回補）。從 MySQL 到 Kafka，再到 Paimon，數據流在各環節的出入口均增加了表級別的指標埋點，用戶可基于這些指標配置數據斷流、延遲等告警，實現了精細化的可觀測性（圖 9-圖 10）。

  圖 8：source 任務狀態監控

  圖 9：表級別 MySQL 增量同步 Kafka 監控

  圖 10：表級別同步至 Paimon 數據監控

2.3 增量計算

數據入湖后，我們提供了多種增量計算方式。除了使用 Flink 持續消費外，還打通了 Spark 和 Trino 對 Paimon 表的增量讀取能力，實現了“批流一體”的計算模式。

圖 11：增量計算流程圖

目前，除了已有的 Flink 和 Spark 支持增量消費之外，我們已全面支持 Trino 對 Paimon 的讀寫、增量讀取及 Compact 操作。通過這一能力，Trino 可以無縫訪問 Paimon 存儲中的實時與歷史數據，支持高并發、低延遲的分析查詢。與此同時，Paimon 的高效數據管理和增量更新機制，也為 Trino 提供了更加輕量、實時的數據源。

兩者的深度融合有效提升了查詢性能與數據一致性，實現了計算與存儲的高效協同，進一步完善了湖倉一體的生態體系，為用戶帶來更靈活、更高效的數據分析體驗， 如圖 11 所示。另外，我們在 trino 中支持了對 hive udf 的復用，這樣可以降低用戶的遷移成本。在 trino 支持讀取 Paimon 的過程中需要注意以下幾點：

• 數據分發策略的一致性 
  在使用固定分桶（Fixed Bucket）模式時，Trino 側的數據分發策略必須與 Paimon Writer 內部的分發策略保持嚴格一致。兩者若出現不一致，會導致數據寫入錯誤的 Bucket，進而引發數據正確性問題和查詢結果異常。因此在實現時需要確保雙方使用相同的哈希算法和分桶邏輯。
• BucketFunction 并發安全 
  數據分發的核心實現是 BucketFunction 類。需要特別注意的是，該類的實例會在多個線程之間共享使用，因此必須保證其線程安全性。在實現時應避免使用可變的實例變量，或通過適當的同步機制來防止并發訪問導致的數據競爭問題。
• Catalog Schema 獲取優化 
  在原生實現中，Catalog 邏輯存在一個隱患：Coordinator 和 Worker 節點會并發地拉取同一張表的 Schema 信息。當查詢執行時間較長且期間發生了 Schema 變更時，各節點獲取到的 Schema 可能不一致，導致查詢失敗或結果錯誤。我們已將此邏輯優化為：由 Coordinator 統一拉取 Schema 后分發給各 Worker 節點，確保全局 Schema 一致性。但由于涉及 FileSystem 對象的序列化問題目前的實現方案在代碼層面不夠優雅，后續可考慮引入更優雅的 Schema 傳遞機制進行重構。

采用增量計算引擎，在大幅提升數據處理速度（尤其在變更頻繁場景）的同時，顯著降低全量計算資源消耗，優化整體計算成本。

三、 應用實踐：核心業務的價值實現

3.1 業務 A ：跨時區業績數據的準實時統一化方案

當前業務 A 國際業務已覆蓋多個區域，其中國際業績數據是公司眾多業務線決策數據之一。在國際數據處理的業績模塊下，某些業務日期是按照統一時區進行統計和更新，主要基于離線業績模型產生，其流程具有以下幾個特點：

• 依賴多個外部 BU 數據源
• 從數據源到結果產出，整體任務層級多、離線任務眾多，數據清洗和整合過程復雜，需要大量的計算資源和時間
• 未能全面進行模塊化建設，各層之間的數據依賴關系復雜

痛點：基于當前的架構可能會產生以下三種比較重大的問題：

• 統計日期窗口錯位 
  對于海外市場，業務日期窗口仍是按照北京時間來做時間窗口劃分，統計每天的數據結果，這就導致非 UTC+8 時區所展示的預訂業績數據，部分取自當天的數據，另外一部分取自前天的數據，進而導致數據統計不準確。
• 數據更新時間標識混淆 
  除統計數據外，目前數據的更新時間也是按照北京時間（UTC+8 時區）展示，對于所在時區排名比 UTC+8 靠后的業務數據，就可能會在所在時區仍在今天，但數據更新時間展示為明天的情況，造成商戶誤解。
• 數據產出時間不匹配工作時間 
  該延遲是指，從業務視角來看，數據可見時間與當地工作時間不匹配。

解決方案：解決上述問題的關鍵就是提升整體業績流程的更新頻率，通過更新加速，實現所有海外業務所在時區可以及時、準確看到業績統計數據。最終海外業務采用了近實時湖倉的鏈路，其整體的鏈路如下所示：

圖 12：業務 A 業績數據架構圖

我們采用 Flink CDC+Paimon+Trino/Spark 作為小時級數倉的技術底座，通過流式入湖和小時級調度，形成了從多源異構數據采集、分鐘級入湖、分層存儲管理到最終應用服務輸出的全鏈路技術架構。

價值：該架構產生了以下的價值

• 實現了數據分鐘級延遲的入湖能力：通過 FlinkCDC 接入 MySQL 表的 Binlog，同時 Paimon 表格式支持 Update，并支持流式寫入，分鐘級數據合并，從而實現如下優點：

a.低延遲性：通過 CDC+Kafka，實現 MySQL 變化數據的實時獲取和傳輸，基于 Paimon 的 ods 表延遲在 5 分鐘以內（延遲時間可按需設置，最低可以設置 1 分鐘）

b.鏈路復雜度低：僅需運維一個實時作業，實現全增量一體的數據同步

c.存儲成本低：得益于湖格式的 Snapshot 管理，加上 LSM 的文件復用，大幅節省存儲資源

• 聚合加速：依托 Paimon 表支持 PartialUpdate/Aggregation 等不同的 MergeEngine，減少 Join/Agg/Sort 等操作的消耗。
• 增量計算：通過 IncrementalQuery 機制，將全量計算轉為增量，大幅減少每次計算的是數據量，減少數據 IO。Paimon 的增量計算能力，可以支持如下兩點功能：

a.查詢當前全量和歷史版本的全量快照數據

b.獲取兩個全量版本之間的增量數據

• 端到端提效：基于上述 3 項優勢，最終實現業績數據從 ODS 到 ADM 層的產出提效，在 1 小時內完成一個調度批次。

改造后整體的收益主要有以下兩點：

• 效率提升：提升業績匯總數據的更新頻率和產出時間，保障海外業務和商戶可以在工作時間盡早的關注到數據情況。
• 準確性保證：保障了海外單店可以按照所在地時區對日期進行篩選，獲取符合海外商戶認知的 T-1 日及更早數據。

3.2 業務 B：準實時聚合驅動的營銷決策看板

業務 B 在全球化戰略的背景下，一直在努力推進國際化戰略部署。目前海外業務已經集中在英國、亞洲和歐洲各國。

痛點：伴隨著業務的發展，在實際的生產中存在以下的問題。

• 離線看板與營銷側對數據時效性有更高要求，如：供應商異常處理批量退款，以及海外營銷策略的調整，當前的數據新鮮度無法滿足業務需求。
• 國際業務的員工分散世界各地，時差問題導致 T+1 天數據不符合海外員工的使用習慣。過往國際 T+1 小時票量統計，是通過與后端合作，由后端處理好部分邏輯，數倉再通過 DataX 進行小時級同步，進行邏輯的二次處理。每小時的批量重復同步造成了計算資源的浪費，兩邊團隊耦合的開發也降低了開發效率。

解決方案：以業務 B 營銷活動為例，改造完成之后的架構圖如下所示：

圖 13：業務 B 營銷看板架構圖

價值：其中業務 B 利用 Paimon 的 partial update 機制。可以避免 Flink 多流 Join 帶來的多個問題：

• 避免了高昂的 Join 成本；
• 防止了因多流導致的 Checkpoint 狀態過大及作業不穩定；
• 解決了因數據流到達時間差異大而無法關聯的問題；

新架構支持銷售監控、客流統計、收入匯總等多維度實時分析場景。同時也支持增量查詢機制，大幅提升查詢性能。確保數據質量和系統穩定性。解決了因時差問題導致 T+1 數據不符合海外員工使用習慣的問題。延遲由天級降到了分鐘級。同時也優化了之前加工鏈路較為復雜，難以維護的問題，使得運維效率得到了大幅提升。

3.3 業務 C：訂單分鐘級準實時歸因

業務 C 聚焦于為企業客戶提供一站式差旅服務，涵蓋機票、酒店、用車、火車等多種場景?？蛻艨赏ㄟ^該系統完成預訂、審批、報銷等完整流程，隨著服務鏈條延伸、數據流轉環節增多，數據量與復雜度持續增長。伴隨業務成長及產品形態豐富，對數據時效性的要求也日益提高。過去的 “T+1” 離線數倉架構已無法滿足對“準實時”數據分析的需求，而采用傳統基于流式平臺的實時數倉雖能處理部分實時計算場景，但其適用性受限，且其計算中間層難以直接用于分析。

在廣告投放場景方面，涉及廣告的曝光、點擊與下單行為的準實時上報。下單行為需與用戶近 3 日內的點擊日志進行歸因匹配，只有在下單前 3 日內存在有效點擊行為的訂單，方會上報給廣告主。該訂單上報流程對響應速度有一定要求，業務方希望實現從觸發到上報端到端的分鐘級時效。

痛點：在實際落地過程中，面臨以下挑戰：  

• 上報所需字段和邏輯在業務系統中涉及 7 張 MySQL 表，實時多流 Join 實現難度和成本較大、穩定性挑戰較大。
• 點擊日志每日增量多，數據表膨脹速度較快，需有效控制表存儲，保障查詢和 Join 性能。

如何高效整合多表數據、管理膨脹的點擊日志表，并滿足分鐘級別的上報時效，是該場景下的核心業務痛點。

解決方案：業務實際改造完之后整個鏈路如下：

圖 14：廣告訂單歸因準實時上報架構圖

價值：改造后，從最上游的 MySQL 數據到最終的結果歸因，端到端時延在 8 分鐘以內（還可通過調整 checkpoint 間隔進一步降低），下游業務方表示當前延遲在可接受范圍內。和之前的整個離線計算邏輯相比，數據延遲降低了 8 倍，達到準實時的效果。

四、成果總結

攜程近實時湖倉生產實踐深度總結：面對數字化轉型浪潮和業務對實時數據分析需求的急劇增長，攜程從傳統數據倉庫的小時級延遲痛點出發，歷經技術選型、架構設計、生產落地等關鍵階段，成功構建了一套完整的近實時湖倉一體化解決方案。該方案以 Flink 作為流處理計算引擎，Paimon 作為湖倉存儲底座，形成了從多源異構數據采集、實時 ETL 處理、分層存儲管理到業務服務輸出的全鏈路技術架構。

我們最終實現了：

• 數據新鮮度達到分鐘級：采用全增量一體化處理模式，顯著降低因傳統離線全量與實時增量雙鏈路并行帶來的復雜性與維護成本。
• 端到端時效躍升： 端到端數據處理時效從天級提升至 5-30 分鐘級，滿足準實時分析需求。
• 主鍵更新賦能實時場景： 湖倉提供原生主鍵（Upsert）更新能力，有效支撐實時訂單狀態、用戶畫像更新、實時維表變更等需要行級更新的核心業務場景。
• 增量計算降本增效： 采用增量計算引擎，在大幅提升數據處理速度（尤其在變更頻繁場景）的同時，顯著降低全量計算資源消耗，優化整體計算成本。

五、未來規劃

征途仍在繼續。未來，我們將致力于：

• 構建分鐘級 SLA 保障體系： 建立覆蓋全鏈路的、具備分鐘級時效性保障能力的 SLA 機制，并配套完善的多級監控與告警體系，確保數據生產的高可靠性與可觀測性。
• 強化 Paimon 表治理能力： 深化 Paimon 表核心管理功能，元數據治理（如血緣、Schema 變更跟蹤）及自動化生命周期管理（如自動 Compaction、數據過期清理），提升表管理效率與數據質量，支撐高頻更新等復雜場景。
• 推動準實時鏈路規?；涞兀?持續擴大準實時湖倉架構在核心數倉場景的應用范圍，沉淀并推廣最佳實踐，實現技術價值向業務價值的高效轉化與閉環。