【问题标题】:Incomplete BigQuery Job Statistics or Reasons for pending Tasks after Job completionBigQuery 作业统计信息不完整或作业完成后待处理任务的原因
【发布时间】:2020-06-26 11:07:10
【问题描述】:

我正在使用 BigQuery Java API 进行查询,我的查询看起来像

select * from <TABLE> where Hour >= timestamp('2020-05-01 00:00:00') and Hour <= timestamp('2020-05-02 00:00:00') and <COLUMN> IN (select <COLUMN> from <OTHER_TABLE> limit 1028) limit 1

我观察到,当作业标记为已完成时,并非所有任务都已完成,如下所示。

      "statementType": "SELECT",
      "timeline": [
        {
          "activeUnits": "1348",
          "completedUnits": "245",
          "elapsedMs": "953",
          "pendingUnits": "13270",
          "totalSlotMs": "11681"
        },
        {
          "activeUnits": "1330",
          "completedUnits": "246",
          "elapsedMs": "1053",
          "pendingUnits": "13269",
          "totalSlotMs": "15647"
        }
      ],
      "totalBytesBilled": "46137344",
      "totalBytesProcessed": "45657839",
      "totalPartitionsProcessed": "2",
      "totalSlotMs": "15647"

对于大多数作业,我通常会在完成时看到 0 个待处理的单元,并且预计它是 0。

这些任务是否被偶然跳过,也许是因为限制(我的猜测)?如果是这样的话,不应该有一个skippedUnits吗?

【问题讨论】:

    标签: google-bigquery performance-testing query-performance


    【解决方案1】:

    是的,像无序行集上的 LIMIT 子句就是一个示例,其中并非所有可能的工作单元都需要完成才能满足查询阶段。查看查询阶段统计信息而不是时间线可以更好地了解这些统计信息的来源,因为它们将与特定的执行阶段相关联。

    时间线只是在给定时刻估计工作状态的一系列快照。它与限定单个工作单元的转换方式无关。

    【讨论】:

    • 我的分析基于查询统计数据。这只是我想知道为什么时间线会这样,试图深入了解 bigquery 的内部结构。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-02
    • 2021-09-03
    • 2022-10-25
    • 2015-04-17
    相关资源
    最近更新 更多