G-gen の神谷です。本記事では、Looker Studio で BigQuery データソースを使う際のコスト最適化について説明します。

はじめに

Looker Studio とは

Looker Studio とは、Google Cloud が提供する BI ツールであり、様々なデータソースに接続し、簡単にダッシュボードを作ることができます。

もともとは Google Workspace 内の製品でありデータポータル（もしくは Data Studio）と呼ばれていましたが、リブランドが行われた結果、Looker Studio という名称になりました。

なお、Looker と Looker Studio は別の製品となります。詳細については、以下の記事をを参照してください。

blog.g-gen.co.jp

料金体系

Looker Studio は無料版と Pro 版の二種類があります。Looker Studio Pro は、無料版にガバナンス機能が追加されたものであり、ユーザー単位でのサブスクリプションとして申込可能です。

Looker Studio Pro の詳細な解説は、以下の記事をご参照ください。

blog.g-gen.co.jp

Looker Studio の無償版は、利用に料金はかかりません。ただし、データソースとして BigQuery を利用している場合、ダッシュボードが読み込まれた際にクエリが実行され、BigQuery からのデータ読み出し料金が発生します。

当記事では、BigQuery をデータソースとする Looker Studio レポートで、コストを削減する手法について紹介します。

料金削減の基本方針

レポートごとの BigQuery コストを調べる

まずは、どのレポートでコストが多く発生しているかを把握することが重要です。

特定の Looker Studio レポートで、どのくらいの BigQuery コストがかかっているかは、以下の記事の方法で調べることができます。

blog.g-gen.co.jp

Looker Studio レポート側の基本方針

Looker Studio レポート側では、以下の基本方針に従って、コスト削減を図ります。

データの更新頻度を減らす
- 参考 : データの更新頻度を管理する
- レポートの編集者権限を持っている人は、データを手動で更新できますが、閲覧者権限の人は手動更新ができません
- 閲覧者権限の人にとって、Looker Studio レポートのデータは、データソースに設定した更新頻度で更新されるのを待つことになります
- データが更新されるまでは、同じクエリに対してはレポートのキャッシュが適用されます
抽出されたデータソースを使用する
- 参考 : パフォーマンス向上のためにデータを抽出する

BigQuery 側の方針

BigQuery 側では、以下の基本方針に従って、コスト削減を図ります。

BI Engine を使用して BigQuery データソースを高速化する
- 参考 : BI Engine とは
パーティショニングやクラスタリングを設定する
- 参考 : BigQueryのパーティションとクラスタリングについての解説
BigQuery Editions を導入して Baseline や Max 値を設定する
- 参考 : BigQuery Editionsを徹底解説
事前集計したマートテーブルを作成する
マテリアライズドビューを使用する
- 参考 : マテリアライズドビューの概要
BigQuery のキャッシュを利用する
- 同じ Google アカウントから発行された同じクエリには、キャッシュが適用されます

Looker Studio のキャッシュ機能

レポートのキャッシュ

Looker Studio のキャッシュは、レポートによって生成されたクエリとその結果を保持します。本記事では「レポートのキャッシュ」と表現しますが、ドキュメントでは「一時的にメモリに保存する」と表現されています。

Looker Studio では、レポートのページを読み込んだときや、フィルタを変更したり、プルダウンから項目を選択したりした際に、データソースへのクエリ（SQL）が生成されます。このときに生成されたクエリが以前に実行されたことのあるクエリと完全に同一であり、かつデータソースに設定された「データの更新頻度」の時間内であれば、キャッシュにヒットする可能性があります。

Looker Studio のデータソースにはデータ更新頻度の設定項目があり、この時間を超えた場合は、クエリが過去のものと同一でもデータソースへクエリが再発行され、キャッシュがリフレッシュされます。

また、キャッシュはデータソースへの認証情報ごとに保持されるため、オーナーの認証情報によって認証するようデータソースを設定すると、最もキャッシュ効率が良くなります。ただし、データソースへの認証情報に何を設定するかは、コスト面だけでなく、データへのアクセス権限の要件をよく検討したうえで決定してください。

