Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

他のプロジェクトからファイルをインポートする

ローカルプロジェクトのインポート機能は、ローカルにある LookML プロジェクトからファイルをインポートする実験的な Labs 機能です。試験運用機能は十分に開発されていないため、大幅に変更されるか、完全に削除される可能性があります。

現在、リモートまたはローカルにある LookML プロジェクトからファイルをインポートすることは、モデルのローカライズとの互換性がありません。

他の LookML プロジェクトや外部リポジトリから現在のプロジェクトにファイルをインポートできます。これにより、複数のプロジェクトでモデルファイル、ファイル、その他のファイルを使用できます。

これにはいくつかのユースケースがあります。以下に例を示します。

インストール済みの Looker Block 上に、直接変更を加えることなく構築する。Looker でブロックに変更を加えた場合、追加した LookML がすべて別のリポジトリに保持されるため、簡単にその変更を pull できます。
データベースのスキーマに基づいて自動生成されたベースプロジェクトを維持する。すべてのカスタムディメンション、measure などは、自動生成されたプロジェクトからすべての LookML をインポートする別のプロジェクトに配置できます。データベーススキーマが変更されたときにベースプロジェクトを定期的に再生成できるため、カスタム LookML をすべて上書きできません。
共有オブジェクトを 1 つのプロジェクトにカプセル化し、他の複数のプロジェクトにインポートする。たとえば、複数のデータベースに共通のテーブルがある場合は、そのビューを 1 つのプロジェクトにまとめて 1 つのプロジェクトに配置できます。そしてそのテーブルを他のプロジェクトにインポートすることで、複数のプロジェクトで使用できます。

別のプロジェクトからファイルをインポートするには、次の操作を行います。

プロジェクトマニフェストファイルを作成する。
インポートするローカルプロジェクトまたはリモートプロジェクトを指定する。
インポートされたプロジェクトのファイルを表示する。
インポートされたプロジェクトのファイルを含める。

これにより、インポートしたプロジェクトのファイルからフィールドを参照したり、インポートしたプロジェクトに定義されている定数の値をオーバーライドしたりできます（定数でオーバーライドが許可されている場合）。

プロジェクトマニフェストファイルを作成する

他のプロジェクトからファイルをインポートするプロジェクトには、プロジェクトマニフェストファイルが必要です。プロジェクトにまだマニフェストファイルがない場合は、Looker IDE 内のファイルブラウザの上部にある [+] アイコンでマニフェストファイルを作成できます。

プロジェクトをインポートするには、マニフェストでプロジェクトを指定します。以下のセクションで説明するように、ローカルプロジェクトまたはリモートプロジェクトを指定できます。

ローカルにあるプロジェクトをインポートする

Looker の管理者は ローカルプロジェクトのインポートの Labs 機能を有効にして、ローカルファイルをプロジェクトにインポートできるようにする必要があります。

ローカルプロジェクトのインポート機能は、インポートしたプロジェクトが同じ Looker インスタンス上にある場合にのみ使用できます。インポートしたプロジェクトのモデルに対するモデル権限があることもおすすめします。デベロッパーが、インポートしたプロジェクトに対するモデル権限を持っている場合、バージョニングが動的になります。つまり、インポートしたプロジェクトでの変更は、そのインポート元のプロジェクトに直ちに影響します。これにより、デベロッパーは本番環境に push する前に、両方のプロジェクトで変更を検証できます。また、デベロッパーが両方のプロジェクトに対してモデル権限を持つ場合、インポートしたプロジェクトのファイルでデベロッパーの開発モードのステータスが反映されます。そのため、デベロッパーが開発モードの場合は、インポートしたプロジェクトのファイルが開発モードで Looker IDE に表示されます。デベロッパーが本番環境モードの場合は、インポートしたプロジェクトが本番環境モードで Looker IDE に表示されます。

ローカルにインポートするには、project_name パラメータを使用して現在のプロジェクトを指定します。1 つ以上の local_dependency パラメータを使用して、インポートするプロジェクトを指定します。

# This project
project_name: "my_project"

# The project to import
local_dependency: {
  project: "my_other_project"
}

次のシナリオでは、ローカルプロジェクトインポートの代わりにリモートプロジェクトインポートを使用します。

