Looker 中的衍生資料表

在 Looker 中，衍生資料表是指查詢結果的使用方式，就好像查詢是資料庫中的實際資料表一樣。

舉例來說，您可能有一個名為 orders 的資料庫資料表，其中包含許多欄位。您想計算一些客戶層級的匯總指標，例如每位客戶下了多少訂單，或是每位客戶首次下單的時間。您可以使用原生衍生資料表或以 SQL 為基礎的衍生資料表，建立名為 customer_order_summary 的新資料庫資料表，其中包含這些指標。

接著，您就可以像使用資料庫中的任何其他資料表一樣，使用 customer_order_summary 衍生資料表。

如要瞭解衍生表格的熱門用途，請參閱 Looker 食譜：充分運用 Looker 中的衍生表格。

原生衍生資料表和以 SQL 為基礎的衍生資料表

如要在 Looker 專案中建立衍生資料表，請使用 view 參數下的 derived_table 參數。在 derived_table 參數中，您可以透過下列任一方式定義衍生資料表的查詢：

• 針對原生衍生資料表，您可以使用以 LookML 為基礎的查詢定義衍生資料表。
• 對於以 SQL 為基礎的衍生資料表，您可以使用 SQL 查詢定義衍生資料表。

舉例來說，下列檢視表檔案說明如何使用 LookML 從 customer_order_summary 衍生資料表建立檢視表。這兩個版本的 LookML 說明如何使用 LookML 或 SQL 定義衍生表的查詢，藉此建立等同的衍生表：

• 原生衍生資料表會在 explore_source 參數中定義使用 LookML 的查詢。在這個範例中，查詢會根據現有的 orders 檢視畫面，該檢視畫面是在這個範例中未顯示的獨立檔案中定義。原生衍生資料表中的 explore_source 查詢會從 orders 檢視檔案中擷取 customer_id、first_order 和 total_amount 欄位。
• 以 SQL 為基礎的衍生資料表會在 sql 參數中使用 SQL 定義查詢。在這個範例中，SQL 查詢是資料庫中 orders 資料表的直接查詢。

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

兩個版本都會建立名為 customer_order_summary 的檢視畫面，該檢視畫面會根據 orders 資料表建立，並包含 customer_id、first_order, 和 total_amount 資料欄。

除了 derived_table 參數及其子參數外，這個 customer_order_summary 檢視畫面與其他檢視畫面檔案的運作方式相同。無論您是使用 LookML 還是 SQL 定義衍生資料表的查詢，都可以建立以衍生資料表的欄為基礎的 LookML 指標和維度。

定義衍生資料表後，就可以像使用資料庫中的其他資料表一樣使用衍生資料表。

原生衍生資料表

原生衍生資料表是根據您使用 LookML 字詞定義的查詢建立。如要建立原生衍生資料表，請使用 view 參數的 derived_table 參數內的 explore_source 參數。您可以參照模型中的 LookML 維度或指標，建立原生衍生資料表的欄位。請參閱前一個範例中的原生衍生表格檢視檔案。

與以 SQL 為基礎的衍生資料表相比，原生衍生資料表在建構資料模型時，更容易閱讀及理解。

如要進一步瞭解如何建立原生衍生資料表，請參閱「建立原生衍生資料表」說明文件。

以 SQL 為基礎的衍生資料表

如要建立以 SQL 為基礎的衍生資料表，您必須使用 SQL 術語定義查詢，並使用 SQL 查詢在資料表中建立資料欄。您無法在以 SQL 為基礎的衍生資料表中參照 LookML 維度和測量指標。請參閱前述範例中以 SQL 為基礎的衍生資料表檢視檔案。

通常，您會使用 view 參數的 derived_table 參數內的 sql 參數，定義 SQL 查詢。

在 Looker 中建立 SQL 查詢時，可以使用SQL Runner 建立 SQL 查詢，並將其轉換為衍生資料表定義，這會是相當實用的捷徑。

在某些極端情況下，系統將不允許使用 sql 參數。在這種情況下，Looker 支援下列參數，可為持久衍生資料表 (PDT) 定義 SQL 查詢：

• create_process：當您為 PDT 使用 sql 參數時，Looker 會在背景中將方言的 CREATE TABLE 資料定義語言 (DDL) 陳述式包裝在查詢中，以便從 SQL 查詢建立 PDT。部分方言不支援單步驟 SQL CREATE TABLE 陳述式。對於這些方言，您無法使用 sql 參數建立 PDT。您可以改用 create_process 參數，以多個步驟建立 PDT。如需相關資訊和範例，請參閱 create_process 參數說明文件頁面。
• sql_create：如果用途需要自訂 DDL 指令，且方言支援 DDL (例如 Google 預測 BigQuery ML)，您可以使用 sql_create 參數建立 PDT，而非使用 sql 參數。如需相關資訊和範例，請參閱 sql_create 說明文件頁面。

無論您使用 sql、create_process 或 sql_create 參數，在所有這些情況下，您都會使用 SQL 查詢定義衍生資料表，因此這些都視為以 SQL 為基礎的衍生資料表。

定義以 SQL 為基礎的衍生資料表時，請務必使用 AS 為每個資料欄指定乾淨的別名。這是因為您需要在維度中參照結果集的欄名稱，例如 ${TABLE}.first_order。因此前一個範例使用 MIN(DATE(time)) AS first_order，而非單純的 MIN(DATE(time))。

臨時性與永久性衍生資料表

除了原生衍生資料表和以 SQL 為基礎的衍生資料表之間的差異之外，暫時衍生資料表 (不會寫入資料庫) 和永久衍生資料表 (PDT) 之間也有差異，後者會寫入資料庫的結構定義。

原生衍生資料表和以 SQL 為基礎的衍生資料表可以是暫時性或永久性。

臨時衍生資料表

先前顯示的衍生資料表是暫時性衍生資料表的範例。由於 derived_table 參數中未定義持久性策略，因此這些值是暫時性的。

臨時衍生資料表不會寫入資料庫。當使用者執行涉及一或多個衍生資料表的探索查詢時，Looker 會使用衍生資料表的 SQL 與所要求的欄位、彙整和篩選值，以特定方言組合方式建構 SQL 查詢。如果先前曾執行過組合查詢，且快取中的結果仍有效，Looker 就會使用快取的結果。如要進一步瞭解 Looker 中的查詢快取功能，請參閱「快取查詢」說明文件頁面。

