catch-img

Tableau × BigQuery BIツールの運用コストを把握しよう

目次[非表示]

  1. 1.はじめに
  2. 2.コスト管理の3つのアプローチ
    1. 2.1.1. INFORMATION_SCHEMAで「重いクエリ」を特定する
    2. 2.2.2. ジョブ履歴でコストの「トレンド」を把握する
    3. 2.3.3. 課金アラートで「予算超過」を事前に防ぐ
      1. 2.3.1.① 予算とアラートを開く
      2. 2.3.2.② 予算を作成する
      3. 2.3.3.③ アラートのしきい値を設定する
    4. 2.4.補足:Data Studio(旧Looker Studio)からのクエリを特定する
  3. 3.まとめ
  4. 4.おわりに

はじめに

前回の記事では、パーティショニング・データマートの活用・カラム削減という3つのアプローチで、BigQueryのスキャン量を設計段階から抑える方法を紹介しました。

前回の記事はこちら:https://ex-ture.com/blog/2026/06/02/bigquery-scan-cost/

ただし、設計を工夫してもBI基盤の運用が始まれば、ユーザーの操作のたびにクエリが積み重なっていきます。今回は、BI基盤の運用が開始後に、BigQueryのスキャン量や課金をどうやって監視・管理するか、その具体的な方法を紹介します。

コスト管理の3つのアプローチ

1. INFORMATION_SCHEMAで「重いクエリ」を特定する

BigQueryには INFORMATION_SCHEMA というメタデータビューが用意されており、実行されたクエリのスキャン量・実行時間・発行ユーザーなどをSQLで確認できます。

特に JOBS_BY_PROJECT ビューは、プロジェクト内の全クエリ履歴を参照できるため、コスト調査の起点として活用できます。

1
2
3
4
5
6
7
8
9
10
11
12
-- 過去7日間でスキャン量が多いクエリ
SELECT
  user_email,
  job_id,
  ROUND(total_bytes_processed / POW(1024, 3), 2) AS scan_gb,
  query,
  creation_time
FROM region-asia-northeast1.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
ORDER BY total_bytes_processed DESC;

各カラムの見方:

  • user_email:誰が実行したか(Tableauの接続ユーザーが表示される)

  • scan_gb:そのクエリが読んだデータ量(GiB換算)

  • query:実行されたクエリ

スキャン量が急増した場合、膨大なデータ量を読んでいるクエリが発生しているケースが少なくありません。

このクエリでINFORMATION_SCHEMAを確認することで、「コストの大半を占めるクエリ」を洗い出すことができます。

※このクエリを実行するには、BigQuery リソース閲覧者(roles/bigquery.resourceViewer) IAMロールが必要です。

https://docs.cloud.google.com/bigquery/docs/information-schema-jobs?hl=ja#required_role

2. ジョブ履歴でコストの「トレンド」を把握する

1でクエリ単位の重さを把握したら、次は全体のコストが時間軸でどう動いているかを確認します。

スキャン量が増加したタイミングを特定できれば、その前後にあった変更(ダッシュボードの追加、ユーザーの増加など)と照らし合わせることができます。

1
2
3
4
5
6
7
8
9
10
11
12
-- 日別のスキャン量推移(過去30日)
SELECT
  DATE(creation_time) AS exec_date,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_processed) / POW(1024, 3), 2) AS total_scan_gb
FROM region-asia-northeast1.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY exec_date
ORDER BY exec_date;

1のクエリとの違いは、個別ジョブではなく日単位で集計している点です。

query_count(クエリ実行回数)と total_scan_gb(スキャン量合計)を並べて見ることで、「回数は変わっていないのにスキャン量だけ増えた」といった異常も検知しやすくなります。

3. 課金アラートで「予算超過」を事前に防ぐ

上記2つは事後の分析ですが、予算を超えそうになったら通知を受け取る仕組みも合わせて設定しておくと安心です。Google Cloudの「予算とアラート」機能を使えば、メール通知まで数分で設定できます。

① 予算とアラートを開く

Google Cloudコンソール → 「お支払い」→「予算とアラート」

予算とアラート

② 予算を作成する

「予算を作成」をクリックし、対象プロジェクトと月間予算額を入力します。

予算の作成画面

③ アラートのしきい値を設定する

通知を受け取るタイミング(例:50% / 90% / 100%)とメール通知先を指定して完了です。

閾値設定画面

「予算とアラート」の画面に追加されているのが確認できました。

予算の追加を確認

さらに発展的な使い方として、Pub/SubやCloud Run Functionsと連携することで、アラート発火時に自動でクエリを制限する仕組みを構築することも可能です。大規模な本番環境では特に有効な手段です。

補足:Data Studio(旧Looker Studio)からのクエリを特定する

Tableauが発行するクエリは、BigQuery上では一般的なクエリと区別しにくい一方で、Data StudioはBigQueryに送信するクエリに自動でジョブラベルを付与します。このラベルを使うことで、Data Studio起因のクエリだけを絞り込むことができます。

BigQueryコンソールのジョブエクスプローラでは、フィルタのラベル欄に requestor:looker_studio を入力することで、Data Studioから発行されたジョブだけを表示できます。

ラベルからData Studioのジョブを特定

INFORMATION_SCHEMAを使う場合も、同様にラベルで絞り込むことができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
-- Data Studioから発行されたクエリのみ抽出
SELECT
  creation_time,
  user_email,
  ROUND(total_bytes_processed / POW(1024, 3), 2) AS scan_gb,
  SUBSTR(query, 1, 100) AS query_preview
FROM region-asia-northeast1.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
  UNNEST(labels) AS label
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
  AND label.key = 'requestor'
  AND label.value = 'looker_studio'
ORDER BY total_bytes_processed DESC
LIMIT 20;

さらに looker_studio_report_id というラベルも付与されているため、どのレポートから発行されたクエリかまで特定することができます。複数のレポートを運用している場合、レポート単位でのコスト把握に活用できます。

まとめ

コスト管理の基本的な考え方は、原因の特定と事前の備えの2つです。

INFORMATION_SCHEMAとジョブ履歴を使うことで、コストに大きな影響を与えているクエリやユーザー、あるいは急増のタイミングと原因を具体的に特定できます。一方、課金アラートはそもそも問題が大きくなる前に気づくための仕組みです。

特定できる仕組みと、発生前に検知できる仕組みを両方持っておくことで、コストの問題に振り回されない運用体制が整います。

おわりに

BIツールからのクエリは、ユーザーの操作のたびに積み重なります。設計段階でスキャン量を抑えることも大切ですが、運用が始まった後も「どこで・どれだけ使われているか」を継続的に見ておくことが、予期しないコスト増への備えになります。

この記事はData Saberコミュニティ活動の一環として執筆しました。

Oishi
Oishi

人気記事ランキング

タグ一覧