请注意，您正在查看 Looker 文档。如需查看 Looker Studio 文档，请访问 https://support.google.com/looker-studio。

此页面由 Cloud Translation API 翻译。

增量 PDT

在 Looker 中，永久性派生表 (PDT) 会写入到数据库的暂存架构中。Looker 会根据其持久化策略保留并重建 PDT。当 PDT 触发重新构建时，Looker 会默认重新构建整个表。

增量 PDT 是 Looker 通过将新数据附加到表（而不是重新构建整个表）来构建的 PDT：

一个大型表格，其中突出显示了底部的三行，显示了向表格中添加少量新行的内容。

如果您的方言支持增量 PDT，您可以将以下类型的 PDT 转换为增量 PDT：

首次对增量 PDT 运行查询时，Looker 会构建整个 PDT 以获取初始数据。如果这个表较大，与构建任何大型表一样，初始构建可能需要大量时间。构建初始表后，如果增量 PDT 设置得当，后续构建将是增量构建，并且所需时间会更短。

对于增量 PDT，请注意以下事项：

只有使用基于触发器的持久性策略（datagroup_trigger、sql_trigger_value 或 interval_trigger）的 PDT 才支持增量 PDT。使用 persist_for 持久化策略的 PDT 不支持增量 PDT。
对于基于 SQL 的 PDT，必须使用 sql 参数定义表查询，才能将其用作增量 PDT。使用 sql_create 参数或 create_process 参数定义的基于 SQL 的 PDT 无法增量构建。正如本页的示例 1 所示，Looker 使用 INSERT 或 MERGE 命令为增量 PDT 创建增量。您无法使用自定义数据定义语言 (DDL) 语句定义派生表，因为 Looker 无法确定创建准确增量所需的 DDL 语句。
必须针对基于时间的查询优化增量 PDT 的源表。具体而言，用于增量键的时间戳列必须采用优化策略，例如分区、排序键、索引或您的方言支持的任何优化策略。我们强烈建议优化来源表，因为每次更新增量表时，Looker 都会查询来源表，以确定用于增量键的时间列的最新值。如果来源表未针对这些查询进行优化，Looker 查询最新值的速度可能会很慢，并且费用很高。

定义增量 PDT

您可以使用以下参数将 PDT 转换为增量 PDT：

increment_key（必须将 PDT 设为增量 PDT）：定义应查询的新记录的时间段。
{% incrementcondition %} 液态过滤器（将基于 SQL 的 PDT 设为增量 PDT 时所必需的；不适用于基于 LookML 的 PDT）：将增量键连接到增量键所基于的数据库时间列。如需了解详情，请参阅 increment_key 文档页面。
increment_offset（可选）：一个整数，用于定义为每个增量 build 重新构建的先前时间段（以增量密钥的粒度级别）的数量。对于延迟数据，increment_offset 参数会非常有用。在这类数据中，之前的时间段可能包含在最初构建相应增量并将其附加到 PDT 时未包含的新数据。

如需查看示例，请参阅 increment_key 参数文档页面，了解如何从永久性原生派生表、基于 SQL 的永久性派生表和汇总表创建增量 PDT。

下面是一个定义基于 LookML 的增量 PDT 的视图文件的简单示例：

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
   dimension: departure_date {
    type: date
  }
}

首次在表中运行查询时，此表将整体构建。之后，PDT 将以一天 (increment_key: departure_date) 为增量重建，过去三天 (increment_offset: 3)。

增量键基于 departure_date 维度，该维度实际上是 departure 维度组中的 date 时间范围。（如需简要了解维度组的工作原理，请参阅 dimension_group 参数文档页面。）维度组和时间范围均在 flights 视图（此 PDT 的 explore_source）中定义。下面是 flights 视图文件中 departure 维度组的定义方式：

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

增量参数与持久化策略的交互

PDT 的 increment_key 和 increment_offset 设置独立于 PDT 的持久化策略：

增量 PDT 的持久化策略仅确定 PDT 的递增时间。除非触发表的持久化策略，或者使用“探索”中的重新构建派生表并运行选项手动触发 PDT，否则 PDT 构建器不会修改增量 PDT。
当 PDT 递增时，PDT 构建器会根据当前时间增量（由 increment_key 参数定义的时间段）确定最新数据之前何时添加到表中。基于此，PDT 构建器会将数据截断到表中最近时间增量的开头，然后从中构建最新的增量。
如果 PDT 具有 increment_offset 参数，则 PDT 构建器还将重新构建 increment_offset 参数中指定的先前时间段的数量。之前的时间段从最新时间增量（由 increment_key 参数定义的时间段）的开始算起。

以下示例场景通过展示 increment_key、increment_offset 和持久化策略的交互来说明如何更新增量 PDT。

示例 1

此示例使用具有以下属性的 PDT：

增量键：date
增量偏移：3
持久性策略：每月第一天触发一次

此表将按如下方式更新：

每月持久化策略意味着系统会每月自动构建一次表格。例如，如果是 6 月 1 日，则表格中的最后一行将是 5 月 1 日添加的。
由于此 PDT 有一个基于日期的递增键，因此 PDT 构建器会在 5 月 1 日截断到当日开始时，并重新生成 5 月 1 日的数据，直到 6 月 1 日为止。
此外，此 PDT 的增量偏移为 3。因此，PDT 构建器还会重建 5 月 1 日之前的三个时间段（天）的数据。结果是，系统会重新构建 4 月 28 日、29 日、30 日以及 6 月 1 日当天的数据。

用 SQL 术语来说，PDT 构建器将在 6 月 1 日运行以下命令，以确定应重新构建现有 PDT 中的哪些行：

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

