Hotdry.
归档
systems

Rust 零拷贝流式 Parquet 解析器：受 Hardwood 启发构建

借鉴 Java Hardwood 的多线程页面解码设计，在 Rust 中实现零拷贝流式 Parquet 解析器，优化大数据管道性能，提供工程参数和监控要点。

在大数据生态中，Apache Parquet 作为列式存储格式已成为数据湖和分析管道的核心。近期发布的 Hardwood 解析器以其最小依赖和高性能著称，尤其通过页面级并行解码和自适应预取机制，利用多核 CPU 显著提升了解析吞吐量。该项目虽基于 Java 21，但其设计理念 —— 零分配、多线程页面处理 —— 非常适合移植到 Rust 中，以实现真正的零拷贝流式解析。本文将聚焦于在 Rust 中构建类似解析器，强调零拷贝 IO、流式处理和兼容性优化，适用于 Spark、Trino 等大管道场景。

Parquet 格式解析挑战与 Hardwood 启发

Parquet 文件结构包括魔数头部、行组（Row Groups）、列块（Column Chunks）和数据页（Pages），尾部以 Thrift 编码的元数据（Footer）结束。传统解析器如 Apache Arrow 的 Rust parquet crate 已优化元数据解析，速度提升 3-9 倍，但仍需缓冲整个行组到 Arrow 数组，无法实现端到端零拷贝流式输出，尤其在处理 TB 级文件时内存压力大。

Hardwood 的关键创新在于页面级并行：不按行组或列块分发任务，而是将单个页面的解码工作扇出到多线程，同时自适应预取慢速列（如字典编码字符串）的页面，确保所有列同步推进。“Hardwood 通过页面级并行和自适应预取，在 M3 Max 16 核机上将 NYC Taxi 数据集（9.2 GB）列求和时间缩短至 1.2 秒。” 这一机制避免了单线程瓶颈，并最小化内存使用。

在 Rust 中，我们可借鉴此法，利用 memmap2 实现文件零拷贝映射，结合 rayon 线程池实现页面并行。Rust 的借用检查确保引用安全，避免 Java 中的 GC 暂停。

核心实现架构

  1. 零拷贝 IO 与元数据解析
    使用 memmap2 映射整个文件（或流式扩展到分块映射），直接从 mmap 切片读取 Footer。复用 Arrow 的自定义 Thrift 解析器（thrift_struct! 宏），跳过无关字段，仅提取 schema、row_groups 和 column_chunks 元数据。
    示例代码框架：

    use memmap2::Mmap;
use rayon::prelude::*;
let mmap = unsafe { Mmap::map(&file)? };
let footer_len = u32::from_le_bytes(mmap[mmap.len()-8..].try_into()?) as usize;
let metadata = parse_thrift_footer(&mmap[mmap.len() - 8 - footer_len..mmap.len() - 8])?;

  2. 流式行组迭代与页面并行解码
    对于每个 Row Group，按 Column Chunk 定位偏移。针对每个 Chunk 的 Pages，使用线程池并行解码：

    • 预取下一页到 ring buffer（大小 16MB，对齐 64B）。
    • 解码逻辑：字典 / RLE/ Delta 等编码按 Thrift 规范实现，输出借用 mmap 的 &[u8] 或解压后 arena 分配的缓冲（仅复杂页）。
    • 自适应预取：监控每个列的解码速率（ns / 页），慢列多分配线程（e.g., 线程权重 = baseline * 1.5）。
      Rayon 线程池配置：ThreadPoolBuilder::new().num_threads(num_cpus::get() - 1).build()?。

  3. 零拷贝输出接口
    设计 StreamingColumnReader trait，返回 BorrowedArray<'a>（lifetimes 绑定 mmap）：

    pub trait StreamingColumnReader<'a> {
    fn next_batch(&mut self, batch_size: usize) -> Option<Result<&'a [u8], Error>>;
}

    对于压缩页，使用 snappy/zstd 等 crate 解压到临时 Vec，但复用 arena 池最小化 alloc。

工程化参数与优化清单

为 big data 管道落地，提供可调参数：

参数 推荐值 说明
thread_pool_size num_cpus - 1 留一核给 IO
page_prefetch_depth 4 预取页数，平衡内存与延迟
batch_size 1MB 解码批次，避免小对象
arena_chunk_size 64MB 解压缓冲池块大小
thrift_skip_threshold 100 cols 列数超阈值跳过统计
  • 监控要点：集成 tracing 和 pprof。记录指标：pages/sec、prefetch_miss_rate（目标 <5%）、alloc_total_bytes。回滚策略：若解码错误率>1%，fallback 到 Arrow parquet。
  • 兼容性测试：使用 parquet-testing/data1 生成的 100+ 测试文件，覆盖嵌套 schema、所有编码（PLAIN, DELTA 等）和压缩（SNAPPY, ZSTD）。确保 100% 通过 Apache 规范。
  • 性能基准：在 32 核 AWS c7i.24xlarge 上，对 S3 9GB NYC Taxi，目标 >10GB/s 吞吐（vs Arrow 5GB/s）。

潜在风险与缓解

零拷贝下，解压 / 解码仍需 alloc（~10-20% 开销），复杂嵌套 schema（如 Overture Maps）借用失效风险高。缓解：渐进实现，先平坦 schema，后扩展；使用 bumpalo arena 管理短期借用。

构建步骤清单：

  1. Cargo.toml: memmap2, rayon, snap, zstd, bytemuck (zero-copy transmute)。
  2. 实现 Thrift parser（fork Arrow）。
  3. PageDecoder trait，按编码 dispatch。
  4. 集成 tokio for async S3（object_store）。
  5. CI: GitHub Actions + parquet-testing。

此解析器可无缝集成 DataFusion 或 Polars，提升管道 2x 性能。未来扩展：predicate pushdown（统计过滤行组）和 Iceberg 元数据支持。

资料来源：

查看归档