匯總認知

總覽

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 就能將匯總資料表用於「探索」查詢：

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

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

現場因素

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

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

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

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

時間範圍因素

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

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

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

度量類型因素

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

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

• 支援的指標類型
• 由 SQL 運算式定義的指標
• 未以 ${TABLE} 定義的指標
• 近似不重複計數的指標

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

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

支援的指標類型

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

• sum
• count
• min
• max
• average

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

如果是含有 type: average 的指標，Looker 會使用總和和計數資料，從匯總表格準確衍生平均值，因此支援匯總認知度。

以 SQL 運算式定義的指標

匯總認知度也可與使用 sql 參數中運算式定義的指標搭配使用。以 SQL 運算式定義時，系統也支援下列指標類型：

• number
• date
• string
• yesno

如果指標定義為其他指標的組合，系統會支援匯總認知度，例如：

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})
}

參照 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 仍可將匯總資料表用於探索的查詢。

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

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

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

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

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

具備 see_sql 權限的使用者可以透過 Explore 的「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 探索中定義的 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.

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

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

注意事項

含聯結的探索的對稱式匯總函式

請注意，在聯結多個資料庫表格的探索中，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 中，下列方言支援匯總感知：

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

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