Looker 26.20 のドキュメントを表示しています。最新のドキュメントについては、こちらのリンクをクリックしてください。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

aggregate_table

用途

explore: explore_name {
  aggregate_table: table_name {

    query:  {
      dimensions: [dimension1, dimension2, ... ]
      measures: [measure1, measure2, ... ]
      sorts: [field1: asc, field2: desc, ... ]
      filters: [field1: "value1", field2: "value2", ... ]
      timezone: timezone
    }

    materialization:  {
      ...
    }
  }

  ...

}

階層

モデルファイル

explore

aggregate_table

デフォルト値

なし

許可

集計テーブルの名前、テーブルを定義する query サブパラメータ、テーブルの永続性戦略を定義する materialization サブパラメータ

特別なルール

table_name は、特定の explore 内で一意である必要があります。
materialization サブパラメータで、サマリー表の永続性戦略を指定する必要があります。

定義

aggregate_table パラメータは、データベース内の大きなテーブルに必要なクエリの数を最小限に抑えるサマリー表を作成するために使用されます。

Looker は、集約認識ロジックを使用して、データベース内で最も小規模の効率的なサマリー表を検出し、正確性を維持しながらクエリを実行します。（集約テーブルの作成の概要と戦略については、集約テーブルの自動認識のドキュメントページをご覧ください）。

データベース内の非常に大きなテーブルに対して、さまざまな属性の組み合わせによってグループ化されたデータのより小さなサマリー表を作成できます。集約テーブルは、元の大きなテーブルの代わりに、Looker が可能であれば常にクエリに使用できるロールアップまたはサマリーテーブルとして機能します。

サマリー表を作成したら、Explore でクエリを実行して、Looker がどのサマリー表を使用するかを確認できます。詳細については、集約テーブルの自動認識のドキュメントページのクエリに使用されるサマリー表を決定するセクションをご覧ください。

集約テーブルが使用されない一般的な理由については、集約テーブルの自動認識のドキュメントページのトラブルシューティングセクションをご覧ください。

LookML でのサマリー表の定義

各 aggregate_table パラメータには、特定の explore 内で一意の名前を付ける必要があります。

aggregate_table パラメータには、query と materialization のサブパラメータがあります。

`query`

query パラメータは、使用するディメンションとメジャーなど、サマリー表のクエリを定義します。query パラメータには、次のサブパラメータが含まれています。

注: このセクションでは、aggregate_table の一部である query パラメータについて説明します。

query は、query パラメータのドキュメントページで説明されているように、explore の一部として使用することもできます。

パラメータ名	説明	例
`dimensions`	サマリー表に含める Explore のディメンションのカンマ区切りリスト。`dimensions` フィールドの形式は次のとおりです。 `dimensions: [dimension1, dimension2, ...]` このリストの各ディメンションは、クエリの Explore のビューファイルで `dimension` として定義する必要があります。Explore クエリで `filter` フィールドとして定義されているフィールドを含める場合は、サマリー表のクエリの `filters` リストに追加します。	`dimensions: [orders.created_month, orders.country]`
`measures`	サマリー表に含める Explore のメジャーのカンマ区切りのリスト。`measures` フィールドの形式は次のとおりです。 `measures: [measure1, measure2, ...]` 集約テーブルの自動認識でサポートされているメジャータイプについては、集約テーブルの自動認識のドキュメントページのメジャータイプの要因セクションをご覧ください。	`measures: [orders.count]`
`filters`	必要に応じて、`query` にフィルタを追加します。フィルタは、サマリー表を生成する SQL の `WHERE` 句に追加されます。 `filters` フィールドの形式は次のとおりです。 `filters: [field1: "value1", field2: "value2", ...]` フィルタによってサマリー表の使用が妨げられる仕組みについては、集約テーブルの自動認識のドキュメントページのフィルタの要因セクションをご覧ください。	`filters: [orders.country: "United States", orders.state: "California"]`
`sorts`	必要に応じて、`query` の並べ替えフィールドと並べ替え方向（昇順または降順）を指定します。 `sorts` フィールドの形式は次のとおりです。 `sorts: [field1: asc\|desc, field2: asc\|desc, ...]`	`[orders.country: asc, orders.state: desc]`
`timezone`	`query` のタイムゾーンを設定します。タイムゾーンが指定されていない場合、サマリー表はタイムゾーン変換を実行せず、代わりにデータベースのタイムゾーンを使用します。集約テーブルがクエリソースとして使用されるようにタイムゾーンを設定する方法については、集約テーブルの自動認識のドキュメントページのタイムゾーンの要因セクションをご覧ください。 IDE で `timezone` パラメータを入力すると、IDE がタイムゾーン値を自動的に提案します。IDE のクイックヘルプパネルにも、サポートされているタイムゾーン値のリストが表示されます。	`timezone: America/Los_Angeles`

