經過這些天對 Flink 生態系統的深入學習，從基礎概念到 Kafka、Iceberg、Paimon 等技術棧，我們見識了 Flink 的強大能力。但作為一個在實際工作中使用過 Flink 的工程師，我必須誠實地分享：技術再強大，如果開發和維護成本過高，在商業環境中就不一定是最佳選擇。
今天我們要聊聊 Flink 在實際使用中的痛點，以及為什麼越來越多團隊開始考慮 RisingWave 這樣的新一代流處理引擎。
RisingWave 是一個流式資料庫（Streaming Database），採用 PostgreSQL 兼容的 SQL 語法，專為簡化實時數據處理而設計。
RisingWave Architecture:
┌───────────────────────────────────────────────┐
│ PostgreSQL-Compatible │
│ SQL Interface │
└─────────────────────┬─────────────────────────┘
│
┌─────────────────────▼─────────────────────────┐
│ Compute Layer │
│ (Rust-based Stream Engine) │
└─────────────────────┬─────────────────────────┘
│
┌─────────────────────▼─────────────────────────┐
│ Storage Layer │
│ (S3-Compatible Object Storage) │
└───────────────────────────────────────────────┘
核心設計理念：
效能對比 (Nexmark Benchmark):
┌─────────────────────────────────────────────────────┐
│ RisingWave outperformed in 22 out of 27 queries │
│ Average performance: 12 queries improved ≥50% │
└─────────────────────────────────────────────────────┘
架構簡化：
Traditional Flink Architecture:
Raw Kafka ──► Flink #1 ──► Kafka Bronze
│
▼
Flink #2 ──► Kafka Silver
│
▼
Flink #3 ──► Kafka Gold
│
▼
External Query System
(OLAP DB)
RisingWave Unified Architecture:
Raw Data ──► ┌────────────────────────────┐
│ RisingWave │
│ │
│ Bronze ──► Silver ──► Gold │
│ ▲ ▲ ▲ │
│ │ │ │ │
│ └── SQL Query Access ┘ │
└────────────────────────────┘
維護優勢：
RisingWave 的三層狀態架構：
RisingWave 採用獨特的三層狀態管理架構，通過 Hummock 存儲引擎實現高效的狀態管理：
RisingWave State Management (3-Tier Architecture):
┌─────────────────────────────────────────────────────┐
│ Layer 1: Memory (Hot Data) │
│ • Hottest data resides in memory │
│ • Provides lowest latency access │
└─────────────────────┬───────────────────────────────┘
│ Auto Flush
┌─────────────────────▼───────────────────────────────┐
│ Layer 2: Local Disk (Warm Data) │
│ • SSD local cache │
│ • Balances performance and cost │
└─────────────────────┬───────────────────────────────┘
│ Periodic Sync
┌─────────────────────▼───────────────────────────────┐
│ Layer 3: S3 Object Storage (Cold Data) │
│ • Permanent persistent storage │
│ • Unlimited scalability │
└─────────────────────────────────────────────────────┘
與 Flink 1.x 的狀態管理對比：
Flink State Management:
┌─────────────────────────────────────────────────────┐
│ RocksDB Local State → Periodic Checkpoint → S3 │
│ │
│ Issues: │
│ • Only two layers: local state + checkpoint │
│ • Checkpoint is time-consuming, affects real-time │
│ • Recovery requires loading all state from S3 │
└─────────────────────────────────────────────────────┘
Hummock 存儲引擎的關鍵特性：
PostgreSQL 兼容性：
-- 創建 Materialized View
CREATE MATERIALIZED VIEW user_stats AS
SELECT
user_id,
COUNT(*) as order_count,
SUM(amount) as total_amount,
AVG(amount) as avg_amount
FROM orders
GROUP BY user_id;
-- 直接查詢實時結果
SELECT * FROM user_stats WHERE user_id = 12345;
查詢優勢：
在了解了 RisingWave 的技術優勢後，讓我們看看如何將實際的業務場景從 Flink 遷移到 RisingWave。
回顧我們在 Day 24 討論的複雜 Flink SQL Pipeline：多流 JOIN、狀態管理、歷史數據補償等挑戰。現在讓我們看看同樣的業務邏輯在 RisingWave 中如何實現：
RisingWave Optimized Architecture:
Orders Stream ──┐ ┌── OrderDetail Stream
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
┌────►│Bronze Orders│ │Bronze Detail│◄─┐
│ │(All History)│ │(All History)│ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ State:
│ ▼ ▼ │ ┌─────────┐
│ ┌─────────────────────────────┐ │ │ Memory │
│ │ [INTERVAL JOIN: 1h window] │────┼──►│ (Hot) │
│ │ Stateful computation │ │ └────┬────┘
│ └─────────────┬───────────────┘ │ │
│ │ │ ▼
│ ▼ │ ┌─────────┐
│ ┌────────────────────────────┐ │ │ Disk │
│ │ [Historical Lookup] │ │ │ (Warm) │
│ │ Need historical data? │ │ └────┬────┘
│───│───────LOOKUP JOIN ─────────┼─────│ │
│ │ ▼
└────────────────────────────┘ ┌─────────┐
│ │ S3 │
│ │ (Cold) │
│ └─────────┘
│
▼
┌─────────────────┐ ┌──────────┐
│ Silver Wide │◄────│ psql │
│ │ │ Query │
└─────────┬───────┘ └──────────┘
│
▼
┌─────────┼────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐┌─────────┐┌─────────┐
│ Gold A ││ Gold B ││ Gold C │
└────┬────┘└────┬────┘└────┬────┘
│ │ │
└──────────┼──────────┘
▼
┌──────────┐
│ psql │
│ Query │
└──────────┘
這個 RisingWave 架構相比傳統 Flink 方案實現了以下重要改進：
所有層級都可直接查詢：
智能分層存儲：
歷史數據補償通過 LOOKUP JOIN 直接訪問 Bronze 表，無需 Redis/KV
傳統方案困境：
Flink Pipeline → 發現需要歷史數據 → LOOKUP JOIN Redis/KV
RisingWave 解決方案：
RisingWave Pipeline → 需要歷史數據 → LOOKUP JOIN Bronze 表
核心優勢：
開發體驗：
運維複雜度：
從 Flink 到 RisingWave 的考慮，反映了流處理技術的一個重要趨勢：從追求技術的極致靈活性，轉向追求開發效率和維護簡便性。
在實際的技術選擇中，我們常常面臨一個根本性的問題：技術的先進性和團隊的駕馭能力之間如何平衡？Flink 無疑是一個技術成熟、功能強大的流處理引擎，擁有豐富的生態系統和大量的企業級應用案例。但正如我們在這些天的學習中所體會到的，掌握 Flink 需要深入理解分散式系統、狀態管理、時間語義等複雜概念，這對團隊的技術水平提出了很高要求。
RisingWave 的出現提供了一個不同的思路。它選擇了用熟悉的 SQL 語言來降低學習門檻，用統一的流式資料庫架構來簡化系統複雜度，用三層狀態管理來提升故障恢復能力。這種設計哲學體現了一個重要觀念：對於大多數業務場景，簡單可靠往往更重要。
透過這些天的深入學習，我們見證了流處理技術的快速演進。從 Kafka 到 Flink 展現的強大處理能力，再到 Iceberg 和 Paimon 帶來的存儲創新，以及 RisingWave 提出的簡化理念，每一項技術都在解決特定的問題，滿足不同的需求。重要的是培養分析問題本質的能力，根據具體的業務場景和團隊情況，做出最合適的技術選擇。
流處理領域的發展從未停歇。Apache Flink 社群於2025年已發布下一代的 Flink 2.0，同時一個名為 Fluss 的新項目也正在嶄露頭角。這些前沿技術又會為流處理領域帶來什麼新的可能性呢？
iThome鐵人賽
看影片追技術
看更多