デベロッパーがインポート済みプロジェクトのモデルにモデル権限がありません。この場合、Looker はインポートされたプロジェクトの本番環境モードのクローンを作成し、その静的バージョンの IDE を表示します。静的バージョンでは、開発モードのファイルは表示されません。また、デベロッパーに対するアラートがないまま、現在の本番環境モードが古くなっている可能性もあります。リモートでの商品インポートを使用し、リモートプロジェクトの Git ブランチまたは Git リリースを指定する ref を指定することをおすすめします。その場合、Looker はリモートプロジェクトの新しい commit を自動的に検出するため、デベロッパーにアラートが送信され、最新バージョンのリモートプロジェクトのファイルを取り込むことができます。
デベロッパーは、インポートされたプロジェクトの本番環境バージョンを常に操作する必要があります。
開発者は、インポートしたプロジェクトのファイルの静的バージョンを使用する必要があります。

リモートプロジェクトをインポートする

リモートインポートでは、インポートしたプロジェクトが同じインスタンスに存在している必要はありません。代わりに、プロジェクトはリモートの Git リポジトリを介してインポートされます。

リモートリポジトリをインポートするには、remote_dependency パラメータを使用してリモートリポジトリの情報を提供します。remote_dependency パラメータは、以下の情報とサブパラメータを取ります。

インポートしたプロジェクトの名前。任意の名前にできます。以下の例では、プロジェクトの名前は ga_360_block です。include 文でこの名前を使用して、LookML プロジェクト内のインポートされたファイルを参照します。この名前は、Looker IDE の imported_projects フォルダ内のフォルダ名としても使用されます。
url サブパラメータは、外部 Git リポジトリのアドレスを指定します。リポジトリのメイン URL を使用します。
ref サブパラメータは、Git ブランチ、Git リリースタグ、または Git リポジトリ内の commit の SHA を指定します。静的なバージョニングが必要な場合は、commit SHA を指定できます。これにより、インポートしたプロジェクトでの変更はプロジェクトに自動的に反映されません（Looker Blocks では、これが最適なオプションとなります）。Looker でリモートプロジェクト内の新しい commit を自動的に検出する場合は、Git ブランチまたは Git リリースタグを指定できます。詳細については、このページにあるリモートプロジェクトの新しいバージョンを自動検出するをご覧ください。
override_constant サブパラメータは、インポートしたプロジェクトで定義されている定数の値をオーバーライドできるオプションサブパラメータです。

プロジェクトマニフェストファイルの remote_dependency パラメータの例を次に示します。この例では HTTPS 接続を使用しています。

remote_dependency: ga360_block {
  url: "https://github.com/llooker/google_ga360"
  ref: "master"
  override_constant: connection {
    value: "importing_project_connection"
  }
}

SSH も使用できます。

remote_dependency: ga360_block {
  url: "git@github.com:llooker/google_ga360.git"
  ref: "master"
  override_constant: connection {
    value: "importing_project_connection"
  }
}

リモート依存関係を追加したら、リモートプロジェクト用のインポート認証情報の構成が必要な場合があります。このページの限定公開リモートリポジトリの認証情報を構成するをご覧ください。

リモートプロジェクトの新しいバージョンを自動的に検出する

Git ブランチまたは Git リリースタグを remote_dependency の ref サブパラメータで指定する場合は、リモートプロジェクトで新しい commit を自動的に Looker に検出させることができます。

たとえば、ref サブパラメータに master 分岐が指定されているリモート依存関係は次のとおりです。

remote_dependency: exchange_rate {
  url: "https://github.com/llooker/datablocks-exchangerate.git"
  ref: "master"
}

master ブランチが新しい commit で更新されると、Looker が自動的に変更を検出します。

v1.0 リリースタグが指定されている例を次に示します。

remote_dependency: e_faa_original {
  url: "https://github.com/llooker/google_ga360"
  ref: "v1.0"
}

指定した ref の種類に関係なく、プロジェクトに remote_dependency パラメータを追加すると、commit SHA であっても IDE に [Update Dependencies] ボタンが表示されます。

ボタンをクリックすると、リモートプロジェクトのファイルが表示されます。これがプロジェクトに追加した最初のリモート依存関係の場合、依存関係を更新すると Looker に対してマニフェストロックファイルの作成を求めるメッセージが表示されます。Looker では、マニフェストロックファイルを使用してリモートプロジェクトのバージョンを追跡します。

ref サブパラメータで Git ブランチまたは Git リリースタグを指定した場合、Looker IDE が更新されるたびに Looker が新しい commit を確認します。これは、Looker デベロッパーが開発モードに移動して IDE で Git の操作を行ったり、ブラウザを更新したりした際に行われます。

