如何增大Pyarrow Flight中FlightStreamReader的read_chunk()块大小？

首先明确核心逻辑：FlightStreamReader.read_chunk()返回的块大小，由服务端的推送分块规则 + 客户端的接收缓冲配置共同决定，不存在纯客户端侧直接强制拉取超大块的开关——read_chunk()本身只会按照服务端推送的单个Arrow RecordBatch的边界返回数据，不会自动跨批次合并内容，你当前遇到的单块固定3968行的情况，本质是对接的Dremio服务默认的推送批大小配置触发的。

可直接调整的配置方向 #

• 服务端侧调整（核心生效手段）
  Flight流的分块逻辑是服务端主导的，对接Dremio服务时，直接修改服务端的Flight批次大小配置参数arrow.flight.batch.size，将默认的千行级批大小调整到十万/百万行级别，重启服务后即可看到read_chunk()返回的单块行数显著提升。这是最直接、零额外性能损耗的调整方式。
• 客户端侧缓冲配置（辅助生效）
  构造DoGet请求的FlightCallOptions时，可主动调整客户端的批次读取缓冲上限，避免客户端默认缓冲过小导致服务端的整批数据被截断拆分：

  options = flight.FlightCallOptions()
  # 设置客户端单批次接收的最大缓冲上限，按网络带宽配置为几十MB级别即可
  options.set(flight.FlightCallOptions.READ_BATCH_SIZE_LIMIT, 64 * 1024 * 1024)
  reader = client.do_get(flight_info.endpoints[0].ticket, options)
  

  注意：如果服务端已经固定将数据拆为千行级的小块推送，仅调整客户端参数无法把多个小块合并为单个大chunk。

无服务端修改权限时的替代方案 #

如果无法调整服务端的批大小配置，可以在客户端侧自行做块累积逻辑，达到减少小粒度调用、提升吞吐量的目标：

• 循环调用read_chunk()获取小批次数据，累积到预设的行数/内存阈值后，通过pyarrow.concat()将多个小RecordBatch合并为目标大小的大块再做后续处理
• 这种方式不会改变底层的网络传输分块逻辑，但能大幅减少小粒度数据处理带来的开销，对大结果集场景的吞吐量提升效果和直接调整块大小基本一致。

内容的提问来源于stack exchange，提问作者user1179317