否則，如果 Looker 無法使用快取結果，每次使用者從臨時衍生資料表要求資料時，Looker 就必須對資料庫執行新查詢。因此，您應確保臨時衍生資料表的效能良好，且不會對資料庫造成過度負擔。如果查詢需要一些時間才能執行，通常建議使用 PDT。

臨時衍生資料表支援的資料庫方言

如要讓 Looker 支援 Looker 專案中的衍生資料表，資料庫方言也必須支援衍生資料表。下表列出最新版本 Looker 中支援衍生資料表的方言：

永久衍生資料表

永久衍生資料表 (PDT) 是一種衍生資料表，會寫入資料庫上的暫存結構定義，並根據您使用持久化策略指定的時間表重新產生。

PDT 可以是原生衍生資料表或以 SQL 為基礎的衍生資料表。

專業開發人員工具的規定

如要在 Looker 專案中使用永久衍生資料表 (PDT)，您需要：

• 支援 PDT 的資料庫方言。如要查看支援以 SQL 為基礎的永久衍生資料表和永久原生衍生資料表的方言清單，請參閱本頁稍後的「支援的 PDT 資料庫方言」一節。

• 資料庫上的暫存結構定義。這可以是資料庫中的任何結構定義，但建議您建立專門用於此用途的新結構定義。資料庫管理員必須為 Looker 資料庫使用者設定具有寫入權限的結構定義。

• 開啟「Enable PDTs」 切換鈕後，所設定的 Looker 連線。這項「啟用 PDT」設定通常會在您初次設定 Looker 連線時進行設定 (請參閱 Looker 方言說明文件，瞭解資料庫方言的操作說明)，但您也可以在初始設定完成後為連線啟用 PDT。

支援的 PDT 資料庫方言

如要讓 Looker 支援 Looker 專案中的 PDT，資料庫方言也必須支援 PDT。

為了支援任何類型的 PDT (基於 LookML 或 SQL)，方言必須支援寫入資料庫，以及其他必要條件。有些唯讀資料庫設定無法讓持久性運作 (最常見的例子是 Postgres 熱插拔備援資料庫)。在這種情況下，您可以改用臨時衍生資料表。

下表列出在最新版本的 Looker 中，支援以 SQL 為基礎的衍生資料表的方言：

為了支援持續性原生衍生資料表 (含有以 LookML 為基礎的查詢)，方言也必須支援 CREATE TABLE DDL 函式。以下是最新版本 Looker 中支援永久原生 (以 LookML 為基礎) 衍生資料表的方言清單：

增量建構 PDT

增量 PDT 是 Looker 建構的持續衍生資料表，其會將新資料附加至資料表，而非重新建構資料表。

如果方言支援增量 PDT，且 PDT 使用的是觸發式持續性策略 (datagroup_trigger、sql_trigger_value 或 interval_trigger)，您可以將 PDT 定義為增量 PDT。

詳情請參閱「增量 PDT」說明文件頁面。

增量 PDT 支援的資料庫方言

如要讓 Looker 支援 Looker 專案中的遞增式 PDT，資料庫方言也必須支援這些資料。下表列出最新版 Looker 中支援增量 PDT 的方言：

建立 PDT

如要將衍生資料表轉換為永久衍生資料表 (PDT)，請為資料表定義持久性策略。如要改善成效，您也應加入最佳化策略。

持久性策略

衍生資料表的持久性可由 Looker 管理，如果是支援物化檢視表的方言，則可由資料庫使用物化檢視表管理。

如要讓衍生表格保持不變，請在 derived_table 定義中新增下列任一參數：

• Looker 管理的持久性參數：
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• 資料庫管理的持續性參數：
  • materialized_view: yes

在使用以觸發事件為依據的持久化策略 (datagroup_trigger、sql_trigger_value 和 interval_trigger) 時，Looker 會在資料庫中保留 PDT，直到 PDT 觸發重建為止。當 PDT 觸發時，Looker 會重新建構 PDT 以取代舊版。也就是說，使用者在使用觸發條件式 PDT 時，不必等待 PDT 建構完成，就能從 PDT 取得探索查詢的答案。

datagroup_trigger

Datagroups 是建立持久性最具彈性的方法。如果您已使用 sql_trigger 或 interval_trigger 定義datagroup，可以使用 datagroup_trigger 參數，啟動重新建構持久衍生資料表 (PDT) 的程序。

Looker 會在資料群組觸發前，在資料庫中保留 PDT。觸發資料群組後，Looker 會重建 PDT 取代先前版本。也就是說，在大多數情況下，使用者不必等待 PDT 建構完成。如果使用者在 PDT 建構期間要求資料，且查詢結果不在快取中，Looker 會傳回現有 PDT 的資料，直到新 PDT 建構完成為止。如要瞭解資料群組的概略說明，請參閱「快取查詢」。

如要進一步瞭解再生器如何建構 PDT，請參閱「Looker 再生器」一節。

sql_trigger_value

sql_trigger_value 參數會觸發永久衍生資料表 (PDT) 的重新產生作業，該資料表會根據您提供的 SQL 陳述式進行產生。如果 SQL 陳述式的結果與先前的值不同，系統會重新產生 PDT。否則，資料庫會保留現有的 PDT。也就是說，在大多數情況下，使用者不必等待 PDT 建構完成。如果使用者在 PDT 建構期間要求資料，且查詢結果不在快取中，Looker 會傳回現有 PDT 的資料，直到新 PDT 建構完成為止。

如要進一步瞭解再生器如何建構 PDT，請參閱「Looker 再生器」一節。

interval_trigger

interval_trigger 參數會根據您提供的時間間隔 (例如 "24 hours" 或 "60 minutes")，觸發永久衍生資料表 (PDT) 的再生作業。與 sql_trigger 參數類似，這表示系統通常會在使用者查詢時預先建構 PDT。如果使用者在 PDT 建構期間要求資料，且查詢結果不在快取中，Looker 會傳回現有 PDT 的資料，直到新 PDT 建構完成為止。

persist_for

另一個選項是使用 persist_for 參數，設定衍生表格應儲存多久才標示為過期，這樣衍生表格就不會再用於查詢，並從資料庫中刪除。

