增量 PDT

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

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

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

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

您首次对增量 PDT 运行查询时，Looker 会构建整个 PDT 来获取初始数据。如果这个表较大，与构建任何大型表一样，初始构建可能需要大量时间。如果策略性地设置了增量 PDT，那么构建初始表后，后续 build 将采用增量方式，用时将会更短。

对于增量 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 的源表。具体而言，用于增量键的基于时间的列必须具有优化策略，例如 Partitioning、sortkeys、indexes，或您的方言支持的任何优化策略。强烈建议优化源表，因为每次更新增量表时，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）中定义。下面是 departure 维度组在 flights 视图文件中的定义方式：

...
  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：

• 递增键：日期
• 增量偏移：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，并相隔三个月。这意味着每天至少会重新构建三个月的数据，使用增量 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，请执行以下操作：

1. 为 PDT 创建探索：

   • 在关联的模型文件中，使用 include 参数将 PDT 的视图文件包含在模型文件中。
   • 在同一模型文件中，使用 explore 参数为增量 PDT 视图创建探索。

    include: "/views/e_faa_pdt.view"
    explore: e_faa_pdt {}
   

2. 打开 PDT 的“探索”。为此，请选择查看文件操作按钮，然后选择“探索”名称。

1. 在“探索”中，选择一些维度或测量，然后点击运行。然后，Looker 将构建整个 PDT。如果这是您对增量 PDT 运行的第一个查询，则 PDT 构建器将构建整个 PDT 以获取初始数据。如果这个表较大，与构建任何大型表一样，初始构建可能需要大量时间。

2. 您可以通过以下方式验证是否构建了初始 PDT：

   • 如果您拥有 see_logs 权限，则可以通过查看 PDT 事件日志来验证该表是否已构建。如果您在 PDT 事件日志中未看到 PDT 创建事件，请查看 PDT 事件日志浏览顶部的状态信息。如果显示“从缓存中”，您可以选择清除缓存并刷新以获取最新信息。
   • 如果没有，您可以在探索数据栏的 SQL 标签页中查看注释。SQL 标签页会显示该查询以及在“探索”中运行查询时将要执行的操作。例如，如果 SQL 标签页中的注释显示 -- generate derived table e_incremental_pdt，那么系统将在您点击运行后执行的操作。

3. 创建 PDT 的初始 build 后，使用“探索”中的 Rebuild Derived Tables & Run（重新构建派生表和运行）选项提示 PDT 的增量 build。

4. 您可以使用与之前相同的方法验证 PDT 是否以增量方式构建：

   • 如果您拥有 see_logs 权限，则可以使用 PDT 事件日志来查看增量 PDT 的 create increment complete 事件。如果您在 PDT 事件日志中没有看到此事件，并且查询状态显示为“来自缓存”，请选择清除缓存并刷新以获取最新信息。
   • 查看“探索”数据栏的 SQL 标签页中的注释。在这种情况下，注释表示 PDT 已递增。例如：-- increment persistent derived table e_incremental_pdt to generation 2

5. 确认 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	是
迪诺多 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	是