GSP1020

概要

Looker は Google Cloud で利用できる最新のデータ プラットフォームで、インタラクティブにデータを分析して可視化できます。LookML のデベロッパーは、新しいフィールド、テーブル、ビュー、Explore を作成することによって、ビジネス ユーザーが使用するデータをキュレートします。また、データとワークフローをカスタマイズして編成することによって、カスタムデータ アプリケーションを作成します。

このラボでは、LookML コードを記述する際のベスト プラクティスを学びます。このベスト プラクティスにより、ビジネス ユーザーとデベロッパーの両方のエクスペリエンスが向上します。たとえば、既存のオブジェクトを再利用し、わかりやすい命名規則を適用することにより、LookML プロジェクトのユーザビリティと持続可能性を向上させます。また、LookML パラメータを使用して、追加のコンテキストを提供し、ビジネス ユーザーに表示されるオブジェクトをカスタマイズすることで、Explore を使いやすくします。

前提条件

LookML に関する知識が必要です。このラボを開始する前に、「Understanding LookML in Looker」を修了することをおすすめします。

演習内容

• わかりやすいフィールド名を使用して、ディメンションとメジャーを定義します。
• 追加のパラメータを活用して、データを整理し、より多くのコンテキストを提供します。
• 作成して表示するフィールドの数と Explore の数をできるだけ少なくします。
• 簡単に更新、保守、再利用できる、持続可能でモジュール型の LookML コードを記述します。

設定と要件

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

こちらの説明をお読みください。ラボの時間は制限されており、一時停止することはできません。タイマーは、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 インスタンスが表示されます。

LookML のコードを記述する際のベスト プラクティス

このセクションでは、LookML コードを記述する際に活用できる上位 5 つのベスト プラクティスについて説明します。これらのベスト プラクティスを活用することにより、ビジネス ユーザーとデベロッパーの両方のエクスペリエンスが向上します。このラボでは、最初の 4 つの項目に焦点を当てます。

わかりやすいフィールド名を使用する

わかりやすいフィールド名を使用してディメンションとメジャーを定義すると、ビジネス ユーザーとデベロッパーの両方が必要なものを見つけやすくなります（ベスト プラクティスの項目 1）。いくつかの例を示します。

• メジャーには、集計関数または一般的な用語で名前を付ける: total_[FIELD]（合計の場合）、count_[FIELD]、avg_[FIELD] など。
• 比率にわかりやすい名前を付ける: percent_returning よりも percent_orders_by_returning_customer の方が明確です。
• yesno フィールドにわかりやすい名前を付ける: ruturned ではなく、order_is_returned または is_order_returned。
• ディメンション グループに「date」や「time」という単語を使用しない。Looker では、ディメンション名の末尾に各タイムフレームが追加されます。たとえば、created_date は created_date_date になります。

追加のパラメータを活用する

追加のパラメータを活用すると、ビジネス ユーザーに公開されるデータを整理し、より多くのコンテキストを提供できます。ビジネス ユーザーがワークフローで使用するフィールドと Explore を特定できるようにするため、label と description を含めることが推奨されます（ベスト プラクティスの項目 1 と 4）。

また、group_label パラメータを使用して、類似するフィールドと Explore を論理カテゴリにグループ化すると、ナビゲーションが容易になります（ベスト プラクティスの項目 2）。

最後に、drill_fields を使用して、ビジネス ユーザーがデータ探索でテーブルセルの値をクリックしたときに表示される追加オプションをキュレートすることが推奨されます。

作成して表示するフィールドの数と Explore の数をできるだけ少なくする

ビジネス ユーザーが必要な回答に簡単にアクセスできるようにしながら、フィールドと Explore を作成して表示する数を最小限に抑えることは、非常に有益なベスト プラクティスです（ベスト プラクティスの項目 3）。最適なフィールドの数と Explore の数はそれぞれのビジネスによって異なりますが、数が多すぎるとエンドユーザーを混乱させがちです。

fields パラメータを使用すると、個々の Explore でビジネス ユーザーに表示されるフィールドを制限できます。また、hidden パラメータを使用すると、モデル全体でフィールドまたは Explore を非表示にできます。

持続可能でモジュール型の LookML コードを記述する

簡単に更新、保守、再利用できる持続性と保守性に優れた LookML コードを記述することは、機能的なプロジェクトを維持するうえで重要です。

