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

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

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

  • インストール済みの Looker Block 上に、直接変更を加えることなく構築する。Looker でブロックに変更を加えた場合、追加した LookML がすべて別のリポジトリに保持されるため、その変更を pull できます。

  • データベースのスキーマに基づいて自動生成されたベース プロジェクトを維持する。すべてのカスタム ディメンション、measure などは、自動生成されたプロジェクトからすべての LookML をインポートする別のプロジェクトに配置できます。すべてのカスタム LookML を上書きすることなく、データベース スキーマが変更されたときにベース プロジェクトを定期的に再生成できます。

  • 共有オブジェクトを単一プロジェクトにカプセル化し、他の複数のプロジェクトにインポートする。たとえば、複数のデータベースに共通のテーブルがある場合は、そのビューを 1 つのプロジェクトにまとめて 1 つのプロジェクトに配置できます。そしてそのテーブルを他のプロジェクトにインポートすることで、複数のプロジェクトで使用できます。

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

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

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

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

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

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

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

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

マニフェスト ファイルで、project_name パラメータで現在のプロジェクトの名前を指定します(プロジェクトのマニフェスト ファイルを作成する際、Looker ではこのパラメータが自動的に入力されます)。ローカル プロジェクトを現在のプロジェクトにインポートするには、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_dependencyref サブパラメータで指定する場合は、リモート プロジェクトで新しい 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 パラメータに指定した値の型に関係なく(commit SHA であっても)、プロジェクトに remote_dependency パラメータを追加すると、IDE によってトップ プロジェクト ナビゲーション バーに依存関係の更新ボタンが表示されます。

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

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

新しい commit が存在する場合、Looker は IDE の Git アクション パネルに [依存関係の更新] オプションを表示します。

[依存関係の更新] オプションを選択して、最新のリモート プロジェクト ファイルをプロジェクトに取り込みます。

最新のファイルを取得したら、LookML を検証して、プロジェクトのすべての参照が更新されたリモート プロジェクト ファイルで動作することを確認できます。その後、破損している参照を修正し、ユーザーのダウンタイムなしで変更をデプロイできます。

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

Looker は、ファイル名が manifest_lock.lkml のマニフェスト ロックファイルを使用して、リモートからインポートされたプロジェクトのバージョンを追跡します。マニフェスト ロックファイルは、Looker IDE のファイル ブラウザ パネルに表示されます。

ロックファイルは 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 になります。

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

非公開リモート リポジトリの認証情報を構成するには、IDE 内の左側のナビゲーション パネルで [Settings] を選択して [Import Credentials] ページに移動します。

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

認証情報を追加する

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

  1. [Import Credentials] ページの [URL] 見出しで、リポジトリ名にポインタを合わせると、[Test] ボタンと [Configure] ボタンを表示して、[Configure] をクリックします。

  2. Looker で [Configure Git Authentication] ダイアログが表示され、リモート リポジトリの認証情報を構成できるようになります。ダイアログには、特定のリポジトリに必要な認証情報の種類が表示されます。

    • リポジトリで認証にユーザー名とパスワード(または個人用のアクセス トークン)が必要な場合は、ユーザー名とパスワードまたはトークンを入力し、[Save Changes] をクリックします。

    • このページで前述した SSH を使用したリモート プロジェクトのインポートの例のように、リポジトリに SSH 認証鍵が必要な場合は、Looker によって、ローカル SSH 認証鍵を示すダイアログが表示されます。[鍵をコピー] をクリックして SSH 認証鍵をクリップボードにコピーし、リポジトリの鍵のリストに追加します。

  3. 認証情報を保存したら、[テスト] をクリックして、リポジトリへの Looker アクセスをテストします。

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

認証情報を編集する

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

  1. [テスト] ボタンと [編集] ボタンを表示するには、認証情報がすでに構成されているリポジトリにポインタを置き、[編集] をクリックします。

  2. リポジトリが認証にユーザー名とパスワード(または個人アクセス トークン)を必要とする場合は、[Clear Credentials] をクリックし、確認のダイアログで [Yes, clear credentials] をクリックします。

  3. [Configure Git Authentication] ダイアログで新しい認証情報を入力し、[Save Changes] をクリックします。

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

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

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

オブジェクト ブラウザでは、アクティブなプロジェクトに含まれるインポートしたプロジェクト ファイルのオブジェクトを表示できます。オブジェクト ブラウザには、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 フォルダを有効にしてパスを指定する方法については、include パラメータ ページのパス構文セクションをご覧ください。

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

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

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

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

IDE フォルダを有効にしてワイルドカードを使用する方法については、include パラメータ ページのワイルドカードの例をご覧ください。

モデルファイルを含める

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

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

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

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

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

プロジェクトの [データ] セクションに保存されているファイルはインポートされません。インポートしたプロジェクトのデータファイル(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_dependencyoverride_constant サブパラメータを使用できます。これにより、定数に新しい値を提供できます(元のプロジェクトで定数に override_optionaloverride_required に設定された export がある場合)。インポートしたプロジェクトの定数値をオーバーライドすると、プロジェクトは override_constant パラメータで指定した値を使用します。

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

この例では、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_coreorders テーブルと同一の構造の proj_a のデータベース内に orders というテーブルもあります。

proj_coreproj_a は同じインスタンス上にあるため、local_dependency を使用して proj_aorders ビューをインポートできます。local_dependencyoverride_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_coreschema_name 定数が export: override_required に設定されているため、proj_a(インポートしたプロジェクト)で値をオーバーライドしないと Looker がエラーを表示します。

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

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