匯總認知

總覽

Looker 會使用匯總感知邏輯，在資料庫中找出最小且最有效率的資料表來執行查詢，同時維持準確度。

如果資料庫中的資料表非常龐大，Looker 開發人員可以建立較小的資料匯總表，並依各種屬性組合分組。匯總資料表可做為匯總或摘要資料表，Looker 盡可能都會使用這類資料表進行查詢，而非原始的大型資料表。策略性地實作匯總感知功能後，平均查詢速度可大幅提升。

舉例來說，您可能有一個 PB 級的資料表，其中包含網站上每筆訂單的資料列。您可以從這個資料庫建立匯總資料表，其中包含每日銷售總額。如果您的網站每天收到 1,000 筆訂單，則每日匯總資料表中的每一天，都會比原始資料表少 999 列。您可以建立另一個匯總資料表，其中包含每月銷售總額，這樣效率會更高。因此，如果使用者查詢每日或每週銷售額，Looker 會使用每日銷售總額資料表。如果使用者查詢年銷售額，但您沒有年匯總資料表，Looker 會使用次佳的資料表，也就是本例中的月銷售額匯總資料表。

Looker 會盡可能使用最小的匯總資料表，回答使用者的問題。例如：

  • 如要查詢每月總銷售額，Looker 會使用以每月銷售額為準的匯總資料表 (sales_monthly_aggregate_table)。
  • 如果查詢的是每日銷售總額，由於沒有這種精細程度的匯總資料表，Looker 會從原始資料庫表格 (orders_database) 取得查詢結果。(不過，如果使用者經常執行這類查詢，您可以為此建立匯總資料表)。
  • 如果查詢每週銷售量，由於沒有每週匯總資料表，Looker 會使用次佳的資料表，也就是以每日銷售量為準的匯總資料表 (sales_daily_aggregate_table)。

Looker 會使用匯總認知邏輯，查詢盡可能小的匯總資料表，以回答使用者的問題。只有在查詢需要比匯總資料表更精細的資料時，才會使用原始資料表。

您不需要在個別的探索中加入或新增匯總資料表。而是動態調整 Explore 查詢的 FROM 子句，以存取最適合查詢的匯總資料表。也就是說，系統會保留下鑽，並整合探索。有了匯總感知功能，Explore 就能自動運用匯總資料表，但仍可視需要深入瞭解細微資料。

您也可以運用匯總資料表大幅提升資訊主頁的效能，尤其是查詢巨量資料集的動態磚。詳情請參閱 aggregate_table 參數說明頁面的「從資訊主頁取得匯總資料表 LookML」一節。

在專案中新增匯總資料表

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，也可以從「探索」或從資訊主頁取得匯總資料表 LookML。如要瞭解 aggregate_table 參數及其子參數的詳細資料，請參閱 aggregate_table 參數說明文件頁面。

設計匯總資料表

如要讓「探索」查詢使用匯總資料表，匯總資料表必須能為「探索」查詢提供準確資料。如果符合下列所有條件，Looker 就能將匯總資料表用於「探索」查詢：

  • 探索查詢的欄位是匯總資料表欄位的子集 (請參閱本頁面的「欄位因素」一節)。如果是時間範圍，則可從匯總表格中的時間範圍衍生「探索」查詢的時間範圍 (請參閱本頁的「時間範圍因素」一節)。
  • 探索查詢包含匯總認知度支援的指標類型 (請參閱本頁的「指標類型因素」一節)，或探索查詢具有完全相符的匯總資料表 (請參閱本頁的「建立與探索查詢完全相符的匯總資料表」一節)。
  • 探索查詢的時區與匯總資料表使用的時區相符 (請參閱本頁的「時區因素」一節)。
  • 探索查詢的篩選器參照匯總資料表中可用的欄位 (做為維度)，或探索查詢的每個篩選器都與匯總資料表中的篩選器相符 (請參閱本頁的「篩選器因素」一節)。

