費用の見積もりと管理

このページでは、BigQuery での費用の見積りと管理のベスト プラクティスについて説明します。

BigQuery の主な費用は、クエリ処理に使用されるコンピューティングと、BigQuery に保存されるデータのストレージです。BigQuery には、クエリ処理用のオンデマンドと容量ベースの 2 種類の料金モデルがあります。各モデルで、費用管理に関するベスト プラクティスは異なります。BigQuery に保存されているデータの場合、費用は各データセットに構成されたストレージ課金モデルによって異なります。

BigQuery のコンピューティング料金について

BigQuery のコンピューティング料金には、容量計画と費用管理に影響する微妙な違いがあります。

料金モデル

BigQuery のオンデマンド コンピューティングの場合、BigQuery クエリに対して TiB あたりの料金が発生します。

一方、BigQuery の容量コンピューティングでは、クエリの処理に使用されるコンピューティング リソース（スロット）に対して料金が発生します。このモデルを使用するには、スロットの予約を構成します。

予約には次の機能があります。

  • スロットのプールで割り当てられ、組織にとって有益な方法で容量を管理し、ワークロードを分離できます。
  • 1 つの管理プロジェクトに存在する必要があり、割り当てと上限が適用されます。

容量ベースの料金モデルには、いくつかのエディションがあります。いずれも、スロット時間単位で課金される従量課金制オプションが用意されています。Enterprise エディションと Enterprise Plus エディションでは、1 年または 3 年のスロット コミットメントもオプションで提供されており、従量課金制の料金よりも費用を節約できます。

また、従量課金制オプションを使用して自動スケーリング予約を設定することもできます。詳しくは次の記事をご覧ください。

モデルごとに費用を制限する

オンデマンド料金モデルを使用する場合、費用を制限する唯一の方法は、プロジェクト レベルまたはユーザーレベルの 1 日あたりの割り当てを構成することです。ただし、これらの割り当てにはハードキャップが適用され、ユーザーが割り当て上限を超えるクエリを実行できなくなります。割り当てを設定するには、カスタムクエリの割り当てを作成するをご覧ください。

スロット予約を使用して定額料金モデルを使用する場合は、予約で使用できるスロットの最大数を指定します。確約期間中は割引価格で利用できるスロット コミットメントを購入することもできます。

エディションを完全にオンデマンドで使用するには、予約のベースラインを 0 に設定し、最大値をワークロードのニーズを満たす設定にします。BigQuery は、ワークロードに必要なスロット数まで自動的にスケールアップします。設定した最大数を超えることはありません。詳細については、予約を使用したワークロード管理をご覧ください。

クエリ費用を管理する

個々のクエリの費用を抑えるには、まずクエリ計算の最適化とストレージの最適化のベスト プラクティスに沿うことをおすすめします。

以降のセクションでは、クエリ費用をさらに抑えるために使用できるその他のベスト プラクティスについて説明します。

カスタムのクエリ割り当てを作成する

ベスト プラクティス: 1 日あたりのカスタムのクエリ割り当てを使用して、1 日に処理されるデータの量を制限します。

プロジェクトまたはユーザーあたりの 1 日あたりの処理データ量の上限を指定するカスタム割り当てを設定することで、費用を管理できます。割り当てに達すると、ユーザーはクエリを実行できなくなります。

カスタム割り当てを設定するには、特定のロールまたは権限が必要です。設定する割り当てについては、割り当てと上限をご覧ください。

詳細については、各料金モデルの費用を制限するをご覧ください。

クエリを実行する前に見積もり費用を確認する

ベスト プラクティス: クエリを実行する前に、プレビューして費用を見積もります。

オンデマンド料金モデルを使用する場合、クエリは読み取られたバイト数に基づいて課金されます。クエリを実行する前に費用を見積もるには:

クエリ検証ツールを使用する

