2 イチから始めるデータ活用！8週連続ウェビナー イチから学ぶLooker 2024/4/10 クラスメソッド株式会社 アライアンス事業部 布施郁美

自己紹介 3 布施 郁美 クラスメソッド株式会社 アライアンス事業部 エンジニアグループ AlteryxやTableau、Lookerの技術支援

会社紹介 4 オープンな発想と高い技術力によりすべての人々の創造活動に貢献し続ける 名称 代表者 設 立 本 社 拠 点 資本金 従業員 クラスメソッド株式会社 横田 聡 2004年7月7日 東京都港区西新橋1－1－1 日比谷フォートタワー26階 東京、札幌、仙台、上越、名古屋、大阪、福岡、 沖縄、ベルリン、バンクーバー、ホーチミン、バ ンコク、ソウル 1億円 700名（2023年9月現在/グループ全体） 2024年7月開催！ 20周年イベントClassmethod ODYSSEY お申し込みはこちら

データ活用を支えるサービス 5 クラスメソッドではこれらサービス製品の導入・運用をサポートしています。 各サービスを組み合わせて使うことで、より簡単にデータ分析を行う環境づくりをお手伝いします。

本日お話すること 6 1. Looker概要 2.Lookerの特徴的な機能 1. LookML 2.アクセス管理機能 3.キャッシュ 4.Looker Actions 3.個人的に感じるLookerの弱み 4.まとめ

Lookerの概要 7

データ利活用における課題 8 ※ 2021/03/12 Cloud on Air Looker ではじめる外部向けデータ分析サービスのセキュアな基盤作り より

9 Lookerはデータガバナンスの効いたデータプラットフォーム

Lookerの特長 10 No データアップロード データベースに直接クエリを 実行。 Looker上ではデータを持たな いため同期・移動の心配が不 要となり、データガバナンス が保たれます。 LookMLで ロジックの一元管理 データの一貫性を担保し、 信頼性の高いデータを提供。 LookMLでメンテナンスコスト の削減が期待できます。 共有・コラボレーション Webブラウザで担当者自らデー タの探索、ダッシュボードの作 成が可能。 Slackなど多くの既存業務アプ リケーションと連携が可能。

Lookerの特徴的な機能 11 - LookML -

12 LookMLとは、 ユーザーとデータベースの間にセマンティックモデルレイヤーを作成する SQLを抽象化したLooker独自の言語

13 セマンティックレイヤーとは？ (セマンティックモデルレイヤー）

14 セマンティックレイヤーとは、 データの定義を一元管理し信頼性の高いデータを提供するためのレイヤー 営業データ アクセスデータ 外部データ アンケート データウェアハウス データの 取り込み 加工 レポート 分析 「売上金額]= SUM([売上]) -SUM([割引額]) [顧客数]= COUNT([顧客ID]) -COUNT([キャンセル]) etc.. セマンティックレイヤー

15 データをビジネス表現に解釈することで、 ビジネスユーザーも品質の高い分析が可能になる セマンティックレイヤーとは、データソースとエンドユーザーの間にある中間層で、統一されたデータの定義 を一元管理できるレイヤーのことを指します。セマンティックレイヤーの導入によりデータの一貫性を担保 できるだけでなく、ビジネスユーザーにもわかりやすい表現にデータを解釈して提供することができます。 セマンティックレイヤーがない場合 セマンティックレイヤーがある場合 SUM([売上]) SUM([売上]) -SUM([割引額]) DWH 同じ「売上金額」でも 違う結果に DWH 「売上金額] SUM([売上]) -SUM([割引額]) セマンティックレイヤー [売上金額] [売上金額] 利用者は[売上金額]を 選ぶだけで 同じ結果を得られる

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に変換 データベースに リクエスト 性別ごとの 売上を抽出！

画面紹介｜Looker IDE 17

画面紹介｜Explore 18

画面紹介｜ホーム画面・ダッシュボード 19

Looker活用までの流れ 20 ※ ウェビナー「Lookerはじめの一歩」より

Lookerの特徴的な機能 21 - アクセス管理機能 -

