瞭解導致GBQ中「資源超出」錯誤的原因？

我正在使用Google Analytics數據的BigQuery。在開發查詢的各個點上，我收到錯誤：「超出資源」。我想進一步理解發生了什麼。我已經成功解決了這個問題，但只能通過試驗和錯誤。瞭解導致GBQ中「資源超出」錯誤的原因？

當我使用解釋工具似乎是看起來有超過資源的任何查詢或子查詢的「計算」的一部分。

下面是成功標準的SQL查詢的示例/失敗取決於某些零件是否被留在：

SELECT 
    fullVisitorId, 
    visitId, 
    h.type AS type, 
    h.hitNumber AS hitNumber, 
    h.eventInfo.eventAction AS action, 
    LOWER(h.eventInfo.eventCategory) AS category, 
    h.page.pagePath AS page, 
    h.page.pageTitle AS landingTitle, 
    h.page.searchKeyword AS searchTerm, 
    LEAD(h.page.pagePath) OVER (PARTITION BY fullVisitorId, visitId ORDER BY h.hitNumber ASC) AS landingPage, 
    SPLIT(h.eventInfo.eventLabel, ':')[OFFSET(0)] AS clickTitle, 
    CASE WHEN LEAD(h.page.pageTitle) OVER (PARTITION BY fullVisitorId, visitId ORDER BY h.hitNumber ASC) = SPLIT(h.eventInfo.eventLabel, ':')[OFFSET(0)] THEN true ELSE false END AS searchClick  
FROM `project.dataset.ga_sessions_*` AS main, UNNEST(hits) AS h 
    WHERE _TABLE_SUFFIX BETWEEN '20170401' AND '20170430' 
AND (
    (
    h.eventInfo.eventAction = 'click' AND LOWER(h.eventInfo.eventCategory) LIKE '/search%' 
) 
    OR type = 'PAGE' 
) 
ORDER BY 
    fullVisitorId ASC, visitId ASC, h.hitNumber ASC

當拆除這些組的元素的查詢運行中的任何一個：

ORDER BY 
    fullVisitorId ASC, visitId ASC, h.hitNumber ASC

或者：

LEAD(h.page.pagePath) OVER (PARTITION BY fullVisitorId, visitId ORDER BY h.hitNumber ASC) AS landingPage, 
SPLIT(h.eventInfo.eventLabel, ':')[OFFSET(0)] AS clickTitle, 
CASE WHEN LEAD(h.page.pageTitle) OVER (PARTITION BY fullVisitorId, visitId ORDER BY h.hitNumber ASC) = SPLIT(h.eventInfo.eventLabel, ':')[OFFSET(0)] THEN true ELSE false END AS searchClick

或者：

在單個日期分區上運行時，將運行整個查詢。

我會形容我現在的理解是膚淺的層面，我知道小吉貝的內部運作和如何分配/許可證計算資源。我知道它在可能的情況下在不同的機器上執行計算。我之前聽說過這些描述爲碎片。

什麼我需要了解吉貝計算資源，以瞭解爲什麼上面將工作/無法正常工作？

N.B：我只有1周的訪問，但是，這並不意味着我不能獲得增加的訪問，如果我能證明有必要。很明顯，我不想以當前的理解水平來做到這一點。

來源

2017-06-16 goose

由順序是你的暗示，資源過多，其他人將在科學添加 – Pentium10

我認爲，應該在你的查詢中引起問題的唯一的事情就是ORDER BY操作。如您在Jordan的answer中看到的，此操作是不可並行的。您還可以查看docs瞭解導致「資源超出」錯誤的一些想法。

雖然查詢的其餘部分似乎很好。我測試您的查詢對我們的數據，並將其在20歲處理了近300GB：

如果仍然出現錯誤，那麼也許你的查詢數據的相當高的量。在這種情況下，您可以嘗試將查詢分解爲較小的日期範圍，查詢較少的列，添加一些WHERE條件來過濾某些行，更改等等。

來源

2017-06-16 12:27:08

感謝您的反應會。所以我正確地認爲在大於〜6.5GB的數據集上不可能使用ORDER BY？這似乎是它突破的地步。 – goose

不知道閾值是多少，但通常如果結果集有百萬行，那麼可能'ORDER BY'將不起作用。我在日常工作中發現的事實是，您實際上從不需要訂購大數據集。通常情況下，大多數任務都可以通過限制結果然後排序來達到目的（希望情況就是這樣）。 –

是的，謝天謝地。從查詢（未顯示在上面）正在處理的時候開始，語句的順序被留下。我仍然想知道更多關於GBQ如何平行查詢的知識。如果您知道任何優質資源，請隨時分享。 – goose

瞭解導致GBQ中「資源超出」錯誤的原因？

回答

相關問題