Google Cloud コンソールでクエリを入力すると、クエリ検証ツールがクエリ構文を検証し、読み取られるバイト数を見積もります。この見積もりを使用して、料金計算ツールでクエリ費用を計算できます。

  • クエリが無効な場合は、クエリ検証ツールにエラー メッセージが表示されます。例:

    Not found: Table myProject:myDataset.myTable was not found in location US

  • クエリが有効な場合は、クエリ検証ツールによりクエリ処理に必要なバイト数の見積もりが提供されます。次に例を示します。

    This query will process 623.1 KiB when run.

ドライランの実行

ドライランを実行するには、次の操作を行います。

コンソール

  1. BigQuery ページに移動します。

    BigQuery に移動

  2. クエリエディタにクエリを入力します。

    クエリが有効な場合、クエリで処理されるデータの量とともにチェックマークが自動的に表示されます。クエリが無効な場合は、感嘆符がエラー メッセージとともに表示されます。

bq

--dry_run フラグを使用して次のようなクエリを入力します。

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'

有効なクエリの場合、このコマンドによって次のレスポンスが生成されます。

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

API

API を使用してドライランを実行するには、JobConfiguration タイプで dryRun を true に設定してクエリジョブを送信します。

Go

このサンプルを試す前に、クライアント ライブラリを使用した BigQuery クイックスタートにある Go の設定手順を完了してください。詳細については、BigQuery Go API のリファレンス ドキュメントをご覧ください。

BigQuery に対する認証を行うには、アプリケーションのデフォルト認証情報を設定します。詳細については、クライアント ライブラリの認証情報を設定するをご覧ください。

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

このサンプルを試す前に、クライアント ライブラリを使用した BigQuery クイックスタートにある Java の設定手順を完了してください。詳細については、BigQuery Java API のリファレンス ドキュメントをご覧ください。

BigQuery に対する認証を行うには、アプリケーションのデフォルト認証情報を設定します。詳細については、クライアント ライブラリの認証情報を設定するをご覧ください。

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

このサンプルを試す前に、クライアント ライブラリを使用した BigQuery クイックスタートにある Node.js の設定手順を完了してください。詳細については、BigQuery Node.js API のリファレンス ドキュメントをご覧ください。

BigQuery に対する認証を行うには、アプリケーションのデフォルト認証情報を設定します。詳細については、クライアント ライブラリの認証情報を設定するをご覧ください。

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

PHP

このサンプルを試す前に、クライアント ライブラリを使用した BigQuery クイックスタートにある PHP の設定手順を完了してください。詳細については、BigQuery PHP API のリファレンス ドキュメントをご覧ください。

BigQuery に対する認証を行うには、アプリケーションのデフォルト認証情報を設定します。詳細については、クライアント ライブラリの認証情報を設定するをご覧ください。

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

Python

QueryJobConfig.dry_run プロパティを True に設定します。ドライランのクエリ構成が渡されると、Client.query() は常に完了した QueryJob を返します。

このサンプルを試す前に、クライアント ライブラリを使用した BigQuery クイックスタートにある Python の設定手順を完了してください。詳細については、BigQuery Python API のリファレンス ドキュメントをご覧ください。

BigQuery に対する認証を行うには、アプリケーションのデフォルト認証情報を設定します。詳細については、クライアント ライブラリの認証情報を設定するをご覧ください。

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

クエリの費用を見積もる

オンデマンド料金モデルを使用している場合は、処理されるバイト数を計算することで、クエリの実行費用を見積もることができます。

オンデマンド クエリのサイズの計算

さまざまなタイプのクエリで処理されるバイト数を計算するには、以降のセクションをご覧ください。

テーブルデータを探索するためにクエリを実行しない

ベスト プラクティス: テーブルデータを探索またはプレビューするためにクエリを実行しないでください。

データの試用や探索を行う場合は、テーブル プレビュー オプションを使用すれば、割り当てに影響を与えることなく、無料でデータを表示できます。

BigQuery は、次のデータ プレビュー オプションをサポートしています。

  • Google Cloud コンソールのテーブルの詳細ページで、[プレビュー] タブをクリックしてデータをサンプリングします。
  • bq コマンドライン ツールで bq head コマンドを使用して、プレビューする行数を指定する。
  • API で tabledata.list を使用して、指定した行のセットからテーブルデータを取得する。
  • クラスタ化されていないテーブルでは LIMIT を使用しない。クラスタ化されていないテーブルの場合は、LIMIT 句によってコンピューティング費用が削減されません。

