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億時間序列的吞吐量。