基盤となる LookML コードの構成と品質はすぐに明らかにならないかもしれませんが、ビジネス ユーザーの全体的なエクスペリエンスに影響を与える可能性があります。特に、LookML デベロッパーがベースコードの記述とメンテナンスに費やす時間を短縮できれば、ビジネス ユーザーからリクエストされた属性や機能をより迅速に変更または実装できます。

持続可能でモジュール型の LookML コードを記述するためのアイデアをいくつかご紹介します。

• コード全体で置換演算子を使用して、基盤となるデータベースへのハードコードされた参照を最小限に抑えます。
• SQL 派生テーブルとネイティブ派生テーブルの適切なケースを特定します。
  • ネイティブ派生テーブルは、モデル内の既存の LookML オブジェクトを活用して、基盤となるデータベースにまだ存在しない新しい構造や集計を定義することで、コードの再利用を促進します。
  • SQL 派生テーブルは、ネイティブ派生テーブルでは簡単に実現できない、よりカスタムな集計や複雑な集計に使用されます。
• extends または絞り込みを使用して、既存のビューと Explore を拡張します。
  • ビューまたは Explore を拡張して、元のオブジェクトのコピーを作成し、変更を適用できます。詳細と演習については、extends による LookML コードのモジュール化のラボをご利用ください。
  • また、既存のビューまたは Explore を含む LookML ファイルを編集せずに、既存のビューまたは Explore を適合させるための絞り込みを作成することもできます。詳細と演習については、LookML クエリのパフォーマンスの最適化のラボをご利用ください。

Explore クエリのパフォーマンスを最適化する

ビジネス ユーザー向けに Explore クエリのパフォーマンスを最適化するには:

• Explore で不要なビューを結合しないようにします。
• ビューファイルで主キーを宣言し、relationship パラメータを使用して結合関係を定義して、正しい集計が生成されるようにします。
• 最も詳細なレベルから最も概略的なレベルのビューの間で many_to_one 結合を定義します。
• 実行に時間がかかる複雑なクエリや、多数のユーザーまたはアプリケーションによって頻繁に使用されるクエリについては、派生テーブルを永続化します。

これらのトピックの詳細については、Looker の推奨事項と禁止事項と LookML クエリのパフォーマンスの最適化をご覧ください。

タスク 1. 既存のフィールドとわかりやすい命名規則を活用するフィールドを作成する

新しいディメンションとメジャーを作成するときは、モデル内の既存の LookML オブジェクトを必ず確認し、再利用できるものがないか確認してください。コードの更新を容易にするには、コード全体で置換演算子を使用して、基盤となるデータベース内のオブジェクトへのハードコードされた参照を最小限に抑えることをおすすめします。

既存のオブジェクトを活用するだけでなく、新しいオブジェクトを作成する際にはわかりやすい名前を選択することも重要です。これにより、デベロッパーやビジネス ユーザーがコードや分析で使用するフィールドを見つけやすくなります。このタスクでは、既存の status ディメンションを活用して、キャンセルされた注文を特定する新しい yesno ディメンションを作成します。また、既存のオブジェクトを活用して、キャンセルされた注文による収益喪失の割合を計算する新しいメジャーを作成します。新しいディメンションとメジャーには、わかりやすい命名規則を適用します。

既存のディメンションから yesno ディメンションを作成する

1. 切り替えボタンをクリックして Development Mode に切り替えます。

2. [開発] メニューで qwiklabs_ecommerce プロジェクトを選択します。

3. [ビュー] の下の order_items.view を開きます。

4. status という名前のディメンションを確認します。

   この構文では、置換演算子 ${TABLE}.column_name を使用しています。これは、ビューファイルの先頭にある sql_table_name パラメータで指定されたテーブルの列を参照します。

   この場合、${TABLE}.status は cloud-training-demos.looker_ecomm.order_items テーブル内の status 列を参照します。この既存のディメンションを活用して、注文のステータスがキャンセル済みかどうかを識別する新しい yesno ディメンションを作成できます。

order_is_canceled と is_order_canceled はどちらも、注文がキャンセルされたかどうかを示すオブジェクトであることが明確であるため、わかりやすい名前のベスト プラクティスに準拠しています。どちらのオプションを選択するかは、チーム内で決定される命名規則に準じます。

5. status ディメンションの下に、新しい yesno ディメンションのための次のコードを追加します。

