GSP935

概要

Looker は Google Cloud で利用できる最新のデータ プラットフォームで、インタラクティブにデータを分析して可視化できます。Looker を使用すると、詳細なデータ分析、さまざまなデータソースから得た分析情報の統合、実用的なデータドリブン ワークフローの構築、独自のデータ アプリケーションの作成を行うことができます。

このラボでは、ネイティブ派生テーブルを活用して複雑な質問に答え、高度なユースケースに対応し、組み込みパラメータを使用してカスタマイズする方法を学習します。

学習内容

ここでは以下について学びます。

• ネイティブ派生テーブルを作成し、派生列を使用して複雑な質問に回答する。
• 組み込みのフィルタ パラメータを使用して動的な値を生成するように、ネイティブ派生テーブルを更新する。
• ビジネス ユーザーがカスタマイズされたネイティブ派生テーブルを活用して複雑な質問に回答する方法を理解する。

前提条件:

学習効果を最大限に高めるためには、LookML に関する知識が必要です。このラボを開始する前に、「Understanding LookML in Looker」スキルバッジ コースを修了することをおすすめします。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボの時間は制限されており、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウントの競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントに追加料金が発生する可能性があります。

ラボを開始して Looker にログインする方法

1. 準備ができたら、[ラボを開始] をクリックします。

   [ラボの詳細] ペインに、このラボで使用する一時的な認証情報が表示されます。

   ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。

   [ラボの詳細] ペインに表示されているラボの認証情報を確認してください（このラボの Looker インスタンスにログインする際に使用します）。

   注: 他の認証情報を使用すると、エラーが表示されたり料金が発生したりします。

2. [Open Looker] をクリックします。

3. 提供されたユーザー名とパスワードを、[Email] フィールドと [Password] フィールドに入力します。

   ユーザー名:

   {{{looker.developer_username | Username}}}

   パスワード:

   {{{looker.developer_password | Password}}} 重要: このページの [ラボの詳細] ペインに表示されている認証情報を使用する必要があります。Google Cloud Skills Boost の認証情報は使用しないでください。ご自身の Looker アカウントをお持ちの場合でも、このラボでは使用しないでください。

4. [Log In] をクリックします。

   正常にログインすると、このラボで使用する Looker インスタンスが表示されます。

タスク 1. 派生列を使用してネイティブ派生テーブルをカスタマイズする

ネイティブ派生テーブルは、作成済みの SQL クエリと同じ関数を実行する派生テーブルですが、LookML 言語でネイティブに表現されます。

ネイティブ派生テーブルは、どのような理由から使用すべきなのでしょうか。前のラボで作成した user_facts SQL 派生テーブルについて考えてみましょう。オーダー ID の COUNT を lifetime_order_count として、sale_price の SUM を lifetime_revenue として計算しました。これらの集計は、メジャーとしてモデルにすでに存在しています。また、order_items ビューには、order_count と total_sales がすでに存在します。

ネイティブ派生テーブルは、LookML の基本原則である再利用性を具現化したものであるため、非常に便利です。既存のディメンション、メジャー、さらには Explore や結合ロジックを継承できます。これにより、「ハードコード」されたデータベース参照の数が最小限で済むため、長期的なモデルの保守性が大幅に向上します。

このセクションでは、brand_order_facts というネイティブ派生テーブルを作成します。このテーブルには、ブランドを総収益でランク付けする派生列が含まれており、動的な日付範囲やユーザー入力を使用してフィルタできます。また、上位 5 ブランドに属するかどうかを各行にラベル付けする新しいディメンションも作成します（6 位以下のすべてのブランドは「6) Other」という 1 つのブランド名にまとめます）。

総売上高で上位 5 ブランドをランク付けするネイティブ派生テーブルを作成する

1. まず、Looker のユーザー インターフェースの左下にある切り替えボタンをクリックして Development Mode に切り替えます。

2. Looker のナビゲーション メニューで、[Explore] をクリックします。

3. [E-Commerce Training] で、[Order Items] をクリックします。

4. [Inventory Items] ビューで、[Product Brand] ディメンションをクリックします。

