匯總認知

總覽

Looker 會使用匯總認知邏輯,找出資料庫中最小且最有效率的資料表,以便執行查詢並維持準確度。

如果資料庫中有非常大的資料表,Looker 開發人員可以建立較小的資料匯總表格,並依據各種屬性組合進行分組。匯總表格可做為匯總或摘要表格,Looker 可在可行時使用這些表格進行查詢,而非使用原始的大資料表。在策略性導入的情況下,匯總感知度可大幅提升平均查詢速度。

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

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

  • 如果查詢的是每月銷售總額,Looker 會使用以月銷售額為依據的匯總資料表 (sales_monthly_aggregate_table)。
  • 如要查詢某天內每筆銷售的總數,由於沒有同等精細度的匯總資料表,因此 Looker 會從原始資料庫資料表 (orders_database) 取得查詢結果。不過,如果使用者經常執行這類查詢,您可以為其建立匯總資料表。
  • 對於每週銷售量查詢,由於沒有每週匯總表,Looker 會使用次佳做法,也就是根據每日銷售量 (sales_daily_aggregate_table) 建立匯總表。

透過匯總認知邏輯,Looker 會查詢最小的匯總資料表,以便回答使用者的問題。原始資料表只會用於查詢,這些查詢需要比匯總資料表更精細的細目資料。

您不必將匯總資料表彙整或新增至個別探索。相反地,Looker 會動態調整 Explore 查詢的 FROM 子句,以便存取查詢的最佳匯總資料表。也就是說,鑽研資料會保留,探索資料也能合併。有了匯總資料意識功能,單一探索工具就能自動利用匯總資料表,但仍可視需要深入研究詳細資料。

您也可以利用匯總表格大幅提升資訊主頁的效能,尤其是查詢大型資料集的資訊方塊。詳情請參閱 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 會使用原始資料表 (而非匯總資料表) 傳回結果。

支援的度量指標類型與度量指標

匯總知名度可用於 Explore 查詢,這些查詢使用以下指標類型的指標:

如要針對探索查詢使用匯總資料表,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% 的誤差。allow_approximate_optimization: yes 參數要求 Looker 開發人員確認可以使用近似值資料來計算指標,以便從匯總資料表計算近似值。

如需更多資訊,請參閱 allow_approximate_optimization 參數說明文件頁面,以及支援使用 HyperLogLog 計算不重複值的方言清單

時區因素

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

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

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

這些概念對於瞭解匯總資料表的認知非常重要,因為匯總資料表的時間區必須與原始查詢使用的時間區設定相符,才能用於含有日期維度或日期篩選器的查詢。

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

  • 您的資料庫不支援時區。
  • 資料庫連線的查詢時區已設為與資料庫時區相同。
  • 您的資料庫連線既沒有指定查詢時區,也沒有使用者專屬時區。在這種情況下,資料庫連線會使用資料庫時區。

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

否則,請定義匯總資料表的時區,以便與可能的查詢相符,讓匯總資料表更有可能被使用:

  • 如果資料庫連線使用單一查詢時區,請將匯總資料表的 timezone 值與查詢時區值比對。
  • 如果資料庫連線使用使用者專屬的時區,您應建立相同的匯總資料表,每個資料表都應有不同的 timezone 值,以便與使用者的可能時區相符。

篩選因素

在匯總表格中加入篩選器時,請務必小心。匯總資料表上的篩選器可能會將結果縮小到無法使用匯總資料表的程度。舉例來說,假設您建立匯總表格來計算每日訂單數量,而匯總表格篩選條件只會篩選來自澳洲的太陽眼鏡訂單。如果使用者針對全球太陽眼鏡的每日訂單數量執行探索查詢,Looker 就無法使用該探索查詢的匯總表格,因為匯總表格只含澳洲的資料。匯總資料表過度篩選資料,無法供探索查詢使用。

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

  • access_filters:套用使用者專屬的資料限制。
  • always_filter:要求使用者為探索查詢加入特定一組篩選器。使用者可以變更查詢的預設篩選器值,但無法完全移除篩選器。
  • conditionally_filter:定義一組預設篩選器,如果使用者套用 Explore 中定義的第二個清單中至少一個篩選器,系統就會覆寫這些篩選器。

這些篩選器類型會根據特定欄位,如果探索包含這些篩選器,您必須在 aggregate_tabledimensions 參數中加入這些欄位。

舉例來說,以下是包含以 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」SQL分頁,查看 Looker 建立的查詢詳細資料。如果您處於開發模式,Looker 會顯示註解,指出用於查詢的匯總資料表。

從「SQL」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」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」SQL分頁,查看 Looker 用於查詢的匯總資料表,以及 Looker 用來擷取匯總資料表中未包含的較新資料的 UNION 陳述式。

匯總資料表必須保留