dimension: order_is_canceled { type: yesno sql: ${status} = "" ;; }

この構文では、現在のビュー内の既存のディメンションまたはメジャーを参照する置換演算子 ${field_name} が使用されています。この場合、${status} は order_items ビュー内の status ディメンションを参照します。

また、このコードにはステータスの値がまだ含まれていないことにも注意してください。既存の status ディメンションを活用できますが、ディメンション内のどの値がキャンセルされた注文の識別に使用されるかを知っておく必要があります。

技術的には、これらすべてのオプションは正しい値を識別するために使用できます。ただし、知識に基づく推測のオプションは非効率的で、誤った値になる可能性があります。期待どおりの結果が得られるまで、Explore の新しいディメンションに対してクエリを実行してコードをテストし続ける必要があります。

Order Items Explore の Order Items ビューの status ディメンションに対してクエリを実行すると、そのディメンション値が返されますが、Explore に表示される値には、LookML コードで適用された追加の形式が反映される可能性があります。

SQL Runner で order_items テーブルに対して直接クエリを実行すると、status 列の元データの値を確認できます。

6. IDE のブラウザタブを開いたままにして、新しいブラウザタブで新しい Looker ウィンドウを開きます。

7. [開発] > [SQL Runner] に移動します。

8. 接続の横にある設定アイコン（）をクリックし、[公開プロジェクトを検索] をクリックします。

9. [プロジェクト] に「cloud-training-demos」と入力し、Enter キーを押します。

10. [データセット] は [looker_ecomm] を選択します。
    この BigQuery データセットで利用可能なテーブルのリストが表示されます。

11. status 列の個別の値を選択するには、次のクエリを SQL クエリ ウィンドウに追加して、[実行] をクリックします。

SELECT distinct(status) FROM cloud-training-demos.looker_ecomm.order_items ORDER BY status 注: 値には Cancelled が含まれています。これは、米国英語のスペルである Canceled ではなく、2 つの L を使用した英国英語のスペルです。

12. SQL Runner のブラウザタブを閉じて、IDE のブラウザタブに戻ります。

13. 新しい yesno ディメンションの LookML コードを完成させます。

dimension: order_is_canceled { type: yesno sql: ${status} = "Cancelled" ;; }

14. [変更内容を保存] をクリックします。

    このブラウザタブは Looker IDE 用に開いたままにしておきます。

15. ブラウザタブで新しい Looker ウィンドウを開きます。

16. [Explore] > Order Items の順に移動します。

17. [データ] ペインで [SQL] タブをクリックします。

18. Order Items > [ディメンション] で、以下を選択します。

• Order ID
• Order Is Canceled (Yes/No)

クエリを実行する前に、order_item.status の値が Cancelled と等しいかどうかに応じて、CASE ステートメントが Yes または No の結果を返すことを確認してください。

CASE WHEN order_items.status = "Cancelled" THEN 'Yes' ELSE 'No' END

19. [実行] をクリックします。

20. [結果] タブを開いて結果を確認します。

21. Explore のブラウザタブを閉じて、IDE のブラウザタブに戻ります。

既存のディメンションとメジャーに基づいて新しいメジャーを作成する

1. order_items.view を開きます。

2. total_revenue_from_completed_orders というメジャーを確認します。

   名前は sum メジャーのベスト プラクティスに沿って付けられています。値が合計値であることを明確に示すために、名前が「total」で始まっていることに注目してください。また、既存の status ディメンションで値が Complete に等しいものを選択するフィルタが含まれていることにも注目してください。

total_canceled_orders は total で始まりますが、合計が注文の合計ではなく収益の合計であることを明確に示していません。一方、revenue_from_canceled_orders にはわかりやすい詳細が含まれていますが、名前の先頭に total がありません。

3. このメジャーの後に次のコードを追加して 2 つの新しいメジャーを作成します。

measure: total_revenue_from_canceled_orders { type: sum sql: ${sale_price} ;; filters: [order_is_canceled: "Yes"] value_format_name: usd } measure: percent_revenue_canceled_orders { type: number value_format_name: percent_2 sql: 1.0*${total_revenue_from_canceled_orders} /NULLIF(${total_revenue}, 0) ;; }

最初のメジャー total_revenue_from_canceled_orders は、total という単語で始まる sum メジャーの命名に関する同じベスト プラクティスに従っており、合計がキャンセルされた注文による収益であることを明確に示しています。

