你问一个 AI 助手：“我去年夏天在听什么？”它真正要做的，不只是理解这句话，还得迅速翻出你的收听记录。可这些记录往往躺在数据湖里。数据湖（Data Lake）以文件形式低成本保存海量数据，适合跑报表、训练模型和批量分析，却不擅长只找某一个人的几行记录。
这就是 Spotify 想解决的问题：让擅长“大批量搬货”的数据湖，也能承担在线点查。点查询（Point Query）是按用户 ID 等键取回少量记录，产品通常要求它很快返回。Spotify Engineering 提出的 Random Access Parquet（RAP），核心不是让查询引擎跑得更快，而是给 Parquet 文件加一份外部索引，直接告诉系统数据在哪里。
本文数据与效果判断均来自 Spotify Engineering，尚无独立信源交叉验证。
慢的未必是硬盘
据 Spotify 称，其在线用例有 PB（拍字节）级数据放在 Bigtable，而 GCS 数据湖已有 EB（艾字节）级数据。把全部湖中数据复制进专门服务在线请求的键值数据库，经济上并不轻松。
问题也不完全出在云存储。Spotify 给出的数字是：GCS 单次请求延迟约为 30—100 毫秒，S3 Express One Zone 和 GCS Rapid Storage 可到个位数毫秒。不过这些数字没有附测试条件，不宜直接横向比较。
真正碍事的是上层查询方式。Trino、BigQuery 这类分布式 SQL 引擎面向分析任务：它们擅长让许多机器一起扫描大量数据，追求的是吞吐量——单位时间处理多少数据。可在线产品更在意延迟，也就是这一次请求要等多久。Spotify 称，即使只查一行，任务调度和查询规划也可能带来秒级开销。
从九万份文件里找一行
Spotify 用一个假设场景解释困难：夏天按约 90 天计算，每天产生 1,000 个 Parquet 文件，就有 90,000 个候选文件。逐个打开一点看看，对在线请求来说仍然太慢、太贵。这些数字是机制示例，不是生产环境测量。
常见做法可以先缩小范围。系统按 key 把每天的数据分进 1,000 个 bucket，也就是按键划分的小桶。只看文件名，就能排除绝大多数文件，候选集合从 90,000 个降到 90 个。
随后，Bloom filter（布隆过滤器）可以继续判断“某个用户肯定不在这份文件中”。Spotify 的示例假设把它缓存到 metadata store（保存文件结构等信息的元数据存储）里，再将约 90 份候选文件缩到用户真正活跃的日期；文中的 12 天仍只是举例。
但文件筛完，系统还得在每份大文件内部找数据。传统路径像连续问路：先读文件尾部，再解析 row group（Parquet 内部的一组行）信息，然后扫描 key 列定位行，最后通过列索引和页索引找到其他字段所在的数据页。后一问依赖前一问的答案，云存储每次往返都会累加等待时间。
RAP 把连续问路改成查目录
RAP 的关键，是预先建立外部索引。索引就像书后的关键词目录：输入用户 ID，系统直接得到它出现在哪些文件、哪些行，而不必扫描文件寻找线索。
索引命中后，读取器利用缓存的文件元数据，把行号换算成数据页位置，再发起 range read——只读取对象中指定字节区间的请求。多个读取请求还能并行发出，不再形成“一步结束才能开始下一步”的依赖链。
Spotify 将索引查找描述为 ：简单说，查找步骤不会随着数据总量线性增长。索引是 multimap（一个键可以对应多处位置），因为同一用户的记录可能散落在多个日期和文件里。每条索引可记录 key、文件、行号，以及用于分页的可选记录数量。
它也不同于 Parquet 自带的 PageIndex 或 Bloom filter。后两者主要用于排除不可能的位置，仍是在缩小扫描范围；RAP 的外部索引则给出确切文件与行号，目标是直接取消扫描。
为什么值得关注
RAP 可以面向已有 Parquet 文件建立索引，不要求先改写数据。索引构建器读取文件尾部和数据页位置，扫描 key 列，再写出“键到位置”的映射。新数据到达后，流水线追加新的索引片段，而不是修改旧索引。
这使同一批 Parquet 文件仍可供机器学习流水线、notebook（交互式分析笔记本）、实验平台和批量分析使用，同时增加在线读取路径。它有望减少为了在线服务再维护一整份数据副本的需要。Spotify 给出的经验量级是：为 TB 级数据建索引会产生 GB 级索引，为 PB 级数据建索引则会产生 TB 级索引；大型索引可按哈希分桶分散存放。
说白了，这不是免费午餐，而是一种架构交换：保留数据湖的低成本批量存储，再用额外索引、元数据缓存和精确读取，换取更接近在线服务需要的响应方式。它特别值得关注，是因为 AI Agent 若要替用户查询历史数据，也需要同一种能力：先快速取回个人记录，再过滤、汇总，或在本地运行 SQL，为大模型准备上下文。
局限与未知
- 现有材料在读取未修改文件的数据页处截断，没有给出 RAP 的端到端延迟、吞吐量或成本，也无法核验实际降延迟幅度。
- Spotify 没有披露生产部署范围，也没有提供与 Bigtable、传统查询引擎或其他方案的完整基准测试。
- RAP 仍需外部索引、metadata store、计算资源和运维投入。“只存一次、只付一次”的说法带有概括性，不能理解为系统只有一项存储成本。