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

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

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

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 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 クエリをご覧ください。

引き上げ可能な割り当てまたは上限のトラブルシューティング

次の割り当てと上限は引き上げることができますが、まず、推奨される回避策やベストプラクティスを試すことをおすすめします。

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

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

エラーメッセージ

Your project exceeded quota for free query bytes scanned

解決策

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

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

このセクションでは、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-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 時間のストリーミングトラフィックをモニタリングし、割り当てエラーを分析します。
- 発生しているエラーが QUOTA_EXCEEDED ではなく主に RATE_LIMIT_EXCEEDED である場合、トラフィック全体が割り当ての 80% を下回ると、エラーで一時的な急増が示されることがあります。このようなエラーに対処するには、オペレーションを再試行します。その際、次の再試行の前に指数バックオフを行うようにします。
- Dataflow ジョブを使用してデータを挿入する場合は、ストリーミング挿入ではなく、読み込みジョブの使用を検討してください。詳細については、挿入方法の設定をご覧ください。カスタム I/O コネクタで Dataflow を使用している場合は、代わりに組み込み 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

診断

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

解決策

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

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

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

エラーメッセージ

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

解決策

CREATE MODEL ステートメントの割り当てを超えた場合は、bqml-feedback@google.com にメールを送信し、割り当ての増加をリクエストしてください。

プロジェクトごとに割り当てられる 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-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 を記載することをおすすめします。

1 日あたりの抽出バイト数の割り当て超過エラー

抽出がプロジェクトのデフォルトの 1 日あたりの上限である 50 TiB を超えると、BigQuery はこのエラーを返します。抽出ジョブの上限の詳細については、抽出ジョブをご覧ください。

エラーメッセージ

Your usage exceeded quota for ExtractBytesPerDay

診断

50 TiB を超えるテーブルをエクスポートすると、抽出の上限を超えるため、エクスポートは失敗します。この問題を回避するには、解決策をご覧ください。特定のテーブルパーティションのテーブルデータをエクスポートする場合は、パーティションデコレータを使用して、エクスポートするパーティションを指定できます。

直近数日間のエクスポートデータの使用状況を収集するには、次の方法を試してください。

Name: Extract bytes per day や Metric: bigquery.googleapis.com/quota/extract/bytes などのフィルタ条件を使用してプロジェクトの割り当てを表示し、[使用状況を表示] グラフで数日間の使用状況の傾向を確認します。

または、INFORMATION_SCHEMA.JOBS_BY_PROJECT をクエリして、数日間の抽出バイト数の合計を確認することもできます。たとえば、次のクエリは、過去 7 日間に EXTRACT ジョブによって処理された 1 日あたりの合計バイト数を返します。

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

想定よりも多くのバイト数を使用している特定のジョブを明確にすることで、結果をさらに絞り込むことができます。次の例では、過去 7 日間に処理された 100 GB を超える EXTRACT ジョブの上位 100 件を返します。

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 などのフィルタとともにジョブエクスプローラを使用して、指定した期間の処理負荷の高いジョブをフィルタ処理することもできます。

解決策

この割り当てエラーを解決する方法の 1 つは、スロット予約を作成し、PIPELINE ジョブタイプを使用して、プロジェクトを予約に割り当てることです。ここでは、無料の共有スロットプールではなく専用の予約を使用するため、上限チェックを回避できます。必要に応じて、後で共有スロットプールを使用する場合は予約を削除できます。

50 TiB を超えるエクスポートを可能にする代替アプローチについては、抽出ジョブの注記セクションをご覧ください。

プロジェクトの割り当てエラーごとに 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. 割り当てを選択して、割り当ての調整をリクエストするの手順に沿って操作してください。
リクエストを確認して処理するのに数日を要する場合があります。

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

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

エラーメッセージ

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

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

診断

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

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

サービスアカウントをホストするプロジェクトに移動します。
Google Cloud コンソールで、[API ダッシュボード] に移動します。

API の詳細な使用状況に関する情報を表示する手順については、API ダッシュボードの使用をご覧ください。
API ダッシュボードで [BigQuery API] を選択します。
使用状況に関する情報をさらに詳しく表示するには、[指標] を選択して、次のようにします。
1. [グラフを選択] で [API メソッド別のトラフィック量] を選択します。
2. サービスアカウントの認証情報でグラフをフィルタします。エラーに気付いた期間中にメソッドの急増が見られる場合があります。

API 呼び出しの場合

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

Google Cloud コンソールで、 Google Cloud ナビゲーションメニューに移動し、プロジェクトの [ロギング] > [ログエクスプローラ] を選択します。

ログエクスプローラに移動

次のクエリを実行して、ログをフィルタします。

 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 メソッドを呼び出して、テーブルが存在するかどうかを確認します。
