Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

集計認識

集約テーブルの自動認識の実装については、ヘルプセンターの集約テーブルの自動認識に関するチュートリアルをご覧ください。

概要

Looker は集約テーブルの自動認識ロジックを使用して、正確さを維持しながらクエリを実行し、データベースで利用可能な最も小さくて効率的なテーブルを見つけます。

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

たとえば、ウェブサイトで発生したすべての注文に 1 行を含むペタバイト規模のデータテーブルがあるとします。このデータベースから、1 日の合計売り上げを含む集計テーブルを作成できます。ウェブサイトで毎日 1,000 件の注文が 1 回受けられる場合、毎日の集計テーブルは、各テーブルが 1 日あたり 999 行少ない表になります。月ごとの総売上高を示す別の集計テーブルを作成すると、さらに効率的になります。このため、ユーザーが日別または週単位の売上のクエリを実行すると、Looker は日次販売の合計テーブルを使用します。ユーザーが年間売上高に関するクエリを実行していて、年間売上高テーブルがない場合は、次善の策であるこの例の月次売上高集約テーブルが使用されます。

以下の画像は、Looker がユーザーに対してどのように回答するかを示しています。可能な限り集約テーブルについて問い合わせています。

総売上高に関するクエリでは、Looker は月次売上（sales_monthly_aggregate_table）に基づく集約テーブルを使用します。
各日の合計販売数に関するクエリの場合、その粒度での集約テーブルは存在しないため、Looker では元のデータベーステーブル（orders_database）からクエリ結果を取得します（ただし、ユーザーがこの種のクエリを頻繁に実行する場合には、集約テーブルを簡単に作成できます）。
週次売上に関するクエリには、週次の集計テーブルがないため、Looker は次の最適情報（日次販売に基づく集約テーブル（sales_daily_aggregate_table））を使用します。

Looker は集約テーブルの自動認識ロジックを使用して、ユーザーの質問に答えることのできる可能な限り最小の集約テーブルをクエリします。元のテーブルは、集計テーブルよりも細かく設定する必要があるクエリにのみ使用されます。

集約テーブルは、別の Explore に結合、追加する必要はありません。その代わり、Looker では Explore クエリの FROM 句を動的に調整し、クエリに最適な集約テーブルにアクセスします。つまり、ドリルダウンが維持され、Explore が統合されます。集約テーブルの自動認識により、1 つの Explore では集約テーブルが自動的に活用されますが、必要に応じて詳細なデータが掘り下げられます。

また、集計テーブルを利用して、特に巨大なデータセットにクエリを実行するタイルの場合は、ダッシュボードのパフォーマンスを大幅に向上させることができます。詳細については、aggregate_table パラメータのドキュメントページのダッシュボードから集計テーブルの LookML を取得するをご覧ください。

集計テーブルをプロジェクトに追加する

集約テーブルの自動認識にアクセスするには、データベースに集約テーブルを永続化する必要があります。集約テーブルは永続的な派生テーブル（PDT）の一種であるため、集約テーブルの要件は PDT と同じです。詳細については、Looker での派生テーブルのドキュメントをご覧ください。

Looker デベロッパーは、戦略的な集約テーブルを作成して、データベース内の大きなテーブルに必要なクエリの数を最小限に抑えることができます。集約テーブルは、集約認識のためにアクセスできるように、データベースに保持される必要があります。集約テーブルは、永続的な派生テーブル（PDT）の一種です。

集約テーブルは、LookML プロジェクトの explore パラメータの下にある aggregate_table パラメータを使用して定義されます。

LookML の集約テーブルを持つ explore の例を次に示します。

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

集約テーブルを作成するには、LookML を最初から作成するか、Explore またはダッシュボードから集約テーブル LookML を取得します。aggregate_table パラメータとそのサブパラメータの詳細については、aggregate_table パラメータのドキュメントページをご覧ください。

集約テーブルの設計

