BigQueryの料金が高いときの確認手順｜クエリ費用を抑える実務チェック

BigQueryの費用増加は、SQLだけでなく実行回数やBIの更新頻度にも左右されます。料金方式の確認、実行前見積もり、読み取り範囲、上限設定を順に調べる方法を解説します。

最初に料金方式と増えた費用を分ける

BigQueryの料金が高いと感じたら、まず請求の内訳と利用している料金方式を確認します。オンデマンドのクエリ課金と、容量ベースのコンピューティングでは、費用を見る観点が異なります。ストレージ、データ転送、周辺サービスの費用も、同じ請求に混ざっていないかを確認します。

オンデマンドの場合は、処理したデータ量と実行回数を中心に調べます。容量ベースの場合は、予約・割当・稼働状況などを含めた確認が必要です。料金体系を確認せずに「列を減らせば請求が必ず下がる」と判断するのは避けます。

この記事では主に、オンデマンドのクエリ費用を調べる手順を扱います。単価や利用可能な機能は、契約条件と利用時点のGoogle Cloud公式情報で確認してください。

同じSQLが一日に何百回も走っていれば、一回の処理量が小さくても合計は増えます。逆に、単発の全件スキャンが増加分の大半を占める場合もあります。ジョブの実行履歴を、日時・実行主体・参照対象・処理量・実行回数で整理します。

BIダッシュボードの自動更新、定期クエリ、開発中の再実行、外部ツールからの接続など、起動元まで追うと改善案が変わります。ダッシュボードの更新頻度を下げる場合も、利用部署が必要とする鮮度と合わせて決めます。

一例として、前日までの実績だけを毎朝確認する画面なら、秒単位の更新が必要とは限りません。一方、運行や在庫判断に必要な更新を、費用だけを理由に遅らせると業務上の損失につながります。

費用増加を調べる順序を表すAI生成のコンセプト画像

Google Cloudは、ドライランなどによる処理量の見積もりや、必要な列・データに読み取りを絞る方法を案内しています。オンデマンドでは、結果の行数をLIMITで減らすだけでは、読み取り費用を抑えられない場合があります。

パーティションやクラスタリングは、追加すれば一律に安くなるものではありません。実際の検索条件とデータの分布を確認し、同じ条件・同じ結果で比較します。性能面の調査はBigQueryの集計が遅いときの確認事項も参照してください。

費用の予算通知は、通知が来ることと支出が自動停止することを同一視しないようにします。想定外のクエリ実行に備える場合は、対象の料金方式で利用できる制御を別途検討します。

オンデマンドでは、クエリごとの最大課金バイト数などが選択肢になります。ただし上限を厳しくすると、必要な集計も失敗する可能性があります。失敗を誰が検知し、例外実行を誰が判断するかまで決めておきます。

本番・検証・一時分析の実行主体やプロジェクトを区別しておくと、増加の発見と責任範囲の確認が容易になります。分析担当者が業務上必要な処理まで止められないよう、制限と申請手順をセットで設計します。

改修後の評価には、対象期間、入力データ、処理結果、処理量、実行時間、実行回数を記録します。キャッシュの利用や、対象データの増減で結果が変わるため、一回の実行だけで削減率を確定しないことが大切です。

Q. BigQueryのコスト相談で何を用意すればよいですか？請求内訳、料金方式、増加した期間、対象ジョブ、BIや定期処理の構成、必要なデータ鮮度を整理します。顧客の個人情報や秘密鍵を、そのまま相談資料へ含める必要はありません。

For f'sAI and data analyticsでは、費用と性能、業務の更新条件を併せて確認し、改善の対象を整理します。