最佳化載入工作

本文所述的策略和最佳做法可協助您將批次載入或串流資料最佳化至 BigQuery，避免達到每個資料表每天的載入工作數量上限。

載入工作的上限是固定的，無法提高，因此您應透過資料表分區等方法建構資料表，或透過批次載入或串流等方法管理載入作業，藉此最佳化載入工作。

資料表作業配額的運作方式

無論修改作業是附加或更新資料，還是截斷資料表，每個專案每天每個資料表的 BigQuery 修改次數上限都是固定的。這項限制包括下列所有工作：載入工作、複製工作和查詢工作，這些工作會將資料附加至目的地資料表或覆寫目的地資料表。

載入工作有補充率。如果超過資料表作業限制或補充率，載入工作就會失敗並顯示 quotaExceeded 錯誤。專案層級的每日載入工作限制會在連續 24 小時內重置。載入工作完成後，可用配額就會減少。配額會在接下來 24 小時內逐漸恢復。即使載入工作失敗，仍會計入每個資料表和每個專案的配額。如要進一步瞭解載入工作限制，請參閱「載入工作」。

如果是分區資料表，則適用分區資料表修改的獨立限制，取代標準資料表限制。

如要維持在每日表格作業限制內，請在 24 小時內完成作業。舉例來說，如果您執行 25 次更新，每次更新有 60 項作業，則每 58 分鐘可執行約 60 項作業。這種做法有助於達到每日上限。如要監控資料表更新，請參閱 BigQuery 檢視畫面INFORMATION_SCHEMA。

配額不含資料表作業

更新資料表資訊 (中繼資料) 和使用 DML 陳述式不會計入每日資料表修改次數上限。這項排除條件適用於標準資料表和分區資料表。

專案可執行無限數量的 DML 陳述式。雖然 DML 陳述式先前會計入每日資料表修改次數，且即使達到上限也不會受到節流，但現在不會再計入。

串流插入也會修改表格，但受專屬配額限制。

載入策略，避免超出資料表作業限制

如要將 BigQuery 的每日資料表作業量控制在上限內，請考慮採用下列最佳做法：

• 執行較少次數的寫入作業，但每次寫入較多資料，而不是多次寫入少量資料。
• 盡量減少每天寫入最終正式版資料表的個別寫入工作。

如要採用這些最佳做法，請將資料批次處理或串流至 BigQuery。載入方法取決於您是否需要即時載入大量資料，或是否不擔心即時載入。以下各節將詳細說明批次載入和資料串流，包括每種方法可用的工具和服務。

批次載入

如要確保 BigQuery 專案的每日載入量不超過上限，請分批載入大量資料，並減少載入工作數量。以下各節說明幾種可批次載入資料的方法。

載入每項工作的更多資料

不必在每次有新資訊時都將資料傳送至 BigQuery，而是使用單一大型工作收集資料並載入 BigQuery。

舉例來說，您不必每隔幾列資料就執行一次載入工作，可以等到檔案 (例如 CSV 或 JSON 檔案) 中累積了數千列資料後，再執行一次載入工作，將所有資料附加至資料表。即使作業包含更多資料，這項動作仍算是一項資料表作業。您可以使用萬用字元搭配載入工作，批次處理檔案。萬用字元可讓您在目錄中選取批次檔案，以便在單一載入工作中載入多個檔案。

下列範例說明如何搭配 bq load 指令或 SQL LOAD DATA 查詢使用萬用字元。

bq

下列範例顯示 bq load 指令，可將 Cloud Storage 中的 CSV 資料載入名為 my_target_table 的 BigQuery 資料表。如要選取多個來源檔案名稱，請在指令中使用萬用字元。AUTODETECT 旗標會根據 Cloud Storage 中的來源資料自動判斷資料表結構定義，並支援萬用字元 (*)，將符合特定命名模式的多個檔案載入 BigQuery 資料表。

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

更改下列內容：

• PROJECT_ID： Google Cloud 專案的 ID。
• DATASET_NAME：要載入資料的 BigQuery 資料集名稱。
• TABLE_NAME：您要載入資料的 BigQuery 資料表名稱。
• BUCKET_NAME：包含來源檔案的 Cloud Storage bucket 名稱。
• OBJECT_PATH_WILDCARD：Cloud Storage bucket 中 CSV 檔案的路徑。加入萬用字元 (*) 即可比對多個檔案。舉例來說，字串 gs://my-bucket/path/to/data/my_prefix_*.csv 使用萬用字元 * 載入 gs://my-bucket/path/to/data/ 中以 my_prefix_ 開頭且以 .csv 結尾的所有檔案。

如要瞭解詳情，請參考下列資源：

• Cloud Storage URI 的萬用字元支援
• bq 指令列工具參考資料

SQL

下列範例說明如何使用 SQL LOAD DATA 查詢，將 Cloud Storage 值區中的 CSV 資料載入 BigQuery 資料表。如要選取多個來源檔案名稱，請在指令中使用萬用字元。

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

更改下列內容：