Explore クエリで集約テーブルを使用するには、集約テーブルが、Explore クエリの正確なデータを提供できる必要があります。以下の条件をすべて満たしている場合、Looker は Explore クエリ用の集約テーブルを使用できます。

Explore クエリのフィールドは、集計テーブルのフィールドのサブセットです（このページのフィールドファクタセクションをご覧ください）。または、期間については、Explore のクエリの期間を集計テーブルの期間から導き出すことができます（このページの期間を参照）。
Explore クエリには、集約テーブルの自動認識でサポートされているメジャータイプが含まれているか（このページのメジャータイプの要因を参照）、Explore クエリには完全に一致する完全一致テーブルがあります（このページの Explore クエリと完全に一致する集約テーブルを作成するをご覧ください）。
Explore クエリのタイムゾーンは、集約テーブルで使用されているタイムゾーンと一致します（このページのタイムゾーンの要素を参照）。
Explore クエリのフィルタは、集計テーブルのディメンションとして使用可能なフィールドを参照するか、Explore クエリの各フィルタが集計テーブルのフィルタに一致します（このページのフィルタ係数を参照）。

集約テーブルが Explore クエリの正確なデータを提供できるようにするための 1 つの方法は、Explore クエリと完全に一致する集約テーブルを作成することです。詳細については、このページの探索クエリに完全に一致する集計テーブルの作成をご覧ください。

フィールド要素

集約テーブルに Explore クエリを使用するには、その Explore クエリに必要なすべてのディメンションとメジャーが含まれている必要があります。これには、Explore クエリのフィルタに使用するフィールドも含まれます。集約テーブルに含まれていないディメンションまたはメジャーが Explore クエリに含まれる場合、Looker では集約テーブルを使用できません。代わりに、ベーステーブルを使用します。

たとえば、クエリがディメンション A と B でグループ化され、メジャー C で集計され、ディメンション D でフィルタされている場合、集計テーブルには、最低限、A、B、D をディメンション、C をメジャーとして含める必要があります。

集約テーブルには他のフィールドも使用できますが、最適化を行うには、少なくとも Explore クエリフィールドが必要です。ただし、細かい粒度の時間枠は、より細かい粒度から導出できるため、例外のタイムフレームがあります。

こうしたフィールドの考慮事項があるため、集約テーブルは、その Explore が定義されている Explore に固有です。ある Explore で定義されたサマリーは、別の Explore のクエリには使用できません。

期間要素

Looker の集約テーブルの自動認識ロジックは、ある時間枠から別の時間帯を導出できます。集計テーブルの時間枠は、Explore クエリよりも細かい（または等しい）期間の粒度があれば、クエリに使用できます。たとえば、日次データに基づく集約テーブルは、他の期間を必要とする Explore クエリに使用できます。たとえば、日、月、年のデータ、さらには日、年、週のデータに対するクエリを使用できます。ただし、集計テーブルのデータは Explore クエリに十分な粒度がないため、1 時間ごとのデータを呼び出す Explore クエリで年次集計テーブルを使用することはできません。

期間のサブセットでも同じことが言えます。たとえば、過去 3 か月間にフィルタされた集約テーブルがあり、ユーザーが過去 2 か月間のフィルタを使用してデータをクエリした場合、Looker はそのクエリに集約テーブルを使用できます。

また、期間フィルタを使用するクエリに対しても同じロジックが適用されます。集計テーブルは、集計テーブルの時間枠が Explore クエリで使用される期間フィルタと同じ粒度（または等しい）である限り、期間フィルタを使用するクエリで使用できます。たとえば、日別の期間ディメンションを含む集計テーブルは、日、週、または月でフィルタする Explore クエリに使用できます。

タイプ係数を測定する

Explore クエリで集約テーブルを使用するには、集約テーブルのメジャーが Explore クエリの正確なデータを提供できる必要があります。

このため、次のセクションで説明するように、特定のタイプのメジャーのみがサポートされています。

サポートされているメジャータイプのメジャー
SQL 式で定義されたメジャー
${TABLE} で定義されていないメジャー
重複カウントを近似するメジャー

