このページは Cloud Translation API によって翻訳されました。

読み込みジョブを最適化する

このドキュメントで説明する戦略とベストプラクティスは、BigQuery へのバッチ読み込みまたはストリーミングデータの最適化に役立ち、テーブルごと、1 日あたりの読み込みジョブ数の上限に達することを回避できます。

読み込みジョブの上限は固定されており、引き上げることはできないため、テーブルパーティショニングなどの方法でテーブルを構造化するか、バッチ読み込みやストリーミングなどの方法で読み込みを管理して、読み込みジョブを最適化する必要があります。

テーブルオペレーションの割り当ての仕組み

BigQuery のプロジェクトあたりのテーブルあたりの 1 日あたりのテーブル変更数の上限は、変更によってデータの追加や更新が行われるか、テーブルが切り捨てられるかに関係なく固定されています。この上限には、宛先テーブルに追加または上書きするすべての読み込みジョブ、コピージョブ、クエリジョブを合わせた合計数が含まれます。

読み込みジョブには補充率があります。テーブルオペレーションの上限または補充率を超えると、読み込みジョブは quotaExceeded エラーで失敗します。1 日あたりの読み込みジョブのプロジェクトレベルの上限は、24 時間ごとに補充されます。読み込みジョブが完了すると、使用可能な割り当てが減少します。割り当ては、その後 24 時間かけて徐々に補充されます。読み込みに失敗したジョブは、テーブルごととプロジェクトごとの両方の割り当てにカウントされます。読み込みジョブの上限の詳細については、読み込みジョブをご覧ください。

パーティション分割テーブルの場合、標準テーブルの上限に代わって、パーティション分割テーブルの変更に関する個別の制限が適用されます。

1 日あたりのテーブルオペレーションの上限を超えないように、オペレーションを 24 時間に分散します。たとえば、60 個のオペレーションを含む更新を 25 回実行する場合、約 58 分ごとに 60 個のオペレーションを実行できます。このアプローチは、1 日の上限を満たすのに役立ちます。テーブルの更新をモニタリングするには、BigQuery INFORMATION_SCHEMA ビューをご覧ください。

割り当てから除外されるテーブルオペレーション

テーブル情報（メタデータ）の更新と DML ステートメントの使用は、1 日あたりのテーブル変更の上限にカウントされません。この除外は、標準テーブルとパーティション分割テーブルの両方に適用されます。

プロジェクトで実行できる DML ステートメントの数に制限はありません。以前は、DML ステートメントは 1 日あたりのテーブル変更の回数にカウントされ、上限に達してもスロットリングされませんでしたが、現在はカウントされません。

ストリーミング挿入もテーブルを変更しますが、独自の特定の割り当てが適用されます。

テーブルオペレーションの上限を超えないようにする読み込み戦略

BigQuery の 1 日のテーブルオペレーションの上限を超えないようにするには、次のベストプラクティスを検討してください。

多数の小さな書き込みではなく、少数の大きな書き込みを実行します。
最終的な本番環境テーブルへの個別の書き込みジョブを毎日最小限に抑えます。

これらのベストプラクティスを使用するには、データをバッチ処理するか、BigQuery にストリーミングします。読み込み方法の選択は、大量のデータをリアルタイムで読み込む必要があるかどうかによって異なります。以降のセクションでは、各メソッドで使用できるツールとサービスを含め、バッチ読み込みとデータストリーミングについて詳しく説明します。

バッチ読み込み

BigQuery のプロジェクトあたりの 1 日の読み込み上限を超えないようにするには、大量のデータをバッチ処理し、より少ないジョブで BigQuery に読み込みます。次のセクションでは、データを一括読み込みするために使用できるいくつかの方法について説明します。

ジョブごとにデータをさらに読み込む

新しい情報が利用可能になるたびに BigQuery にデータを送信するのではなく、単一の大きなジョブを使用してデータを収集し、BigQuery に読み込みます。

