Zenn
🐳

用語を整理しながら学ぶLooker

2023/07/27に公開
Google Cloud
Google Cloud
Google
Looker
tech

Lookerの基礎をおさらい

はじめに

この記事では 用語を整理しながらLookerの基礎を学習していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。

なお、内容につきましては2023年7月21日時点の調査内容で記載しております。あらかじめご了承ください。

そもそもLookerとは

Google Cloudが提供するBIツールです。元々はデータ分析で有名なLooker(Looker Data Sciences) 社が提供していたサービスでしたが、Googleに買収された際にGoogle のサービスの一つとなりました。

なお、同じLookerでもLooker Studioという類似の製品もありますが、今回紹介するLookerはStudioではないほう、旧Google データポータル(Looker Studio )ではないほうです。

Googleでデータを可視化するためのBIツールと覚えておくと良いでしょう。

補足：BIツールって何？

Business Intelligence ツールの略で要するに社内/社外にあるデータを可視化してまだ見えていない新しい価値をデータから掘り出すための手段であり道具です。

昨今ではLookerのようにクラウドプロバイダーが提供するものもあれば、クラウドの外からデータ分析を支援するサービスも存在します。
詳細には説明しませんが、興味のある方は調査してみると良いでしょう。

なお余談ですが、筆者の経験ではLooker以外にDomoという製品やRedashという製品を扱ったことがあります。※DomoはDWHの製品とも言える

Redashについては弊社が公開事例として挙げている運用分析プラットフォームで活用しています。

クラウド監視・運用保守の品質がさらに進化。AMS 適用やインシデント対応品質を高める「運用分析プラットフォーム」を短期間で構築

Lookerの仕組み

では話を戻してLookerではどのようにして分析ができるのでしょうか。

LookerはLookMLプロジェクトを作成してModels、Views、Dashboadsを作成して可視化します。
Models にあるViews をExploresで細かく閲覧したり、集計したりLookを作成できたりします。ViewsではLookerがデータソースとしているテーブルを仮想的なテーブルとして保存することでデータベースでいうところのクエリのような実行ができます。
Dashboads ではLookを並べて一度に閲覧できるようにしたり、用途毎に閲覧する内容を変更できます。

LookML？Models Views Dashboards ？Exploresで細かく閲覧？Look？わからないことが多いですよね。では順番に見ていきましょう。

用語説明その前に

まず最初にLookerではデータソースとなるデータを管理する最小単位としてLookMLプロジェクトというものがあります。
LookMLプロジェクトのLookMLとはLooker が提供するデータモデリング言語のことですが、そんなに難しく考える必要はありません。

LookML = Lookerのモデリング言語
LookeMLプロジェクト=LookMLを保存するプロジェクト

LookMLとは

ではLookMLプロジェクトのLookMLとはどんなものなのでしょうか。
ここではまず、公式の資料を引用して見ていきます。

LookML は、Looker Modeling Language の略です。セマンティック データモデルを作成するために Looker で使用される言語です。LookML を使用して、SQL データベース内のディメンション、集計、計算、およびデータの関係を記述できます。Looker は、LookML で記述されたモデルを使用して、特定のデータベースに対する SQL クエリを作成します。

LookML は make のような依存関係言語で、C や Ruby といった命令型言語とは反対の性質を持ちます。LookMLはデータモデリングのために定義済みのデータタイプと構文を提供します。 LookMLの構文は構造が明瞭で学びやすくなっています。 （LookML を理解するためにプログラミング言語の経験は必要ありません。知っておくべきことはすべてここに記載されています。）LookML は個々の SQL ダイアレクトには依存せず、SQL 式をカプセル化してあらゆる SQL 実装をサポートします。

データ分析のために、LookML では DRY 原則（Don't Repeat Yourself）に基づくスタイルを促進しています。つまり、ある箇所に 1 回 SQL 式を書けば、Looker がこのコードを使ってその場に応じた SQL クエリを繰り返し生成していきます。ビジネス ユーザーはその結果を使用して Looker で複雑なクエリを作成し、SQL 構造の複雑さではなく、必要なコンテンツだけに焦点を当てることができます。

LookMLの紹介 公式引用

たくさん書いてあって少しだけ驚きますが、LookMLは以下のように説明できます。

  • Lookerで利用されるモデリング言語
    • データ定義(スキーマ)を記述する言語
  • SQLを内包するデータ定義言語
  • 複雑なSQLを書くことなく、DRY原則に基づいて複雑なクエリを作成できる

つまり、SQLをほとんど書くことなくデータの取り出しや加工を実行できます。そして、LookMLはlkmlファイルによってプロジェクト上に保存され、管理されます。

lkmlファイルの概要

lkmlはLookMLを定義する言語ですが、実際にはModelやView、dashboardを定義するために利用します。
以下の例は公式資料からの引用ですが、ordersというViewの定義が書いてあります。

##########################################################
# FILE: orders.view.lkml                                 #
# Define the dimensions and measures for the ORDERS view #
##########################################################
view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
  dimension: customer_id {      # field: orders.customer_id
    sql: ${TABLE}.customer_id ;;
  }
  dimension: amount {           # field: orders.amount
    type: number
    value_format: "0.00"
    sql: ${TABLE}.amount ;;
  }
  dimension_group: created {                # generates fields:
    type: time                              # orders.created_time, orders.created_date
    timeframes: [time, date, week, month]   # orders.created_week, orders.created_month
    sql: ${TABLE}.created_at ;;
  }
  measure: count {             # field: orders.count
    type: count                # creates a sql COUNT(*)
    drill_fields: [drill_set*] # list of fields to show when someone clicks 'ORDERS Count'
  }
  measure: total_amount {
    type: sum
    sql: ${amount} ;;
  }
  set: drill_set {
    fields: [id, created_time, customers.name, amount]
  }
}

