データグループ

用途

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}
階層
datagroup
デフォルト値
なし

許可
データグループの識別子と、データグループのプロパティを定義するサブパラメータ。

定義

datagroup を使用して、Explore のキャッシュ保存ポリシーを割り当てるか、永続的な派生テーブル（PDT）の永続性戦略を指定します。異なる Explore と PDT に複数のポリシーを設定する場合は、個別の datagroup パラメータを使用して各ポリシーを指定します。

英数字とアンダースコアのみを使用して、データグループの一意の名前を指定します。他の文字は使用できません。

データグループのラベルと説明を追加できます。

  • label: データグループのラベルを指定します（省略可）。詳しくは、このページの label と description のセクションをご覧ください。
  • description: データグループの目的とメカニズムを説明するために使用できるデータグループの説明（省略可）を指定します。詳しくは、このページの label と description のセクションをご覧ください。

datagroup サブパラメータを使用して、キャッシングと永続性のポリシーの詳細を指定します。

  • max_cache_age: 期間を定義する文字列を指定します。Looker ではクエリがキャッシュされてからこの期間を過ぎると、キャッシュは無効となります。次回このクエリが発行されると、クエリはデータベースに送られ、最新の結果が取得されます。詳しくは、このページの max_cache_age をご覧ください。
  • sql_trigger: 1 つの行と 1 つの列を返す SQL クエリを指定します。クエリが返した値が以前の結果と異なる場合、データグループはトリガー状態になります。詳しくは、このページの sql_trigger をご覧ください。
  • interval_trigger: データグループをトリガーするタイム スケジュール（"24 hours" など）を指定します。詳しくは、このページの interval_trigger をご覧ください。

多くの場合、max_cache_age を sql_trigger または interval_trigger と組み合わせて使用するのが最善策です。データベースへのデータ読み込み（ETL）と一致する sql_trigger または interval_trigger の値を指定し、ETL が失敗した場合に古いデータを無効にする max_cache_age の値を指定します。max_cache_age パラメータを指定すると、データグループのキャッシュが sql_trigger または interval_trigger によって消去されない場合に、キャッシュ エントリが一定期間ごとに期限切れになります。このようにして、データグループの故障モードで、Lookerキャッシュから失効したデータが供給されるのではなく、データベースをクエリすることができます。

データグループに sql_trigger パラメータと interval_trigger パラメータの両方を含めることはできません。両方のパラメータを指定してデータグループを定義した場合、そのデータグループは interval_trigger 値を使用し、sql_trigger の値は無視します。sql_trigger パラメータの場合、データベースをクエリするときにデータベース リソースを使用する必要があるためです。

ユーザー属性を使用して接続パラメータを指定する接続の場合、SQL クエリトリガーを使用してデータグループ キャッシュ ポリシーを定義する場合は、PDT オーバーライド フィールドを使用して個別の接続を作成する必要があります。

PDT のオーバーライドがなくても、sql_trigger ではなく max_cache_age のみを使用してデータグループのキャッシュ保存ポリシーを定義している限り、モデルとその Explore にデータグループを使用できます。

max_cache_age

max_cache_age パラメータは、整数に続けて「seconds」、「minutes」、「hours」のいずれかが含まれる文字列を指定します。この期間は、データグループを使用する Explore クエリでキャッシュに保存された結果が使用される最大期間です。

Looker では、クエリのキャッシュが max_cache_age を超えると、キャッシュは無効になります。次回このクエリが発行されると、クエリはデータベースに送られ、最新の結果が取得されます。データがキャッシュに保存される期間については、クエリのキャッシングのドキュメント ページをご覧ください。

max_cache_age パラメータは、キャッシュが無効になるタイミングのみを定義します。PDT の再構築はトリガーしません。max_cache_age のみでデータグループを定義すると、派生テーブルがデータグループに割り当てられている場合に LookML 検証の警告が表示されます。max_cache_age パラメータのみを含むデータグループに派生テーブルを割り当てたままにすると、テーブルが最初にクエリされたときに派生テーブルがビルドされますが、派生テーブルはスクラッチ スキーマに無期限に残り、再度クエリされても再ビルドされません。特定の時間間隔で PDT を再構築する場合は、データグループに interval_trigger パラメータを追加して、PDT の再構築スケジュールを定義する必要があります。

sql_trigger

sql_trigger パラメータを使用して、1 つの行と 1 つの列を返す SQL クエリを指定します。Looker は、データベース接続の [データグループと PDT のメンテナンス スケジュール] フィールドで指定された間隔で SQL クエリを実行します。クエリが以前の結果と異なる値を返した場合、データグループはトリガー状態になります。データグループがトリガーされると、Looker は datagroup_trigger パラメータでそのデータグループが指定されている PDT を再構築します。PDT の再構築が完了すると、データグループは準備完了状態になり、Looker はそのデータグループを使用する Explore のキャッシュ結果を無効にします。