使用者首次對其執行查詢時，系統會建立 persist_for 持久衍生資料表 (PDT)。接著，Looker 會在資料庫中保留 PDT，時間長度為 PDT 的 persist_for 參數中指定的時間長度。如果使用者在 persist_for 時間內查詢 PDT，Looker 會盡可能使用快取結果，否則會在 PDT 上執行查詢。

在 persist_for 時間過後，Looker 會從資料庫中清除 PDT，並在下次使用者查詢時重建 PDT，這表示查詢必須等待重建作業完成。

使用 persist_for 的 PDT 不會由 Looker 再生器自動重建，除非 PDT 有依附元件 連結。如果 persist_for 資料表是依賴連鎖中以觸發事件為基礎的 PDT (使用 datagroup_trigger、interval_trigger 或 sql_trigger_value 持續性策略的 PDT)，重新產生器會監控並重新建構 persist_for 資料表，以便重新建構連鎖中的其他資料表。請參閱本頁面的「Looker 如何建立階層式衍生資料表」一節。

materialized_view: yes

您可以使用資料庫的功能，透過具象化檢視畫面，在 Looker 專案中持續衍生資料表。如果資料庫方言支援具象化檢視畫面，且Looker 連線已設定為開啟「啟用 PDT」 切換鈕，您就可以為衍生資料表指定 materialized_view: yes，藉此建立具象化檢視畫面。具體化檢視表支援原生衍生資料表和以 SQL 為基礎的衍生資料表。

與永久衍生資料表 (PDT) 類似，具體化檢視畫面是將查詢結果儲存在資料庫的暫存結構定義中。PDT 和具象化檢視畫面的主要差異在於資料表的重新整理方式：

• 對於 PDT，持久化策略是在 Looker 中定義，而持久化則由 Looker 管理。
• 對於已實體化的檢視表，資料庫會負責維護及重新整理表格中的資料。

因此，要使用具象化檢視功能，您必須具備所用方言及其功能的進階知識。在大多數情況下，資料庫在偵測到查詢的資料表中出現新資料時，就會重新整理實體檢視畫面。具體化檢視表最適合需要即時資料的情況。

如要瞭解方言支援、需求和重要考量事項，請參閱 materialized_view 參數說明文件頁面。

最佳化策略

由於永久衍生資料表 (PDT) 會儲存在資料庫中，因此您應使用下列策略 (視方言支援情況而定) 來最佳化 PDT：

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

舉例來說，如要為衍生資料表範例新增持久性，您可以將其設為在資料群組 orders_datagroup 觸發時重建，並在 customer_id 和 first_order 上新增索引，如下所示：

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

如果您未新增索引 (或相應的方言)，Looker 會警告您應新增索引，以改善查詢效能。

PDT 的用途

持續衍生資料表 (PDT) 非常實用，因為它們可在資料表中保留查詢結果，進而提高查詢效能。

一般最佳做法是，開發人員應盡量避免使用 PDT 建立資料模型，除非有必要。

在某些情況下，您可以透過其他方式進行資料最佳化。舉例來說，新增索引或變更資料欄的資料類型，可能就能解決問題，而不需要建立 PDT。請務必使用 SQL Runner 工具中的說明，分析執行速度緩慢的查詢。

除了減少經常執行查詢的查詢時間和資料庫負載外，PDT 還有其他用途，包括：

• 測試最佳化
• 預先彙整或匯入資料

如果沒有合理的方法，無法將資料表中的唯一資料列識別為主鍵，您也可以使用 PDT 定義主鍵。

使用 PDT 測試最佳化

您可以使用 PDT 測試不同的索引、分發和其他最佳化選項，而不需要 DBA 或 ETL 開發人員提供大量支援。

假設您有一個資料表，但想測試不同的索引。您為檢視畫面建立的初始 LookML 可能會如下所示：

view: customer {
  sql_table_name: warehouse.customer ;;
}

如要測試最佳化策略，您可以使用 indexes 參數，在 LookML 中新增索引，如下所示：

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

查詢檢視一次，即可產生 PDT。然後執行測試查詢並比較結果。如果結果良好，您可以請資料庫管理員或 ETL 團隊在原始資料表中加入索引。

請記得將檢視畫面程式碼改回，以移除 PDT。

使用 PDT 預先彙整或匯總資料

針對大量或多種類型的資料，預先彙整或匯入資料，有助於調整查詢最佳化。

舉例來說，假設您想根據客戶首次下單的時間，為同類群組建立查詢。每次需要即時資料時，這項查詢的執行成本可能會很高；不過，您可以只計算一次查詢，然後使用 PDT 重複使用結果：

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

階層式衍生資料表

您可以在另一個衍生資料表的定義中參照一個衍生資料表，藉此建立一連串的層疊衍生資料表，或視情況建立層疊持續衍生資料表 (PDT)。以資料表 TABLE_D 為例，它會依賴另一個資料表 TABLE_C，而 TABLE_C 會依賴 TABLE_B，而 TABLE_B 會依賴 TABLE_A，這就是資料表層疊衍生表格的例子。

參照衍生資料表的語法

如要在另一個衍生資料表中參照衍生資料表，請使用下列語法：

`${derived_table_or_view_name.SQL_TABLE_NAME}`

在這個格式中，SQL_TABLE_NAME 是常值字串。例如，您可以使用下列語法參照 clean_events 衍生表格：

`${clean_events.SQL_TABLE_NAME}`

您可以使用相同的語法參照 LookML 檢視畫面。同樣地，在本例中，SQL_TABLE_NAME 是常值字串。

在下一個範例中，系統會根據資料庫中的 events 資料表建立 clean_events PDT。clean_events PDT 會從 events 資料庫表格中排除不必要的資料列。接著會顯示第二個 PDT，event_summary PDT 是 clean_events PDT 的摘要。只要 clean_events 新增資料列，event_summary 資料表就會重新產生。

event_summary PDT 和 clean_events PDT 是遞迴 PDT，其中 event_summary 依附於 clean_events (因為 event_summary 是使用 clean_events PDT 定義)。這個特定範例可在單一 PDT 中更有效率地完成，但用於說明衍生表格參照時相當實用。

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

