排解配額和限制錯誤

BigQuery 有各式各樣的配額與限制,可限制不同要求和作業的頻率和數量。配額的用途是保護基礎架構,並避免客戶產生超出預期的用量。本文說明如何診斷及減輕配額和限制造成的特定錯誤。

部分錯誤訊息會指出可提高的配額或限制,其他錯誤訊息則會指出無法提高的配額或限制。達到硬性限制表示您需要為工作負載實作暫時或永久的替代方案,或是最佳做法。即使配額或限制可以提高,也建議您這麼做。

本文會根據這些類別整理錯誤訊息和解決方案,而本文稍後的「總覽」一節會說明如何解讀錯誤訊息,並針對問題套用正確的解決方案。

如果錯誤訊息未列於本文,請參閱錯誤訊息清單,其中提供更多一般錯誤資訊。

總覽

如果 BigQuery 作業因超出配額而失敗,API 會傳回 HTTP 403 Forbidden 狀態碼。回應主體會進一步說明已達到的配額。回應主體看起來會與下列內容類似:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

酬載中的 message 欄位會說明超出的限制。例如,message 欄位可能會顯示 Exceeded rate limits: too many table update operations for this table

一般來說,配額限制會被分為兩個類別,如回應酬載中的 reason 欄位所示。

  • rateLimitExceeded這個值表示短期限制。如要解決這些限制問題,請稍待幾秒再重試作業。在兩次重試之間使用「指數輪詢」。也就是說,每次重試之間的延遲時間會呈指數增加。

  • quotaExceeded這個值表示長期限制。如果您達到長期配額上限,則至少應等待 10 分鐘,然後再重試作業。如果您持續達到其中一項長期配額限制,則應分析您的工作負載,以便找出緩解問題的方法。將工作負載最佳化或要求增加配額都有可能緩解問題。

如有 quotaExceeded 錯誤,請查看錯誤訊息,瞭解哪些配額已超過上限。接著分析工作負載,確認是否可以避免達到配額上限。

在某些情況下,您可以與 BigQuery 支援團隊聯絡聯絡 Google Cloud 銷售人員,並申請提高配額,但我們建議您先嘗試本文中的建議。

診斷

如要診斷問題,請按照下列步驟操作:

  • 使用 INFORMATION_SCHEMA 檢視畫面區域限定符,分析基本問題。這些檢視表含有 BigQuery 資源的中繼資料,包括工作、預留項目和串流資料插入。

    舉例來說,以下查詢會使用 INFORMATION_SCHEMA.JOBS 檢視表列出過去一天內所有配額相關錯誤:

    SELECT
    job_id,
    creation_time,
    error_result
    FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
    WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
        error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')

    REGION_NAME 替換為專案的區域。前面必須加上 region-。舉例來說,如果是 US 多區域,請使用 region-us

  • 查看 Cloud 稽核記錄中的錯誤。

    舉例來說,使用記錄檔探索工具時,以下查詢會在訊息字串中找出 Quota exceededlimit 的錯誤:

    resource.type = ("bigquery_project" OR "bigquery_dataset")
    protoPayload.status.code ="7"
    protoPayload.status.message: ("Quota exceeded" OR "limit")
    

    在本例中,狀態碼 7 表示 PERMISSION_DENIED,這對應到 HTTP 403 狀態碼。

    如需其他 Cloud 稽核記錄查詢範例,請參閱 BigQuery 查詢

排解可提高的配額或限制

您可以提高下列配額和限制,但建議先嘗試任何建議的解決方法或最佳做法。

專案掃描的免費查詢位元組數超出配額

在免費方案中執行查詢時,如果帳戶達到每月可查詢的資料大小上限,BigQuery 就會傳回這項錯誤。如要進一步瞭解查詢價格,請參閱免費用量層級

錯誤訊息

Your project exceeded quota for free query bytes scanned

解析度

如要繼續使用 BigQuery,請將帳戶升級為 Cloud Billing 付費帳戶

串流資料插入配額錯誤

本節針對排解以串流方式將資料傳入 BigQuery 的配額錯誤提供相關提示。

在特定區域中,如果您並未在每個資料列的 insertId 欄位中填入資料,則串流資料插入會含有較高的配額。如要進一步瞭解串流資料插入的配額,請參閱串流資料插入。BigQuery 串流的配額相關錯誤取決於 insertId 是否存在。

錯誤訊息

如果 insertId 欄位為空白,則可能會發生下列配額錯誤:

配額限制 錯誤訊息
每項專案每秒位元組數 在區域 REGION 中專案 PROJECT_ID gaia_id 為 GAIA_ID 的實體超過每秒插入位元組數的配額。

