汇总认知度

概览

Looker 会使用汇总感知逻辑,在数据库中查找最小、最高效的表来运行查询,同时保持准确性。

对于数据库中非常大的表,Looker 开发者可以创建较小的数据汇总表,按各种属性组合进行分组。汇总表可用作汇总表或摘要表,Looker 会尽可能使用汇总表或摘要表进行查询,而不是使用原始大型表。如果战略性地实现,汇总感知功能可以将平均查询速度提高数个数量级。

例如,您可能有一个数百 PB 级的数据表,其中每行对应于您网站上发生的每笔订单。在此数据库中,您可以创建一个包含每日销售总额的汇总表。如果您的网站每天收到 1,000 笔订单,那么每日汇总表中每天的行数将比原始表少 999 行。您可以创建另一个包含月度总销售额的汇总表,这样效率会更高。现在,如果用户运行每日或每周销售额查询,Looker 将使用每日销售总额表。如果用户运行有关年销售额的查询,而您没有年级汇总表,Looker 会使用次优选项,即本例中的月度销售额汇总表。

Looker 会尽可能使用最小的汇总表来解答用户的问题。例如:

  • 对于有关每月总销售额的查询,Looker 会使用基于每月销售额 (sales_monthly_aggregate_table) 的汇总表。
  • 对于查询每天每笔销售的总金额,没有该粒度的汇总表,因此 Looker 会从原始数据库表 (orders_database) 获取查询结果。不过,如果您的用户经常运行此类查询,您可以为其创建汇总表。
  • 对于有关每周销售额的查询,没有每周汇总表,因此 Looker 会使用次优选项,即基于每日销售额 (sales_daily_aggregate_table) 的汇总表。

Looker 会使用汇总感知逻辑,查询尽可能小的汇总表,以解答用户的问题。原始表仅用于需要比汇总表提供的更精细粒度的查询。

汇总表无需联接或添加到单独的“探索”中。而是会动态调整“探索”查询的 FROM 子句,以访问最适合该查询的汇总表。这意味着,您的数据分析将得到保留,并且“探索”功能可以合并。借助汇总感知功能,一个探索可以自动利用汇总表,但仍可根据需要深入研究精细数据。

您还可以利用汇总表大幅提升信息中心的性能,尤其是对于查询庞大数据集的图块。如需了解详情,请参阅 aggregate_table 参数文档页面中的从信息中心获取汇总表 LookML 部分。

向项目添加汇总表

Looker 开发者可以创建战略性汇总表,以最大限度地减少对数据库中大型表所需的查询次数。汇总表必须持久保留到数据库中,以便您可以访问这些表来获取汇总数据。因此,汇总表是一种永久性派生表 (PDT)

在 LookML 项目中,您可以使用 explore 参数下的 aggregate_table 参数定义汇总表。

以下是 LookML 中包含汇总表的 explore 示例:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

如需创建汇总表,您可以从头开始编写 LookML,也可以从探索信息中心获取汇总表 LookML。如需详细了解 aggregate_table 参数及其子参数,请参阅 aggregate_table 参数文档页面。

设计汇总表

若要让“探索”查询使用汇总表,汇总表必须能够为“探索”查询提供准确的数据。如果满足以下所有条件,Looker 就可以对“探索”查询使用汇总表:

  • “探索”查询的字段是汇总表的字段的一部分(请参阅本页中的字段因素部分)。或者,对于时间范围,探索查询的时间范围可以从汇总表中的时间范围派生(请参阅本页中的时间范围因素部分)。
  • 探索查询包含汇总认知度支持的衡量类型(请参阅本页中的衡量类型因素部分),或者探索查询包含完全匹配的汇总表(请参阅本页中的创建与探索查询完全匹配的汇总表部分)。
  • “探索”查询的时区与汇总表所用时区一致(请参阅本页上的时区因素部分)。
  • 探索查询的过滤条件引用可用作汇总表中维度的字段,或者探索查询的每项过滤条件都与汇总表中的过滤条件匹配(请参阅本页中的过滤条件因素部分)。

确保汇总表可以为探索查询提供准确数据的一种方法是创建与探索查询完全匹配的汇总表。如需了解详情,请参阅本页中的创建与探索查询完全匹配的汇总表部分。

现场因素

如需用于探索查询,汇总表必须包含该探索查询所需的所有维度和测量,包括在探索查询中用于过滤条件的字段。如果“探索”查询包含汇总表中不存在的维度或测量,Looker 将无法使用汇总表,而会改用基表。

