BigQueryの料金体系が変わるので見積もりSQLを叩いてみた

これまでのおさらい

みなさん、BigQuery 使ってますか！（挨拶

先週（3/30）、BigQuery の新しい料金体系（BigQuery Editions）が発表されたのはご存じのことと思います。

今回の料金体系変更で一番インパクトが大きそうなのが、ストレージ量の計算が非圧縮状態の (= 論理的な) 容量から圧縮された状態の (= 物理的な) 容量に依存するようになること。

でも実際どうなるのか。。と思ったので、手元の環境で確認してみました！
ついでに分析コストについても少しだけ考えてみます。

どうすれば？

こちらのドキュメントに、ストレージについてのシミュレーション方法が書いてありました。

ざっくりいうと、BQ の INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION ビューに圧縮状態・非圧縮状態のストレージ容量 (の予測値) が格納されているので、そちらに料金表の価格をかけ算して見積もることが可能です。具体的には SQL を叩くことになるでしょう。

以下、具体的に手順を書いてみます。

実行権限について

SQL を実行するには権限が必要です。もう少し具体的に言うと、対象の BQ リソースがあるプロジェクトではなく、そのプロジェクトが属する組織 (Organization) に対して以下の権限を持つ必要があります。

• bigquery.tables.get
• bigquery.tables.list

今回は手っ取り早く、作業するプリンシパルに以下の事前定義ロールを追加してしまいました。

• BigQuery データ閲覧者 (roles/bigquery.dataViewer)

SQL の実行

続いて BQ の SQL ワークスペース にて、下記の SQL を実行します。

-- Ref:
--  https://cloud.google.com/bigquery/docs/information-schema-table-storage-by-organization
--  https://cloud.google.com/bigquery/pricing#storage
SELECT
  project_id,
  -- logical_gb  : Total number of logical (uncompressed) bytes in the table (GB)
  -- physical_gb : Total number of physical (compressed) bytes used for storage (GB)
  ROUND(SUM((TOTAL_LOGICAL_BYTES  / POW(1024, 3))),2) AS logical_gb,
  ROUND(SUM((TOTAL_PHYSICAL_BYTES / POW(1024, 3))),2) AS physical_gb,
  -- logical_billing_model  : monthly storage costs that use a logical billing model (USD)
  -- physical_billing_model : monthly storage costs that use a physical billing model (USD)
  ROUND(SUM(((ACTIVE_LOGICAL_BYTES  / POW(1024, 3)) * 0.023) + ((LONG_TERM_LOGICAL_BYTES  / POW(1024, 3)) * 0.016)),3) AS logical_billing_model,
  ROUND(SUM(((ACTIVE_PHYSICAL_BYTES / POW(1024, 3)) * 0.052) + ((LONG_TERM_PHYSICAL_BYTES / POW(1024, 3)) * 0.026)),3) AS physical_billing_model
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION
GROUP BY
  project_id
ORDER BY
  project_id
;

プロジェクトごとに以下の値が表示されました！

この場合、論理 (非圧縮状態) で 3.27GB --> $0.058 だったものが、物理 (圧縮状態) で 0.14GB --> $0.005 と、1/10 以下のコストになる計算です。
（もっとも、このサンプルで使ったデータセットは小さすぎて、無料枠に納まってしまっていますがｗ）

説明

前述のドキュメントに記載されているものを、実行できるようなるべくシンプルにそのまま SQL コードにしたものです（見やすいようにROUND ()(四捨五入) とGROUP BY・ORDER BYを追加しました）。

論理課金モデルを使用するデータセットの場合、月間ストレージ費用は、次のように予測できます。
((ACTIVE_LOGICAL_BYTES value / POW(1024, 3)) * アクティブな論理バイト料金) + ((LONG_TERM_LOGICAL_BYTES value / POW(1024, 3)) * 長期論理バイトの料金)

物理課金モデルを使用するデータセットの場合は、ストレージ費用を次のように予測できます。
((ACTIVE_PHYSICAL_BYTES value / POW(1024, 3)) * アクティブな物理バイト料金) + ((LONG_TERM_PHYSICAL_BYTES value / POW(1024, 3)) * 長期物理バイトの料金)

単価とリージョン（データセットのロケーション）は東京のものにハードコードされているので、他のリージョンで利用する場合は適宜修正してください。12〜13 行目と 15 行目になります。

なお記事執筆時点で、料金のページ は言語を English にしないと物理ストレージ料金が出力されませんでした。
また、そのページに記載の価格も Preview 段階のものとなっていたため、GA 時には変わる可能性もありそうです。ご留意ください。

分析 (Analytics) コストについて

まず、現状オンデマンド分析モデルで移行後もそのままなのであれば、単価が変わるだけなので単純に計算できるかと思います。

定額 (Flat-rate) から Editions に移行する場合は Autoscaling が関係してくるので、具体的に「いくら」というシミュレーションは簡単ではなさそうです。
ただし「分析にかかった単位時間当たりのスロット利用料」は同じく INFORMATION_SCHEMAに記録されているため、そちらから概算値を算出可能です。

算出のための SQL は G-gen さまが素早く公開されていましたので、気になる方はそちらをご参照下さい！

• BigQueryの料金体系(BigQuery Editions)を徹底解説 - G-gen Tech Blog

また、現状のスロット使用状況（Slot Usage）を確認するだけであれば、 BigQuery のモニタリング機能から参照できます。

こちらも組織 (Organizations) に対して追加の権限が必要になる場合があります。詳細は上記ドキュメントの「権限」の項をご参照下さい。

単に参照したいだけであれば、さくっと BigQuery リソース閲覧者 (roles/bigquery.resourceViewer) 事前定義ロールを追加してしまいましょう。

まとめ

BQ の価格体系変更にそなえてシミュレーションする方法をご紹介しました。
実際に移行されるのはもう少し先（7 月）ですが、そんなことを言っていると 3 ヶ月なんてあっという間なので、その時になって慌てないですむように準備しておきましょう！

参考

• BigQuery の新料金体系の解説 どこよりも早くお届けします！ | クラウドエース株式会社
• BigQuery のストレージ料金プランを変更して、年間数千万円を節約する - ZOZO TECH BLOG