新しい commit がある場合、Looker は IDE の Git 操作パネルに [Update Dependencies] オプションが表示されます。

[Update Dependencies] オプションを選択すると、最新のリモートプロジェクトファイルがプロジェクトに取り込まれます。

最新のファイルを用意したら、LookML を検証して、更新されたすべてのリモートプロジェクトファイルで、プロジェクトのすべての参照が機能していることを確認できます。こうすることで、壊れた参照を修正し、ダウンタイムを発生させずに変更をデプロイすることができます。

マニフェストロックファイル

Looker では、マニフェストロックファイルを使用して、リモートインポートしたプロジェクトのバージョンを追跡します。

ロックファイルは Looker によって自動的に管理されるため、Looker デベロッパーはマニフェストロックファイルの作成や編集を行う必要はありません。

マニフェストロックファイルには、url サブパラメータと ref サブパラメータを使用した remote_dependency エントリで表される各リモートプロジェクトが表示されます。

remote_dependency パラメータは、マニフェストファイルで Looker デベロッパーが指定したリモートプロジェクトの名前を示します。
url サブパラメータは、Looker デベロッパーがマニフェストファイルで指定した外部 Git リポジトリのアドレスを示します。
ref サブパラメータは、Looker がプロジェクトで使用しているプロジェクトのバージョン（commit SHA で指定）を示します。
- Git ブランチまたは Git リリースタグの ref を使用してマニフェストファイルでリモートプロジェクトが定義されている場合、ref パラメータはプロジェクトで現在使用されているファイルバージョン（リモートプロジェクトの commit SHA）を示します。リモートプロジェクトに新しい commit がある場合、Looker には IDE の [Update Dependencies] ボタンが表示され、最新のリモートプロジェクトのファイルを取り込むことができます。マニフェストロックファイルの ref の値が更新され、そのブランチまたはリリースタグの最新の commit SHA が表示されます。
- リモートプロジェクトが特定の commit SHA の ref を使用してマニフェストファイルで定義されている場合、マニフェストロックファイル内の ref パラメータは同じ commit SHA になります。

限定公開リモートリポジトリの認証情報を構成する

[Import Credentials] の設定には、プロジェクトのマニフェストファイルで定義されている各リモートリポジトリの URL のリスト、リポジトリに使用される認証の種類（https または ssh）、Looker がリポジトリに問題なく接続できるかどうかが表示されます。

認証情報を追加する

リポジトリの認証情報を追加するには:

リポジトリ名にカーソルを合わせると [Test] ボタンおよび [Configure] ボタンが表示されるので、[Configure] をクリックします。
Looker でダイアログボックスが表示され、リモートリポジトリの認証情報を構成できます。ダイアログボックスには、そのリポジトリに必要な認証情報の種類が表示されます。
- リポジトリの認証にユーザー名とパスワード（または個人用のアクセストークン）が必要な場合は、ユーザー名とパスワードまたはトークンを入力して [変更を保存] をクリックします。
- リポジトリに SSH 認証鍵が必要な場合（こちらの例など）、Looker でローカル SSH 認証鍵を示すダイアログボックスが表示されます。[Copy Key] をクリックして、SSH 認証鍵をクリップボードにコピーし、リポジトリの鍵のリストに追加します。
リモートプロジェクトが LookML リポジトリである場合は、既存の SSH 認証鍵がすでに存在している可能性があります。たとえば、LookML プロジェクトが Git に接続されたときにリポジトリに追加された SSH 認証鍵などです。リポジトリに新しい SSH 認証鍵を追加するときは、既存の SSH 認証鍵はそのまま残します。
認証情報を保存したら、[テスト] ボタンをクリックして、リポジトリに対する Looker のアクセスをテストします。

接続テストに合格してリポジトリに接続すると、[Import Credentials] にリポジトリ名の横に緑色のチェックマークが表示されます。

認証情報の編集

リポジトリの認証情報を編集するには:

認証情報が構成されているリポジトリにカーソルを合わせると [Test] ボタンと [Edit] ボタンが表示されるので、[Edit] をクリックします。
リポジトリが認証にユーザー名とパスワード（または個人アクセストークン）を必要とする場合は、[Clear Credentials] をクリックし、確認のポップアップで [Yes, clear credentials] をクリックします。
[Configure Git Authentication] ポップアップに新しい認証情報を入力し、[Save Changes] をクリックします。

