Looker 中的衍生資料表

在 Looker 中，派生表 是一個查詢，其結果的使用方式與查詢在資料庫中的實際表相同。

例如，您可能有一個名為 orders 的資料庫表，其中包含許多欄位。你要計算一些客戶層級的總結指標，例如每個客戶下了多少訂單，或是每個客戶何時下了第一個訂單。使用 原生派生表 或 基於 SQL 的衍生表，您可以建立一個名為 customer_order_summary 的新資料庫表，其中包含這些指標。

然後，您可以像操作資料庫中的任何其他表一樣操作 customer_order_summary 派生表。

有關派生表的常用用例，請造訪 Looker cookbooks: Getting the most out of derived tables in 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 ;;
  }
}

基於 SQL 的派生表版本

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 術語定義的查詢。若要建立原生派生表，您可以使用 explore_source 參數，該參數位於 view 參數的 derived_table 參數內。您可以透過引用模型中的 LookML 維度或度量來建立原生派生表的列。請參閱本機派生表視圖檔案。前例。

與基於 SQL 的衍生表相比，原生派生表在資料建模過程中更容易閱讀和理解。

有關建立原生派生表的詳細信息，請參閱 建立原生派生表 文件頁面。

基於 SQL 的派生表

若要建立基於 SQL 的衍生表，您需要用 SQL 術語定義查詢，並使用 SQL 查詢在表中建立列。您不能在基於 SQL 的衍生表中引用 LookML 維度和度量。請參閱基於 SQL 的派生表視圖檔案。前例。

最常見的是，您可以使用 sql 參數在 view 參數的 derived_table 參數內定義 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))。

注意: 要用作 增量 PDT，必須使用 sql 參數定義基於 SQL 的衍生表。使用 sql_create 參數或 create_process 參數定義的基於 SQL 的衍生表無法增量建構。

暫時派生表和持久派生表

除了原生派生表和基於 SQL 的派生表之間的差異之外，還有以下差異：暫時的衍生表——但不會寫入資料庫——以及執著的衍生表（PDT）——它被寫入資料庫的模式中。

原生派生表和基於 SQL 的衍生表可以是暫時的，也可以是持久的。

暫時派生表

前面所示的派生表是暫時派生表的範例。它們是暫時的，因為在 derived_table 參數中沒有定義 持久性策略。

臨時派生表不會寫入資料庫。當使用者執行涉及一個或多個派生表的 Explore 查詢時，Looker 會使用派生表的 SQL 方言特定組合加上請求的欄位、連接和篩選值來建立 SQL 查詢。如果之前已經執行過該組合，且快取中的結果仍然有效，則 Looker 會使用快取的結果。有關 Looker 中查詢快取的更多信息，請參閱 快取查詢 文件頁面。

否則，如果 Looker 無法使用快取結果，則每次使用者從臨時派生表要求資料時，Looker 都必須對資料庫執行新查詢。因此，您應該確保臨時派生表的效能良好，不會給資料庫帶來過多的壓力。如果查詢需要一些時間才能運行，則 PDT 通常是更好的選擇。

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

要讓 Looker 在 Looker 專案中支援派生表，您的資料庫方言也必須支援派生表。下表顯示了 Looker 最新版本中支援衍生表的語言：

按這裡即可顯示表格。

方言	是否支援？
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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 可以是原生衍生表或基於 SQL 的派生表。

PDT 的要求

要在 Looker 專案中使用持久化衍生表 (PDT)，您需要以下內容：

• 支援 PDT 的資料庫方言。有關支援 持久化 SQL 派生表 和 持久化原生派生表 的方言列表，請參閱本頁後面的 PDT 支援的資料庫方言 部分。

• 資料庫的臨時架構。這可以是資料庫中的任何模式，但我們建議建立一個僅用於此目的的新模式。資料庫管理員必須為 Looker 資料庫使用者配置寫入權限。

  警告： 如果您有多個 Looker 實例，例如生產實例和測試實例，請確保為每個實例設定不同的臨時架構，以避免 PDT 管理衝突。

