BigQuery作业统计中waitMsAvg指标的具体含义及影响因素咨询

你提供的BigQuery作业执行阶段性能指标片段如下：

...
          "waitRatioAvg": 0.12868179138919197,
          "waitMsAvg": "205214",
          "waitRatioMax": 0.13476867702572207,
          "waitMsMax": "214921",
          "readRatioAvg": 0,
          "readMsAvg": "0",
          "readRatioMax": 0,
          "readMsMax": "0",
          "computeRatioAvg": 0.005780879641822491,
          "computeMsAvg": "9219",
          "computeRatioMax": 0.021879428621593488,
          "computeMsMax": "34892",
          "writeRatioAvg": 0.000007524737574777079,
          "writeMsAvg": "12",
          "writeRatioMax": 0.00023326686481808947,
          "writeMsMax": "372",
...

针对你的疑问，解答如下：

调度对象说明 #

官方描述中等待调度的对象是当前查询执行阶段拆分生成的计算分片（shard），它是BigQuery并行执行逻辑的最小调度单元，每个分片需要绑定一个可用计算slot后才会进入实际执行环节。

waitMsAvg偏高的原因 #

你观察到的waitMsAvg远高于其他阶段耗时的情况，确实代表该查询阶段启动时可用计算slot不足：

• 调度器需要排队等待其他正在运行的查询释放slot资源，才能为当前阶段的分片分配执行资源
• 如果使用的是按需计费模式，也可能是同一时间触发的并发查询总占用slot超过了账号默认的并发配额，触发了排队等待

释放空闲slot的优化效果 #

优化其他查询、释放空闲slot的操作确实会降低waitMsAvg数值：

• 减少同资源池内其他查询的slot占用、关闭非必要的并发查询，都可以让当前查询的分片更快获取到调度资源
• 如果长期出现该指标偏高的情况，也可以通过扩容预留slot资源池、申请提升按需模式的slot配额来从根本上解决调度等待问题

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