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

匯總認知教學課程

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

簡介

本頁面提供實用情境的匯總感知實作指南，包括找出實作機會、匯總感知帶來的價值，以及在實際模型中實作匯總感知的簡單工作流程。本頁面並未深入說明所有匯總意識功能或特殊情況，也未詳盡列出所有功能。

什麼是匯總意識？

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

您可能經常會遇到非常龐大的資料集或資料表，為了確保效能，需要匯總資料表或匯總。

一般來說，您可能會建立匯總資料表，例如包含有限維度的 orders_daily 資料表。這些項目必須在「探索」中分開處理和建模，且不會整齊地放在模型中。如果使用者必須在多個相同資料的探索之間選擇，這些限制會導致使用者體驗不佳。

現在，有了 Looker 的匯總感知功能，您可以預先建構各種精細程度、維度和匯總的匯總資料表，並告知 Looker 如何在現有探索中使用這些資料表。然後，查詢會在 Looker 認為適當的情況下，利用這些匯總資料表，不需要任何使用者輸入內容。這樣可縮減查詢大小、減少等待時間，並提升使用者體驗。

注意：Looker 的匯總資料表是永久衍生資料表 (PDT) 的一種。也就是說，匯總資料表與 PDT 的資料庫和連線需求條件相同。
如要確認資料庫方言和 Looker 連線是否支援 PDT，請參閱「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 權限的使用者可以透過 Explore 的「SQL」分頁中的註解，查看查詢會使用哪個匯總資料表。以下是使用匯總資料表 flights:flights_by_week_and_carrier in teach_scratch 的查詢範例，顯示 Looker SQL 分頁：

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

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

找出商機

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

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

如果資訊主頁的使用率很高，且執行時間很長，建議您建立匯總資料表，這就是提升匯總意識的絕佳機會。使用者可能會向您回報資訊主頁速度緩慢，但如果您有 see_system_activity，也可以使用 Looker 的系統活動記錄探索，找出執行時間比平均值慢的資訊主頁。如要使用捷徑，請在瀏覽器中輸入下列網址，並將 HOSTNAME 替換為 Looker 執行個體的名稱 (例如 example.cloud.looker.com)。

https://HOSTNAME/explore/system__activity/history?fields=dashboard.title,dashboard.link,history.count,history.average_runtime,history.cache_result_query_count,history.database_result_query_count,query.count_of_explores&f[history.created_date]=30+days&f[dashboard.title]=-NULL%2C-Limejump+Dashboard&sorts=history.count+desc&limit=500&query_timezone=America%2FLos_Angeles&vis=%7B%22show_view_names%22%3Afalse%2C%22show_row_numbers%22%3Atrue%2C%22transpose%22%3Afalse%2C%22truncate_text%22%3Atrue%2C%22hide_totals%22%3Afalse%2C%22hide_row_totals%22%3Afalse%2C%22size_to_fit%22%3Atrue%2C%22table_theme%22%3A%22gray%22%2C%22limit_displayed_rows%22%3Afalse%2C%22enable_conditional_formatting%22%3Atrue%2C%22header_text_alignment%22%3A%22left%22%2C%22header_font_size%22%3A%2212%22%2C%22rows_font_size%22%3A%2212%22%2C%22conditional_formatting_include_totals%22%3Afalse%2C%22conditional_formatting_include_nulls%22%3Afalse%2C%22show_sql_query_menu_options%22%3Afalse%2C%22show_totals%22%3Atrue%2C%22show_row_totals%22%3Atrue%2C%22series_column_widths%22%3A%7B%22dashboard.link%22%3A80%2C%22history.average_runtime%22%3A94%2C%22history.count%22%3A96%7D%2C%22series_cell_visualizations%22%3A%7B%22history.count%22%3A%7B%22is_active%22%3Afalse%7D%7D%2C%22conditional_formatting%22%3A%5B%7B%22type%22%3A%22along+a+scale...%22%2C%22value%22%3Anull%2C%22background_color%22%3A%22%232196F3%22%2C%22font_color%22%3Anull%2C%22color_application%22%3A%7B%22collection_id%22%3A%22bdo%22%2C%22palette_id%22%3A%22bdo-diverging-0%22%2C%22options%22%3A%7B%22steps%22%3A5%2C%22constraints%22%3A%7B%22min%22%3A%7B%22type%22%3A%22minimum%22%7D%2C%22mid%22%3A%7B%22type%22%3A%22number%22%2C%22value%22%3A0%7D%2C%22max%22%3A%7B%22type%22%3A%22maximum%22%7D%7D%2C%22mirror%22%3Atrue%2C%22reverse%22%3Atrue%2C%22stepped%22%3Afalse%7D%7D%2C%22bold%22%3Afalse%2C%22italic%22%3Afalse%2C%22strikethrough%22%3Afalse%2C%22fields%22%3A%5B%22history.average_runtime%22%5D%7D%5D%2C%22type%22%3A%22looker_grid%22%2C%22series_types%22%3A%7B%7D%2C%22defaults_version%22%3A1%2C%22hidden_fields%22%3A%5B%22history.cache_result_query_count%22%2C%22history.database_result_query_count%22%2C%22dashboard.link%22%5D%7D&filter_config=%7B%22history.created_date%22%3A%5B%7B%22type%22%3A%22past%22%2C%22values%22%3A%5B%7B%22constant%22%3A%2230%22%2C%22unit%22%3A%22day%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22dashboard.title%22%3A%5B%7B%22type%22%3A%22%21null%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22%22%7D%2C%7B%7D%5D%2C%22id%22%3A2%2C%22error%22%3Afalse%7D%2C%7B%22type%22%3A%22%21%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Limejump+Dashboard%22%7D%2C%7B%7D%5D%2C%22id%22%3A3%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%7B%22table_calculation%22%3A%22ratio_from_cache_vs_database%22%2C%22label%22%3A%22Ratio+from+Cache+vs+Database%22%2C%22expression%22%3A%22%24%7Bhistory.cache_result_query_count%7D%2F%24%7Bhistory.database_result_query_count%7D%22%2C%22value_format%22%3Anull%2C%22value_format_name%22%3A%22decimal_2%22%2C%22_kind_hint%22%3A%22measure%22%2C%22_type_hint%22%3A%22number%22%7D%2C%7B%22table_calculation%22%3A%22is_performing_worse_than_mean%22%2C%22label%22%3A%22Is+Performing+Worse+Than+Mean%22%2C%22expression%22%3A%22%24%7Bhistory.average_runtime%7D%3Emean%28%24%7Bhistory.average_runtime%7D%29%22%2C%22value_format%22%3Anull%2C%22value_format_name%22%3Anull%2C%22_kind_hint%22%3A%22measure%22%2C%22_type_hint%22%3A%22yesno%22%7D%5D&origin=share-expanded"  rel="undefined">this System Activity History Explore link