クエリあたりの課金対象バイト数を制限する

ベスト プラクティス: オンデマンド料金モデルを使用する場合は、課金される最大バイト数を設定してクエリ費用を抑えます。

課金されるクエリのバイト数を制限するには、課金される最大バイト数の設定を使用します。この設定を行うと、クエリが実行される前に、クエリで読み取られるバイト数が推定されます。推定バイト数が上限を超えると、クエリが失敗し、料金は発生しません。

クラスタ化テーブルの場合、クエリに対して課金されるバイト数の推定値は上限値になります。クエリ実行後に請求される実際のバイト数より高くなることがあります。そのため、課金対象の最大バイト数を設定すると、課金される実際のバイト数が課金対象の最大バイト数を超えなくても、クラスタ化テーブルに対するクエリが失敗する場合があります。

課金される最大バイト数を設定したことによってクエリが失敗した場合は、次のようなエラーが返されます。

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

課金される最大バイト数を設定するには:

コンソール

  1. クエリエディタで、[展開] > [クエリ設定] > [詳細オプション] の順にクリックします。
  2. [課金される最大バイト数] フィールドに整数を入力します。
  3. [保存] をクリックします。

bq

bq query コマンドを使用し、--maximum_bytes_billed フラグを指定します。

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

API

JobConfigurationQuery または QueryRequest で maximumBytesBilled プロパティを設定します。

クラスタ化されていないテーブルでは LIMIT を使用しない

おすすめの方法: クラスタ化されていないテーブルでは、費用を管理する手法として LIMIT 句を使用しないでください。

クラスタ化されていないテーブルの場合、LIMIT 句をクエリに適用しても、読み取られるデータの量には影響しません。クエリがサブセットのみを返す場合でも、クエリで示されているテーブル全体のすべてのバイトの読み取りに対して課金されます。クラスタ化テーブルでは、結果を取得するために十分なブロックがスキャンされるとスキャンが停止するため、LIMIT 句でスキャンできるバイト数を減らすことができます。スキャンされたバイトに対してのみ課金されます。

クエリ結果を段階的に実体化する

おすすめの方法: 可能であれば、クエリ結果を段階的に実体化します。

大容量のマルチステージ クエリを作成すると、それを実行するたびに、BigQuery がそのクエリに必要なすべてのデータを読み取ります。クエリが実行されるたびに読み取られるすべてのデータに対して課金されます。

代わりに、クエリを複数のステージに分割し、各ステージでクエリ結果を宛先テーブルに書き込むことにより実体化します。小容量の宛先テーブルを照会することにより、読み取られるデータの量が削減され、費用が削減されます。実体化された結果を保存する費用は、大量のデータを処理する費用よりはるかに少なくなります。

ワークロードの費用を管理する

このセクションでは、ワークロード内で費用を抑えるためのベスト プラクティスについて説明します。ワークロードは関連する一連のクエリです。たとえば、ワークロードには、毎日実行されるデータ変換パイプライン、ビジネス アナリストのグループによって実行される一連のダッシュボード、データ サイエンティストのグループによって実行される複数のアドホック クエリなどがあります。

Google Cloud 料金計算ツールを使用する。

ベスト プラクティス: Google Cloud 料金計算ツールを使用して、予想使用量に基づいて BigQuery の 1 か月の費用の見積もりを作成します。この見積もりを実際の費用と比較して、最適化の対象となる領域を特定できます。

オンデマンド

オンデマンド料金モデルを使用している場合に Google Cloud 料金計算ツールで費用を見積もる手順は、次のとおりです。

  1. Google Cloud 料金計算ツールを開きます。
  2. [Add To Estimate] をクリックします。
  3. [BigQuery] を選択します。
  4. [サービスタイプ] で [オンデマンド] を選択します。
  5. クエリを実行するロケーションを選択します。
  6. [クエリされたデータ量] に、ドライランまたはクエリ検証ツールから返された推定読み取りバイト数を入力します。
  7. アクティブ ストレージ、長期ストレージ、ストリーミング挿入、ストリーミング読み取りの推定ストレージ使用量を入力します。データセット ストレージの課金モデルに応じて、物理ストレージまたは論理ストレージのいずれかを推定する必要があります。
  8. 見積もりは [費用の詳細] パネルに表示されます。推定費用の詳細を確認するには、[詳細ビューを開く] をクリックします。費用見積もりをダウンロードして共有することもできます。

