北京
Spotify 推出了 Random Access Parquet（RAP）。这是一种存储架构，可以直接对数据湖中的数据执行低延迟点查询，让在线服务和 AI 应用无需将数据集复制到操作型数据库，就能检索单条记录。RAP 在 Apache Parquet 文件之上增加了一个外部索引层，既能实现交互式查询，又能继续使用相同的数据集进行分析、机器学习和在线服务。 Spotify 解释称，现代数据湖已经成为分析和 AI 工作负载的中央存储库，但检索单条记录的效率依然很低，因为 Trino 和 BigQuery 等分布式查询引擎针对分析扫描进行了优化，而不是基于键的查询。尽管 Google Cloud Storage 等云对象存储现在能够提供毫秒级访问延迟，但查询规划、元数据遍历和文件发现仍会给点查询带来大量额外开销。Spotify 指出，它在 Bigtable 中存储了 PB 级在线数据，而在基于 Google Cloud Storage 的数据湖中存储了 EB 级数据，这使得向服务数据库大规模复制数据的成本越来越高。 RAP 通过引入外部索引来解决这一挑战。该索引将用户 ID 等查询键直接映射到 Parquet 文件及其行位置。查询无需扫描数千个文件，而是先通过索引解析键，再针对对象存储发起定向范围读取。随着新数据写入 Apache Iceberg 表，索引构建器会生成仅追加的索引片段，而无需修改不可变的 Parquet 文件。Spotify 表示，这种方法使相同的数据集能够同时支持分析处理、机器学习流水线、Notebook、AI 智能体和对延迟敏感的在线应用，而无需维护重复的存储系统。 Spotify 的这项发布是业界推动开放数据湖技术突破分析处理范畴的又一次尝试。Google Cloud 最近介绍了一种面向 AI 应用的基于 Apache Iceberg 的湖仓架构，同样试图在实现数据操作访问的同时减少数据重复。与该方法不同，RAP 引入了一个针对点查询优化的专用外部索引层，同时保持与现有 Parquet 文件和 Iceberg 表的兼容性。 该架构也在数据工程社区引发了讨论。Andrew Lamb 将 RAP 视为扩展开源数据格式以支持交互式工作负载的一个例子。在另一场 LinkedIn 讨论中，Vikas Singh 认为，云对象存储性能的提升，已经使点查询延迟更多地转移到查询规划和元数据访问上，而 RAP 正是通过预计算索引来减少这方面的延迟。 Spotify 还介绍了几项用于降低点查询延迟的存储布局优化措施，包括按查询键对数据排序以减少访问的文件数量、将相关记录组织在一起、交错排列值列以便通过一次连续读取获取多个属性，以及使用覆盖索引，使部分查询无需读取 Parquet 文件即可完成。Spotify 表示，这些技术以适度增加文件或索引大小为代价，减少了存储操作次数，使部分点查询只需对几 KB 数据执行一次范围读取即可完成。 Spotify 还支持二级索引，无需重写 Parquet 文件，即可跨买家 ID 或卖家 ID 等多个查询维度进行高效查询。基于哈希的索引支持精确查询，而排序索引则支持范围查询。Spotify 表示，二级索引在服务层进行管理，因此可以在不更改数据流水线的情况下增加新的访问路径，同时继续使用相同的 Parquet 数据集进行分析扫描和交互式点查询。Z 排序和希尔伯特曲线等存储布局技术，还可以进一步改善二级查询维度的数据局部性。 原文链接：https://www.infoq.com/news/2026/08/spotify-data-lake-point-queries/
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
