请注意，您正在查看 Looker 文档。如需查看 Looker Studio 文档，请访问 https://support.google.com/looker-studio。

此页面由 Cloud Translation API 翻译。

教程：汇总感知

如需了解更多详情，请参阅汇总感知文档页面。

简介

本页面是关于在实际场景中实现聚合认知度的指南，包括确定实施机会、提升聚合价值意识，以及在真实模型中实施该意识的简单工作流。本页并未详尽说明所有总体感知功能或极端情况，也不是所有功能的详尽目录。

什么是总体认知度？

在 Looker 中，您主要是针对数据库中的原始表或视图进行查询。有时这些表是 Looker 永久性派生表 (PDT)。

您经常可能会遇到非常大的数据集或表，为了获得出色性能，需要使用汇总表或总览表。

通常，您可以创建汇总表，例如包含有限维度的 orders_daily 表。这些特征需要在探索中单独处理和建模，并且不会整齐地纳入模型中。当用户必须为相同的数据在多个探索之间进行选择时，这些限制会导致糟糕的用户体验。

现在，借助 Looker 的汇总感知功能，您可以预先构建各种粒度、维度和聚合级别的汇总表格，并告知 Looker 如何在现有探索中使用这些表格。然后，查询将在 Looker 认为合适的情况下利用这些总览表，无需任何用户输入。这将缩减查询大小、减少等待时间并提升用户体验。

注意：Looker 的汇总表是一种永久性派生表 (PDT)。这意味着汇总表的数据库和连接要求与 PDT 相同。
如需查看您的数据库方言和 Looker 连接是否支持 PDT，请参阅 Looker 中的派生表文档页面中列出的要求。
如需查看您的数据库方言是否支持聚合感知，请参阅聚合感知文档页面。

总体认知度的价值

以下是汇总认知度的各种重要价值主张，可帮助您从现有 Looker 模型中获得更多价值：

效果提升：实现聚合感知将加快用户查询速度。如果 Looker 包含完成用户查询所需的数据，则会使用较小的表。
费用节省：某些方言在用量模式中按查询的大小收费。通过让 Looker 查询较小的表，您可以降低每次用户查询的费用。
改善用户体验：除了优化体验（更快获取答案）外，进行整合消除了创建多余的“探索”功能。
减少 LookML 占用的空间：用灵活的原生实现取代现有的基于流动的聚合认知度策略，可以提高弹性并减少错误。
能够利用现有 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 实例的名称。您将看到一个“探索”可视化图表，其中包含有关实例信息中心的数据，包括名称、历史记录、探索次数、缓存与数据库的关系以及效果低于平均值：

在此示例中，有许多利用率较高但性能低于平均值的信息中心，例如示例可视化信息中心。示例可视化图表信息中心使用了两个探索，因此最好为这两个探索创建汇总表格。

找出速度缓慢且用户查询频繁的探索

另一个有助于提升总体认知度的探索是用户查询量很大且查询响应低于平均水平的“探索”。

您可以从系统活动历史记录探索着手，找出优化“探索”的机会。作为一种快捷方式，您可以在浏览器中打开“系统活动历史记录探索”链接，然后将网址中的“主机名”替换为您的 Looker 实例的名称。您将看到一个“探索”可视化图表，其中包含有关实例探索的数据，包括探索、模型、查询运行次数、用户计数和平均运行时间（秒）：

表格可视化内容，显示在实例上查询 order_items 和 flights 探索的频率最高。

在历史记录探索中，您可以识别实例上的以下类型的探索：

用户查询的探索（而不是通过 API 或预定配送进行的查询）
经常查询的探索
效果不佳的探索（相对于其他探索）

在前面的“系统活动历史记录探索”示例中，flights 和 order_items 探索可能是实现汇总认知度的候选对象。

识别查询中频繁使用的字段

最后，通过了解用户通常在查询和过滤器中添加的字段，您可以在数据级别发现其他机会。

使用“系统活动字段使用情况探索”工具，了解“探索”中您被认定为速度缓慢且使用量大的常用字段。作为一种快捷方式，您可以在浏览器中打开此“系统活动字段使用情况探索”链接，然后将网址中的“主机名”替换为您的 Looker 实例的名称。请相应地更换过滤条件。您会看到一个以柱状图呈现的“探索”，表示某个字段在查询中使用的次数：

条形图，显示 FAA 模型中“flights”“Explore”中的“flights.count”和“flight.depart_week”字段是最常用的字段。

在图片中显示的系统 activity 探索示例中，您可以看到 flights.count 和 flights.depart_week 是“探索”的两个最常用的字段。因此，这些字段非常适合包含在汇总表中的字段。