您會看到「探索」的視覺化資料，其中包含執行個體資訊主頁的資料，包括「標題」、「記錄」、「探索次數」、「快取與資料庫的比例」，以及「是否比平均值差」：

在這個範例中，有許多使用率偏高的資訊主頁效能低於平均值，例如「Sample Visualizations」資訊主頁。「Sample Visualizations」(視覺化範例) 資訊主頁使用兩個探索，因此為這兩個探索建立匯總資料表是不錯的策略。

找出速度緩慢且使用者查詢次數頻繁的探索

如果使用者經常查詢某個探索，但查詢回應低於平均值，這也是提高整體曝光度的機會。

您可以從系統活動記錄探索開始，找出可最佳化探索的機會。如要使用捷徑，請在瀏覽器中輸入下列網址，並將 HOSTNAME 替換為 Looker 執行個體的名稱 (例如 example.cloud.looker.com)。

https://HOSTNAME/explore/system__activity/history?fields=query.view,history.query_run_count,user.count,query.model,history.average_runtime&f[history.created_date]=30+days&f[history.source]=Explore&sorts=history.query_run_count+desc&limit=15&query_timezone=America%2FLos_Angeles&vis=%7B%22show_view_names%22%3Afalse%2C%22show_row_numbers%22%3Atrue%2C%22transpose%22%3Afalse%2C%22truncate_text%22%3Atrue%2C%22hide_totals%22%3Afalse%2C%22hide_row_totals%22%3Afalse%2C%22size_to_fit%22%3Atrue%2C%22table_theme%22%3A%22white%22%2C%22limit_displayed_rows%22%3Afalse%2C%22enable_conditional_formatting%22%3Atrue%2C%22header_text_alignment%22%3A%22left%22%2C%22header_font_size%22%3A%2212%22%2C%22rows_font_size%22%3A%2212%22%2C%22conditional_formatting_include_totals%22%3Afalse%2C%22conditional_formatting_include_nulls%22%3Afalse%2C%22show_sql_query_menu_options%22%3Afalse%2C%22show_totals%22%3Atrue%2C%22show_row_totals%22%3Atrue%2C%22series_labels%22%3A%7B%22user.count%22%3A%22User+Count%22%7D%2C%22series_column_widths%22%3A%7B%22query.model%22%3A179%2C%22query.view%22%3A128%7D%2C%22series_cell_visualizations%22%3A%7B%22history.query_run_count%22%3A%7B%22is_active%22%3Atrue%2C%22__FILE%22%3A%22system__activity%2Fcontent_activity.dashboard.lookml%22%2C%22__LINE_NUM%22%3A106%7D%2C%22user.count%22%3A%7B%22is_active%22%3Atrue%2C%22__FILE%22%3A%22system__activity%2Fcontent_activity.dashboard.lookml%22%2C%22__LINE_NUM%22%3A108%7D%7D%2C%22conditional_formatting%22%3A%5B%7B%22type%22%3A%22along+a+scale...%22%2C%22value%22%3Anull%2C%22background_color%22%3A%22%233EB0D5%22%2C%22font_color%22%3Anull%2C%22color_application%22%3A%7B%22collection_id%22%3A%22bdo%22%2C%22palette_id%22%3A%22bdo-diverging-0%22%2C%22options%22%3A%7B%22steps%22%3A5%2C%22reverse%22%3Atrue%7D%7D%2C%22bold%22%3Afalse%2C%22italic%22%3Afalse%2C%22strikethrough%22%3Afalse%2C%22fields%22%3A%5B%22history.average_runtime%22%5D%7D%5D%2C%22type%22%3A%22looker_grid%22%2C%22truncate_column_names%22%3Afalse%2C%22series_types%22%3A%7B%7D%2C%22defaults_version%22%3A1%7D&filter_config=%7B%22history.created_date%22%3A%5B%7B%22type%22%3A%22past%22%2C%22values%22%3A%5B%7B%22constant%22%3A%2230%22%2C%22unit%22%3A%22day%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22history.source%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Explore%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded

您會看到「探索」的視覺化圖表，其中包含執行個體「探索」的資料，包括「探索」、「模型」、「查詢執行次數」、「使用者人數」和「平均執行時間 (秒)」：

表格視覺化效果：顯示執行個體中最常查詢的 order_items 和 flights 探索。

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

使用者查詢的探索 (而非來自 API 或排定傳送時間的查詢)
經常查詢的探索
成效不佳的探索 (相較於其他探索)

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

找出查詢中經常使用的欄位

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

如要使用捷徑，請在瀏覽器中輸入下列網址，並將 HOSTNAME 替換為 Looker 執行個體的名稱 (例如 example.cloud.looker.com)。

https://HOSTNAME/explore/system__activity/field_usage?fields=field_usage.model,field_usage.explore,field_usage.field,field_usage.times_used&f[field_usage.model]=faa%2C%22advanced_data_analyst_bootcamp%22&f[field_usage.explore]=flights%2C%22order_items%22&sorts=field_usage.times_used+desc&limit=500&query_timezone=America%2FNew_York&vis=%7B%22x_axis_gridlines%22%3Afalse%2C%22y_axis_gridlines%22%3Atrue%2C%22show_view_names%22%3Afalse%2C%22show_y_axis_labels%22%3Atrue%2C%22show_y_axis_ticks%22%3Atrue%2C%22y_axis_tick_density%22%3A%22default%22%2C%22y_axis_tick_density_custom%22%3A5%2C%22show_x_axis_label%22%3Atrue%2C%22show_x_axis_ticks%22%3Atrue%2C%22y_axis_scale_mode%22%3A%22linear%22%2C%22x_axis_reversed%22%3Afalse%2C%22y_axis_reversed%22%3Afalse%2C%22plot_size_by_field%22%3Afalse%2C%22trellis%22%3A%22%22%2C%22stacking%22%3A%22%22%2C%22limit_displayed_rows%22%3Atrue%2C%22legend_position%22%3A%22center%22%2C%22point_style%22%3A%22none%22%2C%22show_value_labels%22%3Afalse%2C%22label_density%22%3A25%2C%22x_axis_scale%22%3A%22auto%22%2C%22y_axis_combined%22%3Atrue%2C%22ordering%22%3A%22none%22%2C%22show_null_labels%22%3Afalse%2C%22show_totals_labels%22%3Afalse%2C%22show_silhouette%22%3Afalse%2C%22totals_color%22%3A%22%23808080%22%2C%22limit_displayed_rows_values%22%3A%7B%22show_hide%22%3A%22show%22%2C%22first_last%22%3A%22first%22%2C%22num_rows%22%3A%2215%22%7D%2C%22series_types%22%3A%7B%7D%2C%22type%22%3A%22looker_bar%22%2C%22defaults_version%22%3A1%7D&filter_config=%7B%22field_usage.model%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22faa%2Cadvanced_data_analyst_bootcamp%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22field_usage.explore%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22flights%2Corder_items%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded

並視情況更換濾網。您會看到「探索」頁面，其中以長條圖顯示查詢中使用的欄位次數：

長條圖顯示 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 測量值不支援使用 HyperLogLog 的近似值以外的項目。
以基數為準的度量：與不重複度量一樣，中位數和百分位數無法預先匯總，因此不支援。

注意：如果您知道潛在使用者查詢包含匯總知名度不支援的指標類型，建議您建立與查詢完全相符的匯總資料表。如果匯總資料表與查詢完全相符，即可用於回答查詢，即使查詢的指標類型通常不支援匯總認知度。

匯總資料表精細程度

在為維度和指標組合建構表格之前，您應先判斷常見的使用模式和欄位選取項目，以便建立匯總表格，盡可能經常使用，並發揮最大影響力。請注意，查詢中使用的所有欄位 (無論是選取或篩選) 都必須位於匯總資料表中，該資料表才能用於查詢。但如先前所述，匯總資料表不一定要與查詢完全相符，才能用於查詢。您可以在單一匯總資料表中處理許多潛在的使用者查詢，並獲得大幅效能提升。

以找出查詢中經常使用的欄位為例，有兩個維度 (flights.depart_week 和 flights.carrier) 和兩個指標 (flights.count 和 flights.cancelled_count) 經常遭到選取。因此，使用這四個欄位建立匯總資料表是合情合理的做法。此外，為 flights_by_week_and_carrier 建立單一匯總資料表，會比為 flights_by_week 和 flights_by_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 匯總資料表，探索含有四個欄位的資料表。

從原始資料庫資料表執行這項查詢時，Amazon Redshift 未使用任何聯結，耗時 15.8 秒，掃描了 3,800 萬列。樞紐查詢是正常的使用者操作，耗時 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 查詢，就必須掃描 885,000 列的資料表。相較之下，如果資料表是以兩個維度為基礎，相同的查詢只需要掃描 4,592 個資料列。885,000 列的資料表仍減少了 97% 的資料表大小 (先前為 3,800 萬列)，但新增一個維度後，資料表大小會增加至 2,000 萬列。因此，在彙整資料表中納入更多欄位，以提高其對更多查詢的適用性時，回報率會遞減。

建立匯總資料表

以我們在「航班」探索中發現的最佳化機會為例，最佳策略是為其建立三種不同的匯總資料表：

flights_by_week_and_carrier
flights_by_month_and_distance
flights_by_year

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

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

持續性

如要存取匯總認知度，匯總資料表必須保留在資料庫中。最佳做法是利用資料群組，根據快取政策調整這些匯總資料表的自動重新產生時間。您應為相關聯的探索使用匯總資料表所用的相同資料群組。如果無法使用資料群組，可以改用 sql_trigger_value 參數。以下顯示 sql_trigger_value 的一般日期值：

sql_trigger_value: SELECT CURRENT_DATE() ;;

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

時間範圍邏輯

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

這張圖表顯示訂單的接收和記錄時間軸，以及「訂單」匯總表格的建構時間點。今天收到的兩筆訂單不會出現在「訂單」匯總表格中，因為這些訂單是在匯總表格建構完成後才收到：

時間軸：顯示今天和昨天收到的訂單，但不包括匯總資料表建構完成後發生的兩個資料點。

不過，當使用者查詢的時間範圍與匯總資料表重疊時，Looker 可以將新資料 UNION 到匯總資料表，如下方時間軸圖所示：

使用者的查詢包含時間軸上在匯總資料表建構後發生的資料點。

由於 Looker 可以將新資料 UNION 到匯總資料表，如果使用者篩選的時間範圍與匯總資料表和基礎資料表的結尾重疊，則匯總資料表建構後收到的訂單會納入使用者的結果。如需詳細資料，以及將新資料併入匯總資料表查詢時必須符合的條件，請參閱「匯總認知度」說明文件頁面。

摘要

總結來說，如要建構匯總認知度導入作業，有三個基本步驟：

找出適合使用匯總資料表進行最佳化調整的機會，並評估其影響。
設計匯總資料表，盡可能涵蓋常見的使用者查詢，同時維持夠小的規模，充分縮減這些查詢的大小。
在 Looker 模型中建立匯總資料表，並將資料表的持續性與探索快取的持續性配對。

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

簡介