4月から取り組んできたLookerの導入から実装までのお話

2020-10-23 フィードフォース社内技術勉強会のプレゼン資料です。
https://developer.feedforce.jp/entry/2020/10/23/190000

Transcript

1. 4月から取り組んできた Lookerの導入から実装まで のお話
 2020-10-23 FFTT#414 @masutaka
 Redashとも比較

2. 自己紹介
 • 増田貴士（@masutaka）
 • 株式会社フィードフォース
 • さすらいの（会社に席がない）エンジニア
 • 先月から月火金はFeedmaticでLooker、水木はDF/CF
 • 最近の趣味はリハビリとYouTube鑑賞（楽しいぃぃい）
 https://www.feedforce.jp/ 

3. Lookerとは
 • BIツールの一種。他にTableau、Googleデータポータル、Redashなど がある
 • LookMLと呼ばれるDSLでSQLをラッピングするのが特徴
 ◦ 最終的に実行されるSQLはLookerが自動生成する
 • LookMLがデータ分析のスケーラビリティを高め、ビジネスユーザの SQL学習も不要とする
 • 2019年6月にGoogleによる買収合意。2020年2月買収完了
 https://jp.techcrunch.com/2020/02/14/2020-02-13-google-closes-2-6b-looker-acquisition/ 

4. 注: GCPのここからは使えません。

5. 気になる料金
 • 年間何百万円オーダー
 • 基本はユーザ数に応じた課金（SaaSモデル）
 • 導入時はスポットでいろいろかかる
 ◦ JumpStart（実質的に必須）
 ◦ RapidDeployment（今回未受講）
 ◦ Lookerロゴから会社ロゴに変える（今回は見送り）
 ◦ Staging用インスタンス（今回はなし）
 • 営業の方と調整して決まる

6. BIツールとの関わり
 • Redashは割と真面目にHerokuやEC2で運用したことがある
 ◦ Heroku と Redash は相性が良いのでは？という話 / マスタカの ChangeLog メ モ
 • Redashは開発系運用ダッシュボードとしては優秀だけど、ビジネス向けには厳しい という感想
 ◦ グラフやテーブルを作るためにはSQLのスキルが必要
 ◦ 管理するクエリが増えるとひたすら大変になる
 • TableauとGoogleデータポータルは少し検討したことがあるけど、私には難しすぎた
 https://masutaka.net/chalow/2018-12-17-1.html 

7. Redashとの勝手な比較
 
 Redash
 Looker
 SQLの習得が必要
 Yes
 LookML開発者のみ 
 学習コスト
 低い（SQLのみ）
 高い（LookML）
 始め方
 一人で始められる
 フォームから連絡
 料金
 格安
 月何十万オーダー以上 
 OSS？
 Yes
 No
 大きなチーム向け？ 
 No
 Yes

8. 今回の対象データ
 • 広告媒体の数値
 ◦ Criteo, Facebook, Google, Indeed, LINE, RTB House, SmartNews, Yahoo! JAPAN, …
 • 計測ツールの数値
 ◦ Google Analytics
 • その他
 Webアプリケーションが扱うデータと違って、正規化されてい ない汚いデータが多い。今のところETLは使っていない。

9. 最初の勝手なスケジュール感（4月時点）
 6月からお客様に提供するぞー

10. 実際のスケジュール（10月現在）
 今月中になんとかして数社に試験展開しよう...

11. なぜなのか？

12. こんな理由です
 • LookerはSign upしてすぐに実装し、運用を始められる訳ではな かった
 • 4~6週間のPoCを経て、ほぼ必須である最大90日間のJumpStart を受講する必要があった
 • ビジネス職の方は片手間にならざるを得なかった
 ◦ エンジニア（私）は最近までボッチだけど専任だった。
 ◦ 少なくとも今回に関しては兼任は絶対無理

13. 今回の大雑把な流れ
 1. https://ja.looker.com/demo からデモをリクエストし、営業の方 からの連絡を待った（3月頃？）
 2. 事前準備、PoCスコープ定義（3/30）
 3. PoC（4/2~5/27）
 4. JumpStart（6/16~9/23）