以下是 PDT 构建器将在 6 月 1 日运行的用于构建最新增量项的 SQL 命令：

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

示例 2

此示例使用具有以下属性的 PDT：

持久性策略：每天触发一次
增量键：month
增量偏移：0

以下是此表格将于 6 月 1 日更新的方式：

每日持久化策略意味着系统会每天自动构建一次表。表格中的最后一行将于 6 月 1 日添加于 5 月 31 日。
由于递增键是以月份为基础，因此 PDT 生成器将从 5 月 31 日截断回月初到月初，重新生成 5 月到当天（包括 6 月 1 日）的数据。
由于此 PDT 没有增量偏移量，因此不会重新构建任何之前的时间段。

此表在 6 月 2 日的更新如下：

表格中的最后一行将于 6 月 2 日添加于 6 月 1 日。
由于 PDT 构建器会截断回 6 月初，然后从 6 月 1 日开始重建数据，一直到当天，因此系统只会重建 6 月 1 日和 6 月 2 日的数据。
由于此 PDT 没有增量偏移量，因此不会重新构建任何之前的时间段。

示例 3

此示例使用具有以下属性的 PDT：

增量键：month
增量偏移：3
持久化策略：每天触发一次

这种情况说明，增量 PDT 的设置非常糟糕，因为它是每天触发一次 PDT，并相隔 3 个月。这意味着每天要重建至少三个月的数据，使用增量 PDT 的效率非常低。然而，为了了解增量 PDT 的工作原理，我们来看一个有趣的场景。

此表在 6 月 1 日的更新如下：

每日持久化策略意味着系统会每天自动构建一次表。例如，在 6 月 1 日，表格中的最后一行将是 5 月 31 日添加的。
由于增量键基于月份，因此 PDT 构建器将从 5 月 31 日截断回月初，并重新构建 5 月以及截至当天（包括 6 月 1 日）的所有数据。
此外，此 PDT 的增量偏移量为 3。这意味着，PDT 构建器还会重新构建 5 月之前的三个时间段（月）的数据。因此，系统会重新构建 2 月、3 月、4 月以及截至当天（6 月 1 日）的数据。

此表在 6 月 2 日的更新如下：

表格中的最后一行将于 6 月 2 日添加于 6 月 1 日。
PDT 构建器将月份截断为 6 月 1 日，并重新构建 6 月份的数据（包括 6 月 2 日）。
此外，由于存在增量偏移，PDT 构建器将在 6 月之前重建前三个月的数据。结果是，系统会从 3 月、4 月、5 月重建数据，一直到当前日期 6 月 2 日。

在开发模式下测试增量 PDT

在将新的增量 PDT 部署到生产环境之前，您可以测试 PDT，以确保其构建和递增。如需在开发模式下测试增量 PDT，请执行以下操作：

为 PDT 创建探索：
- 在关联的模型文件中，使用 include 参数将 PDT 的视图文件包含在模型文件中。
- 在同一模型文件中，使用 explore 参数为增量 PDT 视图创建探索。
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
打开 PDT 的“探索”。为此，请选择查看文件操作按钮，然后选择“探索”名称。

在“探索”中，选择一些维度或测量，然后点击运行。然后，Looker 会构建整个 PDT。如果这是您对增量 PDT 运行的首次查询，PDT 构建器将构建整个 PDT 以获取初始数据。如果表很大，初始构建可能需要很长时间，就像构建任何大型表一样。
您可以通过以下方式验证是否构建了初始 PDT：
- 如果您拥有 see_logs 权限，则可以查看 PDT 事件日志，验证表是否已构建。如果您在 PDT 事件日志中未看到 PDT 创建事件，请查看 PDT 事件日志浏览顶部的状态信息。如果显示“来自缓存”，您可以选择清除缓存并刷新，以获取更新的信息。
- 或者，您也可以在“探索”的数据栏的 SQL 标签页中查看注释。SQL 标签页会显示查询以及在“探索”中运行查询时将执行的操作。例如，如果 SQL 标签页中的注释显示 -- generate derived table e_incremental_pdt，那么系统将在您点击运行后执行的操作。
创建 PDT 的初始 build 后，使用“探索”中的重新构建派生表并运行选项，提示系统进行 PDT 的增量 build。
您可以使用之前相同的方法来验证 PDT 是否以增量方式进行构建：
- 如果您拥有 see_logs 权限，则可以使用 PDT 事件日志查看增量 PDT 的 create increment complete 事件。如果您在 PDT 事件日志中没有看到此事件，且查询状态显示为“from cache”，选择清除缓存和请刷新以获取最新信息。
- 查看“探索”数据栏的 SQL 标签页中的注释。在这种情况下，注释将指明 PDT 已递增。例如：-- increment persistent derived table e_incremental_pdt to generation 2
确认 PDT 已正确构建并递增后，如果您不想保留该 PDT 的专用探索，可以从模型文件中移除或注释掉 PDT 的 explore 和 include 参数。

在开发模式下构建 PDT 后，一旦您部署更改，同一表将用于生产环境，除非您进一步更改表的定义。如需了解详情，请参阅 Looker 中的派生表文档页面的开发模式下的持久化表部分。

增量 PDT 支持的数据库方言

为了让 Looker 支持 Looker 项目中的增量 PDT，您的数据库方言必须支持用于删除和插入行的数据定义语言 (DDL) 命令。

下表显示了在最新版 Looker 中哪些方言支持增量 PDT（对于 Databricks，只有 Databricks 12.1 及更高版本支持增量 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	是