【问题标题】:Google BigQuery Query exceeded resource limitsGoogle BigQuery 查询超出资源限制
【发布时间】:2021-09-15 09:31:00
【问题描述】:

我正在为我的公司建立一个粗略的数据仓库,并且我已成功地将联系人、公司、交易和关联数据从我们的 CRM 提取到 bigquery 中,但是当我将这些数据合并到一个主表中以通过我们的 BI 进行分析时平台,我不断收到错误:

Query exceeded resource limits. This query used 22602 CPU seconds but would charge only 40M Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to the flat-rate reservation pricing model, which does not have this limit. 22602 CPU seconds were used, and this query must use less than 10200 CPU seconds.

因此,我希望优化我的查询。我已经删除了所有GROUP BY 和ORDER BY 命令,并尝试使用WHERE 命令进行额外过滤,但这对我来说似乎不合逻辑,因为它会增加处理需求。

我目前的查询是:

SELECT 
    coy.company_id,
    cont.contact_id,
    deals.deal_id,
    {another 52 fields}
FROM `{contacts}` AS cont
LEFT JOIN `{assoc-contact}` AS ac
ON cont.contact_id = ac.to_id
LEFT JOIN `{companies}` AS coy 
ON CAST(ac.from_id AS int64)  = coy.company_id
LEFT JOIN `{assoc-deal}` AS ad
ON coy.company_id = CAST(ad.from_id AS int64) 
LEFT JOIN `{deals}` AS deals
ON ad.to_id = deals.deal_id;

仅供参考 {assoc-contact} 和 {assoc-deal} 都是我从关联表创建的单独视图,以便更轻松地将这些表关联到公司表。

还应注意,此查询偶尔会成功运行,所以我知道它确实有效,但由于查询太大,大约 90% 的时间它都会失败。

【问题讨论】:

  • 尝试优化您的查询,如果您认为优化得很好,您需要让您的项目管理员为您的大查询配置添加更多槽

标签: sql google-bigquery query-optimization etl


【解决方案1】:

TLDR;

检查您的加入密钥。 99% 的时间问题的原因是组合爆炸。

我无法确定,因为我无法访问基础表的数据,但我会给出一个通用的解决方法,根据我的经验,它每次都能找到根本原因。

长答案

调查方法

假设您要连接两个表

SELECT 
  cols
FROM L
JOIN R ON L.c1 = R.c1 AND L.c2 = R.c2

你遇到了这个错误。您应该做的第一件事是检查两个表中的重复项。

SELECT 
  c1, c2, COUNT(1) as nb
FROM L
GROUP BY c1, c2
ORDER by nb DESC

对于连接中涉及的每个表来说都是一样的。

我敢打赌,您会发现您的加入密钥是重复的。 BigQuery 的可扩展性非常强,因此根据我的经验,当您的连接键在两个表上重复超过 100 000 次时,就会发生此错误。这意味着你加入后,你将有 100000^2 = 100 亿行!!!

为什么 BigQuery 会出现此错误

根据我的经验,此错误消息意味着与输入的大小相比,您的查询执行了过多的计算。 难怪如果您在加入具有几百万行的表后最终得到 100 亿行,那么您会得到这个。

BigQuery 的按需定价模型基于在您的表中读取的数据量。这意味着人们可能会试图滥用这一点,例如在读取小型数据集时运行 CPU 密集型计算。举一个极端的例子,假设有人制作了一个 Javascript UDF 来挖掘比特币并在 BigQuery 上运行它

  SELECT MINE_BITCOIN_UDF()

查询的费用为 0 美元,因为它不读取任何内容,但会占用 Google 的 CPU 数小时。当然,他们必须为此做点什么。

所以这个比率的存在是为了确保用户不会在处理几 Mb 输入的同时使用数小时的 CPU 做任何粗略的事情。

具有不同定价模型的其他 MPP 平台(例如,Azure Synapse 根据已处理 字节的数量收费,而不是像 BQ 那样读取)可能会毫无怨言地运行,然后向您收取 10Tb 的费用来读取该 40Mb 表。

P.S.:很抱歉回答的太晚了,对于提问的人来说可能为时已晚,但希望它能帮助遇到该错误的人。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多