詳しくは、オンデマンド料金をご覧ください。

エディション

BigQuery エディションで容量ベースの料金モデルを使用している場合に、Google Cloud 料金計算ツールで費用を見積もる手順は次のとおりです。

  1. Google Cloud 料金計算ツールを開きます。
  2. [Add To Estimate] をクリックします。
  3. [BigQuery] を選択します。
  4. [サービスタイプ] で [エディション] を選択します。
  5. スロットを使用するロケーションを選択します。
  6. ご使用のエディションを選択します。
  7. [Maximum slots]、[Baseline slots]、[Commitment]、[Estimated utilization of autoscaling] で該当する値を選択します。
  8. データを保存するロケーションを選択します。
  9. アクティブ ストレージ、長期ストレージ、ストリーミング挿入、ストリーミング読み取りの推定ストレージ使用量を入力します。データセット ストレージの課金モデルに応じて、物理ストレージまたは論理ストレージのいずれかを推定する必要があります。
  10. 見積もりは [費用の詳細] パネルに表示されます。推定費用の詳細を確認するには、[詳細ビューを開く] をクリックします。費用見積もりをダウンロードして共有することもできます。

詳細については、容量ベースの料金をご覧ください。

予約とコミットメントを使用する

ベスト プラクティス: BigQuery の予約とコミットメントを使用して費用を管理します。

詳細については、各料金モデルの費用を制限するをご覧ください。

スロット見積もりツールを使用する

ベスト プラクティス: スロット見積もりツールを使用して、ワークロードに必要なスロット数を見積もります。

BigQuery スロット見積もりツールを使用すると、過去のパフォーマンス指標に基づいてスロット容量を管理できます。

また、オンデマンド料金モデルを使用しているお客様は、容量ベースの料金に移行する際に、同様のパフォーマンスのコミットメントと自動スケーリングの予約のサイズ設定に関する推奨事項を確認できます。

不要な長時間実行ジョブをキャンセルする

容量を解放するには、長時間実行ジョブが実行を続行する必要があるかどうかを確認します。必要ない場合は、キャンセルします。

ダッシュボードを使用して費用を表示する

ベスト プラクティス: BigQuery の使用量をモニタリングして調整できるように、Cloud Billing データを分析するダッシュボードを作成します。

課金データを BigQuery にエクスポートして、Looker Studio などのツールで可視化できます。課金ダッシュボードの作成方法のチュートリアルについては、BigQuery と Looker Studio を使用した Google Cloud 課金の可視化をご覧ください。

課金の予算とアラートを使用する

ベスト プラクティス: Cloud Billing 課金の予算を使用して、BigQuery の料金を 1 か所でモニタリングします。

Cloud Billing の予算を使用すると、実際の費用を予定費用と照らし合わせて追跡できます。予算額を設定したら、メール通知のトリガーに使用する予算アラートしきい値のルールを設定します。予算アラートのメールにより、予算に対する BigQuery 費用の追跡に関する最新情報を常に取得できます。

ストレージ費用を管理する

BigQuery ストレージの費用を最適化するには、次のベスト プラクティスを使用します。クエリ パフォーマンスのストレージを最適化することもできます。

長期ストレージを使用する

ベスト プラクティス: 長期ストレージの料金を使用して、古いデータの費用を削減します。

BigQuery ストレージにデータを読み込むと、そのデータには BigQuery のストレージ料金が適用されます。古いデータの場合は、BigQuery の長期保存の料金を自動的に利用できます。

90 日間連続して変更されていないテーブルがある場合、そのテーブルのストレージ料金は自動的に 50% 減少します。パーティション分割テーブルがある場合、各パーティションは、パーティション分割されていないテーブルと同じルールに従って、長期料金の対象となるかどうか個別に検討されます。

