中间层方案：实现PB级数据湖Parquet文件查询千倍加速

Meet in the Middle for a 1,000x Performance Boost QueryingParquet Files on Petabyte-Scale Data Lakes 目录 摘要 02 1.简介03 2.核心工作负载与设计目标 05 数据模式查询模式挑战系统设计目标 3.通过分布式缓存降低基线延迟07 4.通过下推提升点查询延迟表现10 下推机制的革新实践中间层计算下推的基本原则 1013 5.低延迟存储方案的成本对比 14 6.相关工作 缓存数据与元数据存算一体计算引擎下推优化161616 7.结论及下一步工作 参考文献18 摘要 在 AWS S3 等云对象存储上以 Parquet 格式存储数据已成为主流选择，不仅能用于大规模数据湖场景，还可作为轻量级特征库支撑训练推理，或充当检索增强生成（RAG）的文档存储。然而，直接从 S3 查询 PB 级至 EB 级数据湖仍然存在严重的性能瓶颈，查询延迟通常高达数百毫秒至数秒。 本文介绍如何利用 Alluxio 在超大规模数据湖上构建高性能缓存加速层，实现对Parquet 文件的查询优化。无需专用硬件、无需修改数据格式或访问对象的URL路径、无需迁移数据，Alluxio 即可实现与 AWS S3 Express One Zone 相当的亚毫秒级首字节响应时间（TTFB）。此外，其吞吐量可随集群规模线性扩展，中型部署（约 50 节点）即可实现每秒 100 万次查询，达到单账户 S3 Express 吞吐量的50 倍，且无延迟劣化。 除了高效支撑 Parquet 文件的字节级访问外，Alluxio 还通过可插拔接口分担查询引擎的部分 Parquet 读取操作，显著降低文件解析与索引查询开销，实现超低延迟的直接点查：单线程即可达到每秒 3,000 次查询、延迟低至数百微秒，相较传统方案实现高达 1,000 倍的性能提升。 1.简介 如今，数据驱动型组织在云对象存储上直接存储和查询 Parquet 文件的做法已极为普遍，原因主要有： 高效的结构化数据访问：以 Parquet 等列式格式存储结构化数据，可显著加速分析型查询，使 Parquet 成为 OLAP 工作负载中数据湖的默认格式。可扩展且具成本效益的存储：云对象存储（尤其是 AWS S3）因其低成本、高可靠性、高持久性及可支持 TB 至 EB 级数据规模的能力，已成为数据湖的首选存储后端。这类存储擅长提供高吞吐量，非常适合大规模分析等吞吐敏感型任务。 然而，新兴的延迟敏感型AI应用正在挑战直接从云对象存储查询 Parquet 文件的传统范式。特别是检索增强生成（RAG） 和 AI 特征库工作负载，这两类场景通常要求亚毫秒级检索。而标准S3 服务并非为这种低延迟访问设计，尽管 S3 Express等高级解决方案能提供毫秒级延迟，但其成本是标准 S3 的 5 倍，并对每个账户的吞吐量有严格限制，使其难以用于大规模部署。 常见的应对方案之一是将数据缓存到计算引擎附近。许多数据湖查询引擎（如Trino 和 Presto）采用内部缓存，通过本地存储资源减少重复的数据拉取。但是，这类方案有着天然的局限性：其扩展仅限于本地存储容量，且难以跨应用共享（参见Speed Up Presto at Uber with Alluxio Local Cache和Trino and AlluxioDocumentation）。 于是，我们推荐使用 Alluxio，将其作为弥补延迟缺口的高性能中间层。Alluxio位于计算与存储之间，在设计上找到了延迟、可扩展性和成本之间的最佳平衡点。更重要的是，Alluxio 作为缓存层，可灵活地将谓词下推等操作卸载到更靠近热数据的位置执行，而非作用于整个数据湖。 通过架构协同设计、系统工程和针对特定工作负载的优化，Alluxio 展示了在云场景下针对关键的延迟敏感型工作负载，相较直接在 AWS S3 上查询 Parquet 文件，可实现超过 1,000 倍的性能提升。Alluxio 带来的提升包括： 单节点优化：单个 Alluxio Worker 实例通过其 S3 API 提供亚毫秒级 TTFB 延迟，相较标准 S3 实现 100 倍提速，并与 S3 Express 性能持平。可扩展分布层：Alluxio 支持横向扩展，能高效处理 PB 级数据集，且不增加延迟。计算卸载：通过选择性地将部分 Parquet 操作从查询引擎卸载到 Alluxio执行，探索如何高效地分发计算任务以及需要配备哪些接口，将端到端的点查询性能再提升 100 倍。 2.核心工作负载与设计目标 本节重点阐述核心工作负载：以亚毫秒级延迟对大规模、分区化的Parquet 文件执行点查询（point lookup）。 数据模式 目标表以 Parquet 文件的形式存储在 AWS S3 中，按照唯一的 id 列进行分区和排序。为减少网络延迟，查询客户端在同一个 AWS 区域内运行。这类数据集通常包含结构化记录，如用户或产品元数据，其中 id 通常指代用户或产品的标识符。 查询模式 主要关注的查询模式是：SELECT id, data FROM table WHERE id = 123通过结合排序主键（primary key） 与 Parquet 的行组（row group）和页级（page-level）统计信息，可有效跳过无关数据。 挑战 虽然此类查询看起来很简单，但要在云对象存储上实现低延迟查询还面临着诸多挑战： 虽然 S3 具有极高的可扩展性，但在 PB 级数据集上进行查询通常会带来较高的延迟，首字节的平均获取时间就高达数百毫秒。执行这样的查找操作还涉及对 Parquet 文件/数据集的多次往返请求，总耗时往往达到数秒。 基于内存的解决方案（如 Redis）可以提供远低于 S3 的延迟，但在 PB 级规模下成本极高，并且需要显式地加载数据，带来运维上的负担。此外，数据加载本身也是计算密集型的，涉及从 Parquet 这样的长期存储格式中读取数据，并将其以键值对的形式写入 Redis 缓存。即 使 使 用 S3 Express 这 类 服 务 ， 在 处 理 小 对 象 时 可 以 实 现 亚 毫 秒 级 的GetObject 延迟，但要将端到端查询延迟压缩到 1 毫秒以内，仍需要进行系统级和架构上的精细优化。此外，虽然 S3 Express 提供了极佳的延迟表现，但其费用是标准 S3 的 5 倍，并且还对每个账户的吞吐量设有上限。 系统设计目标 Alluxio 的设计目标是同时满足四个关键要求：低延迟、高吞吐量、高可靠性和低成本。虽然现有系统可单独满足其中某些要求，但很少有系统能同时实现全部。 1.低延迟：通过谓词下推、投影下推、零拷贝数据传输、单 RPC 执行路径和元数据缓存，实现亚毫秒级的平均查询延迟。2.高吞吐量：随着计算和存储节点的横向扩展，支持每秒超过一百万次查询的可扩展查询吞吐能力。3.高可靠性：在故障情况下确保数据可用性和容错能力，目标是实现与 S3 服务等级协议（SLA）相当的可用性。4.低成本：最大限度地减少内存和计算开销。作为参照，S3 Express One Zone的费用为每月每 TiB 160美元，而标准 S3 仅为 23 美元。Alluxio 可在不修改数据格式或应用逻辑的前提下提供高性能，避免高昂的数据格式转换和应用修改成本。 为了实现这些目标，Alluxio 采用了以下优化措施： 主动缓存数据并进行零拷贝传输：通过将数据与计算部署在同一位置来减少传输时间，并且避免跨 S3 区域访问数据时产生流量成本。谓词下推和投影下推：在数据传输之前进行过滤，节省网络带宽并缩短端到端的查询时间。单 RPC 执行路径：将多个请求步骤合并为单个 RPC，大幅降低往返延迟。元数据缓存：将 Parquet 元数据的最优表示形式缓存在 Alluxio worker 节点内存中，避免重复读取和解析，从而加速查找过程。 3.通过分布式缓存降低基线延迟 实现亚毫秒级查询延迟的第一步是消除每次访问 S3 上 Parquet 文件时产生的高昂网络往返（耗时数十毫秒到数百毫秒）。但是，要支持 PB 级的Parquet 数据集访问意味着一项重大挑战：将所有数据保存在内存中（例如通过 Redis），不仅成本高昂且无法扩展。 为此，我们设计了如图1所示的 Alluxio 智能缓存架构，将高价值数据透明分层缓存至本地 NVMe 固态硬盘，同时底层仍依托 S3 存储。该架构完美融合了两大优势： 对高频访问数据：发挥快速本地存储的低延迟特性对完整数据集：保留云对象存储的弹性扩展能力、耐久性和成本效益 图 1 Alluxio 架构：客户端使用一致性哈希（consistent hashing）基于文件路径确定负责的 Alluxio worker 节点。选定的节点负责处理查询，如果有缓存数据则直接访问，否则通过 GetObject 从底层对象存储（例如 S3）获取数据。 如图 1 所示，Alluxio 将 Parquet 文件切分为按 4MB 对齐的页面，支持细粒度的子文件级缓存。该设计能显著减少存储占用和数据传输时间，让Parquet footers和热点列组等高访问频率的数据更靠近计算节点。 每个 Alluxio worker 会基于 LRU（最近最少使用）缓存策略自动将最热点的数据保存在本地，同时对冷数据无缝回退到 S3。缺失数据按需获取并通过后台异步缓存，在获得本地存储级性能的同时，仍完整保留云对象存储的弹性扩展能力和成本优势。 为了提供稳定的低延迟性能，Alluxio 在客户端使用一致性哈希进行数据分片和请求路由。客户端能够精确计算出数据所在的 Alluxio worker 节点，而非集中式元数据查询及额外跳转。集群成员变更通过 etcd 动态管理，构建完全分布式、无状态且高弹性的架构，完美适配现代云环境。 Alluxio 能够跨 worker 节点集群并行预加载PB级数据集，实现吞吐量最大化与就绪时间最小化。通过完全兼容 S3 的 API 接口，Alluxio 可直接接入现有应用体系,无需修改数据格式或查询逻辑。 为了进一步降低延迟，Alluxio worker 集成了多项系统级优化： 异步事件循环：每个 Alluxio worker 都基于高性能的异步 I/O 框架构建， 通过非阻塞 I/O，最大限度地减少了上下文切换和线程争用，而这两者正是传统阻塞式 I/O 系统中延迟的主要原因。其事件驱动模型使得单个 worker 实例可以扩展到数千个并发连接，同时保持亚毫秒级的响应速度。 基于 NVMe 的堆外页存储 ：Alluxio 利用 NVMe SSD 在堆外存储缓存页面。这一设计大大提高了存储密度，同时不会占用过多内存资源，在成本与访问延迟之间实现了良好平衡。 零拷贝 I/O ：Alluxio 采用基于 sendfile() 和 mmap() 的零拷贝 I/O 技术，避免不必要的内存拷贝，有效降低 CPU 负载。该技术使缓存数据页能够直接从NVMe 固态硬盘读取，并通过网络协议栈传输，无需经过用户空间的数据拷贝，从而提升系统吞吐量并降低访问延迟。 通过这些优化措施，Alluxio 可弥合AWS S3 可扩展性与现代数据密集型应用低延迟需求之间的性能鸿沟。单个基于 NVMe 的 Alluxio worker 实例的延迟可与 S3Express 相媲美，相比标准S3 快达100 倍。单个 Alluxio worker 实例的吞吐量接近 S3 Express 每个账户的上限，并能通过增加节点实现线性扩展。 4.通过下推提升点查询延迟表现 Parquet 格式 [4] 具有内置索引和丰富的元数据，支持快速SELECT 查询。在高选择 性 查 询 中 ， 谓 词 下 推 （ predicate pushdown ） 和