5. [Order Items] ビューで、[Total Revenue] メジャーをクリックします。

6. [Run] をクリックします。

7. [Run]（ページの右上）の横にある設定の歯車アイコン（）をクリックして、[Get LookML] を選択します。

8. [Derived Table] タブに移動し、ボックス内の LookML コードをクリックしてクリップボードにコピーします。

9. Looker IDE（[Develop] > [qwiklabs-ecommerce]）に移動し、[File Browser] の横にあるプラス（+）アイコンをクリックして、[Create View] を選択します。

10. 新しいビューに「brand_order_facts」という名前を付けて、[Create] をクリックします。

11. [brand_order_facts.view] をクリックして、[views] フォルダの下にドラッグします。

12. 自動生成されたサンプルコードをすべて消去し、[Explore] からコピーしたコードを貼り付けます。自動生成されたビュー名は、必ず brand_order_facts に修正してください。ビューは次のようになります。

13. [Save Changes] をクリックします。

ブランドのランキングを示す派生列を追加する

ここまでの作業で、ネイティブ派生テーブルの基盤ができました。次のタスクはブランドのランク付けです。これは、ほとんどの SQL 言語で ROW_NUMBER() 関数を使用して実現できます。

これを行うには、ネイティブ派生テーブルの explore_source に derived_column を追加する必要があります。ネイティブ派生テーブルでは、derived_column を使用して、explore_source パラメータで指定された Explore にまだ存在していない列を指定できます。この例では、brand_rank とします。

1. column: total_revenue {} の定義で、まず brand_rank 派生列を定義します。

derived_column: brand_rank {}

2. 次に、中かっこ内に以下の sql パラメータを追加します。

derived_column: brand_rank { sql: row_number() over (order by total_revenue desc) ;; }

派生列を作成する場合は、必ずディメンションも追加する必要があります。これは、通常のデータベース テーブルに列がある場合と同じです。つまり、列は LookML でディメンションとして表現する必要があります。自動生成されたディメンションには sql パラメータがないことにお気づきでしょうか。これは、ディメンションに対して sql を指定しない場合、Looker はディメンションとまったく同じ名前を持つ基になるデータ内の列を指すものと想定するためです。この動作は、プロジェクトの他の領域では便利なショートカットとして使用できる可能性がありますが、一般的には、可能な限り明示的に記述することをおすすめします。この場合、少なくとも型を指定する必要があります。指定しない場合、Looker はデフォルトで文字列とみなしますが、今回の例では文字列は使用しません。

3. derived_table の定義の外側で、product_brand ディメンションのすぐ上に、次のコードを追加します。

dimension: brand_rank { type: number }

新しいビューは次のようになります。

4. [Save Changes] をクリックします。

5. 次に同じページで、model フォルダ内の training_ecommerce.model ファイルをクリックして、その内容を変更します。

6. explore: order_items の定義を見つけます。

7. explore: order_items の定義で、次のように指定して brand_order_facts の新しい結合を追加します。

join: brand_order_facts { type: left_outer sql_on: ${inventory_items.product_brand} = ${brand_order_facts.product_brand} ;; relationship: many_to_one }

8. [Save Changes] をクリックします。

9. モデルファイルは次のようになります。

10. brand_order_facts ビューを Explore に結合したので、Order Items の [Explore] ページに移動します。

11. Brand Order Facts ビューで、Brand Rank、Product Brand、Total Revenue の各ディメンションを選択します。

12. [Row Limit] を 10 に設定します。

13. [Run] をクリックします。結果は次のようになります。

ここまでは順調です。しかし、ビジネス ユーザーが「Example Brand」だけでなく「1) Example Brand」のような形式でブランド名を表示したい場合はどうでしょうか。どうすれば実現できるでしょうか。このような場合は、他の 2 つのディメンション値を連結するディメンションを作成できます。

14. brand_order_facts ビューに戻ります。

15. ブランドのランキングと商品ブランドを連結する brand_rank_concat という別のディメンションを作成します。

