このセクションでは主に、そもそもLookMLとは？について紹介します。
Lookerの利点を理解することで、LookMLがどのような役割を担っているかについて学ぶことができました。

1.1 LookerとLookML

講義の中で、Lookerの利点と機能はそれぞれ大きく4つに分類されることが紹介されました。

• 利点
  
  • データスタック
  • アジャイルモデリングレイヤ
  • データガバナンス
  • データの民主化
• 機能
  
  • ウェブインターフェース
  • データのスケジュール設定と配信
  • アプリケーションへのLooker コンテンツの埋め込み
  • Looker API

まず4つの利点については大まかに、以下の理解をしていただければと思います。

• データスタック：多様なデータソースからデータを取得できること
• アジャイルモデリングレイヤ：「データソースから取得した値をLooker上でどのように扱うか」を定義できること
• データガバナンス：上記の定義が組織内で統一できること
• データの民主化：データ配信のための機能が複数(4つ)提供されていること

このうち、LookMLは「アジャイルモデリングレイヤ」と「データガバナンス」という2つの利点を提供するための仕組みです。
例えば、「データソースから取得した”合計金額”という値を、Looker上では税込みの値として表示したい」といったケースで力を発揮します（アジャイルモデリングレイヤ）。

また、このような操作をLooker Studio等の他のBIツールで実施しようとすると、グラフ単位に”合計金額”の定義が必要となります。そうすると、グラフAでは”合計金額(税抜き)”であるのに対し、グラフBでは”合計金額(税込み)”といったように、同じ”合計金額”でも異なった値が表示されてしまいます。Lookerでは、LookMLによって組織内で定義が統一できるため、グラフ間で値の解釈が変わることがなくなります（データガバナンス）。

ここまでの内容を「LookerにおけるLookMLの役割」を踏まえて下図のように整理しました。

Lookerは「さまざまなデータソースから取得した値に対し、LookMLによって解釈を定義し、複数の機能で可視化を提供する」ツールと考えることができます。

またセミナーの中では、各利点と機能は下表のように紹介されました。

利点

機能

セクション２からは、実際にLookMLでどのようにデータの解釈を定義するのか」について、セミナーで紹介された内容を中心に紹介していきます。

（1.2~1.4 は、LookML開発のためにLookerが提供している画面の紹介となりますので、読み飛ばしていただいても大丈夫です。）

1.2 Lookerのユーザーインタフェース

LookerにはLookMLの開発に使用されるユーザインタフェース（LookerIDE）が用意されています。

モデルやビューと呼ばれる、データの可視化に使用される要素を修正することで、データの解釈を定義します。

（具体的な内容についてはセクション2以降で説明。）

1.3 LookMLプロジェクトのバージョン管理

LookMLはコードで記述されるため、バージョン管理が可能であり、LookerIDE上で操作できます。
LookML開発を行う上で、コードの修正とバージョン管理の両方をLookerIDEで完結することができるのがとても便利です。

1.4 LookerでのSQL生成の仕組み

Lookerで可視化するデータは、接続先として指定したデータソースから取得されます。
機能の一つであるウェブインターフェースを使用することで、利用者はSQLを意識せずにデータの可視化が可能となります。
その裏では、SQLがLookMLの定義に基づいて作成・実行されているのです。
ウェブインターフェースによる可視化については、冒頭でもご紹介した以下のSkill Boostにて学ぶことができますので、先に学習をしておくとイメージが湧きやすいと思います。
Prepare Data for Looker Dashboards and Reports | Google Cloud Skills Boost

このセクションでは、LookMLを使用したデータモデリングの基本的な概念を詳しく学びました。
講義の内容を要約してご紹介します。

2.1 LookMLプロジェクトの構造

LookMLプロジェクトは、データソースをモデル化するためのコードの集まりです。プロジェクトは以下の要素で構成されます。

• モデル: データの構造を定義し、どのExploreを使用するかを指定します。
  
  • Explore: ユーザーがデータを探索するためのインターフェースを提供します。