如果在 insertId 欄位填入資料,則可能會發生下列配額錯誤:

配額限制 錯誤訊息
每項專案每秒資料列數量 您在 REGION 的專案 PROJECT_ID 超過每秒串流資料插入資料列的配額。
每個資料表每秒資料列數量 您的資料表 TABLE_ID 超過每秒串流資料插入資料列的配額。
每個資料表每秒位元組數 您的資料表 TABLE_ID 超出每秒串流資料插入位元組數的配額。

insertId 欄位的用途是簡化插入的資料列。如果同一個 insertId 的多個插入項目均於幾分鐘之內抵達,則 BigQuery 會寫入單一版本的記錄。但是,我們無法保證系統會自動刪除重複的內容。為了達到最大的串流總處理量,建議您不要加入 insertId,改成手動刪除重複內容。詳情請參閱確保資料一致性一文。

如果遇到這項錯誤,請診斷問題,然後按照建議步驟解決問題。

診斷

使用 STREAMING_TIMELINE_BY_* 檢視表來分析串流流量。這些檢視表會每隔一分鐘匯總串流統計資料,並依錯誤代碼分類。結果中會顯示配額錯誤,且 error_code 等於 RATE_LIMIT_EXCEEDEDQUOTA_EXCEEDED

根據已達到的特定配額上限查看 total_rowstotal_input_bytes。如果錯誤是資料表層級的配額,請依 table_id 進行篩選。

舉例來說,下列查詢顯示每分鐘擷取的位元組總數和配額錯誤總數:

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

解析度

如要解決配額錯誤,請按照下列步驟操作:

  • 如果您使用 insertId 欄位來刪除重複的內容,而您的專案位於支援較高串流配額的區域,則建議移除 insertId 欄位。這個解決方案可能需要執行一些其他步驟,以手動方式刪除重複的資料內容。詳情請參閱手動移除重複內容

  • 如果您並非使用 insertId,或是無法加以移除,請監控 24 小時內的串流流量,並分析配額錯誤:

    • 如果您看到的大多是 RATE_LIMIT_EXCEEDED 錯誤而不是 QUOTA_EXCEEDED 錯誤,而您的整體流量低於配額的 80%,則這些錯誤可能表示流量暫時暴增。您可以在每次重試之間使用指數輪詢重試作業,以處理這些錯誤。

    • 如果您使用 Dataflow 工作插入資料,請考慮改用載入工作,而非串流插入。詳情請參閱「設定插入方法」。如果您使用 Dataflow 和自訂 I/O 連接器,請考慮改用內建 I/O 連接器。詳情請參閱自訂 I/O 模式

    • 如果您看到 QUOTA_EXCEEDED 錯誤,或整體流量持續超過配額的 80%,請提交增加配額的要求。詳情請參閱「要求調整配額」。

    • 您也可以考慮使用較新的 Storage Write API 取代串流插入,因為這項 API 的輸送量較高、價格較低,而且提供許多實用功能。

包含遠端函式的並行查詢數量上限

如果含有遠端函式的並行查詢數量超過上限,BigQuery 就會傳回這項錯誤。不過,這項上限可以提高。請先嘗試解決方法和最佳做法。

如要進一步瞭解遠端函式限制,請參閱「遠端函式」。

錯誤訊息

Exceeded rate limits: too many concurrent queries with remote functions for
this project

診斷

如要瞭解包含遠端函式的並行查詢限制,請參閱「遠端函式限制」。

解析度

CREATE MODEL 陳述式數量上限

這項錯誤表示您已超出 CREATE MODEL 陳述式的配額。

錯誤訊息

Quota exceeded: Your project exceeded quota for CREATE MODEL queries per project.

解析度

如果超出 CREATE MODEL 陳述式的配額,請傳送電子郵件至 bqml-feedback@google.com,要求增加配額。

每個專案每日的複製工作數量上限 (配額錯誤)

如果專案中執行的複製工作數超過每日上限,BigQuery 就會傳回這項錯誤。如要進一步瞭解每日複製作業的限制,請參閱複製作業

錯誤訊息

Your project exceeded quota for copies per project

診斷

