增量 PDT

在 Looker 中，永久衍生資料表 (PDT) 會寫入資料庫的暫存結構定義。Looker 會根據持續性策略保留並重建 PDT。根據預設，當系統觸發 PDT 重建作業時，Looker 會重建整個資料表。

累加型 PDT 是指 Looker 將新資料附加至資料表，而非重新建構整個資料表：

大型表格，底部三列醒目顯示，表示表格新增少量資料列。

如果方言支援增量 PDT，您可以將下列類型的 PDT 轉換為增量 PDT：

首次對永久累加型 PDT 執行查詢時，Looker 會建構整個 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 建立增量。由於 Looker 無法判斷建立準確增量所需的 DDL 陳述式，因此無法使用自訂資料定義語言 (DDL) 陳述式定義衍生資料表。
增量 PDT 的來源資料表必須針對時間查詢進行最佳化。具體來說，用於遞增鍵的時間欄必須採用最佳化策略，例如分割、排序鍵、索引，或是方言支援的任何最佳化策略。強烈建議您最佳化來源資料表，因為每次更新增量資料表時，Looker 都會查詢來源資料表，判斷用於增量鍵的時間型資料欄最新值。如果來源資料表未針對這些查詢進行最佳化，Looker 查詢最新值時可能會耗費大量時間和資源。

定義增量 PDT

您可以使用下列參數，將 PDT 設為累加 PDT：

increment_key (將 PDT 設為增量 PDT 時必須使用)：定義應查詢新記錄的時間範圍。
{% incrementcondition %} Liquid 篩選器 (將以 SQL 為基礎的衍生資料表設為永久累加型衍生資料表時必須使用，不適用於以 LookML 為基礎的衍生資料表)：將遞增鍵連結至遞增鍵所依據的資料庫時間資料欄。詳情請參閱 increment_key 說明文件頁面。
increment_offset (選用)：整數，定義每個增量建構作業重建的前幾個時間週期數 (以增量鍵的精細度為準)。如果資料延遲抵達，導致先前時間範圍內有新資料，但這些資料在最初建構並附加至 PDT 時未納入，這時 increment_offset 參數就很有用。

如要查看範例，瞭解如何從永久原生衍生資料表、永久 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 建構工具不會修改遞增 PDT。
當 PDT 遞增時，PDT 建構工具會根據最新的時間增量 (由 increment_key 參數定義的時間範圍)，判斷先前將最新資料新增至資料表的時間。據此，PDT 建構工具會將資料截斷至資料表最近時間增量的開頭，然後從該處建構最新增量。
如果 PDT 含有 increment_offset 參數，PDT 建構工具也會重建 increment_offset 參數中指定的先前時間範圍數量。系統會從最新時間增量 (由 increment_key 參數定義的時間範圍) 的開頭開始，回溯先前的時間範圍。

下列範例情境說明永久累加型衍生資料表的更新方式，並顯示 increment_key、increment_offset 和持續性策略的互動。

範例 1

本範例使用的 PDT 具有下列屬性：

增量索引鍵：日期
增量偏移：3
持續性策略：每月觸發一次，時間為每月第一天

這份表格的更新方式如下：

每月保存策略是指系統每月會自動建構一次資料表。也就是說，舉例來說，如果今天是 6 月 1 日，表格的最後一列會在 5 月 1 日新增。
由於這個 PDT 的增量鍵是以日期為準，PDT 產生器會將 5 月 1 日截斷至當天開頭，並重建 5 月 1 日至 6 月 1 日 (當天) 的資料。
此外，這個永久累加型衍生資料表的遞增偏移量為 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 的運作方式。

6 月 1 日起，這份表格的更新方式如下：

每日持續性策略是指系統每天會自動建構資料表一次。舉例來說，如果今天是 6 月 1 日，表格的最後一列會在 5 月 31 日新增。
由於增量鍵是以月份為準，PDT 建構工具會從 5 月 31 日截斷，回溯至當月初，並重建 5 月和當月 (包括 6 月 1 日) 的所有資料。
此外，這個永久累加型衍生資料表的遞增偏移量為 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 建立探索：
- 在相關聯的模型檔案中，使用 include 參數將 PDT 的檢視檔案納入模型檔案。
- 在同一個模型檔案中，使用 explore 參數為累加 PDT 的檢視畫面建立 Explore。
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
開啟 PDT 的「探索」。如要執行這項操作，請選取「查看檔案動作」按鈕，然後選取「探索」名稱。

在「探索」中選取維度或指標，然後按一下「執行」。Looker 隨即會建構整個 PDT。如果您是第一次對永久累加型衍生資料表執行查詢，衍生資料表建構工具會建構整個衍生資料表，以取得初始資料。如果資料表很大，初始建構作業可能需要相當長的時間，建構任何大型資料表都是如此。
您可以透過下列方式確認是否已建構初始 PDT：
- 如果您擁有 see_logs 權限，可以查看 PDT 事件記錄，確認表格是否已建構完成。如果 PDT 事件記錄檔中未顯示 PDT 建立事件，請檢查 PDT 事件記錄檔探索頁面頂端的狀態資訊。如果顯示「來自快取」，請選取「清除快取並重新整理」，即可取得最新資訊。
- 否則，您可以在 Explore 的「資料」列中，查看「SQL」分頁中的註解。「SQL」分頁會顯示查詢，以及在探索中執行查詢時採取的動作。舉例來說，如果「SQL」分頁中的註解顯示 -- generate derived table e_incremental_pdt，表示點選「執行」後會執行這項動作。
建立 PDT 的初始建構版本後，請使用「探索」中的「重新建立衍生資料表並執行」選項，提示 PDT 的累加建構版本。
您可以採用與先前相同的方法，驗證 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 column1, column2, ...。

如果結構定義有所變更，且您想從頭重建增量 PDT，請使用 API 呼叫 start_pdt_build，並加入 full_force_incremental 參數。

支援永久累加型衍生資料表的資料庫方言

如要讓 Looker 專案支援累加 PDT，資料庫方言必須支援可刪除及插入資料列的資料定義語言 (DDL) 指令。

下表列出最新版 Looker 中支援永久累加型衍生資料表的方言 (Databricks 僅支援 Databricks 12.1 以上版本)：

方言	是否支援？
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
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