• DATASET_NAME：要載入資料的 BigQuery 資料集名稱。
• TABLE_NAME：您要載入資料的 BigQuery 資料表名稱。
• SOURCE_FORMAT 會設定來源檔案的類型，例如 CSV 或 JSON。在本範例中，請使用 CSV。
• BUCKET_NAME：包含來源檔案的 Cloud Storage bucket 名稱。
• OBJECT_PATH_WILDCARD：Cloud Storage bucket 中 CSV 檔案的路徑。加入萬用字元 (*) 即可比對多個檔案。舉例來說，字串 gs://my-bucket/path/to/data/my_prefix_*.csv 使用萬用字元 *，載入 gs://my-bucket/path/to/data/ 中開頭為 my_prefix_ 且結尾為 .csv 的所有檔案。

詳情請參閱「GoogleSQL 中的 LOAD 陳述式」。

使用 BigQuery Storage Write API 批次載入

如要將批次資料載入 BigQuery，其中一個方法是使用 Google API 用戶端程式庫，直接從應用程式使用 Storage Write API。

Storage Write API 會盡量減少資料載入量，確保不超過資料表限制。如要進行大量即時串流，請使用 PENDING 串流，而非 COMMITTED 串流。使用 PENDING 串流時，API 會暫時儲存記錄，直到您提交串流為止。

如需使用 Storage Write API 批次載入資料的完整範例，請參閱「使用 Storage Write API 批次載入資料」。

使用 Dataflow 批次載入

如要使用資料管道將資料串流、轉換及寫入 BigQuery，可以使用 Dataflow。您建立的資料管道會從 Pub/Sub 或 Apache Kafka 等支援的來源讀取資料。您也可以使用 BigQueryIO 連接器建立 Dataflow 管道，該連接器會使用 Storage Write API 進行高效能資料串流，並提供「剛好一次」語意。

如要瞭解如何使用 Dataflow 將資料批次載入 BigQuery，請參閱「從 Dataflow 寫入 BigQuery」。

資料串流

如要載入大量資料並經常更新，建議您將資料串流至 BigQuery。透過資料串流，用戶端應用程式會持續將新資料寫入 BigQuery，避免因執行過多載入工作而達到上限。以下各節說明將資料串流至 BigQuery 的幾種方法。

使用 Storage Write API 串流資料

使用 Storage Write API，以最低延遲時間將記錄即時串流至 BigQuery。Storage Write API 提供高效的串流通訊協定，可提供進階功能，例如只傳送一次的語意、結構定義更新偵測，以及串流變更資料擷取 (CDC) upsert。此外，您每月最多可免費擷取 2 TiB 的資料。

如要瞭解如何使用 Storage Write API，請參閱「使用 Storage Write API 串流資料」。

使用 Dataflow 串流資料

使用 Dataflow 建立資料管道，從支援的來源 (例如 Pub/Sub 或 Apache Kafka) 讀取資料。這些管道會轉換資料，然後寫入 BigQuery 做為目的地。您可以使用 BigQueryIO 連接器建立 Dataflow 管道，該連接器會使用 Storage Write API。

如要瞭解如何使用 Dataflow 將資料串流至 BigQuery，請參閱「從 Dataflow 寫入 BigQuery」。

管理要載入的表格的最佳做法

除了將資料批次載入或串流至 BigQuery 外，您還可以透過下列方式管理資料表，以最佳化資料擷取作業。

使用分區資料表

資料表分割是管理 BigQuery 大型資料表的強大技術，特別是需要頻繁執行資料載入作業時。您可以根據日期、時間戳記或整數，將資料表分割為較小且易於管理的部分，大幅提升資料表效能和成本效益。

分區的主要優點是，BigQuery 的每日資料表作業配額適用於分區層級，而非資料表層級。如果是分區資料表，分區修改適用較高的限制，取代標準資料表限制。分區資料表的限制大幅提高，因此您每天可以執行的載入工作數量也隨之增加，不會達到配額限制。

常見且非常有效的策略是批次載入每日資料。舉例來說，您可以將 2025-09-18 的所有當日資料收集到臨時暫存資料表中。然後在一天結束時執行單一工作，將這些資料載入主要正式版資料表中當天的特定分區。由於 BigQuery 只會與單一分區的資料互動，這種方法可讓資料井然有序，並加快載入作業速度，降低成本。

雖然強烈建議對大型且不斷成長的資料表進行分區，但如果分區大小一律小於 10 GB，最好避免分區。詳情請參閱「何時該使用分區」。

如要進一步瞭解可用的不同分區方法，例如時間單位和整數範圍分區，請參閱分區資料表類型。

善用內建的指數輪詢、截斷和抖動功能

內建指數輪詢和重試是錯誤處理方法，可協助應用程式在作業暫時失敗時順利復原。這類失敗可能包括速率限制錯誤 (rateLimitExceeded) 或短暫的網路問題 (unavailable)。

在可靠的系統中，從用戶端佇列中提取工作的背景工作人員也會使用指數輪詢並重試。呼叫 BigQuery 時，他們會這麼做，藉此建立兩層防護。

舉例來說，Python 的官方 google-cloud-bigquery-storage 程式庫內建指數輪詢策略的重試邏輯。這項邏輯會處理暫時性 gRPC 錯誤，例如 UNAVAILABLE。在大多數情況下，您不需要自行編寫這段重試程式碼。client.append_rows() 呼叫會自動處理這些重試作業。

使用官方用戶端程式庫的一大優點，就是內建這項處理機制。您只需要處理無法重試的錯誤，例如 INVALID_ARGUMENT，這表示結構定義不相符。