雖然不一定需要，但如果您要以這種方式參照衍生資料表，通常會使用以下格式為資料表建立別名：

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

上一個範例會執行以下操作：

${clean_events.SQL_TABLE_NAME} AS clean_events

使用別名很有幫助，因為在幕後，資料庫中的 PDT 名稱會使用冗長的代碼。在某些情況下 (尤其是使用 ON 子句時)，很容易忘記需要使用 ${derived_table_or_view_name.SQL_TABLE_NAME} 語法來擷取這個長名稱。使用別名有助於避免這類錯誤。

Looker 如何建立階層式衍生資料表

如果是階層式衍生資料表，如果使用者的查詢結果不在快取中，Looker 會建立查詢所需的所有衍生資料表。如果您有 TABLE_D，且其定義包含 TABLE_C 的參照，則 TABLE_D 會依附 TABLE_C。也就是說，如果您查詢 TABLE_D，而查詢不在 Looker 的快取中，Looker 就會重建 TABLE_D。但首先，它必須重新建構 TABLE_C。

請考慮使用階層式暫時衍生資料表的情況，其中 TABLE_D 依附 TABLE_C，而 TABLE_C 依附 TABLE_B，而 TABLE_B 依附 TABLE_A。如果 Looker 在快取中沒有 TABLE_C 查詢的有效結果，就會建構查詢所需的所有資料表。因此 Looker 會依序建構 TABLE_A、TABLE_B 和 TABLE_C：

在這種情況下，TABLE_A 必須先完成產生作業，Looker 才能開始產生 TABLE_B，而 TABLE_B 也必須先完成產生作業，Looker 才能開始產生 TABLE_C。TABLE_C 完成後，Looker 會提供查詢結果。(由於 TABLE_D 不需要回答這個查詢，Looker 目前不會重建 TABLE_D)。

如需使用相同資料群組的遞迴 PDT 示例情境，請參閱 datagroup 參數說明文件頁面。

同樣的基本邏輯也適用於 PDT：Looker 會建立任何需要回答查詢的資料表，一直到依附元件鏈結的頂端。但在 PDT 中，表格通常已存在，因此不需要重建。在標準使用者查詢階層式 PDT 時，Looker 只會在資料庫中沒有有效的 PDT 版本時，才重新建構階層式 PDT。如要強制重新建立分層中的所有 PDT，您可以透過探索手動重新建立查詢的資料表。

請務必瞭解一個重要的邏輯概念：在 PDT 分層的情況下，依附的 PDT 基本上會查詢所依附的 PDT。這對使用 persist_for 策略的 PDT 特別重要。通常，persist_for PDT 會在使用者查詢時建立，並在 persist_for 間隔結束前留在資料庫中，然後在下次使用者查詢時才重新建立。不過，如果 persist_for PDT 是與以觸發事件為基礎的 PDT (使用 datagroup_trigger、interval_trigger 或 sql_trigger_value 持久化策略的 PDT) 一起建立的層疊式結構，則每次重建其依附的 PDT 時，系統都會查詢 persist_for PDT。因此，在這種情況下，系統會根據依附的 PDT 時間表，重新建構 persist_for PDT。也就是說，persist_for PDT 可能會受到其依附項目的持久性策略影響。

手動重建查詢的永久資料表

使用者可以從「探索」選單中選取「Rebuild Derived Tables & Run」選項，覆寫持久性設定，並重新建立「探索」中目前查詢所需的所有永久衍生資料表 (PDT) 和匯總資料表：

只有具備 develop 權限的使用者，且在「探索」查詢載入後，才能看到這個選項。

無論持久化策略為何，重建衍生資料表並執行選項都會重建所有用於回答查詢的持久化資料表 (所有 PDT 和匯總資料表)。這包括目前查詢中的任何匯總資料表和 PDT，也包括目前查詢中的匯總資料表和 PDT 參照的任何匯總資料表和 PDT。

在增量 PDT 的情況下，重建衍生資料表並執行選項會觸發新增量版本的建構作業。在遞增式 PDT 中，遞增項目包含 increment_key 參數中指定的時間範圍，以及 increment_offset 參數中指定的先前時間範圍數量 (如果有)。請參閱「增量 PDT」說明文件頁面，瞭解增量 PDT 如何根據設定建構。

在層疊式 PDT 的情況下，這表示從頂端開始重建層疊中的所有衍生資料表。這與您在臨時衍生資料表的層疊結構中查詢資料表的行為相同：

請注意下列衍生資料表的手動重建作業：

• 對於發起「重建衍生資料表並執行」作業的使用者，查詢會等待資料表重建完成，再載入結果。其他使用者的查詢仍會使用現有資料表。一旦重新建構了永久資料表，所有使用者都會使用重新建構的資料表。雖然這個程序旨在避免在重建資料表時中斷其他使用者的查詢，但這些使用者仍可能受到資料庫額外負載的影響。如果在營業時間內觸發重建作業會對資料庫造成過大的負擔，您可能需要告知使用者，在營業時間內絕對不要重建特定 PDT 或匯總表格。

• 如果使用者處於開發模式，且探索是根據開發資料表建立，則「重新建立衍生資料表並執行」作業會為探索重新建立開發資料表，而非正式環境資料表。但如果開發模式中的「探索」使用衍生資料表的正式版，系統會重新建立正式版資料表。如要瞭解開發資料表和正式資料表，請參閱「開發模式中的已儲存資料表」一文。

• 對於由 Looker 代管的執行個體，如果衍生表格重建時間超過一小時，則無法順利重建表格，瀏覽器工作階段就會逾時。如要進一步瞭解可能影響 Looker 程序的逾時問題，請參閱「管理員設定 - 查詢」說明文件頁面中的「查詢逾時和佇列」部分。

開發模式中的永久性資料表

Looker 在開發模式中提供一些特殊行為，用於管理已儲存的資料表。

如果您在開發模式中查詢已儲存的資料表，但未對其定義進行任何變更，Looker 就會查詢該資料表的正式版本。如果您會變更資料表定義，進而影響資料表中的資料或查詢資料表的方式，則系統會在您下次以開發模式查詢資料表時，建立資料表的新開發版本。有了這類開發表格，您就能在不干擾使用者的情況下測試變更。

促使 Looker 建立開發資料表的因素

