想像一下你在經營一家咖啡店，門口架著一個攝影機，源源不斷拍下每個顧客的身影。這些影像就是事件流（Stream） - 一張又一張，無限播放。

但問題是，如果你想知道：

• 這位顧客今天第幾次光顧？
• 他這一週總共花了多少錢？
• 在他入座後 5 分鐘，點了什麼飲料？

你就不能只看眼前這一張照片，而是必須保留「之前發生的事」。這個「記住歷史」的能力，就是狀態運算（Stateful Operation）。

狀態是什麼？

在流處理系統中，**狀態（State）**指的是系統在處理新事件時，必須保留的歷史資訊。

狀態運算，就是依賴這些歷史資訊來完成計算的處理。

Stateless vs Stateful Processing:

Stateless:
Event1 ─→ [Process] ─→ Result1
Event2 ─→ [Process] ─→ Result2  (獨立處理，不記得 Event1)
Event3 ─→ [Process] ─→ Result3

Stateful:
Event1 ─→ [Process + State] ─→ Result1
                 ↓
Event2 ─→ [Process + State] ─→ Result2  (記住 Event1 的資訊)
                 ↓
Event3 ─→ [Process + State] ─→ Result3  (記住 Event1+2 的資訊)

狀態運算的例子

常見的狀態運算包括：

1. JOIN

保留一部分流 A 和流 B 的資料，等配對成功再輸出

Stream JOIN Example:

Orders Stream:     [Order1] ──┐
                              ├── [JOIN State] ── [Complete Order]
Payments Stream:   [Payment1]─┘
                        ↑
                   Need to store:
                   • Unmatched orders
                   • Unmatched payments

2. GROUP BY / 聚合運算

累計每個群組的統計值

Aggregation Example:

User Events ─→ [Aggregation State] ─→ User Statistics
                      ↑
               Store per user:
               • Visit count
               • Total spending
               • Last activity

3. Window Aggregation

計算時間區間內的平均值、最大值、總和

Window Aggregation:

Events ─→ [Window State] ─→ Window Results
              ↑
        Store in window:
        • All events in timeframe
        • Intermediate calculations

狀態儲存的方式

在 Streaming 系統中，狀態通常有兩種儲存方式：

1. 內嵌型（Local State Store）

Local State Store:

Stream Processor ──┬── Processing Logic
                   └── Local RocksDB
                           ↓
                    Checkpoint to HDFS

特點：

• 例如 RocksDB，直接跟處理節點放在一起
• 延遲低，適合高頻查詢
• 需額外的 checkpoint 機制來容錯

2. 外部型（External Store）

External State Store:

Stream Processor ── Network ── Redis/Cassandra/TiKV
                                      ↑
                               Shared across nodes

特點：

• 例如 Redis、Cassandra、TiKV
• 易於水平擴展與跨節點共享狀態
• 延遲較高，需考慮網路成本

業界現狀

目前以 Flink 為代表的主流 Streaming 系統，主要採用 Local State Store 方案：

為什麼 Local Store 統一江湖？

• 性能優先：流處理對延遲極度敏感，Local Store 的微秒級存取是關鍵優勢
• 技術成熟：RocksDB + Checkpoint 機制已經非常穩定
• 生態完整：Flink 等框架內建完善支援，開箱即用

Local State Store 的挑戰

光是把資料存在 Local State Store 還不夠，還必須解決：

• 持久化：節點重啟後，狀態不能消失
• 一致性：即使在分散式環境中，狀態也要保持正確
• 低延遲存取：處理新事件時，能即時讀寫狀態

如何實現這三大需求？

持久化的實現：

RocksDB (Memory + Disk) ─── Checkpoint ──→ HDFS/S3
                                          (定期快照)
           ↑                                   │
           └────── Recovery ←──────────────────┘
                 (節點重啟時)

• 定期 Checkpoint 將 RocksDB 狀態快照存到分散式檔案系統
• RocksDB 將狀態同時存在記憶體和磁碟，節點故障重啟時，從遠端儲存載入最新 Checkpoint 恢復狀態

一致性的實現：

Event Processing ──→ State Update ──→ Checkpoint Barrier
        │                               │
        └── 確保事件處理順序  ─────────────┘

• 透過 Checkpoint Barrier 機制，確保所有節點在同一時間點創建快照
• 保證分散式環境中狀態的一致性視圖

低延遲存取的實現：

Hot Data (Memory) ←── RocksDB ──→ Cold Data (SSD)
     ↑                              ↑
 微秒級存取                        毫秒級存取

• RocksDB 將熱門資料快取在記憶體，冷資料存在高速 SSD
• 結合本地存取，避免網路延遲

總結

狀態儲存是流處理從「無腦轉發」邁向「智能計算」的關鍵技術：

技術選擇：

• Local State Store（RocksDB + Checkpoint）已成為業界主流
• 犧牲一些擴展複雜度，換取微秒級存取性能

核心機制：

• RocksDB 提供記憶體 + 磁碟的分層儲存
• Checkpoint 實現分散式一致性與故障恢復
• 本地存取 避免網路延遲，滿足即時處理需求

有了狀態儲存，Streaming 才能真正執行 JOIN、聚合、窗口等複雜運算。

Day 13 預告：真正走向 Streaming Join

在 Day 13，我們不再把 JOIN 當成「查一次資料庫就好」的臨時補丁，而是正面踏入 Streaming JOIN 的世界。我們將透過 Join, GroupBy, Window 的實作，能更了解狀態實際的長相與實作，增進對有狀態運算的理解。

我們會以記憶體中的狀態管理為主要概念，讓你理解流處理如何用「記憶」完成有狀態運算，而不使用 RocksDB 的來當作實作講解。