通常、sql_trigger は、新しいデータ読み込み（ETL）が発生したタイミングを示す SQL クエリを指定します。たとえば、テーブル内の max(ID) をクエリします。また、sql_trigger を使用して、特定の日時を指定することもできます。たとえば、午前 4 時を指定するには、現在の日時をクエリし、必要に応じてそのタイムスタンプに時間を追加します。

sql_trigger に関する次の重要な点に注意してください。

  • データベース接続で OAuth またはユーザー属性が使用されていて、接続で PDT が無効になっている場合、sql_trigger は使用できません。Looker では、sql_trigger パラメータで指定されたクエリを実行するために、データベースにアクセスするための静的認証情報が必要になるためです。PDT が有効になっている場合、接続で OAuth やユーザー属性などの動的認証情報が使用されている場合でも、PDT オーバーライド フィールドを使用して、PDT プロセス用の個別の静的ログイン認証情報を Looker に提供できます。ただし、PDT が無効になっている場合、接続で OAuth またはユーザー属性が使用されていると、sql_trigger クエリに必要な静的ユーザー認証情報を Looker に提供できません。
  • Looker では、sql_trigger のタイムゾーン変換は行われません。特定の時刻にデータグループをトリガーする場合は、データベースが構成されているタイムゾーンでトリガーを設定します。

データグループをトリガーする SQL クエリの設定については、sql_trigger パラメータのドキュメントの例をご覧ください。

interval_trigger

オプションの interval_trigger サブパラメータを使用すると、再構築の期間を指定できます。interval_trigger パラメータには、整数とそれに続く「seconds」、「minutes」、「hours」を含む文字列を渡します。

label と description

オプションの label サブパラメータと description サブパラメータを使用すると、カスタマイズされたラベルとデータグループの説明を追加できます。これらのサブパラメータは、ロケール文字列ファイルを使用してローカライズすることもできます。

これらのサブパラメータは、[管理者] パネルの [データベース] セクションにある [データグループ] ページに表示されます。これらの表示方法の詳細については、管理者設定 - データグループのドキュメント ページをご覧ください。

例

次の例は、datagroup のユースケースを示しています。

新しいデータが利用可能になったとき、または少なくとも 24 時間ごとに新しい結果を取得するキャッシュ保存ポリシーを作成する

新しいデータが利用可能になったとき、または少なくとも 24 時間ごとに新しい結果を取得するキャッシュ ポリシーを作成するには、次の操作を行います。

  • orders_datagroup データグループ（モデルファイル内）を使用して、キャッシング ポリシーに名前を付けます。
  • sql_trigger パラメータを使用して、新しいデータがあることを示すクエリ select max(id) from my_tablename を指定します。データが更新されるたびに、このクエリは新しい数値を返します。
  • max_cache_age 設定を使用して、データが 24 時間キャッシュに保存されている場合にデータを無効にします。
  • オプションの label パラメータと description パラメータを使用して、カスタマイズされたラベルとデータグループの説明を追加します。
datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

orders_datagroup キャッシュ ポリシーをモデル内の Explore のデフォルトとして使用するには、モデルレベルで persist_with パラメータを使用し、orders_datagroup を指定します。

persist_with: orders_datagroup

特定の Explore に orders_datagroup キャッシュ ポリシーを使用するには、explore パラメータの下に persist_with パラメータを追加して、orders_datagroup を指定します。モデルレベルでデフォルトのデータグループが指定されている場合は、explore の下の persist_with パラメータを使用して、デフォルト設定をオーバーライドできます。

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

PDT の再構築に orders_datagroup データグループのキャッシュ ポリシーを使用するには、derived_table パラメータの下に datagroup_trigger を追加して、orders_datagroup を指定します。

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

毎月最終日に配信をスケジュールするデータグループを作成する

毎月末にコンテンツ配信を送信するスケジュールを作成することもできます。ただし、月によって日数が異なります。データグループを作成して、特定月の日数に関係なく、毎月末にコンテンツ配信をトリガーできます。

  1. SQL ステートメントを使用して、毎月末にトリガーするデータグループを作成します。

    datagroup: month_end_datagroup {
sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
description: "Triggered on the last day of each month"
}

    この例は Redshift SQL で記述されています。データベースによっては、若干の変更が必要になる場合があります。

    この SQL ステートメントは、明日が属する月を返します。月の最終日には、明日は翌月になるため、データグループがトリガーされます。翌日が同じ月になる日は、データグループはトリガーされません。

  2. 新しいスケジュールまたは既存のスケジュールでデータグループを選択します。

