企业服务集团企业

Spotify推出RAP存储架构优化数据湖查询效率，实现多场景数据复用

Spotify

PB 级

Bigtable中存储的在线数据规模

EB 级

基于Google Cloud Storage的数据湖存储数据规模

几 KB

部分点查询单次范围读取的数据量

项目背景

数据湖已成为分析和AI工作负载的中央存储库，但无法高效支持点查询需求，业界正在探索开放数据湖技术突破分析处理范畴、减少数据重复存储的方案。本案例依据「InfoQ 中文」公开发布的信息整理，原文：https://www.infoq.cn/article/iRjDa2ayZ9KLUtWylQZl?utm_source=rss&utm_medium=article

面临的痛点

现有数据湖针对分析扫描优化，单条记录检索效率低，查询规划、元数据遍历等环节会带来大量额外开销；企业存储的在线数据和数据湖数据体量庞大，跨系统大规模复制数据的成本持续升高；同一数据集需要维护多套重复存储系统才能满足不同工作负载需求，运维成本高。

优秘的方案

推出RAP存储架构，在Parquet文件之上新增针对点查询优化的专用外部索引层，同时配套多种存储布局优化措施及二级索引能力，保持与现有Parquet文件、Iceberg表的兼容性，无需复制数据即可支持多类工作负载共用同一数据集。

可以直接对数据湖中的数据执行低延迟点查询既能实现交互式查询，又能继续使用相同的数据集进行分析、机器学习和在线服务使相同的数据集能够同时支持分析处理、机器学习流水线、Notebook、AI 智能支持二级索引，无需重写 Parquet 文件，即可跨买家 ID 或卖家 ID 等

实施路径

在Apache Parquet文件之上增加外部索引层，将查询键直接映射到Parquet文件及其行位置，查询时先通过索引解析键再发起定向范围读取

新数据写入Apache Iceberg表时，索引构建器生成仅追加的索引片段，无需修改不可变的Parquet文件

采用按查询键排序数据、组织相关记录、交错排列值列、使用覆盖索引等存储布局优化措施降低点查询延迟

支持无需重写Parquet文件的二级索引，在服务层管理索引可灵活新增访问路径

采用Z排序、希尔伯特曲线等存储布局技术提升二级查询维度的数据局部性

落地成效