Apache Beam Dataflow写入GCS Avro文件时抛出OutOfMemoryException

该OOM异常不是Dataflow Runner下Apache Beam IO库的已知缺陷，属于典型的配置误用引发的内存过载。

• 配置逻辑冲突：使用FileIO.writeDynamic()实现动态分桶写入时，配置的.withNumShards(10)作用范围是单个分桶，而非全局总分片数。本次任务预期输出800个Avro文件，对应800个独立分桶（每个Evaluation id为一个分桶key），每个分桶会独立创建临时写入流、初始化GCS上传连接。
• 内存超限逻辑：GCS Java SDK默认给每个可续传上传连接分配8MB的块缓存，800个并发上传连接仅缓存块就需要占用至少6.4GB堆内存。n2-standard-4实例给Worker JVM分配的堆内存通常为4~6GB，直接触发堆空间溢出。该逻辑和堆转储观测到的内存主要被stream/byte[]对象占用、报错栈指向MediaHttpUploader.buildContentChunk方法的特征完全匹配。
• 资源浪费放大问题：本次任务单Avro文件大小仅50KB，远小于默认8MB的上传块大小，预分配的大块缓存几乎没有被实际使用，进一步挤占了可用堆空间。

按优先级选择以下任意一种方案即可解决问题：

• 移除代码中全局的.withNumShards(shards)配置：动态分桶场景无需指定全局固定分片数，交由Beam根据每个分桶的实际数据量自动适配分片策略，从根源上避免无意义的连接和缓存创建。
• 调低GCS上传缓存规格：在Pipeline启动参数中添加--GcsUploadBufferSizeBytes=1048576，将单连接上传块缓存从默认8MB下调为1MB，调整后800个连接的总缓存占用仅800MB左右，完全适配n2-standard-4的内存规格。
• 关闭小文件可续传上传：由于单文件体积远小于GCS单次上传的大小上限，可在启动参数中添加--GcsResumableUploadChunkSize=0，小文件直接走单次上传逻辑，不会预分配大块上传缓存。

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