割り当てと上限のエラーのトラブルシューティング

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 フィールドで示される 2 つのカテゴリに分類されます。

• rateLimitExceeded。この値は、短期的な上限を示します。上限の問題を解決するには、数秒後に操作を再試行してください。次の再試行の前に「指数バックオフ」を使用します。つまり、再試行のたびに指数関数的に遅延が増加します。

• quotaExceeded。この値は、長期的な上限を示します。長期的な割り当て上限に達した場合は、10 分以上経過してからもう一度オペレーションをお試しください。このような長期的な割り当て上限に何度も繰り返し到達する場合は、ワークロードを分析して問題の軽減方法を検討する必要があります。ワークロードの最適化や割り当て上限の引き上げなどにより軽減できる場合があります。

注: 1 日あたりの割り当てとされる割り当てもあります。たとえば、テーブルごとの読み込みジョブ数は 1 日あたりの割り当てです。ただし、この割り当ては 24 時間の中で徐々に補充されるため、上限に達してから 24 時間待つ必要はありません。

quotaExceeded エラーについては、エラー メッセージを調べて、どの割り当て上限を超過しているかを把握します。次に、ワークロードを分析して、割り当ての上限に到達することを回避できるかどうかを確認します。

BigQuery のサポートまたは Google Cloud セールスに割り当ての引き上げをリクエストすることもできますが、このドキュメントの推奨事項を試すことをおすすめします。

診断

問題を診断するには、次の操作を行います。

• INFORMATION_SCHEMA ビューを使用して根本的な問題を分析します。これらのビューには、ジョブ、予約、ストリーミング挿入などの BigQuery リソースに関するメタデータが含まれます。

  たとえば、次のクエリでは INFORMATION_SCHEMA.JOBS ビューを使用して、前日の割り当てに関するすべてのエラーを一覧表示します。

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

• Cloud Audit Logs でエラーを表示します。

  たとえば、ログ エクスプローラを使用すると、メッセージ文字列に Quota exceeded または limit のいずれかが含まれるエラーを次のクエリで照会できます。

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

  この例では、ステータス コード 7 は、HTTP 403 ステータス コードに対応した PERMISSION_DENIED を示します。

  Cloud Audit Logs のその他のクエリサンプルについては、BigQuery クエリをご覧ください。

クエリキューの上限エラー

プロジェクトがキューの上限で許容されるよりも多くのインタラクティブ クエリまたはバッチクエリをキューに入れることを試みると、このエラーが発生する場合があります。

エラー メッセージ

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 を使用することが、このユースケースに対して最適です。

• クエリとデータモデルを最適化する。たいていは、クエリをより効率的に実行するために、クエリを書き換えることができます。たとえば、クエリに複数の場所から参照される Common table expression (CTE)-WITH 句が含まれている場合、この計算は複数回行われます。CTE が行った計算は一時テーブルに保持して、それをクエリで参照することをおすすめします。

  複数の結合も、効率性の損失の原因になる可能性があります。この場合、ネストされた繰り返し列の使用を検討する必要があるかもしれません。これを使用するとしばしば、データの局所性が向上し、一部の結合が不要になり、リソースの消費量とクエリの実行時間が全体的に短縮されます。

  クエリを最適化するとコストが削減されるため、容量ベースの料金を使用すると、スロットでより多くのクエリを実行できます。詳細については、クエリ パフォーマンスの最適化の概要をご覧ください。

• クエリモデルを最適化する。BigQuery はリレーショナル データベースではありません。小規模なクエリが無数に存在する状況には最適化されていません。小規模なクエリを多数実行すると、短時間で割り当てが枯渇します。このようなクエリは、小規模なデータベース プロダクトで実行される場合ほど効率的に実行されません。BigQuery は大規模なデータ ウェアハウスであり、これが主なユースケースです。大量のデータに対する分析クエリで最も効果を発揮します。

