Tabelle derivate in Looker

In Looker, una tabella derivata è una query i cui risultati vengono utilizzati come se la query fosse una tabella effettiva nel database.

Ad esempio, potresti avere una tabella di database chiamata orders con molte colonne. Vuoi calcolare alcune metriche aggregate a livello di cliente, ad esempio il numero di ordini effettuati da ciascun cliente o la data del primo ordine. Utilizzando una tabella derivata nativa o una tabella derivata basata su SQL, puoi creare una nuova tabella di database denominata customer_order_summary che include queste metriche.

Puoi quindi utilizzare la tabella derivata customer_order_summary come qualsiasi altra tabella del database.

Per i casi d'uso più comuni delle tabelle derivate, visita la pagina Looker cookbooks: Getting the most out of derived tables in Looker.

tabelle derivate native e tabelle derivate basate su SQL

Per creare una tabella derivata nel tuo progetto Looker, utilizza il parametro derived_table in un parametro view. All'interno del parametro derived_table, puoi definire la query per la tabella derivata in due modi:

• Per una tabella derivata nativa, definisci la tabella derivata con una query basata su LookML.
• Per una tabella derivata basata su SQL, definisci la tabella derivata con una query SQL.

Ad esempio, i seguenti file di visualizzazione mostrano come utilizzare LookML per creare una visualizzazione da una tabella derivata customer_order_summary. Le due versioni di LookML mostrano come creare tabelle derivate equivalenti utilizzando LookML o SQL per definire la query per la tabella derivata:

• La tabella derivata nativa definisce la query con LookML nel parametro explore_source. In questo esempio, la query si basa su una visualizzazione orders esistente, definita in un file separato che non viene mostrato in questo esempio. La query explore_source nella tabella derivata nativa importa i campi customer_id, first_order e total_amount dal file di vista orders.
• La tabella derivata basata su SQL definisce la query utilizzando SQL nel parametro sql. In questo esempio, la query SQL è una query diretta della tabella orders nel database.

Versione della tabella derivata nativa

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 ;;
  }
}

Versione della tabella derivata basata su 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 ;;
  }
}

Entrambe le versioni creano una vista denominata customer_order_summary basata sulla tabella orders, con le colonne customer_id, first_order, e total_amount.

Oltre alderived_table parametro e i suoi sottoparametri, questocustomer_order_summary la visualizzazione funziona proprio come qualsiasi altravisualizza file. Sia che si definisca la query della tabella derivata con LookML o con SQL, è possibile creare misure e dimensioni LookML basate sulle colonne della tabella derivata.

Una volta definita la tabella derivata, è possibile utilizzarla come qualsiasi altra tabella del database.

tabelle derivate native

Le tabelle derivate native si basano su query definite dall'utente utilizzando i termini LookML. Per creare una tabella derivata nativa, si utilizzaexplore_source parametro all'interno delderived_table parametro di unvisualizzazione parametro. Le colonne della tabella derivata nativa vengono create facendo riferimento alle dimensioni o alle misure LookML presenti nel modello. Vedi il file di visualizzazione della tabella derivata nativa nell'esempio precedente.

Rispetto alle tabelle derivate basate su SQL, le tabelle derivate native sono molto più facili da leggere e comprendere durante la modellazione dei dati.

Consultare la pagina di documentazione Creazione di tabelle derivate native per i dettagli sulla creazione di tabelle derivate native.

Tabelle derivate basate su SQL

Per creare una tabella derivata basata su SQL, si definisce una query in termini SQL, creando le colonne nella tabella utilizzando una query SQL. Non è possibile fare riferimento a dimensioni e misure LookML in una tabella derivata basata su SQL. Vedere il file della vista tabella derivata basata su SQL nell'esempio precedente.

Nella maggior parte dei casi, si definisce la query SQL utilizzandosql parametro all'interno delderived_table parametro di unvisualizzazione parametro.

Una scorciatoia utile per creare query basate su SQL in Looker è utilizzare SQL Runner per creare la query SQL e trasformarla in una definizione di tabella derivata.

In alcuni casi limite non sarà consentito l'uso del parametro sql. In tali casi, Looker supporta i seguenti parametri per definire una query SQL per tabelle derivate persistenti (PDT):

• create_process: Quando usi ilsql parametro per un PDT, in background Looker avvolge il dialettoCREATE TABLE Dichiarazione del linguaggio di definizione dei dati (DDL) attorno alla tua query per creare il PDT dalla tua query SQL. Alcuni dialetti non supportano un'istruzione SQL CREATE TABLE in un singolo passaggio. Per questi dialetti, non è possibile creare un PDT con il parametro sql. In alternativa, è possibile utilizzare il parametro create_process per creare un PDT in più passaggi. Vedi ilcreate_process Pagina di documentazione dei parametri per informazioni ed esempi.
• sql_create: Se il tuo caso d'uso richiede una personalizzazioneDDL comandi e il tuo dialetto supporta DDL (ad esempio, il comando predittivo di Google)BigQuery ML ), puoi usare ilsql_create parametro per creare un PDT invece di utilizzare ilsql parametro. Vedi ilsql_create Pagina di documentazione contenente informazioni ed esempi.

Sia che si utilizzi il parametro sql, create_process o sql_create, in tutti questi casi si definisce la tabella derivata con una query SQL, quindi si tratta in tutti i casi di tabelle derivate basate su SQL.

Quando si definisce una tabella derivata basata su SQL, assicurarsi di assegnare a ciascuna colonna un alias univoco utilizzando AS. Questo perché dovrai fare riferimento ai nomi delle colonne del tuo set di risultati nelle tue dimensioni, ad esempio ${TABLE}.first_order. Ecco perché l'esempio precedente utilizza MIN(DATE(time)) AS first_order invece di MIN(DATE(time)).

Nota: Da utilizzare comePDT incrementale, una tabella derivata basata su SQL deve essere definita utilizzandosql parametro. Tabelle derivate basate su SQL che sono definite consql_create parametro o ilcreate_process Il parametro non può essere costruito in modo incrementale.

tabelle derivate temporanee e persistenti

Oltre alla distinzione tra tabelle derivate native e tabelle derivate basate su SQL, esiste anche una distinzione tra una tabella derivata temporanea — che non viene scritta nel database — e una tabella derivata persistente (PDT) — che viene scritta in uno schema sul database.

Le tabelle derivate native e le tabelle derivate basate su SQL possono essere temporanee o persistenti.

Tavoli derivati ​​temporanei

Le tabelle derivate mostrate in precedenza sono esempi di tabelle derivate temporanee. Sono temporanei perché non è definita alcuna strategia di persistenza nel parametro derived_table.

Le tabelle derivate temporanee non vengono scritte nel database. Quando un utente esegue una query di Esplora che coinvolge una o più tabelle derivate, Looker costruisce una query SQL utilizzando una combinazione specifica del dialetto della query SQL per le tabelle derivate, oltre ai campi, alle join e ai valori di filtro richiesti. Se la combinazione è già stata eseguita in precedenza e i risultati sono ancora validi nella cache, Looker utilizza i risultati memorizzati nella cache. Consulta la pagina della documentazione Memorizzazione nella cache delle query per ulteriori informazioni sulla memorizzazione nella cache delle query in Looker.

Altrimenti, se Looker non può utilizzare i risultati memorizzati nella cache, dovrà eseguire una nuova query sul database ogni volta che un utente richiede dati da una tabella derivata temporanea. Per questo motivo, è necessario assicurarsi che le tabelle derivate temporanee siano performanti e non sovraccarichino il database. Nei casi in cui l'esecuzione della query richiederà del tempo, un PDT è spesso un'opzione migliore.

Dialetti del database supportati per le tabelle derivate temporanee

Affinché Looker supporti le tabelle derivate nel tuo progetto Looker, anche il dialetto del tuo database deve supportarle. La tabella seguente mostra quali dialetti supportano le tabelle derivate nell'ultima versione di Looker:

Fai clic qui per visualizzare la tabella.

Dialetto	Supportata?
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

Tabelle derivate persistenti

Una tabella derivata persistente (PDT) è una tabella derivata che viene scritta in uno schema temporaneo sul database e rigenerata secondo la pianificazione specificata con una strategia di persistenza persistence strategy.

Una PDT può essere una tabella derivata nativa o una tabella derivata basata su SQL.

Requisiti per i PDT

Per utilizzare le tabelle derivate persistenti (PDT) nel tuo progetto Looker, hai bisogno di quanto segue:

• Un dialetto di database che supporta i PDT. Consultare la sezione Dialetti del database supportati per PDT più avanti in questa pagina per gli elenchi dei dialetti che supportano tabelle derivate persistenti basate su SQL e tabelle derivate native persistenti.

• Uno schema provvisorio per il tuo database. Può trattarsi di qualsiasi schema presente nel database, ma consigliamo di crearne uno nuovo da utilizzare esclusivamente per questo scopo. L'amministratore del database deve configurare lo schema con i permessi di scrittura per l'utente del database Looker.

  Avviso: Se si dispone di più istanze di Looker, ad esempio un'istanza di produzione e un'istanza di QA, assicurarsi di impostare schemi temporanei diversi per ciascuna istanza per evitare conflitti di gestione PDT.

• Una connessione Looker configurata con l'interruttore Abilita PDT attivato. Questa impostazione Abilita PDT viene solitamente configurata quando si imposta inizialmente la connessione Looker (vedere la pagina della documentazione Dialetti Looker per le istruzioni relative al dialetto del database in uso), ma è possibile abilitare i PDT per la connessione anche dopo la configurazione iniziale.

Dialetti del database supportati per i PDT

Affinché Looker supporti i PDT nel tuo progetto Looker, anche il dialetto del tuo database deve supportarli.

Per supportare qualsiasi tipo di PDT (sia basato su LookML che su SQL), il dialetto deve supportare le scritture nel database, tra gli altri requisiti. Esistono alcune configurazioni di database di sola lettura che non consentono il funzionamento della persistenza (più comunemente i database di replica hot-swap di PostgreSQL). In questi casi, è possibile utilizzare tabelle derivate temporanee in alternativa.

La tabella seguente mostra i dialetti che supportano la persistenzaTabelle derivate basate su SQL nell'ultima versione di Looker:

Fai clic qui per visualizzare la tabella.

Dialetto	Supportata?
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

Per supportare tabelle derivate native persistenti (che hanno query basate su LookML), il dialetto deve supportare anche una funzione DDL CREATE TABLE. Ecco un elenco dei dialetti che supportano la persistenzatabelle derivate native (basate su LookML) nell'ultima versione di Looker:

Fai clic qui per visualizzare la tabella.

Dialetto	Supportata?
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

Nota: I PDT non sono supportati per le connessioni Snowflake che utilizzano OAuth.

Costruzione incrementale di PDT

Una PDT incrementale è una tabella derivata persistente che Looker crea aggiungendo nuovi dati alla tabella invece di ricostruirla interamente.

Se il tuoil dialetto supporta PDT incrementali e il tuo PDT utilizza una strategia di persistenza basata su trigger (datagroup_trigger ,sql_trigger_value , Ointerval_trigger ), puoidefinire il PDT come un PDT incrementale.

Nota: I PDT incrementali non sono supportati per i PDT che utilizzano ilpersist_for strategia di persistenza.

Consultare la pagina di documentazione Incremental PDT per ulteriori informazioni.

Dialetti del database supportati per PDT incrementali

Affinché Looker supporti i PDT incrementali nel tuo progetto Looker, anche il dialetto del database deve supportarli. La tabella seguente mostra quali dialetti supportano i PDT incrementali nell'ultima versione di Looker:

Fai clic qui per visualizzare la tabella.

Dialetto	Supportata?
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

Creazione di PDT

Per trasformare una tabella derivata in una tabella derivata persistente (PDT), è necessario definire una strategia di persistenza persistence strategy per la tabella. Per ottimizzare le prestazioni, dovresti anche aggiungere una strategia di ottimizzazione .

Strategie di persistenza

La persistenza di una tabella derivata può essere gestita da Looker o, per i dialetti che supportano le viste materializzate, dal database utilizzando le viste materializzate.

Per rendere persistente una tabella derivata, aggiungi uno dei seguenti parametri alla definizione derived_table:

• Parametri di persistenza gestiti da Looker:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parametri di persistenza gestiti dal database:
  • materialized_view: yes

Con le strategie di persistenza basate su trigger (datagroup_trigger, sql_trigger_value e interval_trigger), Looker mantiene il PDT nel database finché il PDT non viene attivato per la ricostruzione. Quando il PDT viene attivato, Looker ricostruisce il PDT per sostituire la versione precedente. Questo significa che, con i PDT basati su trigger, i tuoi utenti non dovranno attendere la creazione del PDT per ottenere risposte alle query di Esplora dal PDT stesso.

Nota: Alcuni utenti possono ignorare l'impostazione di persistenza di un PDT. Un utente condevelop il permesso può essere utilizzatoRicostruisci le tabelle derivate ed eseguile Opzione dal menu di Esplora per ignorare l'impostazione di persistenza e ricostruire tutti i PDT necessari per la query corrente in Esplora. Per i dettagli, consultare la sezione Ricostruzione manuale dei PDT per una query di questa pagina.

datagroup_trigger

I gruppi di dati sono il metodo più flessibile per creare persistenza. Se hai definito ungruppo di dati consql_trigger Ointerval_trigger, puoi usare ildatagroup_trigger parametro per avviare la ricostruzione delle tabelle derivate persistenti (PDT).

Looker mantiene il PDT nel database finché il relativo gruppo di dati non viene attivato. Quando il gruppo di dati viene attivato, Looker ricostruisce il PDT per sostituire la versione precedente. Ciò significa che, nella maggior parte dei casi, i tuoi utenti non dovranno attendere la creazione del PDT. Se un utente richiede dati dal PDT mentre questo è in fase di creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dal PDT esistente fino a quando il nuovo PDT non sarà stato creato. Per una panoramica dei gruppi di dati, consultare Memorizzazione nella cache delle query.

Vedi la sezione suIl rigeneratore Looker Per ulteriori informazioni su come il rigeneratore crea i PDT.

sql_trigger_value

ILsql_trigger_value Questo parametro attiva la rigenerazione di una tabella derivata persistente (PDT) basata su un'istruzione SQL fornita dall'utente. Se il risultato dell'istruzione SQL è diverso dal valore precedente, il PDT viene rigenerato. Altrimenti, il PDT esistente viene mantenuto nel database. Ciò significa che, nella maggior parte dei casi, i tuoi utenti non dovranno attendere la creazione del PDT. Se un utente richiede dati dal PDT mentre questo è in fase di creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dal PDT esistente fino a quando il nuovo PDT non sarà stato creato.

Vedi la sezione suIl rigeneratore Looker Per ulteriori informazioni su come il rigeneratore crea i PDT.

interval_trigger

ILinterval_trigger Il parametro attiva la rigenerazione di una tabella derivata persistente (PDT) in base a un intervallo di tempo specificato, ad esempio"24 hours" O"60 minutes". Analogamente al parametro sql_trigger, ciò significa che di solito il PDT verrà precompilato quando gli utenti lo interrogano. Se un utente richiede dati dal PDT mentre questo è in fase di creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dal PDT esistente fino a quando il nuovo PDT non sarà stato creato.

persist_for

Un'altra opzione ancora è quella di utilizzare ilpersist_for Parametro per impostare la durata di conservazione della tabella derivata prima che venga contrassegnata come scaduta, in modo che non venga più utilizzata per le query e venga eliminata dal database.

Una tabella derivata persistente (PDT) persist_for viene creata quando un utente esegue per la prima volta una query su di essa. Looker mantiene quindi il PDT nel database per il periodo di tempo specificato nel parametro persist_for del PDT. Se un utente interroga il PDT entro il tempo persist_for, Looker utilizza i risultati memorizzati nella cache, se possibile, altrimenti esegue la query sul PDT.

Dopo il tempo persist_for, Looker cancella il PDT dal database e il PDT verrà ricostruito la prossima volta che un utente lo interroga, il che significa che la query dovrà attendere la ricostruzione.

I PDT che utilizzano persist_for non vengono ricostruiti automaticamente dal rigeneratore regenerator di Looker, tranne nel caso di una cascata di dipendenze cascata di PDT. Quando unpersist_for la tabella fa parte di una cascata di dipendenza con PDT basati su trigger (PDT che utilizzano ildatagroup_trigger, interval_trigger, Osql_trigger_value strategia di persistenza), il rigeneratore monitorerà e ricostruirà ilpersist_for tabella per ricostruire altre tabelle a cascata. Consulta la sezione Come Looker crea tabelle derivate a cascata di questa pagina.

materialized_view: yes

Nota: La funzionalità della vista materializzata è una funzionalità avanzata. A seconda del dialetto utilizzato, una vista materializzata può consumare molte risorse, quindi è importante comprendere l'implementazione delle viste materializzate nel proprio dialetto. Consulta la documentazione del tuo dialetto per informazioni sul comportamento del tuo dialetto e sulla frequenza con cui il dialetto aggiorna i dati per le viste materializzate.