dimension: brand_rank_concat { type: string sql: ${brand_rank} || ') ' || ${product_brand} ;; }

16. ビジネス ユーザーは新しい brand_rank_concat でランク番号を確認するだけでよく、別のフィールドを使用する必要はないため、brand_rank を非表示にします。

dimension: brand_rank { hidden: yes type: number }

17. ユーザー フレンドリーな表示にするため、brand_rank_concat にラベルを追加します。ここでは「Brand Name」というラベルを使用します。

dimension: brand_rank_concat { label: "Brand Name" type: string sql: ${brand_rank} || ') ' || ${product_brand} ;; }

最後のステップとして、ランク 6 位以下のすべてのブランドを「Other」という分類にまとめる必要があります。そのため、まずブランドのランキングが上位 5 位以内かどうかを評価する「踏み台」となるディメンションを作成します。

18. 同じ brand_order_facts ビューで、次のパラメータを使用して brand_rank_top_5 という名前の新しいディメンションを作成します。

dimension: brand_rank_top_5 { hidden: yes type: yesno sql: ${brand_rank} <= 5 ;; }

19. 次に、brand_rank_grouped という名前の新しいディメンションを作成し、次のコードを使用して brand_rank_top_5 を組み込みます。

dimension: brand_rank_grouped { label: "Brand Name Grouped" type: string sql: case when ${brand_rank_top_5} then ${brand_rank_concat} else '6) Other' end ;; }

20. [Save Changes] をクリックします。

ビューは以下のようになります。

21. Order Items の [Explore] ページに戻ります。

22. Brand Order Facts ビューで、Brand Name Grouped ディメンションを選択します。

Order Items ビューで Total Revenue メジャーを選択します。[Row Limit] を 10 に設定します。

23. [Run] をクリックします。

24. [Brand Name Grouped] 列が最初から最後までの順に並んでいることを確認し、[Visualization] タブで [Pie Chart] をクリックします。

25. 以下の図のようになっていることを確認します。

26. ページ右上の [Run] の横にある設定（歯車）アイコン をクリックし、[Save] > [As a Look] を選択します。

27. Look のタイトルとして「Ranked Brand Revenue」と入力します。

28. [Save] をクリックします。

29. brand_order_facts ビューに戻ります。

変更を commit して本番環境にデプロイする

1. [LookML を検証] をクリックしてから、[Commit Changes & Push] をクリックします。

2. commit メッセージを追加して、[Commit] をクリックします。

3. 最後に、[本番環境にデプロイ] をクリックします。

これで、ユースケースや必要なロジックを個別の基本ディメンションに分解し、それらを組み合わせて特定のビジネス上の質問に答えることの有用性を理解していただけたかと思います。ベスト プラクティスの LookML 開発では、このような隠された「踏み台」ディメンションとメジャーが多数存在するのが一般的です。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 派生列を使用してネイティブ派生テーブルをカスタマイズする

タスク 2. フィルタを使用してネイティブ派生テーブルをカスタマイズする

次に、過去 365 日間の最近の注文のみを重視する例について考えてみましょう。上位 5 ブランドの中には、現在とは別のトレンドによって数年前は人気を集めていたものの、過去 1 年間でランキングが変動したブランドもあるかもしれません。

このセクションでは、LookML のネイティブ派生テーブルで使用するさまざまなタイプのフィルタについて説明します。フィルタは、メジャーのフィルタと同様に、派生テーブルにフィルタを適用するために使用します。WHERE 句または HAVING 句を追加します。

静的な日付フィルタを追加する

1. まず、brand_order_facts ビューに戻ります。

2. derived_column 定義で、ネイティブ派生テーブルを過去 365 日間に作成された注文に制限するフィルタを追加します。

filters: [order_items.created_date: "365 days"]

3. [Save Changes] をクリックします。ファイルは次のようになります。

4. Order Items Explore に戻ります。

5. Brand Order Facts ビューで、Brand Name Grouped を選択します。

6. Order Items ビューで Total Revenue メジャーを選択します。

7. [Run] をクリックします。

8. [Data] バーで [SQL] タブをクリックして、クエリでフィルタがどのように使用されているかを確認します。

