過去幾天我們深入探討了 Flink + Kafka 的 Kappa 架構，從基礎概念到生產優化，見證了這套經典組合的強大能力。但技術永不停歇，當我們解決了狀態管理、性能優化等技術難題後，新的挑戰又浮現了：成本控制和架構複雜度。

今天我們要探討一個正在興起的新架構：Flink + Iceberg，看看它如何在滿足業務需求的同時，帶來更好的成本效益。

Kappa 架構的成功與局限

經典 Kappa 架構的優勢

Classic Kappa Architecture:
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  OLTP    │───>│  Kafka   │───>│  Flink   │───>│  OLAP    │
│ Systems  │    │  Topics  │    │   Jobs   │    │ Database │
└──────────┘    └──────────┘    └──────────┘    └──────────┘

技術優勢：

• 毫秒級延遲：事件到達後立即處理
• 強一致性：Exactly-once 保證
• 高吞吐量：分散式並行處理
• 容錯能力：自動故障恢復

業務價值：

• 實時風控：毫秒級檢測異常交易
• 實時推薦：用戶行為立即影響推薦結果
• 實時監控：系統異常秒級告警

隱藏的成本挑戰

但當系統運行一段時間後，你會發現一些隱藏的成本問題：

注意：以下所有數字僅為示意參考，實際成本會因企業規模、地理位置、供應商選擇等因素而有很大差異。重點在於理解不同架構的成本結構差異。

1. 儲存成本的指數增長

Kafka Storage Cost Growth:
Month 1: 10TB × $0.12/GB = $1,200/月
Month 6: 60TB × $0.12/GB = $7,200/月
Month 12: 120TB × $0.12/GB = $14,400/月

問題根源：

• Kafka 需要保留所有歷史數據或重新打入歷史數據以支援重放
• 多副本機制進一步增加儲存需求

2. 運維複雜度的倍增

Operation Complexity:
├── Kafka Cluster
   ├── Broker 配置調優
   ├── Topic 分區管理
   ├── Consumer Lag 監控
   └── 跨機房複製

人力成本：需要 3-5 個專業工程師維護整套系統

業務需求的重新審視

真的需要毫秒級延遲嗎？

讓我們重新審視實際的業務需求：

高頻交易場景

要求: < 10ms 延遲
適合: Flink + Kafka
理由: 毫秒級的價差就是利潤

電商推薦系統

要求: < 5分鐘延遲
適合: Flink + Iceberg  
理由: 用戶瀏覽商品到下單通常需要數分鐘

營運報表

要求: < 15分鐘延遲
適合: Flink + Iceberg
理由: 管理層查看報表不需要秒級更新

用戶行為分析

要求: < 30分鐘延遲
適合: Flink + Iceberg
理由: 分析結果用於中長期決策

Data Lakehouse：統一批流的新思路

什麼是 Data Lakehouse？

Data Lakehouse 結合了 Data Lake 的靈活性和 Data Warehouse 的結構化能力：

Traditional Architecture:
┌─────────────┐    ┌─────────────┐    ┌──────────────┐
│ Data Lake   │    │   ETL       │    │Data Warehouse│
│(Raw Data)   │───>│ Process     │───>│(Clean Data)  │
│Flexible     │    │             │    │ACID Support  │
└─────────────┘    └─────────────┘    └──────────────┘

Data Lakehouse:
┌─────────────────────────────────────────────────────┐
│              Data Lakehouse                         │
│ ┌─────────────┐ + ┌─────────────┐ + ┌─────────────┐ │
│ │ Raw Data    │   │Schema Evo.  │   │ACID Support │ │
│ │Storage      │   │& Metadata   │   │& Time Travel│ │
│ └─────────────┘   └─────────────┘   └─────────────┘ │
└─────────────────────────────────────────────────────┘

核心特性：

• 統一存儲：批處理和流處理使用同一份數據
• ACID 事務：支援資料一致性
• Schema Evolution：結構變更不影響歷史數據
• Time Travel：可以查詢任意歷史時點的數據
• 成本優化：基於物件存儲，成本更低

Apache Iceberg：Lakehouse 的技術實現

Apache Iceberg 是實現 Data Lakehouse 的開源表格式：