データグループに基づくスケジュールは、そのデータグループ パラメータのすべての永続的な PDT の再生成プロセスが完了してから送信されるため、配信に最新のデータが含まれることが保証されます。

カスケード PDT でデータグループを使用する

1 つの永続的な派生テーブル（PDT）が別の定義で参照される永続的なカスケード派生テーブルの場合、データグループを使用して、カスケード PDT のチェーンの永続性戦略を指定できます。

たとえば、user_facts_etl というデータグループと user_stuff という Explore を定義するモデルファイルの一部を次に示します。user_stuff Explore は user_facts_etl データグループで永続化されます。

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

user_stuff Explore は、user_facts_pdt_1 ビューを user_facts_pdt_2 ビューと結合します。これらのビューはどちらも、永続性トリガーとして user_facts_etl データグループを使用する PDT に基づいています。user_facts_pdt_2 派生テーブルは user_facts_pdt_1 派生テーブルを参照しているため、これらはカスケード PDT です。これらの PDT のビューファイルから LookML の一部を次に示します。

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

カスケード PDT がある場合は、PDT に矛盾するデータグループ キャッシング ポリシーがないことを確認する必要があります。

Looker リジェネレータは、ステータスをチェックし、次のようにこれらの PDT の再構築を開始します。

  • デフォルトでは、Looker リジェネレータはデータグループの sql_trigger クエリを 5 分ごとにチェックします（Looker 管理者は、データベース接続の [データグループと PDT のメンテナンス スケジュール] 設定を使用して、この間隔を指定できます）。
  • sql_trigger クエリから返された値が、前回のチェックでのクエリの結果と異なる場合、データグループはトリガー状態になります。この例では、etl_jobs テーブルに新しい ID 値がある場合、user_facts_etl データグループがトリガーされます。

  • user_facts_etl データグループがトリガーされると、Looker リジェネレータは、そのデータグループを使用するすべての PDT（つまり、datagroup_trigger: user_facts_etl で定義されたすべての PDT）を再構築します。この例では、リジェネレータは user_facts_pdt_1 を再構築してから、user_facts_pdt_2 を再構築します。

    PDT が同じ datagroup_trigger を共有している場合、リジェネレーターは依存関係の順序で PDT を再構築します。最初に、他のテーブルから参照されるテーブルをビルドします。Looker がカスケード派生テーブルを再構築する方法については、Looker の派生テーブルのドキュメント ページをご覧ください。

  • リジェネレータがデータグループ内のすべての PDT を再構築すると、リジェネレータは user_facts_etl データグループをトリガー状態から外します。

  • user_facts_etl データグループがトリガー状態ではなくなると、Looker は user_facts_etl データグループを使用するすべてのモデルと Explore（つまり、persist_with: user_facts_etl で定義されているすべてのモデルと Explore）のキャッシュをリセットします。この例では、Looker は user_stuff Explore のキャッシュをリセットします。

  • user_facts_etl データグループに基づくスケジュールされたコンテンツ配信が送信されます。この例では、user_stuff エクスプローラからのクエリを含むスケジュール設定された配信がある場合、スケジュール設定されたクエリはデータベースから取得され、最新の結果が取得されます。

モデルファイル間でデータグループを共有する

この例では、複数のモデルファイルでデータグループを共有する方法を示します。このアプローチの利点は、データグループを編集する必要がある場合に、1 か所だけ編集すれば、その変更がすべてのモデルに反映されることです。

データグループを複数のモデルファイルと共有するには、まずデータグループのみを含む別のファイルを作成し、include パラメータを使用して、モデルファイル内のデータグループ ファイルを include します。

データグループ ファイルの作成

データグループを格納する別の .lkml ファイルを作成します。.lkml データグループ ファイルは、別の .lkml Explore ファイルを作成するのと同じ方法で作成できます。

この例では、データグループ ファイルの名前は datagroups.lkml です。

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

モデルファイルにデータグループ ファイルを含める

データグループ ファイルを作成したので、両方のモデルで include を使用し、persist_with を使用して、モデル内の個々の Explore にデータグループを適用するか、モデル内のすべての Explore にデータグループを適用します。

たとえば、次の 2 つのモデルファイルは両方とも datagroups.lkml ファイルを include します。

このファイルの名前は ecommerce.model.lkml です。daily データグループは explore レベルで使用されているため、orders Explore にのみ適用されます。

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

次のファイルの名前は inventory.model.lkml です。daily データグループは model レベルで使用されるため、モデルファイル内のすべての Explore に適用されます。

include: "datagroups.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}