You are viewing documentation for Looker 25.20. Click this link to see the most recent documentation.

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 時間内にクエリを実行しない限り、集計認識に使用する前に集計テーブルを再構築する必要があります。

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 は、テーブル全体を再構築するのではなく、Looker が新しいデータをテーブルに追加して構築する永続的な派生テーブル（PDT）です。詳しくは、増分 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 デベロッパーのみが使用できます。
[Aggregate Table] タブをクリックします。
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 デベロッパー向けの別のオプションとして、ダッシュボードのすべてのタイルの集計テーブル 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+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
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+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
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
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