Apache Arrow C++：parquet::StreamWriter的高效替代方案及写入优化问询

我正在使用Apache Arrow C++编写程序，将自定义行式（"rownar"）二进制表格文件格式转换为Parquet格式。程序核心逻辑如下：

ColInfo colinfo = ...; // 每个文件的固定 schema，编译时未知
parquet::StreamWriter w = ...;

on_row(RowData row) {
  for (col : colinfo) {
    w << convertCell(row, col);
  }
}

其中，输入文件解析器每解析一行就会调用on_row函数。当前实现可正常运行，但性能较差，StreamWriter::<<是性能瓶颈。

问题：是否存在与StreamWriter使用方式类似但性能更高的替代方案？
约束条件：

1. 无法修改上述基于回调的接口；
2. 输入数据无法全部放入内存。

我已查阅Arrow仓库中使用WriteBatch接口的reader_writer{,2}.cc示例，这是否是快速创建Parquet文件的推荐方式？若是，行组大小的推荐设置方式是什么？是否存在类似StreamWriter那样抽象出行组的接口？WriteBatch的num_values推荐设置为多少？

次要问题：创建Parquet文件时有哪些可行的并发优化点？能否并发写入批次、块、列或行组？

核心问题解答 #

1. 替代StreamWriter的高性能方案 #

StreamWriter的逐单元格写入模式会带来频繁的序列化与IO开销，这是性能瓶颈的核心原因。在不修改on_row回调接口的前提下，最优方案是在回调内缓存多行数据，攒够一批后用WriteBatch批量写入，具体实现思路：

• 预先根据colinfo创建对应类型的Arrow数组构建器（arrow::ArrayBuilder）；
• 在on_row中，将每行的单元格数据追加到对应列的构建器中；
• 当缓存行数达到阈值（如1万~10万行），将所有构建器转换为arrow::RecordBatch，再通过parquet::arrow::WriteBatch写入Parquet文件；
• 写入后重置构建器，继续缓存下一批数据；
• 处理完所有行后，将剩余缓存数据作为最后一批写入。

该方案既保留原有回调接口，又通过批量操作大幅降低序列化与IO开销，性能比逐行写入提升数倍甚至一个数量级。

2. WriteBatch的使用建议 #

WriteBatch是Arrow官方推荐的高性能Parquet写入方式，完全适配批量场景：

• 行组大小设置：推荐按未压缩数据量设置为64MB~256MB。Parquet行组是最小并行处理单元，过大会增加内存占用，过小则导致元数据冗余与IO次数上升。可根据单行列数估算每行大小，再计算对应行数阈值（如每行1KB时，64MB对应65536行）。
• 行组抽象接口：parquet::arrow::FileWriter会自动管理行组——当写入的RecordBatch累计达到行组大小阈值时，自动触发行组写入与关闭。无需手动管理行组，只需控制每次写入的RecordBatch大小，逻辑抽象程度与StreamWriter接近。
• num_values参数：直接设置为当前RecordBatch的行数即可，RecordBatch已明确每行的列数据长度，无需额外调整。

并发优化点 #

Parquet写入的并发优化主要围绕行组级别展开，因行组间相互独立，可并行处理：

• 行组并行写入：将输入数据按行组拆分，每个行组在独立线程中完成RecordBatch构建与序列化，再将序列化后的行组字节流按顺序写入文件。注意：文件元数据需最后统一写入，需主线程协调行组写入顺序并完成收尾。
• 列级别并行构建：构建RecordBatch时，不同列的ArrayBuilder可由独立线程处理（如每行不同列分配给不同线程追加数据），但需注意ArrayBuilder非线程安全，每个列的构建器必须由单个线程操作。
• 避免直接并发写文件句柄：parquet::FileWriter非线程安全，不能多线程直接调用WriteBatch。正确做法是每个线程序列化出Parquet行组字节流，由主线程按序写入，或使用Arrow的AsyncFileWriter（若适用）。

额外优化：开启Parquet列级别压缩（如Snappy、GZIP），虽增加CPU开销，但大幅降低IO量，整体性能反而提升；同时确保使用Arrow Release版本并开启编译优化（O2/O3），这对序列化性能影响显著。

内容的提问来源于stack exchange，提问作者Jonas H.