Le viste materializzate consentono di utilizzare le funzionalità del database per rendere persistenti le tabelle derivate nel progetto Looker. Se il tuo dialetto del databasesupporta viste materializzate e il tuoConnessione Looker è configurato con ilAbilitare i PDT Se l'interruttore è attivo, è possibile creare una vista materializzata specificandomaterialized_view: yes per una tabella derivata. Le viste materializzate sono supportate sia per le tabelle derivate native che per le tabelle derivate basate su SQL.

Similmente a una tabella derivata persistente (PDT), una vista materializzata è il risultato di una query che viene memorizzato come tabella nello schema temporaneo del database. La differenza fondamentale tra una PDT e una vista materializzata risiede nel modo in cui le tabelle vengono aggiornate:

• Per i PDT, la strategia di persistenza è definita in Looker e la persistenza è gestita da Looker.
• Per le viste materializzate, il database è responsabile della gestione e dell'aggiornamento dei dati nella tabella.

Per questo motivo, la funzionalità della vista materializzata richiede una conoscenza approfondita del vostro dialetto e delle sue caratteristiche. Nella maggior parte dei casi, il database aggiornerà la vista materializzata ogni volta che rileva nuovi dati nelle tabelle interrogate dalla vista materializzata. Le viste materializzate sono ottimali per scenari che richiedono dati in tempo reale.

Vedi ilmaterialized_view Consultare la pagina di documentazione dei parametri per informazioni sul supporto dei dialetti, i requisiti e le considerazioni importanti.

Strategie di ottimizzazione

Poiché le tabelle derivate persistenti (PDT) vengono memorizzate nel database, è necessario ottimizzarle utilizzando le seguenti strategie, in base al dialetto in uso:

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

Ad esempio, per aggiungere persistenza alla tabella derivata example, è possibile impostarla in modo che venga ricostruita quando il gruppo di dati orders_datagroup viene attivato e aggiungere indici sia su customer_id che su first_order, in questo modo:

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

Se non aggiungi un indice (o un equivalente per il tuo dialetto), Looker ti avviserà che dovresti farlo per migliorare le prestazioni delle query.

Casi d'uso per i PDT

Le tabelle derivate persistenti (PDT) sono utili perché possono migliorare le prestazioni di una query memorizzando i risultati della query in una tabella.

Come buona prassi generale, gli sviluppatori dovrebbero cercare di modellare i dati senza utilizzare i PDT (Probabilistic Data Tables) finché non sia assolutamente necessario.

In alcuni casi i dati possono essere ottimizzati attraverso altri mezzi. Ad esempio, l'aggiunta di un indice o la modifica del tipo di dati di una colonna potrebbero risolvere un problema senza la necessità di creare un PDT. Assicurati di analizzare i piani di esecuzione delle query lente utilizzando lo strumento Explain from SQL Runner.

Oltre a ridurre i tempi di esecuzione delle query e il carico sul database per le query eseguite frequentemente, esistono diversi altri casi d'uso per i PDT, tra cui:

• Ottimizzazioni di test
• Pre-unione o aggregazione dei dati

È inoltre possibile utilizzare un PDT per definire una chiave primaria nei casi in cui non vi sia un modo ragionevole per identificare una riga univoca in una tabella come chiave primaria.

Utilizzo di PDT per testare le ottimizzazioni

È possibile utilizzare i PDT per testare diverse opzioni di indicizzazione, distribuzione e altre ottimizzazioni senza richiedere un supporto significativo da parte dell'amministratore del database o degli sviluppatori ETL.

Consideriamo il caso in cui si dispone di una tabella ma si desidera testare diversi indici. Il codice LookML iniziale per la vista potrebbe apparire come segue:

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

Per testare le strategie di ottimizzazione, è possibile utilizzareindexes parametro per aggiungere indici al LookML in questo modo:

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]
  }
}

Esegui una query sulla vista una sola volta per generare il PDT. Dopodiché, esegui le query di test e confronta i risultati. Se i risultati sono positivi, puoi chiedere al tuo DBA o al team ETL di aggiungere gli indici alla tabella originale.

Ricordati di modificare di nuovo il codice di visualizzazione per rimuovere l'ora legale.

Utilizzare le PDT per pre-unire o aggregare i dati

Può essere utile pre-unire o pre-aggregare i dati per modificare l'ottimizzazione delle query per volumi elevati o più tipi di dati.

Ad esempio, supponiamo che tu voglia creare una query per i clienti per coorte in base al momento in cui hanno effettuato il primo ordine. L'esecuzione di questa query più volte ogni volta che i dati sono necessari in tempo reale potrebbe essere costosa. Tuttavia, puoi calcolare la query una sola volta e riutilizzare i risultati con una tabella derivata permanente:

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]
  }
}

Tabelle derivate a cascata

È possibile fare riferimento a una tabella derivata nella definizione di un'altra, creando una catena di tabelle derivate a cascata o tabelle derivate persistenti (PDT) a cascata, a seconda dei casi. Un esempio di tabelle derivate a cascata è una tabella, TABLE_D, che dipende da un'altra tabella, TABLE_C, mentre TABLE_C dipende da TABLE_B e TABLE_B dipende da TABLE_A.

Nota: prima di configurare le tabelle derivate a cascata, è importante sapere come vengono ricostruite automaticamente dal generatore di Looker e come possono essere ricostruite manualmente dagli utenti. Esistono anche altre considerazioni importanti per l'implementazione di tabelle persistenti. Tutti questi argomenti vengono trattati più avanti in questa pagina.

Sintassi per fare riferimento a una tabella derivata

Per fare riferimento a una tabella derivata in un'altra tabella derivata, utilizza questa sintassi:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

In questo formato, SQL_TABLE_NAME è una stringa letterale. Ad esempio, puoi fare riferimento alla tabella derivata clean_events con questa sintassi:

`${clean_events.SQL_TABLE_NAME}`

Puoi utilizzare la stessa sintassi per fare riferimento a una vista LookML. Anche in questo caso, SQL_TABLE_NAME è una stringa letterale.

Nota :la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} non è supportata nel parametro sql_trigger di un datagroup, pertanto non puoi utilizzare una tabella derivata per attivare un datagroup. Tuttavia, puoi utilizzare la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} nel parametro sql_trigger_value per attivare le ricompilazioni delle PDT.

Nell'esempio successivo, il PDT clean_events viene creato dalla tabella events nel database. La tabella PDT clean_events esclude le righe indesiderate dalla tabella del database events. Poi viene mostrata una seconda PDT: la PDT event_summary è un riepilogo della PDT clean_events. La tabella event_summary viene rigenerata ogni volta che vengono aggiunte nuove righe a clean_events.

ILevent_summary PDT e ilclean_events I PDT sono PDT a cascata, doveevent_summary dipende daclean_events (Daevent_summary è definito utilizzando ilclean_events PDT). Questo particolare esempio potrebbe essere realizzato in modo più efficiente in un singolo PDT, ma è utile per dimostrare i riferimenti alle tabelle derivate.

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
  }
}

Sebbene non sia sempre necessario, quando si fa riferimento a una tabella derivata in questo modo, è spesso utile creare un alias per la tabella utilizzando questo formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

L'esempio precedente fa questo:

${clean_events.SQL_TABLE_NAME} AS clean_events

È utile utilizzare un alias perché, a livello interno, i PDT vengono denominati con codici lunghi nel database. In alcuni casi (specialmente con le clausole ON) è possibile dimenticare che è necessario utilizzare la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} per recuperare questo nome lungo. Un alias può aiutare a prevenire questo tipo di errore.

Come Looker crea tabelle derivate a cascata

Nel caso di tabelle derivate temporary a cascata, se i risultati della query di un utente non sono nella cache, Looker creerà tutte le tabelle derivate necessarie per la query. Se hai un TABLE_D la cui definizione contiene un riferimento a TABLE_C, allora TABLE_D è dipendente da TABLE_C. Ciò significa che se si esegue una query su TABLE_D e la query non è presente nella cache di Looker, Looker ricostruirà TABLE_D. Ma prima deve ricostruire TABLE_C.

Consideriamo uno scenario con tabelle derivate temporanee a cascata, dove TABLE_D dipende da TABLE_C, che dipende da TABLE_B, che dipende da TABLE_A. Se Looker non ha risultati validi per una query su TABLE_C nella cache, Looker creerà tutte le tabelle necessarie per la query. Quindi Looker costruirà TABLE_A, poi TABLE_B e poi TABLE_C:

In questo scenario, TABLE_A deve terminare la generazione prima che Looker possa iniziare a generare TABLE_B, e TABLE_B deve terminare la generazione prima che Looker possa iniziare a generare TABLE_C. Quando TABLE_C è terminato, Looker fornirà i risultati della query. (Dato che TABLE_D non è necessario per rispondere a questa query, Looker non ricostruirà TABLE_D in questo momento.)

Vedi ildatagroup Pagina di documentazione dei parametri per uno scenario di esempio di PDT a cascata che utilizzano lo stesso gruppo di dati.

La stessa logica di base si applica ai PDT: Looker creerà tutte le tabelle necessarie per rispondere a una query, risalendo l'intera catena delle dipendenze. Ma con i PDT, spesso le tabelle esistono già e non è necessario ricostruirle. Con le query utente standard sui PDT a cascata, Looker ricostruisce i PDT nella cascata solo se non esiste una versione valida dei PDT nel database. Se si desidera forzare una ricostruzione per tutti i PDT in una cascata, è possibile ricostruire manualmente le tabelle per una query tramite un Esplora.

Un punto logico importante da capire è che, nel caso di una cascata di PDT, una PDT dipendente interroga essenzialmente la PDT da cui dipende. Ciò è significativo soprattutto per i PDT che utilizzano la strategia persist_for. In genere, le persist_for PDT vengono create quando un utente le esegue, rimangono nel database fino al termine dell'intervallo persist_for e poi non vengono ricreate finché non vengono eseguite di nuovo da un utente. Tuttavia, se una PDT persist_for fa parte di una cascata con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), la PDT persist_for viene interrogata ogni volta che le PDT dipendenti vengono ricreate. Pertanto, in questo caso, la PDT persist_for verrà ricreata in base alla pianificazione delle PDT da cui dipende. Ciò significa che le PDT persist_for possono essere influenzate dalla strategia di persistenza delle relative dipendenze.

Quando configuri la persistenza per strutture PDT nidificate in profondità (catene di PDT a cascata con più livelli di dipendenze), assicurati che i periodi di conservazione della cache e gli intervalli dei gruppi di dati forniscano tempo sufficiente per la creazione dell'intera cascata. Periodi di conservazione della cache brevi possono causare una race condition che genera un errore 409 Conflict durante l'aggiornamento. Per maggiori informazioni e best practice consigliate, consulta la sezione Risoluzione dei problemi relativi agli errori di conflitto 409 nelle PDT nidificate in profondità in questa pagina.

Ricreare manualmente le tabelle permanenti per una query

Gli utenti possono selezionare l'opzione Ricostruisci tabelle derivate ed esegui dal menu di un'esplorazione per ignorare le impostazioni di persistenza e ricostruire tutte le tabelle derivate permanenti (PDT) e le tabelle aggregate richieste per la query corrente nell'esplorazione:

Questa opzione è visibile solo agli utenti con l'autorizzazione develop e solo dopo il caricamento della query Esplora.

L'opzione Ricostruisci tabelle derivate ed esegui ricostruisce tutte le tabelle permanenti (tutte le PDT e le tabelle aggregate) necessarie per rispondere alla query, indipendentemente dalla strategia di persistenza. Sono incluse tutte le tabelle aggregate e le PDT nella query corrente, nonché tutte le tabelle aggregate e le PDT a cui viene fatto riferimento dalle tabelle aggregate e dalle PDT nella query corrente.

Nel caso delle PDT incrementali, l'opzione Ricostruisci tabelle derivate ed esegui attiva la creazione di un nuovo incremento. Con i PDT incrementali, un incremento include il periodo di tempo specificato nel parametro increment_key, nonché il numero di periodi di tempo precedenti specificati nel parametro increment_offset, se presenti. Consulta la pagina di documentazione PDT incrementali per alcuni scenari di esempio che mostrano come vengono create le PDT incrementali, a seconda della loro configurazione.

Nel caso di PDT a cascata, ciò significa ricompilare tutte le tabelle derivate nella cascata, a partire dalla parte superiore. Questo è lo stesso comportamento che si verifica quando esegui una query su una tabella in una cascata di tabelle derivate temporanee:

Tieni presente quanto segue in merito alla ricreazione manuale delle tabelle derivate:

• Per l'utente che avvia l'operazione Ricostruisci tabelle derivate ed esegui, la query attenderà la ricostruzione delle tabelle prima di caricare i risultati. Le query degli altri utenti continueranno a utilizzare le tabelle esistenti. Una volta ricostruite le tabelle persistenti, tutti gli utenti utilizzeranno le tabelle ricostruite. Sebbene questo processo sia progettato per evitare di interrompere le query degli altri utenti durante la ricostruzione delle tabelle, tali utenti potrebbero comunque risentire del carico aggiuntivo sul database. Se vi trovate in una situazione in cui avviare una ricostruzione durante l'orario lavorativo potrebbe sovraccaricare eccessivamente il vostro database, potreste dover comunicare ai vostri utenti che non dovrebbero mai ricostruire determinate tabelle di dati personali (PDT) o tabelle aggregate durante tali orari.

• Se un utente si trova in Modalità di sviluppo e l'esplorazione si basa su una tabella di sviluppo, l'operazione Ricostruisci tabelle derivate ed esegui ricostruirà la tabella di sviluppo, non la tabella di produzione, per l'esplorazione. Tuttavia, se la funzione Esplora in modalità di sviluppo utilizza la versione di produzione di una tabella derivata, la tabella di produzione verrà ricostruita. Per informazioni sulle tabelle di sviluppo e sulle tabelle di produzione, consultare Tabelle persistenti in modalità di sviluppo.

• Per le istanze ospitate su Looker, se la ricostruzione della tabella derivata richiede più di un'ora, la ricostruzione non andrà a buon fine e la sessione del browser scadrà. Consulta la sezione Timeout delle query e accodamento nella pagina della documentazione Impostazioni di amministrazione - Query per ulteriori informazioni sui timeout che potrebbero influire sui processi di Looker.

Tabelle persistenti in modalità di sviluppo

Looker ha alcuni comportamenti speciali per la gestione delle tabelle persistenti in Modalità di sviluppo.

Nota: Questi comportamenti si applicano a qualsiasi tipo di tabella persistente, comprese tabelle aggregate e tabelle derivate persistenti (PDT).

Se si esegue una query su una tabella persistente in modalità di svilupposenza Se Looker apporta modifiche alla sua definizione, interrogherà la versione di produzione di quella tabella. Se do apporti una modifica alla definizione della tabella che influisce sui dati nella tabella o sul modo in cui la tabella viene interrogata, verrà creata una nuova versione di sviluppo della tabella la prossima volta che eseguirai una query sulla tabella in modalità di sviluppo. Disporre di una tabella di sviluppo di questo tipo consente di testare le modifiche senza disturbare gli utenti.

Cosa spinge Looker a creare una tabella di sviluppo?

Quando possibile, Looker utilizza la tabella di produzione esistente per rispondere alle query, indipendentemente dal fatto che tu sia in modalità di sviluppo o meno. Tuttavia, in alcuni casi Looker non può utilizzare la tabella di produzione per le query in modalità di sviluppo:

• Se la tua tabella persistente ha un parametro che restringe il suo set di dati a lavora più velocemente in modalità di sviluppo
• Se hai apportato modifiche alla definizione della tua tabella persistente che influiscono sui dati nella tabella

Looker creerà una tabella di sviluppo se sei in modalità di sviluppo e interroghi unTabella derivata basata su SQL che viene definito utilizzando uncondizionaleWHERE clausola conif prod Eif dev dichiarazioni.

Nota: Questo non è il caso pertabelle derivate native con ildev_filters parametro. Per le tabelle derivate native con dev_filters, Looker ha la logica per utilizzare la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non si modifichi la definizione della tabella e quindi si esegua una query sulla tabella in modalità di sviluppo.

Per le tabelle persistenti che non hanno un parametro per restringere il dataset in modalità di sviluppo, Looker utilizza la versione di produzione della tabella per rispondere alle query in modalità di sviluppo, a meno che non si modifichi la definizione della tabella e then esegua una query sulla tabella in modalità di sviluppo. Questo vale per qualsiasi modifica alla tabella che influisca sui dati in essa contenuti o sul modo in cui la tabella viene interrogata.

Ecco alcuni esempi dei tipi di modifiche che indurranno Looker a creare una versione di sviluppo di una tabella persistente (Looker creerà la tabella solo se in seguito eseguirai una query sulla tabella dopo aver apportato queste modifiche):