例如,如果查询按维度 A 和 B 进行分组,按指标 C 进行汇总,并按维度 D 进行过滤,则汇总表中至少必须包含 A、B 和 D 作为维度,以及 C 作为指标。

汇总表还可以包含其他字段,但必须至少包含“探索”查询字段,才能进行优化。唯一的例外是时间范围维度,因为较粗粒度的时间范围可以从较精细的时间范围派生

鉴于这些字段注意事项,汇总表仅适用于其定义所在的探索。在一个探索中定义的汇总表不会用于对其他探索进行查询。

时间范围因素

Looker 的汇总认知度逻辑能够根据一个时间范围推导出另一个时间范围。汇总表可以用于查询,前提是汇总表的时间范围与探索查询的时间范围具有更精细(或等同)的粒度。例如,基于每日数据的汇总表可用于需要其他时间范围的探索查询,例如查询每日、每月和每年的数据,甚至是日期、星期和月份的数据。但是,年级汇总表无法用于需要小时级数据的探索查询,因为汇总表中的数据精细程度不够,无法满足探索查询的要求。

这同样适用于时间范围子集。例如,如果您有一个过滤了过去三个月数据的汇总表,而用户使用过滤条件查询过去两个月的数据,Looker 将能够针对该查询使用汇总表。

此外,对于包含时间范围过滤条件的查询,也适用相同的逻辑:只要汇总表的时间范围与“探索”查询中使用的时间范围过滤条件的粒度相同或更细,就可以将汇总表用于包含时间范围过滤条件的查询。例如,包含每日时间范围维度的汇总表可用于按天、周或月进行过滤的探索查询。

测量类型因素

若要让探索查询使用汇总表,汇总表中的衡量指标必须能够为探索查询提供准确的数据。

因此,仅支持某些类型的测量,如以下部分所述:

如果“探索”查询使用任何其他类型的衡量标准,Looker 将使用原始表(而非汇总表)返回结果。唯一的例外情况是,探索查询与汇总表查询完全匹配,如创建与探索查询完全匹配的汇总表部分所述。

否则,Looker 将使用原始表(而非汇总表)返回结果。

具有支持的测量类型的测量

汇总认知度可用于使用以下衡量类型的衡量结果的探索查询:

若要将汇总表用于探索查询,Looker 必须能够对汇总表的测量值进行运算,以便在探索查询中提供准确的数据。例如,包含 type: sum 的衡量指标可用于汇总认知度,因为您可以对多个总和进行求和:您可以将每周总和的汇总表相加,以获得准确的月总和。同样,您也可以使用包含 type: max 的测量,因为可以使用每日最大值的汇总表来查找准确的每周最大值。

对于包含 type: average 的指标,Looker 支持汇总感知,因为 Looker 使用总和和计数数据从汇总表中准确派生平均值。

使用 SQL 表达式定义的测量

汇总认知度还可与 sql 参数中使用表达式定义的衡量指标搭配使用。使用 SQL 表达式进行定义时,还支持以下衡量类型:

对于定义为其他测量指标组合的测量指标,系统支持汇总感知,如以下示例所示:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

对于在 sql 参数中定义计算方式的衡量标准(例如以下衡量标准),也支持汇总感知:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

此外,对于在 sql 参数中定义了 MIN、MAX 和 COUNT 运算的测量,系统支持汇总感知,例如以下测量:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

引用 LookML 字段的衡量

在衡量指标中使用 sql 表达式时,汇总认知度支持以下类型的字段引用

  • 使用 ${view_name.field_name} 格式的引用,表示其他视图中的字段
  • 使用 ${field_name} 格式的引用,表示同一视图中的字段

使用 ${TABLE}.column_name 格式(表示表中的列)定义的衡量不支持汇总感知。(如需简要了解如何在 LookML 中使用引用,请参阅纳入 SQL 和引用 LookML 对象文档页面。)

例如,由于使用此 sql 参数定义的衡量标准使用 ${TABLE}.column_name 格式,因此汇总表不支持此衡量标准:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

如果您想在汇总表中添加此测量,则可以改为创建使用 ${TABLE}.column_name 格式定义的维度,然后创建引用该维度的测量,如下所示:


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

现在,您可以在汇总表中使用 wholesale_value 测量值。

近似计数不同的衡量指标

一般来说,汇总认知度不支持使用唯一计数,因为如果您尝试汇总唯一计数,将无法获得准确的数据。例如,如果您要统计某个网站上的不同用户数,那么可能会有用户在相隔三周的时间内访问该网站两次。如果您尝试应用每周汇总表来获取您网站上的唯一用户数(按月),系统会在您的每月唯一用户数查询中将该用户统计两次,并且数据会不正确。