たとえば、数行のデータごとに個別の読み込みジョブを実行するのではなく、ファイル（CSV ファイルや JSON ファイルなど）に数千行のデータが蓄積されるまで待ってから、1 つの読み込みジョブを実行して、すべてのデータをテーブルに追加できます。ジョブにさらに多くのデータが含まれていても、このアクションは 1 つのテーブルオペレーションとしてカウントされます。読み込みジョブでワイルドカードを使用することで、ファイルをバッチ処理できます。ワイルドカードを使用すると、ディレクトリ内のファイルのバッチを選択して、1 回の読み込みジョブで複数のファイルを読み込むことができます。

次の例は、bq load コマンドまたは SQL LOAD DATA クエリでワイルドカードを使用する方法を示しています。

bq

次の例は、Cloud Storage から my_target_table という名前の BigQuery テーブルに CSV データを読み込む bq load コマンドを示しています。複数のソースファイル名を選択するには、コマンドでワイルドカードを使用します。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 バケットの名前。
OBJECT_PATH_WILDCARD: Cloud Storage バケット内の CSV ファイルへのパス。複数のファイルを照合するには、ワイルドカード（*）を含めます。たとえば、文字列 gs://my-bucket/path/to/data/my_prefix_*.csv は、ワイルドカード文字 * を使用して、my_prefix_ で始まり .csv で終わる gs://my-bucket/path/to/data/ 内のすべてのファイルを読み込みます。

詳しくは以下をご覧ください。

SQL

次の例は、SQL の LOAD DATA クエリを使用して、Cloud Storage バケットから BigQuery テーブルに CSV データを読み込む方法を示しています。複数のソースファイル名を選択するには、コマンドでワイルドカードを使用します。

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 バケットの名前。
OBJECT_PATH_WILDCARD: Cloud Storage バケット内の CSV ファイルへのパス。複数のファイルを照合するには、ワイルドカード（*）を含めます。たとえば、文字列 gs://my-bucket/path/to/data/my_prefix_*.csv は、ワイルドカード文字 * を使用して、my_prefix_ で始まり .csv で終わる gs://my-bucket/path/to/data/ 内のすべてのファイルを読み込みます。

詳細については、GoogleSQL の LOAD ステートメントをご覧ください。

BigQuery Storage Write API を使用したバッチ読み込み

バッチデータを BigQuery に読み込む方法の 1 つは、Google API クライアントライブラリを使用して、アプリケーションから Storage Write API を直接使用することです。

Storage Write API は、テーブルの制限内に収まるようにデータ読み込みを最適化します。大容量のリアルタイムストリーミングの場合は、COMMITTED ストリームではなく PENDING ストリームを使用します。PENDING ストリームを使用すると、API はストリームを commit するまでレコードを一時的に保存します。

Storage Write API を使用したデータ読み込みのバッチ処理の完全な例については、Storage Write API を使用したデータ読み込みのバッチ処理をご覧ください。

Dataflow を使用したバッチ読み込み

データパイプラインを使用してデータをストリーミング、変換、BigQuery への書き込みを行う場合は、Dataflow を使用できます。作成するデータパイプラインは、Pub/Sub や Apache Kafka などのサポートされているソースから読み取ります。BigQueryIO コネクタを使用して Dataflow パイプラインを作成することもできます。このコネクタは、高性能データストリーミングと 1 回限りのセマンティクスに Storage Write API を使用します。

Dataflow を使用して BigQuery にデータをバッチ読み込みする方法については、Dataflow から BigQuery に書き込むをご覧ください。

データストリーミング

頻繁に更新される大量のデータを読み込むには、データを BigQuery にストリーミングすることをおすすめします。データストリーミングでは、クライアントアプリケーションから BigQuery に新しいデータが継続的に書き込まれます。この戦略により、読み込みジョブの実行数が多すぎるという制限に達することを回避できます。以降のセクションでは、BigQuery にデータをストリーミングするいくつかの方法について説明します。

Storage Write API を使用したデータのストリーミング

