我发现了几个相关的问题，但 Google 团队没有针对这个特定问题给出明确的答案：
写入 BigQuery 的 Cloud DataFlow 作业是否限制为 BigQuery 配额，即每表每秒 100K 行（即 BQ 流式传输限制）？
google dataflow write to bigquery table performance
Cloud DataFlow performance - are our times to be expected?
编辑： 主要动机是找到一种方法来预测各种输入大小的运行时间。
我已成功运行显示通过数据流监控 UI 处理的 > 180K 行/秒的作业。但我不确定这是否会在插入表时受到某种限制，因为作业运行时间比简单计算慢了大约 2 倍（500 毫米行/18 万行/秒 = 45 分钟，实际上花了将近 2 小时）
【问题讨论】：
标签： google-bigquery google-cloud-dataflow
从您的消息来看，听起来您是在批量执行管道，而不是流模式。
在批处理模式下，在 Google Cloud Dataflow 服务上运行的作业不使用 BigQuery 的流式写入。相反，我们将所有要导入的行写入 GCS 上的文件，然后调用 BigQuery load" job。请注意，这会降低您的成本（加载作业比流式写入更便宜）并且总体上更高效（BigQuery 进行批量加载比进行每行导入更快）。权衡是在整个作业成功完成之前，BigQuery 中没有可用的结果。
加载作业不受每秒行数的限制，而是受daily quotas的限制。
在流模式下，Dataflow 确实使用 BigQuery 的流式写入。在这种情况下，每秒 100,000 行的限制确实适用。如果超出该限制，Dataflow 将收到 quota_exceeded 错误，然后将重试失败的插入。此行为将有助于消除暂时超出 BigQuery 配额的短期峰值；如果您的管道在很长一段时间内超出配额，则此失败并重试策略最终将成为一种背压形式，会减慢您的管道速度。
--
至于为什么您的工作需要 2 小时而不是 45 分钟，您的工作将有多个连续进行的阶段，因此使用最快阶段的吞吐量并不是估算端到端运行时间的准确方法。例如，直到 Dataflow 完成将所有行写入 GCS 后，才会启动 BigQuery 加载作业。您的费率似乎合理，但如果您怀疑性能下降，请跟进。
【讨论】：