本頁面由 Cloud Translation API 翻譯而成。

匯總認知教學課程

詳情請參閱「匯總認知度」說明文件頁面。

簡介

本頁面是實用情境中導入匯總認知功能的指南，包括如何找出導入機會、匯總認知功能帶來的價值，以及在實際模型中導入匯總認知功能的簡易工作流程。本頁面並未深入說明所有匯總認知功能或極端情況，也不是所有功能的完整目錄。

什麼是匯總認知度？

在 Looker 中，您通常會查詢資料庫中的原始資料表或檢視表。有時這些是 Looker 永久衍生資料表 (PDT)。

您可能經常會遇到需要匯總資料表或匯總資料表才能發揮效能的大型資料集或資料表。

通常，您可以建立匯總表格，例如含有有限維度的 orders_daily 表格。這些資料必須個別處理，並在「探索」中個別建立模型，且無法整齊地放入模型中。當使用者必須在同一份資料的多個探索中進行選擇時，這些限制會導致使用者體驗不佳。

有了 Looker 的匯總資料意識，您可以預先建構匯總資料表，以便匯總資料表具有不同程度的精細度、維度和匯總功能，並告知 Looker 如何在現有的探索中使用這些資料表。接著，查詢會在 Looker 認為適當的情況下，利用這些匯總表格，而不需要任何使用者輸入內容。這麼做可縮減查詢大小、縮短等待時間，並提升使用者體驗。

注意：Looker 的匯總資料表是一種永久衍生資料表 (PDT)。也就是說，匯總資料表與 PDT 有相同的資料庫和連線要求。
如要瞭解資料庫方言和 Looker 連線是否支援持續衍生資料表，請參閱「Looker 中的衍生資料表」說明文件頁面上的相關規定。
如要瞭解資料庫方言是否支援匯總認知，請參閱「匯總認知」說明文件頁面。

匯總知名度的價值

您可以透過多種價值主張匯總認知優惠，從現有的 Looker 模型中獲得額外價值：

改善效能：實作匯總認知功能，可加快使用者查詢速度。如果 Looker 發現較小的資料表含有完成使用者查詢所需的資料，就會使用該資料表。
節省成本：某些方言會根據消費模型的查詢大小收費。讓 Looker 查詢較小的資料表，即可降低每個使用者查詢的費用。
使用者體驗強化：除了提供更快的查詢解答體驗，整合功能還可避免重複建立探索。
減少 LookML 足跡：將現有的 Liquid 匯總認知策略，換成彈性原生實作，可提高韌性並減少錯誤。
可利用現有的 LookML：匯總資料表會使用 query 物件，重複使用現有模型化邏輯，而非使用明確的自訂 SQL 重複邏輯。

基本範例

以下是 Looker 模型中非常簡單的實作方式，可說明輕量匯總感知功能。假設資料庫中有個虛構的 flights 資料表，其中每筆資料行都代表 FAA 記錄的每個航班，我們就可以在 Looker 中使用這個表格建立模型，並透過專屬檢視畫面和探索功能進行分析。以下是我們可為探索定義的匯總資料表 LookML：

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

有了這個匯總資料表，使用者就能查詢 flights 探索，Looker 也會自動利用 LookML 中定義的匯總資料表，並使用匯總資料表來回答查詢。使用者不必向 Looker 告知任何特殊條件：如果表格適合使用者選取的欄位，Looker 就會使用該表格。

擁有 see_sql 權限的使用者，可以透過「探索」頁面 SQL 分頁中的註解，查看查詢會使用哪個匯總資料表。以下是使用匯總資料表 flights:flights_by_week_and_carrier in teach_scratch 的查詢，其 Looker SQL 分頁範例：

「探索」的「SQL」分頁會顯示基礎 SQL 和註解，其中註解會指定所用匯總資料表的暫存結構定義。

如要進一步瞭解如何判斷查詢是否使用匯總資料表，請參閱「匯總資料表感知功能」說明文件頁面。

找出商機

如要盡量發揮匯總知名度的效益，您應找出匯總知名度在最佳化或提升匯總知名度價值方面的作用。

找出執行時間較長的資訊主頁

