Spotify为数据湖构建外部索引实现低延迟点查询

Spotify推出了随机访问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表示，这种方法使得相同的数据集能够支持分析处理、机器学习管道、笔记本、AI代理和延迟敏感的在线应用，而无需维护重复的存储系统。

Spotify的发布是在将开放数据湖技术扩展到分析处理之外的更广泛努力之后进行的。Google Cloud最近描述了一种基于Apache Iceberg的湖仓架构，用于AI应用，同样寻求减少数据复制，同时支持对数据的操作访问。与那种方法不同，RAP引入了一个专门为点查找优化的外部索引层，同时保持与现有Parquet文件和Iceberg表的兼容性。

该架构也在数据工程社区内引发了讨论。Andrew Lamb强调RAP是扩展开放数据格式以支持交互式工作负载的一个例子。在另一场LinkedIn讨论中，Vikas Singh认为，云对象存储性能的改进已将点查询相关的更多延迟转移到查询规划和元数据访问上，而RAP正是通过预计算索引来减少这一领域的延迟。

Spotify还介绍了多种存储布局优化，以减少点查询延迟。这些优化包括按查找键对数据进行排序以减少访问的文件数、将相关记录分组在一起、交错值列以便通过单次连续读取检索多个属性，以及使用覆盖索引，这样无需读取Parquet文件即可满足某些查询。根据Spotify的说法，这些技术以文件或索引大小适度增加为代价，减少存储操作次数，使某些点查询能够通过仅几KB的单次范围读取来服务。

交错值列布局可以从多个列中检索相关值（来源：Spotify博客文章)

Spotify还支持二级索引，无需重写Parquet文件即可跨多个查找维度（如买家ID或卖家ID）高效查询。基于哈希的索引支持精确查找，而有序索引支持范围查询。Spotify表示，二级索引在服务层管理，允许在不更改数据管道的情况下添加新的访问路径，同时继续使用相同的Parquet数据集进行分析扫描和交互式点查询。诸如Z排序和Hilbert曲线之类的存储布局技术可以进一步改善二级查找维度的数据局部性。