ストレージの課金モデルを構成する

ベスト プラクティス: 使用パターンに基づいてストレージの課金モデルを最適化します。

BigQuery は、論理バイト（非圧縮）、物理バイト（圧縮）、またはその両方の組み合わせによるストレージ課金をサポートしています。各データセットに構成されたストレージ課金モデルによってストレージの料金が変化しますが、クエリのパフォーマンスには影響しません。

INFORMATION_SCHEMA ビューを使用すると、使用パターンに基づいて最適なストレージ課金モデルを特定できます。

テーブルの上書きを避ける

ベスト プラクティス: 物理ストレージの課金モデルを使用している場合は、テーブルを繰り返し上書きしないでください。

バッチ読み込みジョブで --replace パラメータを使用するか、TRUNCATE TABLE SQL ステートメントを使用してテーブルを上書きすると、置換されたデータはタイムトラベルとフェイルセーフのウィンドウの期間保持されます。テーブルを上書きする頻度が高いと、追加のストレージ料金が発生します。

代わりに、読み込みジョブの WRITE_APPEND パラメータ、MERGE SQL ステートメント、またはストレージ書き込み API を使用して、テーブルにデータを段階的に読み込むことができます。

タイムトラベル期間を短縮する

ベスト プラクティス: 要件に応じて、タイムトラベル期間を短縮できます。

タイムトラベル期間をデフォルト値の 7 日から短縮すると、テーブルから削除または変更されたデータの保持期間が短縮されます。タイムトラベル ストレージの料金は、物理（圧縮）ストレージの課金モデルを使用している場合にのみ発生します。

タイムトラベル期間はデータセット レベルで設定されます。構成設定を使用して、新しいデータセットのデフォルトのタイムトラベル期間を設定することもできます。

宛先テーブルにテーブルの有効期限を使用する

おすすめの方法: 大容量のクエリ結果を宛先テーブルに書き込む場合は、デフォルトのテーブル有効期限を適用して不要になったデータを削除します。

BigQuery ストレージで大容量の結果セットを維持するには費用がかかります。結果に永続的にアクセスする必要がなければ、デフォルトのテーブル有効期限を使用して自動的にデータを削除するようにします。

Cloud Storage にデータをアーカイブする

ベスト プラクティス: Cloud Storage にデータをアーカイブすることを検討します。

アーカイブのビジネスニーズに応じて、BigQuery から Cloud Storage にデータを移動できます。BigQuery からデータをエクスポートする前に、長期ストレージの料金と物理ストレージの課金モデルを検討することをおすすめします。

BigQuery の費用の不一致と予期しない請求のトラブルシューティング

BigQuery の予期しない料金や費用の不一致のトラブルシューティングを行う手順は次のとおりです。

  1. Cloud Billing レポートで BigQuery の料金を確認する際に、料金の発生元を把握するには、まず料金を SKU でグループ化して、対応する BigQuery サービスの使用量と料金を簡単に確認できるようにすることをおすすめします。

  2. その後、SKU のドキュメント ページまたは Cloud Billing UI の Pricing ページで、対応する SKU の料金を確認し、BigQuery Storage Read API、長期保存、オンデマンド料金、Standard エディションなどの機能を確認します。

  3. 対応する SKU を特定したら、INFORMATION_SCHEMA ビューを使用して、これらの料金に関連付けられている特定のリソースを特定します。次に例を示します。

トラブルシューティングに関する重要な考慮事項:

  • Cloud Billing レポートの日別期間は、米国およびカナダの太平洋時間（UTC-8）の深夜 0 時に開始し、米国の夏時間への移行が適用されることを考慮してください。計算とデータ集計を調整して、同じ期間に合わせます。

  • 請求先アカウントに複数のプロジェクトが関連付けられていて、特定のプロジェクトからの請求を確認する場合は、プロジェクトでフィルタします。

  • 調査を行う際は、正しい地域を選択してください。