ただし、フィルタが異なることに注意してください。total_revenue_from_canceled_orders では、status ディメンションではなく、前の手順で作成した yesno ディメンションを使用します。どちらのオプションも、モデルで使用可能なオブジェクトに応じて、既存の LookML オブジェクトを再利用するというベスト プラクティスに従っています。

2 番目のメジャーは、percent と canceled orders という単語を含めることで、比率をわかりやすく命名するというベスト プラクティスに沿っています。このメジャーでは、既存の 2 つのメジャー（最初のメジャーと total_revenue メジャー）も活用して、キャンセルされた注文に起因する収益の割合を計算します。

4. [変更内容を保存] をクリックします。

   このブラウザタブは Looker IDE 用に開いたままにしておきます。

5. ブラウザタブで新しい Looker ウィンドウを開きます。

6. [Explore] > Order Items の順に移動します。

7. [データ] ペインで [SQL] タブをクリックします。

8. Order Items > [メジャー] で、以下を選択します。

• Total Revenue From Canceled Orders
• Total Revenue
• Percent Revenue Canceled Orders

クエリを実行する前に、CASE ステートメントが SUM と組み合わせて使用され、order_items.status が Cancelled の場合に order_items.sale_price の合計を計算し、order_items.sale_price のすべての値の合計で除算していることに注目してください。

SUM(CASE WHEN order_items.status = "Cancelled" THEN order_items.sale_price ELSE NULL END), 0) / NULLIF(COALESCE(SUM(order_items.sale_price ), 0), 0)

9. [実行] をクリックします。

10. [結果] タブを開いて結果を確認します。

11. Explore クエリのブラウザタブを閉じて、Looker IDE のブラウザタブに戻ります。

12. [プロジェクトの状態]（）をクリックします。

13. [プロジェクトの状態] > [LookML の検証] セクションで、[LookML を検証] をクリックします。

LookML エラーは見つからないはずです。

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

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

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

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

Looker IDE のブラウザタブを開いたまま、次のタスクに進みます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 既存のフィールドとわかりやすい命名規則を活用するフィールドを作成する

タスク 2. ラベルと説明を使用してフィールドと Explore にコンテキストを提供する

LookML オブジェクトにラベルと説明を追加すると、ビジネス ユーザーがワークフローで使用するフィールドと Explore を簡単に特定できるようになります。このタスクでは、前のタスクで作成した新しい yesno ディメンションとメジャーにラベルと説明を追加します。また、これらのフィールドをビジネス ユーザーに公開する既存の Order Items Explore にもラベルと説明を追加します。

ディメンションにラベルと説明を追加する

1. 新しいブラウザタブで新しい Looker ウィンドウを開きます。

2. [Explore] > Order Items の順に移動します。

3. Order Items を開き、Order Is Canceled (Yes/No) というディメンションにポインタを合わせると、その他のオプションが表示されます。

4. 情報アイコン（）をクリックして、このディメンションの詳細を表示します。

   [情報] コントロールには SQL パラメータなどの詳細が表示されますが、SQL の知識が限られているビジネス ユーザーにとっては、ディメンションの意図された用途の簡単な理解に役立つ追加の説明がありません。以降の手順では、ビジネス ユーザーに追加のコンテキストを提供するために、Order Is Canceled ディメンションに説明パラメータを追加します。

5. Explore のブラウザタブを開いたままにして、Looker IDE のブラウザタブに戻ります。

6. order_items.view を開きます。

7. 先ほど作成した order_is_canceled ディメンションの説明を追加します。

dimension: order_is_canceled { description: "A value equal to Yes means that the order has a canceled status. A value equal to No means that the order does not have a canceled status." type: yesno sql: ${status} = "Cancelled" ;; }

8. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

9. Order Items Explore のブラウザタブに戻り、ページを更新します。

10. Order Items を開き、Order Is Canceled (Yes/No) というディメンションにポインタを合わせると、その他のオプションが表示されます。

11. 情報アイコン（）をクリックして、このディメンションの詳細を表示します。

    ビジネス ユーザーがディメンションの値を解釈する方法が明確に説明されるようになりました。

12. Explore のブラウザタブを開いたままにして、Looker IDE のブラウザタブに戻ります。