• 已設定啟用 啟用 PDTs 開關的 Looker 連接。此 啟用 PDTs 設定通常在您首次設定 Looker 連線時進行設定（有關資料庫方言的說明，請參閱 Looker 方言 文件頁面），但您也可以在初始設定後為您的連線啟用 PDTs。

PDT 支援的資料庫方言

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

為了支援任何類型的 PDT（無論是基於 LookML 的還是基於 SQL 的），方言必須支援寫入資料庫，除其他要求。有些只讀資料庫配置不允許持久化工作（最常見的是 Postgres 熱交換副本資料庫）。在這種情況下，您可以使用 臨時派生表 來代替。

下表顯示了 Looker 最新版本中支援持久化 基於 SQL 的派生表 的方言：

按這裡即可顯示表格。

方言	是否支援？
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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

為了支援持久化的原生派生表（具有基於 LookML 的查詢），該方言還必須支援 CREATE TABLE DDL 函數。以下是支援持久模式的方言清單。原生（基於 LookML）派生表在 Looker 的最新版本：

按這裡即可顯示表格。

方言	是否支援？
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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 不支援使用 OAuth 的 Snowflake 連結。

逐步建構 PDT

增量式 PDT 是 Looker 透過向表中新增資料而非完全重建表來建構的 持久化衍生表。

如果你的方言支援增量式 PDT並且您的 PDT 使用基於觸發器的持久化策略（datagroup_trigger ，sql_trigger_value ， 或者interval_trigger）， 你可以將 PDT 定義為增量 PDT 。

註： 使用persist_for持久化策略的 PDT 不支援增量 PDT。

有關更多信息，請參閱 增量 PDT 文件頁面。

增量 PDT 支援的資料庫方言

要讓 Looker 在 Looker 專案中支援增量 PDT，您的資料庫方言也必須支援增量 PDT。下表顯示了 Looker 最新版本中支援增量 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.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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)，您需要為該表定義 持久化策略。為了優化效能，您還應該添加 優化策略。

持久性策略

派生表的持久性可以由 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 取得 Explore 查詢的答案。

註： 某些使用者可以覆寫 PDT 的持久性設定。 擁有 develop 權限的使用者可以使用 Explore 選單中的 重建派生表並執行 選項來覆寫持久性設置，並重建 Explore 中目前查詢所需的所有 PDT。參見手動重建查詢的 PDT詳情請參閱本頁的相應部分。

datagroup_trigger

資料組是創建持久化最靈活的方法。如果您定義了一個包含 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 參數會根據您提供的 SQL 語句觸發持久派生表 (PDT) 的重新產生。如果 SQL 陳述式的結果與先前的值不同，系統會重新產生 PDT。否則，現有的 PDT 將保留在資料庫中。這意味著，在大多數情況下，您的用戶無需等待 PDT 建置完成。如果使用者在 PDT 建置期間請求從中獲取數據，但查詢結果不在快取中，則 Looker 將從現有的 PDT 傳回數據，直到新的 PDT 建置完成。

有關再生器如何建構 PDT 的更多信息，請參閱 Looker 再生器 部分。

interval_trigger

interval_trigger 參數會根據您提供的時間間隔（例如 "24 hours" 或 "60 minutes"）觸發持久派生表 (PDT) 的重新生成。與 sql_trigger 參數類似，這表示通常情況下，當使用者查詢 PDT 時，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 regenerator 自動重建，除非有 PDT 的依賴關係 cascade。當 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

例如，要為 派生表 example 新增持久性，您可以將其設定為在資料組 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 工具的 Explain 功能分析慢查詢的執行計劃。

除了減少頻繁執行查詢的查詢時間和資料庫負載外，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。然後執行測試查詢並比較結果。如果結果令人滿意，您可以要求 DBA 或 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。

