「あつまれ Lookerの森 #3」 オンサイト行ってきました記録

what

• 6/27に開催された「あつまれ Lookerの森 #3」のオンサイト参加ログです
• 当日の雰囲気や登壇者の方々の発表内容等を簡単にまとめたものになります

あつまれ Lookerの森とは

Jagu'e'rのデータ利活用分科会が主催するLookerにフォーカスを当てた勉強会です
※ Jagu'e'r: Google Cloudのユーザー会。Lookerだけでなく様々なGoogle Cloud製品に関したコミュニティやイベントを企画・開催しています
今回は3回目ということでしたが、私は初めての参加でした。
コミュニティイベントというのも初参加だったため、「どんな雰囲気なのだろう」と少々ドキドキしていました。

イベント内容

登壇者4名によるLookerの活用事例や取り組みについて発表されました。

• 株式会社マネーフォワードさん『Looker、”単なるBIツール”としての認識を超えて 〜現場で発見した活用へのヒント〜』
• 株式会社TimeTreeさん『データモデリングで、もっと使いやすい Looker』
• 株式会社Hacobuさん『「拠点横断アナリティクス」リリースまでの3ヶ月』
• 株式会社LegalOn Technologiesさん『そのLooker構成、世界で戦える？～グローバル展開のための設計術～』

※登壇資料が発見できたものについては、スライドのURLを記載しています。

マネーフォワードさん『Looker、”単なるBIツール”としての認識を超えて 〜現場で発見した活用へのヒント〜』

Looker導入から5年。その時間の中で得られた失敗や知見、そして再チャレンジについて共有されました。
特に「Lookerは単なるBIツールではない、BI+セマンティックレイヤー」というのが、今回特に熱く勝たれていました。

【内容まとめ】

• Lookerとの5年間は順風満帆にはいかなかった
  • 初期導入→失敗→再投入　という時期があった
  • 再チャレンジとして過去の失敗を振り返って使ってもらう活動をしている
• Lookerは単なるBIツールではない、BI+セマンティックレイヤー
  • 今では当たり前だが、5年前はLookerはBIツールなイメージが強かった
  • 当時はセマンティックレイヤーの部分を使いやすくする取り組みができていなかったため、使いづらい、とっつきづらいと感じた
• 失敗談
  • 1: おなじExplorerが乱立する
    • 商談を表すExplorerがいっぱいでてきてしまい、欲しいデータがどこにあるのかわからなくなってしまった
    • 解決策
      • ビジネスイベントとExplorerを1対1の関係にするようにルールを決めた
      • ドメインごとにLookMLの管理者を置くようにしている
  • 2: Lookerで何でも可視化しようとする
    • LookerをメインのBIとしていたので何でも可視化しようとしてしまった
    • Lookerは得意・不得意が明確
      • 得意: 既にLookMLができている場合
      • 不得意: LookMLができていない、データの加工が必要な場合
      • 不得意な面で利用しようとすると、LookMLの改修コストが見合わなくなってしまった
    • 解決策
      • Lookerの得意な事に集中させ、スポットでの可視化利用等についてはLooker Studio等の別BIを利用
  • 3: 指標の二重定義で指標の数字が合わない
    • Lookerとデータマートの両方で同じ指標を定義したが片方の定義しか更新されず、双方の数字が合わなくなってしまう自体が発生
    • 修正も実施したが、信頼性が下がってしまう結果となった
    • 解決策
      • 指標の定義に関してはLooker側に集約、Lookerだけで保持することにした
• LookerはただのBIツールではない
  • セマンティックレイヤーとうまく付き合っていくことが大事

TimeTreeさん『データモデリングで、もっと使いやすい Looker』

「データモデリングを利用してLookerをもっと使いやすくしよう」という内容で、Lookerを使いやすくするアプローチが紹介されました。
この発表の中では「計算は高くてストレージはチープ(やすい)」というワードを起点として様々な知識が紹介されました。

【内容まとめ】

• 計算は高くてストレージはチープ
  • JOINが高い(値段的な意味で)
  • (高いので)中間テーブルでJOINしておく
  • (JOINをしなくていいように)中間テーブルをパターン化する
• 最適化されていないJOINは高くつく
  • 規模が大きいテーブルだと、JOINの前にフィルターをすることが推奨される
  • なぜJOINするのか?
    • Explorerは色々な属性を使ってデータを見ることができる
    • 属性は、集計対象とは別のテーブルからJOINして持ってくることが多い
• 毎回JOINするなら非正規化するのが有効
  • よく使う属性を非正規化した中間テーブルを作ることは、コスト削減に繋がる
• ディメンショナルモデリングのアプローチ
  • 矛盾の解消
    • 何を作るか、どう作るかを一定のパターンに落とし込む
    • LookerのExplorerは、関心のあるビジネスイベントを表す一つのテーブルに、分析軸として使いたい属性をいくつも結合させる
  • ビジネスイベントを特定する(ファクト)
    • 分析の中心となる関心事を定める
  • 分析の切り口を特定する(ディメンション)
    • イベントを分析するための属性情報を整理する
• セマンティックレイヤーだから変えやすい
  • 「どういうものを提供するのか」を決めれれば、ダッシュボードは壊れることはない

Hacobuさん『「拠点横断アナリティクス」リリースまでの3ヶ月』

https://speakerdeck.com/hacobu/deng-tan-zi-liao-fan-zhong-da-di