解决此问题的一个方法是创建与“探索”查询完全匹配的汇总表,如本页中的创建与“探索”查询完全匹配的汇总表部分所述。当“探索”查询与汇总表查询相同时,唯一计数衡量标准确实会提供准确的数据,因此可以用于汇总认知度。

另一种方法是使用近似值来计算不重复计数。对于支持 HyperLogLog 草图的方言,Looker 可以利用 HyperLogLog 算法近似估算汇总表的唯一计数。

已知 HyperLogLog 算法的误差约为 2%。allow_approximate_optimization: yes 参数要求您的 Looker 开发者确认可以使用近似数据来计算该指标,以便系统可以根据汇总表大致计算该指标。

如需了解详情以及支持使用 HyperLogLog 计算不重复计数的方言列表,请参阅 allow_approximate_optimization 参数文档页面。

时区因素

在许多情况下,数据库管理员会将世界协调时间 (UTC) 用作数据库的时区。不过,许多用户可能不在世界协调时间 (UTC) 时区。Looker 提供了多种时区转换选项,以便用户在自己的时区内获取查询结果:

  • 查询时区,此设置适用于数据库连接上的所有查询。如果您的所有用户都位于同一时区,您可以设置一个查询时区,以便将所有查询从数据库时区转换为查询时区。
  • 用户自选时区,可为用户分配和单独选择时区。在这种情况下,系统会将查询从数据库时区转换为具体用户的时区。

如需详细了解这些选项,请参阅使用时区设置文档页面。

这些概念对于了解汇总感知至关重要,因为若要将汇总表用于包含日期维度或日期过滤条件的查询,汇总表的时区必须与原始查询所用的时间区设置一致。

如果未指定 timezone 值,汇总表将使用数据库时区。如果存在以下任一情况,您的数据库连接也会使用数据库时区:

  • 您的数据库不支持时区。
  • 数据库连接的查询时区设置为与数据库时区相同的时区。
  • 您的数据库连接既没有指定的查询时区,也没有用户自选时区。如果是这种情况,您的数据库连接将使用数据库时区。

如果存在上述任一种情况,您可以为汇总表省略 timezone 参数。

否则,应定义汇总表的时区,使其与可能的查询相匹配,以便更有可能使用汇总表:

  • 如果您的数据库连接使用单个查询时区,您应将汇总表的 timezone 值与查询时区值进行匹配。
  • 如果您的数据库连接使用用户专用时区,您应创建完全相同的汇总表,每个表的 timezone 值都不同,以匹配用户可能的时区。

过滤条件

在汇总表中添加过滤条件时,请务必小心。对汇总表应用过滤条件可能会使结果过于缩小,以至于汇总表无法使用。例如,假设您创建了一个用于统计每日订单数的汇总表,并且该汇总表仅过滤出来自澳大利亚的太阳镜订单。如果用户运行一个探索查询来查看全球太阳镜的每日订单量,Looker 无法对该探索查询使用汇总表,因为汇总表中只有澳大利亚的数据。汇总表过滤的数据范围过窄,无法供“探索”查询使用。

此外,请注意 Looker 开发者可能已将哪些过滤条件内置到“探索”中,例如:

  • access_filters:应用特定于用户的数据限制。
  • always_filter:要求用户为“探索”查询添加一组特定的过滤条件。用户可以更改查询的默认过滤条件值,但无法完全移除过滤条件。
  • conditionally_filter:定义一组默认过滤条件,如果用户应用“探索”中定义的第二个列表中的至少一个过滤条件,则可以替换这些过滤条件。

这些过滤条件类型基于特定字段。如果您的探索包含这些过滤条件,您必须在 aggregate_tabledimensions 参数中添加其字段。

例如,下面的探索使用基于 orders.region 字段的访问权限过滤条件:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

如需创建要用于此探索的汇总表,该汇总表必须包含访问权限过滤条件所依据的字段。在下一个示例中,访问权限过滤条件基于字段 orders.region,并且该字段也作为维度包含在汇总表中:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

由于汇总表查询包含 orders.region 维度,因此 Looker 可以动态过滤汇总表中的数据,以匹配“探索”查询中的过滤条件。因此,即使探索具有访问权限过滤条件,Looker 仍可针对探索的查询使用汇总表。

