Looker → Looker Studio 移行の罠
はじめに
今回は社内で使用してる BI ツールを Looker から Looker Studio へ移行した際に起こった出来事について書いた記事です。
なお、移行に関する記事は以下で ゲンシュン さんがまとめてくださってるので合わせてご覧ください。
背景
今年度の最初に Looker の解約意思決定が下り、11月の契約満期に向けて移行作業が夏頃から本格的に始まりました。
移行作業自体はおかげさまで1ヶ月ほどで完了することができ、ツールコストを踏まえると事業的にもかなりインパクトの大きい取り組みだったと思います。
しかし、移行完了から1ヶ月が経った頃、Looker Studio のメインユーザーである Customer Success (CS) チームから問い合わせが発生しました。
問題提起
今回 CS からいただいた問題は、大きく分けて以下の3つです。
- 特定のデータに関するレポートを開くと出力に時間がかかる
- ユーザーが指定した3ヶ月で集計した結果がほしい
- ユーザーが指定した値によってカテゴリ分類してほしい
以下にそれぞれの問題とその対応について簡単に触れていきます。
1. 特定のデータに関するレポートを開くと出力に時間がかかる
原因はカスタムクエリの書き方にあり、毎回の実行時に余計な期間と余分なカラムを実行していました。Looker側 の Explore で定義されていた内容をそのままカスタムクエリで表現したことが要因だと推測できました。移行前後における集計結果に差分がないことを第一に考えると、Looker 側で実装した内容をそのまま書き写すのはごく自然な流れなのですが、1つのクエリで表現しようと思うと少し工夫する必要があります。
さらに、こうした背景の1つにデータソースをむやみに増やしたくないという思惑がありました。弊社では組織体制が変わり、データ基盤やBIツールを保守運用する専属チームが無いため、極力メンテナンスしないための工夫が必要でした。しかし、結果的にBIツールを使用するメインユーザーに負荷がかかってしまったため、早急に対応する必要が出てしまいました。
対応はいたってシンプルで、負荷の大きいレポートに対してそれぞれ専用のデータソースを作成していきました。CSが活用するレポートは滅多に変わるものではないため、多少カスマイズ要件があったとしてもそれを最低限満たしたものを提供しています。無論、既存のレポートで使われている指標のうち、これって本当に必要？は毎回問いただしながら要件は詰めていきます。また、集計粒度が決まってるものに関してはその粒度まで集計したテーブルをデータ基盤側で実装し、Looker Studio で直接参照するものもありました。これは当時移行のタイミングでも決めていた方針で、データ基盤側で補えるものは積極的にデータ基盤側に寄せています。
2. ユーザーが指定した3ヶ月で集計した結果がほしい
Looker では Liquid Parameter というユーザーが自由に指定できるパラメータと、そのパラメータを参照したいい感じのクエリを組み合わせた期間パラメータを使っていました。例えばユーザーが集計粒度を「日単位」なのか「週単位」なのか「月単位」なのか、はたまた「ある一定期間」なのかを自由に選べる設計にしていました。最初の3つは Looker Studio でも用意に実現することはできるのですが、4つ目の「ある一定期間」での集計が難しく、移行時にも必要ないだろうということで実装はしていませんでした。しかし、CSの一部のユーザーで「3ヶ月単位で集計したデータが見たい」という要望がコンスタントに来るようになり、今回の問い合わせへとつながりました。
3ヶ月単位での集計が「四半期単位」であれば簡単なのですが、今回の要望としては「ユーザーが指定した3ヶ月での集計」というものでした。色々と模索した結果、本件は3ヶ月単位のローリング集計を採用することにしました。ローリング集計と言ってるのは、BigQuery の Window 関数を使った集計方法で、以下のように実装します。
select
partition_col,
month_col,
sum(value_col) over (
partition by partition_col
order by month_col
rows between 2 preceding and current row
) as sum_col
from my_table
また、複数の指標に対して Window 関数を使いたい場合は以下のように書くと便利です。
select
partition_col,
month_col,
sum(value_col) over w as sum_col,
max(value_col) over w as max_col,
avg(value_col) over w as avg_col
from my_table
window w as (
partition by partition_col
order by month_col
rows between 2 preceding and current row
)
これで集計した結果をテーブルとして実体化し、 Looker Studio で直接参照することで今回の問題を解決しました。
3. ユーザーが指定した値によってカテゴリ分類してほしい
こちらも Looker では Liquid Parameter を組み合わせて実装していたのですが、 Looker Studio だと簡単にできなさそうということで後回しになっていた問題でした。ですが、まだ社内の知見として Looker Studio の機能を十分に理解できていなかった点もあり、この件に関してはカスタムクエリにパラメータを使用することで意外にもすんなり解決することができました。
ただ落とし穴が1つあり、カスタムクエリ上でパラメータを使用する場合、デフォルト値を指定しないとレポートの表示でエラーが出てしまいます。エラー内容がまだまだ不十分な Looker Studio としてはドツボにはまるポイントなので注意が必要です。
今回の事例から学んだこと
今回の取り組みを経て、 Looker から Looker Studio へ移行する際に組織単位で決めておくべき方針がありそうだなと感じたので以下にまとめます。
カスタムクエリはレビュー体制を取る
Looker Studio ではカスタムクエリを使うことで手軽に誰でも好きなデータソースを作ることができますが、みんなが参照するようなデータソースを作る際、カスタムクエリであってもレビュー体制は取るべきだなと感じました。Github でコード管理できないのが歯がゆいポイントなのですが、そこまで頻度高く変わらないクエリなのであればどこかドキュメントを作成しておいてレビューし合うのが健全かなと思います。ここは改善の余地がありそうな観点ではあるので、もしこんな方法もあるよ〜って方がいらっしゃったら教えてください。
データソースだけは何が何でも管理する
これも将来的なメンテナンスコストや運用を考えると必須な観点だなと感じました。むやみやたらとデータソースを作られると、今回の1つ目の問題で出てきたような大量のクエリコストがかかるものが誕生しかねないので、レポートは無理でもデータソースだけは管理する必要はありそうです。ただ、これもドキュメントにまとめていくとかしか対応ができていないので、何か手軽に管理できるいい方法があれば教えてください。
BigQuery のインプットを勧める
そもそもちょっとだけ集計した結果を見たい、とかであれば BigQuery でサクッと叩くのが何よりも早いし楽だなと感じました。今だと BigQuery 上でも簡易的なグラフは描写できるので、意思決定の判断材料としてデータを見るのであればこの方針が手っ取り早いと思います。もちろん、集計方法が人によって異なるなどの問題は発生しますが、そこはデータ基盤側でコントロールしたり、有識者にクエリをレビューしてもらったりで対応できるかなと思います。
おわりに
Looker に慣れてた身からすると Looker Studio はかなり使い勝手が悪いように最初は感じましたが、使っていくと意外と何でもできますし、これが無料で使えるなら、、、って思えるので、ぜひ皆さんも1周回って使ってみてください！ただレポート管理が現状できていないので、そろそろ Pro にアップグレードしたいな〜と最後にぼそっと呟いて終わりたいと思います。
Discussion