筆記： 在設定級聯派生表之前，瞭解級聯表的工作原理非常重要。由 Looker 再生器自動重建以及它們如何能夠由使用者手動重建。實現持久化表還有其他重要考慮因素。本頁稍後將介紹所有這些主題。

引用派生表的語法

若要在一個派生表中引用另一個派生表，請使用下列語法：

`${derived_table_or_view_name.SQL_TABLE_NAME}`

在這種格式中，SQL_TABLE_NAME 是一個字面字串。例如，您可以使用下列語法參考 clean_events 派生表：

`${clean_events.SQL_TABLE_NAME}`

您可以使用相同的語法來引用 LookML 視圖。同樣，在這種情況下，SQL_TABLE_NAME 是一個字面字串。

注意: ${derived_table_or_view_name.SQL_TABLE_NAME} 語法在 資料組 的 sql_trigger 參數中不受支持，因此您不能使用派生表來觸發資料組。但是，您可以在 sql_trigger_value 參數中使用 ${derived_table_or_view_name.SQL_TABLE_NAME} 語法來觸發 PDT 重建。

在下一個範例中，clean_events PDT 是從資料庫中的 events 表建立的。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_B這取決於TABLE_A。如果 Looker 在快取中沒有針對 TABLE_C 的查詢的有效結果，Looker 將建立查詢所需的所有資料表。所以 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。如果 PDT 使用 persist_for 策略，這項功能就特別重要。通常，系統會在使用者查詢時建構 persist_for PDT，並保留在資料庫中，直到 persist_for 間隔時間結束為止。之後，系統會在使用者下次查詢時重建 PDT。不過，如果 persist_for PDT 屬於含有觸發式 PDT (使用 datagroup_trigger、interval_trigger 或 sql_trigger_value 持續策略的 PDT) 的層疊，每當重建其依附的 PDT 時，系統基本上都會查詢 persist_for PDT。因此，在這種情況下，系統會根據相依 PDT 的排程重建 persist_for PDT。也就是說，persist_for PDT 可能會受到其依附項目的持續性策略影響。

為深度巢狀 PDT 結構 (多層依附元件的層疊 PDT 鏈結) 設定持續性時，請確保快取保留時間和資料群組間隔提供足夠時間，讓整個層疊結構建構完成。快取保留時間過短可能會導致競爭狀況，進而造成重新整理時發生 409 Conflict 錯誤。如需更多資訊和建議最佳做法，請參閱本頁的「排解深層巢狀 PDT 中的 409 衝突錯誤」一節。

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

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

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

「重建衍生資料表並執行」選項會重建回答查詢所需的所有永久資料表 (所有永久衍生資料表和匯總資料表)，無論其永久策略為何。包括目前查詢中的所有匯總資料表和 PDT，以及目前查詢中匯總資料表和 PDT 參照的任何匯總資料表和 PDT。

如果是永久累加型衍生資料表，「重新建構衍生資料表並執行」選項會觸發新增量的建構作業。使用增量 PDT 時，增量會包含 increment_key 參數中指定的時間範圍，以及 increment_offset 參數中指定的先前時間範圍數量 (如有)。如要查看一些範例情境，瞭解永久累加型衍生資料表如何根據設定建構，請參閱「永久累加型衍生資料表」說明文件頁面。

如果是連鎖 PDT，這表示系統會從頂端開始，重新建構連鎖中的所有衍生資料表。這與查詢臨時衍生資料表串聯中的資料表時的行為相同：

手動重建衍生資料表時，請注意下列事項：

• 對於發起 重建派生表並執行 操作的用戶，查詢將等待表重建完成，然後再載入結果。其他使用者的查詢仍將使用現有表格。持久表重建完成後，所有使用者都將使用重建後的表。雖然此流程旨在避免在重建表時中斷其他使用者的查詢，但這些使用者仍可能會受到資料庫額外負載的影響。如果在營業時間內觸發重建作業可能會給資料庫帶來無法接受的壓力，則可能需要告知用戶，他們絕不應該在這些時間段內重建某些 PDT 或聚合表。