HAacobuさんが提供する物流向けプラットフォーム「Hacobu MOVO」の1機能である「拠点横断アナリティクス」。これはLookerの埋め込み機能を利用した顧客向けの分析機能です。
元々は社内向用のLookerダッシュボードだったそうですが、これを顧客向けの機能として実装するまでの苦難や得られた知見が紹介されました。

【内容まとめ】

• リリースまでは約3ヶ月間。様々な苦労の連続だった
  • 社内用ダッシュボードのデータのマスキングをしようとした
    • 本番相当量のデータだとマスキングロジックが返ってこない問題が発生
      • パフォーマンス・チューニングが必要
      • 複雑なパイプラインのパフォーマンス・チューニングはとても難しい…
    • 従来データマートをディメンショナルモデルにフルリプレースすることを決断
    • フルリプレース完了
      • しかし、Lookerと既存機能のデータで差異があった…
    • Lookerで苦労したよりも、データモデリングで苦労した
• 苦労した点
  • 1: データ項目に対する認識ズレ
    • 1つの単語でも、関係者間での解釈が異なってしまっていた
    • 解決策
      • 認識のズレは期待値のズレにもつながるため、図を書くなど時間をかけて定義を明確化・認識をしっかり合わせた
  • 2: データマートをそのまま適用しようとしたこと
    • 社内向けに最適化されたデータマートをそのまま機能として利用しようとしたが、拡張性の面で問題が発生した
    • 複雑なリネージをLookerで出そうとした
    • 解決策
      • 従来データマートをディメンショナルモデルにフルリプレースした
  • 3:データスコープを単なる時間軸だけで捉えていたこと
    • 「特定期間」でデータを抽出と言っても、「どのタイムスタンプを基準にするか」で結果が大きく変わってしまった
      • 今回においては正しくはトランザクションのタイムラインで捉えるべきだった
    • 解決策
      • 時間軸の定義を明確化することが重要
• 今回は「既存の移行」というよくある失敗を踏んで苦労した
• 普段使っているものでも、ちゃんと意識て理解しようとすると認識がズレていることもある
  • 図などをたくさん駆使して、時間かけても良いので認識を揃えた方が良い

LegalOn Technologiesさん『そのLooker構成、世界で戦える？～グローバル展開のための設計術～』

https://speakerdeck.com/legalontechnologies/looker-architecture-for-global-expansion

LegalOn Technologiesさんでは法務・契約業務や経営・コーポレート支援のサービスを提供しています。
今回はサービスのグローバル展開に向けたLookerプロジェクトの分割構成や、複数リージョン対応を効率的に行うために実施したことについて紹介されました。

【内容まとめ】

• 元々Lookerのプロジェクトはプロジェクト単位で1つだったが、Lookerのプロジェクトは増えれば増える程管理コストがかかる問題があった
  • Viewだけでも数千個存在しており、開発に時間がかかっていた
• グローバル展開に向けたLookerの構成検討
  • 日本での対応を踏襲した場合、リージョンごとにLookerプロジェクトを分割する必要がある
    • BQのプロジェクト・データセットのリージョンは別に設置するが、グローバル・サービスのテーブル名とテーブル構成は同じになることを想定
• グローバル展開に向けてのアプローチ
  • Lookerプロジェクトの分割
    • プロジェクトを以下のように分けた
      • テーブル定義をimportするだけのプロジェクト
      • Explorer等を定義するためのプロジェクト
  • local_dependencyを利用した動的な参照元を切り替え実現するための仕組み
    • local_dependencyという別のLookerのローカルプロジェクトをインポートするパラメータを利用し、インポート側の接続情報を上書きするようにした
• Lookerのプロジェクトをうまく分割することで、開発効率を上げつつ、運用コストを削減してグローバル展開が可能
  • リージョンごとにどこまで共通化したルールとするか、社内での方針確定は必須

まとめ

今回の発表内容で特に印象に残ったのは以下でした。

• セマンティックレイヤー
• ディメンショナルモデリング
• 定義について、認識合わせの大切さ
• データモデリング

また、それぞれ事例や体験したことは違いますが、共通して次の事が挙げられていたなと思いました。
「Lookerは単なるBIツールではない」
「セマンティックレイヤーも大事になる」

今後、Lookerを触る上でこれらのことは大事になりそうだなと、強く感じました。

余談: 個人的な感想など

Lookerがメインのイベントということで、存在を知ったときは「これはいかねば!」と即応募しました。
(イベント発表から数日後にオンサイト申し込みしたので「先着間に合っただろうか?」と少々心配になりました)

自分がまだまだLooker駆け出しの民もあり、Lookerを使っている企業の方や知見もなかなか見つからない…いるのか…?と思っていました。
本当に身近にいなかったんです、Looker触ってる方。
しかし、今回のイベントを通じてLookerを触ったことがある・これから活用しようとしているという方々が沢山いることがわかってとても嬉しかったです。

イベント後の懇親会も参加しましたが、皆さん優しかったです…駆け出しの民に色々と教えてくださりすごく勉強になりました。
本当にありがとうございました!

Lookerについてまた学びや挑戦をしてみたくなるとても良いイベントでした。
次の開催も計画されているようなので、また参加できる日を楽しみに待ってます!

P.S.
オンサイト参加特典?でLookerタオルとステッカーを頂きました。
まさかタオルを貰えるとは思わなかったです…フカフカでした