14. PoC（4/2~5/27）

15. Proof Of Concept（概念実証）
 
 “新たな概念やアイデアの実現可能性を示すために、簡単かつ不 完全な実現化（または概要）を行うこと。あるいは原理のデモンス トレーションによって、ある概念や理論の実用化が可能であること を示すこと”
 https://ja.wikipedia.org/wiki/概念実証 

16. やったこと
 • SEの方とペアプロして、LookML開発を体験する
 • 実際の広告数値を使って試作する
 • LookML質疑応答
 • ビジネスへの展開の認識合わせ

17. 今回のPoCタイムライン
 4/15 9:00-10:30 Kick off兼初回ペアプロ 4/22 10:00-11:00 PoC 1st Check In 5/7 13:00-14:00 PoC 3rd Check In 4/30 13:00-14:00 PoC 2nd Check In 5/27 最終打ち合わせ (契約判断) 4/2 10:00-11:00 事前準備 PoCスコープ定義 この間にLookerと BigQueryを連携してお く 5/19 15:00-16:00 PoC Final Check In ※Looker社からの資料を引用＆加筆 

18. PoCへの雑感
 • 社外の方と初めての言語でのペアプロはかなり緊張した。こ の後のJumpStartが本番とは知る由もなく...
 • 我々の導入はほぼ決まっていたため、PoCの期間はもう少し 柔軟に減らして頂いても良かった気はする
 • すべての回をesa記事に残さなかったことは、少々悔やまれる （日報に書いてしまった）

19. JumpStart（6/16~9/23）

20. JumpStart前後の変化
 • 受講前の自分「本当に必要なの？ポジショントークなんじゃな いの？」
 • 受講後の自分「受講してなかったら、とんでもないものを作っ ていた。危なかった...」
 JumpStartを受けずに、あとで苦労した 会社さんもいるみたい？

21. JumpStartの内容
 • 30時間が基本で、最長90日間
 • 主体は我々
 • 超優秀なコンサルタントの方が、一通りの説明をしてくれて、 LookMLのレビューや相談に乗ってくれる
 • ビジネスユーザー向けトレーニングもある
 • ちなみにRapidDeploymentは主体が逆らしい？

22. 今回のJumpStartタイムライン
 ※Looker社からの資料を引用 

23. JumpStartの料金
 • エンジニアを雇うくらいの料金はかかる
 • でも期間限定だし、効果や、受講しないデメリットを考えると安 い気はする

24. JumpStartで実践したこと
 • JumpStart前にLooker Training（英語）を全て受講した
 • ほぼ全部の回で前日に質問をSlackで送った
 • 全部の回でesa記事を作って、Q&Aや学んだことを記録した。全て録 画を頂けたのはありがたかった
 • PoC当初から会社からLooker専任にして頂けたことは良かった。と は言え、最初はそこまでやることはないので、専任はPoC中盤くらい からでも良いかも
 https://training.looker.com/ 

25. LookML

26. LookMLへの印象
 • PoC前: Cof◦eeS◦riptみたいな中途半端なやつなんじゃない の？SQLで全部書けるならそうしようかな？
 • PoC後: レイヤーが厚すぎず薄すぎず適切だ。設計を間違えな ければ、SQLの能力を何倍にも高められる。SQLはアセンブラ

27. LookMLの例
 view: orders {
 sql_table_name: `feedmatic-looker.sandbox_masutaka.orders` ;; 
 
 dimension: order_id { 
 primary_key: yes
 type: number
 sql: ${TABLE}.order_id ;; 
 }
 
 measure: count {
 type: count
 drill_fields: [order_id] 
 }
 }
 

28. 自動生成されるこんなSQLにも臆さなくなった

29. 軽くデモする

30. Symmetric 集計