匯總資料表必須在資料庫中保留,才能用於匯總資訊。持久化策略是在匯總資料表的 materialization 參數中指定。匯總資料表是一種永久衍生資料表 (PDT),因此匯總資料表的相關規定與 PDT 相同。詳情請參閱「Looker 中的衍生資料表」說明文件。

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

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

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

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

如果使用者啟動「Rebuild Derived Tables & Run」選項,查詢會等待資料表重建完成,再載入結果。其他使用者的查詢仍會使用現有資料表。一旦重新建構了永久資料表,所有使用者都會使用重新建構的資料表。

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

疑難排解

如「決定查詢要使用哪個匯總資料表」一節所述,如果您處於開發模式,可以在「探索」中執行查詢,然後按一下「SQL」SQL分頁,查看與查詢所用匯總資料表相關的註解 (如有)。

「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 就無法使用匯總表格,而會改用基礎表格。詳情請參閱本頁的「欄位因素」一節。唯一的例外狀況是時間範圍維度,因為較粗略精細度的時間範圍可從較精細精細度的時間範圍衍生

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

如要解決這個問題,請執行下列任一操作:
  • 在匯總表格中加入相同的篩選器。
  • 將篩選器使用的欄位新增至匯總表格。
  • 從探索查詢中移除篩選器。
詳情請參閱本頁的「篩選因素」一節。
查詢包含下列無法匯總的評估指標。 查詢包含一或多個不支援匯總認知的度量類型,例如不重複計數中位數百分位數

如要解決這個問題,請檢查查詢中每個指標的類型,並確認該類型為支援的指標類型之一。此外,如果探索中有彙整,請確認您的成效指標不會透過扇形彙整轉換為不同的成效指標 (對稱匯總)。如需說明,請參閱本頁的「含有彙整的 Explore 的對稱匯總」一節。
其他匯總資料表更適合用於最佳化。 查詢有許多可用的匯總表格,Looker 找到了更合適的匯總表格來取代。在這種情況下,您無須採取任何行動。
Looker 並未進行任何分組 (因為 primary_keycancel_grouping_fields 參數),因此無法匯總查詢。 查詢參照的維度會導致無法使用 GROUP BY 子句,因此 Looker 無法為查詢使用任何匯總資料表。

如要解決這個問題,請確認檢視畫面的 primary_key 參數和探索的 cancel_grouping_fields 參數設定正確無誤。
匯總表格包含查詢中沒有的篩選器。 匯總表格含有不在查詢中的非時間篩選器。

如要解決這個問題,您可以從匯總表格中移除篩選器。詳情請參閱本頁的「篩選因素」一節。
在探索查詢中,某個欄位會定義為篩選器限定欄位,但會列在匯總表格的 dimensions 參數中。 匯總表格的 dimensions 參數會列出在探索查詢中僅定義為 filter 欄位的欄位。

如要解決這個問題,請從匯總表格的 dimensions 清單中移除該欄位。如果匯總表需要這個欄位,請將該欄位新增至匯總表查詢的 filters 清單中。
最佳化工具無法判斷為何未使用匯總資料表。 這則留言是用於極端情況。如果您看到這則訊息,表示您經常使用的探索查詢無法建立匯總表。您可以從「探索」取得匯總資料表 LookML,如 aggregate_table 參數頁面所述。

注意事項

針對含有彙整作業的探索,使用對稱式匯總函式

值得注意的是,在彙整多個資料庫資料表的探索中,Looker 會將 SUMCOUNTAVERAGE 類型的評量項目分別顯示為 SUM DISTINCTCOUNT DISTINCTAVERAGE DISTINCT。Looker 會這麼做,是為了避免扇形展開錯誤計算。舉例來說,count 測量值會以 count_distinct 測量值類型呈現。這可避免彙整作業的扇形展開錯誤計算,也是 Looker 對稱匯總功能的一部分。如要進一步瞭解 Looker 的這項功能,請參閱對稱匯總的最佳做法頁面。

對稱匯總功能可避免誤算,但在某些情況下,這項功能也會導致匯總資料表無法使用,因此請務必瞭解這項功能。

對於匯總感知支援的評估類型,這項規定適用於 sumcountaverage。如果符合下列情況,Looker 會將這類指標顯示為 DISTINCT:

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

如果發現匯總資料表並未因這個原因而無法使用,您可以建立匯總資料表,讓匯總資料表與探索查詢完全相符,以便在含有彙整作業的探索中使用這些測量類型。詳情請參閱本頁的「建立與探索查詢完全相符的匯總資料表」一節。

此外,如果您使用支援 HyperLogLog 草圖的 SQL 方言,可以將 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
Dremio
Dremio 11+
Exasol
Firebolt
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
Dremio
Dremio 11+
Exasol
Firebolt
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