如要確保匯總資料表能為「探索」查詢提供準確資料，方法之一是建立與「探索」查詢完全相符的匯總資料表。詳情請參閱本頁的「建立與探索查詢完全相符的匯總資料表」一節。

現場因素

如要用於探索查詢，匯總資料表必須包含該探索查詢所需的所有維度和指標，包括用於探索查詢中篩選器的欄位。如果探索查詢包含匯總資料表中沒有的維度或指標，Looker 就無法使用匯總資料表，而會改用基礎資料表。

舉例來說，如果查詢依維度 A 和 B 分組、依指標 C 匯總，並依維度 D 篩選，則匯總資料表至少須包含維度 A、B 和 D，以及指標 C。

匯總資料表也可以包含其他欄位，但必須至少包含「探索」查詢欄位，才能進行最佳化。時間範圍維度是唯一例外，因為較粗略的時間範圍可從較精細的時間範圍衍生而來。

由於有這些欄位考量，匯總資料表會專用於定義該資料表的探索。在一個探索中定義的匯總資料表，不會用於其他探索的查詢。

時間範圍因素

Looker 的匯總意識邏輯可從一個時間範圍衍生出另一個時間範圍。只要匯總資料表的時間範圍細微程度與探索查詢相同 (或更細微)，即可用於查詢。舉例來說，如果 Explore 查詢需要其他時間範圍的資料 (例如每日、每月和每年資料，甚至是每月第幾天、每年第幾天和每年第幾週的資料)，就可以使用以每日資料為基礎的匯總資料表。但如果 Explore 查詢需要每小時的資料，就無法使用年度匯總表格，因為匯總表格的資料不夠精細，無法滿足 Explore 查詢的需求。

這項原則也適用於時間範圍子集。舉例來說，如果您有過去三個月的匯總資料表，而使用者查詢過去兩個月的資料，Looker 就能使用該匯總資料表進行查詢。

此外，時間範圍篩選器查詢也適用相同邏輯：只要匯總資料表的時間範圍與探索查詢中使用的時間範圍篩選器具有相同或更精細的粒度，即可用於時間範圍篩選器查詢。舉例來說，如果匯總資料表含有每日時間範圍維度，即可用於探索查詢，並依天、週或月篩選。

度量類型因素

如要讓 Explore 查詢使用匯總資料表，匯總資料表中的指標必須能為 Explore 查詢提供準確的資料。

因此，系統僅支援特定類型的指標，詳情請參閱以下各節：

如果探索查詢使用其他類型的指標，Looker 會使用原始資料表 (而非匯總資料表) 傳回結果。唯一例外狀況是「探索」查詢與匯總資料表查詢完全相符，如「建立與『探索』查詢完全相符的匯總資料表」一節所述。

否則 Looker 會使用原始資料表 (而非匯總資料表) 傳回結果。

支援的指標類型

如果探索查詢使用的指標屬於下列類型，即可使用匯總知名度：

如要將匯總資料表用於「探索」查詢，Looker 必須能夠對匯總資料表的指標執行運算，才能在「探索」查詢中提供準確資料。舉例來說，含有 type: sum 的指標可用於匯總認知度，因為您可以加總多個總和：將每週總和的匯總資料表加總，即可取得準確的每月總和。同樣地，您可以使用 type: max 的指標，因為每日最大值的匯總資料表可用於找出準確的每週最大值。

如果是含有 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) ;;
}

如果測量指標的 sql 參數中定義了 MIN、MAX 和 COUNT 作業，系統就會支援匯總感知功能，例如這個測量指標：

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

參照 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 評估指標。

近似不重複計數的指標

一般來說，匯總認知度不支援不重複計數，因為如果您嘗試匯總不重複計數，就無法取得準確的資料。舉例來說，如果您要計算網站上的不重複使用者，某位使用者可能在間隔三週後造訪網站兩次。如果您嘗試套用每週匯總表格，取得網站上每月不重複使用者人數，該使用者會在每月不重複計數查詢中計入兩次，資料會不正確。