割り当ての増加をリクエストするには、サポートまたは営業担当者にお問い合わせください。追加の割り当てについては、割り当ての増加をリクエストするをご覧ください。割り当て量の増加のリクエストは、処理に数日かかることがあります。リクエストの際には詳細情報として、ジョブの優先順位、クエリを実行するユーザー、影響を受けるメソッドの情報を提供することをおすすめします。

引き上げられない割り当てまたは上限のトラブルシューティング

次の割り当てまたは上限を引き上げることはできませんが、提案された回避策またはベストプラクティスを適用して緩和することはできます。

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

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

エラーメッセージ

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 では結果セットを計算する必要がないため、キャッシュに保存された結果を使用するクエリは、キャッシュに保存された結果を使用しないクエリよりも実行速度が大幅に上昇します。

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

プロジェクトでシャッフルオペレーションに使用できるディスクとメモリの最大サイズの上限を超えると、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.

解決策

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

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

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

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

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

エラーメッセージ

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

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

診断

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

API 呼び出しを特定する。
ジョブを特定する。

API 呼び出しを特定する

Google Cloud ナビゲーションメニューに移動し、[ロギング>ログエクスプローラ] を選択します。

ログエクスプローラに移動

ログをフィルタリングしてテーブルオペレーションを表示するには、次のクエリを実行します。

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")

ジョブを特定する

次のクエリは、過去 1 日以内のプロジェクトで影響を受けるテーブルを変更するジョブのリストを返します。組織内の複数のプロジェクトがテーブルに書き込むことを想定する場合は、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 に保存された複数の小さなファイルから頻繁にデータを読み込み、ファイルごとにジョブが使用される場合には、複数の読み込みジョブを結合して 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 ビューを使用します。

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

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

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

エラーメッセージ

Your table exceeded quota for imports or query appends per table

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

診断

ほとんどのテーブルオペレーションが発生している場所が特定されていない場合は、次の操作を行います。

失敗したクエリ、読み込み、またはコピージョブが書き込まれるプロジェクト、データセット、テーブルをメモしておきます。
テーブルを変更するジョブの詳細を確認するには、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 に保存された複数の小さなファイルから頻繁にデータを読み込み、ファイルごとにジョブが使用される場合には、複数の読み込みジョブを結合して 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 ビューを使用します。

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

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

解決策

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

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

ユーザーが同時 `project.lists` リクエストの割り当てを超えました

このエラーは、Simba ODBC ドライバまたは DataHub を介して BigQuery と通信する Microsoft Power BI ジョブが project.list API の上限を超えたために失敗した場合に発生します。この問題を解決するには、このセクションで説明する短期的な回避策または長期的な回避策を使用します。

エラーメッセージ

Your user exceeded quota for concurrent project.lists requests

診断

このエラーは、Power BI レポートが更新され、Simba ドライバが特定の BigQuery プロジェクトへの接続を確立するときに、Power BI の接続と検出のフェーズで発生します。

短期的な解決策

この問題に短期的に対処するには、次の回避策を使用します。回避策は、効果の高い順に並んでいます。Simba ドライバまたは DataHub を使用して BigQuery に接続するかどうかに応じて、修正 3 または 4 を実装します。

長期的な解決策については、長期的な解決策をご覧ください。

レポートの更新をずらす。DSN を変更できない場合は、同時リクエストの数を減らして割り当ての問題を軽減します。すべてのレポートが同時に更新される（午前 9 時など）のではなく、スケジュールを数分ずらします（午前 9 時 1 分、午前 9 時 3 分、午前 9 時 5 分など）。この方法では、API 呼び出しが時間とともに分散されるため、同時実行上限に達する可能性が低くなります。
Power BI で再試行を実装します。このリアクティブ戦略は、レポートが一時的な障害から復旧するのに役立ちます。Power BI には、データ更新の失敗に対する再試行ロジックが組み込まれています。この方法では割り当てエラーを防ぐことはできませんが、API 呼び出しの最初の急増が収まった後でレポートを再試行することで、パイプラインの復元力を高めることができます。この修正を実装する手順は次のとおりです。
1. Power BI サービスで、データセットの [設定] に移動します。
2. [スケジュール設定された更新] セクションを開きます。[再試行] で、失敗した更新を自動的に再実行するように Power BI を構成します。
Simba ドライバの以前のバージョンでは、ODBC 接続でプロジェクト ID を指定します。このアクションにより、ドライバは projects.list 検出呼び出しを実行できなくなります。代わりに、ドライバは指定されたプロジェクトに直接接続するため、不要な API 呼び出しが回避され、割り当ての問題が解決されます。

新しいドライバは、プロジェクトが指定されていない場合、Unable to establish connection with data source. Missing settings: {[Catalog]} のようなメッセージが表示されてすぐに失敗します。