Explore クエリで他のタイプのメジャーが使用されている場合、Looker は集約テーブルではなく、元のテーブルを使用して結果を返します。唯一の例外は、Explore クエリと完全に一致する集約テーブルの作成で説明しているように、Explore クエリが集計テーブルクエリと完全に一致している場合です。

それ以外の場合は、Looker は集約テーブルではなく、元のテーブルを使用して結果を返します。

サポートされているメジャータイプのメジャー

集約テーブルの自動認識は、次のメジャータイプのメジャーを使用する Explore クエリに使用できます。

Explore が複数のデータベーステーブルを結合すると、Looker では SUM、COUNT、AVERAGE タイプのメジャーをそれぞれ SUM DISTINCT、COUNT DISTINCT、AVERAGE DISTINCT としてレンダリングできます。Looker は、このページの結合を使用した Explore の対称集計セクションで説明されているように、ファンアウトの計算ミスを避けるためにこの処理を行います。

Explore クエリに集約テーブルを使用するには、Looker が集約テーブルのメジャーを使用して Explore クエリで正確なデータを提供できる必要があります。たとえば、type: sum のメジャーは複数の合計を合計できるため、集約テーブルの自動認識に使用できます。1 週間の合計のテーブルを加算して、1 か月の正確な合計を取得できます。同様に、type: max のメジャーを使用すると、1 日の上限の集計テーブルを使用して 1 週間の最大値を正確に確認できます。

type: average を使用したメジャーの場合、Looker は合計とカウントのデータを使用して、集約テーブルから平均値を正確に導き出すため、集約テーブルの自動認識がサポートされます。

SQL 式で定義されたメジャー

集約テーブルの自動認識は、sql パラメータの式で定義されたメジャーで使用することもできます。SQL 式で定義する場合は、次のメジャータイプもサポートされます。

集約テーブルの自動認識は、次の例のように、他のメジャーとの組み合わせとして定義されるメジャーでサポートされています。

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

集約テーブルの自動認識は、sql パラメータで計算が定義されているメジャーでもサポートされています。たとえば、次のようなメジャーです。

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

また、集約テーブルの自動認識は、MIN、MAX、COUNT オペレーションが sql パラメータで定義されているメジャーでサポートされています。たとえば、次のようなメジャーです。

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

集約テーブルの自動認識は、MIN()、MAX()、COUNT() のオペレーションでのみサポートされています。集約テーブルで平均または合計メジャーを使用する場合は、type: average または type: sum のメジャーを作成します。どちらも集計認識がサポートされています。

LookML フィールドを参照するメジャー

メジャーで sql 式を使用する場合、集計認識では、次の種類のフィールド参照がサポートされます。

${view_name.field_name} 形式を使用した参照。これは他のビューのフィールドを示します。
${field_name} 形式を使用する参照。これは同じビュー内のフィールドを示します。

集約テーブルの自動認識は、テーブル内の列を示す ${TABLE}.column_name 形式で定義されているメジャーではサポートされていません。（LookML での参照の使用の概要については、SQL を組み込んで LookML オブジェクトを参照するをご覧ください）。

たとえば、この sql パラメータで定義されたメジャーは、${TABLE}.column_name フォーマットを使用しているため、集計テーブルではサポートされていません。

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

このメジャーを集計テーブルに含める場合は、${TABLE}.column_name 形式で定義したディメンションを作成してから、そのディメンションを参照するメジャーを作成します。次に例を示します。


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

これで、集約テーブルで wholesale_value メジャーを使用できるようになりました。

大まかな個数を表すメジャー

一般に、集約テーブルの自動認識では、個別カウントがサポートされていません。個別のカウントを集計しようとしても、正確なデータを取得できないためです。たとえば、あるウェブサイトのユニークユーザーをカウントした場合、3 週間おきに 2 回ウェブサイトにアクセスしたユーザーが存在することがあります。週別の集計テーブルを適用して、ウェブサイトでのユニークユーザー数を月ごとに取得しようとしたユーザーは、月ごとのユニーククエリ数で 2 回カウントされ、データが正しくありません。