Storage Write API を使用して、最小限のレイテンシでレコードをリアルタイムで BigQuery にストリーミングします。Storage Write API は、1 回限りの配信セマンティクス、スキーマ更新の検出、ストリーミング変更データキャプチャ（CDC）の UPSERT などの高度な機能を提供する効率的なストリーミングプロトコルを提供します。さらに、1 か月あたり最大 2 TiB を無料で取り込むことができます。

Storage Write API の使用については、Storage Write API を使用したデータのストリーミングをご覧ください。

Dataflow を使用してデータをストリーミングする

Dataflow を使用して、Pub/Sub や Apache Kafka などのサポートされているソースから読み取るデータパイプラインを作成します。これらのパイプラインは、データを変換して宛先として BigQuery に書き込みます。Storage Write API を使用する BigQueryIO コネクタを使用して、Dataflow パイプラインを作成できます。

Dataflow を使用して BigQuery にデータをストリーミングする方法については、Dataflow から BigQuery に書き込むをご覧ください。

読み込み用のテーブルを管理するためのベストプラクティス

BigQuery にデータをバッチ読み込みまたはストリーミングするだけでなく、次の方法でテーブルを管理して、データ取り込み用に最適化します。

パーティション分割テーブルを使用する

テーブルパーティショニングは、BigQuery で大規模なテーブルを管理するための強力な手法です。特に、頻繁にデータ読み込みオペレーションを実行する必要がある場合に有効です。テーブルを日付、タイムスタンプ、整数に基づいて、より管理しやすい小さなセグメントに分割することで、テーブルのパフォーマンスと費用対効果を大幅に向上させることができます。

データ読み込みのパーティショニングの主な利点は、BigQuery の 1 日あたりのテーブルオペレーションの割り当てがテーブルレベルではなくパーティションレベルで適用されることです。パーティション分割テーブルの場合、パーティションの変更には、標準テーブルの上限に代わる、より高い上限が別途適用されます。パーティション分割テーブルの上限により、割り当て上限に達することなく 1 日に実行できる読み込みジョブの数が大幅に増加します。

一般的で非常に効果的な戦略は、毎日のデータをバッチで読み込むことです。たとえば、2025-09-18 の 1 日分のデータをすべて一時的なステージングテーブルに収集できます。次に、1 日の終わりに 1 つのジョブを実行して、このデータをメインの本番環境テーブルのこの日の特定のパーティションに読み込みます。BigQuery は単一パーティションのデータのみを処理するため、このアプローチによりデータが適切に整理され、読み込みオペレーションが高速化され、費用が削減されます。

パーティショニングは、サイズが大きく増加するテーブルに強く推奨されますが、パーティションのサイズが常に 10 GB 未満になる場合は、パーティショニングを避けることをおすすめします。詳細については、パーティショニングを使用するタイミングをご覧ください。

時間単位のパーティショニングや整数範囲のパーティショニングなど、使用可能なさまざまなパーティショニング方法の詳細については、パーティション分割テーブルのタイプをご覧ください。

組み込みの指数バックオフ、切り捨て、ジッターを活用する

組み込みの指数バックオフと再試行は、オペレーションが一時的に失敗した場合に、アプリケーションがスムーズに復元できるようにするエラー処理方法です。このような障害には、レート制限エラー（rateLimitExceeded）やネットワークの短時間の中断（unavailable）などがあります。

信頼性の高いシステムでは、クライアントサイドキューからタスクを取得するワーカーも指数バックオフと再試行を使用します。これは、BigQuery を呼び出すときに行われ、2 つのレベルの保護が作成されます。

たとえば、Python 用の公式の google-cloud-bigquery-storage ライブラリには、指数バックオフによる再試行ロジックが組み込まれています。このロジックは、UNAVAILABLE などの一時的な gRPC エラーを処理します。ほとんどの場合、この再試行コードを自分で記述する必要はありません。client.append_rows() 呼び出しは、これらの再試行を自動的に処理します。

この組み込みの処理は、公式クライアントライブラリを使用する大きなメリットです。再試行できないエラー（スキーマの不一致を示す INVALID_ARGUMENT など）のみを処理する必要があります。