• データ（保存済みテーブル）を永続化する。BigQuery でデータを前処理して、新たなテーブルに格納します。たとえば、異なる WHERE 条件で類似した計算負荷の高いクエリを大量に実行した場合、結果はキャッシュに保存されません。また、このようなクエリは実行するたびにリソースを消費します。データを事前に計算してテーブルに保存することで、クエリのパフォーマンスを向上させ、処理時間を短縮できます。テーブルに保存されている事前計算したデータは、SELECT クエリによって照会できます。この処理は、ETL プロセス内の取り込み中に行うことも、スケジュール設定されたクエリやマテリアライズド ビューを使用して行うこともできます。

• ドライラン モードを使用する。読み取りバイト数は推定するものの、実際にはクエリを処理しないドライラン モードでクエリを実行します。

• テーブルデータをプレビューする。 クエリを実行するのではなく、データをテストまたは探索するには、BigQuery のテーブル プレビュー機能を使用してテーブルデータをプレビューします。

• キャッシュに保存されたクエリ結果を使用する。 インタラクティブ クエリとバッチクエリの両方を含むすべてのクエリの結果は、一部の例外を除いて、一時テーブルに約 24 時間キャッシュ保存されます。実行中、キャッシュに保存されたクエリは同時実行クエリの上限に引き続きカウントされますが、BigQuery では結果セットを計算する必要がないため、キャッシュに保存された結果を使用するクエリは、キャッシュに保存された結果を使用しないクエリよりも実行速度が大幅に上昇します。

列パーティション分割テーブルのパーティション変更数の割り当てエラー

列パーティション分割テーブルのパーティション変更数が 1 日あたりの割り当てに達すると、BigQuery がこのエラーを返します。パーティションの変更には、宛先パーティションを追加または上書きするすべての読み込みジョブ、コピージョブ、クエリジョブの合計が含まれます。

1 日あたりの列パーティション分割テーブルあたりのパーティション変更数の上限値を確認するには、パーティション分割テーブルをご覧ください。

エラー メッセージ

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

解決策

この割り当てを増やすことはできません。この割り当てエラーを解決するには、次の操作を行います。

• パーティションの合計数を減らすために、テーブルのパーティショニングを変更して、各パーティションに格納されるデータ量を増やします。たとえば、日単位のパーティショニングから月単位のパーティショニングへの変更や、テーブルのパーティショニング方法の変更を行います。
• パーティショニングの代わりにクラスタリングを使用します。
• Cloud Storage に保存された複数の小さなファイルから頻繁にデータを読み込み、ファイルごとにジョブが使用される場合には、複数の読み込みジョブを結合して 1 つのジョブにします。カンマ区切りのリスト（例: gs://my_path/file_1,gs://my_path/file_2）を使用するか、ワイルドカード（例: gs://my_path/*）を使用すれば、複数の Cloud Storage URI から読み込むことができます。

  詳細については、データのバッチ読み込みをご覧ください。

• たとえば、読み込み、選択、コピーのジョブを使用して 1 行のデータをテーブルに追加する場合は、複数のジョブを 1 つのジョブでバッチ処理することを検討してください。BigQuery をリレーショナル データベースとして使用するとうまく動作しません。ベスト プラクティスとしては、単一行の追加アクションを頻繁に実行しないでください。
• 高頻度でデータを追加する場合は、BigQuery Storage Write API の使用を検討してください。これは、高パフォーマンスのデータ取り込みに推奨されるソリューションです。BigQuery Storage Write API には、1 回限りの配信セマンティクスなど、堅牢な機能が用意されています。上限と割り当てについては、Storage Write API をご覧ください。この API の使用料金については、BigQuery データの取り込み料金をご覧ください。
• テーブルで変更されたパーティションの数をモニタリングするには、INFORMATION_SCHEMA ビューを使用します。

ストリーミング挿入の割り当てエラー

このセクションでは、BigQuery へのデータのストリーミングに関連する割り当てエラーを解決するためのヒントをいくつか紹介します。

特定のリージョンでは、各行の insertId フィールドにデータを入力しないと、ストリーミング挿入の割り当て量が高くなります。ストリーミング挿入の割り当ての詳細については、ストリーミング挿入をご覧ください。BigQuery ストリーミングの割り当て関連エラーは、insertId の有無によって異なります。

