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

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

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

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

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

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

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

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

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

ローカルプロジェクトのインポート機能は、インポートしたプロジェクトが同じ 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 パラメータに指定した値の型に関係なく（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 の左側のナビゲーションペインで [設定] を選択し、[資格情報のインポート] ページに移動します。

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

認証情報を追加する

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

[Import Credentials] ページの [URL] 見出しで、リポジトリ名にポインタを合わせると、[Test] ボタンと [Configure] ボタンを表示して、[Configure] をクリックします。
Looker で [Configure Git Authentication] ダイアログが表示され、リモートリポジトリの認証情報を構成できるようになります。ダイアログには、特定のリポジトリに必要な認証情報の種類が表示されます。
- リポジトリで認証にユーザー名とパスワード（または個人用のアクセストークン）が必要な場合は、ユーザー名とパスワードまたはトークンを入力し、[Save Changes] をクリックします。
  
  注: Looker では、GitHub のきめ細かい個人用アクセストークンがサポートされていません。HTTPS を使用して Looker プロジェクトを GitHub に接続するには、個人用のアクセストークンを作成するときに GitHub のTokens (classic) のオプションを使用します。
- このページで前述した SSH を使用したリモートプロジェクトのインポートの例のように、リポジトリに SSH 認証鍵が必要な場合は、Looker によって、ローカル SSH 認証鍵を示すダイアログが表示されます。[キーをコピー] をクリックして SSH 認証鍵をクリップボードにコピーし、リポジトリの鍵のリストに追加します。
  
  注: リモートプロジェクトが LookML リポジトリである場合、SSH 認証鍵はすでに存在している可能性があります。たとえば、LookML プロジェクトが最初に Git に接続されたときに、SSH 認証鍵がリポジトリに追加された可能性があります。リポジトリに新しい SSH 認証鍵を追加する場合は、既存の SSH 認証鍵はそのまま残します。
認証情報を保存したら、[テスト] をクリックして、リポジトリへの Looker のアクセスをテストします。

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

認証情報を編集する

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

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

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

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_dependency の override_constant サブパラメータを使用できます。これにより、定数に新しい値を提供できます（元のプロジェクトで定数に override_optional、override_required に設定された export がある場合）。インポートしたプロジェクトの定数値をオーバーライドすると、プロジェクトは override_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_core の orders テーブルと同一の構造の proj_a のデータベース内に orders というテーブルもあります。

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


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 テーブルに基づいています。