インポートしたプロジェクトのファイルを表示する

Looker IDE では、インポートしたプロジェクトファイルが左側のナビゲーションペインの imported_projects フォルダに表示されます。インポートしたプロジェクトファイルをクリックすると、その内容が表示されます。

ローカルプロジェクトとリモートプロジェクトのファイルが imported_projects フォルダに表示されます。

これらのファイルは編集できないので、IDE でファイルを一括編集する場合は、インポートしたプロジェクトファイルは表示されません。

オブジェクトブラウザでは、アクティブなプロジェクトに含まれるインポートしたプロジェクトファイルのオブジェクトを表示できます。オブジェクトブラウザには、Looker IDE のナビゲーションバーからアクセスします。

さらに、develop 権限を持つユーザーは、メタデータパネルを使用して、インポートしたプロジェクトのオブジェクトに関する情報（オブジェクトが定義されているインポートファイルに移動するリンクなど）を表示できます。詳細については、LookML オブジェクトのメタデータのドキュメントをご覧ください。

インポートしたプロジェクトのファイルを含める

モデルファイルの include パラメータで、そのモデルで使用可能なプロジェクトファイルを指定します。ローカルまたはリモートのインポートしたプロジェクトをマニフェストファイルで指定したら、モデルファイルの include パラメータを使用して、インポートしたプロジェクトのファイルを指定できます。マニフェストファイルにリストされているプロジェクトのファイルのみを含めることができます。

別のプロジェクトのファイルを include するには、スラッシュ 2 つ（//）とインポートしたプロジェクトの名前をファイル名として使用します。インポートしたプロジェクト名の後に、スラッシュ 1 つ（/）と、含めたいファイルへのフルパスを続けます。

たとえば、以下の include コマンドでは、インポートされた e_flights プロジェクトの users ビューファイルと、インポートされた e_commerce プロジェクトの orders ビューを示しています。

include: "//e_flights/views/users.view.lkml"
include: "//e_commerce/public/orders.view.lkml"

IDE フォルダを有効にしてパスを指定する方法については、IDE 内のフォルダの操作のドキュメントでパス構文セクションをご覧ください。

ワイルドカードを使用すると、複数のファイルを含めることができます。たとえば、インポートされたビュー e_flights の /views/ ディレクトリにすべてのビューファイルを含めるには、次のコマンドを実行します。

include: "//e_flights/views/*.view"

また、ワイルドカードを使用して、特定のディレクトリレベルや、インポートしたプロジェクト内の再帰ディレクトリをスコープにすることができます。

include: "//e_flights/*/*.view.lkml"
include: "//e_commerce/*/*.view.lkml"

IDE フォルダでワイルドカードを使用する方法については、IDE 内のフォルダの操作のドキュメントのワイルドカードの例をご覧ください。

モデルファイルを含める

別のプロジェクトのモデルファイルを含めることはできません。プロジェクト間で Explore の再利用、絞り込み、拡張を行う場合は、インポートしたプロジェクトで別の Explore ファイルを作成してから、その Explore ファイルを他のプロジェクトに含めます。詳細については、include パラメータのドキュメントのページの Explore をモデルに含めるをご覧ください。

他のファイルを含むファイルを含める

他のファイルを含むファイルを含めると、ファイルがそれを含む次のプロジェクトに渡される前に、含まれるすべてが解決されます。

たとえば現在のプロジェクトに他のプロジェクト（proj_A）からファイル（A）をインポートし、インポートしたファイルにプロジェクト proj_B からのファイル B を含む include パラメータが含まれる場合、ファイル B はファイル A が現在のプロジェクトにインポートされる前にファイル A に含まれます。

データファイルをインポートする

プロジェクトの Data セクションに保存されているファイルはインポートされません。インポートしたプロジェクトのデータファイル（map_layer パラメータなど）を参照するには、ファイルのフルパスとファイル名を使用します。例:

map_layer: json_from_imported_project {
  file: "//path_to_imported_project/folder/filename.topojson"
  ...
}

インポートされたプロジェクトからファイルを参照する

ビューファイルをプロジェクトにインポートしたら、構文 ${view_name.field_name} を使用して、そのプロジェクトにネイティブであるかのようにインポートしたビューのフィールドを参照できます。たとえば、ga_360_block プロジェクトをプロジェクトマニフェストファイルにインポートし、モデルファイルに次の include 文があるとします。