匯總資料的一個絕佳應用情境，就是為使用頻率極高的資訊主頁建立匯總資料表，以便在執行期間取得大量資料。使用者可能會向您反映資訊主頁執行速度緩慢的問題，如果您有 see_system_activity，也可以使用 Looker 的「系統活動記錄探索」功能，找出執行速度低於平均值的資訊主頁。您可以透過捷徑在瀏覽器中開啟這個系統活動記錄探索連結，然後將網址中的「主機名稱」替換為 Looker 例項的名稱。您會看到「探索」視覺化資料，其中包含相關例項的資訊，包括「標題」、「記錄」、「探索次數」、「快取與資料庫的比例」和「成效低於平均值」：

在這個範例中，有許多使用率偏高的資訊主頁，其效能低於平均值，例如「Sample Visualizations」資訊主頁。「範例圖表」資訊主頁使用兩個探索，因此建議您為這兩個探索建立匯總資料表。

找出使用者大量查詢且速度緩慢的探索

另一個提高總體認知的機會，是針對使用者大量查詢且查詢回應率低於平均值的探索。

您可以使用「系統活動歷程記錄探索」做為起點，找出可改善探索成效的機會。您可以使用捷徑，在瀏覽器中開啟系統活動記錄探索連結，然後將網址中的「主機名稱」替換為 Looker 執行個體的名稱。您會看到「探索」視覺化資料，其中包含相關例項的「探索」、「模型」、「查詢執行次數」、「使用者人數」和「平均執行時間 (秒)」：

表格視覺化資料顯示，在這個例項中，order_items 和 flights Explore 的查詢頻率最高。

在「歷史記錄探索」中，您可以在執行個體中找出下列類型的探索項目：

使用者查詢的探索 (與 API 或排程提交的查詢不同)
經常查詢的探索
成效不佳的探索 (相對於其他探索)

在先前的系統活動記錄探索範例中，flights 和 order_items 探索是可能的匯總認知實作候選項目。

找出在查詢中使用頻繁的欄位

最後，您可以瞭解使用者在查詢和篩選器中常用的欄位，藉此在資料層級找出其他商機。

使用「系統活動欄位使用率」探索，瞭解您認為速度較慢且使用頻繁的探索中常用的欄位。您可以透過捷徑在瀏覽器中開啟這個系統活動欄位用途探索連結，然後將網址中的「主機名稱」替換為 Looker 例項的名稱。並據此替換篩選器。您會看到「探索」畫面，其中的長條圖視覺化呈現資料欄在查詢中使用的次數：

長條圖：顯示 faa 模型中航班探索的欄位，其中 flights.count 和 flights.depart_week 是使用頻率最高的欄位。

在圖片中顯示的系統活動探索範例中，您可以看到 flights.count 和 flights.depart_week 是探索中兩個最常選取的欄位。因此，這些欄位是納入匯總表的理想選擇。

這類具體資料很有幫助，但您也需要參考主觀因素來決定選拔條件。舉例來說，根據前面四個欄位，您可以合理推斷使用者通常會查看預定航班數量和取消航班數量，而且他們希望以週和航空公司做為資料細分依據。以下是欄位和指標的實際明確邏輯組合範例。

摘要

本說明文件頁面上的步驟可做為指南，協助您找出需要納入最佳化考量的資訊主頁、探索和欄位。另外，請注意，這三項功能可能互相排斥：有問題的資訊圖表可能無法由有問題的探索功能提供支援，而使用常用欄位建立匯總表格可能對這些資訊圖表毫無幫助。這可能是三種不同的匯總認知度實作方式。

設計匯總資料表

找出匯總認知度商機後，您就可以設計最能因應這些商機的匯總表格。如要瞭解匯總資料表支援的欄位、指標和時間範圍，以及設計匯總資料表的其他規範，請參閱「匯總認知度」說明文件頁面。

注意：匯總資料表不必與查詢完全相符，如果查詢的細節層級為週，且您有每日匯總表格，Looker 會使用匯總表格，而非原始的時間戳記層級表格。同樣地，如果您將匯總資料表匯總至 brand 和 date 層級，而使用者只在 brand 層級進行查詢，該資料表仍可供 Looker 用於匯總認知。