如要解決這個問題，可以建立與「探索」查詢完全相符的匯總資料表，詳情請參閱本頁面的「建立與『探索』查詢完全相符的匯總資料表」一節。如果探索查詢和匯總表格查詢相同，相異計數指標就會提供準確的資料，因此可用於匯總認知度。

您也可以使用不重複計數的近似值。對於支援 HyperLogLog 草圖的方言，Looker 可以運用 HyperLogLog 演算法，估算匯總資料表的相異計數。

HyperLogLog 演算法的誤差約為 2%。Looker 開發人員必須確認可使用指標的近似資料，才能使用 allow_approximate_optimization: yes 參數，這樣系統才能從匯總資料表概略計算指標。

如要瞭解詳情，並查看支援使用 HyperLogLog 計算不重複計數的方言清單，請參閱 allow_approximate_optimization 參數說明文件頁面。

時區因素

在許多情況下，資料庫管理員會使用世界標準時間做為資料庫的時區。不過，許多使用者可能不在世界標準時間時區。Looker 提供多種時區轉換選項，讓使用者能以自己的時區取得查詢結果：

  • 查詢時區：這項設定會套用至資料庫連線的所有查詢。如果所有使用者都位於同一時區，您可以設定單一查詢時區，將所有查詢從資料庫時區轉換為查詢時區。
  • 使用者專屬時區：可為使用者個別指派及選取時區。在這種情況下，查詢會從資料庫時區轉換為個別使用者的時區。

如要進一步瞭解這些選項，請參閱「使用時區設定」說明文件頁面。

瞭解這些概念有助於掌握匯總認知度，因為如果要在查詢中使用日期維度或日期篩選器，匯總資料表的時間地帶必須與原始查詢所用的時間地帶設定相符。

如果未指定 timezone 值，匯總資料表會使用資料庫時區。如果符合下列任一情況，資料庫連線也會使用資料庫時區：

  • 您的資料庫不支援時區。
  • 資料庫連線的查詢時區與資料庫時區相同。
  • 資料庫連線未指定查詢時區或使用者專屬時區。如果是這種情況，資料庫連線會使用資料庫時區。

如果符合上述任一情況，您可以省略匯總資料表的 timezone 參數。

否則，應定義匯總資料表的時區，以符合可能的查詢，這樣匯總資料表就更有可能派上用場：

  • 如果資料庫連線使用單一查詢時區，則應將匯總資料表的 timezone 值與查詢時區值相符。
  • 如果資料庫連線使用特定使用者的時區，您應建立相同的匯總資料表，但每個資料表都具有不同的 timezone 值，以配合使用者的可能時區。

篩選因子

在匯總表格中加入篩選器時，請務必小心。如果對匯總資料表套用篩選器，可能會導致結果過於狹窄，以致於無法使用匯總資料表。舉例來說，假設您建立每日訂單數的匯總資料表，並篩選出澳洲的太陽眼鏡訂單。如果使用者執行探索查詢，想瞭解全球太陽眼鏡的每日訂單數量，Looker 就無法使用匯總表格，因為匯總表格只有澳洲的資料。匯總資料表篩選資料的範圍過於狹窄，無法供探索查詢使用。

此外，請留意 Looker 開發人員可能已在探索中內建的篩選器，例如：

  • access_filters：套用使用者專屬的資料限制。
  • always_filter：要求使用者在探索查詢中加入特定一組篩選條件。使用者可在查詢時變更預設篩選條件值，但無法移除篩選條件。
  • conditionally_filter：定義一組預設篩選條件，而使用者只要從探索中定義的替換清單中套用至少一個篩選條件，就能覆寫這些預設篩選條件。

這些篩選器類型是以特定欄位為依據。如果探索有這些篩選條件，您必須在 aggregate_table 的 dimensions 參數中加入這些篩選條件的欄位。

