Netflix 架構演進：從 Casspactor 到現代化 Cassandra 數據搬移引擎

原始來源與檔名：2026-05-21T093502+0800-The Evolution of Cassandra Data Movement at Netflix.md

NAPKIN | 餐巾紙

餐巾紙公式

Legacy System (Fragile Metadata + Intermediate Tables) → Modern Stack (Direct S3 Reads + Spark DataFrames + Connector Factory) = Massive Cost Savings & Reliability

公式說明：Netflix 的 Cassandra 到 Iceberg 數據搬移系統原本依賴脆弱的多服務複合視圖與耗費資源的中介表。新架構直接從 S3 備份讀取數據，轉換為標準的 Spark DataFrames，並引入了「連接器工廠 (Connector Factory)」模式，從而在降低數百萬美元成本的同時，解決了資料傾斜與 OOM 問題。

一句話

Netflix 每天需要將 3 PB 的資料從 Cassandra 搬運到 Iceberg。這篇文章揭露了他們如何汰除舊有龐雜的 Casspactor 系統，改為直接從 S3 備份讀取資料並利用 Spark 進行分散式壓縮。更精彩的是他們的「無感遷移策略 (Zero-impact Migration)」：利用 Maestro 工作流引擎建立抽象層，讓新舊系統平行運作，實現了對下游業務團隊完全透明的底層大換血。

餐巾紙草圖

[ Legacy: Casspactor ]
Cassandra Backup -> Metadata Service A + B + C -> Casspactor -> Intermediate Iceberg Table -> Final Iceberg
(Fragile, OOM on wide partitions, expensive storage)

[ Modern: Move Data Framework ]
S3 Backup Files (Single Source of Truth) -> Spark DataFrame (Executors handle compaction) -> Final Iceberg
+ Connector Factory (Allows Key-Value, Time Series to build custom logic)
(Resilient, Handles Skew, Zero intermediary tables)

ROUND 1: SKELETON | 骨架掃描

「這篇文章在說什麼」

• 核心問題: Netflix 依賴 Cassandra 處理核心業務，並需要將資料 (每日約 3 PB) 搬移到 Iceberg 進行分析。舊的搬移引擎 Casspactor 面臨嚴重的架構瓶頸：脆弱的元數據依賴、無法處理大型分區傾斜 (OOM)、缺乏資料模型感知、以及產生昂貴的中介表。
• 核心答案: Netflix 開發了全新的分層架構。底層直接從 S3 讀取備份資料生成 Spark DataFrames，消除了中介表與多重微服務依賴；上層提供「連接器工廠」，讓不同資料抽象 (如 KV, Time Series) 能自訂處理邏輯。並透過嚴謹的「驗證、可視化、安全」三支柱策略完成無痛遷移。
• 論證結構: 介紹背景 -> 點出舊系統 Casspactor 的致命傷 (元數據拼裝、單體設計) -> 提出新架構 (直接讀 S3, Spark DataFrame, 自動擴縮, 時間旅行) -> 詳細闡述大型重構的遷移策略 (Validation, Visibility, Safety) -> 總結與未來展望。

章節骨架

1. 背景: Cassandra 是 Netflix 核心。資料搬移本質上是利用 Cassandra 的 S3 備份基礎設施。
2. 舊引擎的極限 (Casspactor):
   • 元數據依賴脆弱 (多個系統拼湊，容易失去同步)。
   • 繼承限制：分區傾斜導致 OOM、無資料模型感知、中介表導致儲存膨脹。
3. 新堆疊 (分層架構):
   • 基礎層直接讀 S3 產出 Spark DataFrames。
   • 處理層利用 Spark Executor 解決 OOM，不寫中介表。
   • 提供連接器工廠模式，支援資料抽象自訂。
4. 遷移策略三支柱:
   • Pillar 1 驗證 (Validation): 平行執行 (Shadow testing)，數學級保證新舊輸出列完全一致 (C=M)。
   • Pillar 2 可視化 (Visibility): 儀表板、依賴追蹤與主動警報。
   • Pillar 3 安全 (Safety): 利用 Maestro 工作流實現 Decider Pattern (決策者模式)，抽象化遷移過程，失敗時自動退回舊系統。

ROUND 2: DISSECTION | 血肉解剖

「憑什麼這麼說」

論證鏈

龐大的歷史系統會隨著業務成長 (如 KV、Time Series 抽象的出現) 而不堪負荷，成為單點瓶頸 (Monolithic bottleneck) --> 解決方案不是在舊系統上打補丁，而是重新思考資料流。將「真實來源 (Source of Truth)」下放至 S3 物理備份層，將「運算 (Compaction)」交給分散式的 Spark 框架，將「業務邏輯」透過 Connector Factory 釋放給各業務端 --> 在執行高風險替換時，必須保證下游的合約不變 (Like-for-Like)。透過在控制平面 (Control Plane) 引入 Decider Pattern，可以在不修改使用者工作流的情況下，動態路由流量並提供 Fallback，實現零感知的架構升級。

關鍵證據