• Modificando la query su cui si basa la tabella persistente, ad esempio modificando laexplore_source ,sql ,query ,sql_create , Ocreate_process parametro nella tabella persistente stessa o in qualsiasi tabella richiesta (nel caso ditabelle derivate a cascata )
• Modificare la strategia di persistenza della tabella, ad esempio modificando la tabelladatagroup_trigger, sql_trigger_value, interval_trigger, Opersist_for parametro
• Modificare il nome di una tabella derivataview
• Cambiare ilincrement_key Oincrement_offset Di unPDT incrementale
• Cambiare ilconnection che viene utilizzato dal modello associato

Per le modifiche che non alterano i dati della tabella o non influiscono sul modo in cui Looker interroga la tabella, Looker non creerà una tabella di sviluppo. ILpublish_as_db_view il parametro è un buon esempio: in modalità di sviluppo, se modifichi solo ilpublish_as_db_view Se si imposta una tabella derivata, Looker non ha bisogno di ricostruire la tabella derivata e quindi non creerà una tabella di sviluppo.

Per quanto tempo Looker conserva le tabelle di sviluppo

Indipendentemente dalla strategia di persistenza effettiva della tabella, Looker tratta le tabelle persistenti di sviluppo come se avessero una strategia di persistenza di persist_for: "24 hours". Looker fa questo per garantire che le tabelle di sviluppo non vengano mantenute per più di un giorno, poiché uno sviluppatore Looker potrebbe interrogare molte iterazioni di una tabella durante lo sviluppo e ogni volta che viene creata una nuova tabella di sviluppo. Per evitare che le tabelle di sviluppo ingombrino il database, Looker applica la strategia persist_for: "24 hours" per garantire che le tabelle vengano rimosse frequentemente dal database.

Altrimenti, Looker crea tabelle derivate persistenti (PDT) e tabelle aggregate in modalità di sviluppo nello stesso modo in cui crea tabelle persistenti in modalità di produzione.

Se una tabella di sviluppo è persistente nel database quando si implementano modifiche a una tabella di produzione (PDT) o a una tabella aggregata, Looker può spesso utilizzare la tabella di sviluppo come tabella di produzione, in modo che gli utenti non debbano attendere la creazione della tabella quando la interrogano.

Tieni presente che, a seconda della situazione, dopo aver implementato le modifiche, potrebbe essere necessario ricostruire la tabella prima di poterla interrogare in ambiente di produzione:

• Se sono trascorse più di 24 ore dall'ultima query eseguita sulla tabella in modalità di sviluppo, la versione di sviluppo della tabella viene contrassegnata come scaduta e non verrà utilizzata per le query. È possibile verificare la presenza di PDT non compilate utilizzando l'IDE Looker oppure utilizzando la scheda Sviluppo della pagina Tabelle derivate persistenti. Se disponi di PDT non ancora compilati, puoi interrogarli in modalità di sviluppo subito prima di apportare le modifiche, in modo che la tabella di sviluppo sia disponibile per l'utilizzo in produzione.
• Se una tabella persistente ha ildev_filters parametro (pertabelle derivate native ) o ilcondizionaleWHERE clausola che utilizza laif prod Eif dev dichiarazioni (perTabelle derivate basate su SQL ), la tabella di sviluppo non può essere utilizzata come versione di produzione, poiché la versione di sviluppo ha un set di dati abbreviato. In tal caso, dopo aver terminato lo sviluppo della tabella e prima di implementare le modifiche, è possibile commentare il parametro dev_filters o la clausola condizionale WHERE e quindi interrogare la tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che potrà essere utilizzata in produzione quando implementerai le modifiche.

Altrimenti, se si distribuiscono le modifiche quando non esiste una tabella di sviluppo valida che può essere utilizzata come tabella di produzione, Looker ricostruirà la tabella la prossima volta che la tabella viene interrogata in modalità di produzione (per le tabelle persistenti che utilizzano lapersist_for strategia), o la prossima volta cherigeneratore esegue (per tabelle persistenti che utilizzanodatagroup_trigger, interval_trigger, Osql_trigger_value ).

Verifica della presenza di PDT non compilati in modalità di sviluppo

Se una tabella di sviluppo è presente nel database quando si implementano modifiche a una tabella derivata persistente (PDT) o a una tabella aggregata, Looker può spesso utilizzare la tabella di sviluppo come tabella di produzione, in modo che gli utenti non debbano attendere la creazione della tabella quando la interrogano. Per maggiori dettagli, consultare le sezioni Per quanto tempo Looker conserva le tabelle di sviluppo e Cosa spinge Looker a creare una tabella di sviluppo di questa pagina.

Pertanto, è ottimale che tutti i PDT vengano creati al momento del deployment in produzione, in modo che le tabelle possano essere utilizzate immediatamente come versioni di produzione.

È possibile verificare la presenza di PDT non compilati nel progetto nel pannello Stato del progetto. Fai clic sull'icona Project Health nell'IDE Looker per aprire il pannello Project Health. Quindi fai clic sul pulsante Convalida stato PDT.

Se sono presenti PDT non ancora creati, il pannello Project Health li elencherà:

Se haisee_pdts autorizzazione, puoi cliccare suVai alla gestione PDT pulsante. Looker aprirà la scheda Sviluppo della pagina Tabelle derivate persistenti e filtrerà i risultati in base al tuo progetto LookML specifico. Da lì, è possibile visualizzare quali PDT di sviluppo sono stati compilati e quali no, nonché accedere ad altre informazioni per la risoluzione dei problemi. Consultare la pagina della documentazione Impostazioni di amministrazione - Tabelle derivate persistenti per ulteriori informazioni.

Una volta identificato un PDT non compilato nel progetto, è possibile crearne una versione di sviluppo aprendo un Esplora che interroga la tabella, quindi utilizzando l'opzione Ricostruisci tabelle derivate ed esegui dal menu Esplora. Consulta la sezione Ricostruzione manuale delle tabelle persistenti per una query di questa pagina.

Nota: Se una tabella persistente è unaTabella derivata basata su SQL che viene definito utilizzando uncondizionaleWHERE clausola conif prod Eif dev dichiarazioni Non sarà possibile utilizzare la versione di sviluppo della tabella in ambiente di produzione, poiché la versione di sviluppo della tabella presenta un set di dati abbreviato. Per ulteriori informazioni, consultare la sezione Per quanto tempo Looker conserva le tabelle di sviluppo di questa pagina. Pertabelle derivate native con ildev_filters parametro, Looker utilizza la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non si modifichi la definizione della tabella e quindi si esegua una query sulla tabella in modalità di sviluppo (vedere ilCosa spinge Looker a creare una tabella di sviluppo? (sezione in questa pagina di documentazione).

Condivisione del tavolo e pulizia

All'interno di una data istanza di Looker, Looker condividerà le tabelle persistenti tra gli utenti se le tabelle hanno la stessa definizione e la stessa impostazione del metodo di persistenza. Inoltre, se la definizione di una tabella cessa di esistere, Looker la contrassegna come scaduta.

Ciò presenta diversi vantaggi:

• Se non hai apportato modifiche a una tabella in modalità di sviluppo, le tue query utilizzeranno le tabelle di produzione esistenti. Questo è il caso a meno che la tua tabella non sia unaTabella derivata basata su SQL che viene definito utilizzando uncondizionaleWHERE clausola conif prod Eif dev dichiarazioni. Se la tabella è definita con una clausola condizionale WHERE, Looker creerà una tabella di sviluppo se si esegue una query sulla tabella in modalità di sviluppo. (Pertabelle derivate native con ildev_filters parametro, Looker ha la logica per usare la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non si modifichi la definizione della tabella e quindi si esegua una query sulla tabella in modalità di sviluppo.)
• Se due sviluppatori apportano la stessa modifica a una tabella mentre si trovano in modalità di sviluppo, condivideranno la stessa tabella di sviluppo.
• Una volta che le modifiche vengono trasferite dalla modalità di sviluppo alla modalità di produzione, la vecchia definizione di produzione non esiste più, quindi la vecchia tabella di produzione viene contrassegnata come scaduta e verrà eliminata.
• Se decidi di annullare le modifiche apportate alla Modalità di sviluppo, la definizione di quella tabella non esisterà più, quindi le tabelle di sviluppo non necessarie verranno contrassegnate come scadute e saranno eliminate.

Lavorare più velocemente in modalità di sviluppo

Ci sono situazioni in cui la generazione della tabella derivata persistente (PDT) che stai creando richiede molto tempo, il che può risultare dispendioso in termini di tempo se stai testando molte modifiche in modalità di sviluppo. In questi casi, puoi chiedere a Looker di creare versioni più piccole di una tabella derivata quando sei in modalità di sviluppo.

Pertabelle derivate native, puoi usare ildev_filters sottoparametro diexplore_source per specificare i filtri che vengono applicati solo alle versioni di sviluppo della tabella derivata:

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 {}
    }
  }
