概览
Looker 使用聚合感知逻辑查找数据库中最小、最高效的表来运行查询，同时仍能保持准确性。
对于数据库中非常大的表，Looker 开发者可以创建较小的汇总数据表，并按各种属性组合进行分组。汇总表充当总览表或摘要表，Looker 可以尽可能将其而不是原始的大表用于查询。如果有策略地实现，汇总认知度可以将平均查询速度提高几个数量级。
例如，您可能有一个 PB 级数据表，其中一行对应您网站上发生的每个订单。根据该数据库，您可以创建一个包含每日销售总额的汇总表。如果您的网站每天收到 1,000 个订单，则每日汇总表格每天显示的行数比原始表格少 999 行。您可以创建另一个包含每月销售总额的汇总表格，这样会更加高效。因此，现在，如果用户针对每日或每周销售额运行查询，Looker 将使用“Daily sales total”表格。如果用户运行的是有关年销售额的查询，而您没有年度汇总表，则 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 权限的用户可以替换保留设置并针对查询重新构建所有汇总表，以获取最新数据。如需为查询重新构建表，请从探索操作齿轮菜单中选择重新构建派生表并运行选项。
您必须等待“探索”查询加载完成后，此选项才可用。
重新构建派生表并运行选项会重建查询中引用的所有派生表以及查询中的表所依赖的所有派生表。这包括汇总表，而汇总表本身就是一种永久性派生表。
对于启动 Rebuild Derived Tables & Run 选项的用户，查询会等到表重新构建后才加载结果。其他用户的查询仍将使用现有表。永久性表重新构建后，所有用户都将使用重新构建的表。
如需详细了解重新构建派生表并运行选项，请参阅 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 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 11 及更高版本 | 否 |
| Exasol | 是 |
| 火箭 | 否 |
| Google BigQuery 旧版 SQL | 是 |
| Google BigQuery 标准 SQL | 是 |
| Google Cloud PostgreSQL | 是 |
| Google Cloud SQL | 否 |
| Google Spanner | 否 |
| 绿紫红 | 是 |
| 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 | 是 |
| SingleStore 7 或更高版本 | 是 |
| Snowflake | 是 |
| Teradata | 是 |
| Trino | 是 |
| 矢量 | 是 |
| Vertica | 是 |
为逐步构建汇总表提供方言支持
为了让 Looker 支持 Looker 项目中的增量汇总表，您的数据库方言也必须支持这些表。下表显示了在最新版 Looker 中，哪些方言支持逐步构建 PDT：
| 方言 | 是否支持？ |
|---|---|
| 艾克蒂安雪崩 | 否 |
| Amazon Athena | 否 |
| Amazon Aurora MySQL | 否 |
| Amazon Redshift | 是 |
| 阿帕奇·德鲁伊 | 否 |
| 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 11 及更高版本 | 否 |
| Exasol | 否 |
| 火箭 | 否 |
| Google BigQuery 旧版 SQL | 否 |
| Google BigQuery 标准 SQL | 是 |
| Google Cloud PostgreSQL | 是 |
| Google Cloud SQL | 否 |
| Google Spanner | 否 |
| 绿紫红 | 是 |
| 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 | 否 |
| SingleStore 7 或更高版本 | 否 |
| Snowflake | 是 |
| Teradata | 否 |
| Trino | 否 |
| 矢量 | 否 |
| Vertica | 是 |