無論您是否處於開發模式，Looker 都會盡可能使用現有的正式版資料表來回答查詢。不過，在某些情況下，Looker 無法在開發模式中使用正式版資料表進行查詢：

• 如果持久化表格含有參數，可縮小資料集範圍，以便在開發模式下加快運作
• 如果您變更了已儲存資料表的定義，而這會影響表格中的資料

如果您處於開發模式，且查詢的以 SQL 為基礎的衍生資料表是使用含有 if prod 和 if dev 陳述式的條件式 WHERE 子句定義，Looker 就會建立開發資料表。

如果是已儲存的資料表，且沒有用於在開發模式中縮小資料集的參數，Looker 會使用實際工作環境版本的資料表來回答開發模式中的查詢，除非您變更資料表定義，並接著在開發模式中查詢資料表。這適用於任何會影響資料表中資料或資料表查詢方式的變更。

以下列舉一些會促使 Looker 建立永久資料表開發版本的變更類型 (Looker 只會在您變更後隨後查詢資料表時建立資料表)：

• 變更持久性資料表所依據的查詢，例如修改持久性資料表本身或任何必要資料表 (在級聯衍生資料表的情況下) 中的 explore_source、sql、query、sql_create 或 create_process 參數
• 變更資料表的持久化策略，例如修改資料表的 datagroup_trigger、sql_trigger_value、interval_trigger 或 persist_for 參數
• 變更衍生資料表的 view 名稱
• 變更增量 PDT 的 increment_key 或 increment_offset
• 變更關聯模型使用的 connection

如果變更不會修改資料表的資料，或影響 Looker 查詢資料表的方式，Looker 就不會建立開發資料表。publish_as_db_view 參數就是很好的例子：在開發模式中，如果您只變更衍生資料表的 publish_as_db_view 設定，Looker 就不需要重建衍生資料表，因此不會建立開發資料表。

Looker 會保留開發資料表多久

無論資料表的實際持久化策略為何，Looker 都會將開發持續性資料表視為具有 persist_for: "24 hours" 的持久化策略。Looker 會這麼做，是為了確保開發資料表不會保留超過一天，因為 Looker 開發人員在開發期間可能會查詢資料表的許多疊代，而且每次建立新開發資料表時，都會執行這項操作。為避免開發資料表造成資料庫雜亂，Looker 會套用 persist_for: "24 hours" 策略，確保資料庫經常清除資料表。

否則，Looker 會在開發模式中建立持續衍生資料表 (PDT) 和匯總資料表，這與在正式環境模式中建立持續資料表的方式相同。

如果您在部署 PDT 或匯總資料表的變更時，在資料庫中保留開發資料表，Looker 通常會將開發資料表用作正式環境資料表，這樣使用者在查詢資料表時，就不會需要等待資料表建構完成。

請注意，在部署變更時，您可能仍需要重建資料表，才能在實際環境中進行查詢，具體情況如下：

• 如果您在開發模式下查詢資料表的時間已超過 24 小時，資料表的開發版本就會標示為已過期，且不會用於查詢。您可以使用 Looker IDE，或使用「持久性衍生資料表」頁面的「開發」分頁，查看是否有未建構的 PDT。如果您有未建構的 PDT，可以在變更前透過開發模式查詢，讓開發資料表可在正式環境中使用。
• 如果已儲存的資料表含有 dev_filters 參數 (適用於原生衍生資料表)，或是使用 if prod 和 if dev 陳述式的條件式 WHERE 子句 (適用於以 SQL 為基礎的衍生資料表)，則開發版資料表含有簡略資料集，因此無法用於正式版。在這種情況下，您可以先在完成資料表開發作業後，再部署變更，然後將 dev_filters 參數或條件式 WHERE 子句註解掉，再以開發模式查詢資料表。接著，Looker 會建構完整版本的資料表，以便在您部署變更時用於實際工作環境。

否則，如果您在沒有可用於正式版資料表的有效開發資料表時部署變更，Looker 會在下次以正式版模式查詢資料表時 (針對使用 persist_for 策略的已快取資料表)，或下次執行 regenerator 時 (針對使用 datagroup_trigger、interval_trigger 或 sql_trigger_value 的已快取資料表)，重新建構資料表。

在開發模式中檢查未建構的 PDT

如果您在資料庫中保留開發資料表，並將變更部署至永久衍生資料表 (PDT) 或匯總資料表，Looker 通常會將開發資料表用作正式資料表，這樣使用者在查詢資料表時，就不會需要等待資料表建構完成。詳情請參閱本頁的「Looker 會保留開發資料表多久」和「Looker 會在何種情況下建立開發資料表」兩節。

因此，建議您在部署至正式環境時建立所有 PDT，這樣資料表就能立即用於正式版。

您可以在「Project Health」面板中，查看專案是否有未建構的 PDT。按一下 Looker IDE 中的「Project Health」圖示，開啟「Project Health」面板。然後按一下「驗證 PDT 狀態」按鈕。

如果有未建構的 PDT，專案健康狀況面板會列出這些項目：

如果您具備 see_pdts 權限，可以按一下「前往 PDT 管理」按鈕。Looker 會開啟「Persistent Derived Tables」頁面的「Development」分頁，並將結果篩選為特定 LookML 專案。您可以在這裡查看哪些開發 PDT 已建構或未建構，以及存取其他疑難排解資訊。詳情請參閱「管理員設定 - 永久衍生資料表」說明文件。

在專案中找出未建構的 PDT 後，您可以開啟用於查詢資料表的「探索」頁面，然後在「探索」選單中使用「重新建立衍生資料表並執行」選項，建構開發版本。請參閱本頁的「手動重建查詢的永久表格」一節。

共用和清除資料表

在任何 Looker 例項中，如果資料表具有相同的定義和相同的持久化方法設定，Looker 會在使用者之間共用已儲存的資料表。此外，如果資料表定義不再存在，Looker 會將該資料表標示為已過期。

這麼做有幾個好處：

