Google cloud platform 什么是BigQuery DML配额限制

我的印象是BigQuery DML不再有惰性限制，但是，我的一个摄取工作流运行INSERT DML，该工作流在一天中均匀分布，平均每2分钟80 DML（每天约35-70B条记录转换和聚合）偶尔失败

奇怪的是，我看到只有几个INSERT DML查询失败，而且只持续了几个小时。当查看挂起的作业时，在发生错误时，处于挂起状态的作业中只有几个查询。所有DML查询都使用保留

我想知道配额是什么以及如何计算的，除此之外，还声称没有DML插入配额

这是我看到的错误。 {“location”：“max_dml_pensible_per_table”，“message”：“配额已超出：您的表超过了写入表的dml作业总数的配额，挂起+正在运行。有关详细信息，请参阅

为了更好地理解我的案例，我正在使用定义为以下内容的摄入工作流：

When:
  Prefix: "/xxxxx/xxxx/"
  Suffix: ".gz"
Async: true
Batch:
  MultiPath: true
  Window:
    DurationInSec: 120

Dest:
  Pattern: '.+/(\d{4})/(\d{2})/(\d{2})/.+'
  Table: myproject.selector.selection_$Mod(80)_$1$2$3
  SourceFormat: NEWLINE_DELIMITED_JSON
  Transient:
    Dataset: temp
    Balancer:
      MaxLoadJobs: 100
      ProjectIDs:
        - myproject-transient1
        - myproject-transient2
        - myproject-transient3
        - myproject-transient4
        - myproject-transient5
  Schema:
    Template: myproject.selector.selection_tmpl
  SchemaUpdateOptions:
    - ALLOW_FIELD_ADDITION
  WriteDisposition: WRITE_APPEND

OnSuccess:
  - Action: query
    Request:
      SQL: INSERT INTO `myproject.selector.xxx_agg1`( ....) SELECT ... FROM $TempTable GROUP BY x, y, z
    OnSuccess:
      - Action: query
        Request:
          SQL: INSERT INTO `myproject.selector.xxx_agg2`( ....) SELECT ... FROM $TempTable GROUP BY x1, y1, z1
        OnSuccess:
          - Action: delete

总之：每两分钟，数据文件将被批处理到多达80个加载请求的临时表中，然后复制到最终目标表：myproject.selector.selection_$Mod（80）$1$2$3（80个不同的表以日期为后缀）

---

摄取工作分布在5个临时项目之间，典型的批处理最多为1M条记录，每个加载作业大约需要22秒，复制作业需要1秒。成功复制后，第一个DML执行，然后第二个DML执行。

感谢您的评论，您应该达到一个限制。当您查看

BigQuery DML语句没有配额限制

但是，DML语句被计入每天表操作和分区修改的最大数量。DML语句不会因为这些限制而失败

此外，DML语句受表元数据更新操作的最大速率限制。如果超过此限制，请在重试之间使用指数退避重试该操作

如果您关注最新的链接，请点击

表元数据更新操作的最大速率-每个表每10秒5次操作

表元数据更新限制包括通过调用tables.insert、tables.patch或tables.update API方法或执行ALTER table DDL语句，使用云控制台、经典BigQuery web UI、bq命令行工具、客户端库执行的所有元数据更新操作。此限制也适用于作业输出

---

因此，总而言之，您执行5次以上的表插入

表。插入
超过10秒，您就会遇到重试指数退避的问题

有时配额是允许的，有时它拒绝您！这取决于全球平台状态

尝试在同一个表中插入只有1个请求（您可以使用临时表，然后对所有这些临时表执行全局插入查询）
此配额错误意味着您提交作业的速度比BigQuery完成作业的速度快。BigQuery只能在一个表上同时运行一定数量的DML作业（运行作业）。当超过此限制后收到作业时，作业将放入队列等待执行（挂起作业）。当也超过此队列的限制时，您将收到此配额错误，“您的表超过了写入表的dml作业总数的配额，挂起+运行”

在这种情况下，使用指数回退重试提交这些作业会有所帮助

流式API是另一个用于频繁、小型表附件的选项。它允许更高的QPS。
根据GCP支持团队的说法。错误消息表明DML作业达到了DML所有作业并发限制

DML_ALL_JOBS_CONCURRENT本身不是编号限制，它只是在达到插入并发限制或更新/删除/合并并发限制时触发

DML INSERT允许每个表最多100个并发作业（挂起+运行）。
DML合并/更新/删除多达20个并发作业（挂起+运行）每个表。
您知道每个插入中的数据量吗？它每天在一个聚合表上生成15B条记录，因此每个DML作业将插入262721条记录，通常，作业运行时间为6-17秒每个DML作业在同一个表上执行多少DML插入（每2分钟一次）？最多80个，如描述中所述，它在5个临时项目中实施（每个项目20个DML，所有项目都将进入一个最终dest表）。不应应用元数据限制。我不使用任何列出的操作（DDL、tables.insert、tables.patch或tables.update）我已经阅读了BQ文档，唯一可以解释这种行为的是DML并发限制：1K操作减少到10后，但在这种情况下，我不会看到更多的未决作业参考：总之，我看不到配额错误的解释。您可以直接向谷歌云支持部门询问more准确信息。如果您没有付费支持，您可以提出问题（无需承诺回答延迟）感谢您的推荐。我希望避免流式API的复杂性和高成本，目前，它正在探索事件驱动的数据消耗，因为数据到达BigQuery时，使用基于摄取后SQL的转换。了解BigQuery限制很好。特别是在计划每天500B+的事务目标时。幸运的是DML INSERT不是拦截器，我可以通过额外的导出和加载管道链接操作实现相同的聚合、转换。