• 如果使用者處於 開發模式，且 Explore 是基於 開發表，則 重建派生表並執行 操作將為 Explore 重建開發表，而不是生產表。但是，如果開發模式下的 Explore 使用的是衍生表的生產版本，則會重建生產表。有關開發表和生產表的信息，請參閱開發模式下的持久化表。

• 對於 Looker 託管的實例，如果派生表重建時間超過一小時，則表將無法成功重建，瀏覽器工作階段將會逾時。有關可能影響 Looker 進程的超時的更多信息，請參閱 管理設定 - 查詢 文檔頁面上的 查詢超時和排隊 部分。

開發模式下的持久化表

Looker 在 開發模式 下對管理持久化表有一些特殊行為。

註： 這些行為適用於任何類型的持久化表，包括聚合表以及持久化衍生表 (PDT)。

如果在開發模式下查詢持久化表沒有如果對該表的定義進行任何更改，Looker 將查詢該表的生產版本。如果你做如果對錶定義進行更改，影響到表中的資料或表的查詢方式，則下次在開發模式下查詢表時，將建立一個新的表開發版本。有了這樣的開發表，你就可以在不打擾用戶的情況下測試更改。

是什麼促使 Looker 創建開發表

無論是否處於開發模式，Looker 都會盡可能使用現有的生產表來回答查詢。但在某些情況下，Looker 無法在開發模式下使用生產表進行查詢：

• 如果您的持久化表有一個參數，將其資料集縮小到 在開發模式下工作速度更快
• 如果您對持久化表的定義進行了更改，從而影響了表中的數據，

如果您處於開發模式並查詢，Looker 將建立開發表。基於 SQL 的派生表這是用以下方式定義的條件WHERE條款if prod和if dev聲明。

注意： 對於有 dev_filters 參數的 原生派生表 則不是這種情況。對於具有 dev_filters 的原生衍生表，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 小時，則該表的開發版本將被標記為已過期，並且不會再用於查詢。您可以檢查未建置的 PDT。透過使用 Looker IDE或透過使用發展標籤頁持久化派生表頁。如果您有未建置的 PDT，可以在進行變更之前在開發模式下查詢它們，以便開發表可在生產環境中使用。
• 如果持續性資料表具有 dev_filters 參數 (適用於原生衍生資料表)，或使用 if prod 和 if dev 陳述式的條件式 WHERE 子句 (適用於以 SQL 為基礎的衍生資料表)，則開發資料表無法做為正式版，因為開發版本具有縮寫的資料集。如果是這種情況，在完成資料表開發並部署變更前，您可以註解掉 dev_filters 參數或條件式 WHERE 子句，然後在開發模式中查詢資料表。部署變更時，Looker 會建立完整版本的資料表，供實際工作環境使用。

否則，如果部署變更時沒有可做為正式版資料表的有效開發資料表，Looker 會在下次以正式版模式查詢資料表時 (適用於使用 persist_for 策略的持續性資料表)，或下次執行重新產生器時 (適用於使用 datagroup_trigger、interval_trigger 或 sql_trigger_value 的持續性資料表)，重建資料表。

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

如果將變更部署至永久衍生資料表 (PDT) 或匯總表格時，開發資料表仍保留在資料庫中，Looker 通常會將開發資料表做為正式環境資料表，這樣使用者查詢資料表時，就不必等待資料表建構完成。詳情請參閱本頁的「Looker 會保留開發資料表多久」和「Looker 在什麼情況下會建立開發資料表」一節。

因此，建議您在部署至正式環境時建立所有 PDT，以便立即將這些資料表做為正式環境版本使用。

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

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

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

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

注意： 如果持續性資料表是以 SQL 為基礎的衍生資料表，且使用含有 if prod 和 if dev 陳述式的條件式 WHERE 子句定義，您就無法將資料表的開發版本用於正式環境，因為資料表的開發版本含有縮寫的資料集。詳情請參閱本頁的「Looker 會保留開發資料表多久」一節。對於具有 dev_filters 參數的原生衍生資料表，除非您變更資料表的定義，然後在開發模式中查詢資料表 (請參閱本文件頁面上的「促使 Looker 建立開發資料表的原因」一節)，否則 Looker 會使用正式環境資料表來回答開發模式中的查詢。