エラー メッセージ

insertId フィールドが空の場合、次の割り当てエラーが発生する可能性があります。

割り当て上限	エラー メッセージ
プロジェクトごと 1 秒あたりのバイト数	リージョン: REGION 内の gaia_id: GAIA_ID、プロジェクト: PROJECT_ID のエンティティが、1 秒あたりの挿入バイト数に対する割り当てを超過しました。

insertId フィールドに値が入力されている場合、次の割り当てエラーが発生する可能性があります。

割り当て上限	エラー メッセージ
プロジェクトごと 1 秒あたりの行数	REGION 内のプロジェクト PROJECT_ID で、1 秒あたりのストリーミング挿入行数に対する割り当てを超過しました。
テーブルごと 1 秒あたりの行数	テーブル: TABLE_ID で、1 秒あたりのストリーミング挿入行数に対する割り当てを超過しました。
テーブルごと 1 秒あたりのバイト数	テーブル: TABLE_ID で、1 秒あたりのストリーミング挿入バイト数に対する割り当てを超過しました。

insertId フィールドの目的は、挿入した行の重複を排除することです。数分で同じ insertId が複数挿入されると、BigQuery は 1 つのバージョンのレコードを書き込みます。ただし、この自動重複排除は保証されていません。ストリーミングのスループットを最大にするために、insertId を含めずに手動の重複排除を使用することをおすすめします。詳細については、データ整合性の確保をご覧ください。

このエラーが発生した場合は、問題を診断し、推奨される手順を実施して解決します。

診断

ストリーミング トラフィックの分析には STREAMING_TIMELINE_BY_* ビューを使用します。これは、ストリーミング統計を 1 分間隔で集計し、エラーコードでグループ化したビューです。割り当てエラーは、結果で error_code が RATE_LIMIT_EXCEEDED または QUOTA_EXCEEDED に等しくなっています。

到達した割り当て上限に従い、total_rows または total_input_bytes を確認します。テーブルレベルの割り当てに関するエラーの場合は、table_id でフィルタリングします。