過去 365 日間の注文のみを表示するよう Ordered Items Created Date にフィルタを追加したため、WHERE 条件はいわゆる「外部クエリ」内でのみ生成されます。これはディメンション フィルタのデフォルトの動作です。派生テーブルの共通テーブル式内に入るように指定したり、外部の WHERE を内部クエリに波及的に適用したりすることはできません。そのため、NDT 自体にフィルタを追加すると便利です。

バインド フィルタを追加する

過去 365 日間の注文データのみに制限するのは厳しすぎると企業側が判断した場合はどうすればよいでしょうか。たとえば、過去 2 年間のランキングを分析したい場合もあるでしょう。このような場合は、filters: [order_items.created_date: "365 days"] を使用すると、期間がハードコードされます。

この場合、単なるフィルタよりも bind_filters の方が便利なパラメータとして使用できます。外部の Explore からネイティブ派生テーブルの内部クエリに波及的に適用するフィールド（from_field）と、それをマッピングするネイティブ派生テーブルのフィールド（to_field）を指定できます。ほとんどの場合、これら 2 つは同じ値になります。

explore_source の bind_filters サブパラメータは、Explore クエリの特定のフィルタをネイティブ派生テーブルのサブクエリに渡します。

• to_field は、フィルタが適用されるネイティブ派生テーブル内のフィールドです。to_field は、基盤となる explore_source のフィールドでなければなりません。
• from_field は、ユーザーが実行時にフィルタを指定した場合に、フィルタの取得元となる Explore 内のフィールドを指定します。

1. brand_order_facts ビューに戻ります。

2. バインド フィルタを使用するには、まず前のセクションで作成した派生テーブル定義内の静的な日付フィルタを削除します。

3. 次に、derived_column 定義で、bind_filters の次のテンプレートを追加します。

