Oodle 如何實現大規模可觀測性的高速查詢

在可觀測性領域，傳統資料庫架構往往將儲存與計算緊密耦合，導致為應對突發查詢而過度預留容量，成本高昂。Oodle 採用了一種不同的思路：將資料持久化到物件儲存（如 S3），並在需要時才啟動計算資源。這種設計聽起來簡單，但要在大規模負載下保持快速響應，需要對資料寫入、壓縮和查詢執行進行精細最佳化。

Oodle 的架構主要服務於指標資料，但同樣適用於日誌和追蹤。其核心原則包括：資料不可變性、近期資料對事故響應至關重要、查詢負載波動大、同一資料可能被反覆查詢。AI 的引入進一步加劇了這些需求：更多服務產生更多遙測資料，AI 輔助除錯工具會並行發起大量查詢，且模型生命週期要求更長的資料保留週期。傳統的內聚式架構無法在不過度配置的情況下應對這種增長。

指標資料的特殊性在於，它們通常以約30秒的間隔到達，但並非按時間序列順序寫入，而是以輪詢方式分散在大量序列中。這導致三個實際問題：不能依賴簡單的順序寫入、壓縮時需要拼接交錯片段、使用者期望在壓縮後臺進行時仍能快速查詢最新資料。

Oodle 的解決方案包括：

• 儲存與計算分離：物件儲存提供永續性和經濟性，無伺服器計算（AWS Lambda）處理突發查詢。
• 寫入（Ingestion）：透過 Prometheus Remote Write 或 OTLP 協議接收資料，批次寫入預寫日誌（WAL）物件到 S3。採用壓力重新整理策略避免熱點阻塞，早期分割槽減少後續合併工作。
• 壓縮（Compaction）：將無序的 WAL 資料轉換為讀取友好的檔案格式，包括合併去重、寫入索引檔案、清理舊物件。
• 近期資料快速通道（Blazer）：將最近的 WAL 資料快取到記憶體，提供快速查詢，直到壓縮完成。同時支援高可用副本。
• 查詢路徑：按資料鮮度分發查詢，常規負載使用專用計算，突發負載使用 Lambda 無伺服器工作節點。列式 PromQL 引擎與列式壓縮檔案配合，僅讀取所需列，減少資料掃描。
• 檔案格式最佳化：按指標名稱排序資料塊、尾後設資料支援定向讀取、壓縮後設資料字典編碼、列塊級跳過等減少不必要的資料解碼。

此外，Oodle 還注意避免序列 S3 呼叫，採用並行讀取和範圍讀取，並快取小後設資料以減少開銷。壓縮檔案大小控制在 128MB 左右，既便於並行化，又避免了巨大的單體檔案。資料和後設資料分離儲存，後設資料檔案小，可快速獲取。

最終，工程團隊體驗到了顯著改善：更少的儲存叢集維護、更好的保留經濟性、更好的突發查詢併發處理能力，以及更快的從資料採集到可用答案的路徑。Oodle 的設計目標是支援每小時超過10億時間序列的吞吐量。