`materialization`

materialization パラメータは、サマリー表の永続性戦略と、SQL 言語でサポートされている可能性のある分散、パーティショニング、インデックス、クラスタリングのその他のオプションを指定します。

集約テーブルの自動認識にアクセスするには、集約テーブルがデータベースに保持されている必要があります。サマリー表の materialization パラメータには、永続化戦略を指定する次のサブパラメータのいずれかが必要です。

datagroup_trigger
sql_trigger_value
persist_for（非推奨）

また、SQL 言語によっては、サマリー表で次の materialization サブパラメータがサポートされる場合があります。

cluster_keys
distribution
distribution_style
indexes
partition_keys
publish_as_db_view
sortkeys

増分集計テーブルを作成するには、次の materialization サブパラメータを使用します。

increment_key
increment_offset

`datagroup_trigger`

datagroup_trigger パラメータを使用して、モデルファイルで定義されている既存のデータグループに基づいて、サマリー表の再生成をトリガーします。


explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: order_datagroup
    }
    query: {
      ...
    }
  }
  ...
}

`sql_trigger_value`

sql_trigger_value パラメータを使用して、指定した SQL ステートメントに基づいてサマリー表の再生成をトリガーします。SQL ステートメントの結果が前の値と異なる場合、テーブルが再生成されます。この sql_trigger_value ステートメントは、日付が変更されると再生成をトリガーします。

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      sql_trigger_value: SELECT CURDATE() ;;
    }
    query: {
      ...
    }
  }
  ...
}

`persist_for`

persist_for パラメータは、サマリー表でもサポートされています。ただし、persist_for 戦略では、集約テーブルの自動認識で最適なパフォーマンスが得られない場合があります。これは、ユーザーが persist_for テーブルに依存するクエリを実行すると、Looker が persist_for 設定に対してテーブルの経過時間をチェックするためです。テーブルが persist_for 設定よりも古い場合、クエリが実行される前にテーブルが再生成されます。経過時間が persist_for 設定より短い場合は、既存のテーブルが使用されます。したがって、ユーザーが persist_for 時間内にクエリを実行しない限り、サマリー表を再構築してから、サマリー表を Aggregate Awareness に使用する必要があります。

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      persist_for: "90 minutes"
    }
    query: {
      ...
    }
  }
  ...
}

制限事項を理解し、persist_for の実装に特定のユースケースがある場合を除き、サマリー表の永続化戦略として datagroup_trigger または sql_trigger_value を使用することをおすすめします。

`cluster_keys`

cluster_keys パラメータを使用すると、BigQuery または Snowflake のパーティション分割テーブルにクラスタ化された列を追加できます。クラスタリングでは、クラスタ化列の値に基づいてパーティション内のデータを並べ替え、最適なサイズに設定されたストレージブロック単位でクラスタ化列を編成します。

詳しくは、cluster_keys パラメータのドキュメントページをご覧ください。

`distribution`

distribution パラメータを使用すると、分散キーを適用するサマリー表の列を指定できます。distribution は、Redshift データベースと Aster データベースでのみ機能します。他の SQL 言語（MySQL や Postgres など）の場合は、代わりに indexes を使用します。

詳しくは、distribution パラメータのドキュメントページをご覧ください。

`distribution_style`

distribution_style パラメータを使用すると、サマリー表のクエリを Redshift データベースのノードに分散する方法を指定できます。

distribution_style: all は、すべての行が各ノードに完全にコピーされることを示します。
distribution_style: even は均等な分散を指定します。これにより、行はラウンドロビン方式で異なるノードに分散されます。

詳しくは、distribution_style パラメータのドキュメントページをご覧ください。

`indexes`

indexes パラメータを使用すると、サマリー表の列にインデックスを適用できます。

詳しくは、indexes パラメータのドキュメントページをご覧ください。

`partition_keys`