Iceberg Table Structure:
┌─────────────────────────────────────────────────────┐
│                Catalog                              │
│           (Table Metadata)                          │
└─────────────────┬───────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────┐
│              Metadata Files                         │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐     │
│ │ Manifest    │ │ Manifest    │ │ Manifest    │     │
│ │ File 1      │ │ File 2      │ │ File 3      │     │
│ └─────────────┘ └─────────────┘ └─────────────┘     │
└─────────────────┬───────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────┐
│              Data Files                             │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐     │
│ │   Parquet   │ │   Parquet   │ │   Parquet   │     │
│ │   File 1    │ │   File 2    │ │   File 3    │     │
│ └─────────────┘ └─────────────┘ └─────────────┘     │
└─────────────────────────────────────────────────────┘

技術優勢：

• 增量讀取：只讀取變更的文件，支援流式處理
• 事務保證：寫入操作具備 ACID 特性
• 元數據優化：快速定位需要的數據文件
• 壓縮效率：Parquet 格式提供高壓縮比

Flink + Iceberg：最佳實踐

新架構設計

Flink + Iceberg Architecture:

┌──────────┐    ┌──────────────┐
│  OLTP    │───>│    Flink     │
│ Systems  │    │Stream Jobs   │
└──────────┘    └──────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────────┐
│                    Iceberg Storage Layer                    │
│                                                             │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐ │
│ │   Bronze    │ │   Silver    │ │         Gold            │ │
│ │ (Raw Data)  │ │(Cleaned)    │ │   (Business Ready)      │ │
│ └─────────────┘ └─────────────┘ └─────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
                       │
         ┌─────────────┼─────────────┼─────────────┐
         │             │             │             │
         ▼             ▼             ▼             ▼
┌──────────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐
│Query Engines │ │Batch Jobs│ │ Flink    │ │  BI Tools   │
│              │ │          │ │Streaming │ │& Dashboards │
│              │ │          │ │Jobs      │ │             │
└──────────────┘ └──────────┘ └──────────┘ └─────────────┘

核心特性：

• 統一存儲：多個需求可以使用同一份數據
• Layer 資料可查詢：可直接查詢各 Layer 資料，方便排查

為什麼 Iceberg 延遲是分鐘級？

• Snapshot 比對機制：Flink streaming read Iceberg 是透過比對兩次 snapshot 的差異來識別新數據，這個比對過程需要時間
• Checkpoint 間隔限制：Flink 向 Iceberg 的 commit 頻率與 checkpoint 間隔綁定，每次 checkpoint 才會提交一個新的 snapshot
• 小文件問題：如果 checkpoint 間隔過小（如秒級），會導致 Iceberg 產生過多小文件，嚴重影響查詢性能和存儲效率
• 最佳實踐考量：實務上 checkpoint 間隔設置為 1-5 分鐘是平衡延遲和文件大小的最佳實踐
• 元數據開銷：每次 snapshot 更新都需要更新表的元數據，頻繁更新會增加元數據存儲的負擔

注意：V3 版本的改進
隨著 Apache Iceberg V3 的發展，streaming read 能力得到了顯著加強，使得延遲可以進一步降低。但基於文件系統的本質特性，分鐘級延遲仍是目前的最佳實踐。

成本效益分析

注意：以下所有數字僅為示意參考，實際成本會因企業規模、地理位置、供應商選擇等因素而有很大差異。重點在於理解不同架構的成本結構差異。

成本對比

12個月總成本對比:

Kafka + Flink + OLAP:
├── Kafka Storage: $100,000
├── Flink Compute: $180,000  
├── OLAP Storage: $50,000
└── 總計: $330,000

Iceberg + Flink:
├── Object Storage: $20,000
├── Flink Compute: $180,000
├── Query Engine: $10,000
└── 總計: $210,000

總結

Flink + Iceberg 架構的興起反映了技術演進的一個重要趨勢：從追求極致性能到平衡成本效益。

當 Kafka 架構解決了實時性問題後，新的挑戰是成本控制和運維簡化。Iceberg 通過統一批流處理，在略微犧牲延遲性的前提下，大幅提升了成本效益和開發效率。

技術選擇沒有標準答案，關鍵是理解業務需求的本質。當你的業務真正需要毫秒級響應時，Kafka 仍是不二選擇；當你的業務可以接受分鐘級延遲時，Iceberg 可能是更明智的選擇。

真正的技術智慧在於：不盲目追求最新技術，也不固守舊有方案，而是根據具體場景做出最適合的權衡。

Day 26 預告：Flink Paimon - 流式原生的 Lakehouse 格式

Iceberg 雖然在成本效益上有優勢，但你可能會好奇：既然 Flink 在流式處理領域如此強大，為什麼不直接開發一個專門為流式處理優化的 Lakehouse 格式呢？

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