31. Symmetric 集計
 • LookerをLookerたらしめている最大の機能（大げさ）
 • ビジネスユーザがSQLを書かずに済む
 • 正規化されていない汚いデータも扱える
 • 最初にこの仕組みを知った時は感動しました・・・！

32. https://help.looker.com/hc/en-us/articles/3600237 22974
 頑張って説明する

33. 2つのテーブル
 order_id user_id total order_date 1 100 $50.36 2017-12-01 2 101 $24.12 2017-12-02 3 137 $50.36 2017-12-02 $124.84 order_id item_id quantity unit_price 1 50 1 $23.00 1 63 2 $13.68 2 63 1 $13.68 2 72 1 $5.08 2 79 1 $5.36 3 78 1 $50.36 7 $111.16 order_items orders
34. order_idでJoinする
 order_id user_id total order_date item_id quantity unit_price 1 100 $50.36 2017-12-01 50 1 $23.00 1 100 $50.36 2017-12-01 63 2 $13.68 2 101 $24.12 2017-12-02 63 1 $13.68 2 101 $24.12 2017-12-02 72 1 $5.08 2 101 $24.12 2017-12-02 79 1 $5.36 3 137 $50.36 2017-12-02 78 1 $50.36 増えてる $223.44 7 $111.16
35. Lookerだと？
 増えてなーい！ (^^)v
36. なぜなのか？

37. ここのSQL

38. Lookerが生成するSQL
 SELECT COALESCE(ROUND(COALESCE(CAST( ( SUM(DISTINCT (CAST(ROUND(COALESCE(orders.total ,0)*(1/1000*1.0), 9) AS NUMERIC) + (cast(cast(concat('0x', substr(to_hex(md5(CAST(orders.order_id AS STRING))), 1, 15)) as int64) as numeric) * 4294967296 + cast(cast(concat('0x', substr(to_hex(md5(CAST(orders.order_id AS STRING))), 16, 8)) as int64) as numeric)) * 0.000000001 )) - SUM(DISTINCT (cast(cast(concat('0x', substr(to_hex(md5(CAST(orders.order_id AS STRING))), 1, 15)) as int64) as numeric) * 4294967296 + cast(cast(concat('0x', substr(to_hex(md5(CAST(orders.order_id AS STRING))), 16, 8)) as int64) as numeric)) * 0.000000001) ) / (1/1000*1.0) AS FLOAT64), 0), 6), 0) AS orders_total_total, COALESCE(SUM(order_items.quantity ), 0) AS order_items_total_quantity, COALESCE(SUM(order_items.unit_price ), 0) AS order_items_total_unit_price FROM `feedmatic-looker.sandbox_masutaka.orders` AS orders LEFT JOIN `feedmatic-looker.sandbox_masutaka.order_items` AS order_items ON orders.order_id = order_items.order_id LIMIT 1 これがポイント

39. ポイントはSUM DISTINCT
 WITH tmp AS ( SELECT 200 AS price UNION ALL SELECT 300 UNION ALL SELECT 300 ) SELECT SUM(price) from tmp -- -> 800 WITH tmp AS ( SELECT 200 AS price UNION ALL SELECT 300 UNION ALL SELECT 300 ) SELECT SUM(DISTINCT(price)) from tmp -- -> 500
40. 理解してくれ
 それぞれのTotalにユニーク性を与え、
 Order Idが1と3の$50.36を区別して合計を出した。

41. そもそも
 • Totalを使わずに、QuantityとUnit Priceで計算すればよいだけ の話
 • でもLookerが扱うデータは常にきれいではないし、ユーザは データ構造を把握し切れてもいない

42. 代わりに必要なこと（制約）
 • primary_key
 ◦ いわゆるidを必ず設定する
 ◦ 広告数値だとid的なカラムが存在しないことが多い
 ◦ データの理解とSQLでうまく確認すればなんとかなる
 • relationship
 ◦ 1:1, 1:Nのような関係を必ず設定する

43. 今回作ったLookML
 https://gist.github.com/masutaka/6d5b7483337cfaff a661da95fce7e3cf

44. おしまい