この問題を解決するには、次の操作を行います。
1. Power BI ゲートウェイまたは Power BI Desktop を実行しているマシンで、ODBC データソース（64 ビット）アプリケーションを開きます。
2. BigQuery 用 Simba ODBC ドライバのメイン設定画面で、[カタログ（プロジェクト）] フィールドに特定の Google Cloud プロジェクト ID（例: my-gcp-project-id）を入力します。
以前のバージョンの DataHub の場合は、DataHub 取り込み構成でプロジェクト ID を指定します。Simba ドライバではなく DataHub を使用している場合は、この修正を行います。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: 準備

Power BI ゲートウェイと DataHub 構成のオーナーに、進行中のジョブの失敗を解決するために調整された変更を行うことを通知します。
Google Cloud コンソールで、2 つの新しいサービスアカウント（sa-powerbi-gateway@... や sa-datahub-ingestion@... など）を作成します。
Power BI サービスアカウントと DataHub サービスアカウントのサービスアカウントキーを作成します。
関連する Identity and Access Management（IAM）でタスクを実行できるようにする次の Identity and Access Management ロールを割り当てて、各新しいサービスアカウントに最小権限を付与します。ProjectEditor など、広すぎるロールの割り当ては避けます。

必要なロール

Power BI のサービスアカウントは、クエリを実行し、テーブルからデータを読み取ります。Power BI がアクセスする必要があるデータを含む各 Google Cloud プロジェクトのサービスアカウントに、次のロールを付与します。これらのロールの詳細については、BigQuery のロールをご覧ください。

BigQuery データ閲覧者: データセット、テーブル、ビューへの読み取り専用アクセスを提供します。
BigQuery ジョブユーザー: クエリなどのジョブを実行する権限を付与します。これは、Power BI がリクエストを実行するために不可欠です。

DataHub 取り込みのサービスアカウントは、テーブル内のデータではなく、テーブル名、スキーマ、説明などのメタデータを読み取るだけで済みます。DataHub がスキャンする各プロジェクトに対して、プロジェクトレベルで次のロールを付与します。これらのロールの詳細については、BigQuery の IAM ロールをご覧ください。

BigQuery メタデータ閲覧者: このロールは、メタデータの読み取り専用に設計されています。基盤となるデータへのアクセス権を付与せずに、データセットとテーブルを一覧表示し、そのメタデータを表示する権限を付与します。

フェーズ 2: 調整されたロールアウト

使用率の低い期間に、Power BI 管理者は次の手順でゲートウェイマシンの ODBC DSN 構成を更新します。

認証方法を、前の手順で作成した新しい sa-powerbi-gateway@... サービスアカウントキーを使用するように変更します。
短期的な修正としてまだ実行されていない場合は、ODBC ドライバの [カタログ（プロジェクト）] フィールドに Google Cloudプロジェクト ID を入力します。
DataHub のオーナーに BigQuery ソース構成 YAML ファイルを更新してもらいます。
前の手順で作成した新しい sa-datahub-ingestion@... サービスアカウントキーを指します。
短期的な修正としてまだ実行されていない場合は、project_ids パラメータを使用して、スキャンするプロジェクトを明示的にリストします。
新しい構成で DataHub 取り込みレシピを再デプロイします。

フェーズ 3: 検証とモニタリング

修正の効果を確認してモニタリングするには、Power BI 管理者と DataHub 管理者が次の手順を行います。

いくつかの重要な Power BI レポートと DataHub の新しい取り込み実行の更新を手動でトリガーします。これらのジョブが割り当てエラーを発生させることなく正常に完了することを確認します。
Google Cloud コンソールで、[IAM と管理] > [割り当て] ページに移動します。
BigQuery API サービスでフィルタします。
[Concurrent project.lists requests] という割り当てを見つけて、グラフアイコンをクリックして使用状況の推移を表示します。

管理者は、この特定の API 呼び出しの使用量が大幅に減少し、修正が成功したことを確認できます。

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

概要

診断

引き上げ可能な割り当てまたは上限のトラブルシューティング

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

解決策

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

診断

解決策

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

診断

解決策

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

解決策

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

診断

解決策

1 日あたりの抽出バイト数の割り当て超過エラー

診断

解決策

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

解決策

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

診断

解決策

引き上げられない割り当てまたは上限のトラブルシューティング

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

解決策

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

解決策

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

解決策

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

診断

API 呼び出しを特定する

ジョブを特定する

解決策

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

診断

解決策

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

解決策

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

解決策

ユーザーが同時 project.lists リクエストの割り当てを超えました

診断

短期的な解決策

長期的な解決策

フェーズ 1: 準備

必要なロール

フェーズ 2: 調整されたロールアウト

フェーズ 3: 検証とモニタリング

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

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

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

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

ユーザーが同時 `project.lists` リクエストの割り当てを超えました