mcpField
L
lookml-refinements

lookml-refinements

github.com/looker-open-sourceデータ・データベース43146 回インストール2 週間前に更新
リポジトリ

lookml-refinements について

LookML 開発者向けに、ファイルの include、refinement、プロジェクト構成を解説するガイドです。既存のビューや Explore を段階的に変更する方法や、Explore ごとのファイル分割を扱います。

主な機能

  1. 01LookML ファイルの include 範囲指定
  2. 02refinement による変更の重ね合わせ
  3. 03include 順による上書きの制御
  4. 04Explore ごとのファイル分割

活用シーン

  1. 01元のファイルを変更せずにベンダービューをカスタマイズ
  2. 02特定の Explore にフィールドを追加
  3. 03大規模プロジェクトで命名や共同作業の衝突を軽減

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/looker-open-source/looker-skills --skill lookml-refinements

インストール後、Claude Code で/lookml-refinementsを入力して読み込まれたか確認します。

詳細

手順

1. Include の仕組み

include を使うと、Open LookML オブジェクト(ビュー、Explore、ダッシュボード)を現在のファイルで利用できるようになります。

  • ワイルドカード(*):任意の文字列に一致します。

    • /views/*.view:絶対パスの /views ディレクトリにあるすべてのビュー。
    • *.view:現在のディレクトリにあるすべてのビュー。
    • /**/*.view:(再帰的に)現在のディレクトリとすべてのサブディレクトリにあるビュー。
    • //project-name/views/*.view:リモートプロジェクトのインポート(プロジェクトマニフェストが必要です)。
  • ベストプラクティス:名前空間の衝突やパフォーマンスの低下を避けるため、対象を具体的に指定します。

    • 悪い例:include: "/**/*.view"(あらゆる場所からすべてをインポートします。処理が遅く、リスクがあります)。
    • 良い例:include: "/views/users.view"(明示的に指定します)。
    • 良い例:include: "/views/finance/*.view"(特定のドメインに範囲を限定します)。

2. Refinement(レイヤリング)

Refinement を使うと、元のファイルを変更せずに既存のビューや Explore を変更できます。これは、次の用途で特に重要です。

  1. ハブ&スポーク:コアとなる「ハブ」モデルを、特定の「スポーク」ユースケースに合わせて調整します。
  2. ベンダーブロック:フォークせずに、読み取り専用ブロック(Google Analytics など)をカスタマイズします。
構文
  • 元の定義:view: users { ... }
  • Refinement:view: +users { ... }
  • 要件:元のファイルを見つける前に、必ず include する必要があります。
適用ルール
  1. 最後の Include が優先:複数のファイルで +users を Refinement する場合、include の順序によって最終的な状態が決まります。
  2. 追加:新しいパラメーターが追加されます。
  3. 上書き:既存のパラメーターが置き換えられます。
    • 例外:リスト型のパラメーター(drill_fields など)は、実装によってマージされずに置き換えられることがよくあります。リスト全体を明示的に再指定する方が安全です。
  4. フィールドの変更:
    • フィールドを変更するには、まったく同じ名前で再宣言します。
    • 変更したいパラメーターだけを指定すれば十分です(例:description や label の追加)。

3. 「1 ファイルにつき 1 Explore」パターン

保守性に優れたエンタープライズ規模の LookML を実現するには、.explore.lkml ファイルを使った1 ファイルにつき 1 Exploreのパターンに従います。

構成
  • ファイル:explores/orders.explore.lkml
  • 内容:
    1. この Explore に必要なビューだけを include します。
    2. explore: orders { ... } を定義します。
  • モデルファイル:models/my_model.model.lkml
    • include: "/explores/orders.explore.lkml"
    • モデルファイル自体には explore の定義を記述しません。
メリット
  • パフォーマンス:接続は、要求された Explore に必要なものだけを解析します。
  • 名前空間の整理:ビュー名の衝突は、それらをインポートした特定の Explore ファイル内に限定されます。
  • コラボレーション:モデルファイルでのマージコンフリクトを避けながら、開発者が異なる Explore を並行して作業できます。

例

シナリオ:ベンダービューの変更

元の定義(読み取り専用)://lkr_block/users.view

view: users {
  dimension: id { primary_key: yes }
  dimension: name {}
}

Refinement:views/users_rfn.view

include: "//lkr_block/users.view"

view: +users {
  # 1. New Dimension
  dimension: email {
    sql: ${TABLE}.email ;;
  }

  # 2. Modify Existing Dimension
  dimension: name {
    label: "Full Name"
    description: "Legal name of the user."
  }
}

シナリオ:Explore 固有のロジック

ファイル:explores/marketing_orders.explore.lkml

include: "/views/orders.view"
include: "/views/users.view"

# Refine users ONLY for this explore to add marketing-specific fields
view: +users {
  dimension: acquisition_channel {
    sql: ${TABLE}.utm_source ;;
  }
}

explore: marketing_orders {
  view_name: orders
  from: orders # mapping 'orders' view to 'orders' alias (standard)
  
  join: users {
    sql_on: ${orders.user_id} = ${users.id} ;;
  }
}

コメント