回避策は、Explore のクエリと完全に一致する集約テーブルを作成することです。詳しくは、このページの Explore クエリと完全に一致する集約テーブルの作成をご覧ください。Explore クエリと集約テーブルクエリが同じ場合、異なるカウント方法によって正確なデータが測定されるため、集約テーブルの自動認識に使用できます。

別の方法として、近似値を使用して異なるカウントすることもできます。HyperLogLog スケッチをサポートする言語の場合、Looker では HyperLogLog アルゴリズムを利用して、集計テーブルの個別のカウントを近似できます。

HyperLogLog アルゴリズムには約 2% の誤差があることがわかっています。allow_approximate_optimization: yes パラメータは、メジャーがメジャーテーブルから計算されるように、メジャーに近似データを使用しても問題ないことを Looker 開発者が認識する必要があります。

詳細については、allow_approximate_optimization パラメータのドキュメントページと、HyperLogLog を使用した個別件数の指定をサポートする言語の一覧をご覧ください。

タイムゾーン係数

多くの場合、データベース管理者は UTC をデータベースのタイムゾーンとして使用します。ただし、多くのユーザーが UTC タイムゾーンにいるとは限りません。Looker には、ユーザーが独自のタイムゾーンでクエリ結果を取得できるように、タイムゾーンを変換するための複数のオプションがあります。

クエリのタイムゾーン: データベース接続に対するすべてのクエリに適用される設定。すべてのユーザーが同じタイムゾーンにいる場合は、単一のクエリタイムゾーンを設定して、すべてのクエリがデータベースのタイムゾーンからクエリのタイムゾーンに変換されるようにできます。
ユーザー固有のタイムゾーン: ユーザーを割り当てることができ、タイムゾーンを個別に選択できます。この場合、クエリはデータベースのタイムゾーンから個々のユーザーのタイムゾーンに変換されます。

これらのオプションの詳細については、タイムゾーン設定の使用に関するドキュメントページをご覧ください。

これらのコンセプトは、集約テーブルの自動認識を理解するうえで重要です。なぜなら、集計テーブルを日付ディメンションや日付フィルタでクエリに使用するには、集約テーブルのタイムゾーンと元のクエリのタイムゾーンの設定が一致しなければならないからです。

timezone 値が指定されていない場合、集計テーブルではデータベースのタイムゾーンが使用されます。次のいずれかに該当する場合、データベース接続はデータベースのタイムゾーンも使用します。

データベースはタイムゾーンをサポートしていません。
データベース接続のクエリタイムゾーンが、データベースタイムゾーンと同じタイムゾーンに設定されている。
データベース接続に指定されたクエリタイムゾーンもユーザー固有のタイムゾーンもありません。この場合、データベース接続ではデータベースのタイムゾーンが使用されます。

いずれかが true の場合、集約テーブルの timezone パラメータは省略できます。

それ以外の場合は、集計テーブルが使用される可能性が高くなるように、集計テーブルのタイムゾーンをクエリに一致するように定義する必要があります。

データベース接続で単一のクエリタイムゾーンを使用している場合は、集計テーブルの timezone 値をクエリタイムゾーンの値と一致させる必要があります。
データベース接続でユーザー固有のタイムゾーンを使用している場合は、同一の集約テーブルを、それぞれ異なる timezone 値で作成し、ユーザーの使用可能なタイムゾーンと一致させる必要があります。

Looker では、集約テーブルのタイムゾーンが Explore クエリのタイムゾーンと一致しない場合、Explore クエリに集約テーブルを使用できません。データベース接続にユーザー固有のタイムゾーンがある場合、ユーザーのタイムゾーンごとに個別の集約テーブルが必要になります。

フィルタ係数