• ビュー: データベースのテーブルやクエリの結果を表現します。
  
  • ディメンション: データの属性を定義します。（データベース テーブルのフィールド（列）を表す）
  • メジャー: データの集計結果を定義します。（ディメンションを集計して合計や個数などの値を生成する

2.2 ディメンションのモデル化

ディメンションは、データの属性を表し、ユーザーがデータをフィルタリングやグルーピングする際に使用します。LookMLでは、ディメンションを簡単に定義できます。

ディメンションの定義例

dimension: user_id {

　type: number

　sql: ${TABLE}.user_id ;;

}

この例では、user_idというディメンションを定義しています。${TABLE}は、ビューファイルの先頭で指定されたテーブルを参照します。

カスタムディメンションの作成

LookMLでは、カスタムディメンションを作成することも可能です。例えば、ユーザーのフルネームを作成する場合、以下のように定義できます。

dimension: full_name {

　type: string

　sql: CONCAT(${first_name}, ' ', ${last_name}) ;;

}

first_name と last_name という既存の LookML オブジェクトを参照して full_nameという新しいディメンションを作成しています。

このように、他のディメンションを組み合わせて新しいディメンションを作成することができます。

2.3 メジャーのモデル化

メジャーは、ディメンションに対して集計関数を適用した結果を表します。

Looker には sum、average、count の3 つの主要なメジャータイプがあり、LookMLで、さまざまなタイプのメジャーを定義できます。

メジャーの定義例

measure: total_sales {

　type: sum

　sql: ${sale_amount} ;;

}

この例では、total_salesというメジャーを定義し、sale_amountの合計を計算します。

複雑なメジャーの作成

LookMLでは、条件付きのメジャーや、他のメジャーを使用して新しいメジャーを定義することもできます。

例えば、特定の条件を満たす売上の合計を計算する場合、以下のように定義できます。

measure: total_sales_above_threshold {

　type: sum

　sql: CASE WHEN ${sale_amount} > 100 THEN ${sale_amount} ELSE 0 END ;;

}

このメジャーは、売上が100を超える場合のみその金額を合計します。

2.4 高度なロジックの使用

LookMLでは、他のビューファイルのフィールドを参照したり、メジャーを使用して他のメジャーを定義したりすることができます。これにより、より複雑なデータモデルを構築できます。

例: 他のビューファイルのフィールドを参照

dimension: profit {

　type: number

　sql: ${sale_amount} - ${inventory_items.cost} ;;

}

この例では、profitというディメンションを定義し、sale_amountからinventory_itemsのcostを引いた値を計算しています。

※この構文を正しく機能させるには、関係する 2 つのビューが Explore 内で結合されている必要があります！

2.5 まとめ

LookMLを使用したデータモデリングは、データの構造を明確にし、ビジネスユーザーがデータを効果的に探索できるようにするための重要なプロセスです。ディメンションやメジャーの定義を通じて、データの意味を明確にし、分析の質を向上させることができます。

このセクションでは、LookMLのモデルファイルについて学び、Exploreを定義する方法を解説します。
Exploreでビューファイルを使用できるようにするために、モデルファイルに定義する必要があります。
モデルファイルで定義するExploreの名前とビューの名前が一致しなければなりません。

モデルファイルは、以下の機能を考慮することでExploreをより効率的に利用することができます。

• ビュー間の結合
• フィルター
• 対象集計

3.1 ビュー間の結合

Exploreにjoinパラメーターを使用することでビュー同士の結合を定義することができます。

explore: order_items {

　join: users {

　　type: left_outer

　　sql_on: ${order_items.user_id} = ${users.id} ;;

　　relationship: many_to_one

　}

}

この例は、定義された’order_items’と’users’の結合を行います。
‘order_items’が多数の行を持ち、各行が’users’の1つの行にマッチする関係を示しています。
1人のユーザが複数の注文アイテムを持つことを示しています。

主な結合パラメーター

3.2 フィルタ