• 如果您在開發模式中未對資料表進行任何變更，查詢會使用現有的正式版資料表。除非資料表是以 SQL 為基礎的衍生資料表，且定義時使用帶有 if prod 和 if dev 陳述式的條件式 WHERE 子句，否則會發生這種情況。如果資料表是使用條件式 WHERE 子句定義，在開發模式中查詢資料表時，Looker 會建立開發資料表。(如果是使用 dev_filters 參數的原生衍生資料表，Looker 會在開發模式中使用正式環境資料表來回答查詢，除非您變更資料表定義，然後在開發模式中查詢資料表)。
• 如果兩位開發人員在開發模式下對表格進行相同的變更，就會共用相同的開發表格。
• 將變更從開發模式推送至實際工作環境模式後，舊的實際工作環境定義就會消失，因此舊的實際工作環境資料表會標示為已過期，並遭到刪除。
• 如果您決定捨棄開發模式變更，該資料表定義就會消失，因此系統會將不需要的開發資料表標示為已過期，並將其刪除。

在開發模式下加快工作速度

在某些情況下，您建立的永久衍生資料表 (PDT) 可能需要很長的時間才能產生，如果您在開發模式中測試大量變更，這可能會耗費許多時間。在這種情況下，您可以在開發模式下，要求 Looker 建立衍生資料表的較小版本。

針對原生衍生資料表，您可以使用 explore_source 的 dev_filters 子參數，指定只套用至衍生資料表開發版本的篩選器：

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

這個範例包含 dev_filters 參數，可篩選過去 90 天的資料，以及 filters 參數，可篩選過去 2 年內的資料，以及 Yucca Valley Airport。

dev_filters 參數會與 filters 參數搭配運作，將所有篩選器套用至資料表的開發版本。如果 dev_filters 和 filters 都為同一欄指定篩選器，則 dev_filters 會優先套用至表格的開發版本。在這個範例中，表格的開發版本會將資料篩選為 Yucca Valley Airport 的最近 90 天。

針對以 SQL 為基礎的衍生資料表，Looker 支援條件式 WHERE 子句，其中包含正式版 (if prod) 和開發版 (if dev) 資料表的不同選項：

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

在這個範例中，查詢會在實際工作環境模式下納入 2000 年起的所有資料，但在開發模式下只納入 2020 年起的資料。您可以有策略地使用這項功能來限制結果集，並提高查詢速度，這樣就能更輕鬆地驗證開發模式變更。

Looker 建構 PDT 的方式

定義持久化衍生資料表 (PDT) 後，如果是第一次執行，或是由再生器觸發，以便根據持久化策略重建，Looker 會執行下列步驟：

1. 使用衍生資料表 SQL 建立 CREATE TABLE AS SELECT (或 CTAS) 陳述式並執行。例如，如要重新建構名為 customer_orders_facts 的 PDT：CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. 在建立資料表時，發出建立索引的陳述式
3. 將資料表從 LC$.. (「Looker Create」) 重新命名為 LR$.. (「Looker Read」)，表示資料表已可供使用
4. 刪除任何不再使用的舊版資料表

這會帶來幾項重要影響：

• 形成衍生資料表的 SQL 必須在 CTAS 陳述式中有效。
• SELECT 陳述式的結果集資料欄別名必須是有效的資料欄名稱。
• 指定分布、排序鍵和索引時使用的名稱，必須是衍生資料表的 SQL 定義中列出的資料欄名稱，而非 LookML 中定義的欄位名稱。

Looker 再生器

Looker 再生器會檢查狀態，並啟動觸發式永久資料表的重建作業。採用觸發條件的永久資料表是使用觸發條件做為永久化策略的永久衍生資料表 (PDT) 或匯總資料表：

• 對於使用 sql_trigger_value 的資料表，觸發條件是資料表的 sql_trigger_value 參數中指定的查詢。如果最新的觸發查詢檢查結果與先前的觸發查詢檢查結果不同，Looker 再生器就會觸發重建資料表的動作。舉例來說，如果衍生資料表會透過 SQL 查詢 SELECT CURDATE() 持續存在，Looker 再生器會在日期變更後，在下次檢查觸發事件時重建資料表。
• 對於使用 interval_trigger 的資料表，觸發條件是資料表的 interval_trigger 參數中指定的時間長度。在指定時間過後，Looker 再生器會觸發資料表重建作業。
• 如果是使用 datagroup_trigger 的資料表，觸發條件可以是關聯資料群組 sql_trigger 參數中指定的查詢，也可以是資料群組 interval_trigger 參數中指定的時間長度。

Looker 再生器也會針對使用 persist_for 參數的已儲存資料表啟動重建作業，但只有在 persist_for 資料表是觸發已儲存資料表的依附元件 cascade 時才會這樣做。在這種情況下，Looker 再生器會啟動 persist_for 資料表的重建作業，因為該資料表需要重建連鎖中的其他資料表。否則，再生器不會監控使用 persist_for 策略的已儲存資料表。

Looker 再生器週期會在 Looker 管理員在資料庫連線的 維護排程 設定中設定的規則間隔開始 (預設為五分鐘間隔)。不過，Looker 再生工具必須先完成上一個週期的所有檢查和 PDT 重建作業，才能開始新的週期。也就是說，如果您有長時間執行的 PDT 版本，Looker 再生器週期可能不會按照「維護時間表」設定的頻率執行。如本頁「實作已儲存資料表時的重要考量」一節所述，其他因素也可能會影響重建資料表所需的時間。

如果 PDT 建構作業失敗，再生器可能會在下一個再生器週期中嘗試重新建構資料表：

• 如果資料庫連線已啟用「重試失敗的 PDT 建構作業」設定，Looker 再生器會在下一個再生器週期中嘗試重建資料表，即使未符合資料表的觸發條件也一樣。
• 如果停用「Retry Failed PDT Builds」設定，Looker 再生器會等到符合 PDT 的觸發條件，才會嘗試重新建構資料表。

如果使用者在持續性資料表建構期間要求資料表的資料，且查詢結果不在快取中，Looker 會檢查現有資料表是否仍有效。(如果舊資料表與新版資料表不相容，可能會失效。新版資料表的定義不同、使用不同的資料庫連線，或是使用其他版本的 Looker 建立，都可能導致這種情況發生)。如果現有資料表仍有效，Looker 會在建立新資料表前，持續傳回現有資料表的資料。否則，如果現有資料表無效，Looker 會在重建新資料表後提供查詢結果。

實作已儲存表格的重點考量