キャッシュが最後に更新された日時は、レポートの左下に表示されています。レポートを読み込んだり、フィルタを変更した際に、左下の「最終更新日」が変更された場合、キャッシュヒットせずに、データソースへクエリが発行されたことがわかります。

なお BigQuery コネクタの場合、更新頻度は「分単位: 1～50 分」「時間単位: 1～12 時間」から選択可能です。

参考 : データの更新頻度を管理する

抽出されたデータソース

レポートのキャッシュとは別に、抽出されたデータソースというデータのスナップショットを保持する機能があります。

データソースを選択して、特定のフィールドを指定すると、そのフィールドだけを含む「抽出済みデータソース」を作成することができます。

抽出されたデータソースは、100 MB を上限として、データを Looker Studio に保持しておくことができます。データを自動的に更新したい場合は、自動更新を有効化し、更新頻度を設定します。

参考 : パフォーマンス向上のためにデータを抽出する

BigQuery のキャッシュ機能

クエリ結果のキャッシュ

BigQuery のクエリ結果のキャッシュは、デフォルトで提供される機能です。過去に実行されたクエリと同一のクエリが同じ Google アカウントから実行された場合、キャッシュが使用されます。

なお、BigQuery Editions のうち Enterprise または Enterprise Plus エディションを使っている場合、別の Google アカウントのキャッシュも利用できます。

マテリアライズドビュー

マテリアライズドビューは、データの実体を保持するビューです。マテリアライズドビューを SQL で定義すると、定期的にデータが更新され、また古くなったデータをクエリするとその部分だけが自動的に更新されるため、常に最新の情報を取得できます。

通常のビューとは異なりいくつかの制約がありますが、要件に応じて導入を検討してください。

参考 : マテリアライズドビューの概要

BI Engine

BI Engine は、BI ツールのために BigQuery のデータをキャッシュしておくためのメモリです。パーティショニングやクラスタリングと組み合わせることで、特に効果を発揮します。

BI Engine には、以下のような特徴があります。

BI Engine に保存されたデータから結果を取得するクエリを実行する場合、データの読み取りが課金されない
BigQuery Editions で購入したスロット数に応じて無料の BI Engine 容量が付帯する
- 例として100スロットを購入すると、5 GiB の BI Engine 容量が無料で付帯する
- 参考 : BI Engine の料金
BI Engine に有効なクエリ演算子が決まっており、このリスト以外のクエリでは効果が薄れる
- 参考 : 最適化される SQL 関数と演算子
BI Engine は結合が多いクエリだと効果が弱くなる
- 参考 : 結合を最小化する
優先テーブル設定により、BI Engine が適用されるテーブルを限定できる
- 参考 : 優先テーブル

キャッシュ以外の手法

BigQuery Editions

BigQuery Editions を使うと、Autoscaler の効果により、デフォルト設定であるオンデマンドよりも料金が安くなる可能性があります。

必要に応じてスロットの1年または3年コミットメントを購入すると、さらに安価に利用可能になります。

blog.g-gen.co.jp

パーティショニングとクラスタリング

パーティション分割テーブルやクラスタリングを利用することで BigQuery テーブルに対するフルスキャンが回避され、コスト削減に繋がります。

blog.g-gen.co.jp

事前集計とカラム設計

動的集計が必要なケース（例 : 日付の期間指定によるユニークカウント（distinct）。小計の合計が総計にならない）以外は、raw データを扱うのではなく、なるべく事前集計をします。

日付やフィルタ項目のパターン分、あらかじめ集計しておくことが有用です。以下は、その例です。

SELECT
  date_,
  title,
  contributor_ip,
  COUNT(title) AS revision_count
FROM
  `jkamiya.Looker Studio_test.wikipedia`,
  UNNEST ([date_, "9999-12-31"]) AS date_,
  UNNEST ([title, "ALL"]) AS title,
  UNNEST ([contributor_ip, "ALL"]) AS contributor_ip
GROUP BY
  date_,
  title,
  contributor_ip
ORDER BY
  revision_count desc