資料表共用和清除

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

這樣做有幾個好處：

• 如果在開發模式下沒有對錶進行任何更改，則查詢將使用現有的生產表。除非你的桌子是…，否則情況就是如此。基於 SQL 的派生表這是用以下方式定義的條件WHERE條款if prod和if dev聲明。如果表定義了條件 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 年的資料以及尤卡谷機場的資料。

dev_filters 參數與 filters 參數搭配使用，以便所有篩選器都套用於表格的開發版本。如果 dev_filters 和 filters 都為同一列指定了篩選條件，則 dev_filters 在表的開發版本中優先。在這個例子中，表格的開發版本會將尤卡谷機場的資料篩選為最近 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 年及以後的資料。策略性地使用此功能來限制結果集並提高查詢速度，可以使開發模式下的變更更容易驗證。

注意： 如果持久化表具有 dev_filters 參數或條件 WHERE 子句，則開發表不能用作生產版本，因為開發版本具有縮減的資料集。如果是這種情況，在完成表格的開發之後，在部署變更之前，您可以註解掉 dev_filters 參數或條件 WHERE 子句，然後在開發模式下查詢表。Looker 將建立一個完整的表格版本，當您部署變更時，該表格可用於生產環境。參見Looker 會保留開發表多久？本頁的相應部分提供了有關在生產環境中使用開發表的更多詳細資訊。

Looker 如何建構 PDT

在定義持久化派生表 (PDT) 之後，無論是首次運行還是由 regenerator 觸發以根據其 持久化策略 重建，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 建立」）重新命名為 LR$..（「Looker 讀取」），以表示該表已準備好使用。
4. 刪除任何不再使用的舊版本表格。

這其中蘊含著幾個重要的意義：

• 產生派生表的 SQL 語句必須在 CTAS 語句中有效。
• SELECT 語句結果集中的列別名必須是有效的列名。
• 指定分佈、排序鍵和索引時使用的名稱必須是派生表的 SQL 定義中列出的列名，而不是 LookML 中定義的欄位名。

觀察者再生器

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 策略的持久化表。

此外，如果您使用 derived_analytic_model 參數定義了分析模型，Looker 重新產生器會在您的資料庫中建立 分析模型。Looker 再生器處理衍生分析模型，類似於 PDT，即 物化視圖。物化視圖和衍生分析模型都只建立一次，且不支援觸發器，例如 資料組觸發器、SQL 觸發器 或 間隔觸發器。Looker 重生成程式僅在 LookML 定義變更或其所依賴的任何 LookML 視圖變更時才在資料庫中重新建立分析模型。

Looker 重新產生週期以 Looker 管理員在資料庫連線的 維護計畫 設定中配置的固定間隔開始（預設間隔為五分鐘）。但是，Looker 再生器只有在完成上一個週期的所有檢查和 PDT 重建後才會開始新的週期。這意味著，如果您有長時間運行的 PDT 構建，Looker 重新生成週期可能不會像 維護計劃 設定中定義的那樣頻繁運行。其他因素也會影響重建表所需的時間，詳情請參閱下文。實現持久表的重要考慮因素section on this page.

如果 PDT 建置失敗，則再生器可能會在下一個再生器週期中嘗試重建該表：

• 如果資料庫連接上啟用了 重試失敗的 PDT 建置 設置，即使表的觸發條件未滿足，Looker 重建器也會在下一個重建週期中嘗試重建表。
• 如果停用 重試失敗的 PDT 建置 設置，則 Looker 重新產生程式不會嘗試重建表，直到滿足 PDT 的觸發條件。

