管理查詢輸出

評估輸出資料時,請考慮查詢寫入的位元組數。您的結果集會寫入多少位元組?您是否正確限制了寫入的資料量?您是否重複寫入相同的資料?查詢寫入的資料量會影響查詢效能 (I/O)。如果您將結果寫入到永久 (目的地) 資料表,寫入的資料量也會產生費用。

以下最佳做法提供控制輸出資料的指引。

避免重複的資料彙整與子查詢

最佳做法:避免重複彙整相同的資料表及使用相同的子查詢。

如果您要重複彙整相同的資料表,請考慮重新檢查您的結構定義。相較於重複彙整資料,使用巢狀、重複的資料來表示關係可能更有效率。若使用巢狀、重複的資料,彙整作業佔用的通訊頻寬就不會對效能產生影響。如此一來,您也能節省重複讀取及寫入相同資料所產生的 I/O 成本。詳情請參閱使用巢狀和重複的欄位一節。

同樣的,重複執行相同的子查詢也會因重複的查詢處理作業而對效能造成影響。如果您要在多個查詢中使用相同的子查詢,請考慮具體化資料表中的子查詢結果,然後在查詢中使用經過具體化的資料。

具體化子查詢中的結果可改善效能,並減少 BigQuery 讀取及寫入的整體資料量。雖然儲存具體化資料會產生少量費用,不過比起重複 I/O 與查詢處理作業的效能影響,仍是利大於弊。

審慎考慮是否要將大型結果集具體化

最佳做法:請審慎考慮是否將大型結果集具體化並寫入目標資料表。寫入大型結果集會對效能與成本造成影響。

BigQuery 將快取結果限制在壓縮後約 10 GB。傳回較大結果的查詢會超過這個限制,而經常導致下列錯誤:Response too large

如果您從含有可觀資料量的資料表中選取大量欄位,就很可能產生這個錯誤。若執行將資料正規化而未進行縮減或匯總的 ETL 查詢,則寫入快取結果時也可能會發生問題。

您可以透過以下方式克服快取結果的限制:

  • 使用篩選器限制結果集
  • 使用 LIMIT 子句減少結果集,特別是當您使用 ORDER BY 子句時
  • 將輸出資料寫入至目的地資料表

請注意,將非常大的結果集寫入到目的地資料表會影響查詢效能 (I/O)。此外,您將會因儲存目的地資料表而產生少量成本。您可以使用資料集的預設資料表到期時間自動刪除大型目的地資料表。 詳情請參閱儲存空間最佳做法中的使用到期時間設定

在進行大規模排序時使用 LIMIT 子句

最佳做法:如果您要對非常大量的值進行排序,請使用 LIMIT 子句。

使用 ORDER BY 子句寫入查詢的結果會導致 Resources exceeded 錯誤。由於最終排序必須在單一運算單元上完成,如果您嘗試排序非常大型的結果集,最終排序可能會使處理資料的運算單元癱瘓。如果您要使用 ORDER BY 子句,也請使用 LIMIT 子句。

例如,下列查詢會排序非常大型的結果集,並擲回 Resources exceeded 錯誤。查詢會依 mytable 中的 title 資料欄排序。title 資料欄中包含數百萬個值。

SELECT
  title
FROM
  `my-project`.mydataset.mytable
ORDER BY
  title

如要移除錯誤,請使用類似下方內容的查詢:

SELECT
  title
FROM
  `my-project`.mydataset.mytable
ORDER BY
  title DESC
LIMIT
  1000
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