为在线点查询索引数据湖
内容提要
Spotify等公司需快速访问海量数据，但传统SQL引擎延迟高。RAP（随机访问Parquet）通过外部索引将键直接映射到文件位置，实现O(1)查找，避免扫描。它支持排序、分组、单页键、ZSTD帧重置等优化，减少读取次数和字节数，甚至可零读取。RAP复用现有Parquet文件，无需复制，使数据湖支持交互式查询，降低在线服务成本，惠及AI代理等场景。
延伸解读
核心优势：免复制与低成本
RAP 的最大卖点在于直接复用数据湖中已有的 Parquet 文件，无需复制或转换数据，避免了额外的存储成本和 ETL 流程。这使得原本因成本高昂而无法放入 KV 存储的历史数据、长尾实体等，也能以交互式速度访问，改变了在线服务的数据经济性。
适用场景与限制
RAP 特别适合需要按主键进行高频点查询的场景，如用户行为查询、AI 代理上下文检索。但它的优化依赖于对 Parquet 文件的特定预处理（如排序、分组、单页键等），且部分优化会牺牲批量分析的性能（如列裁剪、谓词下推）。因此，并非所有数据都适合采用 RAP，需权衡在线查询与离线分析的利弊。
与现有技术的区别
与 Parquet 内置的 PageIndex 或 Bloom filter 不同，RAP 的外部索引是确定性的，直接映射键到精确的文件和行号，彻底消除扫描。而 PageIndex 和 Bloom filter 只是概率性过滤，仍需扫描候选文件。RAP 的 O(1) 查找和并行读取显著降低了延迟，尤其适合云存储环境。
Q&A
RAP是什么？它如何解决数据湖中的点查询延迟问题？
RAP（Random Access Parquet）是一种通过外部索引实现数据湖中快速点查询的技术。它将键直接映射到文件位置，实现O(1)查找，避免扫描整个文件，从而将查询延迟从秒级降低到毫秒级。
RAP与Parquet内置的PageIndex或Bloom过滤器有何不同？
Parquet内置的PageIndex和Bloom过滤器是概率性的，用于缩小扫描范围，而RAP的外部索引是确定性的，直接返回键对应的精确文件和行号，完全消除扫描。
RAP如何减少点查询的读取次数和字节数？
RAP通过多种优化减少读取：排序和哈希分桶集中数据，单页键和ZSTD帧重置减少读取的字节数，列交错和Blob存储减少读取次数，覆盖索引甚至可以实现零读取。
RAP支持哪些数据布局优化？它们分别有什么权衡？
RAP支持排序、哈希分桶、共分组、更粗粒度分区、单页键、ZSTD帧重置、存储对齐、Blob/变体列、列交错和覆盖索引等优化。权衡包括：单页键可能增加PageIndex大小，ZSTD帧重置需要PLAIN编码，列交错增加单列扫描的I/O，覆盖索引增加索引大小。
RAP如何处理多维度查询（如按买家ID和卖家ID查询）？
RAP支持为同一数据集构建多个访问结构（如哈希表和排序索引），每个维度一个。添加或删除二级索引只需在服务层操作，无需修改数据或管道。
RAP如何降低在线服务的数据存储成本？
RAP允许直接使用数据湖中的Parquet文件，无需复制到KV存储，从而避免额外的存储费用。这使得历史数据、长尾实体等也能以低成本提供交互式访问。
RAP对AI代理有什么帮助？
RAP使AI代理能够快速检索用户的历史数据（如去年夏天的收听记录），无需将数据预加载到KV存储，从而可以处理更广泛的数据集，构建更丰富的上下文。
