Netflix AI團隊透過按ID拆分Cassandra分割槽，將寬分割槽讀取延遲從秒級降至毫秒級

Netflix工程團隊釋出了一種處理Apache Cassandra中寬分割槽的方法。該研究工作針對Netflix的TimeSeries Abstraction，這是一個用於時間事件資料的平臺。

TimeSeries Abstraction以毫秒級延遲攝入和查詢PB級的時間事件資料，底層使用Apache Cassandra 4.x。時序資料按識別符號和時間範圍組織成分割槽，隨著事件累積，分割槽可能變得“寬”。動態重新分割槽將過大的分割槽非同步地拆分為較小的子分割槽，應用程式繼續查詢相同的邏輯分割槽，而儲存佈局透明地演變。

對於大多數資料集，平均讀取延遲保持在個位數毫秒。但當分割槽過寬時，尾部讀取延遲上升到秒級，可能導致讀取超時、垃圾回收暫停、高CPU利用率和執行緒排隊。TimeSeries伺服器還處理非常高的讀取吞吐量，使問題更加複雜。Netflix團隊希望找到比單純擴充套件叢集更智慧的解決方案。

TimeSeries將資料集分解為離散的時間塊：時間切片、時間桶和事件桶。當建立名稱空間時，使用者指定預期的工作負載特徵，供應管道執行蒙特卡洛模擬來選擇基礎設施和分割槽配置。這種方法在三種情況下不足：工作負載未知或估計不準確；工作負載隨時間和需求變化；存在資料異常值（少數ID收到更多事件）。離散時間切片為前兩種情況提供了自然解決方案，但手動調整數千個資料集不可持續。

解決方案1：時間切片重新分割槽。Cassandra提供nodetool tablehistograms等內省API。後臺工作執行緒監視這些直方圖，並在分割槽大小偏離目標密度時計算調整因子。該密度通常設定為2 MiB到10 MiB。例如，如果過度分割槽導致高讀取放大，工作執行緒會更新未來時間切片採用更寬的間隔。這減少了讀取延遲和超時，但僅在大多數表需要重新分割槽時有效。

解決方案2：按ID動態分割槽。這是一個非同步管道，按TimeSeries ID拆分寬分割槽。分為三個階段：檢測、規劃和拆分、讀取服務。檢測在讀取路徑上進行：每次讀取跟蹤分割槽的位元組數，當超過閾值時，伺服器向Kafka傳送事件。優先拆分不可變分割槽。規劃階段讀取整個分割槽以計算準確拆分計劃，支援檢查點。拆分子任務使用事件桶分割槽策略，將更多事件桶分配到同一時間桶。驗證透過比較拆分前後的校驗和進行，僅當匹配時拆分才算完成。

讀取路徑使用布隆過濾器（微秒級響應）檢查已拆分的分割槽鍵，命中時查詢路由後設資料，將請求路由到較小的子分割槽。原始寬分割槽永不刪除，作為安全回退。Netflix還透過Data Bridge Spark作業進行離線驗證。分階段推出，包括影子比較模式。

兩種解決方案的比較：粒度、觸發條件、影響範圍、核心機制、檢測訊號、最佳適用場景等均有不同。用例包括長期使用者活動日誌、裝置遙測、過度供應的新資料集和延遲敏感儀表板。

結果：平均讀取延遲從秒級降至低雙位數毫秒，尾部延遲從幾秒降至約200毫秒，讀取超時減少，CPU利用率降低，叢集更穩定。對於500MB以上的極端寬行，服務仍能分頁查詢並保持可用。未來工作包括拆分可變寬分割槽和重新處理失敗的拆分。