Dataproc升级后GCS限流日志及Class A操作成本飙升问题咨询

1. 是否需要修复「GoogleHadoopOutputStream: hflush(): No-op due to rate limit」日志？ #

不需要专门“修复”这条日志本身——它是Info级别的正常提示，说明GCS Hadoop客户端在触发hflush()时，因为达到了GCS的请求速率限制，自动跳过了这次flush操作（No-op），属于客户端的限流保护机制，不是错误或故障。

但这条日志是明确的信号：你的任务触发了GCS的请求限流，同时伴随Class A操作成本骤升，这背后的配置或行为变化需要调整，否则会持续推高成本，甚至可能在限流加剧时引发性能问题。

2. 是否会引发性能问题？ #

当前的Info日志阶段不会直接导致任务失败，但如果限流持续加剧：

• 客户端会不断重试请求，增加任务的整体延迟；
• 极端情况下，频繁的限流可能导致任务出现超时或失败；
• 更直接的影响是大量Class A操作（比如频繁的hflush）会大幅推高GCS的使用成本。

3. 升级Dataproc后出现问题的原因 #

Dataproc 2.2.29-debian12使用的是较新版本的GCS Connector（通常为2.2.x或更高），和2.0.x版本的Connector相比：

• 默认的fs.gs.outputstream.flush.mode等参数可能发生了变化，导致更频繁的hflush()调用；
• 新版本Connector的并发处理逻辑调整，可能增加了对GCS的请求频次，触发了GCS的速率限制。

4. 优化方案（解决成本骤升和限流问题） #

可以通过调整Spark和GCS Connector的配置来优化：

• 调整flush策略：将fs.gs.outputstream.flush.mode设置为NEVER或MANUAL，减少自动flush的频次，Spark提交时可添加参数：

  --conf spark.hadoop.fs.gs.outputstream.flush.mode=NEVER
  

• 减少小文件生成：通过spark.sql.files.maxRecordsPerFile或fs.gs.block.size参数增大输出文件块大小，降低GCS的请求次数；
• 启用批处理请求：开启fs.gs.batch.thread.count等批处理参数，合并多个请求为批量操作，减少Class A操作的数量；
• 控制并行度：调整Spark任务的并行度，避免过多并行任务同时向GCS写入，匹配GCS的速率限制。

内容的提问来源于stack exchange，提问作者Vikrant Singh Rana