考量持續性資料表 (PDT 和匯總資料表) 的實用性，您可以輕鬆在 Looker 執行個體上累積大量資料表。您可以建立情境，讓 Looker 再生器需要同時建構多個資料表。特別是對於層疊式資料表或執行時間較長的資料表，您可以建立一種情況，讓資料表重建作業延遲很久，或是在資料庫努力產生資料表時，使用者無法即時從資料表取得查詢結果。

Looker 再生器會檢查 PDT 觸發事件，判斷是否應重新建構觸發事件持續性資料表。再生器週期會以 Looker 管理員在資料庫連線的 維護排程 設定中設定的規則間隔運作 (預設間隔為五分鐘)。

下列幾個因素會影響重建資料表所需的時間：

• Looker 管理員可能已使用資料庫連線的維護排程設定，變更了再生器觸發檢查的間隔。
• Looker 再生器會先完成上一個週期的所有檢查和 PDT 重建作業，才會開始新的週期。因此，如果您有長時間執行的 PDT 版本，Looker 再生器週期可能不會像維護時間表設定那麼頻繁。
• 根據預設，再生器可透過連線，一次重建一個 PDT 或匯總資料表。Looker 管理員可以使用連線設定中的 PDT 建構工具連線數量上限 欄位，調整再生器允許的並行重建作業數量。
• 在同一個再生程序中，所有由相同 datagroup 觸發的 PDT 和匯總資料表都會重新建構。如果有許多資料表直接或透過連鎖依附元件使用資料群組，這可能會造成負載過重。

除了上述考量因素外，在下列情況下，您也應避免在衍生資料表中新增持久性：

• 衍生資料表的擴充時間：每個 PDT 擴充資料表都會在資料庫中建立資料表的新副本。
• 衍生資料表使用範本篩選器或 Liquid 參數時：對於使用範本篩選器或 Liquid 參數的衍生資料表，系統不支援持久性。
• 當原生衍生資料表是從使用 access_filters 或 sql_always_where 的使用者屬性建立的探索中建立時，系統會針對指定的每個使用者屬性值，在資料庫中建立該資料表的複本。
• 當基礎資料經常變更，且資料庫方言不支援增量 PDT 時。
• 建立 PDT 的成本和時間過高。

根據 Looker 連線中已儲存資料表的數量和複雜度，佇列可能會包含許多需要在每個週期檢查及重建的已儲存資料表，因此在 Looker 執行個體上實作衍生資料表時，請務必考量這些因素。

透過 API 大規模管理 PDT

在執行個體中建立更多持續衍生資料表 (PDT) 後，監控及管理以不同時間表進行重新整理的 PDT 會變得越來越複雜。建議您使用 Looker Apache Airflow 整合，搭配其他 ETL 和 ELT 程序管理 PDT 排程。

監控及排解 PDT 問題

如果您使用的是持續衍生資料表 (PDT)，尤其是層疊的 PDT，查看 PDT 狀態會很有幫助。您可以使用 Looker 的「永久衍生資料表」管理員頁面查看 PDT 狀態。詳情請參閱「管理員設定 - 持續衍生表格」說明文件。

嘗試排解 PDT 問題時，請注意下列事項：

• 調查 PDT 事件記錄時，請特別留意開發資料表和正式資料表之間的差異。
• 請確認 Looker 儲存 PDT 的暫存結構定義未經過任何變更。如果已進行變更，您可能需要更新 Looker 管理區段中的「連線」設定，然後重新啟動 Looker，才能恢復正常的 PDT 功能。
• 判斷所有 PDT 是否都有問題，還是只有一個。如果其中一個發生問題，則問題很可能是由 LookML 或 SQL 錯誤造成。
• 判斷 PDT 問題是否與重新建構的時間點相符。
• 請確認所有 sql_trigger_value 查詢都能順利評估，且只傳回一個資料列和資料欄。針對以 SQL 為基礎的 PDT，您可以在 SQL Runner 中執行這些檔案。(套用 LIMIT 可避免查詢失控)。如要進一步瞭解如何使用 SQL Runner 偵錯衍生資料表，請參閱「使用 SQL Runner 測試衍生資料表 」社群文章。
• 針對以 SQL 為基礎的 PDT，請使用 SQL Runner 驗證 PDT 的 SQL 執行無誤。(請務必在 SQL Runner 中套用 LIMIT，以便維持合理的查詢時間)。
• 對於以 SQL 為基礎的衍生資料表，請避免使用一般資料表運算式 (CTE)。使用 CTE 與 DT 會建立巢狀 WITH 陳述式，可能導致 PDT 失敗而未顯示警告。請改用 CTE 的 SQL 建立次要 DT，並使用 ${derived_table_or_view_name.SQL_TABLE_NAME} 語法，從第一個 DT 參照該 DT。
• 請檢查問題 PDT 所依附的任何資料表 (無論是一般資料表或 PDT 本身) 是否存在且可查詢。
• 請確認問題 PDT 所依賴的任何資料表都沒有共用或專屬鎖定。如要讓 Looker 順利建構 PDT，它必須取得需要更新的資料表專屬鎖定。這會與目前在資料表上使用的其他共用或專屬鎖定相衝突。所有其他鎖定都必須解除，Looker 才能更新 PDT。同樣地，如果 Looker 要建構 PDT 的資料表上有任何專屬鎖定，在專屬鎖定解除前，Looker 就無法取得共用鎖定來執行查詢。
• 請使用 SQL Runner 中的「Show Processes」按鈕。如果有大量的程序正在執行，這可能會導致查詢時間變慢。
• 監控查詢中的註解。請參閱本頁的「查詢 PDT 的註解」一節。

查詢 PDT 的註解

資料庫管理員可以輕鬆區分一般查詢和產生永久衍生資料表 (PDT) 的查詢。Looker 會在 CREATE TABLE ... AS SELECT ... 陳述式中加入註解，其中包含 PDT 的 LookML 模型和檢視畫面，以及 Looker 例項的專屬 ID (slug)。如果系統是在開發模式下，代表使用者產生 PDT，則註解會顯示使用者的 ID。PDT 產生註解遵循以下模式：

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

如果 Looker 必須為 Explore 查詢產生 PDT，則「探索」的 SQL 分頁會顯示 PDT 產生註解。留言會顯示在 SQL 陳述式的頂端。