这也适用于使用使用 bind_filters 配置的原生派生表的探索查询。bind_filters 参数会将“探索”查询中的指定过滤条件传递到原生派生表子查询。对于汇总认知度,如果您的探索查询需要使用 bind_filters 的原生派生表,则只有当原生派生表的 bind_filters 参数中使用的所有字段在探索查询中的过滤值与汇总表中的过滤值完全相同时,探索查询才能使用汇总表。

创建与“探索”查询完全匹配的汇总表

若要确保汇总表可用于探索查询,一种方法是创建与探索查询完全匹配的汇总表。如果“探索”查询和汇总表都使用相同的测量标准、维度、过滤条件、时区和其他参数,那么根据定义,汇总表的结果将应用于“探索”查询。如果汇总表与“探索”查询完全匹配,Looker 便可使用包含任何类型衡量指标的汇总表。

您可以使用探索的齿轮菜单中的获取 LookML 选项,从探索中创建汇总表。您还可以使用信息中心齿轮菜单中的 Get LookML 选项,为信息中心中的所有图块创建完全匹配的 LookML。

确定用于查询的汇总表

具有 see_sql 权限的用户可以通过“探索”的 SQL 标签页中的注释,查看系统将使用哪个汇总表进行查询。SQL 标签页中的注释也会显示在开发模式下,因此开发者可以在将新表推送到生产环境之前测试新的汇总表,了解 Looker 如何使用这些表。

例如,根据上文中显示的月度汇总表格示例,您可以前往“探索”部分,针对全年销售总额运行查询。然后,您可以点击 SQL 标签页,查看 Looker 创建的查询的详细信息。如果您使用的是开发模式,Looker 会显示注释,指明其用于查询的汇总表。

SQL 标签页上的以下注释中,我们可以看到 Looker 正在为此查询使用 sales_monthly 汇总表,以及有关为何未将其他汇总表用于此查询的信息:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

如需了解您可能会在 SQL 标签页中看到的可能的评论以及解决这些评论的建议,请参阅本页的问题排查部分。

汇总认知度计算节省估算值

如果您的数据库连接支持费用估算,并且汇总表可用于查询,则“探索”窗口会显示使用汇总表(而不是直接查询数据库)可节省的计算开销。在“探索”中运行查询之前,系统会在运行按钮旁边显示总体认知度提升幅度。

如果您想在运行查询之前查看将用于查询的汇总表,可以点击 SQL 标签页,如本文档页面中的确定将哪个汇总表用于查询部分所述。

运行查询后,探索窗口会在 Run 按钮旁边显示用于回答查询的汇总表。

系统会针对启用了费用估算功能的数据库连接显示总体感知节省金额。如需了解详情,请参阅在 Looker 中探索数据 文档页面。

Looker 会将新数据联接到汇总表

对于包含时间过滤条件的汇总表,Looker 可以将新数据联接到汇总表中。您可能有一个包含过去三天数据的汇总表,但该汇总表可能在昨天构建的。汇总表中将缺少今天的信息,因此您无法使用该表来查询最新的每日信息。

不过,Looker 仍可使用该汇总表中的数据进行查询,因为 Looker 会对最新数据运行查询,然后将这些结果联接到汇总表中的结果。

在以下情况下,Looker 可以将新数据与汇总表中的数据联接起来:

  • 汇总表包含时间过滤条件。
  • 汇总表包含一个基于时间过滤条件所用时间字段的维度。

例如,以下汇总表包含基于 orders.created_date 字段的维度,以及基于同一字段的时间过滤条件 ("3 days"):

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

如果此汇总表是昨天构建的,Looker 会检索尚未包含在汇总表中的最新数据,然后将新结果与汇总表中的结果联接起来。这意味着,您的用户将获得最新数据,同时仍可使用汇总认知度来优化效果。

如果您使用的是开发模式,可以点击“探索”的 SQL 标签页,查看 Looker 用于查询的汇总表,以及 Looker 用于提取未包含在汇总表中的较新数据的 UNION 语句。

汇总表必须持久化

为了能够获取汇总数据,您的汇总表必须持久化到数据库中。持久化策略在汇总表的 materialization 参数中指定。由于汇总表是一种永久性派生表 (PDT),因此汇总表与 PDT 具有相同的要求。如需了解详情,请参阅 Looker 中的派生表文档页面。

如果您的方言支持增量 PDT,您可以在项目中创建增量 PDT。Looker 通过将新数据附加到表中来构建增量 PDT,而不是重新构建整个表。由于汇总表本身就是 PDT 的一种,因此您也可以创建增量汇总表。如需详细了解增量 PDT,请参阅增量 PDT 文档页面。如需查看增量汇总表的示例,请参阅 increment_key 参数文档页面。

