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

イチから学ぶLooker

ikumi
April 10, 2024
380

 イチから学ぶLooker

ikumi

April 10, 2024
Tweet

Transcript

  1. 会社紹介 4 オープンな発想と高い技術力によりすべての人々の創造活動に貢献し続ける 名称 代表者 設 立 本 社 拠

    点 資本金 従業員 クラスメソッド株式会社 横田 聡 2004年7月7日 東京都港区西新橋1-1-1 日比谷フォートタワー26階 東京、札幌、仙台、上越、名古屋、大阪、福岡、 沖縄、ベルリン、バンクーバー、ホーチミン、バ ンコク、ソウル 1億円 700名(2023年9月現在/グループ全体) 2024年7月開催! 20周年イベントClassmethod ODYSSEY お申し込みはこちら
  2. Lookerの特長 10 No データアップロード データベースに直接クエリを 実行。 Looker上ではデータを持たな いため同期・移動の心配が不 要となり、データガバナンス が保たれます。

    LookMLで ロジックの一元管理 データの一貫性を担保し、 信頼性の高いデータを提供。 LookMLでメンテナンスコスト の削減が期待できます。 共有・コラボレーション Webブラウザで担当者自らデー タの探索、ダッシュボードの作 成が可能。 Slackなど多くの既存業務アプ リケーションと連携が可能。
  3. LookML 16 - LookMLはプロジェクト単位で定義され、Gitで管理することができます。 - LookMLで定義した内容に基づいて、LookerがバックグラウンドでSQLを発行します。 view: sample { sql_table_name:

    `schema.dataset_name.table_name` ;; dimension: gender { type: string sql: ${TABLE}.gender ;; } dimension: sales { type: number sql: ${TABLE}.sales ;; } measure: total_sales { type: sum sql: ${sales} ;; } } ▽コードサンプル SELECT gender ,SUM(sales) as total_sales FROM `schema.dataset_name.table_name` GROUP BY 1 LookerがLookMLをもとにSQLに変換 データベースに リクエスト 性別ごとの 売上を抽出!
  4. アクセス制御と権限の管理 22 ⚫ データアクセス(model set) ◦ ユーザーに表示を許可するデータを制御する機能 ⚫ 機能アクセス(permission set)

    ◦ データの表示、分析、開発権限など、ユーザーが行える機能を制御する機能 ⚫ ロール ◦ model setとpermission setを組み合わせて作成し、 ユーザーやグループに対して権限を細かく制御できるようになる ⚫ コンテンツアクセス ◦ フォルダの表示や管理を制御する機能 ※参考情報:公式Doc「アクセス制御と権限の管理」、「管理者設定-ロール」
  5. ユーザー属性を使った表示制御 23 ⚫ ユーザー属性とは ◦ グループやユーザーに任意の値を設定する事が可能で、 持っている値によって表示の出し分け等が可能 ⚫ access_filter ◦

    ユーザー属性の値に応じて、「行レベルの表示制御」を設定することができる ⚫ access_grant ◦ ユーザー属性の値に応じて、「列レベルの表示制御」を設定することができる ※参考情報:公式Doc「管理者の設定 - ユーザー属性」、「access_filter」、「access_grant」 ユーザー属性名 : 部署 人事部 …”HR” 営業部 …”sales”
  6. access_filterとaccess_grantの挙動 24 explore: directory { access_filter: { field: directory.department user_attribute:

    department } } SELECT * FROM directory WHERE directory.department = “sales” ▽営業部の人がaccess_filterが適用されたデータを抽出するケース ▽営業部の人がaccess_grantが適用されたデータを抽出するケース access_grant: departments { user_attribute: department allowed_values: [“HR"] } dimension: salary required_access_grants: [departments] type: number sql: ${TABLE}.salary ;; } 閲覧権限がないため、分析画面で [salary] フィールドが表示されなくなる departmentフィールドの値のうち、 ユーザー属性「department」で保持する値に 一致するものをフィルタ departmentフィールドの値のうち、 “HR”の値を持つ人のみに [salary]フィールドを表示する departmentフィールドに対して、営業部が 持っている属性値”sales”でフィルタがかかる
  7. キャッシュの仕組み 26 ⚫ クエリのキャッシング ◦ 発行されたSQLクエリの結果を保持するキャッシュの仕組みがあります ◦ 同じクエリが投げられたら、キャッシュから結果を返すため、データベース に負荷がかからない ⚫

    キャッシュの更新頻度 ◦ キャッシュポリシーもLookMLで定義する ◦ 指定したクエリの値が更新されたらキャッシュを更新する ◦ 例) sql trigger: SELECT MAX([取り込み日時]) FROM table ◦ 一定時間が経過したらキャッシュを削除する ◦ 例) max_cache_age: “24hours” ※参考情報:公式Doc「クエリのキャッシング」
  8. 個人的に感じるLookerの弱み 30 ⚫ LookMLを覚える必要がある ◦ 基本的なSQLやデータの仕様についての理解がほぼ必須 ◦ 事前に分析要件やアクセス権限などを決めておく必要があり、 フィールドの追加・編集は毎回LookMLをいじらなくてはいけない ⚫

    DWH / DB を用意する必要がある ◦ 主要なサービスには対応しているものの、ExcelやCSV等は非対応 ⚫ Lookerの可視化表現は良くも悪くもシンプル ◦ 複雑で自由度の高いビジュアライズは出来ないケースも・・
  9. 逆に… 31 ⚫ LookMLを覚える必要がある ◦ 基本的なSQLやデータの仕様についての理解がほぼ必須 ◦ 事前に分析要件やアクセス権限などを決めておく必要があり、 フィールドの追加・編集は毎回LookMLをいじらなくてはいけない ⚫

    DWH / DB を用意する必要がある ◦ 主要なサービスには対応しているものの、ExcelやCSV等は非対応 ⚫ Lookerの可視化表現は良くも悪くもシンプル ◦ 複雑で自由度の高いビジュアライズは出来ないケースも・・ ・初期コストはかかるが、データの一元管理によって正しい分析が行えることは大きなメリット ・Gitでのバージョン管理も可能で、開発者にとってもうれしいポイント ・パフォーマンスは接続先のDWH/DBに依存するため、 チューニングもDWH/DB側で対策すればよい ・分析画面がシンプルゆえ、操作方法も覚えやすい
  10. 33 Lookerはデータカオスの課題がない企業には不向き 一方で、課題あればそれを解決できる素晴らしいソリューション Lookerの特長 • DWH / DB に直接接続して実行する、ガバナンスの保たれたBIツールである •

    データ品質の高い分析環境を提供し、ビジネスユーザーも分析を実行できる • LookMLでロジックを一元管理することで、データカオスを抑制し誰もが正しい数値で分析可能 つまり… DWH / DB の利用が前提で、データの仕様や活用方針をある程度定義する必要があるため、 Looker導入することで本来の「正しいデータ分析環境」が整えられる Lookerの利用に向いていない人 • 手元のデータでクイックに分析したい • 個人(またはごく少数)でのみ分析を行う予定 • 要件によっては、Lookerとの併用検討もアリ
  11. 34