ジョブ実行に関連する予期しない請求のトラブルシューティングは、請求の発生元によって異なります。

  • オンデマンド分析の費用が増加している場合は、起動されたジョブ数の増加や、ジョブで処理する必要があるデータ量の変化に関連している可能性があります。INFORMATION_SCHEMA.JOBS ビューを使用して、この問題を調査します。
  • コミットされたスロットの料金が増加した場合は、INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES をクエリして、新しいコミットメントが購入または変更されたかどうかを確認します。
  • 予約の使用に起因する料金の増加については、INFORMATION_SCHEMA.RESERVATION_CHANGES に記録されている予約の変更を確認してください。自動スケーリングの予約の使用状況と課金データを照合するには、自動スケーリングの例をご覧ください。

請求されたスロット時間が INFORMATION_SCHEMA.JOBS ビューで計算されたスロット時間よりも大きい

自動スケーリング予約を使用する場合、課金は使用されたスロット数ではなく、スケーリングされたスロット数に基づいて計算されます。BigQuery は 50 スロットの倍数で自動スケーリングされるため、実際に使用された量が自動スケーリングされた量よりも少ない場合でも、最も近い倍数で課金されます。オートスケーラーのスケールダウンには最低でも 1 分はかかるため、クエリがスロットを使用した時間が 1 分未満の場合でも（たとえば 1 分のうち 10 秒だけの場合でも）、少なくとも 1 分分の料金が請求されます。自動スケーリング予約の料金を見積もる正しい方法は、スロットの自動スケーリングのページに記載されています。自動スケーリングを効率的に使用する方法については、自動スケーリングのベスト プラクティスをご覧ください。

自動スケーリング以外の予約でも同様のシナリオが発生します。課金は、使用されたスロット数ではなく、プロビジョニングされたスロット数に基づいて計算されます。自動スケーリングなしの予約の料金を見積もる場合は、RESERVATIONS_TIMELINE ビューを直接クエリできます。

オンデマンド クエリを実行するプロジェクトの INFORMATION_SCHEMA.JOBS で計算された課金対象の合計バイト数よりも課金額が少ない

実際の請求額が計算された処理済みバイト数よりも少ない理由はいくつか考えられます。

  • 各プロジェクトには、毎月 1 TB の無料枠のクエリが追加料金なしで提供されます。
  • SCRIPT タイプのジョブが計算から除外されなかったため、一部の値が 2 回カウントされる可能性があります。
  • Cloud 請求先アカウントに適用されたさまざまな種類の節約額（交渉済み割引、プロモーション クレジットなど）。Cloud Billing レポートの [Savings] セクションを確認します。ここには、無料枠の 1 TB のクエリ（1 か月あたり）も含まれます。

オンデマンド クエリを実行しているプロジェクトの INFORMATION_SCHEMA.JOBS で計算された処理済みバイト数よりも課金額が大きい

請求額が INFORMATION_SCHEMA.JOBS ビューのクエリで計算した値よりも大きい場合は、次の条件が原因である可能性があります。

  • 行レベルのセキュリティ テーブルに対するクエリ

    • 行レベルのセキュリティが設定されたテーブルに対するクエリでは、INFORMATION_SCHEMA.JOBS ビューの total_bytes_billed の値が生成されないため、INFORMATION_SCHEMA.JOBS ビューの total_bytes_billed を使用して計算された課金は、請求額よりも少なくなります。この情報が表示されない理由について詳しくは、行レベルのセキュリティに関するベスト プラクティスのページをご覧ください。

  • BigQuery で ML オペレーションを実行する

    • BigQuery ML のオンデマンド クエリの料金は、作成されるモデルのタイプによって異なります。これらのモデル オペレーションの一部は、ML 以外のクエリよりも高い料金で課金されます。したがって、プロジェクトの total_billed_bytes をすべて合計して、標準のオンデマンド料金（TB あたりの料金）を使用しても、正しい料金集計にはなりません。TB あたりの料金の差を考慮する必要があります。

  • 価格の金額が正しくない

    • 計算で正しい TB あたりの料金値が使用されていることを確認します。料金は場所によって異なるため、正しいリージョンを選択してください。料金に関するドキュメントをご覧ください。

