在分析BigQuery审核日志时,我可以看到以下两个字段:
protopayload_auditlog.servicedata_v1_bigquery.jobCompletedEvent.job.jobStatistics.createTime
protopayload_auditlog.servicedata_v1_bigquery.jobCompletedEvent.job.jobStatistics.startTime
在工作时间里,我想保证Tableau触发的某些查询会很快得到答复,从而为我们的业务用户提供最佳体验。
这就是为什么我想尽可能减少“交互式”查询的延迟(“ createTime”和“ startTime”之间的差异)的原因。
当前,“ createTime”和“ startTime”之间的延迟平均为600毫秒。
但这可能会超过10秒甚至20秒,远远超过我们想要的查询响应时间。
“ createTime”和“ startTime”之间延迟的原因是什么?
是由于编译时间(生成查询计划)引起的吗?
还是由于BigQuery上的广告位不可用的事实?
还是其他?
有人对如何减少这种延迟有指示吗?
我看过BigQuery文档,但它似乎只是为了减少执行时间而建议,而不是减少此“预”执行时间。
答案 0 :(得分:0)
我认为,减慢BQ作业从PENDING(createTime)到RUNNING(startTime)状态过渡的因素很少
Concurrent rate limit for on-demand, interactive queries
— 50个并发查询
此限制适用于项目级别。要提高限额,请联系支持或销售
或者,根据部门或团队或其他方面在多个计费项目中分配用户
和
可用插槽-Maximum concurrent slots per project for on-demand pricing
-2,000
如果您需要超过2,000个插槽,请考虑使用flat-rate pricing
而且,您仍然可以将用户分散到不同的计费项目中