集計表にフィルタを追加する際は注意が必要です。集計テーブルのフィルタを使用すると、集計テーブルを使用できない時点まで結果を絞り込むことができます。たとえば、毎日の注文数を示す集計テーブルを作成し、オーストラリアからのサングラスの注文のみを集計テーブルとしてフィルタするとします。ユーザーが世界中のサングラスの 1 日の注文数について Explore クエリを実行した場合、Looker では集計テーブルにオーストラリアのデータしか存在しないため、その Explore クエリには集約テーブルを使用できません。集約テーブルは、対象範囲が狭すぎて Explore クエリで使用できない。

また、Looker デベロッパーが Explore に組み込んでいる可能性のある次のようなフィルタにも注意してください。

access_filters: ユーザー固有のデータ制限を適用します。
always_filter: ユーザーに Explore クエリの特定のフィルタセットの使用を要求します。ユーザーはクエリのデフォルトのフィルタ値を変更できますが、フィルタを完全に削除することはできません。
conditionally_filter: デフォルトフィルタのセットを定義します。ユーザーは、Explore で定義している 2 つ目のリストから少なくとも 1 つのフィルタを適用した場合に、オーバーライドできます。

これらのフィルタタイプは、特定のフィールドに基づいています。Explore にこれらのフィルタがある場合は、aggregate_table の dimensions パラメータにそれらのフィールドを含める必要があります。

たとえば、orders.region フィールドに基づくアクセスフィルタを持つ Explore は次のようになります。

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

この Explore に使用する集約テーブルを作成するには、集約テーブルに、アクセスフィルタの基となるフィールドを含める必要があります。次の例では、アクセスフィルタは orders.region フィールドに基づいており、同じフィールドが集計テーブルのディメンションとして含まれています。

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

集約テーブルクエリには orders.region ディメンションが含まれているため、Looker は集計テーブルのデータを動的にフィルタして Explore クエリのフィルタに一致させます。そのため、Looker では Explore のアクセスフィルタがあっても、Explore のクエリ用に集約テーブルを使用できます。

これは、bind_filters で構成されたネイティブ派生テーブルを使用する Explore クエリにも適用されます。bind_filters パラメータは、Explore クエリから指定されたフィルタを、ネイティブ派生テーブルのサブクエリに渡します。集約テーブルの自動認識の場合、Explore クエリに bind_filters を使用するネイティブ派生テーブルが必要な場合、Explore クエリでは、ネイティブ派生テーブルの bind_filters パラメータで使用されるすべてのフィールドが、集約テーブルのものとまったく同じフィルタ値を持つ Explore クエリ内でのみ、集約テーブルを使用できます。

Explore クエリと完全に一致する集約テーブルを作成する

集約テーブルを Explore クエリに使用できることを確認する方法の 1 つは、Explore クエリと完全に一致する集約テーブルを作成することです。Explore クエリと集約テーブルの両方が同じメジャー、ディメンション、フィルタ、タイムゾーンなどのパラメータを使用している場合、定義上、集約テーブルの結果は Explore クエリに適用されます。集約テーブルが Explore クエリと完全に一致している場合、Looker はあらゆる種類の測定を含む集約テーブルを使用できる。

Exploreの歯車メニューから Get LookML オプションを使用して、Explore から集約テーブルを作成できます。また、ダッシュボードの歯車メニューから [Get LookML] オプションを使用して、ダッシュボード内のすべてのタイルを完全一致にすることもできます。

クエリに使用する集約テーブルの決定

see_sql 権限を持つユーザーは、Explore の [SQL] タブのコメントを使用して、クエリに使用される集約テーブルを確認できます。[SQL] タブのコメントは、開発モードでも表示されるため、新しいテーブルを本番環境に push する前に、Looker がどのように新しい集計テーブルを使用しているかをテストできます。

たとえば、先ほど説明した毎月の集約テーブルの例に基づいて Explore に移動し、年間合計売上高に関するクエリを実行できます。次に、[SQL] タブをクリックして、Looker が作成したクエリの詳細を表示します。開発モードを使用している場合、Looker はクエリに使用した集約テーブルを示すコメントを表示します。