一般的なアドバイスは、公開ドキュメントで推奨されているオンデマンド ジョブの使用量の計算方法に従うことです。

API が無効で、予約やコミットメントが使用されていないにもかかわらず、BigQuery Reservations API の使用量に対して課金される

SKU を調べて、どのサービスが課金対象であるかを把握します。請求対象の SKU が BigQuery Governance SKU の場合、これは Dataplex Universal Catalog からの料金です。Dataplex Universal Catalog の一部の機能は、BigQuery を使用してジョブの実行をトリガーします。これらの料金は、対応する BigQuery Reservations API SKU で処理されるようになりました。詳細については、Dataplex Universal Catalog の料金に関するドキュメントをご覧ください。

プロジェクトが予約に割り当てられているにもかかわらず、BigQuery 分析のオンデマンド費用が表示される

予約に関する問題のトラブルシューティングのセクションを読んで、Analysis の請求元を特定します。

BigQuery Standard エディションの従量課金制（PAYG）スロットに対する予期しない請求

Cloud Billing レポートで、ラベルを goog-bq-feature-type、値を BQ_STUDIO_NOTEBOOK としたフィルタを適用します。表示される使用量は、BigQuery Standard Edition の従量課金制スロットとして測定されます。これは、BigQuery Studio ノートブックの使用に対する請求です。BigQuery Studio ノートブックの料金の詳細をご覧ください。

Reservation API を無効にした後に BigQuery Reservations API の料金が表示される

BigQuery を無効にしても、コミットメント料金は停止しません。コミットメントの課金を停止するには、コミットメントを削除する必要があります。更新プランを NONE に設定すると、コミットメントの有効期限が切れたときに自動的に削除されます。

予想外のストレージ料金

ストレージ料金の増加につながる可能性があるシナリオは次のとおりです。

テーブルまたはデータセットを削除した結果、BigQuery のストレージ費用が増加した

BigQuery のタイムトラベル機能は、構成されたタイムトラベル ウィンドウの期間と、フェイルセーフ復元用の追加の 7 日間、削除されたデータを保持します。この保持期間中、テーブルは INFORMATION_SCHEMA.TABLE_STORAGE やコンソールに表示されなくなりますが、物理ストレージの課金モデルのデータセットで削除されたデータは、アクティブな物理ストレージの費用に計上されます。テーブルデータが長期ストレージにある場合、削除すると、このデータはアクティブな物理ストレージに移動します。BigQuery ストレージの料金ページによると、アクティブな物理バイトは長期の物理バイトの約 2 倍の料金で課金されるため、対応する費用が増加します。物理ストレージの課金モデルのデータセットで、データ削除による費用を最小限に抑えるには、タイムトラベル期間を 2 日に短縮することをおすすめします。

データを変更せずにストレージ費用を削減

BigQuery では、アクティブ ストレージと長期保存に対して料金が発生します。アクティブ ストレージ料金には、90 日間連続して変更されていないテーブルまたはテーブル パーティションが含まれます。一方、長期ストレージ料金には、90 日間連続して変更されていないテーブルとパーティションが含まれます。データが長期ストレージに移行すると、ストレージ費用全体が削減されます。長期ストレージはアクティブ ストレージよりも約 50% 安価です。詳細については、ストレージの料金をご覧ください。

INFORMATION_SCHEMA のストレージ計算が課金と一致しない

  • INFORMATION_SCHEMA.TABLE_STORAGE ではなく INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE ビューを使用する - TABLE_STORAGE_USAGE_TIMELINE は、ストレージ費用を正しく計算するための、より正確で詳細なデータを提供します。
  • INFORMATION_SCHEMA ビューで実行されるクエリには、税金、調整、丸め誤差は含まれません。データを比較する際は、これらの点を考慮してください。Cloud Billing のレポートの詳細については、このページをご覧ください。
  • INFORMATION_SCHEMA ビューに表示されるデータは UTC ですが、請求レポートのデータは米国とカナダの太平洋時間（UTC-8）で報告されます。

次のステップ