...
}

Questo esempio include un parametro dev_filters che filtra i dati agli ultimi 90 giorni e un parametro filters che filtra i dati agli ultimi 2 anni e all'aeroporto di Yucca Valley.

Il parametro dev_filters agisce in combinazione con il parametro filters in modo che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se entrambidev_filters Efilters specificare i filtri per la stessa colonna, dev_filters ha la precedenza per la versione di sviluppo della tabella. In questo esempio, la versione di sviluppo della tabella filtrerà i dati relativi agli ultimi 90 giorni per l'aeroporto di Yucca Valley.

Per le tabelle derivate basate su SQL, Looker supporta una clausola condizionale WHERE con diverse opzioni per le versioni di produzione (if prod) e di sviluppo (if dev) della tabella:

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

In questo esempio, la query includerà tutti i dati dal 2000 in poi quando si è in modalità di produzione, ma solo i dati dal 2020 in poi quando si è in modalità di sviluppo. Utilizzando questa funzionalità in modo strategico per limitare il set di risultati e aumentare la velocità delle query, è possibile convalidare molto più facilmente le modifiche apportate in modalità Sviluppo.

Nota: Se una tabella persistente ha il parametro dev_filters o la clausola condizionale WHERE, la tabella di sviluppo non può essere utilizzata come versione di produzione, poiché la versione di sviluppo ha un dataset abbreviato. In tal caso, dopo aver terminato lo sviluppo della tabella e prima di implementare le modifiche, è possibile commentare il parametro dev_filters o la clausola condizionale WHERE e quindi interrogare la tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che potrà essere utilizzata in produzione quando implementerai le modifiche. Consulta la sezione Per quanto tempo Looker conserva le tabelle di sviluppo di questa pagina per ulteriori dettagli sull'utilizzo delle tabelle di sviluppo in produzione.

Come Looker crea i PDT

Dopo che una tabella derivata persistente (PDT) è stata definita e viene eseguita per la prima volta o attivata dal regenerator per la ricostruzione secondo la sua strategia di persistenza, Looker eseguirà i seguenti passaggi:

1. Utilizza la query SQL della tabella derivata per creare un'istruzione CREATE TABLE AS SELECT (o CTAS) ed eseguirla. Ad esempio, per ricostruire un PDT chiamato customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Eseguire le istruzioni per creare gli indici quando la tabella viene creata
3. Rinominare la tabella da LC$.. ("Looker Create") a LR$.. ("Looker Read") per indicare che la tabella è pronta per l'uso.
4. Elimina qualsiasi versione precedente della tabella che non dovrebbe più essere utilizzata.

Ciò comporta alcune importanti implicazioni:

• Il codice SQL che costituisce la tabella derivata deve essere valido all'interno di un'istruzione CTAS.
• Gli alias delle colonne nel set di risultati dell'istruzione SELECT devono essere nomi di colonna validi.
• I nomi utilizzati per specificare la distribuzione, le chiavi di ordinamento e gli indici devono essere i nomi delle colonne elencati nella definizione SQL della tabella derivata, non i nomi dei campi definiti nel LookML.

Il rigeneratore Looker

Il rigeneratore Looker controlla lo stato e avvia la ricostruzione delle tabelle rese persistenti dai trigger. Una tabella persistente tramite trigger è una tabella derivata persistente (PDT) o una tabella aggregata aggregata che utilizza un trigger come strategia di persistenza:

• Per le tabelle che utilizzanosql_trigger_value, il trigger è una query specificata nella tabellasql_trigger_value parametro. Il rigeneratore Looker attiva la ricostruzione della tabella quando il risultato dell'ultimo controllo della query di attivazione è diverso dal risultato del controllo della query di attivazione precedente. Ad esempio, se la tabella derivata viene salvata con la query SQL SELECT CURDATE(), il rigeneratore Looker ricostruirà la tabella la prossima volta che controllerà il trigger dopo la modifica della data.
• Per le tabelle che utilizzanointerval_trigger, il trigger è una durata temporale specificata nella tabellainterval_trigger parametro. Il rigeneratore Looker avvia la ricostruzione della tabella al termine del tempo specificato.
• Per le tabelle che utilizzanodatagroup_trigger, il trigger può essere una query specificata nel datagroup associatosql_trigger parametro, oppure il trigger può essere una durata temporale specificata nel datagroupinterval_trigger parametro.

Il rigeneratore Looker avvia anche le ricostruzioni per le tabelle persistenti che utilizzano ilpersist_for parametro, ma solo quando ilpersist_for la tabella è una dipendenzacascata di una tabella persistente attivata da un trigger. In questo caso, il rigeneratore Looker avvierà la ricostruzione di una tabella persist_for, poiché tale tabella è necessaria per ricostruire le altre tabelle nella cascata. Altrimenti, il rigeneratore non monitora le tabelle persistenti che utilizzano la strategia persist_for.

Inoltre, il rigeneratore Looker creamodelli analitici nel tuo database, se hai definito il modello analitico utilizzando ilderived_analytic_model parametro. Il rigeneratore Looker elabora modelli analitici derivati ​​in modo simile ai PDT che sono viste materializzate. Sia le viste materializzate che i modelli analitici derivati ​​vengono creati una sola volta e non supportano trigger, come trigger di gruppo di dati, trigger SQL o trigger di intervallo. Il rigeneratore Looker ricrea i modelli analitici nel database solo se la loro definizione LookML cambia o se cambia una qualsiasi delle viste LookML da cui dipendono.