拥有 develop 权限的用户可以替换持久性设置,并重新构建查询的所有汇总表,以获取最新的数据。如需为查询重新构建表,请从“探索”操作齿轮菜单中选择重新构建派生表并运行选项。

您必须等待“探索”查询加载完毕,然后才能使用此选项。

重新构建派生表并运行选项会重新构建查询中引用的所有派生表,以及查询中表所依赖的所有派生表。这包括汇总表,它们本身就是一类永久性派生表。

对于启动重新构建派生表并运行选项的用户,查询将等待表重新构建完毕,然后再加载结果。其他用户的查询仍会使用现有表。重新构建永久表后,所有用户都将使用重新构建的表。

如需详细了解重新构建派生表并运行选项,请参阅 Looker 中的派生表文档页面。

问题排查

确定查询使用的是哪个汇总表部分所述,如果您处于开发模式,则可以在“探索”中运行查询,然后点击 SQL 标签页查看有关用于查询的汇总表的注释(如果有)。

SQL 标签页还包含有关未对查询使用汇总表的原因的说明(如果存在)。对于未使用的汇总表,注释将以以下内容开头:

Did not use [explore name]::[aggregate table name];

例如,下面的评论说明了为什么未使用 order_items“探索”中定义的 sales_daily 汇总表进行查询:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

在本例中,查询中的过滤条件阻止了使用汇总表。

下表列出了无法使用汇总表的其他可能原因,以及您可以采取的措施来提高汇总表的可用性。

不使用汇总表的原因 说明和可能的步骤
探索中没有此字段。 存在 LookML 验证类型错误。这很可能是由于汇总表未正确定义,或者汇总表的 LookML 中存在拼写错误。可能的原因是字段名称不正确或类似问题。

如需解决此问题,请验证汇总表中的维度和测量值是否与“探索”中的字段名称一致。如需详细了解如何定义汇总表,请参阅 aggregate_table 参数文档页面。
汇总表中的查询不包含以下字段。 如需用于探索查询,汇总表必须包含该探索查询所需的所有维度和测量,包括在探索查询中用于过滤条件的字段。如果“探索”查询包含汇总表中不存在的维度或测量,Looker 将无法使用汇总表,而会改用基表。如需了解详情,请参阅本页的字段因素部分。唯一的例外是时间范围维度,因为较粗粒度的时间范围可以从较精细的时间范围派生

如需解决此问题,请验证“探索”查询的字段是否包含在汇总表定义中。
查询包含以下过滤条件,这些过滤条件既未作为字段包含,也与汇总表中的过滤条件完全匹配。 “探索”查询中的过滤条件会阻止 Looker 使用汇总表。

如需解决此问题,您可以执行以下任一操作:
  • 将相同的过滤条件添加到汇总表中。
  • 将过滤器使用的字段添加到汇总表中。
  • 从“探索”查询中移除过滤条件。
如需了解详情,请参阅本页的过滤条件部分。
该查询包含以下无法汇总的测量。 查询包含一个或多个不支持汇总认知度的指标类型,例如不重复计数中位数百分位数

如需解决此问题,请检查查询中每个测量值的类型,并确保其属于支持的测量值类型之一。此外,如果您的探索包含联接,请验证您的测量结果是否未通过扇出联接转换为不重复的测量结果(对称汇总)。如需了解详情,请参阅本页中的适用于包含联接的探索的对称汇总部分。
另一个汇总表更适合进行优化。 该查询有多个可行的汇总表,Looker 找到了更合适的汇总表来替代。在这种情况下,您无需执行任何操作。
Looker 未进行任何分组(由于 primary_keycancel_grouping_fields 参数),因此无法对查询进行汇总。 查询引用的维度会导致其无法使用 GROUP BY 子句,因此 Looker 无法为该查询使用任何汇总表。

如需解决此问题,请验证视图的 primary_key 参数和探索的 cancel_grouping_fields 参数是否设置正确。
汇总表包含查询中不存在的过滤条件。 汇总表包含查询中不存在的非时间过滤条件。

要解决此问题,您可以从汇总表中移除过滤条件。如需了解详情,请参阅本页的过滤条件部分。
某个字段在“探索”查询中被定义为仅限过滤条件的字段,但在汇总表的 dimensions 参数中列出。 汇总表的 dimensions 参数列出了在“探索”查询中仅定义为 filter 字段的字段。

