Netflix 讓 Cassandra 直接讀 S3 備份，取代 Kafka/Flink 冷資料串流
Netflix TechBlog · 2026-10-14
Netflix 的 TimeSeries 冷資料層，從「Kafka + Flink 把事件另存一份到 S3」改成「Cassandra 直接讀自己已經存在 S3 的備份」，省掉整套串流基礎設施。做法是 Cassandra 4.1 的 pluggable Memtable 加上自製的 ReadOnlyCompactionStrategy（ROCS）。
作者是 Oleksii Tkachuk 等人。目前這個冷層已存放超過 15 PB 壓縮後資料，受影響叢集的磁碟用量從 80% 降到 7%。
原本的問題
TimeSeries Abstraction 是 Netflix 儲存事件資料的平台，最大的資料集已達數個 PB。熱儲存為了低毫秒延遲而調校，成本很高，而多數查詢只碰最近的事件，舊資料只在稽核與調查時偶爾被讀。
使用者還一直要求拉長保留期，磁碟密度因此持續上升，擴容、部署與叢集穩定度都受影響。文中把需求歸納為：舊資料要便宜、API 要不變、內部工具仍要求亞秒級查詢。
第一代：Kafka 與 Flink 串流到 S3
第一代設計在寫入 Cassandra 的同時，把資料即時串流進 S3。時間序列 ID 先雜湊分桶，每個桶由專屬的 Flink task 處理，並依小時內的事件時間批次寫成 Parquet 檔。
小檔不利低延遲讀取，所以每天跑一次壓縮作業，把它們合併成每個 namespace 一個每日 Parquet 檔，並做三件事：
- row group 縮到 4–8 MB，因為讀取以點查與範圍查為主，文中說這刻意低於 Parquet 建議的下限。
- row group 內依時間排序，查時間範圍不必暴力掃描。
- Bloom filter 與檔案 metadata 快取在 EVCache，讓查詢規劃器跳過不必要的 S3 讀取。
壓縮完成後，熱儲存的對應 slice 就能截斷。最大的資料集上這個作業約跑 12 小時，Netflix 選擇用時間換較低的運算成本。查詢最多三次循序 S3 讀取即可取回一整天資料，p50 約 150 ms，p99 約 500 ms；撰文時全球冷層讀取量最高達每秒 1,250 次。
代價是串流本身很貴：它擴大了 on-call 範圍，也帶來資料傳輸費用。於是團隊問了個更激進的問題：既然 Cassandra 本來就把備份放在 S3，能不能直接讀那份備份？
第二代：直接讀備份
TimeSeries 以 Time Slice 為單位分表，一張表一旦越過冷層邊界就不再接受寫入，成為不可變。這是整個設計能成立的前提。
第一步是 ROCS。標準策略（LCS、TWCS）產生的 SSTable 在 token 空間會重疊，一次點查要碰多個檔案。ROCS 對不可變的表只重新壓縮一次，讓 SSTable 精確對齊 token 範圍。文中指出這也降低了所有儲存層的尾延遲。
第二步利用備份結構。每個節點的備份在 S3 上有 manifest 與 SSTable 元件。除了巨大的 Data.db，其餘 Index、Filter、Summary 等元件都能先下載到節點本機，佔用空間可忽略，查詢規劃在讀 S3 之前就完成。
第三步是 Cassandra 4.1 的 pluggable Memtable，把冷表的讀取導向備份：
CREATE TABLE data_20260616_00_04 (...)
WITH memtable = 'backupmemtable:timestamp=1781953200000'該 timestamp 表示備份保證涵蓋整張表、且表已不可變的時間點。
安全讀取的條件與資源隔離
切換前要確認兩件事，都用 Cassandra Virtual Tables 查：整個 ring 沒有進行中的壓縮（system_views.sstable_tasks），以及備份已完整上傳（complete_backups 的 uploaded=True）。TimeSeries 控制平面把 slice 越過邊界後的流程全部自動化，備份延遲或壓縮落後都不影響可用性。
初始化與讀取有幾項防護：
- S3 操作皆有指數退避重試，初始化跑在獨立執行緒池。
- 下載元件大小與 manifest 不符就刪掉重抓。
- 初始化中的讀取最多阻塞半個 read RPC timeout。
- 叢集設定上關閉 read repair 與 speculative retry，並使用較大的壓縮 chunk 以減少 S3 呼叫。
從 S3 讀資料比讀本機更吃 CPU，突發讀取可能拖累熱路徑。因此冷讀取可以選擇跑在獨立的 Cassandra 叢集，其 backup Memtable 指向熱叢集的備份。拓撲需一致，硬體不必，可以換成更小、更便宜的儲存輕量機型。
實際效果
| Kafka/Flink 冷層 | Cassandra 冷層 | |
|---|---|---|
| 資料路徑 | 另存一份 Parquet 到 S3 | 直接讀既有備份 |
| p99 讀取延遲 | 約 500 ms | 低於約 500 ms |
| p90 延遲 | 基準 | 改善約 30% |
對維運 TimeSeries 或類似 Cassandra 大叢集的團隊，可檢查的是：資料是否真的有明確的不可變邊界、備份是否已有完整 manifest，以及冷讀取要不要與熱叢集隔離。若是 Cassandra 4.1 之前的版本則缺少 pluggable Memtable。文中未公布 ROCS 或 backup Memtable 是否開源，也未給出成本節省的具體金額。