教程：汇总感知

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

简介

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

什么是总体认知度？

在 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 实例的名称。请相应地替换过滤条件。您会看到一个包含条形图可视化的探索，其中会显示某个字段在查询中被使用的次数：

在图片中显示的系统 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 汇总表中的“航班出发周”“航班详情运输公司”“航班数量”和“航班详细已取消次数”字段的“探索”查询：

使用 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 查询，则需要扫描包含 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 项目并将更新部署到生产环境后，您的探索会将汇总表用于用户的查询。

持久性

为了便于进行汇总感知，汇总表格必须保留在您的数据库中。最佳做法是利用数据组使这些汇总表格的自动重新生成与您的缓存政策保持一致。对于用于关联的“探索”的汇总表格，您应该使用相同的数据组。如果您无法使用 datagroups，可以改用 sql_trigger_value 参数。下面显示了 sql_trigger_value 基于日期的通用值：

sql_trigger_value: SELECT CURRENT_DATE() ;;

这样，系统会在每天午夜自动创建汇总表格。

时间范围逻辑

Looker 构建汇总表格时，会纳入截至汇总表格建立之时的数据。随后附加到数据库中基表的任何数据通常都会从使用该汇总表的查询结果中排除。

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

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

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

摘要

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

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