下列指標支援匯總認知度：

標準指標： SUM、COUNT、AVERAGE、MIN 和 MAX 類型的指標
複合指標： NUMBER、STRING、YESNO 和 DATE 類型的指標
近似不重複度量： 可使用 HyperLogLog 功能的方言

下列指標不支援匯總知曉度：

Distinct 指標：由於distinctness 只能根據原子且未經匯總的資料計算，因此除了使用 HyperLogLog 的近似值外，不支援 *_DISTINCT 指標。
以基數為準的評估指標：與不重複評估指標一樣，系統不支援預先匯總中位數和百分位數。

注意：如果您知道潛在使用者查詢的評估類型不受匯總認知支援，建議您建立與查詢完全相符的匯總資料表。與查詢完全相符的匯總資料表，可用於回答包含匯總認知功能不支援的評估類型查詢。

匯總表格精細程度

在為維度和度量組合建立資料表之前，請先確定常見的使用模式和欄位選取方式，以便建立盡可能頻繁使用且影響力最大的匯總資料表。請注意，查詢中使用的所有欄位 (無論是選取或篩選) 都必須位於匯總資料表中，資料表才能用於查詢。不過，如先前所述，匯總資料表不必與查詢完全相符，即可用於查詢。您可以在單一匯總資料表中處理許多潛在的使用者查詢，同時仍可獲得大幅的效能提升。

在找出查詢中使用頻率很高的欄位的範例中，有兩個經常選取的維度 (flights.depart_week 和 flights.carrier)，以及兩個度量 (flights.count 和 flights.cancelled_count)。因此，建立使用這四個欄位的匯總資料表是合理的做法。此外，與為 flights_by_week 和 flights_by_carrier 建立兩個不同的匯總資料表相比，為 flights_by_week_and_carrier 建立單一匯總資料表，可讓匯總資料表的使用頻率更高。

以下是我們可能會為常見欄位查詢建立的累加表格範例：

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

您的業務使用者、軼事證據，以及 Looker 的系統活動資料，都能協助您做出決策。

平衡適用性和效能

以下範例顯示探索查詢，針對 flights_by_week_and_carrier 匯總表格中的「航班出發週」、「航班詳細資料航空公司」、「航班數量」和「航班詳細資料取消數量」欄位：

探索含有四個欄位的資料表，這些欄位來自 flights_by_week_and_carrier 匯總資料表。

從原始資料庫資料表執行這項查詢，需要花費 15.8 秒，並掃描 3800 萬列，且不會使用 Amazon Redshift 進行任何彙整。轉換查詢 (這是一般使用者操作) 需要花費 29.5 秒。

實作 flights_by_week_and_carrier 匯總資料表後，後續查詢花費 7.2 秒，並掃描 4592 列。這表示資料表大小減少了 99.98%。轉換查詢的時間為 9.8 秒。

透過「系統活動欄位使用率探索」功能，我們可以瞭解使用者在查詢中加入這些欄位的頻率。在這個範例中，flights.count 使用了 47,848 次，flights.depart_week 使用了 18,169 次，flights.cancelled_count 使用了 16,570 次，flights.carrier 使用了 13,517 次。

即使我們保守估計，這類查詢中有 25% 以最簡單的方式 (簡單選取，不含樞紐) 使用所有 4 個欄位，3379 x 8.6 秒 = 可省下 8 小時 4 分鐘的總使用者等待時間。

注意：此處使用的範例模型非常基本。這些結果不應做為模型的基準或參考依據。

將相同的流程套用至電子商務模型 order_items (在執行個體中使用最頻繁的「探索」功能) 後，結果如下：

來源	查詢時間	掃描的資料列
基本資料表	13.1 秒	285,000
匯總資料表	5.1 秒	138,000
Delta	8 秒	147,000

在查詢和後續匯總資料表中使用的欄位為 brand、created_date、orders_count 和 total_revenue，並使用兩個彙整。這些欄位已被使用 11,000 次。假設使用者同樣有 25% 的總用量，他們的總省時時間將會是 6 小時 6 分鐘 (8 秒 * 2750 = 22000 秒)。匯總表格的建構時間為 17.9 秒。