partition_keys パラメータは、サマリー表をパーティショニングする列の配列を定義します。partition_keys は、列をパーティショニングできるデータベース言語をサポートしています。パーティション分割された列でフィルタされたクエリが実行されると、データベースはテーブル全体をスキャンするのではなく、フィルタされたデータを含むパーティションのみをスキャンします。partition_keys は、Presto と BigQuery のダイアレクトでのみサポートされています。

詳しくは、partition_keys パラメータのドキュメントページをご覧ください。

`publish_as_db_view`

publish_as_db_view パラメータを使用すると、Looker の外部でクエリを実行するためにサマリー表にフラグを設定できます。publish_as_db_view が yes に設定されたサマリー表の場合、Looker はサマリー表のデータベースに安定したデータベースビューを作成します。安定したデータベースビューはデータベース自体に作成されるため、Looker の外部からクエリを実行できます。

詳しくは、publish_as_db_view パラメータのドキュメントページをご覧ください。

`sortkeys`

sortkeys パラメータを使用すると、通常の並べ替えキーを適用するサマリー表の 1 つ以上の列を指定できます。

詳しくは、sortkeys パラメータのドキュメントページをご覧ください。

`increment_key`

言語がサポートしている場合は、プロジェクトで増分 PDT を作成できます。増分 PDT は永続的な派生テーブル（PDT）です。Looker はテーブル全体を再構築するのではなく、テーブルに新しいデータを追加して構築します。詳細については、増分 PDT のドキュメントページをご覧ください。

サマリー表は PDT の一種であり、increment_key パラメータを追加することで段階的に構築できます。increment_key パラメータは、新しいデータをクエリしてサマリー表に追加する時間増分を指定します。

詳しくは、increment_key パラメータのドキュメントページをご覧ください。

`increment_offset`

increment_offset パラメータは、集計テーブルにデータを追加するときに再構築される、以前の期間（インクリメントキーの粒度）の数を定義します。increment_offset パラメータは、増分 PDT と集約テーブルでは省略可能です。

詳しくは、increment_offset パラメータのドキュメントページをご覧ください。

Explore からサマリー表の LookML を取得する

ショートカットとして、Looker デベロッパーは Explore クエリを使用してサマリー表を作成し、LookML を LookML プロジェクトにコピーできます。

Explore で、サマリー表に含めるすべてのフィールドとフィルタを選択します。
[実行] をクリックして結果を取得します。
Explore の歯車メニューから [LookML を取得] を選択します。このオプションは、Looker デベロッパーのみが使用できます。
[サマリー表] タブをクリックします。
Looker は、サマリー表を Explore に追加する Explore のリファインメント用の LookML を提供します。LookML をコピーして、関連するモデルファイルに貼り付けます。このファイルは、Explore の絞り込みの前のコメントに示されています。Explore がモデルファイルではなく別の Explore ファイルで定義されている場合は、モデルファイルではなく Explore のファイルに絞り込みを追加できます。どちらの場所でも構いません。

注: Looker は、Explore のディメンションに基づいてサマリー表に名前を付けます。Looker は、Explore のサマリー表 LookML を提供するたびに、サマリー表に同じ名前を使用します。以前に追加された可能性のある、同じ Explore への他の改良に注意してください。自分または別のデベロッパーが Explore からサマリー表の LookML をすでに取得している場合、Looker はサマリー表に同じ名前を付けます。Explore に複数のリファインメントがあり、それぞれに同じ名前のサマリー表がある場合、LookML のリファインメントドキュメントページのリファインメントは順番に適用されるセクションで説明されているように、1 つのリファインメントが他のリファインメントをオーバーライドします。

サマリー表の LookML を変更する必要がある場合は、このページの LookML でのサマリー表の定義セクションで説明されているパラメータを使用して変更できます。集約テーブルの名前を変更しても、元の Explore クエリへの適用性は変わりません。ただし、サマリー表にその他の変更を加えると、Looker が Explore クエリにサマリー表を使用できなくなる可能性があります。集約テーブルを最適化して集約テーブルの自動認識で使用されるようにするためのヒントについては、集約テーブルの自動認識ドキュメントページの集約テーブルの設計セクションをご覧ください。

ダッシュボードからの集計テーブルLookMLの取得

Looker デベロッパー向けのもう 1 つのオプションは、ダッシュボード上のすべてのタイルのサマリー表 LookML を取得し、LookML を LookML プロジェクトにコピーすることです。