Exploreにフィルタオプションを適用することで、効率の良いデータ検索を可能にします。
LookMLは下記の4種類のフィルタオプションを利用することができます。

3.3 対象集計

データ分析を行う上で、ファンアウトの問題に直面することがよくあります。
ファンアウトとは、複数のテーブルを結合する際、正しい関係性で定義されない場合、分析結果が重複や誤った集計が発生することです。
Lookerでは条件が満たされた場合に、自動的に対象集計が適応されデータを正確に集計し、ファンアウトを解消することができます。

Lookerで下記2つの条件が満たされる場合に自動的に対象集計が適応されます。

• primary_keyの定義
  すべてのビューファイルで、Exploreに結合するためのprimary_keyが定義する必要があります。

  dimension: user_id {
  
  　type: number
  
  　primary_key: yes
  
  　sql: ${TABLE}.user_id ;;
  
  }

• 正しい結合関係
  テーブルを結合する際、relationshipパラメータが正しく指定されている必要があります。

4.1派生テーブルの概要

派生テーブルは、データベース内に存在しないテーブルを定義できる Looker の機能の一つです。
派生テーブルは、LookML プロジェクト内のビューと同様に利用でき、実際のデータベーステーブルと同様の方法でクエリを実行できます。
最も一般的なユースケースとしては、たとえば、どの部門の総売上高が最も多いかを求める場合など、サブクエリが必要なシーンで使用されます。

4.2派生テーブルの種類

派生テーブルには 2 つの種類があります。ビジネスのニーズや LookML プロジェクトの方針などによって適切な方法を選択します。

2 種類の派生テーブルの例を示します。

SQL 派生テーブル

view: order_facts {

 derived_table: {

　　sql: SELECT

         order_id,

         user_id,

         COUNT(*) AS order_item_count,

         SUM(sale_price) AS order_revenue

        FROM

          `example.ecommerce.order_items`

        GROUP BY

          1, 2 ;;

 }

}

ネイティブ派生テーブル

view: order_details {

 derived_table: {

　　explore_source: order_items {

      column: order_id {}

      column: user_id {}

      column: count {}

      column: total_revenue {}

    }

 }

}

4.3ネイティブ派生テーブルのパラメータ

ネイティブ派生テーブルのパラメータをいくつか紹介します。その他のパラメータは リファレンス を参考にしてください。

4.4永続的な派生テーブルの使用

派生テーブルは実行時に Looker でビルドして一時的に使用することも、接続済みのデータベースに書き出して永続的に使用することもできます。
一時的な派生テーブルは、実行時に SQL クエリの WITH としてビルドされ、永続的な派生テーブル (PDT) は、接続済みのデータベース内で SQL の CREATE を実行して物理テーブルを作成します。
PDT はデータベース内に物理的なテーブルとして保管されるためクエリの実行時間が短くなる半面、費用の上昇につながる可能性もあるので、必要に応じて選択します。

4.5キャッシングとデータグループ

Looker では、キャッシングを使用してデータベースの負荷を減らすことができます。
Looker は、キャッシングポリシーであるデータグループを使用してキャッシュに保存された有効な結果があるか確認し、有効な結果が確認できた場合はキャッシュから結果を返却します。データグループはモデル、Explore、PDT に適用できます。

• 今回の内容は、Skills Boost の延長戦という位置づけでした。セミナーは中級編とされていましたが、説明が丁寧だったたため、初心者の方でも十分についていける内容でした。
• 講師の方の経験も交えて説明があり、より実践的な技術を学ぶことができました。また、独学で進める場合と異なり、「ありがちなミス」の原因と解決策を把握できたためとても参考になりました。
• お客様のニーズを満たすために、データ分析の知識を習得することで、より提案の幅が広がると感じました。今後は、データ分析の知識を積極的に身につけていきたいです。
• 事前に Google Cloud Skills Boost で学習していたおかげでより深い理解につながりました。同様のセミナーに参加される方はぜひ Google Cloud Skills Boost の活用をおすすめします！