查看這些結果後，不妨花點時間退一步，評估以下項目可能帶來的報酬：

改善效能「可接受」的大型複雜模型/探索，並透過更優質的建模做法提升效能

相較於

使用匯總認知功能，針對使用頻率較高且成效不佳的簡易模型進行最佳化

您會發現，當您嘗試從 Looker 和資料庫中取得最後一點成效時，成效就會遞減。您應隨時瞭解基準效能預期值，尤其是來自商業使用者的預期值，以及資料庫的限制 (例如並行作業、查詢門檻、成本等)。您不應期待總體認知度能克服這些限制。

此外，設計匯總資料表時，請記住，如果欄位越多，匯總資料表就會越大，速度也會變慢。較大的資料表可改善更多查詢，因此可用於更多情況，但大型資料表的速度不如較小、較簡單的資料表。

例如：

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

這會導致匯總表格用於任何顯示的維度組合和任何包含的評估指標，因此可用於回答許多不同的使用者查詢。不過，如果要使用這個資料表執行簡單的 carrier 和 count 查詢 SELECT，就必須掃描 885,000 列的資料表。相較之下，如果資料表是根據兩個維度建立，同樣的查詢只需要掃描 4,592 列。885K 列的資料表仍可將資料表大小縮減 97% (相較於先前的 38M 列)；但再新增一個維度後，資料表大小就會增加到 20M 列。因此，如果在匯總資料表中加入更多欄位，以便讓匯總資料表適用於更多查詢，則會導致邊際效益遞減。

建構匯總資料表

以我們認為有最佳化機會的「航班」探索為例，最佳策略是建立三個不同的匯總表格：

flights_by_week_and_carrier
flights_by_month_and_distance
flights_by_year

建立這些匯總資料表最簡單的方法，就是從「探索」查詢或資訊主頁取得匯總資料表 LookML，然後將 LookML 新增至 Looker 專案檔案。

將匯總資料表新增至 LookML 專案並將更新部署至正式環境後，探索功能就會為使用者的查詢運用匯總資料表。

長期潛伏

如要使用匯總資料，匯總資料表必須保留在資料庫中。最佳做法是利用datagroups，讓這些匯總資料表的自動重建作業與您的快取政策保持一致。您應為用於相關探索的匯總資料表使用相同資料群組。如果無法使用資料群組，您可以改用 sql_trigger_value 參數。以下為 sql_trigger_value 的泛型日期值：

sql_trigger_value: SELECT CURRENT_DATE() ;;

系統會在每天午夜自動建立匯總資料表。

時間範圍邏輯

Looker 建立匯總表時，會納入匯總表建立時點之前的資料。後續在資料庫中附加至基礎資料表的任何資料，通常會從使用該匯總表格的查詢結果中排除。

這張圖表顯示訂單何時收到並記錄在資料庫中，以及Orders匯總表格建立的時間點。今天收到兩筆訂單，但由於訂單是在匯總表格建立後才收到，因此不會顯示在「Orders」匯總表格中：

今天和昨天收到的訂單時間表，排除建立匯總資料表後的兩個資料點。

不過，如果使用者查詢的時間範圍與匯總資料表重疊，Looker 可以將新資料匯入匯總資料表，如同同一個時間軸圖表所示：

使用者的查詢會納入匯總資料表建立後的時間軸資料點。

由於 Looker 可將最新資料與匯總資料表進行 UNION，因此如果使用者篩選的時間範圍與匯總資料表和基礎資料表的結束時間重疊，匯總資料表建立後收到的訂單就會納入使用者的結果。如需詳細資訊，請參閱「匯總資料感知功能」說明文件頁面，瞭解匯總表格查詢需要符合哪些條件，才能將新資料合併。

摘要

回顧一下，如要建構匯總認知實作項目，必須完成三個基本步驟：

找出適合使用匯總資料表進行最佳化調整的機會，並發揮最佳成效。
設計匯總資料表，以便為常見的使用者查詢提供最完整的涵蓋率，同時保持資料表大小足以充分減少這些查詢的大小。
在 Looker 模型中建構匯總表格，將表格的持久性與「探索」快取的持久性配對。

匯總認知教學課程 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

簡介