舉例來說，以下是根據 orders.region 欄位套用存取權篩選條件的探索：

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

如要建立用於這項探索的匯總資料表，匯總資料表必須包含存取篩選器所依據的欄位。在下一個範例中，存取權篩選器是以 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 可以動態篩選匯總資料表中的資料，以符合探索查詢中的篩選條件。因此，即使探索有存取篩選器，Looker 仍可將匯總資料表用於探索的查詢。

如果探索查詢使用以 bind_filters 設定的原生衍生資料表，也會受到影響。bind_filters 參數會將探索查詢中指定的篩選器傳遞至原生衍生資料表子查詢。如果是匯總認知度，如果您的探索查詢需要使用 bind_filters 的原生衍生資料表，則只有在探索查詢中，原生衍生資料表 bind_filters 參數使用的所有欄位，與匯總資料表中的篩選器值完全相同時，探索查詢才能使用匯總資料表。

建立與探索查詢完全相符的匯總資料表

如要確保匯總資料表可用於「探索」查詢，其中一個方法是建立與「探索」查詢完全相符的匯總資料表。如果探索查詢和匯總資料表都使用相同的指標、維度、篩選條件、時區和其他參數，匯總資料表的結果就會套用至探索查詢。如果匯總資料表與「探索」查詢完全相符，Looker 就能使用包含任何類型指標的匯總資料表。

您可以使用「探索」齒輪選單中的「取得 LookML」選項，從「探索」建立匯總資料表。您也可以使用資訊主頁齒輪選單中的「取得 LookML」選項，為資訊主頁中的所有圖塊建立完全相符項目。

判斷查詢使用哪個匯總資料表

具備 see_sql 權限的使用者可以透過「探索」的「SQL」分頁中的註解，查看查詢會使用哪個匯總資料表。SQL 分頁標籤註解也會顯示在開發模式中，因此開發人員可以測試新的匯總資料表，瞭解 Looker 如何使用這些資料表，再將新資料表推送至正式環境。

舉例來說，根據先前顯示的每月匯總資料表範例，您可以前往「探索」並執行年度銷售總額的查詢。然後點選「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」分頁中可能顯示的註解，以及如何解決這些問題，請參閱本頁的「疑難排解」一節。

計算匯總意識的預估節省費用

如果資料庫連線支援費用估算，且查詢可以使用匯總資料表，則「探索」視窗會顯示使用匯總資料表而非直接查詢資料庫，可節省的運算費用。在執行查詢前，探索頁面上的「執行」按鈕旁會顯示匯總的品牌知名度節省金額。

執行查詢前，如要查看查詢會使用哪個匯總資料表，可以點選「SQL」分頁標籤，如本文件頁面的「判斷查詢會使用哪個匯總資料表」一節所述。

查詢執行完畢後，「探索」視窗的「執行」按鈕旁會顯示用於回答查詢的匯總資料表。

如果資料庫連線已啟用費用估算功能，系統會顯示匯總的認知節省金額。詳情請參閱「在 Looker 中探索資料 」說明文件頁面。

Looker 會將新資料併入匯總表格

對於設有時間篩選器的匯總資料表，Looker 可以將新資料聯集到匯總資料表中。您可能有一個包含過去三天的資料的匯總資料表，但該匯總資料表可能是昨天建構的。匯總資料表會缺少今天的資訊，因此您不會想使用該資料表，查詢最近的每日資訊。

不過，Looker 仍可使用該匯總資料表中的資料進行查詢，因為 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 會擷取匯總資料表尚未納入的最新資料，然後將最新結果與匯總資料表的結果合併。也就是說，使用者可以取得最新資料，同時運用匯總認知度資料，盡可能提升成效。

如果您處於開發模式，可以按一下「探索」的「SQL」分頁，查看 Looker 用於查詢的匯總資料表，以及 Looker 用於匯入匯總資料表未納入的新資料的 UNION 陳述式。