如果使用者在持久化表建置過程中要求該表的數據，而查詢結果不在快取中，Looker 會檢查現有表是否仍然有效。（如果舊表與新表版本不相容，則舊表可能無效。這種情況可能發生在新表具有不同的定義、新表使用不同的資料庫連接，或者新表是使用不同版本的 Looker 建立的。） 如果現有表仍然有效，Looker 將從現有表中傳回數據，直到新表建置完成。否則，如果現有表無效，Looker 將在新表重建後提供查詢結果。

實現持久表的重要考慮因素

考慮到持久化表（PDT 和 聚合表）的實用性，可以在 Looker 實例上累積許多這樣的表。有可能出現這樣的場景：Looker 重生成器 需要同時建立多個表。尤其是級聯表對於長時間運行的表，您可以建立一個場景，其中表在重建之前會有很長的延遲，或者當資料庫努力產生表時，用戶在從表中獲取查詢結果時會遇到延遲。

Looker regenerator 檢查 PDT 觸發器，以確定是否應該重建觸發器持久化的表。再生週期是按 Looker 管理員在資料庫連接的 維護計劃 設定中配置的固定間隔設定的（預設間隔為五分鐘）。

重建表格所需的時間會受到多種因素的影響：

• 您的 Looker 管理員可能已透過資料庫連線上的 維護計畫 設定變更了重新產生觸發器檢查的間隔。
• Looker 再生器只有在完成上一個週期的所有檢查和 PDT 重建後才會開始新的週期。因此，如果您有長時間運行的 PDT 構建，Looker 重新生成週期可能不會像 維護計劃 設定那樣頻繁。
• 預設情況下，重建器可以透過連接一次啟動一個 PDT 或聚合表的重建。Looker 管理員可以透過在連線設定中使用 PDT 建構器連線的最大數量 欄位來調整重新產生器允許的並發重建數量。
• 由同一 datagroup 觸發的所有 PDT 和聚合表將在同一重生成過程中重建。如果有很多表直接或由於 級聯依賴 而使用資料組，這可能會造成沉重的負擔。

除了前面提到的注意事項之外，在某些情況下，您也應該避免在衍生表中新增持久化功能：

• 當派生表被 擴充 時 — PDT 的每次擴充都會在您的資料庫中建立一個新的表副本。
• 當派生表使用 模板過濾器或 Liquid 參數 時 — 使用模板過濾器或 Liquid 參數的派生表不支援持久化。
• 當使用 使用者屬性 和 access_filters 或 sql_always_where 從 Explore 建立 原生派生表 時 — 將在您的資料庫中為指定的每個可能的使用者屬性值建立表格的副本。
• 當底層資料頻繁更改且您的資料庫方言不支援 增量 PDT 時。
• 當創建 PDT 的成本和時間過高時。

根據 Looker 連線中持久化表的數量和複雜程度，佇列可能包含許多需要在每個週期檢查和重建的持久化表，因此在 Looker 實例上實作衍生表時，請務必牢記這些因素。

使用 API 大規模管理 PDT

隨著實例上建立的 PDT 越來越多，監控和管理不同計畫刷新的持久性衍生表 (PDT) 變得越來越複雜。考慮使用 Looker Apache Airflow 整合 來管理您的 PDT 計劃以及其他 ETL 和 ELT 流程。

監測和故障排除 PDT

如果您使用持久化衍生表 (PDT)，尤其是級聯對於 PDT 來說，查看您的 PDT 狀態是有幫助的。您可以使用 Looker 持久派生表 管理頁面 查看您的 PDT 的狀態。您也可以查看 PDT 故障排除樹 以進行逐步偵錯。

嘗試對 PDT 進行故障排除時：

• 在調查 PDT 事件日誌 時，請特別注意 開發表 和生產表之間的差異。
• 請確認 Looker 連線中的 Temp Database 設定與您的實際臨時架構或資料庫相符。如果連線上的 Temp Database 設定與資料庫中的暫存架構不匹配，請更新 Temp Database 設置，以便 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 中使用 顯示進程 按鈕。如果大量進程處於活動狀態，則可能會減慢查詢速度。
• 監控查詢中的評論。請參閱此頁面上的 PDT 查詢註釋 部分。

