GCP Dataflow运行Wordcount示例作业长期卡在0%进度问题咨询

无全局已知的Dataflow服务端缺陷会导致官方Wordcount示例无法正常跑完，作业提交后长时间停在0%进度基本都是本地启动参数或者云侧资源配置错误导致，结合你贴的启动命令，优先按以下顺序排查：

• 第一优先级修正参数拼写错误：你当前命令里写的临时路径参数是--tmp_location，不管是Python还是Go版的Apache Beam SDK，识别的合法参数名是--temp_location，少写一个e会导致作业提交后无法正确读取临时文件、拉取worker启动依赖，全程卡在初始化阶段没有任何进度推进。
• 排查自定义子网连通性：你指定了--subnetwork参数使用自定义子网，首先确认对应子网已经开启Private Google Access，否则worker节点无法访问GCP公共服务端点拉取系统镜像、读取公共样例数据桶、上报作业状态；其次确认子网所在VPC的防火墙规则没有拦截worker节点之间的内部通信，也没有拦截worker访问GCP服务的443出站流量；另外还要确认子网剩余可用IP数量足够分配Dataflow worker节点，IP耗尽也会导致worker一直拉不起来。
• 排查自定义服务账号权限：你指定了--service_account_email使用自定义服务账号，该账号至少需要绑定以下角色才能正常跑作业：
  • Dataflow Worker 角色
  • Storage Object Viewer 角色（用于读取dataflow-samples公共桶里的莎士比亚样例文本）
  • Storage Object Creator 角色（用于往你指定的输出桶、临时桶写入文件）
• 查作业日志定位具体报错：进入GCP控制台对应Dataflow作业的日志面板，筛选worker启动阶段的ERROR级日志，能直接定位到具体失败原因，常见的报错包括服务账号没有子网使用权限、GCS桶的访问被拒绝、SDK版本和服务端不兼容等。

快速验证方法：可以先去掉--subnetwork和--service_account_email两个参数，用默认VPC、默认Compute Engine服务账号提交一次作业，如果能正常跑通，就说明问题100%出在自定义网络或者服务账号的配置上，和Dataflow服务本身无关。

修正参数拼写后的参考启动命令如下：

python -m apache_beam.examples.wordcount \
  --input gs://dataflow-samples/shakespeare/kinglear.txt \
  --output <output_bucket> \
  --runner DataflowRunner \
  --project <project_id> \
  --region us-west1 \
  --temp_location <gcp_tmp_bucket> \
  --service_account_email=<service_account> \
  --subnetwork=<subnetwork_path>

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