1. S3 作為 Single Source of Truth: 舊系統依賴外部服務來確認「備份是否存在與完整」，這違反了分散式系統的簡單性原則。新系統直接從 S3 檔案讀取元數據，這消除了一整條容易失效的依賴鏈，並賦予了系統「時間旅行 (Time Travel)」的能力 (Schema 與資料可作為整體被回溯)。
2. Spark Executor 的降維打擊: Cassandra 常見的痛點是 Wide Partitions (寬分區)。舊系統容易 OOM。新系統將壓實 (Compaction) 作業移至 Spark Executor 層級，利用 Spark 強大的記憶體與溢寫磁碟管理能力，優雅解決了資料傾斜問題。
3. Decider Pattern 的保護網: Netflix 使用 Maestro 工作流平台。使用者看到的 Job 沒變，但底層被注入了一個 Decider 節點。如果新系統 (Move Data) 發生錯誤，它會立刻自動執行舊系統 (Casspactor)。這保證了使用者永遠能拿到資料，只是偶爾會慢一點。

隱形假設與邊界

• 隱形假設:
  • 團隊擁有強大的資料平台基礎設施 (如 Maestro 工作流引擎與高度客製化的 Spark 環境) 來支撐這種級別的抽象與切換。
• 邊界條件:
  • 這種「無感遷移」的代價是極高的「雙重運算成本 (Shadow Testing)」。在遷移驗證期間，Netflix 必須為了同一份資料同時跑兩套系統，這需要雄厚的算力資本支持。

ROUND 3: SOUL | 靈魂提取

「還能怎麼用」

• 知識連接: 本文提到的「Decider Pattern (決策者模式)」與《I cut my AI agent’s token bill 87% in 7 days》中提到的「Model Routing (模型路由)」本質上是同一種架構思維：在抽象層動態決定執行引擎，並提供降級 (Fallback) 機制。 此外，將元數據從獨立系統收斂至 S3 實體檔案的做法，也呼應了軟體工程中「消除狀態碎片」的核心原則。
• 行動觸發: 當你面對一個祖傳的、龐大的、充滿 if-else 的單體資料處理系統時，不要試圖原地重構。學習 Netflix：1. 建立一個新的分層引擎；2. 寫一個 Router (Decider) 夾在中間；3. 開啟 Shadow Mode 讓兩邊產生的資料進行差異比對 (Diff)；4. 只有當差異為 0 時，才偷偷把舊系統拔掉。

平台工程的最高境界：無感遷移 (Architectural Deep Dive)

前言

Netflix Tech Blog 的這篇文章是一份大師級的「大型分散式系統重構與遷移指南」。它不僅展示了如何用現代化的大數據堆疊 (Spark + Iceberg + S3) 解決 Cassandra 的痛點，更示範了平台工程 (Platform Engineering) 的核心價值：替業務團隊吸收掉所有的底層複雜度。

核心架構洞察

1. 解構單體 (Deconstructing the Monolith) 的正確姿勢

舊的 Casspactor 是一個大雜燴，它同時負責了「尋找備份」、「解析 Cassandra 格式」、「處理不同資料抽象邏輯」與「寫入 Iceberg」。 Netflix 的新架構是一次完美的 SoC (Separation of Concerns，關注點分離)：

• 底層 (Storage/Retrieve)：只依賴 S3，把 S3 當作唯一的 Source of Truth。
• 引擎層 (Compute)：只負責把原始位元組轉成通用的 Spark DataFrame，解決記憶體與擴縮容問題。
• 邏輯層 (Connector Factory)：開放 API，讓 KV 團隊、Time Series 團隊自己寫 UDF 去轉換他們特有的資料模型。 這種分層讓引擎團隊專注於效能，業務團隊專注於邏輯，消除了單點瓶頸。

2. 數學級別的驗證 (C = M)

在重構資料管線時，最怕的就是「默默搞壞了資料，一個月後才被財報團隊發現」。

• Netflix 的做法非常暴力且有效：並排跑 (Shadow Run)。
• 定義集合 C (Casspactor 的輸出) 和集合 M (Move Data 的輸出)。
• 只要 C - M (漏資料) 或 M - C (多資料) 大於 0，就報警處理。 這種做法將「系統是否正確」從一種模糊的感覺，變成了一個絕對的數學證明題。

3. Decider Pattern (決策者模式) 與動態路由

這是我認為全篇最精彩的架構設計。如何在飛行中更換飛機引擎？

• 在使用者呼叫與底層執行器之間，插入一個 Control Plane (控制平面)。
• 這個 Decider 會根據規則（例如：這個 Table 是否已經被驗證過？現在是灰度發布的第幾批？）來決定把流量派給新引擎還是舊引擎。
• 更關鍵的是容錯路由 (Fault-tolerant Routing)：如果新引擎拋出 Exception，Decider 攔截它，並把同樣的參數丟給舊引擎重跑一次。使用者端只會感覺到「這次轉檔比較久」，但絕對不會拿到失敗的結果。

總結

這是一篇所有後端工程師、SRE 與資料工程師都該熟讀的案例。它告訴我們：好的架構不僅僅是跑得快、省成本，好的架構必須具備「可遷移性 (Migratability)」。 能夠在不驚動任何使用者的情況下，完成 3 PB 級別核心系統的替換，這才是頂級工程實力的展現。