匯總資料表必須保留

如要存取匯總認知度，匯總資料表必須保留在資料庫中。持續性策略是在匯總資料表的 materialization 參數中指定。由於匯總資料表是永久衍生資料表 (PDT) 的一種，因此匯總資料表與 PDT 的需求條件相同。詳情請參閱「Looker 中的衍生資料表」說明文件頁面。

如果方言支援漸進式 PDT，您可以在專案中建立漸進式 PDT。Looker 會將新資料附加至資料表，藉此建立累加 PDT，而非重建整個資料表。由於匯總資料表本身就是 PDT 的一種，因此您也可以建立增量匯總資料表。如要進一步瞭解增量 PDT，請參閱「增量 PDT」說明文件頁面。如需漸進式匯總資料表的範例，請參閱 increment_key 參數說明文件頁面。

如果使用者具備 develop 權限，即可覆寫持續性設定，並重建查詢的所有匯總資料表，以取得最新資料。如要重新建立查詢的資料表，請從「探索動作」齒輪選單中選取「重建衍生資料表並執行」選項。

您必須等待「探索」查詢載入完成，才能使用這個選項。

「重建衍生資料表並執行」選項會重建查詢中參照的所有衍生資料表，以及查詢中資料表所依附的任何衍生資料表。包括匯總資料表，這本身就是一種永久衍生資料表。

如果使用者啟動「重建衍生資料表並執行」選項，查詢會等待資料表重建完成，再載入結果。其他使用者的查詢仍會使用現有資料表。重建永久資料表後，所有使用者都會使用重建的資料表。

如要進一步瞭解「重建衍生資料表並執行」選項，請參閱「Looker 中的衍生資料表」說明文件頁面。

疑難排解

如「判斷查詢使用的匯總資料表」一節所述，如果您處於開發模式，可以在「探索」中執行查詢，然後按一下「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.

在本例中，查詢中的篩選器導致系統無法使用匯總資料表。

下表列出無法使用匯總資料表的其他可能原因，以及可採取的步驟，以提高匯總資料表的可用性。

未使用匯總表格的原因 說明和可能步驟
探索中沒有這類欄位。 發生 LookML 驗證類型錯誤。這很可能是因為匯總資料表定義有誤，或是匯總資料表的 LookML 中有錯字。可能是欄位名稱有誤等問題。

如要解決這個問題，請確認匯總表格中的維度和指標與「探索」中的欄位名稱相符。如要進一步瞭解如何定義匯總資料表，請參閱 aggregate_table 參數說明文件頁面。
匯總資料表不會在查詢中納入下列欄位。 如要用於探索查詢，匯總資料表必須包含該探索查詢所需的所有維度和指標，包括用於探索查詢中篩選器的欄位。如果探索查詢包含匯總資料表中沒有的維度或指標，Looker 就無法使用匯總資料表，而會改用基礎資料表。詳情請參閱本頁的「欄位因素」一節。時間範圍維度是唯一例外，因為較粗略的時間範圍可從較精細的時間範圍衍生而來。

如要解決這個問題，請確認 Explore 查詢的欄位已納入匯總資料表定義。
查詢包含下列篩選器，但這些篩選器既未納入欄位，也未與匯總資料表中的篩選器完全相符。 「探索」查詢中的篩選器會禁止 Looker 使用匯總資料表。

如要解決這個問題，請採取下列任一做法：
  • 在匯總表格中新增相同的篩選器。
  • 將篩選器使用的欄位新增至匯總資料表。
  • 從探索查詢中移除篩選器。
詳情請參閱本頁的「篩選條件」一節。
查詢包含下列無法匯總的指標。 查詢包含一或多個匯總認知度不支援的指標類型，例如不重複計數、中位數或百分位數。