[SQL] タブのコメントから、Looker がこのクエリに sales_monthly 集約テーブルを使用していることと、他の集約テーブルがこのクエリに使用されていない理由がわかります。

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

[SQL] タブに表示される可能性のあるコメントと、それを解決するための提案については、このページのトラブルシューティングをご覧ください。

集約テーブルの自動認識のための計算削減量の見積もり

データベース接続が費用の見積もりをサポートし、クエリに集約テーブルを使用できる場合は、[探索] ウィンドウに、データベースに対して直接クエリを実行する代わりに、集約テーブルを使用することで節約できるコンピューティングが表示されます。集約テーブルの自動認識による削減額は、クエリが実行される前に Explore の [Run] ボタンの左に表示されます。

クエリを実行する前に、クエリに使用する集計テーブルを確認するには、[SQL] タブをクリックします。このドキュメントのクエリに使用する集約テーブルの特定をご覧ください。

クエリが実行されると、[探索] ウィンドウに、クエリに対して使用された集計テーブルが表示されます。

費用の見積もりが有効になっているデータベース接続では、集約テーブルの自動認識による削減額が表示されます。詳細については、Looker でのデータ探索に関するドキュメントページをご覧ください。

Looker が新しいデータを集約テーブルに統合

時間フィルタを含む集約テーブルの場合、Looker は最新データを集約テーブルに結合できます。過去 3 日間のデータを含むサマリー表があるかもしれませんが、その集約テーブルは昨日構築されているかもしれません。集約テーブルは今日の情報が不足しているため、最新の毎日の情報の Explore クエリに使用することは想定されていません。

ただし、Looker は最新のデータに対してクエリを実行し、その結果を集約テーブルの結果に結合するため、その集計テーブルのデータを引き続きクエリに使用できます。

Looker では、次のような状況で最新データを集約テーブルのデータと結合できます。

集計表には時間フィルタがあります。
集計表には、時間フィルタと同じ時間フィールドに基づくディメンションが含まれています。

たとえば、次の集計テーブルには、orders.created_date フィールドに基づくディメンションと、同じフィールドに基づく時間フィルタ（"3 days"）があります。

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

この集約テーブルが昨日作成された場合、Looker は、まだ集約テーブルに含まれていない最新のデータを取得し、新しい結果を集約テーブルの結果と結合します。ユーザーは集約テーブルの自動認識を利用してパフォーマンスを最適化しながら、最新のデータを取得できます。

開発モードを使用している場合は、Explore の [SQL] タブをクリックして、Looker がクエリに使用した集約テーブルと、集約テーブルに含まれていない新しいデータを Looker が取り込むために使用する UNION ステートメントを確認できます。

現在、Looker が新しいテーブルに集約テーブルを結合できない場合、Looker は集約テーブルの既存のデータを使用します。

集約テーブルは永続化する必要がある

集約テーブルの自動認識にアクセスするには、集約テーブルがデータベースに保持されている必要があります。永続化戦略は、集計テーブルの materialization パラメータで指定されます。集約テーブルは永続的な派生テーブル（PDT）の一種であるため、集約テーブルの要件は PDT と同じです。詳細については、Looker での派生テーブルのドキュメントをご覧ください。

プロジェクトで増分 PDT を言語がサポートする場合、増分 PDT を作成できます。Looker は、テーブル全体を再ビルドするのではなく、最新のデータをテーブルに追加することで増分 PDT を作成します。集約テーブル自体も PDT の一種であるため、増分集約テーブルも作成できます。インクリメンタル PDT の詳細については、インクリメンタル PDT のドキュメントをご覧ください。増分集計テーブルの例については、increment_key パラメータのドキュメントページをご覧ください。

develop 権限を持つユーザーは、永続性の設定をオーバーライドしてクエリのすべての集計テーブルを再構築することで、最新のデータを取得できます。クエリのテーブルを再構築するには、Explore のメニューから [Rebuild Derived Tables & Run] オプションを使用します。

このオプションを使用するには、Exploreクエリの読み込みを待つ必要があります。