たとえば次のクエリは、1 分で取り込まれる合計バイト数と割り当てエラーの総数を示します。

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-us`.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 時間のストリーミング トラフィックをモニタリングし、割り当てエラーを分析します。

  • 発生しているエラーが QUOTA_EXCEEDED ではなく主に RATE_LIMIT_EXCEEDED である場合、トラフィック全体が割り当ての 80% を下回ると、エラーで一時的な急増が示されることがあります。このようなエラーに対処するには、オペレーションを再試行します。その際、次の再試行の前に指数バックオフを行うようにします。

  • Dataflow ジョブを使用してデータを挿入する場合は、ストリーミング挿入ではなく、読み込みジョブの使用を検討してください。詳細については、挿入方法の設定をご覧ください。カスタム I/O コネクタで Dataflow を使用している場合は、代わりに組み込み I/O コネクタの使用を検討してください。詳細については、カスタム I/O パターンをご覧ください。

  • QUOTA_EXCEEDED エラーが発生した場合や、トラフィック全体が割り当ての 80% を常に超えている場合は、割り当ての引き上げをリクエストしてください。詳細については、割り当て上限の引き上げをリクエストするをご覧ください。

  • また、ストリーミング挿入を新しい Storage Write API に置き換えることも検討してください。この API は高スループット、低料金であり、多くの便利な機能があります。

CSV ファイル読み込みの割り当てエラー

bq load コマンドで --allow_quoted_newlines フラグを使用して大規模な CSV ファイルを読み込むと、このエラーが発生する可能性があります。

エラー メッセージ

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 にデータを読み込む際に適用される上限について詳しくは、読み込みジョブをご覧ください。

テーブルのインポートまたはクエリの追加の割り当てエラー

テーブルが標準テーブル オペレーション数の 1 日あたりの上限に達すると、BigQuery はこのエラー メッセージを返します。テーブル オペレーションには、宛先テーブルへのデータの追加または上書きを実行するすべての読み込みジョブ、コピージョブ、クエリジョブを合わせた合計数が含まれます。

1 日あたりのテーブル オペレーション数の上限値については、標準テーブルをご覧ください。

エラー メッセージ

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-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   #Adjust time
   WHERE creation_time BETWEEN "2021-06-20 00:00:00" AND "2021-06-21 00:00:00"
   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 に保存された複数の小さなファイルから頻繁にデータを読み込み、ファイルごとにジョブが使用される場合には、複数の読み込みジョブを結合して 1 つのジョブにします。カンマ区切りのリスト（例: gs://my_path/file_1,gs://my_path/file_2）を使用するか、ワイルドカード（例: gs://my_path/*）を使用すれば、複数の Cloud Storage URI から読み込むことができます。

  詳細については、データのバッチ読み込みをご覧ください。

• たとえば、読み込み、選択、コピーのジョブを使用して 1 行のデータをテーブルに追加する場合は、複数のジョブを 1 つのジョブでバッチ処理することを検討してください。BigQuery をリレーショナル データベースとして使用するとうまく動作しません。ベスト プラクティスとしては、単一行の追加アクションを頻繁に実行しないでください。
• 高頻度でデータを追加する場合は、BigQuery Storage Write API の使用を検討してください。これは、高パフォーマンスのデータ取り込みに推奨されるソリューションです。BigQuery Storage Write API には、1 回限りの配信セマンティクスなど、堅牢な機能が用意されています。上限と割り当てについては、Storage Write API をご覧ください。この API の使用料金については、BigQuery データの取り込み料金をご覧ください。
• テーブルで変更されたパーティションの数をモニタリングするには、INFORMATION_SCHEMA ビューを使用します。

テーブル メタデータ更新オペレーションの最大レートの上限エラー

BigQuery がテーブル メタデータ更新オペレーションの標準テーブルのテーブルあたりの最大レート上限に達すると、このエラーが返されます。テーブル オペレーションは、宛先テーブルへのデータの追加や上書き、DML の DELETE、INSERT、MERGE、TRUNCATE TABLE、または UPDATE ステートメントを使用したテーブルへのデータの書き込みを実行するすべての読み込みジョブ、コピージョブ、クエリジョブを合わせた合計数が対象です。

テーブルあたりのメタデータ更新オペレーションの最大レートの上限値を確認するには、標準テーブルをご覧ください。

エラー メッセージ

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

このエラーが発生した場合は、問題を診断し、推奨される手順を実施して解決します。

診断

メタデータ テーブルの更新は、テーブルのメタデータを変更する API 呼び出しやテーブルのコンテンツを変更するジョブで発生します。テーブルのメタデータに対するほとんどの更新オペレーションが発生している場所が特定されていない場合は、次の操作を行います。

• 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
#Adjust region
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
#Adjust time
WHERE creation_time BETWEEN "2021-06-21 10:00:00" AND "2021-06-21 20:00:00"
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 に保存された複数の小さなファイルから頻繁にデータを読み込み、ファイルごとにジョブが使用される場合には、複数の読み込みジョブを結合して 1 つのジョブにします。カンマ区切りのリスト（例: gs://my_path/file_1,gs://my_path/file_2）を使用するか、ワイルドカード（例: gs://my_path/*）を使用すれば、複数の Cloud Storage URI から読み込むことができます。

  詳細については、データのバッチ読み込みをご覧ください。

• たとえば、読み込み、選択、コピーのジョブを使用して 1 行のデータをテーブルに追加する場合は、複数のジョブを 1 つのジョブでバッチ処理することを検討してください。BigQuery をリレーショナル データベースとして使用するとうまく動作しません。ベスト プラクティスとしては、単一行の追加アクションを頻繁に実行しないでください。
• 高頻度でデータを追加する場合は、BigQuery Storage Write API の使用を検討してください。これは、高パフォーマンスのデータ取り込みに推奨されるソリューションです。BigQuery Storage Write API には、1 回限りの配信セマンティクスなど、堅牢な機能が用意されています。上限と割り当てについては、Storage Write API をご覧ください。この API の使用料金については、BigQuery データの取り込み料金をご覧ください。
• テーブルで変更されたパーティションの数をモニタリングするには、INFORMATION_SCHEMA ビューを使用します。

API リクエストの最大数の上限エラー

BigQuery では、サービス アカウントからの tables.get メソッドの呼び出しや、別のユーザーのメールアドレスからの jobs.insert メソッドの呼び出しなど、メソッド、ユーザーごとの BigQuery API に対する API リクエスト数のレート上限に達すると、BigQuery がこのエラーを返します。詳細については、すべての BigQuery API の メソッド、ユーザーごとの 1 秒あたりの最大 API リクエストの最大数のレート上限をご覧ください。

注: BigQuery API のレート上限は、ストリーミング挿入の API リクエストには適用されません。

エラー メッセージ

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

このエラーが発生した場合は、問題を診断し、推奨される手順を実施して解決します。

診断

このレート上限に達したメソッドが特定されていない場合は、次の操作を行います。

サービス アカウントの場合

1. サービス アカウントをホストするプロジェクトに移動します。

2. Google Cloud コンソールで [API ダッシュボード] に移動します。

   API の詳細な使用状況に関する情報を表示する手順については、API ダッシュボードの使用をご覧ください。

3. API ダッシュボードで [BigQuery API] を選択します。

4. 使用状況に関する情報をさらに詳しく表示するには、[指標] を選択して、次のようにします。

   1. [グラフを選択] で [API メソッド別のトラフィック量] を選択します。

   2. サービス アカウントの認証情報でグラフをフィルタします。エラーに気付いた期間中にメソッドの急増が見られる場合があります。

API 呼び出しの場合

一部の API 呼び出しのエラーは、Cloud Logging の BigQuery 監査ログに記録されます。上限に達したメソッドを特定するには、次の操作を行います。

1. Google Cloud コンソールで、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 の料金をご覧ください。

• BigQuery I/O コネクタで Dataflow を使用して BigQuery にデータを読み込んでいる間に、tables.get メソッドで次のエラーが発生することがあります。この問題を解決するには、次の操作を行います。

  • 宛先テーブルの create disposition を CREATE_NEVER に設定します。詳細については、Create disposition をご覧ください。

  • Apache Beam SDK バージョン 2.24.0 以降を使用する。以前のバージョンの SDK では、CREATE_IF_NEEDED 処理は tables.get メソッドを呼び出して、テーブルが存在するかどうかを確認します。

• 割り当ての増加をリクエストするには、サポートまたは営業担当者にお問い合わせください。追加の割り当てについては、割り当ての増加をリクエストするをご覧ください。割り当て量の増加のリクエストは、処理に数日かかることがあります。リクエストの際には詳細情報として、ジョブの優先順位、クエリを実行するユーザー、影響を受けるメソッドの情報を提供することをおすすめします。

プロジェクトで無料のクエリバイト数に対する割り当てを超過した

BigQuery は、無料使用枠でクエリを実行中に、アカウントがクエリ可能なデータサイズの月間の上限に達すると、このエラーを返します。クエリ（分析）について詳しくは、無料枠をご覧ください。

エラー メッセージ

Your project exceeded quota for free query bytes scanned

解決策

BigQuery を引き続き使用するには、アカウントを有料の Cloud 請求先アカウントにアップグレードする必要があります。

プロジェクトの割り当てエラーごとに 1 秒あたり最大 tabledata.list バイト

エラー メッセージに記載されているプロジェクト番号が、tabledata.list API 呼び出しでプロジェクトあたり 1 秒間に読み取り可能なデータの最大サイズに到達すると、BigQuery がこのエラーを返します。詳細については、1 分あたりの最大 tabledata.list バイト数をご覧ください。

エラー メッセージ

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

解決策

このエラーを解決するには、次の手順を行います。

• 通常は、この上限を超えないようにすることをおすすめします。たとえば、遅延を発生させながら長期間にわたってリクエストを並べることで。エラーが頻繁に発生しない場合は、指数バックオフによる再試行を実装することでこの問題は解決されます。
• ユースケースでテーブルから大量のデータを高速かつ頻繁に読み込むことが予想される場合、tabledata.list API ではなく BigQuery Storage Read API を使用することをおすすめします。

• 上述の推奨事項が機能しない場合は、Google Cloud コンソール API のダッシュボードから割り当ての増加をリクエストできます。手順は次のとおりです。

  1. Google Cloud コンソール API のダッシュボードに移動します。
  2. ダッシュボードで、「割り当て: Tabledata list bytes per minute (default quota)」でフィルタします。
  3. 割り当てを選択して、割り当て上限の引き上げをリクエストするの手順に沿って操作してください。

  リクエストを確認して処理するのに数日を要する場合があります。

テーブルに対して過剰な数の未処理の DML ステートメントが存在する

このエラーは、同じテーブルに対して実行される同時変更 DML ステートメント（UPDATE、DELETE、MERGE）の数が、データ操作言語（DML）の割り当て上限を超過したことを意味します。この割り当て上限はテーブルごとであり、INSERT を含まない変更 DML にのみ適用されます。

解決策

DML ステートメントのベスト プラクティスに沿って DML ジョブをバッチ処理する。

プロジェクトごとに割り当てられる 1 日あたりのコピージョブの最大数のエラー

プロジェクト内で実行されているコピージョブの数が 1 日あたりの上限を超えると、BigQuery はこのエラーを返します。1 日あたりのコピージョブ数の上限について詳しくは、コピージョブをご覧ください。

エラー メッセージ

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_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

  REGION_NAME の部分は、region- 接頭辞を含むリージョン名に置き換える必要があります。例: region-us、region-asia-south1。対象の期間に応じて時間間隔を調整することもできます。
• すべてのリージョンのすべてのコピージョブを表示するには、Cloud Logging で次のフィルタを使用します。

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

解決策

• 頻繁なコピー オペレーションがデータのスナップショット作成を目的としている場合は、代わりにテーブル スナップショットの使用を検討してください。テーブル スナップショットは、テーブル全体をコピーするよりも低コストで高速です。
• 割り当ての増加をリクエストするには、サポートまたは営業担当者にお問い合わせください。リクエストを確認して処理するのに数日を要する場合があります。リクエストには、優先度、ユースケース、プロジェクト ID を記載することをおすすめします。

リモート関数を含む同時実行クエリの最大数

リモート関数を含む同時実行クエリの数が上限を超えると、BigQuery がこのエラーを返します。

リモート関数の上限について詳しくは、リモート関数をご覧ください。

エラー メッセージ

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

診断

リモート関数を含む同時実行クエリの上限については、リモート関数の上限をご覧ください。

解決策

• リモート関数を使用する場合は、リモート関数のベスト プラクティスを遵守してください。
• 割り当ての増加をリクエストするには、サポートまたは営業担当者にお問い合わせください。リクエストを確認して処理するのに数日を要する場合があります。リクエストには、優先度、ユースケース、プロジェクト ID を記載することをおすすめします。

シャッフル サイズの上限エラー

プロジェクトでシャッフル オペレーションに使用できるディスクとメモリの最大サイズの上限を超えると、BigQuery からこのエラーが返されます。

この割り当ては予約ごとに計算され、予約のためにプロジェクト間でスライスされます。Cloud カスタマーケアでは割り当てを変更できません。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.

解決策

このエラーを解決するには、次の手順を行います。

• 予約を増やす
• クエリを最適化する
• クエリの同時実行を減らすか、中間結果を実体化して、リソースへの依存を軽減します。詳細については、クエリキューとマテリアライズド ビューを作成するをご覧ください。

CREATE MODEL ステートメントの最大数

このエラーは、CREATE MODEL ステートメントの割り当てを超えたことを示します。

エラー メッセージ

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

解決策

CREATE MODEL ステートメントの割り当てを超えた場合は、割り当ての増加をリクエストしてください。