Dataflow BigQuery读写pipeline小数据正常但大作业运行失败

• NLP处理环节的数据倾斜与长尾卡顿是根本诱因：日志中反复出现的单操作耗时超400秒的堆栈直接指向自定义函数get_company_sentences，本质是数据分布不均——长文本记录的处理耗时是普通短文本的几十上百倍，单条记录长期占用Worker计算核心不释放，最终出现整体处理进度不升反降的现象（计数下降是因为失败的工作项被系统回收重跑，并非实际处理量减少）。
• BigQuery写入链路配置不当是直接故障点：报错日志最终中断在GroupShardedRows/Write环节，结合Worker的401权限刷新日志判断，当前默认写入模式下生成的分片文件体积过小，会触发大量小文件合并、加载请求，叠加权限token刷新的重试开销，最终触发写入链路超时失败。
• 常见认知误区澄清：
  • 不存在“BigQuery直连链路不可用”的问题：手动将中间结果输出到GCS文件再导入BigQuery属于冗余绕路，不会带来性能提升
  • 并非纯内存资源不足：当前使用的n1-highmem-6机型单节点具备6GB内存，子集测试可稳定跑通，说明基础内存配置满足要求，全量作业失败是数据倾斜与链路配置不当叠加导致的，并非单纯堆砌内存就能解决

• 解决NLP环节的长尾卡顿
  • 在自定义ParDo的process逻辑中增加前置校验：对full_text字段长度设置阈值，超过模型可处理上限的文本直接截断，避免单条超长文本占用Worker计算资源数十秒甚至数分钟
  • 调整Dataflow扩缩容配置：关闭固定250个Worker的硬编码配置，设置弹性扩缩容范围（最小50、最大500），将默认1分钟的缩容判定间隔调整为3分钟，避免系统误判Worker长时间无输出为节点闲置，引发无意义的资源抢占
  • 对识别到的长文本记录，给分配的处理key加0-9的随机数前缀做打散，避免同批次长文本被调度到同一个Worker节点形成热点
• 优化BigQuery写入配置
  • 调整WriteToBigQuery的参数配置：开启with_batched_input=True，将单分片文件的目标大小设置为1GB以上，减少小文件触发的合并、加载请求数量，从根源上解决GroupShardedRows/Write环节的超时问题
  • 校验服务账号权限：确认运行Dataflow的服务账号已绑定BigQuery读写、GCS临时目录读写的对应权限，避免token过期后无权限写入引发的重试循环
• 优化BigQuery读取性能
  • 给ReadFromBigQuery添加method="DIRECT_READ"参数，替代默认的临时表导出模式，减少数据传输阶段的临时文件生成开销，明显降低启动阶段的传输等待时间

• 查看失败作业的WorkerCPU监控，如果出现单节点CPU长期100%、其余节点CPU使用率低于20%的情况，即可确认是NLP环节的数据倾斜问题
• 查看写入阶段的GCS临时目录，如果发现大量几十KB的细碎小文件，即可确认是写入分片配置不当的问题

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