[派生テーブルの再作成と実行] オプションは、クエリで参照しているすべての派生テーブルと、クエリ内のテーブルに依存する派生テーブルを再ビルドします。これには、永続的な派生テーブルの一種である集約テーブルも含まれます。

[派生テーブルを再ビルド] オプションを選択すると、クエリはテーブルが再ビルドされるのを待ってから結果を読み込みます。その他のユーザーは、引き続き既存のテーブルを使用します。永続的なテーブルが再構築された後、すべてのユーザーは再構築されたテーブルを使用します。

[派生テーブルの再構築と実行] オプションについて詳しくは、Looker での派生テーブルに関するドキュメントページをご覧ください。

トラブルシューティング

クエリに使用する集約テーブルの特定のセクションで説明したように、開発モードを使用している場合は、Explore でクエリを実行し、[SQL] タブをクリックすると、クエリに使用される集約テーブルに関するコメントを表示できます。

[SQL] タブには、クエリに集計テーブルが使用されなかった理由に関するコメントも表示されます（該当する場合）。使用されていない集約テーブルの場合、コメントの先頭は次のようになります。

Did not use [explore name]::[aggregate table name];

たとえば、order_items Explore で定義された sales_daily 集約テーブルがクエリに使用されなかった理由に関するコメントは次のとおりです。

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

この場合、クエリのフィルタによって集約テーブルを使用できなくなりました。

次の表に、集計テーブルを使用できない理由と、集計テーブルのユーザビリティを高める手順を示します。

集計表を使用していない理由	説明と可能なステップ
Explore にそのようなフィールドはありません。	LookML 検証タイプのエラーがあります。おそらく、集計表が正しく定義されていないか、LookML で集約表に入力ミスがあった可能性があります。フィールド名が間違っていたことが原因の可能性があります。この問題を解決するには、集約テーブルのディメンションとメジャーが Explore のフィールド名と一致していることを確認してください。集約テーブルを定義する方法については、`aggregate_table` パラメータのドキュメントページをご覧ください。
集約テーブルでは、クエリに次のフィールドは含まれません。	集約テーブルに Explore クエリを使用するには、その Explore クエリに必要なすべてのディメンションとメジャーが含まれている必要があります。これには、Explore クエリのフィルタに使用するフィールドも含まれます。集約テーブルに含まれていないディメンションまたはメジャーが Explore クエリに含まれる場合、Looker では集約テーブルを使用できません。代わりに、ベーステーブルを使用します。詳しくは、このページのフィールド要素をご覧ください。ただし、細かい粒度の時間枠は、より細かい粒度から導出できるため、例外のタイムフレームがあります。この問題を解決するには、Explore クエリのフィールドが集約テーブルの定義に含まれていることを確認します。
このクエリには以下のフィールドが含まれ、これらはフィールドとして含まれず、集計テーブルのフィルタと完全には一致しません。	Explore クエリのフィルタは、Looker では集約テーブルを使用できません。この問題を解決するには、次のいずれかを行います。同じフィルタを集計表に追加します。フィルタで使用するフィールドを集計テーブルに追加します。 Explore クエリからフィルタを削除します。詳しくは、このページのフィルタ係数のセクションをご覧ください。
クエリには、ロールアップできない次のメジャーが含まれています。	クエリに、個別の数量、中央値、パーセンタイルなど、集計認識に対応していないメジャータイプが 1 つ以上含まれています。この問題を解決するには、クエリ内の各メジャーのタイプを確認し、サポートされているメジャータイプのいずれかであることを確認します。Explore に結合がある場合は、ファンアウトした結合によってメジャーが個別メジャー（対称集計）に変換されていないことを確認します。説明については、このページの結合を使用した Explore の対称集計をご覧ください。
最適化には、別の集計テーブルの方が適していました。	このクエリには実行可能な集約テーブルが複数あり、Looker がより最適な集約テーブルを代わりに使用していることがわかりました。この場合、何もする必要はありません。
Looker でグループ化が（`primary_key` パラメータまたは `cancel_grouping_fields` パラメータにより）行われなかったため、クエリはロールアップできません。	クエリでは `GROUP BY` 句のないディメンションが参照されているため、Looker は集約テーブルをクエリに使用できません。この問題を解決するには、ビューの `primary_key` パラメータと Explore の `cancel_grouping_fields` パラメータが正しく設定されていることを確認します。
集計テーブルに、クエリに含まれていないフィルタが含まれています。	集計表に、クエリに非時間フィルタが含まれています。この問題を解決するには、集計表からフィルタを削除します。詳細については、このページのフィルタ係数をご覧ください。
フィールドは、Explore クエリではフィルタ専用のフィールドとして定義されますが、集計テーブルの `dimensions` パラメータに含まれます。	集約テーブルの `dimensions` パラメータには、Explore クエリの `filter` フィールドとしてのみ定義されるフィールドが一覧表示されます。この問題を解決するには、集約テーブルの `dimensions` リストからフィールドを削除します。集計表でこのフィールドが必要な場合は、集計テーブルのクエリの `filters` リストに追加します。
オプティマイザーでは、集計テーブルが使用されていない理由を特定できません。	このコメントは特殊なケースのために予約されています。よく使用される Explore クエリでこのクエリが表示される場合は、Explore クエリと完全に一致する集約テーブルを作成できます。`aggregate_table` パラメータページで説明されているように、Explore から集約テーブル LookML を簡単に取得できます。

