表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

ベストプラクティス: 持続性と管理性に優れた LookML の記述

これらのベストプラクティスには、経験豊富な Looker の機能横断的なチームによる推奨事項が反映されています。これらのインサイトは、実装から長期的な成功に至るまで、Looker のお客様との連携に携わった長年の経験に基づいています。これらの手法は、ほとんどのユーザーと状況に対応するよう作成されています。ただし、このページに示された推奨事項を実装する場合は、常に慎重に判断してください。

このページでは、持続性と管理性に優れた LookML の記述するための推奨事項について説明します。これらの推奨事項については、以降のセクションで詳しく説明します。

置換演算子を使用する
フィールドセットを定義する
コードの繰り返しを避ける
マップレイヤや値の形式などのアイテムを統合する
開発ガイドラインを作成する

置換演算子を使用する

置換演算子は、すべての LookML ファイルで一貫して使用する必要があります。LookML モデルでは、物理データモデル内のオブジェクトに対する参照ポイントは 1 つのみとします。そのオブジェクトを参照する必要がある後続の定義では、すでに定義されている LookML オブジェクトを参照するようにします。

基になるデータベース列から直接データを取得するすべての基本ディメンションに対して、基になるデータベーステーブルを参照する場合は、構文 ${TABLE}.field_name を使用します。スキーマやテーブルの名前が変更されると、デベロッパーはスキーマやテーブル名を 1 か所（sql_table_name パラメータ内）で更新し、コードの残りの部分に反映させることができます。

LookML 内ですでに定義されているディメンションまたは measure を参照する場合は、${field_name} 構文を使用します。列名が変更された場合、その変更は基本ディメンションまたは measure の sql パラメータでのみ更新する必要があります。この変更は、列を参照する他のすべてのフィールドに自動的に反映されます。たとえば、データベース内の列名が usersid から users_id に変更された場合は、Looker で参照を変更する必要があります。${field_name} を使用すると、更新する必要があるのは 1 行だけです。

複数のディメンションとメジャーが ${TABLE}.field_name で既存の LookML フィールドを参照する場合、多くの変更が必要になります。たとえば、次の LookML コードの例で this_week_count measure と this_month_count measure について考えてみましょう。

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "1 month"]
}

this_week_count と this_month_count は両方とも sql パラメータで構文 ${TABLE}.usersid を使用するため、3 つのフィールドすべての sql パラメータを更新する必要があります。

${field_name} を参照する場合、必要な変更は 1 つのみです。

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "1 month"]
}

置換演算子のその他の使用方法については、SQL の組み込みと LookML オブジェクトの参照のドキュメントをご覧ください。

フィールドセットを定義する

モデル内で再利用可能なフィールドのリストを維持するにはセットを使用します。繰り返しフィールドのリスト（fields パラメータを指定するかドリルフィールド内か）は、フィールドリストの更新やフィールド参照の変更を行う単一の場所をモデル内に作成するために、セットに組み込む必要があります。セットの詳細については、set パラメータのドキュメントページをご覧ください。

コードの繰り返しを避ける

LookML オブジェクトを構成要素として捉え、extends パラメータを使用して、コードを繰り返さずにさまざまな方法でオブジェクトを組み合わせることが可能です。コードの再利用に関する詳細情報と例については、Extend によるコードの再利用のドキュメントページをご覧ください。その他の例については、extends（ビューの場合）と extends（Explore の場合）のパラメータドキュメントページ、および結合を定義する拡張機能に関するコミュニティ投稿をご覧ください。

複数の場所でコードを繰り返さないようにすることで、Explore 全体で整合性を維持します。これを実現するためのその他のアイデアについては、Explore 間の不整合の回避に関する Looker コミュニティの投稿をご覧ください。

マップレイヤや値の形式などのアイテムを統合する

map_layers.lkml という LookML ファイルで、カスタムのマップレイヤを一元的に定義します。このファイルは、Looker のプロジェクトファイルに関するドキュメントに沿って作成できます。このファイルは、必要に応じてモデル間で含めることができます。または、データファイルを LookML プロジェクトにドラッグ&ドロップして JSON ファイルをリポジトリに直接追加し、モデル内で参照します。

たとえば、次の LookML コードを含むマップレイヤファイル map_layers.base.lkml があるとします。

map_layer: example_africa {
  file: "africa_file_name.json"
  property_key: "geounit"
}

map_layer: example_asia {
  file: "asia_file_name.json"
  property_key: "geounit"
}

map_layer: example_europe {
  file: "europe_file_name.json"
  property_key: "geounit"
}

LookML コード include: "map_layers.base.lkml" を目的のモデルファイルに追加することで、マップレイヤファイル map_layers.base.lkml をプロジェクト内の任意のモデルに含めることができます。

モデル内で、カスタムの値のフォーマットを一元的に設定する。 named_value_format パラメータを使用してモデル内でカスタム形式を設定してから、ディメンションと measure で value_format_name パラメータを使用し、それらの形式を参照します。

開発ガイドラインを作成する

開発ガイドラインを定義し、LookML モデルを開発、スケーリングしやすくします。サンプル開発ガイドラインリストのチュートリアルについては、LookML 開発ガイドラインの例に関する Looker コミュニティの投稿をご覧ください。一般的なガイドラインには、次の要件があります。

LookML ファイルを明確に整理して、一貫性を保ち、操作しやすくする
ビューおよびモデル全体でコメントを使用して、記述された LookML にコンテキストを追加する
Markdown ファイルを使用して Looker 内でドキュメントを作成する

ベスト プラクティス: 持続性と管理性に優れた LookML の記述