增量 PDT

在 Looker 中，永久衍生資料表 (PDT) 會寫入資料庫的暫存結構定義。Looker 會根據持久化策略，儲存及重建 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。如果 PDT 使用 persist_for 持久化策略，則不支援增量 PDT。
• 針對以 SQL 為基礎的 PDT，您必須使用 sql 參數定義資料表查詢，才能用於做為遞增式 PDT。使用 sql_create 參數或 create_process 參數定義的 SQL 資料集無法逐步建構。如您在本頁的範例 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 (選用)：整數，定義每個增量版本重建的先前時間週期數量 (以增量鍵的精細程度為準)。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 timeframe。(如要瞭解維度群組的運作方式，請參閱 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 何時增加。除非表格的持久化策略已觸發，或是透過「探索」中的Rebuild Derived Tables & Run 選項手動觸發 PDT，否則 PDT 建構工具不會修改遞增式 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：

• 保留策略：每天觸發一次
• 增量索引鍵：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，且有三個月的偏移。也就是說，每天都會重建至少三個月的資料，這會導致遞增式 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 的檢視畫面建立 Explore。

    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 建立事件，請檢查「探索」畫面頂端的狀態資訊。如果畫面顯示「從快取」，您可以選取「清除快取並重新整理」，取得較新的資訊。
   • 或者，您也可以在「探索」的「資料」列的「SQL」分頁中查看留言。「SQL」SQL分頁會顯示查詢，以及在 Explore 中執行查詢時會採取的動作。舉例來說，如果「SQL」分頁中的註解顯示 -- generate derived table e_incremental_pdt，表示您按一下「執行」時，系統會執行這項操作。

3. 建立 PDT 的初始版本後，請使用「探索」中的重新建立衍生資料表並執行選項，提示 PDT 的漸進式版本。

4. 您可以使用與先前相同的方法，驗證 PDT 是否以逐步方式建構：

   • 如果您具備 see_logs 權限，就可以使用 PDT 事件記錄檔查看增量 PDT 的 create increment complete 事件。如果您在 PDT 事件記錄中找不到這項事件，且查詢狀態顯示「來自快取」，請選取「清除快取並重新整理」，取得最新資訊。
   • 查看「探索」資料列的「SQL」分頁中的註解。在這種情況下，註解會指出 PDT 已增加。例如：-- increment persistent derived table e_incremental_pdt to generation 2

5. 確認 PDT 已正確建構及遞增後，如果您不想保留專屬的 Explore 資料，可以從模型檔案中移除或註解 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 參數。

增量 PDT 支援的資料庫方言

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

下表列出 Looker 最新版本支援增量 PDT 的方言 (針對 Databricks，增量 PDT 僅支援 Databricks 12.1 以上版本)：