本記事は
【Advent Calendar 2024】
5日目の記事です。
🌟🎄
4日目
▶▶ 本記事 ▶▶
6日目
🎅🎁
坂本です。
昨年に続いてAdvent Calendarに執筆させていただきます。
※本記事は下記の2023-12-22に投稿した記事の続編になるため、ご覧になっていない方はまずこちらを参照していただけると幸いです。
Looker StudioのデータソースにBigQueryのテーブルを使用する - NRIネットコムBlog
はじめに
Looker StudioでデータソースにBigQueryを使用する場合、（Looker StudioやBigQueryのキャッシュが有効な場合を除いて）レポートを表示する度にBigQueryのクエリが実行されます。
BigQueryのオンデマンド料金ではクエリで処理するデータ量に応じて課金されます。
※BigQueryのクエリの実行（分析）の料金については下記をご参照ください。
料金 | BigQuery: Cloud Data Warehouse | Google Cloud
またクエリで処理するデータ量が多い場合、レポートを表示する時間が遅くなる場合があります。
このためデータソースをBigQueryにする場合、クエリで処理するデータ量をいかに削減するかが重要となります。
集計していないテーブルを使用する場合
以下のようなユーザー数とページビュー数の日毎の推移を表示するグラフを例にします。
集計していないテーブルとして、前回の記事で解説した、Google社が提供しているGA4の一般公開データセット「ga4_obfuscated_sample_ecommerce」を加工したテーブルを使用します。
このテーブルはイベント毎にレコードが作成されており、スキーマは下記の通りとなります。
| フィールド | 取得する内容 |
|---|---|
| event_date | イベントが発生した日付 |
| event_name | イベント名 |
| user_pseudo_id | デバイス ID（ユーザーを識別するID） |
| unique_ga_session_id | デバイスIDと「ga_session_id（セッションを識別するためのID）」を結合した文字列（※本記事では未使用） |
| page_location | イベントが発生したページのURL（GA4のディメンション「ページ ロケーション」に相当する値） |
| device_category | ユーザーのデバイスの種類（GA4のディメンション「デバイス カテゴリ」に相当する値） |
ユーザー数とページビュー数は以下の方法で算出することができます。
- ユーザー数→デバイス ID（user_pseudo_id ）のユニーク数（重複を除いた数）
- ページビュー数→イベント名（event_name）=「page_view」のレコード数
このため、このグラフを表示する際に実行されるクエリの処理対象のデータの範囲は下記のオレンジ色部分になります。
データ量は下記の掛け算になるため、対象のデータ量が多く利用者数が多いレポートほど注意が必要です。
- 元のテーブルのデータ量（イベント数）
- 集計対象とする期間
- レポートで使用するグラフや表の数
- レポートの利用者数、利用頻度
この例で使用しているテーブルは1日あたりのユーザー数が約2,000人のWebサイトのもので、1ヶ月分のデータ量が約60MB程度なので問題ないですが、ユーザー数が多いWebサイトのデータを使用する場合は注意が必要です。
例えば1日あたりのユーザー数が約20万人の場合は、単純計算で100倍になるため同様の1ヶ月分のデータ量は約6GBになります。
1年分のデータを表示する場合はさらに12倍になるので約72GBとなり、クエリはグラフや表毎に実行されるため、実際のデータ量はさらに増加します。
※利用者数、利用頻度によってはBigQueryの費用が月間で数十万円以上となる可能性もあります。
集計済のテーブルを使用した場合
データ量を削減する一番効果的な方法は、レポートに最適化した事前に集計したテーブルを使用することです。
※データマートと呼ばれる場合もあります。
例のようなグラフを表示する場合に一番データ量を削減できるのは、下記のような日付毎に集計したテーブルをデータソースとすることです。
このテーブルはどんなに集計前のデータ量が多い場合でも日付毎にデータが集約されるため、レポートを表示する際に処理するデータ量を大幅に削減できます。
ただし、このテーブルは日毎のユーザー数とページビュー数を表示することに特化しているため、下記のような場合には対応できません。
- デバイスカテゴリ毎に集計する。
- スコアカードで任意の期間のユーザー数を表示する。
- 日毎以外に、週、月、曜日毎のユーザー数を表示する。
1つのテーブルでこれらを実現する場合は、下記のような、日付:x_黒太字:デバイスID毎に集計したテーブルを作成することで対応できます。
日付毎のテーブルと比較するとデータ量は増えてしまいますが、日付✖デバイスID毎にデータが集約されるためイベント毎のテーブルよりはデータ量を削減できます。
また下記のように月別にデータを表示する場合は、月別に集計したデータを別途作成することでデータ量を削減できます。
集計済のテーブルを使用するデメリット
集計済テーブルを使用することでデータ量（コスト）を削減できますが、以下のようなデメリットがあります。
- テーブルのストレージ料金が発生します。
- テーブルの作成およびデータを更新する対応が必要となります。
- テーブル（データソース）が多くなるほど、Looker Studioのレポートの設定が複雑になります。特に1つのページに複数のデータソースを使用する場合、ページ共通でコントロール（プルダウン等のフィルタ）を設定することが難しくなります。
まとめ
Looker StudioのデータソースでBigQueryを使用する場合、データソースで使用するテーブルの設計（集計済テーブルの使用）が重要となります。 集計済テーブルをどう使うかは、BigQueryの分析（クエリ）のコストと、テーブルやダッシュボードの作成・維持管理（人）のコストのトレードオフとなります。
データ量が少なく、レポートの利用者・利用頻度が少なくコストやレポート表示速度に問題がない場合は、無理をして集計済テーブルを使う必要はないかと思います。 逆にデータ量が多く、レポートの利用者・利用頻度が多い場合はコストやレポートの表示速度を考慮して集計済テーブルを使用する必要があります。
許容できるコストを意識した上で、状況に応じて最適な方法を検討していただければと思います。
