在現代的大數據架構中，數據湖（Data Lake）已成為儲存分析工作負載與 AI 訓練數據的核心倉庫。然而，數據湖在設計之初就是為了處理大規模的掃描分析，而非快速檢索單一紀錄。Spotify 在其技術分享中指出，雖然雲端物件儲存（如 Google Cloud Storage）的存取延遲已降低至毫秒等級，但在實際執行點查詢（Point Query，指根據特定鍵值如用戶 ID 檢索單一紀錄）時，查詢規劃、元數據遍歷以及檔案發現過程仍會產生巨大的額外開銷。
對於 Spotify 而言，這造成了嚴重的儲存冗餘問題。為了滿足線上服務對低延遲的需求，他們必須將大量數據從數據湖複製到像 Bigtable 這樣的運營資料庫中。當數據量達到 Exabyte 等級時，這種大規模的數據複製不僅成本高昂，且增加了維護數據一致性的複雜度。為了打破分析型儲存與運營型儲存的隔閡，Spotify 開發了一套名為 Random Access Parquet (RAP) 的儲存架構，旨在讓線上服務能直接從數據湖中高效地獲取單一紀錄。
RAP 的核心機制在於為 Apache Parquet 檔案建立一個外部索引層（External Indexing Layer）。Apache Parquet 是一種列式儲存格式，非常適合分析掃描，但極不適合隨機存取。RAP 透過這個外部索引，將查詢鍵（Lookup Key）直接映射到特定的 Parquet 檔案及其內部的行位置（Row Location）。當系統收到查詢請求時，不再需要透過分佈式查詢引擎（如 Trino 或 BigQuery）去掃描數千個檔案，而是先透過索引定位，隨後直接對物件儲存發起一次精準的範圍讀取（Ranged Read）。
為了確保系統的靈活性與效能，RAP 在實作上採取了幾項關鍵設計。首先，它與 Apache Iceberg 深度整合，Iceberg 是一種開放的表格式，能管理大規模數據集的快照與演進。當新數據寫入 Iceberg 表格時，索引構建器會生成僅限追加（Append-only）的索引片段，而不需要修改原本不可變（Immutable）的 Parquet 檔案，這保證了寫入效能與數據完整性。其次，RAP 支援二級索引（Secondary Indexes），允許開發者針對不同的維度（例如買家 ID 或賣家 ID）建立索引，而無需重寫原始數據。其中，基於雜湊（Hash-based）的索引用於精確匹配，而排序索引（Sorted Indexes）則支援範圍查詢。
除了索引層，Spotify 還對儲存佈局（Storage Layout）進行了深度優化，以進一步壓低延遲。他們採用將數據按查詢鍵排序的策略，減少存取檔案的數量；同時利用交錯值列（Interleaving Value Columns）技術，將多個相關屬性放置在連續的儲存空間中，使得一次少量的範圍讀取（僅數 KB）就能獲取多個欄位的值。此外，他們還引入了覆蓋索引（Covering Indexes），讓部分查詢在不需要讀取原始 Parquet 檔案的情況下就能直接由索引返回結果。針對多維度查詢，則採用 Z-ordering 或 Hilbert curves 等空間填充曲線技術來提升數據的局部性（Data Locality）。
RAP 的實務意義在於它實現了「單一數據源，多種存取模式」。同一套數據集現在可以同時支援大規模的分析處理（Analytical Processing）、機器學習管線、AI 代理（AI Agents）以及對延遲極其敏感的線上應用。這消除了在運營資料庫與數據湖之間同步數據的必要，顯著降低了基礎設施的成本與維運壓力。
然而，這種架構也存在一定的權衡。為了換取極低的讀取延遲，RAP 必須接受索引檔案大小的適度增加，以及在數據寫入時增加索引構建的額外步驟。儘管如此，隨著雲端物件儲存性能的提升，瓶頸已從物理讀取移轉至元數據處理與查詢規劃，而 RAP 正是針對這一痛點而設計的解決方案。這標誌著開放數據湖技術正從單純的分析工具，演進為能夠支持互動式、低延遲運營工作負載的通用數據層。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。