include: "//ga_360_block/ga_block.view"

${ga_block.hits_total} 構文を使用して、含まれる ga_block ビューから hits_total フィールドを参照します。

インポートしたプロジェクトのファイルで定数を使用する

LookML 定数を使用すると、プロジェクトのマニフェストファイルに値を定義できます。この値はプロジェクト全体で再利用できます。constant パラメータの export サブパラメータは、定数を参照するファイルが別のプロジェクトにインポートされたときに定数の値をオーバーライドできるかどうかを指定します。

export 要素には次の値を使用できます。

none: export のデフォルト値。インポートしたプロジェクトで定数の値をオーバーライドすることはできません。インポートプロジェクトでは、インポートしたプロジェクトのマニフェストファイルで指定された定数値を使用します。
override_optional: インポートしたプロジェクトでは、定数値をオプションでオーバーライドできます。インポートされたプロジェクトのマニフェストファイルで値が指定されていない場合は、インポートされたプロジェクトの元の値が使用されます。
override_required: インポートしたプロジェクトは、インポートしたプロジェクトのマニフェストファイルで最初に指定された定数値をオーバーライドする必要があります。インポートしたプロジェクトで新しい定数値が指定されていない場合は、エラーが表示されます。

定数を参照するファイルをプロジェクトにインポートする場合、プロジェクトのマニフェストファイルで local_dependency または remote_dependency の override_constant サブパラメータを使用できます。これにより、定数に新しい値を提供できます（元のプロジェクトで定数に override_optional、override_required に設定された export がある場合）。インポートしたプロジェクトの定数値をオーバーライドすると、プロジェクトは override_constant パラメータで指定した値を使用します。

定数は、元々定義されているプロジェクトのファイルでのみ使用できます。そのため、ファイルをインポートしたプロジェクトで定義された定数は、インポートしたファイルでのみ使用でき、インポート元のプロジェクトで定義されたファイルでは使用できません。

インポートしたプロジェクトのファイルで定数を使用する場合は、constant パラメータを使用して、インポートしたプロジェクトのマニフェストファイルに新しい定数を定義します。この方法で定義された定数は、インポートしたプロジェクトで定義されたファイルでのみ使用できます。

たとえば、1 つの Looker インスタンスで複数のデータベースを管理し、データベースごとに個別のプロジェクトを使用するとします。この例では、データスキーマが各データベースで同一で、分析を 1 回定義して各データセットに適用することを目標としています。

この例で、proj_core は、他のプロジェクトにインポートするビューを定義したベースプロジェクトであるとします。また、インポートするビューのうち 1 つが orders ビューです。これは次のように定義されています。


view: orders {
  sql_table_name: "@{schema_name}.orders"
}

orders ビューのもとになるスキーマは、proj_core マニフェストファイルで定義されている schema_name 定数を使用して sql_table_name パラメータで指定されます。以下の例では、schema_name 定数が export: override_required に設定されているため、schema_name をインポートするすべてのプロジェクトは override_constant パラメータを使用して値をオーバーライドする必要があります。


constant: schema_name {
  value: "proj_core_schema"
  export: override_required
}

この例では、orders ビューを proj_a というローカルプロジェクトにインポートするとします。proj_a のデータベースには、ベースプロジェクト proj_core の orders テーブルと同じ構造の orders というテーブルもあります。

proj_core と proj_a は同じインスタンス上にあるため、local_dependency を使用して proj_a に orders ビューをインポートできます。local_dependency の override_constant サブパラメータを使用して、proj_a のマニフェストファイルのスキーマ proj_a_schema を指すように schema_name 定数を更新できます。


project_name: "proj_a"

local_dependency: {
  project: "proj_core"
  override_constant: schema_name {
    value: "proj_a_schema"
  }
}

この例では、project_core で schema_name 定数が export: override_required に設定されているため、proj_a（インポートしたプロジェクト）で値をオーバーライドしないと Looker がエラーを表示します。

proj_a の schema_name 定数をオーバーライドすることで、新しいビューファイルを作成してフィールドをゼロから定義するのではなく、proj_core の orders ビューで定義されたフィールドを使用できます。この例では、orders ビューはプロジェクトごとに異なるテーブルに対応しています。

proj_core では、orders ビューはデータベース内の proj_core_schema.orders テーブルに基づいています。
proj_a では、orders ビューはデータベース内の proj_a_schema.orders テーブルに基づいています。