从模板创建Cloud Dataflow任务失败，错误提示：Workflow failed

我完全理解这种摸不着头脑的感觉——当任务悄无声息失败还没错误提示时，排查起来确实头疼。针对你遇到的Cloud Dataflow Wordcount模板任务无错误日志失败的情况，可以试试下面这些排查方向：

打开Cloud Console的Dataflow页面，定位到你提供的Job ID：2022-10-29_04_23_45-16586439030273551039，点进去查看两个关键标签：

• Job Graph：看看任务卡在了哪个步骤，是初始化阶段就失败，还是某个处理环节出了问题？
• Logs：别只看默认的日志级别，切换到WARNING或ERROR层级，有时候关键报错会被大量INFO日志淹没。另外，检查每个Worker节点的日志，可能底层的资源问题或权限问题只在Worker日志里体现。

• 参数验证：确认inputFile和output这两个核心参数是否正确：输入路径是不是有效的GCS路径？有没有读权限？输出路径是不是未被占用且有写权限？别漏掉gs://前缀这类细节。
• 资源调整：默认的Worker配置可能不足以处理你的数据量，试着调高Worker数量或者改用更大的机器类型（比如从n1-standard-1换成n1-standard-2）再跑一次，排除资源不足导致的静默失败。

运行Dataflow任务的服务账号需要足够的权限才能正常工作，比如：

• GCS的读写权限（至少Storage Object Admin角色）
• Dataflow API的调用权限（Dataflow Worker角色）
• 如果涉及其他服务（比如BigQuery），也要对应配置权限。权限不足时，任务可能不会抛出明确错误，只会悄悄终止。

去Cloud Logging页面，用Job ID作为过滤条件搜索：

resource.type="dataflow_step" AND labels.dataflow_job_id="2022-10-29_04_23_45-16586439030273551039"

这里能搜到所有和该Job相关的底层日志，包括Worker节点的系统级报错，大概率能找到任务失败的根源。

把Wordcount模板拉到本地，用Direct Runner运行测试，这样能快速区分是模板本身的问题还是云端环境的问题。本地测试命令示例：

mvn compile exec:java -Dexec.mainClass=org.apache.beam.examples.WordCount \
  -Dexec.args="--inputFile=./src/main/resources/*.txt --output=./output" \
  -Pdirect-runner

本地运行的日志会更详尽，能帮你快速定位参数或代码层面的问题。

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