サマリー表を作成すると、ダッシュボードのパフォーマンスを大幅に向上させることができます。特に、大量のデータセットに対してクエリを実行するタイルの場合に効果的です。

develop 権限がある場合は、ダッシュボードを開き、ダッシュボードのその他メニューから [LookML を取得] を選択し、[サマリー表] タブを選択することで、ダッシュボードのサマリー表を作成する LookML を取得できます。

集約アウェアネスで最適化されていないタイルごとに、Looker は Explore にサマリー表を追加する Explore のリファインメントの LookML を提供します。ダッシュボードに同じ Explore の複数のタイルが含まれている場合、Looker はすべてのサマリー表を 1 つの Explore のリファインメントに配置します。生成されるサマリー表の数を減らすため、Looker は生成されたサマリー表を複数のタイルで使用できるかどうかを判断し、使用できる場合は、使用できるタイルが少ない冗長なサマリー表を削除します。

各 Explore のリファインメントをコピーして、関連するモデルファイルに貼り付けます。このファイルは、Explore のリファインメントの前のコメントに示されています。Explore がモデルファイルではなく別の Explore ファイルで定義されている場合は、モデルファイルではなく Explore ファイルに改良を追加できます。どちらの場所でも機能します。

注: Looker は、タイルのクエリのディメンションに基づいて、各サマリー表に名前を付けます。Looker は、タイルクエリのサマリー表 LookML を提供するたびに、サマリー表に同じ名前を使用します。以前に追加された可能性のある、タイルの Explore への他の絞り込みを考慮してください。自分または別のデベロッパーがダッシュボードタイルのクエリからサマリー表の LookML をすでに取得している場合、Looker はサマリー表に同じ名前を付けます。Explore に複数のリファインメントがあり、それぞれに同じ名前のサマリー表がある場合、LookML のリファインメントドキュメントページのリファインメントは順番に適用されるセクションで説明されているように、1 つのリファインメントが他のリファインメントをオーバーライドします。

ダッシュボードフィルタがタイルに適用されている場合、Looker はフィルタのディメンションをタイルのサマリー表に追加して、サマリー表をタイルに使用できるようにします。これは、クエリのフィルタがサマリー表のディメンションとして使用できるフィールドを参照している場合にのみ、サマリー表をクエリに使用できるためです。詳細については、集約テーブルの自動認識のドキュメントページをご覧ください。

サマリー表の LookML を変更する必要がある場合は、このページの LookML でのサマリー表の定義セクションで説明されているパラメータを使用して変更できます。元のダッシュボードタイルへの適用性を変更せずに、集約テーブルの名前を変更できます。ただし、集約テーブルにその他の変更を加えると、Looker がダッシュボードに集約テーブルを使用できなくなる可能性があります。集約テーブルを最適化して集約テーブルの自動認識で使用されるようにするためのヒントについては、集約テーブルの自動認識ドキュメントページの集約テーブルの設計セクションをご覧ください。

例

次の例では、event Explore の monthly_orders サマリー表を作成します。サマリー表は、月ごとの注文数を作成します。Looker は、年次、四半期、月次の注文数など、月単位の粒度を利用できる注文数クエリにサマリー表を使用します。

集約テーブルは、datagroup orders_datagroup を使用して永続性が設定されています。また、集約テーブルは publish_as_db_view: yes で定義されています。つまり、Looker は集約テーブルのデータベースに安定したデータベースビューを作成します。

サマリー表の定義は次のようになります。

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: orders_datagroup
      publish_as_db_view: yes
    }
    query: {
      dimensions: [orders.created_month]
      measures: [orders.count]
      filters: [orders.created_date: "1 year", orders.status: "fulfilled"]
      timezone: America/Los_Angeles
    }
  }
}

注意点

集約テーブルを戦略的に作成するためのヒントについては、集約テーブルの自動認識のドキュメントページの集約テーブルの設計セクションをご覧ください。

集計テーブルの自動認識向けの言語サポート

集約テーブルを使用できるかどうかは、Looker 接続で使用されているデータベース言語によって異なります。Looker の最新リリースでは、次の言語が集約テーブルの自動認識をサポートしています。

方言	サポート対象
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

aggregate_table コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

用途

定義

LookML でのサマリー表の定義

query

materialization

datagroup_trigger

sql_trigger_value

persist_for

cluster_keys

distribution

distribution_style

indexes

partition_keys

publish_as_db_view

sortkeys

increment_key

increment_offset