Il ciclo di rigenerazione di Looker inizia a intervalli regolari configurati dall'amministratore di Looker nell'impostazione Programmazione di manutenzione della connessione al database (l'impostazione predefinita è un intervallo di cinque minuti). Tuttavia, il rigeneratore Looker non avvia un nuovo ciclo finché non ha completato tutti i controlli e le ricostruzioni PDT del ciclo precedente. Ciò significa che se si hanno build PDT di lunga durata, il ciclo di rigenerazione di Looker potrebbe non essere eseguito con la frequenza definita nell'impostazione Programmazione di manutenzione. Altri fattori possono influenzare il tempo necessario per ricostruire le tabelle, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle persistenti di questa pagina.

Nei casi in cui la creazione di una PDT non riesce, il rigeneratore può tentare di ricostruire la tabella nel ciclo di rigenerazione successivo:

• Se l'impostazione Retry Failed PDT Builds è abilitata sulla connessione al database, il rigeneratore Looker tenterà di ricostruire la tabella durante il ciclo di rigenerazione successivo, anche se la condizione di attivazione della tabella non viene soddisfatta.
• Se l'impostazione Retry Failed PDT Builds è disabilitata, il rigeneratore Looker non tenterà di ricostruire la tabella finché non verrà soddisfatta la condizione di attivazione del PDT.

Se un utente richiede dati dalla tabella persistente mentre questa è in fase di creazione e i risultati della query non sono presenti nella cache, Looker verifica se la tabella esistente è ancora valida. (La tabella precedente potrebbe non essere valida se non è compatibile con la nuova versione della tabella, il che può accadere se la nuova tabella ha una definizione diversa, utilizza una connessione al database diversa o è stata creata con una versione diversa di Looker.) Se la tabella esistente è ancora valida, Looker restituirà i dati da tale tabella fino alla creazione della nuova. Altrimenti, se la tabella esistente non è valida, Looker fornirà i risultati della query una volta ricostruita la nuova tabella.

Considerazioni importanti per l'implementazione delle tabelle persistenti

Considerando l'utilità delle tabelle persistenti (PDT etabelle aggregate ), è possibile accumularne molti sulla tua istanza Looker. È possibile creare uno scenario in cui il Looker regenerator deve costruire molte tabelle contemporaneamente. Soprattutto contavoli a cascata, o tabelle a lunga esecuzione, è possibile creare uno scenario in cui le tabelle presentano un lungo ritardo prima di essere ricostruite, oppure in cui gli utenti riscontrano un ritardo nell'ottenere i risultati delle query da una tabella mentre il database sta lavorando intensamente per generare la tabella.

Il Looker regenerator controlla i trigger PDT per vedere se deve ricostruire le tabelle rese persistenti dai trigger. Il ciclo di rigenerazione è impostato a intervalli regolari configurati dall'amministratore di Looker nell'impostazione Programmazione di manutenzione della connessione al database (l'impostazione predefinita è un intervallo di cinque minuti).

Diversi fattori possono influenzare il tempo necessario per ricostruire le tabelle:

• L'amministratore di Looker potrebbe aver modificato l'intervallo dei controlli del trigger del rigeneratore utilizzando l'impostazione Programmazione di manutenzione sulla connessione al database.
• Il rigeneratore Looker non avvia un nuovo ciclo finché non ha completato tutti i controlli e le ricostruzioni PDT del ciclo precedente. Pertanto, se si utilizzano build PDT di lunga durata, il ciclo di rigenerazione di Looker potrebbe non essere frequente quanto l'impostazione Programmazione di manutenzione.
• Per impostazione predefinita, il rigeneratore può avviare la ricostruzione di una tabella PDT o di una tabella aggregata alla volta tramite una connessione. Un amministratore di Looker può regolare il numero di ricostruzioni simultanee consentite dal rigeneratore utilizzando il campo Numero massimo di connessioni del costruttore PDT nelle impostazioni di una connessione.
• Tutti i PDT e le tabelle aggregate attivati ​​dallo stessodatagroup verrà ricostruito durante lo stesso processo di rigenerazione. Questo può rappresentare un carico pesante se si hanno molte tabelle che utilizzano il gruppo di dati, direttamente o come risultato di dipendenze a cascata.

Oltre alle considerazioni precedenti, ci sono anche alcune situazioni in cui è opportuno evitare di aggiungere la persistenza a una tabella derivata:

• Quando le tabelle derivate verranno estese — Ogni estensione di una PDT creerà una nuova copia della tabella nel tuo database.
• Quando si utilizzano le tabelle derivatefiltri preimpostati o parametri del liquido — La persistenza non è supportata per le tabelle derivate che utilizzano filtri basati su modelli o parametri Liquid.
• Quandotabelle derivate native sono costruiti da Esplora che utilizzanoattributi utente conaccess_filters, o consql_always_where — Nel database verranno create copie della tabella per ogni possibile valore dell'attributo utente specificato.
• Quando i dati sottostanti cambiano frequentemente e il dialetto del database non supporta PDT incrementali.
• Quando i costi e i tempi necessari per la creazione dei PDT sono troppo elevati.

A seconda del numero e della complessità delle tabelle persistenti sulla connessione Looker, la coda potrebbe contenere molte tabelle persistenti che devono essere controllate e ricostruite a ogni ciclo; pertanto, è importante tenere a mente questi fattori quando si implementano tabelle derivate sull'istanza Looker.

Gestione di PDT su larga scala tramite API

Il monitoraggio e la gestione delle tabelle derivate persistenti (PDT) che si aggiornano con intervalli variabili diventano sempre più complessi man mano che si crea un numero maggiore di PDT nella propria istanza. Valuta la possibilità di utilizzare l'integrazione Looker Apache Airflow per gestire le pianificazioni PDT insieme agli altri processi ETL ed ELT.

Monitoraggio e risoluzione dei problemi dei PDT

Se si utilizzano tabelle derivate persistenti (PDT), e in particolare le PDT cascading, è utile visualizzare lo stato delle PDT. È possibile utilizzare la pagina di amministrazione Looker Persistent Derived Tables per visualizzare lo stato delle proprie PDT. È inoltre possibile consultare l'albero di risoluzione dei problemi PDT per una procedura di debug passo passo.

Quando si tenta di risolvere i problemi dei PDT:

• Presta particolare attenzione alla distinzione tra tabelle di sviluppo e tabelle di produzione quando esamini il registro eventi PDT.
• Verifica che l'impostazione Database temporaneo nella connessione Looker corrisponda allo schema o al database temporaneo effettivo. Se l'impostazione Temp Database sulla connessione non corrisponde allo schema temporaneo del database, aggiorna l'impostazione Temp Database in modo che Looker possa memorizzare tabelle derivate persistenti nel database.
• Determinare se i problemi riguardano tutti i PDT o solo uno. Se si verifica un problema con uno, è probabile che sia causato da un errore LookML o SQL.
• Verificare se i problemi con il PDT coincidono con i periodi in cui è prevista la sua ricostruzione.
• Assicurati che tutte le query sql_trigger_value vengano valutate correttamente e che restituiscano una sola riga e colonna. Per i PDT basati su SQL, è possibile farlo eseguendoli in SQL Runner. (L'applicazione di LIMIT protegge dalle query incontrollate.) Per ulteriori informazioni sull'utilizzo di SQL Runner per il debug delle tabelle derivate, consulta il post della Community Utilizzo di SQL Runner per testare le tabelle derivate .
• Per le PDT basate su SQL, utilizza SQL Runner per verificare che l'SQL della PDT venga eseguito senza errori. Assicurati di applicare un LIMIT in SQL Runner per mantenere tempi di query ragionevoli.
• Per le tabelle derivate basate su SQL, evita di utilizzare le espressioni di tabella comuni (CTE). L'utilizzo di CTE con DT crea istruzioni WITH annidate che possono causare il fallimento dei PDT senza preavviso. Invece, usa l'SQL per la tua CTE per creare un DT secondario e fai riferimento a quel DT dal tuo primo DT usando il${derived_table_or_view_name.SQL_TABLE_NAME} sintassi.
• Verificare che tutte le tabelle da cui dipende il PDT problematico, siano esse tabelle normali o PDT stesse, esistano e siano interrogabili.
• Assicurati che le tabelle da cui dipende il PDT problematico non abbiano blocchi condivisi o esclusivi. Affinché Looker possa creare con successo un PDT, deve acquisire un blocco esclusivo sulla tabella che deve essere aggiornata. Ciò entrerà in conflitto con altri blocchi condivisi o esclusivi presenti sul tavolo. Looker non sarà in grado di aggiornare il PDT finché tutti gli altri blocchi non saranno stati rimossi. Lo stesso vale per i blocchi esclusivi sulla tabella da cui Looker sta creando una PDT: se è presente un blocco esclusivo su una tabella, Looker non potrà acquisire un blocco condiviso per eseguire query finché il blocco esclusivo non viene rimosso.
• Utilizza il pulsante Mostra processi in SQL Runner. Se è attivo un numero elevato di processi, i tempi di esecuzione delle query potrebbero rallentare.
• Monitora i commenti nella query. Consulta la sezione Commenti di query per PDT in questa pagina.

• Quando si utilizzano funzioni di data specifiche del database (come current_date()) nella query SQL di una tabella derivata, esiste il rischio di una discrepanza di fuso orario tra la sessione Looker dell'utente e il database sottostante. Poiché le funzioni del database vengono eseguite direttamente all'interno del database e non vengono sottoposte alla conversione del fuso orario delle query di Looker, questa discrepanza può causare risultati inattesi nei filtri data (ad esempio, un filtro data per "Ieri" potrebbe risultare pari a due giorni fa, vicino alla mezzanotte).

  Per risolvere questo problema, assicurati che il fuso orario tra il tuo database e l'istanza di Looker sia corretto, operazione che potrebbe richiedere il coordinamento con il tuo team di Data Engineering.

• Se riscontri un errore 409 Conflict durante l'aggiornamento di un PDT in strutture PDT profondamente annidate (catene di PDT a cascata con più livelli di dipendenza), consulta la sezione Risoluzione dei problemi relativi agli errori di conflitto 409 nei PDT profondamente annidati di questa pagina.

Commenti di query per PDT

Gli amministratori di database possono distinguere le query normali da quelle che generano tabelle derivate persistenti (PDT). Looker aggiunge commenti all'istruzione CREATE TABLE ... AS SELECT ... che include il modello LookML e la vista del PDT, oltre a un identificatore univoco (slug) per l'istanza di Looker. Se il PDT viene generato per conto di un utente in modalità di sviluppo, i commenti indicheranno l'ID utente. I commenti relativi alla generazione del PDT seguono questo schema:

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

Il commento relativo alla generazione del PDT verrà visualizzato nella scheda SQL di un Esplora se Looker ha dovuto generare un PDT per la query di Esplora. Il commento apparirà all'inizio dell'istruzione SQL.

Infine, il commento di generazione PDT appare nel campo Messaggio nella scheda Informazioni del pop-up Dettagli query per ogni query nella pagina di amministrazione Query.

Ricostruzione dei PDT dopo un guasto

Quando una tabella derivata persistente (PDT) presenta un errore, ecco cosa accade quando si esegue una query su tale PDT:

• Looker utilizzerà i risultati presenti nella cache se la stessa query è stata eseguita in precedenza. (Vedi la pagina della documentazione Memorizzazione nella cache delle query per una spiegazione del funzionamento.)
• Se i risultati non sono presenti nella cache, Looker recupererà i risultati dal PDT presente nel database, qualora esista una versione valida del PDT.
• Se nel database non è presente un PDT valido, Looker tenterà di ricostruirlo.
• Se il PDT non può essere ricostruito, Looker restituirà un errore per la query. Il rigeneratore Looker tenterà di ricostruire il PDT la prossima volta che il PDT viene interrogato o la prossima volta che la strategia di persistenza del PDT attiva una ricostruzione.

Con i PDT cascading, si applica la stessa logica, tranne che con i PDT a cascata:

• Un errore nella compilazione di una tabella impedisce la compilazione dei PDT lungo la catena di dipendenza.
• Un PDT dipendente interroga essenzialmente il PDT da cui dipende, quindi la strategia di persistenza di una tabella può innescare la ricostruzione dei PDT in corsosu la catena.

Riprendendo l'esempio precedente di tabelle a cascata, dove TABLE_D dipende da TABLE_C, che dipende da TABLE_B, che dipende da TABLE_A:

Se TABLE_B presenta un errore, si applica tutto il comportamento standard (non a cascata) per TABLE_B:

1. Se viene interrogato TABLE_B, Looker tenta prima di tutto di utilizzare la cache per restituire i risultati.
2. Se questo tentativo fallisce, Looker prova a utilizzare una versione precedente della tabella, se possibile.
3. Se anche questo tentativo fallisce, Looker prova a ricostruire la tabella.
4. Infine, se TABLE_B non può essere ricostruito, Looker restituirà un errore.

Looker tenterà nuovamente di ricostruire TABLE_B alla successiva interrogazione della tabella o al successivo avvio di una ricostruzione da parte della strategia di persistenza della tabella.

Lo stesso vale anche per i dipendenti di TABLE_B. Quindi, se TABLE_B non può essere costruito e c'è una query su TABLE_C, si verifica la seguente sequenza:

1. Looker tenterà di utilizzare la cache per la query su TABLE_C.
2. Se i risultati non sono presenti nella cache, Looker tenterà di recuperare i risultati da TABLE_C nel database.
3. Se non esiste una versione valida di TABLE_C, Looker tenterà di ricostruire TABLE_C, il che crea una query su TABLE_B.
4. Looker tenterà quindi di ricostruire TABLE_B (operazione che fallirà se TABLE_B non è stato riparato).
5. SeTABLE_B non può essere ricostruito, quindiTABLE_C non è possibile ricostruire, quindi Looker restituirà un errore per la query suTABLE_C.
6. Looker tenterà quindi di ricostruire TABLE_C secondo la sua solita strategia di persistenza, oppure la prossima volta che viene interrogato il PDT (il che include la prossima volta che TABLE_D tenta di essere costruito, poiché TABLE_D dipende da TABLE_C).

Una volta risolto il problema con TABLE_B, allora TABLE_B e ciascuna delle tabelle dipendenti tenteranno di ricostruirsi in base alle proprie strategie di persistenza, oppure la prossima volta che verranno interrogate (il che include la prossima volta che una PDT dipendente tenta di ricostruirsi). Oppure, se in modalità di sviluppo è stata creata una versione di sviluppo dei PDT nella cascata, tali versioni di sviluppo possono essere utilizzate come nuovi PDT di produzione. (Vedi la sezione Tabelle persistenti in modalità di sviluppo di questa pagina per capire come funziona.) Oppure puoi usare un Esplora per eseguire una query su TABLE_D e poi ricostruire manualmente i PDT per la query, il che forzerà la ricostruzione di tutti i PDT risalendo la cascata delle dipendenze.

Risoluzione dei problemi relativi agli errori di conflitto 409 nei PDT annidati in profondità

Quando si lavora con strutture PDT profondamente annidate (catene di PDT a cascata con più livelli di dipendenza), la configurazione di brevi periodi di conservazione della cache (ad esempio, 15 minuti) può causare una race condition che si traduce in un errore 409 Conflict durante l'aggiornamento.

Questa race condition si verifica perché la cache per i PDT annidati di livello inferiore potrebbe scadere mentre i PDT di livello superiore sono ancora in fase di creazione. Quando si verifica questa situazione, Looker attiva una nuova richiesta di build duplicata per i PDT di livello inferiore mentre il job iniziale è ancora in fase di elaborazione nel data warehouse, il che provoca il conflitto.

Per risolvere o prevenire questo errore, si consiglia di seguire le seguenti procedure consigliate:

• Aumentare il periodo di conservazione della cache: Imposta il periodo di conservazione della cache (max_cache_age Opersist_for ) per i PDT ad almeno due o tre volte il tempo massimo necessario per completare la costruzione completa di tutti i PDT annidati.
• Aumenta l'intervallo di aggiornamento del gruppo di dati: Consenti un tempo adeguato per il completamento delle build PDT annidate in profondità, riducendo il rischio di sovrapposizione dei processi di build.

Migliorare le prestazioni della terapia fotodinamica

Quando tucreare tabelle derivate persistenti (PDT) le prestazioni possono essere un problema. Soprattutto quando la tabella è molto grande, l'interrogazione della tabella può risultare lenta, proprio come può accadere per qualsiasi tabella di grandi dimensioni nel database.

È possibile migliorare le prestazioni tramitefiltraggio dei dati o dacontrollo del modo in cui i dati nel PDT vengono ordinati e indicizzati.

Aggiunta di filtri per limitare il set di dati

Con set di dati particolarmente grandi, la presenza di molte righe rallenterà le query su una tabella derivata persistente (PDT). Se di solito si interrogano solo i dati recenti, si consiglia di aggiungere un filtro alla clausola WHERE della tabella PDT che limiti la tabella ai dati degli ultimi 90 giorni. In questo modo, solo i dati rilevanti verranno aggiunti alla tabella ogni volta che viene ricostruita, rendendo l'esecuzione delle query molto più veloce. Successivamente, è possibile creare un PDT separato e più ampio per l'analisi storica, che consentirà sia query rapide sui dati recenti sia la possibilità di interrogare i dati meno recenti.

Utilizzandoindexes Osortkeys Edistribution

Quando si crea una tabella derivata persistente (PDT) di grandi dimensioni, l'indicizzazione della tabella (per dialetti come MySQL o PostgreSQL) o l'aggiunta di chiavi di ordinamento e distribuzione (per Redshift) possono contribuire a migliorare le prestazioni.

Di solito è meglio aggiungere ilindexes parametro sui campi ID o data.

Per Redshift, di solito è meglio aggiungere ilsortkeys parametro sui campi ID o data e ildistribution parametro sul campo utilizzato per l'unione.

Impostazioni consigliate per migliorare le prestazioni

Le seguenti impostazioni controllano l'ordinamento e l'indicizzazione dei dati nella tabella derivata persistente (PDT). Queste impostazioni sono facoltative, ma altamente consigliate:

• Per Redshift e Aster, utilizzare ildistribution parametro per specificare il nome della colonna il cui valore viene utilizzato per distribuire i dati all'interno di un cluster. Quando due tabelle vengono unite tramite la colonna specificata nel parametro distribution, il database può trovare i dati di join sullo stesso nodo, riducendo al minimo le operazioni di I/O tra i nodi.
• Per Redshift, impostare ildistribution_style parametro daall per istruire il database a conservare una copia completa dei dati su ciascun nodo. Questa tecnica viene spesso utilizzata per ridurre al minimo le operazioni di I/O tra i nodi quando si uniscono tabelle di dimensioni relativamente ridotte. Imposta questo valore su even per indicare al database di distribuire i dati in modo uniforme nel cluster senza utilizzare una colonna di distribuzione. Questo valore può essere specificato solo quando distribution non è specificato.
• Per Redshift, utilizzare ilsortkeys parametro. I valori specificano quali colonne della tabella dei dati personali (PDT) vengono utilizzate per ordinare i dati su disco, in modo da semplificare la ricerca. Su Redshift, è possibile utilizzare sortkeys o indexes, ma non entrambi.
• Nella maggior parte dei database, utilizzare ilindexes parametro. I valori specificano quali colonne del PDT sono indicizzate. (Su Redshift, gli indici vengono utilizzati per generare chiavi di ordinamento interlacciate.)