bind_filters: { from_field: # フィルタ領域でエンドユーザーが操作するフィールド to_field: # NDT 内でフィルタされるフィールド }

この場合、フィルタ from_field: order_items.created_date を取得し、影響を与えるかようにするか、to_field: order_items.created_date に適用する必要があります。

4. バインド フィルタ フィールド用に次のコードを追加します。

bind_filters: { from_field: order_items.created_date to_field: order_items.created_date } 注: これは、SQL 派生テーブルにテンプレート フィルタを追加するのと同じ効果を持ちます。前回のラボで見たように、SQL 派生テーブルにテンプレート フィルタを追加することで、ユーザーが日付を選択すると、その日付に基づいて値が更新されることを確認できるようになりました。

5. [Save Changes] をクリックします。ファイルは次のようになります。

6. Order Items Explore に戻ります。

7. Brand Order Facts ビューで、Brand Name Grouped を選択します。

8. Order Items ビューで Total Revenue メジャーを選択します。

9. さらに、Order Items ビューの Created Date ディメンションで [Date] フィールドを選択し、[Date] の横にあるフィルタボタンを選択します。

10. フィルタ定義で、フィルタを「is in the past 1000 days」に指定します。デモでは、フィルタの制限が厳しくなりすぎないように、また過去 3 年間のデータを確実に取り込めるように、1,000 日間を使用しています。

11. [Run] をクリックします。

12. [Data] バーで [SQL] タブをクリックして、クエリでフィルタがどのように使用されているかを確認します。生成された SQL では、派生テーブルの共通テーブル式内の WHERE 条件と、外部の WHERE 条件が動的に更新されることに注意してください。

ご覧のとおり、柔軟性がはるかに高くなっています。過去 3 四半期に作成された注文でフィルタすると、ネイティブ派生テーブルはそれに応じて過去 3 四半期のランキングを計算します。特定の期間内に作成された注文でフィルタすると、ネイティブ派生テーブルの WHERE 条件でも同じ期間が使用されます。

13. 次に、[Users] フィールドで [Country] と [Age] を選択し、フィルタを追加します。そしてフィルタをそれぞれ [Country is equal to USA] と [Age is greater than 21] に設定します。

14. [Run] をクリックします。

15. 最後に、[SQL] タブをクリックします。

派生テーブルの WHERE 条件が影響を受けないことに注目してください。では、ビジネス ユーザーが「Ordered Items Created Date」以外の条件を設定していたらどうなるでしょうか。たとえば、米国の顧客による注文のランキングや、男性の顧客による注文のランキングだけを表示したい場合はどうすればよいでしょうか。

もちろん bind_filters を追加し続けることもできますが、Order Items Explore には多くのフィールドが用意されています。また、すべてに対して bind_filters を追加すると、時間がかかりすぎます。ここで非常に役立つのが、bind_all_filters という別のパラメータです。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 フィルタを使用してネイティブ派生テーブルをカスタマイズする

bind_all_filters を使用する

Explore からネイティブ派生テーブルのサブクエリにフィルタを渡す最も簡単な方法は、ネイティブ派生テーブルの explore_source パラメータで bind_all_filters: yes を指定する方法です。これにより、Explore のすべてのランタイム フィルタが、ネイティブ派生テーブルのサブクエリに渡されます。

前のセクションで説明したように、別の Explore でネイティブ派生テーブルを使用する場合は、代わりに bind_filters パラメータを使用します。

1. まず、前のセクションで作成した派生テーブル定義内の bind_filter を削除します。

2. derived_column 定義の下に bind_all_filters: yes 定義を追加し、order_created_date だけでなく、すべてのフィルタをそれ自体にバインドします。

bind_all_filters: yes

3. [Save Changes] をクリックします。ファイルは次のようになります。

4. Order Items Explore に戻ります。

5. Brand Order Facts ビューで、Brand Name Grouped を選択します。

6. Order Items ビューで Total Revenue メジャーを選択します。

7. さらに、Order Items ビューで Created Date ディメンションを見つけ、[Date] の横にあるフィルタボタンをクリックします。

8. フィルタ定義で、フィルタを「is in the past 365 days」に指定します。

9. Users ビューで、[Country] と [Age] にフィルタを追加し、「Country is equal to USA」と「Age is greater than 21」に設定します。

10. [Run] をクリックします。

11. [SQL] タブをクリックします。派生テーブルの WHERE 条件が動的に更新されるようになりました。

bind_all_filters は便利ですが、ネイティブ派生テーブルを explore_source に結合しないと機能しません。つまり、ここでは brand_order_facts を explore_source（order_items）と同じ Explore に結合しているため、使用できるのです。

なぜかというと、bind_all_filters は、Looker が Explore 全体の任意のフィールドに対して WHERE 条件を生成する方法を認識する必要があるためです。ネイティブ派生テーブルで order_items の explore_source を使用しているにもかかわらず、それを別の Explore に結合している場合、その別の Explore には order_items に存在しない結合ビューとフィールドが多数含まれている可能性があり、order_items の世界では意味をなさない可能性があります。Looker は、このような他のフィールドで派生テーブルをフィルタする方法を認識できません。

bind_all_filters の動作を確認したところで、いくつかの異なる Explore フィルタを試し、ネイティブ派生テーブルのコンパイル方法にどのように影響するのかを確認してみましょう。

12. brand_order_facts ビューに戻ります。

変更を commit して本番環境にデプロイする

1. [LookML を検証] をクリックしてから、[Commit Changes & Push] をクリックします。

2. commit メッセージを追加して、[Commit] をクリックします。

3. 最後に、[本番環境にデプロイ] をクリックします。

お疲れさまでした

このラボでは、ネイティブ派生テーブルを使用して複雑な質問に回答し、派生列を使用して高度なユースケースに対応しました。また、組み込みのフィルタ パラメータを使用して動的な値を生成するように更新しました。さらに、ビジネス ユーザーがカスタマイズされたネイティブ派生テーブルを活用して複雑な質問に回答する方法についても学習しました。

次のステップと詳細情報

• LookML クイック リファレンス
• LookML の用語と概念
• Looker コミュニティ
• LookML の基礎の補足

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2024 年 3 月 4 日

ラボの最終テスト日: 2024 年 3 月 4 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。