lookml-refinements について
LookML 開発者向けに、ファイルの include、refinement、プロジェクト構成を解説するガイドです。既存のビューや Explore を段階的に変更する方法や、Explore ごとのファイル分割を扱います。
主な機能
- 01LookML ファイルの include 範囲指定
- 02refinement による変更の重ね合わせ
- 03include 順による上書きの制御
- 04Explore ごとのファイル分割
活用シーン
- 01元のファイルを変更せずにベンダービューをカスタマイズ
- 02特定の Explore にフィールドを追加
- 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 を変更できます。これは、次の用途で特に重要です。
- ハブ&スポーク:コアとなる「ハブ」モデルを、特定の「スポーク」ユースケースに合わせて調整します。
- ベンダーブロック:フォークせずに、読み取り専用ブロック(Google Analytics など)をカスタマイズします。
構文
- 元の定義:
view: users { ... } - Refinement:
view: +users { ... } - 要件:元のファイルを見つける前に、必ず
includeする必要があります。
適用ルール
- 最後の Include が優先:複数のファイルで
+usersを Refinement する場合、includeの順序によって最終的な状態が決まります。 - 追加:新しいパラメーターが追加されます。
- 上書き:既存のパラメーターが置き換えられます。
- 例外:リスト型のパラメーター(
drill_fieldsなど)は、実装によってマージされずに置き換えられることがよくあります。リスト全体を明示的に再指定する方が安全です。
- 例外:リスト型のパラメーター(
- フィールドの変更:
- フィールドを変更するには、まったく同じ名前で再宣言します。
- 変更したいパラメーターだけを指定すれば十分です(例:
descriptionやlabelの追加)。
3. 「1 ファイルにつき 1 Explore」パターン
保守性に優れたエンタープライズ規模の LookML を実現するには、.explore.lkml ファイルを使った1 ファイルにつき 1 Exploreのパターンに従います。
構成
- ファイル:
explores/orders.explore.lkml - 内容:
- この Explore に必要なビューだけを
includeします。 explore: orders { ... }を定義します。
- この Explore に必要なビューだけを
- モデルファイル:
models/my_model.model.lkmlinclude: "/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} ;;
}
}
コメント
Markdown 対応