データグループ

用途

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 パラメータの場合、Looker がデータベースをクエリするときにデータベース リソースを使用する必要があるためです。

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

PDT のオーバーライドを行わなくても、モデルとその Explore に対してデータグループを使用することはできますが、データグループのキャッシング ポリシーを定義するにあたり、max_cache_age のみを使用し sql_trigger は使わないことが条件となります。

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 を再構築します。datagroup_triggerPDT の再構築が完了すると、データグループは準備完了状態になり、Looker はそのデータグループを使用する Explore のキャッシュされた結果を無効にします。

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

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

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

データグループをトリガーする 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"
}

モデル内の Explore のデフォルトとして orders_datagroup キャッシング ポリシーを使用するには、モデルレベルで 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 データグループ キャッシング ポリシーを使用するには、datagroup_trigger パラメータの下に derived_table を追加し、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 リジェネレータは 5 分ごとにデータグループの sql_trigger クエリをチェックします（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 Explore のクエリを含むスケジュールされた配信がある場合、スケジュールされたクエリはデータベースから取得され、最新の結果が取得されます。

モデルファイル間でのデータグループの共有

この例では、複数のモデルファイルでデータグループを共有する方法を示します。この方法の利点は、データグループを編集する必要がある場合に、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 {
}