アクセス制御と権限の管理 22 ⚫ データアクセス(model set) ◦ ユーザーに表示を許可するデータを制御する機能 ⚫ 機能アクセス(permission set) ◦ データの表示、分析、開発権限など、ユーザーが行える機能を制御する機能 ⚫ ロール ◦ model setとpermission setを組み合わせて作成し、 ユーザーやグループに対して権限を細かく制御できるようになる ⚫ コンテンツアクセス ◦ フォルダの表示や管理を制御する機能 ※参考情報：公式Doc「アクセス制御と権限の管理」、「管理者設定-ロール」

ユーザー属性を使った表示制御 23 ⚫ ユーザー属性とは ◦ グループやユーザーに任意の値を設定する事が可能で、 持っている値によって表示の出し分け等が可能 ⚫ access_filter ◦ ユーザー属性の値に応じて、「行レベルの表示制御」を設定することができる ⚫ access_grant ◦ ユーザー属性の値に応じて、「列レベルの表示制御」を設定することができる ※参考情報：公式Doc「管理者の設定 - ユーザー属性」、「access_filter」、「access_grant」 ユーザー属性名 ： 部署 人事部 …”HR” 営業部 …”sales”

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”でフィルタがかかる

Lookerの特徴的な機能 25 - キャッシュ -

キャッシュの仕組み 26 ⚫ クエリのキャッシング ◦ 発行されたSQLクエリの結果を保持するキャッシュの仕組みがあります ◦ 同じクエリが投げられたら、キャッシュから結果を返すため、データベース に負荷がかからない ⚫ キャッシュの更新頻度 ◦ キャッシュポリシーもLookMLで定義する ◦ 指定したクエリの値が更新されたらキャッシュを更新する ◦ 例） sql trigger: SELECT MAX([取り込み日時]) FROM table ◦ 一定時間が経過したらキャッシュを削除する ◦ 例） max_cache_age: “24hours” ※参考情報：公式Doc「クエリのキャッシング」

Lookerの特徴的な機能 27 - Looker Actions -

Looker Actionsとは？ 28 ⚫ Lookerからサードパーティのサービスにコンテンツを配信できる機能 既存のアクション以外にも、カスタムアクションとして独自の機能を開発可能 ※参考情報：公式Doc「管理設定 - アクション」、「カスタム アクションを作成する」

個人的に感じるLookerの弱み 29

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

逆に… 31 ⚫ LookMLを覚える必要がある ◦ 基本的なSQLやデータの仕様についての理解がほぼ必須 ◦ 事前に分析要件やアクセス権限などを決めておく必要があり、 フィールドの追加・編集は毎回LookMLをいじらなくてはいけない ⚫ DWH / DB を用意する必要がある ◦ 主要なサービスには対応しているものの、ExcelやCSV等は非対応 ⚫ Lookerの可視化表現は良くも悪くもシンプル ◦ 複雑で自由度の高いビジュアライズは出来ないケースも・・ ・初期コストはかかるが、データの一元管理によって正しい分析が行えることは大きなメリット ・Gitでのバージョン管理も可能で、開発者にとってもうれしいポイント ・パフォーマンスは接続先のDWH/DBに依存するため、 チューニングもDWH/DB側で対策すればよい ・分析画面がシンプルゆえ、操作方法も覚えやすい

まとめ 32

33 Lookerはデータカオスの課題がない企業には不向き 一方で、課題あればそれを解決できる素晴らしいソリューション Lookerの特長 • DWH / DB に直接接続して実行する、ガバナンスの保たれたBIツールである • データ品質の高い分析環境を提供し、ビジネスユーザーも分析を実行できる • LookMLでロジックを一元管理することで、データカオスを抑制し誰もが正しい数値で分析可能 つまり… DWH / DB の利用が前提で、データの仕様や活用方針をある程度定義する必要があるため、 Looker導入することで本来の「正しいデータ分析環境」が整えられる Lookerの利用に向いていない人 • 手元のデータでクイックに分析したい • 個人（またはごく少数）でのみ分析を行う予定 • 要件によっては、Lookerとの併用検討もアリ

34