13. order_is_canceled ディメンションの LookML コードをもう一度確認します。

    ラベル パラメータは必要なかったため、含めていません。Explore でディメンション名が「Order Is Canceled (Yes/No)」と表示されており、すでに明確に内容を表しています。

    次の手順では、前のタスクで作成したメジャーに説明とラベルの両方を追加して、Explore でメジャー名がどのように表示されるかを変更し、メジャーの値の解釈方法に関する追加の詳細情報を提供します。

メジャーにラベルと説明を追加する

1. order_items.view で、total_revenue_from_canceled_orders と percent_revenue_canceled_orders というメジャーに説明とラベルを追加します。

measure: total_revenue_from_canceled_orders { label: "Total Revenue Lost From Canceled Orders" description: "Sum of sale price for orders with canceled status." type: sum sql: ${sale_price} ;; filters: [order_is_canceled: "Yes"] value_format_name: usd } measure: percent_revenue_canceled_orders { label: "% Revenue Lost From Canceled Orders" description: "Total revenue lost from canceled orders as a percentage of the total revenue from all orders." type: number value_format_name: percent_2 sql: 1.0*${total_revenue_from_canceled_orders} /NULLIF(${total_revenue}, 0) ;; }

2. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

   これらのメジャーにラベルを追加すると、キャンセルされた注文が収益の喪失を表していることを強調できます。説明は、メジャーの種類と SQL パラメータの解釈方法に関する追加のコンテキストを提供します。

3. Order Items Explore のブラウザタブに戻り、ページを更新します。

4. Order Items を開くと、2 つのメジャーのラベルが % Revenue Lost From Canceled Orders と Total Revenue Lost From Canceled Orders に変更されていることがわかります。

5. 各メジャーの情報アイコン（）をクリックすると、詳細が表示されます。

   ラベルに加えて、ビジネス ユーザーがこれらのメジャーの値を解釈する方法についての便利な説明が表示されるようになりました。

6. Order Items > [ディメンション] で、Order Is Canceled (Yes/No) を選択します。

7. Order Items > [メジャー] で、以下を選択します。

• Total Revenue Lost From Canceled Orders
• Total Revenue
• % of Revenue Lost from Canceled Orders

8. [データ] ペインで列名にカーソルを合わせると、Order Is Canceled、Total Revenue Lost From Canceled Orders、% of Revenue Lost from Canceled Orders で [情報] ボタンをクリックしたときに表示される説明と同じ説明が表示されます。

9. [実行] をクリックします。

   このクエリは、Order Is Canceled ディメンションに基づいて 2 つの行を返します。1 つは Yes の行、もう 1 つは No の行です。これらの結果について知りたいビジネス ユーザーは、ディメンションとメジャーの説明を参照して、より多くのコンテキストを得ることができます。

Explore にラベルと説明を追加する

1. Explore のブラウザタブを閉じて、Looker IDE のブラウザタブに戻ります。

2. [モデル] の下の training_ecommerce.model を開きます。

3. users の結合の前の部分で、既存の Order Items Explore に対してラベルと説明を追加します。

