概览
Looker 使用汇总感知逻辑来查找数据库中可用的最小、最高效的表，以便在运行查询的同时仍然保持准确性。
对于数据库中非常大的表，Looker 开发者可以创建较小的数据汇总表，并按各种属性组合进行分组。汇总表可用作汇总表或摘要表，Looker 会尽可能使用汇总表或摘要表进行查询，而不是使用原始的大表。如果有策略地实施，总体意识可以将平均查询速度加快一个数量级。
例如，您可能有一个 PB 级数据表，您网站上发生的每个订单都占一行。在此数据库中，您可以创建一个包含每日销售总额的汇总表。如果您的网站每天收到 1,000 笔订单，那么每日汇总表中每天的行数将比原始表少 999 行。您可以创建另一个包含每月总销售额的汇总表，这样效率会更高。现在，如果用户运行每日或每周销售额查询，Looker 将使用每日销售总额表。如果用户运行有关年销售额的查询，而您没有年级汇总表，Looker 会使用次优选项，即本例中的月度销售额汇总表。
Looker 可满足用户的使用最小的汇总表格来回答问题。例如：
- 对于有关每月总销售额的查询，Looker 会使用基于每月销售额 (
sales_monthly_aggregate_table) 的汇总表。 - 对于查询每天每笔销售的总金额，没有该粒度的汇总表，因此 Looker 会从原始数据库表 (
orders_database) 获取查询结果。不过，如果您的用户经常运行此类查询，您可以为其创建汇总表。 - 对于有关每周销售额的查询，没有每周汇总表，因此 Looker 会使用次优选项，即基于每日销售额的汇总表 (
sales_daily_aggregate_table)。
使用汇总感知逻辑，Looker 将查询尽可能小的汇总表格，以回答用户的意见问题。原始表仅用于需要比汇总表提供的更精细粒度的查询。
汇总表无需联接到或添加到单独的探索中。相反，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 使用求和和计数数据从汇总表格中准确推导出平均值。
使用 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_table 的 dimensions 参数中添加其字段。
例如，下面是一个基于 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 标签页，如本文档页面中的确定将哪个汇总表用于查询部分所述。
查询运行后，“探索”窗口会在运行按钮旁边显示用于回答查询的汇总表格。
对于启用了费用估算功能的数据库连接，系统会显示汇总认知度节省情况。请参阅在 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 中的派生表文档页面，详细了解重新构建派生表和Run 选项。
问题排查
如确定查询使用的是哪个汇总表部分所述，如果您处于开发模式，则可以在“探索”中运行查询，然后点击 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_key 或 cancel_grouping_fields 参数），因此无法对查询进行汇总。 |
查询引用的维度阻止其包含 GROUP BY 子句，因此 Looker 无法为此查询使用任何汇总表。
如需解决此问题，请检查视图的 primary_key 参数和探索的 cancel_grouping_fields 参数是否设置正确。 |
| 汇总表包含查询中不存在的过滤条件。 | 汇总表包含未在查询中包含的非时间过滤条件。要解决此问题，您可以从汇总表中移除过滤条件。如需了解详情，请参阅本页中的过滤条件部分。 |
字段在“探索”查询中定义为仅用于过滤条件的字段，但会列在汇总表格的 dimensions 参数中。 |
汇总表的 dimensions 参数列出了在“探索”查询中仅定义为 filter 字段的字段。要解决此问题，请从汇总表格的“dimensions”列表中移除该字段。如果汇总表需要此字段，请将其添加到汇总表查询中的 filters 列表中。 |
| 优化器无法确定未使用汇总表的原因。 | 此注释仅适用于极端情况。如果您经常使用的探索查询出现此问题，可以创建与该探索查询完全匹配的汇总表。您可以从探索中轻松获取汇总表 LookML，如 aggregate_table 参数页面中所述。 |
需要考虑的事项
针对包含联接的探索的对称聚合
需要注意的重要一点是，在联接多个数据库表的探索中，Looker 可以将类型为 SUM、COUNT 和 AVERAGE 的测量结果分别呈现为 SUM DISTINCT、COUNT DISTINCT 和 AVERAGE DISTINCT。Looker 之所以这样做，是为了避免扇出误算。例如，count 测量值会呈现为 count_distinct 测量值类型。这是为了避免对联接进行扇出误算，是 Looker 对称汇总功能的一部分。如需了解 Looker 的此功能，请参阅关于对称汇总的最佳实践页面。
对称聚合功能可以防止计算错误，但它还可以防止在某些情况下使用您的聚合表，因此请务必了解。
对于汇总认知度支持的衡量类型，这适用于 sum、count 和 average。如果满足以下条件，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 数据库 | 是 |
| 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 及更高版本 | 是 |
| PostgreSQL 9.5 之前的版本 | 是 |
| PrestoDB | 是 |
| PrestoSQL | 是 |
| SAP HANA 2 及更高版本 | 是 |
| SingleStore | 是 |
| 单一商店 7+ | 是 |
| Snowflake | 是 |
| TeraData | 是 |
| Trino | 是 |
| 矢量 | 是 |
| Vertica | 是 |
对增量构建汇总表的方言支持
为了让 Looker 支持 Looker 项目中的增量汇总表，您的数据库方言也必须支持这些表。下表显示了哪些方言在最新版本的 Looker 中支持增量构建 PDT：
| 方言 | 是否支持？ |
|---|---|
| 阿克蒂安雪崩 | 否 |
| 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 数据库 | 否 |
| Microsoft Azure Synapse 分析 | 是 |
| 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 及更高版本 | 是 |
| PostgreSQL 9.5 之前的版本 | 是 |
| PrestoDB | 否 |
| PrestoSQL | 否 |
| SAP HANA 2+ | 否 |
| SingleStore | 否 |
| 单一商店 7+ | 否 |
| Snowflake | 是 |
| TeraData | 否 |
| Trino | 否 |
| 矢量 | 否 |
| Vertica | 是 |