Netflix AI Team Cuts Wide-Partition Read Latency from Seconds to Milliseconds by Splitting Cassandra Partitions Per ID

Netflix 工程團隊近日發表了一套動態分區機制，成功將 Apache Cassandra 中寬分區（wide partition）的讀取延遲從數秒大幅降至個位數毫秒等級。這套方法專為 Netflix 自家的 TimeSeries Abstraction 平台設計，該平台負責處理 PB 等級的時間序列事件資料，每日需以毫秒級延遲進行寫入與查詢。團隊選擇 Cassandra 作為底層儲存引擎，看重的是其吞吐量、延遲表現、成本效益以及營運成熟度；然而時間序列資料依照標識符與時間範圍分群，容易隨著事件累積而產生體積過大的「寬分區」，成為效能瓶頸。 在一般情況下，Cassandra 多數分區的讀取延遲可維持在個位數毫秒，但當分區過寬時，尾端延遲（tail latency）會突然飆升至數秒鐘，甚至引發讀取逾時。更嚴重的是，極端案例會造成叢集出現垃圾回收暫停、CPU 使用率飆高以及執行緒排隊現象，加上 TimeSeries 伺服器本身承受極高的讀取吞吐量，問題被進一步放大。雖然直接擴充 Cassandra 叢集可以緩解症狀，但 Netflix 團隊傾向於尋找更聰明的自動化解決方案，而非單純以硬體堆疊應對。 TimeSeries 平台將資料集拆分成離散的時間區塊：時間切片（Time Slice）、時間桶（time bucket）與事件桶（event bucket），讓團隊可以按時間進行查詢與刪除，同時避免產生墓碑（tombstone）記錄。建立資料集（namespace）時，使用者需預估工作負載特性，接著佈建管線會透過蒙地卡羅模擬選出基礎設施與分區配置。這種事前規劃在三種情況下會力有未逮：專案初期無法準確預測工作負載；工作負載隨著流量與產品需求而變化；以及少數標識符（ID）接收遠多於平均的事件量——即資料離群值。時間切片提供了一條天然的逃脫路徑，因為每個新時間切片都可採用不同的分區策略，但人工調整數千個資料集顯然不可行，自動化勢在必行。 為此 Netflix 提出第一套解決方案：Time Slice 重新分區（Time Slice Re-Partitioning）。團隊利用 Cassandra 內建的 `nodetool tablehistograms` 等自省 API 取得分區大小的百分位數，背景工作者監控這些數據並透過虛擬表暴露出來；當分區大小偏離設定的密度目標（通常設定在 2 MiB 至 10 MiB 之間）時，便計算調整因子。舉例來說，若最初佈建時選擇 60 秒的時間桶，導致每個分區僅 10 KB，反而造成過度分區與讀取放大，工作者便會將未來時間切片策略更新為更大的時間桶間隔（例如從 60 秒改為 604800 秒）。這麼做成功降低了因執行緒排隊導致的讀取延遲與逾時。然而此方案僅在整個資料表多數分區都需要調整時才有效，無法處理僅有少數 ID 異常寬大的情況。 對於那些僅部分 ID 過寬的場景，團隊提供三種選項：第一是「不處理」，適用於整體指標未受影響時；第二是「部分回傳」，當請求已違反延遲 SLO 時中斷處理，回傳已收集的數據；第三是「封鎖 ID」，針對測試或垃圾 ID 採用的極端手段，透過設定檔直接列出違規 ID。但這些選項對合法且重要的寬 ID 並無幫助，因為呼叫端仍然需要所有事件。於是第二套解決方案應運而生：按 ID 的動態分區（Dynamic Partitioning per ID）。 動態分區是一條非同步管線，運作在單一 TimeSeries ID 的粒度，而非整個資料表。它分為三個階段：偵測、規劃與拆分、以及讀取服務。偵測階段發生在讀取路徑上：每次讀取都會追蹤該分區讀取的字節數，當超過設定門檻時，伺服器便向 Kafka 發送一筆事件，內容包含時間切片名稱、TimeSeries ID、時間桶與事件桶編號，並標記該分區是否為不可變（immutable）。團隊選擇在讀取路徑而非寫入路徑偵測，因為多數資料永遠不需要拆分；當然，部分寬分區仍會持續慢速讀取數秒，直到管線趕上進度。初始實作優先鎖定不可變分區以降低複雜度。 規劃階段會完整讀取該分區一次，計算精確的拆分計畫，並支援檢查點（checkpoint）讓失敗的規劃讀取能從最後儲存點復原。拆分狀態、檢查點與路由資訊都存放在 `wide_row` 元數據表中。實際拆分交由策略如 `EventBucketPartitionSplitStrategy` 執行：將更多事件桶分配到同一個時間桶中，若分區極寬則設事件桶上限以控制讀取放大。驗證階段透過比對拆分前後的校驗和來確保資料正確性，只有兩者一致時拆分狀態才會標記為 COMPLETED。團隊還會追蹤拆分前後的分區大小以確認拆分配置得宜。 讀取路徑則仰賴 Bloom 過濾器與元數據路由。TimeSeries 伺服器定期將已完成拆分的分區主鍵載入記憶體內 Bloom 過濾器，每次讀取先檢查過濾器，回應時間僅需個位數微秒，對呼叫端幾乎無感。若過濾器命中，伺服器再讀取 `wide_row` 元數據（背後有 read-through 快取）取得路由資訊，接著由既有的 PartitionReader 從較小的子分區服務讀取，最後合併結果回傳。原始寬分區永遠不會被刪除，因此即使部分失敗或遭遇最終一致性問題，仍可作為安全備援。此外 Netflix 也透過 Data Bridge Spark 任務在離線驗證拆分正確性，並採用分階段推出，歷經影子模式的比較階段（同時執行新舊讀取路徑，比對位元組數）來累積信心。 總結兩套方案的差異：時間切片重新分區作用於資料表/時間切片層級，由背景工作者根據分區直方圖觸發，影響僅限於未來的時間切片，核心機制是調整時間桶間隔與密度目標；而按 ID 動態分區作用於個別 TimeSeries ID 層級，由讀取路徑上的字節計數觸發，針對既有的不可變寬分區，核心機制是拆分成子事件桶分區。 Netflix 團隊的實際測試顯示，動態分區導入後，讀取延遲從原本的數秒改善至低雙位數毫秒，尾端延遲降至約 200 毫秒；即使是超過 500 MB 的極寬分區也能維持可用，不再造成系統不穩。這項發布不僅突顯 Netflix 在大型分散式系統上持續創新的能力，也為使用 Apache Cassandra 處理時間序列資料的團隊提供一個可參考的自動化拆分策略，證明在儲存引擎層級之上加入智慧路由層，能夠在不變動應用程式的前提下顯著提升效能。