explore: order_items { label: "Orders and Users" description: "Use this Explore to review details for orders and users, including information on inventory, products, and distribution centers." join: users { type: left_outer sql_on: ${order_items.user_id} = ${users.id} ;; relationship: many_to_one }

4. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

5. IDE のブラウザタブを開いたままにして、新しいブラウザタブで新しい Looker ウィンドウを開きます。

6. [Explore] をクリックして、Explore のメニューリストを表示します。

Order Items Explore のラベルが Orders and Users に変更されました。また、Explore 名の横に [情報] コントロールが表示されていることにも注目してください。

7. 情報アイコン（）にカーソルを合わせると、Explore の詳細が表示されます。

   Explore で利用可能なデータに関する明確で詳しい説明が追加され、ビジネス ユーザーは、この Explore が自分のワークフローにとって正しいものかどうかを簡単に判断できるようになりました。

8. Explore のブラウザタブを閉じ、IDE のブラウザタブは開いたままにします。

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

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

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

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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ラベルと説明を使用してフィールドと Explore にコンテキストを提供する

タスク 3. 特定の Explore に表示されるフィールドを必要なもののみに制限する

モデル内に新しい LookML オブジェクトを作成するときは、どのフィールドと Explore に対してビジネス ユーザーが直接アクセスする必要があるかを考慮してください。特別にキュレートしたフィールドと Explore のみを提示することで、ビジネス ユーザーは必要なデータをすばやく見つけることができます。

このタスクでは、hidden パラメータを使用して training_ecommerce モデル全体で余計なフィールドを非表示にし、fields パラメータを使用して既存の Order Items Explore でビジネス ユーザー提示されるフィールドを制限します。

LookML モデル内のすべての Explore でフィールドを非表示にする

1. 新しいブラウザタブで新しい Looker ウィンドウを開きます。

2. [Explore] > Events に移動します。

3. Users を開きます。

4. 新しいブラウザタブで新しい Looker ウィンドウを開きます。

5. [Explore] > Orders and Users に移動します。

6. Users を開いて、2 つの Explore を比較します。

Events Explore の Users には、Orders and Users と同じディメンションが表示されます。たとえば、Latitude ディメンションと Longitude ディメンションは、ビジネス ユーザーに常に公開する必要があるとは限りません。

ヒント: Looker のドキュメントで各パラメータを検索してみてください。

7. 両方の Explore のブラウザタブを開いたままにして、Looker IDE に戻ります。

8. [ビュー] で users.view を開きます。

9. latitude と longitude のディメンションに hidden パラメータを追加します。

dimension: latitude { hidden: yes type: number sql: ${TABLE}.latitude ;; } dimension: longitude { hidden: yes type: number sql: ${TABLE}.longitude ;; }

10. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

11. Orders and Users Explore のブラウザタブに戻り、ページを更新します。

12. Users を開いて、使用可能なディメンションを確認します。

    Orders and Users Explore に latitude ディメンションと longitude ディメンションが表示されなくなっていることに注目してください。

13. Events Explore のブラウザタブに戻り、ページを更新します。

14. Users を開いて、使用可能なディメンションを確認します。

    どちらの Explore にも、latitude と longitude のディメンションが表示されなくなります。次は、ディメンションやメジャーをすべての Explore で非表示にするのではなく、特定の Explore のみで非表示にしたい場合を考えます。たとえば、Events Explore には Orders and Users Explore と同じユーザー情報がすべて含まれていますが、これらのフィールドの多くは、Events Explore で実際に必要となるよりも多くの個人情報を提供します。

    次の手順では、Events Explore のみで、Users ビューのほとんどのディメンションとメジャーを非表示にします。Events Explore で必要になるのは、ユーザーの選択や一般的な傾向の特定に必要な最小限の情報のみだからです。

特定の Explore でフィールドを選択的に非表示にする

1. Explore のブラウザタブを開いたままにして、IDE のブラウザタブに戻ります。

2. training_ecommerce.model を開きます。

3. event_session_facts の join の前の部分で、既存の Events Explore に fields パラメータを追加します。

explore: events { fields: [ALL_FIELDS*, -users.city, -users.email, -users.first_name, -users.gender, -users.last_name, -users.state] join: event_session_facts { type: left_outer sql_on: ${events.session_id} = ${event_session_facts.session_id} ;; relationship: many_to_one }

fields パラメータの構文は、フィールド名の前にマイナス記号（-）が付いているフィールド（users.city など）を除き、すべてのフィールドが Explore に表示されることを示しています。マイナス記号が付いているフィールドは Explore で非表示になります。

4. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

5. Orders and Users Explore のブラウザタブに戻り、ページを更新します。

6. Users を開いて、使用可能なディメンションを確認します。

   Orders and Users Explore では、他のディメンションは非表示になっていないことに注目してください。

7. Events Explore のブラウザタブに戻り、ページを更新します。

8. Users を開いて、使用可能なディメンションを確認します。

   Events Explore で使用できる Users のディメンションは、フィールド パラメータでマイナス記号（-）が明示的に指定されていないものだけです。

   Events Explore では、ユーザーとイベントに関するより一般的な分析がサポートされるようになりました。Orders and Users Explore には、個人情報など、ユーザーに関するより詳細な情報が含まれています。

9. Users > [ディメンション] で、Country を選択します。

10. Users > [メジャー] で、Count を選択します。

11. Events > [ディメンション] で、Event Type を選択します。

12. [実行] をクリックします。

    このクエリは、国ごとのユーザー数をイベントタイプごとに返します。これには、国の値が null のユーザーも含まれます。

13. Explore 用に開いている 2 つのブラウザタブを閉じ、IDE 用のブラウザタブは開いたままにします。

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

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

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

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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 特定の Explore に表示されるフィールドを必要なもののみに制限する

タスク 4. 類似するフィールドまたは Explore を有用なカテゴリにグループ化する

LookML デベロッパーは、group_label パラメータを使用して、類似するフィールドまたは Explore を論理カテゴリにグループ化することで、Explore のナビゲーションを容易にできます。このタスクでは、users.view のさまざまな位置情報のディメンションをグループ化し、training_ecommerce.model の Orders and Users Explore と Events Explore に、チームごとに異なる見出しでラベル付けされた個別のグループを作成します。

ビューで類似するフィールドをグループ化する

1. users.view を開き、使用可能なディメンションを確認します。

複数のディメンションに、都市、国、州、郵便番号などの位置情報が含まれています。

フィールドの group_label パラメータのドキュメントに基づいて、複数のディメンションに group_label: "グループ名" の LookML 構文を追加して、複数のディメンションを 1 つのカテゴリにグループ化できます。

2. city、country、state、zip の各ディメンションに group_label パラメータを追加して、Location という 1 つのカテゴリにグループ化します。

dimension: city { group_label: "Location" type: string sql: ${TABLE}.city ;; } dimension: country { group_label: "Location" type: string map_layer_name: countries sql: ${TABLE}.country ;; } dimension: state { group_label: "Location" type: string sql: ${TABLE}.state ;; map_layer_name: us_states } dimension: zip { group_label: "Location" type: zipcode sql: ${TABLE}.zip ;; }

3. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

4. IDE のブラウザタブを開いたままにして、新しいブラウザタブで新しい Looker ウィンドウを開きます。

5. [Explore] > Orders and Users に移動します。

6. Users を開いて、使用可能なディメンションを確認します。

7. Users > [ディメンション] > Location で、以下を選択します。

• City
• Country
• State
• Zip

8. [実行] をクリックして、結果を確認します。

9. Orders and Users Explore のブラウザタブを閉じて、IDE のブラウザタブに戻ります。

さまざまな見出しの下に Explore のグループを作成する

1. training_ecommerce.model を開きます。

15 行目のモデルレベルのラベル パラメータの値が “E-Commerce Training” になっていることに注目してください。これは、Explore メニューに現在表示されている見出しです。Orders and Users Explore と Events Explore は、Explore メニューのこの見出しの下に整理されています。

Explore の group_label に関するドキュメント ページを確認し、次の質問に答えてください。

2. ラベル パラメータの前の部分で、Order Items Explore に “E-commerce - Inventory Team” という group_label を追加します。

explore: order_items { group_label: "E-commerce - Inventory Team" label: "Orders and Users"

3. fields パラメータの前の部分で、Events Explore に “E-commerce - Marketing Team” という group_label を追加します。

explore: events { group_label: "E-commerce - Marketing Team" fields: [ALL_FIELDS*, -users.city, -users.email, -users.first_name, -users.gender, -users.last_name, -users.state]

4. [変更内容を保存] をクリックし、[LookML を検証] をクリックします。

5. 新しいブラウザタブで新しい Looker ウィンドウを開きます。

6. [Explore] メニューを開き、オプションを確認します。

Explore がそれぞれの見出しの下に表示されるようになりました。新しい Explore を追加する際に、同じ group_label 値を使用して既存のグループを拡張し続けることも、新しい group_label 値を割り当てて独自の見出しを持つ新しいグループを作成することもできます。

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

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

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

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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 類似するフィールドまたは Explore を有用なカテゴリにグループ化する

お疲れさまでした

このラボでは、既存のオブジェクトを再利用し、わかりやすい命名規則を適用し、fields や hidden などの追加のパラメータを使用して、LookML プロジェクトのユーザビリティと持続可能性を向上させました。次に、特定の Explore で必要なフィールドのみが表示されるように制限し、group_label パラメータを使用して類似したフィールドと Explore を論理カテゴリにグループ化することで、Explore のナビゲーションを容易にしました。

次のステップと詳細情報

• LookML クイック リファレンス
• LookML の用語と概念
• Looker コミュニティ
• LookML の基礎の補足
• ベスト プラクティス: Looker ユーザーに良質なエクスペリエンスを提供

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

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

マニュアルの最終更新日: 2026 年 2 月 2 日

ラボの最終テスト日: 2025 年 12 月 3 日

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