作者：林岚｜OC 开发者生态编辑

Spotify 工程团队提出 Random Access Parquet（RAP），用外部索引把用户 ID 等键直接映射到 Parquet 文件和行号，再通过精确的范围读取取得数据。目标是让同一份数据湖文件同时服务批量分析和低延迟点查询。

一句话结论：RAP 没有把 Parquet 变成数据库，而是提前计算“答案在哪个文件、哪一页”，绕过分布式 SQL 引擎的调度和逐层发现成本；它用额外索引和更讲究的数据布局，换掉第二份在线存储。

数据湖的存储本身已经不一定慢。Spotify 称，GCS 单次请求通常在 30 至 100 毫秒，新型对象存储甚至进入个位数毫秒。真正拖慢单条查询的是上层：Trino、BigQuery 等引擎要调度任务、规划查询，哪怕只找一行也可能花数秒。

传统 Parquet 读取还要形成依赖链：先取文件尾部，解析 row group，扫描键列找到行号，再通过页索引定位目标列。前一步没完成，后一步就不知道该读哪里。分区和 Bloom Filter 能减少候选文件，却不能消除文件内部的多轮读取。

RAP 的外部索引记录键、文件编号和行号。查询时先做 O(1) 索引查找，再用缓存的页位置发出少量可以并行的范围请求。索引按追加片段增长，不要求修改已有 Parquet；但代价也很直白，TB 级数据可能产生 GB 级索引，PB 级数据则可能需要 TB 级索引服务。

若只给旧文件建索引，系统仍可能为了 100 字节结果读取整个 4MB 页。Spotify 因此提出按键排序、每个键单独成页、在页内重置 ZSTD 帧、把常用列交错放置，甚至把小值直接提升进覆盖索引。这些优化会减少在线读取，却可能增加页索引体积，或削弱批量分析的列裁剪和压缩效率。

文章给出了完整设计，但没有公布生产延迟、吞吐和总成本对比，也没有把 RAP 描述成已经通用发布的产品。它更像一份架构提案：当在线访问集中在低频历史数据时，维护 Bigtable 或 DynamoDB 全量副本可能太贵，外部索引才有经济意义。

关键事实

• 核心方法：外部索引把查询键映射到具体 Parquet 文件和行号
• 读取方式：利用缓存元数据和对象存储范围请求，减少依赖式 I/O
• 存储收益：批量分析与在线查询可以复用同一份 Parquet 数据
• 主要代价：额外索引规模、索引一致性，以及针对点查询重排文件布局的分析性能权衡

OC 判断

先别急着把数据湖直接接到用户请求。RAP 适合历史跨度大、键查询明确、访问相对稀疏的场景；高频写入、强一致事务和复杂过滤仍然属于数据库。真正要测的是 P95/P99 延迟、索引更新滞后、对象存储请求费和故障恢复，而不是只看一次查询读了多少字节。

为什么重要

• 对开发者：Agent 检索长期个人数据时，不一定要把全部历史复制进昂贵的在线 KV 系统。
• 对数据团队：文件布局会同时影响批量扫描与点查询，需要明确哪一类负载优先。
• 对企业：省掉第二份数据副本，也会增加索引服务和一致性维护成本，账要一起算。

参考来源

• Spotify Engineering: Indexing the Data Lake for Online Point Queries
• Apache Parquet documentation
• Apache Iceberg partitioning specification