这样的具体数据固然很有帮助，但其中有些因素会决定您的选择标准。例如，通过查看前四个字段，您可以放心地假定，用户通常会查看预定的广告投放数和已取消的广告投放数，并且他们希望按周和按运输公司来细分这些数据。这是一个清晰、逻辑、真实的字段和指标组合的示例。

摘要

本文档页面上的步骤应作为指南，帮助您查找需要优化的信息中心、探索和字段。另外值得注意的是，这三个选项可能互斥：有问题的信息中心可能并非由有问题的“探索”功能提供支持，而且使用常用字段构建汇总表格可能对信息中心毫无帮助。这有可能是三种分散的、汇总式的认知度实现。

设计汇总表

在发现可提升汇总认知度的机会后，您可以设计最适合这些机会的汇总表格。如需了解汇总表格中支持的字段、衡量指标和时间范围，以及设计汇总表格的其他准则，请参阅汇总感知文档页面。

注意：汇总表不必与要使用的查询完全匹配。如果您的查询是以周为粒度的，并且您有一个每日汇总表格，Looker 将使用汇总表格，而不是时间戳级别的原始表格。同样，如果您将汇总表格汇总到 brand 和 date 级别，而用户仅在 brand 级别执行了查询，则该表格仍可供 Looker 用于汇总认知度。

以下衡量指标支持汇总感知：

标准测量 ：SUM、COUNT、AVERAGE、MIN 和 MAX 类型的测量
复合测量 ：NUMBER、STRING、YESNO 和 DATE 类型的测量
大致差异测量 ：可以使用 HyperLogLog 功能的方言

以下衡量指标不支持汇总感知：

独特措施：由于只能针对非汇总数据的原子性数据计算区别性，因此除了这些使用 HyperLogLog 的近似方法之外，不支持 *_DISTINCT 度量方式。
基于基数的度量：与不同的度量一样，中位数和百分位无法预汇总，也不支持。

注意：如果您知道某个潜在用户查询包含汇总感知不支持的衡量类型，就可能需要创建一个与相应查询完全匹配的汇总表格。对于某个查询，您可以使用与查询完全匹配的汇总表格来回答采用汇总认知度不支持的衡量类型。

汇总表粒度

在为维度和度量的组合创建表格之前，您应先确定常见的使用模式和字段选择模式，从而创建会尽可能频繁、能产生最大影响的汇总表格。请注意，查询中使用的所有字段（无论是选中的字段还是过滤字段）都必须位于汇总表格中，表格才能用于查询。但是，如前所述，汇总表格不必与用于该查询的查询完全匹配。您可以在一个汇总表格中处理许多潜在的用户查询，并且仍能获得显著的效果提升。

在识别查询中频繁使用的字段示例中，有两个维度（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 汇总表中的“航班出发周”“航班详情运输公司”“航班数量”和“航班详细已取消次数”字段的“探索”查询：

浏览包含“flight_by_week_and_carrier 汇总表”中的四个字段的数据表。

从原始数据库表运行此查询需要 15.8 秒，并使用 Amazon Redshift 扫描了 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（实例上最常用的“探索”）后，结果如下所示：

来源	Query Time	扫描的行数
基表	13.1 秒	28.5 万
汇总表	5.1 秒	13.8 万
增量	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 行。与之前 3800 万行相比，88.5 万行的表大小仍然减少了 97%；但再添加一个维度，将表的大小增加到 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 构建汇总表格时，会纳入截至汇总表格建立之时的数据。随后附加到数据库中基表的任何数据通常都会从使用该汇总表的查询结果中排除。

此图表显示的是与创建订单汇总表格的时间点相比，数据库中收到和记录订单的时间线。今天收到的订单有 2 个不会显示在订单汇总表格中，因为这些订单是在汇总表格创建之后才收到的：

当天和前一天所获订单的时间轴数据，不包括汇总表格建立后的两个数据点。

但是，当用户查询的时间范围与汇总表格重叠时，Looker 可以将最新数据整合到汇总表格中，如同一时间轴图所示：

用户的查询包括汇总表格创建后时间轴上的数据点。

由于 Looker 可以将新数据联合到汇总表中，因此如果用户过滤的时间范围与汇总表和基表的结束时间重叠，那么汇总表构建后收到的订单将包含在用户的结果中。如需了解详情以及将新数据联合以汇总表查询所需满足的条件，请参阅汇总感知文档页面。

摘要

总而言之，要构建聚合认知度的实现，需要执行三个基本步骤：

发现使用汇总表进行优化的适当且有影响力的机会。
设计的汇总表格应能够最大程度地覆盖常见的用户查询，同时仍然保持足够小，以便充分减小这些查询的规模。
在 Looker 模型中构建汇总表，以兼顾表格的持久性与“探索”缓存的持久性。