• 當在派生表的 SQL 查詢中使用資料庫特定的日期函數（例如 current_date()）時，使用者的 Looker 會話和底層資料庫之間可能存在時區不匹配的風險。由於資料庫函數直接在資料庫中執行，不會經過 Looker 的查詢時區轉換，因此這種差異可能會導致意外的日期篩選結果（例如，「昨天」的日期篩選結果可能是兩天前的午夜）。

  要解決此問題，請確保資料庫和 Looker 執行個體之間的時區正確對齊，這可能需要與您的資料工程團隊協調。

• 如果在深度嵌套的 PDT 結構（具有多層依賴關係的級聯 PDT 鏈）中刷新 PDT 時遇到 409 Conflict 錯誤，請參閱本頁上的 深度嵌套 PDT 中的 409 衝突錯誤故障排除 部分。

PDT 的查詢評論

資料庫管理員可以區分普通查詢和產生持久派生表 (PDT) 的查詢。Looker 會在 CREATE TABLE ... AS SELECT ... 語句中新增註釋，其中包含 PDT 的 LookML 模型和視圖，以及 Looker 實例的唯一識別碼（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，則 PDT 產生註解將顯示在 Explore 的 SQL 標籤中。註釋將顯示在 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_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 隨後會嘗試重建TABLE_C根據其通常的持久化策略，或下次查詢 PDT 時（包括下次查詢 PDT 時）。TABLE_D嘗試構建，因為TABLE_D取決於TABLE_C）。

一旦您解決了 TABLE_B 的問題，那麼 TABLE_B 和每個依賴表將根據其持久性策略嘗試重建，或在下次查詢時（包括下次依賴 PDT 嘗試重建時）重建。或者，如果級聯中的 PDT 的開發版本是在開發模式下建構的，則開發版本可以用作新的生產 PDT。（參見）開發模式下的持久化表本頁的相應章節將介紹其工作原理。 ） 或者，您可以使用 Explore 對 TABLE_D 執行查詢，然後 手動重建查詢的 PDT，這將強制重建依賴級聯中所有向上延伸的 PDT。

排除深度嵌套 PDT 中的 409 衝突錯誤

當您處理深度嵌套的 PDT 結構（具有多個依賴等級的級聯 PDT 鏈）時，配置較短的快取保留期（例如 15 分鐘）可能會導致競爭條件，從而在刷新期間產生 409 Conflict 錯誤。

造成這種競爭條件的原因是，當上層 PDT 仍在建置過程中時，下層嵌套 PDT 的快取可能會過期。當這種情況發生時，Looker 會為較低層級的 PDT 觸發一個新的、重複的建置請求，而初始作業仍在資料倉儲中處理，從而導致衝突。

為解決或防止此錯誤，請遵循以下最佳實踐：

• 增加快取保留期: 將 PDT 的快取保留期（max_cache_age 或 persist_for）設定為至少是完成所有嵌套 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 參數中指定的列連接時，資料庫可以在同一節點上找到連接數據，從而最大限度地減少節點間的 I/O。
• 對於 Redshift，將 distribution_style 參數設為 all，以指示資料庫在每個節點上保留資料的完整副本。當連接相對較小的表時，通常使用這種方法來最大限度地減少節點間的 I/O。將此值設為 even，以指示資料庫在不使用分佈列的情況下將資料均勻地分佈在叢集中。只有在未指定 distribution 時才能指定此值。
• 對於 Redshift，請使用 sortkeys 參數。這些值指定了用於對磁碟上的資料進行排序的 PDT 列，以便於搜尋。在 Redshift 中，您可以使用 sortkeys 或 indexes，但不能同時使用兩者。
• 在大多數資料庫中，使用 indexes 參數。這些值指定要對 PDT 的哪些欄位建立索引。（在 Redshift 中，索引用於產生交錯排序鍵。）