如要解決這個問題，請檢查查詢中的各項指標類型，確認是否為支援的指標類型。此外，如果 Explore 具有聯結，請確認您的指標不會透過扇出聯結轉換為相異指標 (對稱匯總)。如需相關說明，請參閱本頁的「使用彙整的對稱探索」一節。
其他匯總資料表更適合用於最佳化。 查詢有多個可用的匯總資料表，而 Looker 找到更適合使用的匯總資料表。在此情況下，您無須採取任何行動。
Looker 未進行任何分組 (因為有 primary_key 或 cancel_grouping_fields 參數)，因此無法彙整查詢。 查詢參照的維度會導致查詢無法使用 GROUP BY 子句，因此 Looker 無法使用任何匯總資料表。

如要解決這個問題，請確認檢視區塊的 primary_key 參數和「探索」的 cancel_grouping_fields 參數設定正確無誤。
匯總表格包含查詢中沒有的篩選器。 匯總資料表含有查詢中沒有的非時間篩選器。

如要解決這個問題，請從匯總資料表中移除篩選器。詳情請參閱本頁的「篩選條件」一節。
欄位在探索查詢中定義為篩選器限定欄位，但列於匯總資料表的 dimensions 參數中。 匯總資料表的 dimensions 參數會列出僅在探索查詢中定義為 filter 欄位的欄位。

如要解決這個問題，請從匯總表格的 dimensions 清單中移除該欄位。如果匯總資料表需要這個欄位，請將其新增至匯總資料表查詢中的 filters 清單。
最佳化工具無法判斷為何未使用匯總資料表。 這個註解適用於特殊情況。如果經常使用的探索查詢出現這種情況，您可以建立與探索查詢完全相符的匯總資料表。您可以從「探索」取得匯總資料表 LookML，詳情請參閱 aggregate_table 參數頁面。

注意事項

含彙整的探索對稱式彙整

請注意，在聯結多個資料庫表格的探索中，Looker 可以將 SUM、COUNT 和 AVERAGE 類型的測量值分別算繪為 SUM DISTINCT、COUNT DISTINCT 和 AVERAGE DISTINCT。Looker 這麼做是為了避免扇出誤算。舉例來說，count 測量指標會以 count_distinct 測量指標類型呈現。這是為了避免聯結的扇出誤算，也是 Looker 對稱匯總功能的一部分。如要瞭解 Looker 的這項功能，請參閱對稱匯總的最佳做法頁面。

對稱匯總功能可避免誤算，但有時也會導致匯總資料表無法使用，因此請務必瞭解這項功能。

如果是匯總感知支援的指標類型，則適用於 sum、count 和 average。如果符合下列條件，Looker 會將這些類型的指標算繪為 DISTINCT：

  • 測量指標來自「多對一」或「一對多」聯結的「一」檢視畫面。
  • 這項指標來自多對多彙整的任一檢視畫面。

如要瞭解這些類型的彙整，請參閱 relationship 參數說明文件頁面。

如果發現匯總資料表未因此原因而使用，您可以建立匯總資料表，與探索查詢完全相符，以便在探索中使用這些指標類型 (含聯結)。詳情請參閱本頁的「建立與探索查詢完全相符的匯總資料表」一節。

此外，如果您的 SQL 方言支援 HyperLogLog 草圖，可以將 allow_approximate_optimization: yes 參數新增至指標。以 allow_approximate_optimization: yes 定義計數測量指標時，即使系統將其算為不重複計數，Looker 仍可將該指標用於匯總認知度。

如需詳細資料，請參閱 allow_approximate_optimization 參數說明文件頁面，以及支援 HyperLogLog 草圖的 SQL 方言清單。

支援匯總意識的方言

使用匯總感知功能的權限取決於 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
是

支援方言，可逐步建構匯總資料表

如要讓 Looker 支援 Looker 專案中的漸進式匯總資料表，資料庫方言也必須支援。下表列出最新版 Looker 中支援遞增建構 PDT 的方言：

方言 是否支援？
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
否