如要收集更多有關複製作業來源的資料,可以嘗試下列做法:

  • 如果複製作業位於單一或少數幾個區域,您可以嘗試查詢特定區域的 INFORMATION_SCHEMA.JOBS 資料表。例如:

    SELECT
    creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
    FROM `PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
    WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "COPY"
    order by creation_time DESC

    您也可以根據想查看的時間範圍調整時間間隔。

  • 如要查看所有地區的所有複製工作,請在 Cloud Logging 中使用下列篩選器:

    resource.type="bigquery_resource"
    protoPayload.methodName="jobservice.insert"
    protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*
    

解析度

  • 如果頻繁複製作業的目的是建立資料快照,建議改用資料表快照。相較於複製完整表格,表格快照的費用較低,速度也較快。
  • 如要要求增加配額,請與支援團隊銷售人員聯絡。審查及處理要求可能需要幾天的時間。建議在要求中說明優先順序、用途和專案 ID。

超出每日擷取位元組配額錯誤

如果專案的擷取作業超出預設的 50 TiB 每日上限,BigQuery 就會傳回這項錯誤。如要進一步瞭解擷取工作限制,請參閱「擷取工作」。

錯誤訊息

Your usage exceeded quota for ExtractBytesPerDay

診斷

如果匯出的資料表超過 50 TiB,匯出作業會失敗,因為超過擷取限制。如要解決這個問題,請參閱這篇文章。如要匯出特定資料表分區的資料表資料,可以使用分區修飾符來識別要匯出的分區。

如要收集最近幾天的匯出資料用量,可以嘗試下列做法:

  • 查看專案配額:使用 Name: Extract bytes per dayMetric: bigquery.googleapis.com/quota/extract/bytes 等篩選條件,並顯示用量圖表,即可查看幾天內的用量趨勢。

  • 或者,您也可以查詢 INFORMATION_SCHEMA.JOBS_BY_PROJECT,查看幾天內的總擷取位元組。舉例來說,下列查詢會傳回過去七天內,EXTRACT 工作每天處理的位元組總數。

    SELECT
    TIMESTAMP_TRUNC(creation_time, DAY) AS day,
    SUM ( total_bytes_processed ) / POW(1024, 3) AS total_gigabytes_processed
    FROM
    `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "EXTRACT"
    GROUP BY 1
    ORDER BY 2 DESC
  • 然後找出耗用位元組數超出預期的特定工作,進一步縮小搜尋結果範圍。以下範例會傳回過去七天內處理超過 100 GB 的前 100 個 EXTRACT 工作。

    SELECT
    creation_time,
    job_id,
    total_bytes_processed/POW(1024, 3) AS total_gigabytes_processed
    FROM
    `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
    AND job_type="EXTRACT"
    AND total_bytes_processed > (POW(1024, 3) * 100)
    ORDER BY
    total_bytes_processed DESC
    LIMIT 100

您也可以使用工作探索器,搭配 Bytes processed more than 等篩選器,篩選出特定時間範圍內的高處理量工作。

解析度

如要解決這項配額錯誤,其中一種方法是建立運算單元預留項目,然後將專案指派給具有 PIPELINE 工作類型的預留項目。由於這個方法使用專屬預訂,而非免費的共用運算單元集區,因此可以略過限制檢查。如有需要,您可以刪除預留項目,以便日後使用共用運算單元集區。

如要瞭解匯出超過 50 TiB 資料的替代方法,請參閱「擷取工作」的附註部分。

每個專案配額錯誤的每秒 tabledata.list 位元組數上限

當錯誤訊息中提及的專案號碼達到每秒可透過專案中的 tabledata.list API 呼叫讀取的資料大小上限時,BigQuery 就會傳回這項錯誤。詳情請參閱「每分鐘最多 tabledata.list 位元組」。

錯誤訊息

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

解析度

如要解決這項錯誤,請按照下列步驟操作:

  • 一般來說,我們建議盡量不要超過這個上限。舉例來說,您可以延長要求間隔時間,如果錯誤不常發生,實作指數輪詢重試即可解決這個問題。
  • 如果使用案例需要從資料表快速且頻繁地讀取大量資料,建議使用 BigQuery Storage Read API,而非 tabledata.list API。
  • 如果上述建議無法解決問題,請按照下列步驟,透過Google Cloud 主控台 API 資訊主頁申請增加配額:

    1. 前往Google Cloud 控制台 API 資訊主頁
    2. 在資訊主頁中,篩選配額:Tabledata list bytes per minute (default quota)
    3. 選取配額,然後按照「要求調整配額」一文中的指示操作。

    審查及處理要求可能需要幾天的時間。

API 要求數量上限錯誤

當您達到每個使用者每個方法對 BigQuery API 的 API 要求數量速率限制時,BigQuery 會傳回這項錯誤。舉例來說,服務帳戶的 tables.get 方法呼叫,或是不同使用者電子郵件地址的 jobs.insert 方法呼叫。詳情請參閱 BigQuery API 中的「每位使用者每種方法每秒最多可發出的 API 請求數」速率限制。

錯誤訊息

Quota exceeded: Your user_method exceeded quota for concurrent api requests
per user per method.

如果遇到這項錯誤,請診斷問題,然後按照建議步驟解決問題。

診斷

如果尚未找出達到此速率限制的方法,請執行下列操作:

服務帳戶

  1. 前往代管服務帳戶的專案

  2. 在 Google Cloud 控制台中,前往「API Dashboard」(API 資訊主頁)

    如需查看 API 詳細用量資訊的操作說明,請參閱「使用 API 資訊主頁」。

  3. 在 API 資訊主頁中,選取「BigQuery API」

  4. 如要查看更詳細的使用情況資訊,請選取「指標」,然後執行下列操作:

    1. 在「選取圖表」中,選取「依 API 方法劃分的流量」

    2. 依服務帳戶的憑證篩選圖表。在發現錯誤的時間範圍內,您可能會看到某個方法的尖峰。

API 呼叫

部分 API 呼叫會在 Cloud Logging 的 BigQuery 稽核記錄中記錄錯誤。如要找出達到上限的方法,請按照下列步驟操作:

  1. 前往 Google Cloud 控制台,依序選取�navigation menu 和「Logging」>「Logs Explorer」,為專案啟用記錄檔探索工具: Google Cloud

    前往記錄檔探索工具

  2. 執行下列查詢來篩選記錄:

     resource.type="bigquery_resource"
     protoPayload.authenticationInfo.principalEmail="<user email or service account>"
     "Too many API requests per user per method for this user_method"
     In the log entry, you can find the method name under the property protoPayload.method_name.
     

    詳情請參閱 BigQuery 稽核記錄總覽

解析度

如要解決配額錯誤,請按照下列步驟操作:

  • 減少 API 要求數量,或在多個 API 要求之間加入延遲,確保要求數量不超過上限。

  • 如果只是偶爾超出限制,您可以針對這項特定錯誤實作重試作業,並採用指數輪詢。

  • 如果經常插入資料,建議使用串流插入,因為串流插入不受 BigQuery API 配額影響。不過,串流插入 API 會產生相關費用,且有專屬的限制和配額

    如要瞭解串流插入的費用,請參閱 BigQuery 定價

  • 使用 Dataflow 和 BigQuery I/O 連接器將資料載入 BigQuery 時,您可能會遇到 tables.get 方法的這項錯誤。如要解決這個問題,請按照下列步驟操作:

    • 將目的地資料表的建立處理方式設為 CREATE_NEVER。詳情請參閱「建立處置方式」。

    • 使用 Apache Beam SDK 2.24.0 以上版本。在舊版 SDK 中,CREATE_IF_NEEDED 處置會呼叫 tables.get 方法,檢查資料表是否存在。

  • 如要申請提高配額,請與支援團隊或銷售人員聯絡。如需額外配額,請參閱「申請提高配額」。申請增加配額可能需要幾天才能處理完畢。為提供更多要求相關資訊,建議您在要求中加入工作優先順序、執行查詢的使用者,以及受影響的方法。

排解無法提高的配額或限制

您無法提高下列配額或限制,但可以套用建議的解決方法或最佳做法來減輕影響。

查詢佇列限制錯誤

如果專案嘗試互動式或批次查詢排入佇列,但數量超出佇列限制,您可能會遇到這個錯誤。

錯誤訊息

Quota exceeded: Your project and region exceeded quota for
max number of jobs that can be queued per project.

解析度

這項上限無法提高。如要解決配額錯誤,請按照下列步驟操作:

  • 暫停工作。如果發現某個程序或管道導致查詢次數增加,請暫停該程序或管道。

  • 使用批次優先順序的工作。您可以將比互動式查詢更多的批次查詢加入佇列。

  • 分發查詢。根據查詢性質和業務需求,在不同專案之間分配及散布負載。

  • 分配跑步時間。在較長的時間範圍內分配負載。如果您的報表解決方案需要執行許多查詢,請嘗試在查詢開始時導入一些隨機性。舉例來說,請勿同時開始所有報表。

  • 使用 BigQuery BI Engine。如果您在使用商業智慧 (BI) 工具建立資訊主頁時遇到這個錯誤,且該資訊主頁會查詢 BigQuery 中的資料,建議您使用 BigQuery BI Engine。使用 BigQuery BI Engine 是這個用途的最佳選擇。

  • 最佳化查詢和資料模型。通常可以重新撰寫查詢,提高執行效率。舉例來說,如果查詢包含一般資料表運算式 (CTE) (即 WITH 子句),且查詢中有多個位置參照該運算式,系統就會多次執行這項運算。最好將 CTE 執行的計算作業保留在臨時資料表中,然後在查詢中參照該資料表。

    多個聯結也可能導致效率不彰。在這種情況下,您可能需要考慮使用 巢狀和重複的資料欄。使用這項功能通常可改善資料的區域性、免除部分聯結需求,並整體減少資源耗用量和查詢執行時間。

    最佳化查詢可降低費用,因此採用以運算資源為基礎的計價模式時,您就能使用運算單元執行更多查詢。詳情請參閱「查詢效能最佳化簡介」。

  • 最佳化查詢模型。BigQuery 並非關聯資料庫。不適合用於無限次的小型查詢。執行大量小型查詢會快速耗盡配額。這類查詢的執行效率不如小型資料庫產品。BigQuery 是大型資料倉儲,主要用途就是儲存大量資料。最適合對大量資料執行分析查詢。

  • 保存資料 (已儲存的表格)。在 BigQuery 中預先處理資料,並儲存在其他資料表中。舉例來說,如果您執行許多類似的運算密集型查詢,但條件不同,則結果不會快取。WHERE這類查詢每次執行時也會耗用資源。您可以預先計算資料並儲存在資料表中,藉此提升這類查詢的效能,並縮短處理時間。您可以使用 SELECT 查詢資料表中的預先計算資料。您通常可以在 ETL 程序中擷取資料時執行這項操作,也可以使用排程查詢具體化檢視區塊

  • 使用模擬測試模式。模擬測試模式執行查詢,估算讀取的位元組數,但不會實際處理查詢。

  • 預覽資料表資料。如要試用或探索資料,而非執行查詢,請使用 BigQuery 的資料表預覽功能預覽資料表資料。

  • 使用快取查詢結果 所有查詢結果 (包括互動式與批次查詢) 皆會以快取方式存放在暫時性資料表中約 24 小時,但也有一些例外狀況。 執行快取查詢時,仍會計入並行查詢限制,但使用快取結果的查詢作業速度,會比未使用快取結果的查詢作業快上許多,因為 BigQuery 不需計算結果集。

隨機播放大小限制錯誤

如果專案超出可供隨機排序作業使用的磁碟和記憶體大小上限,BigQuery 就會傳回這項錯誤。

這項配額的計算方式是以預訂為單位,並根據預訂項目將配額分配給各個專案。Cloud Customer Care 無法修改配額。如要進一步瞭解用量,請查詢 INFORMATION_SCHEMA.JOBS_TIMELINE 檢視畫面

錯誤訊息

您收到下列其中一則錯誤訊息:

  • Quota exceeded: Your project exceeded quota for total shuffle size limit.
  • Resources exceeded: Your project or organization exceeded the maximum
    disk and memory limit available for shuffle operations. Consider provisioning
    more slots, reducing query concurrency, or using more efficient logic in this
    job.

解析度

如要解決這項錯誤,請按照下列步驟操作:

依資料欄分區的資料表分區修改次數配額錯誤

當資料表達到每日允許的分區修改次數配額時,BigQuery 就會傳回這個錯誤。分區修改次數包括所有載入工作複製工作查詢工作,這些工作會將資料附加至目的地分區或覆寫目的地分區。

如要查看「每個資料欄分區資料表每日可修改分區的次數上限」值,請參閱「分區資料表」一文。

錯誤訊息

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table

解析度

這項配額無法提高。如要解決配額錯誤,請按照下列步驟操作:

  • 變更資料表的分區,讓每個分區包含更多資料,以減少分區總數。舉例來說,您可以將分區依天改為依月,或是變更資料表的分區方式
  • 請改用叢集,而非分區。
  • 如果您經常從儲存在 Cloud Storage 中的多個小型檔案載入資料,且每個檔案都使用一個工作,請將多個載入工作合併為單一工作。您可以透過以逗號分隔的清單 (例如 gs://my_path/file_1,gs://my_path/file_2),或使用萬用字元 (例如 gs://my_path/*),從多個 Cloud Storage URI 載入資料。

    詳情請參閱批次載入資料

  • 舉例來說,如果您使用載入、選取或複製工作,將單一資料列附加至資料表,則應考慮將多個工作批次處理為一個工作。如果將 BigQuery 當做關聯式資料庫使用,效能會不佳。最佳做法是避免頻繁執行單列附加動作。
  • 如要以高頻率附加資料,請考慮使用 BigQuery Storage Write API。建議您使用這項解決方案,以高效能方式擷取資料。BigQuery Storage Write API 具備強大的功能,包括單次傳送語意。如要瞭解限制和配額,請參閱「Storage Write API」一文;如要瞭解使用這項 API 的費用,請參閱「BigQuery 資料擷取定價」一文。
  • 如要監控資料表上修改的分區數量,請使用 INFORMATION_SCHEMA 檢視區塊

資料表中繼資料更新作業的頻率上限錯誤

如果資料表達到標準資料表的中繼資料更新作業頻率上限,BigQuery 就會傳回這項錯誤。資料表作業包括下列所有工作:載入工作複製工作查詢工作,這些工作會將資料附加至目的地資料表、覆寫目的地資料表,或是使用 DML DELETEINSERTMERGETRUNCATE TABLEUPDATE 將資料寫入資料表。

如要查看「每個資料表的資料表中繼資料更新作業頻率上限」值,請參閱「標準資料表」一節。

錯誤訊息

Exceeded rate limits: too many table update operations for this table

如果遇到這項錯誤,請診斷問題,然後按照建議步驟解決問題。

診斷

中繼資料表更新可能來自修改資料表中繼資料的 API 呼叫,或修改資料表內容的工作。如果尚未找出資料表中繼資料更新作業的主要來源,請按照下列步驟操作:

找出 API 呼叫
  1. 前往 Google Cloud 導覽選單,然後依序選取「記錄」>「記錄檔探索工具」

    前往記錄檔探索工具

  2. 執行下列查詢,篩選記錄以查看資料表作業:

    resource.type="bigquery_dataset"
    protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
    (protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
    protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
    protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
    
找出所需的工作

以下查詢會傳回過去一天內,專案中修改受影響資料表的作業清單。如果預期機構中的多個專案會寫入資料表,請將 JOBS_BY_PROJECT 替換為 JOBS_BY_ORGANIZATION

SELECT
 job_id,
 user_email,
 query
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

詳情請參閱 BigQuery 稽核記錄總覽

解析度

這項配額無法提高。如要解決配額錯誤,請按照下列步驟操作:

  • 降低資料表中繼資料的更新頻率。
  • 在工作或資料表作業之間加入延遲時間,確保更新率在限制範圍內。
  • 如要插入或修改資料,請考慮使用 DML 作業。DML 作業不受每個資料表的資料表中繼資料更新作業頻率上限限制。

    DML 作業有其他限制和配額。詳情請參閱使用資料操縱語言 (DML)

  • 如果您經常從儲存在 Cloud Storage 中的多個小型檔案載入資料,且每個檔案都使用一個工作,請將多個載入工作合併為單一工作。您可以透過以逗號分隔的清單 (例如 gs://my_path/file_1,gs://my_path/file_2),或使用萬用字元 (例如 gs://my_path/*),從多個 Cloud Storage URI 載入資料。

    詳情請參閱批次載入資料

  • 舉例來說,如果您使用載入、選取或複製工作,將單一資料列附加至資料表,則應考慮將多個工作批次處理為一個工作。如果將 BigQuery 當做關聯式資料庫使用,效能會不佳。最佳做法是避免頻繁執行單列附加動作。
  • 如要以高頻率附加資料,請考慮使用 BigQuery Storage Write API。建議您使用這項解決方案,以高效能方式擷取資料。BigQuery Storage Write API 具備強大的功能,包括單次傳送語意。如要瞭解限制和配額,請參閱「Storage Write API」一文;如要瞭解使用這項 API 的費用,請參閱「BigQuery 資料擷取定價」一文。
  • 如要監控資料表上修改的分區數量,請使用 INFORMATION_SCHEMA 檢視區塊

資料表匯入或查詢附加配額錯誤

如果資料表達到標準資料表每日資料表作業的限制,BigQuery 就會傳回這則錯誤訊息。資料表作業包括下列所有載入工作複製工作查詢工作:將資料附加至目的地資料表或覆寫目的地資料表。

如要查看「每日資料表作業數」限制的值,請參閱「標準資料表」一文。

錯誤訊息

Your table exceeded quota for imports or query appends per table

如果遇到這項錯誤,請診斷問題,然後按照建議步驟解決問題。

診斷

如果尚未找出大部分表格作業的來源,請按照下列步驟操作:

  1. 記下失敗的查詢、載入或複製工作要寫入的專案、資料集和資料表。

  2. 使用INFORMATION_SCHEMA.JOBS_BY_*表格進一步瞭解會修改資料表的作業。

    以下範例使用 JOBS_BY_PROJECT,找出過去 24 小時內依工作類型分組的每小時工作計數。如果預期多個專案會寫入資料表,請將 JOBS_BY_PROJECT 替換成 JOBS_BY_ORGANIZATION

    SELECT
    TIMESTAMP_TRUNC(creation_time, HOUR),
    job_type,
    count(1)
    FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
    AND destination_table.project_id = "my-project-id"
    AND destination_table.dataset_id = "my_dataset"
    AND destination_table.table_id = "my_table"
    GROUP BY 1, 2
    ORDER BY 1 DESC

解析度

這項配額無法提高。如要解決配額錯誤,請按照下列步驟操作:

  • 如果您經常從儲存在 Cloud Storage 中的多個小型檔案載入資料,且每個檔案都使用一個工作,請將多個載入工作合併為單一工作。您可以透過以逗號分隔的清單 (例如 gs://my_path/file_1,gs://my_path/file_2),或使用萬用字元 (例如 gs://my_path/*),從多個 Cloud Storage URI 載入資料。

    詳情請參閱批次載入資料

  • 舉例來說,如果您使用載入、選取或複製工作,將單一資料列附加至資料表,則應考慮將多個工作批次處理為一個工作。如果將 BigQuery 當做關聯式資料庫使用,效能會不佳。最佳做法是避免頻繁執行單列附加動作。
  • 如要以高頻率附加資料,請考慮使用 BigQuery Storage Write API。建議您使用這項解決方案,以高效能方式擷取資料。BigQuery Storage Write API 具備強大的功能,包括單次傳送語意。如要瞭解限制和配額,請參閱「Storage Write API」一文;如要瞭解使用這項 API 的費用,請參閱「BigQuery 資料擷取定價」一文。
  • 如要監控資料表上修改的分區數量,請使用 INFORMATION_SCHEMA 檢視區塊

針對資料表待處理的 DML 陳述式過多

這個錯誤表示針對相同資料表執行的並行變動 DML 陳述式 (UPDATEDELETEMERGE) 數量,已超過資料操縱語言 (DML) 配額限制。這項配額限制適用於每個資料表,且僅適用於變動 DML 陳述式,不包括 INSERT

解析度

請按照 DML 陳述式的最佳做法,批次處理 DML 工作。

載入 CSV 檔案配額錯誤

如果您使用 bq load 指令載入大型 CSV 檔案,並搭配 --allow_quoted_newlines 旗標,可能會遇到這個錯誤。

錯誤訊息

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

解析度

如要解決配額錯誤,請按照下列步驟操作:

  • --allow_quoted_newlines 旗標設為 false
  • 將 CSV 檔案分割成較小的區塊,每個區塊的大小不得超過 4 GB。

如要進一步瞭解將資料載入 BigQuery 時的限制,請參閱「載入工作」。

使用者超出並行 project.lists 要求配額

如果 Microsoft Power BI 工作透過 Simba ODBC 驅動程式或 DataHub 與 BigQuery 通訊時,超出 project.list API 限制,就會發生這個錯誤。如要解決這個問題,請使用本節所述的短期或長期解決方法。

錯誤訊息

Your user exceeded quota for concurrent project.lists requests

診斷

當 Power BI 報表重新整理,且 Simba 驅動程式與特定 BigQuery 專案建立連線時,Power BI 的連線和探索階段就會發生這個錯誤。

短期解決方案

如要暫時解決這個問題,請使用下列解決方法,並依效用排序。根據您是使用 Simba 驅動程式還是 DataHub 連接至 BigQuery,實作三或四項修正。

如需長期修正方式,請參閱「長期解決方案」。

  1. 錯開報表重新整理時間。如果無法修改 DSN,請減少並行要求數量,以解決配額問題。不要讓所有報表同時重新整理 (例如上午 9:00),而是將排程錯開幾分鐘 (例如上午 9:01、9:03 和 9:05)。這種做法可將 API 呼叫分散到一段時間內,降低達到並行限制的可能性。

  2. 在 Power BI 中實作重試機制。這項反應式策略有助於報表從暫時性故障中復原。Power BI 內建資料重新整理失敗的重試邏輯。雖然這種做法無法避免配額錯誤,但可讓管道在 API 呼叫量最初的尖峰期過後,於後續嘗試中成功產生報表,進而提升管道的復原能力。如要實作這項修正,請按照下列步驟操作:

    1. 在 Power BI 服務中,前往資料集的「設定」
    2. 展開「排定的重新整理作業」區段。在「重試」下方,設定 Power BI 自動重新執行失敗的重新整理作業。
  3. 如果是舊版 Simba 驅動程式,請在 ODBC 連線中指定專案 ID。這項動作可防止驅動程式執行 projects.list 探索呼叫。駕駛人會直接連線至指定專案,避免不必要的 API 呼叫,並解決配額問題。

    如果未指定專案,較新的驅動程式會立即失敗,並顯示類似 Unable to establish connection with data source. Missing settings: {[Catalog]} 的訊息。

    如要修正這個問題,請按照下列步驟操作:

    1. 在執行 Power BI Gateway 或 Power BI Desktop 的電腦上,開啟「ODBC Data Sources (64-bit)」應用程式。
    2. 在 BigQuery 專用的 Simba ODBC 驅動程式主要設定畫面中,請在「Catalog (Project)」欄位中填入特定 Google Cloud 專案 ID,例如 my-gcp-project-id
  4. 如果是舊版 DataHub,請在 DataHub 擷取設定中指定專案 ID。如果您使用 DataHub 而非 Simba 驅動程式,請進行這項修正。與 Simba 類似,DataHub 的後續版本也需要您指定專案 ID,否則無法連線至 BigQuery。

    為避免超出 DataHub 限制,請修改 DataHub 擷取設定,提供要掃描的專案 ID 清單。這會導致 DataHub 設定無法找到服務帳戶可查看的所有專案。

    在 BigQuery 來源配方檔案 (通常是 YAML 檔案) 中,使用 project_ids 設定列舉要擷取的專案。然後使用新設定重新部署 DataHub 擷取方案。請參閱以下範例和 DataHub 提供的這個較長的範例

    以下是 DataHub 設定程式碼片段的範例:

  source:
  type: "bigquery"
  config:
    # Instead of relying on discovery, explicitly list the projects.
    # This avoids the problematic projects.list() API call.
  project_ids:
    -   "YOUR_PRODUCTION_PROJECT_ID"
    -   "YOUR_ANALYTICS_PROJECT_ID"
    -   "ANOTHER_BQ_PROJECT"

長期解決方案

如要長期解決這個錯誤訊息,最佳做法是為每個函式建立專屬的獨立Google Cloud 服務帳戶。舉例來說,您可以為所有 Power BI 報表建立服務帳戶,並為 DataHub 擷取作業建立服務帳戶。

這項最佳做法可將 API 用量劃分為不同的配額儲存區,避免 DataHub 中的高負載工作導致 Power BI 中的重要商務報表失敗。

請使用下列各節中的行動計畫,解決 Power BI 和 DataHub 的長期配額錯誤。

第 1 階段:準備
  1. 通知 Power BI 閘道和 DataHub 設定的擁有者,您將進行協調變更,以解決持續發生的工作失敗問題。
  2. 在 Google Cloud 控制台中,建立兩個新的服務帳戶,例如 sa-powerbi-gateway@...sa-datahub-ingestion@...
  3. 為 Power BI 和 DataHub 服務帳戶建立服務帳戶金鑰。
  4. 授予每個新服務帳戶最低權限,指派下列 Identity and Access Management 角色,讓服務帳戶在相關的 Identity and Access Management (IAM) 中執行工作。請避免指派過於廣泛的角色,例如 ProjectEditor
必要的角色

Power BI 的服務帳戶會執行查詢,並從資料表讀取資料。在每個 Google Cloud 專案中,將下列角色授予服務帳戶,Power BI 必須存取這些專案中的資料。如要進一步瞭解這些角色,請參閱「BigQuery 角色」。

DataHub 擷取作業的服務帳戶只需要讀取中繼資料,例如資料表名稱、結構定義和說明,不需要讀取資料表中的資料。針對 DataHub 掃描的每個專案,在專案層級授予下列角色。如要進一步瞭解這些角色,請參閱「BigQuery 的 IAM 角色」。

BigQuery 中繼資料檢視者:這個角色專門用於讀取中繼資料。這項角色可授予列出資料集和資料表,以及查看中繼資料的權限,但不會授予存取基礎資料的權限。

階段 2:協調發布

在用量較低的期間,Power BI 管理員會在閘道電腦上更新 ODBC DSN 設定,方法如下:

  1. 將驗證方法變更為使用在上一個步驟中建立的新 sa-powerbi-gateway@... 服務帳戶金鑰。
  2. 如果尚未執行短期修正,請在 ODBC 驅動程式的「Catalog (Project)」(目錄 (專案)) 欄位中輸入專案 ID。 Google Cloud
  3. 請 DataHub 擁有者更新 BigQuery 來源設定 YAML 檔案。
  4. 指向先前步驟中建立的新 sa-datahub-ingestion@... 服務帳戶金鑰。
  5. 如果尚未執行短期修正,請使用 project_ids 參數明確列出要掃描的專案。
  6. 使用新設定重新部署 DataHub 擷取方案。
第 3 階段:驗證與監控

如要驗證及監控修正效果,Power BI 和 DataHub 管理員請執行下列步驟:

  1. 手動觸發幾份重要 Power BI 報表的重新整理作業,以及 DataHub 中的新擷取作業。確認這些工作順利完成,且未發生配額錯誤。
  2. 在 Google Cloud 控制台,依序前往「IAM 與管理」>「配額」頁面。
  3. 篩選 BigQuery API 服務。
  4. 找到名為「並行 project.lists 要求」的配額,然後點選圖表圖示,即可查看一段時間內的用量。

管理員應該會發現這個特定 API 呼叫的使用量大幅且永久下降,確認修正成功。