如需解决此问题,请从汇总表的 dimensions 列表中移除该字段。如果汇总表需要此字段,请将其添加到汇总表查询中的 filters 列表中。
优化器无法确定未使用汇总表的原因。 此注释仅适用于极端情况。如果您经常使用的探索查询出现此问题,可以创建与该探索查询完全匹配的汇总表。您可以轻松从探索中获取汇总表 LookML,如 aggregate_table 参数页面中所述。

需要考虑的事项

适用于包含联接的探索的对称汇总

需要注意的重要一点是,在联接多个数据库表的探索中,Looker 可以将类型为 SUMCOUNTAVERAGE 的测量结果分别呈现为 SUM DISTINCTCOUNT DISTINCTAVERAGE DISTINCT。Looker 之所以这样做,是为了避免扇出误算。例如,count 测量值会呈现为 count_distinct 测量值类型。这是为了避免对联接进行扇出误算,是 Looker 对称汇总功能的一部分。如需了解 Looker 的此功能,请参阅关于对称汇总的最佳实践页面。

对称汇总功能可防止计算错误,但在某些情况下,它也可能会阻止使用汇总表,因此请务必了解。

对于汇总认知度支持的衡量类型,这适用于 sumcountaverage。如果满足以下条件,Looker 会将此类测量结果呈现为 DISTINCT:

如需了解这些类型的联接,请参阅 relationship 参数文档页面。

如果您发现汇总表未因这个原因而被使用,可以创建一个与探索查询完全匹配的汇总表,以便在包含联接的探索中使用这些衡量类型。如需了解详情,请参阅本页中的创建与探索查询完全匹配的汇总表部分。

此外,如果您使用的 SQL 方言支持 HyperLogLog 草图,则可以向该衡量添加 allow_approximate_optimization: yes 参数。使用 allow_approximate_optimization: yes 定义计数指标后,Looker 可以使用该指标来汇总认知度,即使它显示为唯一计数也是如此。

如需了解详情,以及哪些 SQL 方言支持 HyperLogLog 草图的列表,请参阅 allow_approximate_optimization 参数文档页面。

对汇总认知度的方言支持

能否使用汇总感知功能取决于 Looker 连接所使用的数据库方言。在最新版 Looker 中,以下方言支持汇总感知:

方言 是否支持?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18 及更高版本
Apache Hive 2.3 及更高版本
Apache Hive 3.1.2 及更高版本
Apache Spark 3 及更高版本
ClickHouse
Cloudera Impala 3.1 及更高版本
搭配原生驱动程序的 Cloudera Impala 3.1 及更高版本
使用原生驱动程序的 Cloudera Impala
DataVirtuality
Databricks
Denodo 7
Denodo 8
Dremio
Dremio 11+
Exasol
Firebolt
Google BigQuery 旧版 SQL
Google BigQuery 标准 SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008 及更高版本
Microsoft SQL Server 2012 及更高版本
Microsoft SQL Server 2016
Microsoft SQL Server 2017 及更高版本
MongoBI
MySQL
MySQL 8.0.12 及更高版本
Oracle
Oracle ADWC
PostgreSQL 9.5 及更高版本
9.5 之前的 PostgreSQL
PrestoDB
PrestoSQL
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
TeraData
Trino
向量
Vertica

对增量构建汇总表的方言支持

为了让 Looker 支持 Looker 项目中的增量汇总表,您的数据库方言也必须支持这些表。下表显示了哪些方言在最新版 Looker 中支持增量构建 PDT:

方言 是否支持?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18 及更高版本
Apache Hive 2.3 及更高版本
Apache Hive 3.1.2 及更高版本
Apache Spark 3 及更高版本
ClickHouse
Cloudera Impala 3.1 及更高版本
搭配原生驱动程序的 Cloudera Impala 3.1 及更高版本
使用原生驱动程序的 Cloudera Impala
DataVirtuality
Databricks
Denodo 7
Denodo 8
Dremio
Dremio 11+
Exasol
Firebolt
Google BigQuery 旧版 SQL
Google BigQuery 标准 SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008 及更高版本
Microsoft SQL Server 2012 及更高版本
Microsoft SQL Server 2016
Microsoft SQL Server 2017 及更高版本
MongoBI
MySQL
MySQL 8.0.12 及更高版本
Oracle
Oracle ADWC
PostgreSQL 9.5 及更高版本
9.5 之前的 PostgreSQL
PrestoDB
PrestoSQL
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
TeraData
Trino
向量
Vertica