并发3 分钟阅读
按分钟统计 BigQuery 并发查询
此查询计算每分钟运行的不同查询数量，揭示影响性能的并发模式。高并发可能导致按需和 Editions 定价下的查询排队。
为什么重要
BigQuery 的并发限制因计费模式而异——按需最多 100 个并发查询，或受 Editions 预留槽位容量限制。超过这些限制时，查询会排队等待。了解并发模式有助于避免这些瓶颈并高效安排工作负载。
工作原理
查询从 INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT 读取，该视图每秒记录作业活动。按 job_id 去重，将时间戳截断到分钟，并按分钟周期计算不同作业。
SQL 查询
Fill in your details to get a ready-to-run query:
SQL
-- Count concurrent queries per minute to detect bottlenecks
DECLARE lookback_days INT64 DEFAULT 7;
WITH timeline AS (
SELECT
TIMESTAMP_TRUNC(period_start, MINUTE) AS minute,
job_id,
ROW_NUMBER() OVER (PARTITION BY job_id ORDER BY job_creation_time DESC) AS rn
FROM `your-project`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY)
AND job_type = 'QUERY'
AND parent_job_id IS NULL
)
SELECT
minute,
COUNT(job_id) AS concurrent_queries
FROM timeline
WHERE rn = 1
GROUP BY minute
ORDER BY minute将 your-project 和 region-us 替换为您的 GCP 项目和数据集区域。
查询说明
JOBS_TIMELINE_BY_PROJECT 每秒执行记录每个作业一行。ROW_NUMBER() 去重确保每个作业只计数一次。parent_job_id IS NULL 过滤掉脚本子作业。按截断分钟的 COUNT 给出并发作业计数。
关键洞察
并发查询 >50 的分钟有触及按需并发限制（每项目 100 个）的风险。
特定时间段内持续高并发表明计划作业重叠——错开开始时间。
并发的峰值后下降可能表明某些查询正在排队，然后在突发中清除。
低并发但高槽位使用意味着少数非常繁重的查询——与许多轻量查询不同的优化策略。
最佳实践
- 1
将管道开始时间错开甚至 1-2 分钟，以降低峰值并发。
- 2
使用 BigQuery 的作业优先级设置（INTERACTIVE 与 BATCH），防止临时查询在批量作业后面排队。
- 3
使用 queued_queries 视图监控 PENDING 状态的查询。
- 4
考虑具有足够 max_slots 的 Editions 预留以处理峰值并发。