概览
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 选项，通过“探索”工具创建汇总表。您还可以使用信息中心齿轮菜单中的获取 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。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_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 中，以下方言支持聚合感知：
| 方言 | 是否支持？ |
|---|---|
| 阿克蒂安雪崩 | 是 |
| 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 | 是 |
| 迪诺多 7 | 否 |
| 迪诺多 8 号星 | 否 |
| 德雷米奥 | 否 |
| Dremio 11+ | 否 |
| Exasol | 是 |
| 火箭 | 否 |
| 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 | 是 |
| 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 | 是 |
| 迪诺多 7 | 否 |
| 迪诺多 8 号星 | 否 |
| 德雷米奥 | 否 |
| Dremio 11+ | 否 |
| Exasol | 否 |
| 火箭 | 否 |
| 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 | 否 |
| SingleStore 7 及更高版本 | 否 |
| Snowflake | 是 |
| Teradata | 否 |
| Trino | 否 |
| 矢量 | 否 |
| Vertica | 是 |