Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

D6c5403c0b6ef2f9fd51910ea38323a3?s=128

Takashi Masuda

October 23, 2020
Tweet

More Decks by Takashi Masuda

Other Decks in Technology

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. おしまい