昨天我們探討了 Flink + Iceberg 如何在分鐘級延遲下提供更好的成本效益，看到了 Data Lakehouse 架構的優勢。但你可能會好奇：既然 Flink 在流式處理領域如此強大，為什麼不直接開發一個專門為流式處理優化的 Lakehouse 格式呢？

答案就是今天的主角：Apache Paimon（原名 Flink Table Store）- 由 Flink 社群開發的流式原生 Lakehouse 格式。

Paimon 的誕生背景

• 串流優先：以串流處理為第一優先
• 低延遲：分鐘到秒級的串流延遲
• 即時 OLAP：支援即時分析查詢
• 成本效益：更好的壓縮比與儲存效率
• 統一介面：批次與串流的統一操作介面

Paimon 的核心技術創新

1. LSM-Tree 存儲引擎

Paimon 採用 LSM-Tree (Log-Structured Merge Tree) 作為底層存儲結構，這是 NoSQL 資料庫常用的架構：

LSM-Tree in Paimon:
┌─────────────────────────────────────────────────────────┐
│                    Memory                               │
│ ┌─────────────┐  ┌─────────────┐                        │
│ │ MemTable 1  │  │ MemTable 2  │                        │
│ │ (Active)    │  │ (Flushing)  │                        │
│ └─────────────┘  └─────────────┘                        │
└─────────────────────┬───────────────────────────────────┘
                      │ Flush to Disk
                      ▼
┌─────────────────────────────────────────────────────────┐
│                   Disk Storage                          │
│ Level 0: [SST1] [SST2] [SST3] [SST4]                    │
│ Level 1: [──── SST5────] [────SST6────]                 │
│ Level 2: [──────────SST7──────────]                     │
│                                                         │
│ New data in upper levels, periodic merge to lower       │
└─────────────────────────────────────────────────────────┘

LSM-Tree 的流式優勢：

• 寫入友好：新數據直接寫入內存，無需立即整理文件結構
• 壓縮效率：背景自動合併小文件，保持良好的文件大小

Paimon 的進階特性

Partial Update：取代多流 JOIN 的大狀態問題

實時寬表的傳統困境：

在實時場景下，通常需要構建大寬表來支持 Ad-Hoc Query。傳統做法是使用多流 JOIN：

訂單流 + 用戶流 + 商品流 + 支付流 + 物流流
         ↓
    流式 JOIN 引擎
         ↓
      大寬表

多流 JOIN 的狀態爆炸問題：

• 狀態膨脹：需要在內存中維護所有流的歷史數據等待關聯
• 資源浪費：大量狀態長期駐留內存，消耗巨大計算資源
• 延遲不穩定：狀態過大導致 checkpoint 時間過長，影響處理延遲

Partial Update 的解決方案：

Paimon 通過 Partial Update 將 JOIN 操作下沉到存儲層：

訂單流 → 寫入訂單相關欄位
用戶流 → 寫入用戶相關欄位
商品流 → 寫入商品相關欄位
支付流 → 寫入支付相關欄位
物流流 → 寫入物流相關欄位
→ 存儲層自動 Merge 
→ 完整寬表

核心優勢：

• 無狀態處理：計算層不需要保留任何 JOIN 狀態，大幅節省資源
• 存儲層拼接：數據在寫入時自動按主鍵合併，與計算引擎無關

Lookup Join：取代外部緩存的維度查詢

以往在流處理中需要 Lookup Join 數據時，常見做法是：

流式事件 → 查詢 Redis/KV → 獲取資料 → 組裝完整記錄

傳統方案的問題：

• 額外維護成本：需要維護 Redis 或 KV 等外部系統
• 數據一致性風險：緩存與原始數據可能不同步
• 資源開銷：維度表數據需要額外的存儲
• 查詢延遲：網絡調用增加處理延遲

Paimon Lookup Join 的解決方案：

Paimon 直接支援 Lookup Join：

流式事件 → 直接 JOIN Paimon 維度表 → 獲取資料 → 組裝完整記錄

核心優勢：

• 統一存儲：使用同一套存儲系統，減少架構複雜度
• 成本節省：不需要維護額外的 Redis 或 KV 集群
• 查詢高效：基於 LSM-Tree 的索引結構提供快速的點查詢能力

支援索引

目前 Iceberg 不支援索引，但 Paimon 支援欄位等級的索引，可有效加強點查詢與範圍查詢能力

file-index.bloom-filter.columns: specify the columns that need bloom filter index.
file-index.bloom-filter.<column_name>.fpp to config false positive probability.
file-index.bloom-filter.<column_name>.items to config the expected distinct items in one data file.


file-index.bitmap.columns: specify the columns that need bitmap index.
file-index.bitmap.<column_name>.index-block-size: to config secondary index block size, default value is 16kb.


file-index.range-bitmap.columns: specify the columns that need range-bitmap index.
file-index.range-bitmap.<column_name>.chunk-size: to config the chunk size, default value is 16kb.

Flink 生態整合性良好

例如與 Flink-CDC 整合，能自動達成 auto schema evolution

與 Iceberg 整合性高

Paimon 支援產生與 Iceberg 相容的元數據，以便 Iceberg 使用者可以直接使用 Paimon 表。

總結：進一步降低成本與延遲的 Lakehouse 方案

Paimon 繼承了 Iceberg 統一批流存儲的成本優勢，並在延遲性能上實現了重大突破，並增加了不少功能讓 streaming 生態更完整，與 Iceberg 一樣，Paimon 不需要維護 Kafka + OLAP Database 的多套存儲系統，帶來了顯著的系統成本降低和維運複雜度簡化。

延遲性能的重大提升

在延遲表現上，Paimon 相比 Iceberg 有了質的飛躍：

Latency Comparison:
┌────────────────────────────────────────────────────┐
│ Iceberg: 5-10 minutes (small file problem)         │
│           ↓                                        │
│ Paimon:  30 seconds - 1 minute (LSM-Tree optimized)│
└────────────────────────────────────────────────────┘

關鍵技術差異：

• 寫入機制：Paimon 的 LSM-Tree 支援高效的增量寫入，無需等待大文件累積
• 讀取優化：內建索引，無需掃描大量小文件
• 狀態處理：存儲層直接支援 JOIN 和 UPDATE，計算層無狀態開銷

實務應用的選擇指南

Business Latency Requirements:
┌──────────────────────────────────────────────────────┐
│ < 1 second:     Kafka + Flink (millisecond real-time)│
│ 30s - 1 minute: Paimon (near real-time)              │
│ 5-10 minutes:   Iceberg (near real-time)             │
│ > 1 hour:       Traditional batch processing         │
└──────────────────────────────────────────────────────┘

Paimon 填補了 Kafka 的高成本複雜性和 Iceberg 的高延遲之間的空白，為大多數準實時業務場景提供了理想的平衡點。

Day 27 預告：RisingWave

在深入了解了 Flink、Kafka、Iceberg、Paimon 等技術後，你可能會問：「這些方案看起來都很強大，但在實際開發中遇到的痛點呢？」

下一章我們將分享筆者的真實經歷：為什麼在使用 Flink 一段時間後，開始考慮更易用的 SQL-based 流處理引擎。