在處理大規模即時分析系統時，工程師經常會遇到一個棘手的問題：儀表板（Dashboard）的滾動時間視窗。想像一個監控畫面，每分鐘更新一次過去三小時的錯誤率，雖然每次查詢的時間範圍只偏移了一分鐘，但對於傳統的快取系統來說，只要時間邊界稍微變動，這就被視為一個完全不同的請求。這導致系統必須重複掃描數兆筆資料，造成極大的計算浪費。
Netflix 為了優化其基於 Apache Druid（一個專為快速分析而設計的分散式資料儲存系統）的分析架構，開發了一套區間感知快取（Interval-Aware Caching）策略。這套機制讓他們能將 84% 的查詢結果直接從快取中提供，並將對 Druid 的查詢壓力降低了 33%。
傳統快取的失效痛點
在標準的快取機制中，快取的鍵值（Cache Key）通常是整個查詢語句的雜湊值。如果查詢是過去三小時的數據，而一分鐘後再次查詢，時間範圍發生了微小偏移，快取鍵就會完全改變，導致快取失效（Cache Miss）。在 Netflix 這種處理超過 10 兆行數據的規模下，這種重複計算會造成嚴重的效能瓶頸，導致 P90 延遲（代表 90% 的請求都能在該時間內完成）居高不下。
區間感知快取的運作邏輯
Netflix 的解決方案不再將整個查詢結果視為單一快取對象，而是將其分解為時間對齊的片段（Time-aligned Segments）。
具體做法是將時間軸切分成固定大小的桶子（Buckets）。例如，將數據按小時或十分鐘分段儲存中間聚合結果（Intermediate Aggregates）。當一個新的滾動視窗查詢進來時，系統會將其拆解為兩個部分：穩定的歷史區間與最新的變動區間。
對於那些已經過去且數據不再變動的歷史區間，系統直接從快取中提取預先計算好的片段；只有最靠近現在、尚未結算的最新區間才需要真正發送到 Apache Druid 進行計算。最後，系統將快取的歷史片段與剛計算出的最新結果合併，回傳給使用者。
架構實現與實務影響
為了達成這個目標，Netflix 引入了一個外部代理層（External Proxy）。這個代理層負責攔截所有進入 Druid 的查詢，將查詢的結構（例如：要計算什麼指標）與時間區間（例如：從什麼時候到什麼時候）分開處理，從而生成可重複利用的快取鍵。
在儲存策略上，他們採用了指數級的 TTL（Time To Live，快取有效期）政策。這意味著越久遠的歷史數據，其快取有效期越長，而越新的數據則更新頻率越高，從而在數據準確性與查詢效能之間取得平衡。
這套方案帶來了顯著的工程成效。除了提升快取命中率，某些工作負載下，傳回的結果位元組數減少了 14 倍，且大幅降低了對資料分段（Segment）的掃描次數，直接提升了 P90 查詢速度達 66%。
未來演進方向
目前的區間感知快取仍是以外部代理層的形式存在，這增加了一定的架構複雜度。Netflix 未來的優化方向包括支援更多儀表板工具使用的模板化 SQL 查詢，以及嘗試將此快取邏輯直接整合進 Apache Druid 的核心引擎中，以消除代理層並提升查詢規劃的效率。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。