Spotify 推出 Random Access Parquet（RAP） 存储架构，在 Parquet 文件之上增加外部索引层，让数据湖直接支持低延迟点查询——在线服务和 AI 应用无需再将数据复制到操作型数据库，即可检索单条记录。
现代数据湖已成为分析和 AI 工作负载的中央存储库。但检索单条记录这件事，一直是个麻烦。
Trino 和 BigQuery 等分布式查询引擎针对分析扫描优化，而非基于键的查询。尽管 Google Cloud Storage 等云对象存储已能提供毫秒级访问延迟，但查询规划、元数据遍历和文件发现仍会给点查询带来大量额外开销。
Spotify 的规模让这个问题更加尖锐。
向服务数据库大规模复制数据的成本越来越高。RAP 正是为打破这种复制困境而生。
注：PB 与 EB 为 Spotify 公开披露的存储量级，代表在线数据库与数据湖的规模差异，而非全部 RAP 管理数据。
RAP 的核心思路：在 Apache Parquet 文件之上增加一个外部索引层。索引将用户 ID 等查询键直接映射到 Parquet 文件及其行位置。
查询无需扫描数千个文件，而是先通过索引解析键，再针对对象存储发起定向范围读取。随着新数据写入 Apache Iceberg 表，索引构建器生成仅追加的索引片段，不修改不可变的 Parquet 文件。
数据湖→ETL搬运→操作型数据库→在线服务。两套存储，数据重复，同步成本高。
数据湖（Parquet + 外部索引）→ 分析与在线服务共用同一数据集，零搬运。
这意味着相同的数据集能够同时支持分析处理、机器学习流水线、Notebook、AI 智能体和对延迟敏感的在线应用，无需维护重复的存储系统。
注：对比卡仅展示存储架构层面的核心差异，实际部署中 RAP 仍需服务层管理索引生命周期。
RAP 的工作流程可以拆解为四个阶段：
与扫描数千个文件的传统路径相比，RAP 将查询路径压缩为索引查找 + 一次定向读取。配合存储布局优化，部分点查询只需对几 KB 数据执行一次范围读取即可完成。
但是，索引不是免费的。
这些技术以适度增加文件或索引大小为代价，减少存储操作次数。这是一种存储空间与查询延迟之间的工程权衡。
注：链路图简化了实际执行中的缓存命中、索引合并等中间步骤，仅展示核心数据路径。
Spotify 的发布是业界推动开放数据湖技术突破分析处理范畴的又一次尝试。Google Cloud 最近也介绍了面向 AI 应用的基于 Apache Iceberg 的湖仓架构，试图在实现数据操作访问的同时减少数据重复。
但 RAP 走了一条不同的路。
与 Google Cloud 的方法不同，RAP 引入了一个针对点查询优化的专用外部索引层，同时保持与现有 Parquet 文件和 Iceberg 表的兼容性。
在社区讨论中，Andrew Lamb 将 RAP 视为扩展开源数据格式以支持交互式工作负载的一个例子。Vikas Singh 则指出，云对象存储性能的提升已使点查询延迟更多地转移到查询规划和元数据访问上，而 RAP 正是通过预计算索引来减少这方面的延迟。
注：标签云按技术路线分类，非严格时间线；各方案仍在演进中，边界可能模糊。
RAP 的本质不是发明了一种新的存储格式，而是在不动数据的前提下，给数据湖加了一副「索引眼镜」——让原本只能做批处理的存储层，获得了点查能力。
这种思路的代价是诚实的：索引需要构建和维护，文件大小会膨胀，存储布局优化意味着压缩率与查询速度的权衡。它并非银弹，而是针对特定查询模式的工程优化。
当 AI 智能体需要从海量数据中精准检索单条记录时，「分析存储」与「服务存储」的边界正在消失——数据湖不再只是数据的终点，而是正在成为所有应用的统一入口。