请注意，您正在查看 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 会自动利用上面定义的汇总表格来回答查询。用户无需将任何特殊条件告知 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 模型中“Explore”字段的“flights.count”和“flights.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 和 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 汇总表中的“航班出发周”“航班详情运输公司”“航班数”和“航班详细取消数”字段的“探索”查询：

探索具有 FHIR_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 秒	285000
汇总表	5.1 秒	138000
增量	8 秒	147000

查询和后续汇总表中使用的字段分别是 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 行。88.5 万行的表大小仍然缩减了 97%（与之前的 3800 万行相比）；但再添加一个维度后，表的大小就会增加到 2000 万行。因此，随着您在汇总表格中添加更多字段，使其适用于更多查询，收入会逐渐减少。

构建汇总表

以我们发现可优化的航班探索为例，最好的策略是为其构建三个不同的汇总表格：

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 模型中构建汇总表，将表的持久性与探索缓存的持久性相结合。