汇总感知度教程

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

简介

本页面介绍了如何在实际场景中实现汇总感知，包括确定实现机会、汇总感知带来的价值，以及在真实模型中实现汇总感知的简单工作流。本页面并未详细介绍所有汇总感知功能或极端情况，也未详尽列出所有功能。

什么是汇总感知？

在 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 权限的用户可以通过“探索”的 SQL 标签页中的注释，查看系统将使用哪个汇总表进行查询。下面是一个使用汇总表 flights:flights_by_week_and_carrier in teach_scratch 的查询的 Looker SQL 标签页示例：

如需详细了解如何确定查询是否使用汇总表，请参阅汇总感知文档页面。

发现机会

为了最大限度地发挥汇总认知度带来的好处，您应确定汇总认知度在优化或提升汇总认知度的价值方面发挥作用的位置。

找出运行时较长的信息中心

一个很好的汇总感知机会是，为运行时非常长的经常使用的信息中心创建汇总表。您可能会收到用户反馈，说某些信息中心运行缓慢，但如果您使用的是 see_system_activity，还可以使用 Looker 的“系统活动历史记录”探索功能，查找运行时间低于平均水平的信息中心。快捷方式：您可以在浏览器中打开此系统活动记录“探索”链接，然后将网址中的“hostname”替换为 Looker 实例的名称。您会看到一个“探索”可视化图表，其中包含与实例信息中心相关的数据，包括标题、历史记录、探索次数、缓存与数据库的比率和效果不及平均水平：

在此示例中，有许多利用率较高的信息中心的效果低于平均水平，例如示例可视化图表信息中心。“示例可视化图表”信息中心使用了两个探索，因此一个好策略是为这两个探索创建汇总表。

找出速度缓慢且用户查询量较高的探索

另一个可提高总体认知度的机会是，用户对某个探索的查询量很大，但查询响应率低于平均水平。

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

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

• 由用户查询的探索（而不是通过 API 或通过定期提交内容进行的查询）
• 经常查询的探索
• 效果不佳的探索（与其他探索相比）

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

确定在查询中使用频率较高的字段

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

使用“系统活动字段使用情况”探索可了解您在探索中常常选择的字段（您已将这些字段标记为速度缓慢且使用频率较高）。快捷方式：您可以在浏览器中打开此“系统活动字段使用情况”探索链接，然后将网址中的“hostname”替换为 Looker 实例的名称。请相应地替换过滤条件。您会看到一个包含条形图可视化的探索，其中显示了字段在查询中被使用的次数：

在图中显示的“系统活动探索”示例中，您可以看到 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 汇总表中的“Flights Depart Week”“Flights Details Carrier”“Flights Count”和“Flights Detailed Cancelled Count”字段的探索查询：

使用 Amazon Redshift 从原始数据库表运行此查询需要 15.8 秒，并扫描了 3800 万行，而无需执行任何联接。对查询进行转轴（这项操作属于常规用户操作）需要 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
增量	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 行。88.5 万行的表格仍比之前的 3800 万行表格缩减了 97%；但再添加一个维度后，表格大小会增加到 2000 万行。因此，如果您在汇总表中添加更多字段以扩大其适用范围，那么效果会越来越不明显。

构建汇总表

以我们之前确定的航班探索为例，最佳策略是为其构建三个不同的汇总表：

• 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 汇总表的时间点之间的时间轴。今天收到了两个订单，但由于这些订单是在汇总表构建后收到的，因此不会显示在订单汇总表中：

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

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

摘要

总而言之，若要构建汇总感知实现，需要完成以下三个基本步骤：

1. 找出适合使用汇总表进行优化且能带来显著成效的机会。
2. 设计汇总表，以便为常见的用户查询提供最大覆盖率，同时保持足够小，以充分缩减这些查询的大小。
3. 在 Looker 模型中构建汇总表，将表的持久性与“探索”缓存的持久性搭配使用。