最後，每個查詢的「查詢詳細資料」彈出式視窗的「資訊」分頁標籤「訊息」欄位中，都會顯示「PDT 產生」註解。

在失敗後重新建構 PDT

當永久衍生資料表 (PDT) 發生錯誤時，查詢該 PDT 會發生以下情況：

• 如果先前執行過相同的查詢，Looker 就會使用快取中的結果。(請參閱「快取查詢」說明文件頁面，瞭解這項功能的運作方式)。
• 如果結果不在快取中，Looker 會從資料庫中的 PDT (如果有有效的 PDT 版本) 提取結果。
• 如果資料庫中沒有有效的 PDT，Looker 會嘗試重新建構 PDT。
• 如果無法重新建構 PDT，Looker 會針對查詢傳回錯誤。Looker 再生器會在下次查詢 PDT 或 PDT 的持久化策略觸發重建作業時，嘗試重建 PDT。

對於層疊的 PDT，則適用相同的邏輯，但層疊的 PDT 有以下差異：

• 如果無法為一個資料表進行建構，就無法在依附元件鏈中建構 PDT。
• 依附的 PDT 基本上會查詢所依附的 PDT，因此一個資料表的持久化策略可觸發重新建構鏈結上的 PDT。

回到先前的資料表連結示例，其中 TABLE_D 依附 TABLE_C，而 TABLE_C 依附 TABLE_B，而 TABLE_B 依附 TABLE_A：

如果 TABLE_B 發生錯誤，系統會為 TABLE_B 套用所有標準 (非連鎖) 行為：

1. 如果查詢 TABLE_B，Looker 會先嘗試使用快取來傳回結果。
2. 如果這次嘗試失敗，Looker 會嘗試使用先前版本的表格 (如果有的話)。
3. 如果這次嘗試也失敗，Looker 會嘗試重建資料表。
4. 最後，如果無法重建 TABLE_B，Looker 會傳回錯誤。

下次查詢資料表時，或資料表的持久化策略下次觸發重建作業時，Looker 會再次嘗試重建 TABLE_B。

TABLE_B 的從屬項目也適用相同的規則。因此，如果無法建構 TABLE_B，且 TABLE_C 有查詢，就會發生以下序列：

1. Looker 會嘗試使用 TABLE_C 的查詢快取。
2. 如果結果不在快取中，Looker 會嘗試從資料庫中的 TABLE_C 擷取結果。
3. 如果沒有有效的 TABLE_C 版本，Looker 會嘗試重建 TABLE_C，並在 TABLE_B 上建立查詢。
4. Looker 會嘗試重建 TABLE_B (如果 TABLE_B 未修正，則會失敗)。
5. 如果無法重建 TABLE_B，TABLE_C 也無法重建，因此 Looker 會針對 TABLE_C 的查詢傳回錯誤。
6. 接著，Looker 會嘗試根據通常的持久化策略，或下次查詢 PDT 時重建 TABLE_C (包括 TABLE_D 下次嘗試建構時，因為 TABLE_D 會依賴 TABLE_C)。

解決 TABLE_B 的問題後，TABLE_B 和每個依附的資料表都會根據其持久化策略，或在下次查詢時 (包括下次依附的 PDT 嘗試重建時) 嘗試重建。或者，如果在開發模式中建立了層疊式 PDT 的開發版本，則可將開發版本用作新的正式版 PDT。(如要瞭解這項功能的運作方式，請參閱本頁的「開發模式中的已儲存資料表」一節)。或者，您也可以使用探索工具對 TABLE_D 執行查詢，然後手動重新建立查詢的 PDT，這會強制重新建立依附元件連鎖中所有 PDT。

提升 PDT 效能

建立永久衍生資料表 (PDT) 時，效能可能會受到影響。尤其是當資料表非常大時，查詢資料表的速度可能會變慢，這與資料庫中任何大型資料表一樣。

您可以篩選資料或控制 PDT 中資料的排序和索引方式，藉此提升效能。

新增篩選器來限制資料集

如果資料集特別龐大，資料列太多會導致針對持久衍生資料表 (PDT) 的查詢速度變慢。如果您通常只查詢近期資料，建議您在 PDT 的 WHERE 子句中新增篩選器，將資料表限制為 90 天或更短的資料。如此一來，每次重建資料表時，系統只會新增相關資料，因此執行查詢的速度會大幅提升。接著，您可以建立另一個較大的 PDT 用於歷來分析，這樣就能快速查詢近期資料，也能查詢舊資料。

使用 indexes 或 sortkeys 和 distribution

建立大型的永久衍生資料表 (PDT) 時，為資料表建立索引 (適用於 MySQL 或 Postgres 等方言)，或新增排序鍵和分發 (適用於 Redshift)，有助於提升效能。

一般來說，建議在 ID 或日期欄位中加入 indexes 參數。

對於 Redshift，通常建議在 ID 或日期欄位上新增 sortkeys 參數，並在用於彙整的欄位上新增 distribution 參數。

可改善效能的建議設定

下列設定會控管永久衍生資料表 (PDT) 中資料的排序和索引方式。以下設定為選用，但強烈建議您採用：

• 針對 Redshift 和 Aster，請使用 distribution 參數指定資料欄名稱，其值會用於在叢集中散布資料。如果兩個資料表透過 distribution 參數中指定的資料欄彙整，資料庫就能在同一節點上找到彙整資料，因此節點間的輸入/輸出作業量會降到最低。
• 針對 Redshift，請將 distribution_style 參數設為 all，指示資料庫保留每個節點的完整資料副本。這類作業通常用於在彙整相對較小的資料表時，盡可能減少節點間的 I/O。將這個值設為 even，即可指示資料庫在叢集中平均分配資料，而不需要使用分配欄。只有在未指定 distribution 時，才能指定這個值。
• 針對 Redshift，請使用 sortkeys 參數。這些值會指定 PDT 的哪些資料欄用於排序磁碟上的資料，以利搜尋。在 Redshift 中，您可以使用 sortkeys 或 indexes，但不能同時使用兩者。
• 在大多數資料庫中，請使用 indexes 參數。這些值會指定要為 PDT 的哪些資料欄建立索引。(在 Redshift 中，索引會用於產生交錯式排序鍵)。