留意事項

結合を使用した Explore の対称集計

重要なデータベーステーブルを結合する Explore では、Looker は SUM、COUNT、AVERAGE 型のメジャーをそれぞれ SUM DISTINCT、COUNT DISTINCT、AVERAGE DISTINCT としてレンダリングできることに注目してください。Looker は、ファンアウトの誤計算を避けるためにこの処理を行います。たとえば、count メジャーは count_distinct メジャータイプとしてレンダリングされます。これは結合のファンアウトの計算ミスを防ぐためのものであり、Looker の対称集計機能の一部です。Looker のこの機能の説明については、対称集計に関するヘルプセンター記事をご覧ください。

対称集計機能は、誤計算を防ぐだけでなく、場合によっては集計テーブルが使われるのを防ぐことができるため、理解しておくことが重要です。

集約テーブルの自動認識でサポートされているメジャータイプの場合、これはsum、count、averageに適用されます。Looker は、次のような場合に、これらのメジャーを DISTINCT としてレンダリングします。

メジャーは、多対 1 または 1 対多の結合のビューに基づいています。
メジャーは、多対多の結合のどちらかのビューから取得されます。

このタイプの結合の説明については、relationship パラメータのドキュメントページをご覧ください。

この理由で集約テーブルが使用されていない場合は、Explore クエリと完全に一致する集約テーブルを作成して、結合を使用した Explore でこれらのメジャータイプを使用できます。詳細については、このページの探索クエリに完全に一致する集約テーブルの作成セクションをご覧ください。

また、HyperLogLog スケッチをサポートする SQL 言語がある場合は、allow_approximate_optimization: yes パラメータをメジャーに追加できます。allow_approximate_optimization: yes でカウントメジャーが定義されている場合、Looker はメジャーとして認識できる場合でも、メジャーを使用して集計できます。

詳細については、allow_approximate_optimization パラメータのドキュメントページと、HyperLogLog スケッチをサポートする SQL 言語の一覧をご覧ください。

言語認識のサポート（集約テーブルの自動認識）

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

Google BigQuery のレガシー SQL は集約テーブルの自動認識をサポートしていますが、最新のデータと集約テーブルのデータを結合する機能には対応していません。

増分集約テーブルを段階的に構築するための言語サポート

Looker プロジェクトで Looker の増分集約テーブルをサポートするには、データベース言語もサポートする必要があります。Looker の最新リリースでは、集約テーブルと PDT の増分ビルドの両方をサポートする言語を次の表に示します。