Looker ノススメ
はじめに
Looker Advent Calendar 2019 兼 YAMAP エンジニア Advent Calendar 2019 1日目の記事です。 （元々 Qiita に書いていたもの を、こちらに引っ越しました）
こんばんは、🔺YAMAP 分析チームの松本です。好きな山は赤岳（八ヶ岳）です。 YAMAP は 2019-11 から、次世代 BI ツール Looker を導入しました。
この記事では、YAMAP で導入前に感じていた課題とその解決方法を中心に、Looker の素晴らしさを紹介したいと思います。
参考までに、YAMAP の概況
Looker をはじめ、 BI ツール導入を検討している方の参考になればと思い、会社の規模などを共有してみます。
Looker 導入前の課題と、どう解決するか
私達は、おおよそ以下のような課題を感じていました。
それがこうなります、Looker 凄い 🎉
以下でそれぞれ説明したいと思います。 なお LookML については、分かりやすくまとめて頂いている記事 等ありますので、そちらをご参照下さい 👀
a. データ基盤をみんなに使ってもらうには敷居が高い
私達は BigQuery にデータ基盤を構築し、2019-06 から運用を始めました。 （構築に当たっては 私の考えた最強のログ＆モニタリング設計 - 下町柚子黄昏記 by @yuzutas0 がとても参考になりました。この場を借りてお礼を 🙏 ）
ですがデータが1箇所に集まったのは良いものの、
- 何がどこにあるのか難易度が高く、分析者以外が使うのに敷居が高い
という課題がありました。
どう解決するか？
これは 「分析者が LookML を定義すれば、それを元に Looker が UI が提供してくれるので、利用者はポチポチでグラフが作れる」 という特徴により、解決できます。
b. Redash でクエリが乱立、メンテが大変
私達はもともと Redash を使っていました。 Redash は無料ですし、とても素晴らしかったのですが、運用を重ねるにつれ、
- 似たようなクエリが増殖
- どれが使われているのか分からない
- スキーマに変更があった際、参照しているクエリを修正して回るのが辛い
という課題が出てきました。
どう解決するか？
これも LookML が分析用 Object-relational mapping の如く、グラフとテーブルの間に入ってくれるので、テーブルに変更があったときは LookML を修正すれば、それを利用しているグラフを一括修正できる ということで解決できます。
また Looker には Look（グラフ） ごとのアクセス数を可視化する機能が備わっており、使われていない Look を整理するのにとても便利そうでした。
c. 人によってクエリの書き方が異なり、信頼性を担保しにくい
YAMAP では実際
- SQL を書く人の技量により、間違った集計を行ってしまう
- 技量が高くても分析対象のテーブルの細かい仕様までは把握しきれておらず、間違った集計を行ってしまう
といったケースが有りました。 （例えば、論理削除フラグや、契約履歴テーブルに "契約解除" でもレコードが挿入されるなどの仕様の把握漏れで、集計が水増しされてしまう. etc.）
こういう事が重なると、誰かがグラフを書いた時に「そもそも集計合ってるんだっけ？」といった確認作業が大変になるのも残念です。
どう解決するか？
これまた テーブル定義に精通した分析者が LookML を定義し、利用者はそれを使ってグラフを書く といった明確な分担ができることで、集計の信頼性が格段に担保しやすくなります。
d. 細かい集計依頼が多く、骨太な分析に時間を使えない
先に紹介したように、YAMAP は有料会員、登山保険、EC、営業と事業が多く、各チームから分析チームへ細かい集計依頼もコンスタントに来ています。
そして、YAMAP 分析チームは↓2つのミッションを掲げています。
- データ分析で事業の意思決定にコミットする
- ユーザーが投稿するデータを価値に変え、ユーザーに還元する
しかし先述したように現状分析チームは2人だけなので、各チームからの集計依頼が多くなると、2 に時間を使えなくなるという危機意識がありました。 （僕たちは 2 を "骨太な分析" と呼んでいます）
どう解決するか？
今まで書いたことでお分かり頂けると思うのですが、Looker は データの民主化 という視点で、とても強力です。 "LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる 訳です。 今まで Looker を使ってみて、このバランス感は本当に素晴らしいと感じます 💜
ということで、Looker を各チームに浸透させ、簡単な集計や分析はチーム内で完結できるように持っていくことで、"骨太な分析" の時間も確保していく方針です。
加えて LookML はとても優秀で、クエリをかなり動的に生成してくれます。 故にお決まりの集計やデータ抽出業務は、グラフ（Look）の FILTERS パラメータを良い感じに用意してあげると、仕組み化しやすいです。 （Redash にもパラメータ機能はありますが、Looker はパラメータの選択状況に応じて JOIN 文レベルで切り替わってくれるので、柔軟に仕組み化できます）
まとめ
YAMAP での BI の課題と、それをどう解決できるのかを中心に、Looker をご紹介しました。
使えば使うほどに素晴らしいツールだと驚くのですが、特に
- "LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる
点がミソなのかなと感じています。
しっかり使いこなして、みんなの登山をより安全にしていきたいと思います。 🗻 明日の Looker Advent Calendar 2019, YAMAP エンジニア Advent Calendar 2019 もお楽しみに！
