此页面由 Cloud Translation API 翻译。

增量 PDT

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

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

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

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

汇总表
基于 LookML 的（原生）PDT
基于 SQL 的 PDT

首次对增量 PDT 运行查询时，Looker 会构建整个 PDT 以获取初始数据。如果表很大，则初始构建可能需要相当长的时间，就像构建任何大型表一样。构建初始表后，如果增量 PDT 设置得当，后续构建将是增量的，所需时间也会更少。

请注意以下有关增量 PDT 的事项：

增量 PDT 仅适用于使用基于触发器的持久性策略（datagroup_trigger、sql_trigger_value 或 interval_trigger）的 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 %} Liquid 过滤条件（必须使用此过滤条件才能使基于 SQL 的 PDT 成为增量 PDT；不适用于基于 LookML 的 PDT）：将增量键连接到增量键所基于的数据库时间列。如需了解详情，请参阅 increment_key 文档页面。
increment_offset（可选）：一个整数，用于定义为每个增量 build 重建的之前时间段（以增量键的粒度为单位）的数量。如果数据延迟到达，increment_offset 参数会非常有用，因为之前的时间段可能包含在最初构建相应增量并将其附加到 PDT 时未包含的新数据。

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

下面是一个简单的视图文件示例，用于定义基于 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
  }
}

首次对该表运行查询时，系统会完整构建该表。之后，系统将以一天为增量 (increment_key: departure_date) 重建 PDT，最多可回溯三天 (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；除非在探索中通过 Rebuild Derived Tables & Run 选项手动触发 PDT。
当 PDT 递增时，PDT 构建器将根据最新的时间增量（由 increment_key 参数定义的时间段）确定之前向表中添加最新数据的时间。根据此信息，PDT 构建器会将数据截断到表中最近的时间增量的开头，然后从该位置开始构建最新增量。
如果 PDT 具有 increment_offset 参数，PDT 构建器还会重新构建 increment_offset 参数中指定的先前时间段数。之前的时间段从当前时间增量（由 increment_key 参数定义的时间段）的开头开始回溯。

以下示例场景展示了增量 PDT 的更新方式，其中显示了 increment_key、increment_offset 和持久性策略的互动。

示例 1

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

递增键：日期
增量偏移：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：

持久化策略：每天触发一次
增量键：月份
增量偏移：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：

增量键：月份
增量偏移：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 个月的数据。这样一来，系统会从 3 月、4 月、5 月一直到当前日期（6 月 2 日）重新构建数据。

在开发模式下测试增量 PDT

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

为 PDT 创建探索：
- 在关联的模型文件中，使用 include 参数将 PDT 的视图文件包含在模型文件中。
- 在同一模型文件中，使用 explore 参数为增量 PDT 的视图创建 Explore。
```
 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 事件日志中未看到此事件，并且查询状态显示“来自缓存”，请选择清除缓存并刷新以获取最新信息。
- 查看探索的数据栏的 SQL 标签页中的注释。在这种情况下，注释将表明 PDT 已递增。例如：-- increment persistent derived table e_incremental_pdt to generation 2
验证 PDT 是否已构建并正确递增后，如果您不想保留 PDT 的专用探索，可以从模型文件中移除或注释掉 PDT 的 explore 和 include 参数。

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

排查增量 PDT 问题

本部分介绍了使用增量 PDT 时可能会遇到的一些常见问题，以及排查和解决这些问题的步骤。

在架构更改后，增量 PDT 构建失败

如果您的增量 PDT 是基于 SQL 的派生表，并且 sql 参数包含通配符（例如 SELECT *），那么底层数据库架构的更改（例如添加列、移除列或更改列数据类型）可能会导致 PDT 失败，并显示以下错误：

SQL Error in incremental PDT: Query execution failed

如需解决此问题，请修改 sql 参数中的 SELECT 语句，改为选择各个列。例如，如果您的 SELECT 子句是 SELECT *，请将其更改为 SELECT column1, column2, ...。

如果您的架构发生变化，并且您想从头开始重建增量 PDT，请使用 API 调用 start_pdt_build，并添加 full_force_incremental 参数。

增量 PDT 支持的数据库方言

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

下表显示了 Looker 最新版本中哪些方言支持增量 PDT（对于 Databricks，仅在 Databricks 版本 12.1 及更高版本中支持增量 PDT）：

方言	是否支持？
Actian Avalanche	否
Amazon Athena	否
Amazon Aurora MySQL	否
Amazon Redshift	是
Amazon Redshift 2.1+	是
Amazon Redshift Serverless 2.1+	是
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+ with Native Driver	否
Cloudera Impala with Native Driver	否
DataVirtuality	否
Databricks	是
Denodo 7	否
Denodo 8 & 9	否
Dremio	否
Dremio 11+	否
Exasol	否
Firebolt	否
Google BigQuery Legacy SQL	否
Google BigQuery Standard 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+	是
PostgreSQL pre-9.5	是
PrestoDB	否
PrestoSQL	否
SAP HANA	否
SAP HANA 2+	否
SingleStore	否
SingleStore 7+	否
Snowflake	是
Teradata	否
Trino	否
Vector	否
Vertica	是

增量 PDT 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

定义增量 PDT

增量参数与持久性策略的互动

示例 1

示例 2

示例 3

在开发模式下测试增量 PDT

排查增量 PDT 问题

在架构更改后，增量 PDT 构建失败

增量 PDT 支持的数据库方言

增量 PDT