view{〜}という構文でViewを定義し、dimensionやdimension_group、measureはViewを構成するカラムとなります。(つまりは列情報の名前です。)

dimension(dimension_group)とmeasureですが、最初の理解では生の列データと計算列という理解でOKです。なお、dimensionとdimension_groupは厳密には別のものですが、別の機会に解説します。

Modelとは

Viewを解説しましたが、Viewはそのままでは扱えません。Viewに対してはexploreを実行する必要があるのですが、exploreを実行するにはModelにViewを書く必要があります。

また、Lookerがデータソースを認識するためにもModelが重要となります。
ModelもViewと同様にlkmlファイルで管理されます。具体的には以下のような内容になります。

connection: "data_src"

# include all the views
include: "/views/**/*.view.lkml"

datagroup: default_datagroup {
  # sql_trigger: SELECT MAX(id) FROM etl_log;;
  max_cache_age: "1 hour"
}

persist_with: default_datagroup

explore: view_test {}

explore: view_service {}

explore: test {}
項目 説明
connection Lookerとデータソースの接続
include Model への include、上記のModelではviewをinclude
datagroup データグループ
persist_with キャッシュの設定
explore ModelにViewを登録する。厳密にはModelからViewを探せるように設定する項目

ここまでで概ね理解できたとおり、Modelはデータソースへの接続情報やViewの管理、キャッシュポリシーを管理しています。また、exploreでViewを使うための設定もModelで管理することになっていますが、そもそもexploreとは何のでしょうか。

exploreとは

簡単に説明するとViewの中身を詳細に閲覧するために
ダッシュボードに必要な可視化を作成したり、データをフィルターするなどの機能のことです。

このexploreで可視化してデータとして保存したものをLookと呼びそして、ダッシュボード上で管理できる最小単位となります。

※exploreの画面
image.png

exploreではViewから取り出せるDimentionやMeasureを選択して様々な可視化を利用することでLookを作成できます。
作成したLookはDashboard上に載せることができ、用途毎にLookをDashbordに束ねて掲載できます。

これで概ね、Looker上でデータを可視化できます。

「でもなんだろう。データから何かを抽出するのにLookMLを使わないとダメなのかと思うとちょっと難しいな」とそう感じる人もいると思います。※筆者の私もそうでした！

そこでLookerにはSQL RunnerというSQLを直接実行する機能があります。

SQL Runnerとは

これまでに説明した機能でだいたいの可視化はできると思いますが、SQL Runnerは「もっと細かく計算式を組んだり、もともと持っているSQLの資産を再利用したい」という方にはもってこいの機能です。

※SQL Runnerの画面

image.png

使い方は至ってシンプルでクエリと表示されているすぐ下のテキストエリアに実行したいSQLを書いて実行するだけです。

ただし、注意点としては記載するSQLは接続先(データソース)を提供しているDBが解釈できるようにSQLを書く必要があります。

ex) 接続先がMySQLならMySQLの構文でSQLを書かないといけません

上記の画像ではAWSが提供するAmazon AthenaをLookerでODBC接続してAthenaクエリを実行できるようにしています。つまり、Lookerの画面ではありますが、記載するSQLはAthenaクエリに準拠したSQLを入力する必要があります。

SQL Runnerで取り出したデータはLookMLプロジェクトに追加したり、そのままexploreを実行できます。

もちろん、DashboardにもSQL Runnerで作成したLook(可視化)を掲載できます。
いろんなものを掲載できるDashboardとはなんでしょうか。Looker ではどのようなポジションになるのでしょうか。

Dashboardとは

今までの話をまとめるとダッシュボードでは以下のようなことができます。

  • exploreによりView をLookとして保存する。保存したLookをダッシュボードに掲載する
  • SQL Runnerから作成したLookをダッシュボードに掲載する

上記の2点ですが、他にも掲載したLookに対してフィルタを実行できます。
つまりはLookを掲載する機能以外にもLookの表示を変更するための機能がダッシュボードにはあります。

ダッシュボードには他にも様々な機能がや設定項目がありますが、別の記事で解説したいと思います。

まとめ

  • LookerはGoogle のBIツールである
    • 別の製品としてLooker Studio(旧Google データポータル)があるが別の製品
  • LookerではLookMLプロジェクトを使う
  • LookMLプロジェクトではLookMLを管理している
  • LookMLはLooker独自のモデリング言語である。ModelやView、Dashboardを定義する
    • lkmlファイルが実態となる
    • ModelではViewを管理する
    • Viewはexploreを使うことでLookを作成できる
    • LookはDashboard上におく可視化の最小単位のようなもの
  • SQL Runnerを使うとSQLベースのより詳細な分析が可能となる
    • SQLは接続先に合わせて書く必要がある

所感

Lookerは難しい部分があって理解するのがなかなか大変でした。※筆者の私も苦戦しました。

余談ですが、他のBIツールを触っていた時に「分析結果やデータ定義を再現よくそして、設定内容をコードで管理したい。それこそインフラのIaCのように管理したい」と考えていました。
私が考えていたことを簡単に述べるとデータ分析 as CodeもしくはETL as Codeみたいなことです。※SQLではなく、分析環境を忠実に再現することでもない。

データの定義内容と併せてデータへの操作内容を記録して管理できることが私の考えでそれがLookerではできるというところには驚きしかありませんでした。

コードで管理できれば、リポジトリ管理ができるので記録としても使えますし、元に戻す時にも使えますので「そういうのがあったいいな」と思っていました。

今回は以上です。

iret.meida 内関連記事

おわり

Discussion