Tabelle derivate in Looker

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

Ad esempio, potresti avere una tabella di database chiamata orders che ha molte colonne. Vuoi calcolare alcune metriche aggregate a livello di cliente, ad esempio quanti ordini ha effettuato ogni cliente o quando ogni cliente ha effettuato il 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 includa queste metriche.

Puoi quindi lavorare con la tabella derivata customer_order_summary come se fosse qualsiasi altra tabella nel database.

Per i casi d'uso più diffusi delle tabelle derivate, consulta Libri di ricette di Looker: ottenere il massimo dalle tabelle derivate in Looker.

Tabelle derivate native e tabelle derivate basate su SQL

Per creare una tabella derivata nel 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 uno dei due seguenti modi:

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

Ad esempio, i seguenti file di vista mostrano come utilizzare LookML per creare una vista da una tabella derivata customer_order_summary. Le due versioni di LookML illustrano 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 vista orders esistente, definita in un file separato non mostrato in questo esempio. La query explore_source nella tabella derivata nativa include i campi customer_id, first_order e total_amount dal file di visualizzazione 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 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 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 che si basa sulla tabella orders, con le colonne customer_id, first_order, e total_amount.

A parte il parametro derived_table e i relativi sottoparametri, questa vista customer_order_summary funziona come qualsiasi altro file di visualizzazione. Sia che definisci la query della tabella derivata con LookML o SQL, puoi creare misure e dimensioni LookML basate sulle colonne della tabella derivata.

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

Tabelle derivate native

Le tabelle derivate native si basano su query che definisci utilizzando i termini LookML. Per creare una tabella derivata nativa, utilizza il parametro explore_source all'interno del parametro derived_table di un parametro view. Puoi creare le colonne della tabella derivata nativa facendo riferimento alle dimensioni o alle misure LookML nel modello. Visualizza il file di visualizzazione tabella derivata nativo 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.

Per maggiori dettagli sulla creazione di tabelle derivate native, consulta la pagina della documentazione relativa alla creazione di tabelle derivate native.

Tabelle derivate basate su SQL

Per creare una tabella derivata basata su SQL, devi definire una query in termini SQL, creando colonne nella tabella utilizzando una query SQL. Non puoi fare riferimento a dimensioni e misure LookML in una tabella derivata basata su SQL. Consulta il file di visualizzazione della tabella derivata basato su SQL nell'esempio precedente.

Più comunemente, la query SQL viene definita utilizzando il parametro sql all'interno del parametro derived_table di un parametro view.

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.

Alcuni casi limite non consentono l'utilizzo del parametro sql. In questi casi, Looker supporta i seguenti parametri per definire una query SQL per le tabelle derivate permanenti (PDT):

• create_process: quando utilizzi il parametro sql per una PDT, in background Looker inserisce l'CREATE TABLE istruzione DDL (Data Definition Language) del dialetto attorno alla query per creare la PDT dalla query SQL. Alcuni dialetti non supportano un'istruzione SQL CREATE TABLE in un unico passaggio. Per questi dialetti, non puoi creare una PDT con il parametro sql. In alternativa, puoi utilizzare il parametro create_process per creare una PDT in più passaggi. Consulta la pagina della documentazione relativa al parametro create_process per informazioni ed esempi.
• sql_create: se il tuo caso d'uso richiede comandi DDL personalizzati e il tuo dialetto supporta il linguaggio DDL (ad esempio, il parametro predittivo BigQuery ML di Google), puoi utilizzare il parametro sql_create per creare una PDT anziché utilizzare il parametro sql. Consulta la pagina della documentazione di sql_create per informazioni ed esempi.

A prescindere dal fatto che utilizzi il parametro sql, create_process o sql_create, in tutti questi casi definisci la tabella derivata con una query SQL, pertanto vengono tutte considerate tabelle derivate basate su SQL.

Quando definisci una tabella derivata basata su SQL, assicurati di assegnare a ogni colonna un alias pulito utilizzando AS. Questo accade perché nelle dimensioni dovrai fare riferimento ai nomi delle colonne del set di risultati, ad esempio ${TABLE}.first_order. Questo è il motivo per cui l'esempio precedente utilizza MIN(DATE(time)) AS first_order anziché semplicemente MIN(DATE(time)).

Nota: per essere utilizzata come PDT incrementale, una tabella derivata basata su SQL deve essere definita utilizzando il parametro sql. Le tabelle derivate basate su SQL definite con il parametro sql_create o il parametro create_process non possono essere create in modo incrementale.

Tabelle derivate temporanee e permanenti

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), scritta in uno schema del database.

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

Tabelle derivate temporanee

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

Le tabelle derivate temporanee non vengono scritte nel database. Quando un utente esegue una query di esplorazione che interessa una o più tabelle derivate, Looker crea una query SQL utilizzando una combinazione specifica del dialetto dell'SQL per le tabelle derivate più i campi, le unioni e i valori dei filtri richiesti. Se la combinazione è già stata eseguita in precedenza e i risultati sono ancora validi nella cache, Looker utilizza i risultati memorizzati nella cache. Per ulteriori informazioni sulla memorizzazione nella cache delle query in Looker, consulta la pagina della documentazione relativa alla memorizzazione delle query nella cache.

Altrimenti, se Looker non può utilizzare i risultati memorizzati nella cache, deve eseguire una nuova query sul tuo database ogni volta che un utente richiede dati da una tabella derivata temporanea. Per questo motivo, devi assicurarti che le tabelle derivate temporanee abbiano prestazioni elevate e non sovraccaricano il database. Nei casi in cui l'esecuzione della query richieda un po' di tempo, una PDT è spesso un'opzione migliore.

Dialetti di database supportati per le tabelle derivate temporanee

Affinché Looker supporti le tabelle derivate nel tuo progetto Looker, è necessario che anche il dialetto del database le supporti. La tabella seguente mostra quali dialetti supportano le tabelle derivate nella versione più recente di Looker:

Dialetto	Supportato?
Valanga atiana	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Apache drud	Sì
Apache Druid 0.13 e versioni successive	Sì
Apache Druid 0.18 e versioni successive	Sì
Apache Hive 2.3 e versioni successive	Sì
Apache Hive 3.1.2 o versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	Sì
Cloudera Impala 3.1 o versioni successive	Sì
Cloudera Impala 3.1+ con driver nativo	Sì
Cloudera Impala con driver nativo	Sì
DataVirtuality	Sì
Databricks	Sì
Denodo 7	Sì
Denodo 8	Sì
Dremio	Sì
Dremio 11+	Sì
Exasol	Sì
Firebolt	Sì
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	Sì
Google Spanner	Sì
Verde prugna	Sì
HyperSQL	Sì
IBM Netezza	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	Sì
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
ADWC Oracle	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7 o versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettore	Sì
Vertica	Sì

Tabelle derivate permanenti

Una tabella derivata permanente (PDT) è una tabella derivata scritta in uno schema temporaneo nel database e rigenerata in base alla pianificazione specificata con una strategia di persistenza.

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

Requisiti per le PDT

Per utilizzare le tabelle derivate permanenti (PDT) nel progetto Looker, devi disporre di quanto segue:

• Un dialetto del database che supporta le PDT. Consulta la sezione Dialetti di database supportati per le PDT più avanti in questa pagina per gli elenchi di dialetti che supportano le tabelle derivate basate su SQL permanenti e le tabelle derivate native permanenti.
• Uno schema temporaneo sul tuo database. Può trattarsi di qualsiasi schema del database, ma ti consigliamo di creare un nuovo schema che verrà utilizzato solo a questo scopo. L'amministratore del database deve configurare lo schema con autorizzazione di scrittura per l'utente del database Looker.
• Una connessione Looker configurata con l'opzione Abilita PDT attivata. In genere questo viene configurato quando configuri per la prima volta la connessione Looker (per istruzioni sul dialetto del database, consulta la pagina della documentazione relativa ai dialetti di Looker), ma puoi anche abilitare le PDT per la connessione dopo la configurazione iniziale.

Dialetti di database supportati per le PDT

Affinché Looker supporti le tabelle derivate permanenti (PDT) nel tuo progetto Looker, è necessario che anche il dialetto del tuo database le supporti.

Per supportare qualsiasi tipo di PDT (basata su LookML o 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 database di replica hot-swap Postgres). In questi casi, puoi utilizzare invece le tabelle derivate temporanee.

La tabella seguente mostra i dialetti che supportano le tabelle derivate basate su SQL permanenti nell'ultima versione di Looker:

Dialetto	Supportato?
Valanga atiana	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Apache drud	No
Apache Druid 0.13 e versioni successive	No
Apache Druid 0.18 e versioni successive	No
Apache Hive 2.3 e versioni successive	Sì
Apache Hive 3.1.2 o versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	Sì
Cloudera Impala 3.1+ con driver nativo	Sì
Cloudera Impala con driver nativo	Sì
DataVirtuality	No
Databricks	Sì
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11+	No
Exasol	Sì
Firebolt	No
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	Sì
Google Spanner	No
Verde prugna	Sì
HyperSQL	No
IBM Netezza	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
ADWC Oracle	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7 o versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettore	Sì
Vertica	Sì

Per supportare le tabelle derivate native permanenti (con query basate su LookML), il dialetto deve supportare anche una funzione DDL di CREATE TABLE. Di seguito è riportato un elenco dei dialetti che supportano le tabelle derivate native (basate su LookML) permanenti nell'ultima release di Looker:

Dialetto	Supportato?
Valanga atiana	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Apache drud	No
Apache Druid 0.13 e versioni successive	No
Apache Druid 0.18 e versioni successive	No
Apache Hive 2.3 e versioni successive	Sì
Apache Hive 3.1.2 o versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	Sì
Cloudera Impala 3.1+ con driver nativo	Sì
Cloudera Impala con driver nativo	Sì
DataVirtuality	No
Databricks	Sì
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11+	No
Exasol	Sì
Firebolt	No
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	No
Google Spanner	No
Verde prugna	Sì
HyperSQL	No
IBM Netezza	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
ADWC Oracle	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7 o versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettore	Sì
Vertica	Sì

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

Creazione incrementale di PDT

Una PDT incrementale è una tabella derivata permanente (PDT) che Looker crea aggiungendo dati aggiornati alla tabella anziché ricrearla nella sua interezza.

Se il tuo dialetto supporta PDT incrementali e la PDT utilizza una strategia di persistenza basata su trigger (datagroup_trigger, sql_trigger_value o interval_trigger), puoi definire la PDT come una PDT incrementale.

Nota: le PDT incrementali non sono supportate per le PDT che utilizzano la strategia di persistenza persist_for.

Per ulteriori informazioni, consulta la pagina della documentazione relativa alle PDT incrementali.

Dialetti di database supportati per PDT incrementali

Affinché Looker possa supportare le PDT incrementali nel progetto Looker, è necessario che anche il dialetto del database le supporti. La tabella seguente mostra quali dialetti supportano le PDT incrementali nell'ultima release di Looker:

Dialetto	Supportato?
Valanga atiana	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sì
Apache drud	No
Apache Druid 0.13 e versioni successive	No
Apache Druid 0.18 e versioni successive	No
Apache Hive 2.3 e versioni successive	No
Apache Hive 3.1.2 o versioni successive	No
Apache Spark 3 e versioni successive	No
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	No
Cloudera Impala 3.1+ con driver nativo	No
Cloudera Impala con driver nativo	No
DataVirtuality	No
Databricks	Sì
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11+	No
Exasol	No
Firebolt	No
SQL precedente di Google BigQuery	No
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	No
Google Spanner	No
Verde prugna	Sì
HyperSQL	No
IBM Netezza	No
MariaDB	No
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	No
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	No
Microsoft SQL Server 2012 e versioni successive	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 e versioni successive	No
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	No
ADWC Oracle	No
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	No
PrestoSQL	No
SAP HANA	No
SAP HANA 2 o versioni successive	No
SingleStore	No
SingleStore 7 o versioni successive	No
Snowflake	Sì
Teradata	No
Trino	No
Vettore	No
Vertica	Sì

Creazione di PDT

Per trasformare una tabella derivata in una tabella derivata permanente (PDT), devi definire una strategia di persistenza per la tabella. Per ottimizzare il rendimento, devi 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 permanente una tabella derivata, aggiungi uno dei seguenti parametri alla definizione di 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 conserva la PDT nel database finché non viene attivata per la nuova creazione. Quando viene attivata, Looker ricrea la PDT per sostituire la versione precedente. Ciò significa che, con le PDT basate su trigger, gli utenti non dovranno attendere la creazione della PDT per ricevere risposte alle query su Esplora dalla PDT.

Nota: alcuni utenti possono sostituire l'impostazione di persistenza di una PDT. Un utente con l'autorizzazione develop può utilizzare l'opzione Ricrea le tabelle derivate ed esegui dal menu di un'esplorazione per eseguire l'override dell'impostazione di persistenza e ricreare tutte le PDT necessarie per la query corrente nell'esplorazione. Per maggiori dettagli, consulta la sezione Ricreare manualmente le PDT per una query in questa pagina.

datagroup_trigger

I gruppi di dati sono il metodo più flessibile per creare la persistenza. Se hai definito un gruppo di dati con sql_trigger o interval_trigger, puoi utilizzare il parametro datagroup_trigger per avviare la nuova creazione delle tabelle derivate permanenti (PDT).

Looker conserva la PDT nel database fino all'attivazione del relativo gruppo di dati. Quando il gruppo di dati viene attivato, Looker ricrea la PDT per sostituire la versione precedente. Ciò significa che, nella maggior parte dei casi, gli utenti non dovranno attendere la creazione della PDT. Se un utente richiede dati alla PDT durante la creazione e i risultati della query non sono nella cache, Looker restituirà i dati della PDT esistente fino alla creazione della nuova PDT. Per una panoramica dei gruppi di dati, consulta Memorizzazione nella cache delle query.

Per saperne di più su come il rigeneratore crea PDT, consulta la sezione Il rigeneratore Looker.

sql_trigger_value

Il parametro sql_trigger_value attiva la rigenerazione di una tabella derivata permanente (PDT) in base a un'istruzione SQL fornita da te. Se il risultato dell'istruzione SQL è diverso dal valore precedente, la PDT viene rigenerata. In caso contrario, la PDT esistente viene mantenuta nel database. Ciò significa che, nella maggior parte dei casi, gli utenti non dovranno attendere la creazione della PDT. Se un utente richiede dati alla PDT durante la creazione e i risultati della query non sono nella cache, Looker restituirà i dati della PDT esistente fino alla creazione della nuova PDT.

Per saperne di più su come il rigeneratore crea PDT, consulta la sezione Il rigeneratore Looker.

interval_trigger

Il parametro interval_trigger attiva la rigenerazione di una tabella derivata permanente (PDT) in base a un intervallo di tempo fornito, ad esempio "24 hours" o "60 minutes". Analogamente al parametro sql_trigger, questo significa che in genere la PDT sarà preconfigurata quando gli utenti la eseguono query. Se un utente richiede dati alla PDT durante la creazione e i risultati della query non sono nella cache, Looker restituirà i dati della PDT esistente fino alla creazione della nuova PDT.

persist_for

Un'altra opzione consiste nell'utilizzare il parametro persist_for per impostare il periodo di tempo in cui la tabella derivata deve essere archiviata prima di essere contrassegnata come scaduta, in modo che non venga più utilizzata per le query e venga eliminata dal database.

Una tabella derivata permanente (PDT) persist_for viene creata quando un utente esegue per la prima volta una query su questa tabella. Looker conserva quindi la PDT nel database per il periodo di tempo specificato nel parametro persist_for della PDT. Se un utente esegue una query sulla PDT entro persist_for, Looker utilizza i risultati memorizzati nella cache, se possibile, oppure esegue la query sulla PDT.

Dopo il persist_for tempo, Looker cancella la PDT dal database e verrà ricreata alla successiva query di un utente, il che significa che la query dovrà attendere la nuova creazione.

Le PDT che utilizzano persist_for non vengono ricostruite automaticamente dal rigeneratore di Looker, ad eccezione del caso di una cascata di dipendenze PDT. Quando una tabella persist_for fa parte di una cascata di dipendenze con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), il rigeneratore monitora e ricrea la tabella persist_for per ricreare altre tabelle nella cascata. Consulta la sezione In che modo Looker crea tabelle derivate a cascata in questa pagina.

materialized_view: yes

Nota: la funzionalità vista materializzata è una funzionalità avanzata. A seconda del tuo dialetto, una vista materializzata può consumare grandi risorse, quindi è importante capire l'implementazione delle viste materializzate da parte del dialetto. Consulta la documentazione del dialetto per informazioni sul suo comportamento e sulla frequenza con cui il dialetto aggiorna i dati relativi alle viste materializzate.

Le viste materializzate consentono di sfruttare la funzionalità del database per rendere persistenti le tabelle derivate nel progetto Looker. Se il dialetto del database supporta le viste materializzate e la connessione Looker è configurata con l'opzione Abilita PDT attivata, puoi creare una vista materializzata specificando materialized_view: yes per una tabella derivata. Le viste materializzate sono supportate sia per le tabelle derivate native sia per le tabelle derivate basate su SQL.

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

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

Per questo motivo, la funzionalità vista materializzata richiede una conoscenza avanzata del tuo dialetto e delle sue caratteristiche. Nella maggior parte dei casi, il database aggiorna la vista materializzata ogni volta che rileva nuovi dati nelle tabelle su cui la vista materializzata esegue una query. Le viste materializzate sono ottimali per scenari che richiedono dati in tempo reale.

Consulta la pagina della documentazione relativa al parametro materialized_view per informazioni su supporto del dialetto, requisiti e considerazioni importanti.

Strategie di ottimizzazione

Poiché le tabelle derivate permanenti (PDT) sono archiviate nel database, devi ottimizzare le PDT utilizzando le seguenti strategie, supportate dal tuo dialetto:

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

Ad esempio, per aggiungere persistenza all'esempio di tabella derivata, puoi impostarla di nuovo quando viene attivato il gruppo di dati orders_datagroup 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 avvisa che devi farlo per migliorare le prestazioni delle query.

Casi d'uso delle PDT

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

Come best practice generale, gli sviluppatori dovrebbero provare a creare modelli dei dati senza utilizzare PDT fino a quando non è assolutamente necessario.

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

Oltre alla riduzione dei tempi di query e del carico del database per le query eseguite di frequente, esistono molti altri casi d'uso per le PDT, tra cui:

• Test delle ottimizzazioni
• Prima dell'unione o dell'aggregazione dei dati

Puoi anche utilizzare una PDT per definire una chiave primaria nei casi in cui non esista un modo ragionevole per identificare una riga univoca di una tabella come chiave primaria.

Utilizzo delle PDT per testare le ottimizzazioni

Puoi utilizzare le PDT per testare diverse opzioni di indicizzazione, distribuzione e altre opzioni di ottimizzazione senza bisogno di un'ampia assistenza da parte degli sviluppatori DBA o ETL.

Considera un caso in cui hai una tabella, ma vuoi testare indici diversi. Il codice LookML iniziale per la vista potrebbe avere il seguente aspetto:

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

Per testare le strategie di ottimizzazione, puoi utilizzare il parametro indexes per aggiungere indici a 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 volta per generare la PDT. Poi esegui le query di prova e confronta i risultati. Se i risultati sono positivi, puoi chiedere al tuo team DBA o ETL di aggiungere gli indici alla tabella originale.

Ricorda di ripristinare il codice di visualizzazione per rimuovere la PDT.

Utilizzo delle PDT per pre-unire o aggregare i dati

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

Ad esempio, supponi di voler creare un report sui clienti in base alla coorte in base a quando hanno effettuato il primo ordine. Questa query potrebbe essere costosa da eseguire più volte ogni volta che sono necessari dati in tempo reale; tuttavia, puoi calcolare la query solo una volta e quindi riutilizzare i risultati con una 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]
  }
}

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 permanenti a cascata (PDT), a seconda dei casi. Un esempio di tabelle derivate a cascata potrebbe essere una tabella TABLE_D, che dipende da un'altra tabella, TABLE_C, mentre TABLE_C dipende da TABLE_B, mentre TABLE_B dipende da TABLE_A.

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

Sintassi per il riferimento a una tabella derivata

Per fare riferimento a una tabella derivata in un'altra tabella derivata, utilizza la seguente 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 questa 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 gruppo di dati, quindi non puoi utilizzare una tabella derivata per attivare un gruppo di dati. Tuttavia, puoi utilizzare la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} nel parametro sql_trigger_value per attivare le rigenerazioni PDT.

Nell'esempio successivo, la PDT clean_events viene creata dalla tabella events nel database. La PDT clean_events esclude le righe indesiderate dalla tabella di database events. Poi viene mostrata una seconda PDT; la PDT event_summary è un riepilogo della PDT clean_events. La tabella event_summary si rigenera ogni volta che vengono aggiunte nuove righe a clean_events.

Le PDT event_summary e clean_events sono PDT a cascata, dove event_summary dipende da clean_events (poiché event_summary viene definito utilizzando la PDT clean_events). Questo esempio specifico può essere eseguito in modo più efficiente in una singola 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 obbligatorio, quando fai 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

Nell'esempio precedente è così:

${clean_events.SQL_TABLE_NAME} AS clean_events

È utile utilizzare un alias perché, dietro le quinte, le PDT vengono denominate con lunghi codici nel database. In alcuni casi (soprattutto con le clausole ON) è facile dimenticare che è necessario utilizzare la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} per recuperare questo nome lungo. L'alias può contribuire a evitare questo tipo di errore.

In che modo Looker crea tabelle derivate a cascata

Nel caso di tabelle derivate temporanee a cascata, se i risultati della query di un utente non sono nella cache, Looker crea 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 dipende da TABLE_C. Ciò significa che se esegui una query su TABLE_D e la query non si trova nella cache di Looker, Looker creerà di nuovo TABLE_D. Prima, però, deve ricreare TABLE_C.

Ora prendiamo uno scenario di tabelle derivate temporanee a cascata in cui TABLE_D dipende da TABLE_C, che a sua volta dipende da TABLE_B, che dipende da TABLE_A. Se nella cache non sono disponibili risultati validi per una query su TABLE_C, Looker crea tutte le tabelle necessarie per la query. Looker creerà TABLE_A, quindi TABLE_B e infine TABLE_C:

In questo scenario, la generazione di TABLE_A deve essere completata prima che Looker possa iniziare a generare TABLE_B e così via, fino al completamento di TABLE_C e a Looker può fornire i risultati della query. (Dal momento che TABLE_D non è necessario per rispondere a questa query, al momento Looker non ricrea TABLE_D).

Consulta la pagina della documentazione relativa al parametro datagroup per uno scenario di esempio di PDT a cascata che utilizzano lo stesso gruppo di dati.

Per le PDT si applica la stessa logica di base: Looker creerà qualsiasi tabella necessaria per rispondere a una query, lungo la catena delle dipendenze. Tuttavia, con le PDT, capita spesso che le tabelle esistano già e non debbano essere ricreate. Con query utente standard sulle PDT a cascata, Looker ricrea le PDT a cascata solo se non esiste una versione valida delle PDT nel database. Se vuoi forzare la ricreazione di tutte le PDT in una cascata, puoi ricreare manualmente le tabelle per una query tramite un'esplorazione.

Un aspetto logico importante da comprendere è che, nel caso di una PDT a cascata, una PDT dipendente consiste essenzialmente nell'eseguire query sulla PDT da cui dipende. Questo aspetto è significativo soprattutto per le PDT che utilizzano la strategia persist_for. In genere, le PDT di persist_for vengono create quando un utente esegue una query, rimangono nel database fino a quando l'intervallo persist_for non è attivo e poi non vengono ricreate fino a quando l'utente non esegue una successiva query. Tuttavia, se una PDT di 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 di persist_for viene essenzialmente sottoposta a query ogni volta che le PDT dipendenti vengono ricreate. Quindi, in questo caso, la PDT persist_for verrà ricreata in base alla pianificazione delle PDT dipendenti. Ciò significa che persist_for PDT possono essere influenzate dalla strategia di persistenza dei rispettivi elementi dipendenti.

Ricostruzione manuale delle tabelle permanenti per una query

Gli utenti possono selezionare l'opzione Ricrea le tabelle derivate ed esegui dal menu di un'esplorazione per eseguire l'override delle impostazioni di persistenza e ricreare tutte le tabelle derivate permanenti (PDT) e le tabelle aggregate necessarie per la query corrente nell'esplorazione:

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

L'opzione Ricrea le tabelle derivate ed esegui ricrea tutte le tabelle permanenti (tutte le PDT e le tabelle aggregate) necessarie per rispondere alla query, indipendentemente dalla strategia di persistenza. Ciò include tutte le tabelle e le PDT aggregate nella query corrente, nonché eventuali tabelle e PDT aggregate a cui fanno riferimento le tabelle aggregate e le PDT nella query corrente.

Nel caso di PDT incrementali, l'opzione Ricrea le tabelle derivate ed esegui attiva la generazione di un nuovo incremento. Con le PDT incrementali, un incremento include il periodo di tempo specificato nel parametro increment_key e anche il numero di periodi di tempo precedenti specificati nel parametro increment_offset, se presente. Consulta la pagina della documentazione relativa alle PDT incrementali per alcuni scenari di esempio che mostrano come vengono create le PDT incrementali, in base alla loro configurazione.

Nel caso delle PDT a cascata, ciò significa ricreare tutte le tabelle derivate nella cascata, a partire dall'alto. Questo è lo stesso comportamento di quando esegui una query su una tabella in una cascata di tabelle derivate temporanee:

Tieni presente quanto segue per la ricreazione manuale delle tabelle derivate:

• Per l'utente che avvia l'operazione Ricrea le tabelle derivate ed esegui, la query attende che le tabelle vengano create di nuovo prima di caricare i risultati. Le query di altri utenti continueranno a utilizzare le tabelle esistenti. Dopo aver ricreato le tabelle permanenti, tutti gli utenti utilizzeranno le tabelle rigenerate. Sebbene questo processo sia progettato per evitare di interrompere le query di altri utenti durante la ricostruzione delle tabelle, questi utenti potrebbero comunque essere interessati dal carico aggiuntivo sul database. Se ti trovi in una situazione in cui l'attivazione di una nuova creazione durante l'orario di apertura potrebbe sovraccaricare il database in modo inaccettabile, potresti dover comunicare agli utenti che non devono mai ricreare alcune PDT o tabelle aggregate durante queste ore.

• Se un utente è in modalità di sviluppo e l'esplorazione si basa su una tabella di sviluppo, l'operazione Ricrea le tabelle derivate ed esegui ricrea la tabella di sviluppo, non la tabella di produzione, per l'esplorazione. Tuttavia, se l'esplorazione in modalità di sviluppo utilizza la versione di produzione di una tabella derivata, la tabella di produzione verrà ricreata. Per informazioni sulle tabelle di sviluppo e sulle tabelle di produzione, consulta Tabelle persistenti in modalità di sviluppo.

• Per le istanze ospitate da Looker, se la nuova creazione della tabella derivata richiede più di un'ora, la creazione della tabella non andrà a buon fine e la sessione del browser scadrà. Per saperne di più sui timeout che possono influire sui processi di Looker, consulta la sezione Timeout e code delle query nella pagina della documentazione relativa a Impostazioni amministratore - Query.

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, che include le tabelle aggregate e le tabelle derivate permanenti (PDT).

Se esegui una query su una tabella persistente in modalità di sviluppo senza apportare modifiche alla sua definizione, Looker eseguirà una query sulla versione di produzione della tabella. Se modifichi la definizione della tabella che influisce sui dati della tabella o sul modo in cui vengono eseguite query sulla tabella, alla successiva esecuzione di query sulla tabella in modalità di sviluppo verrà creata una nuova versione di sviluppo della tabella. Una tabella di sviluppo di questo tipo consente di testare le modifiche senza disturbare gli utenti finali.

Che cosa richiede a Looker di creare una tabella di sviluppo

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

• Se la tabella persistente ha un parametro che limita il set di dati per lavorare più velocemente in modalità di sviluppo,
• Se hai apportato modifiche alla definizione della tabella persistente che influiscono sui dati della tabella

Looker creerà una tabella di sviluppo se sei in modalità di sviluppo e esegui una query su una tabella derivata basata su SQL definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev.

Nota: questo non avviene per le tabelle derivate native con il parametro dev_filters. Per le tabelle derivate native con dev_filters, Looker dispone della logica per utilizzare la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non modifichi la definizione della tabella ed esegui query sulla tabella in modalità di sviluppo.

Per le tabelle persistenti che non hanno un parametro per restringere il set di dati in modalità di sviluppo, Looker utilizza la versione di produzione della tabella per rispondere alle query in modalità di sviluppo, a meno che non modifichi la definizione della tabella e quindi esegui una query sulla tabella in modalità di sviluppo. Questo vale per qualsiasi modifica alla tabella che influisce sui dati al suo interno o sul modo in cui viene eseguita la query sulla tabella.

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

• Modificare la query su cui si basa la tabella permanente, ad esempio modificando il parametro explore_source, sql, query, sql_create o create_process nella tabella permanente stessa o in qualsiasi tabella obbligatoria (nel caso delle tabelle derivate a cascata)
• Modificare la strategia di persistenza della tabella, ad esempio modificando il parametro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for della tabella stessa
• Modifica del nome del parametro view di una tabella derivata
• Modifica di increment_key o increment_offset di una PDT incrementale
• Modifica dell'elemento connection utilizzato dal modello associato

Per le modifiche che non modificano i dati della tabella o influiscono sul modo in cui Looker esegue query sulla tabella, Looker non crea una tabella di sviluppo. Il parametro publish_as_db_view è un buon esempio: in modalità di sviluppo, se modifichi solo l'impostazione publish_as_db_view per una tabella derivata, Looker non deve ricreare la tabella derivata, quindi non creerà una tabella di sviluppo.

Per quanto tempo Looker conserva le tabelle di sviluppo

Indipendentemente dall'effettiva strategia di persistenza della tabella, Looker considera le tabelle di sviluppo persistenti come se avessero una strategia di persistenza pari a persist_for: "24 hours". Looker lo fa per garantire che le tabelle di sviluppo non siano rese persistenti per più di un giorno, poiché uno sviluppatore Looker può eseguire query su 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 ingombrano il database, Looker applica la strategia persist_for: "24 hours" per assicurarsi che le tabelle vengano pulite dal database regolarmente.

Altrimenti, Looker crea tabelle derivate permanenti (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 rimane persistente nel database quando esegui il deployment delle modifiche a una 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 eseguono query sulla tabella.

Tieni presente che, quando esegui il deployment delle modifiche, potrebbe comunque essere necessario ricreare la tabella per poter eseguire query in produzione, a seconda della situazione:

• Se sono trascorse più di 24 ore da quando hai eseguito la query sulla tabella in modalità di sviluppo, la versione di sviluppo della tabella viene contrassegnata come scaduta e non verrà utilizzata per le query. Puoi verificare la presenza di PDT non create utilizzando l'IDE Looker o utilizzando la scheda Sviluppo della pagina Tabelle derivate permanenti. Se hai PDT non create, puoi eseguire query in modalità di sviluppo immediatamente prima di apportare modifiche, in modo che la tabella di sviluppo sia disponibile per l'utilizzo in produzione.
• Se una tabella persistente contiene il parametro dev_filters (per le tabelle derivate native) o la clausola WHERE condizionale che utilizza le istruzioni if prod e if dev (per le tabelle 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 questo caso, dopo aver completato lo sviluppo della tabella e prima di eseguire il deployment delle modifiche, puoi commentare il parametro dev_filters o la clausola WHERE condizionale ed eseguire query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che può essere utilizzata per la produzione quando esegui il deployment delle modifiche.

Altrimenti, se esegui il deployment delle modifiche quando non è disponibile una tabella di sviluppo valida che può essere utilizzata come tabella di produzione, Looker ricostruisce la tabella alla successiva query in modalità di produzione (per le tabelle permanenti che utilizzano la strategia persist_for) o alla successiva esecuzione del rigeneratore (per le tabelle permanenti che utilizzano datagroup_trigger, interval_trigger o sql_trigger_value).

Controllo di PDT non create in modalità di sviluppo

Se una tabella di sviluppo rimane persistente nel database quando esegui il deployment delle modifiche in una tabella derivata permanente (PDT) o in 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 eseguono query sulla tabella. Per ulteriori dettagli, consulta le sezioni Per quanto tempo Looker persiste nelle tabelle di sviluppo e Cosa richiede a Looker di creare una tabella di sviluppo in questa pagina.

Di conseguenza, è ottimale che tutte le PDT vengano create quando esegui il deployment in produzione, in modo che le tabelle possano essere utilizzate immediatamente come versioni di produzione.

Puoi verificare l'eventuale presenza di PDT non create nel tuo progetto nel riquadro Integrità del progetto. Fai clic sull'icona Integrità del progetto nell'IDE di Looker per aprire il riquadro Integrità del progetto. Quindi, fai clic sul pulsante Convalida stato PDT.

Se sono presenti PDT non create, vengono elencate nel riquadro Stato del progetto:

Se disponi dell'autorizzazione see_pdts, puoi fare clic sul pulsante Vai alla gestione delle PDT. Looker aprirà la scheda Sviluppo della pagina Tabelle derivate permanenti e filtrerà i risultati in base al tuo progetto LookML specifico. Qui puoi vedere quali PDT di sviluppo sono state create e non create e puoi accedere ad altre informazioni per la risoluzione dei problemi. Per ulteriori informazioni, consulta la pagina della documentazione Impostazioni amministratore - Tabelle derivate permanenti.

Dopo aver identificato una PDT non creata nel tuo progetto, puoi crearne una versione di sviluppo aprendo un'esplorazione che esegua una query sulla tabella e utilizzando l'opzione Ricrea le tabelle derivate ed esegui dal menu Esplora. Consulta la sezione Ricreare manualmente le tabelle permanenti per una query in questa pagina.

Nota: se una tabella persistente è una tabella derivata basata su SQL definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev, non potrai utilizzare la versione di sviluppo della tabella per la produzione, poiché la versione di sviluppo della tabella ha un set di dati abbreviato. Per saperne di più, consulta la sezione Per quanto tempo Looker persiste nelle tabelle di sviluppo in questa pagina. Per le tabelle derivate native con il parametro dev_filters, Looker utilizza la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non modifichi la definizione della tabella e poi esegui una query sulla tabella in modalità di sviluppo (consulta la sezione Cosa richiede a Looker di creare una tabella di sviluppo in questa pagina della documentazione).

Condivisione e pulizia della tabella

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

Questo offre diversi vantaggi:

• Se non hai apportato modifiche a una tabella in modalità di sviluppo, le query utilizzeranno le tabelle di produzione esistenti. Questo vale a meno che la tua tabella non sia una tabella derivata basata su SQL che viene definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev. Se la tabella è definita con una clausola WHERE condizionale, Looker crea una tabella di sviluppo se esegui una query sulla tabella in modalità di sviluppo. Per le tabelle derivate native con il parametro dev_filters, Looker dispone della logica per utilizzare la tabella di produzione per rispondere alle query in modalità di sviluppo, a meno che non modifichi la definizione della tabella e poi esegui query sulla tabella in modalità di sviluppo.
• Se due sviluppatori apportano la stessa modifica a una tabella in modalità di sviluppo, condivideranno la stessa tabella di sviluppo.
• Quando esegui il push delle modifiche dalla modalità di sviluppo alla modalità di produzione, la precedente definizione di produzione non esiste più, pertanto la tabella di produzione precedente viene contrassegnata come scaduta e verrà eliminata.
• Se decidi di eliminare le modifiche alla modalità di sviluppo, la definizione della tabella non esiste più, pertanto le tabelle di sviluppo non necessarie vengono contrassegnate come scadute e vengono eliminate.

Lavorare più velocemente in modalità di sviluppo

A volte, la generazione della tabella derivata permanente (PDT) che stai creando richiede molto tempo, il che può richiedere molto tempo se stai testando molte modifiche in modalità di sviluppo. In questi casi, puoi richiedere a Looker di creare versioni più piccole di una tabella derivata quando sei in modalità di sviluppo.

Per le tabelle derivate native, puoi utilizzare il sottoparametro dev_filters di explore_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 in base agli ultimi 90 giorni e un parametro filters che filtra i dati in base agli ultimi 2 anni e all'aeroporto di Yucca Valley.

Il parametro dev_filters agisce in combinazione con il parametro filters per far sì che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se dev_filters e filters specificano 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 degli ultimi 90 giorni per l'aeroporto di Yucca Valley.

Per le tabelle derivate basate su SQL, Looker supporta una clausola WHERE condizionale 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 a partire dal 2000 in modalità di produzione, ma solo quelli a partire dal 2020 in modalità di sviluppo. L'uso strategico di questa funzionalità per limitare il set di risultati e aumentare la velocità delle query può semplificare notevolmente la convalida delle modifiche apportate alla modalità di 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 set di dati abbreviato. In questo caso, dopo aver completato lo sviluppo della tabella e prima di eseguire il deployment delle modifiche, puoi commentare il parametro dev_filters o la clausola WHERE condizionale ed eseguire query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che può essere utilizzata per la produzione quando esegui il deployment delle modifiche. Per ulteriori dettagli sull'utilizzo delle tabelle di sviluppo in produzione, consulta la sezione Per quanto tempo Looker conserva le tabelle di sviluppo in questa pagina.

In che modo Looker crea le PDT

Dopo aver definito una tabella derivata permanente (PDT) che è stata eseguita per la prima volta o attivata dal rigeneratore per ricostruire la tabella in base alla sua strategia di persistenza, Looker seguirà i seguenti passaggi:

1. Usa il codice SQL della tabella derivata per creare un'istruzione CREATE TABLE AS SELECT (o CTAS) ed eseguila. Ad esempio, per ricreare una PDT denominata customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Emetti le istruzioni per creare gli indici quando viene creata la tabella
3. Rinomina la tabella da LC$.. ("Looker Create") in LR$.. ("Looker Read"), per indicare che la tabella è pronta per l'uso
4. Elimina qualsiasi versione precedente della tabella che non dovrebbe più essere in uso

Ci sono alcune implicazioni importanti:

• L'SQL che forma la tabella derivata deve essere valido all'interno di un'istruzione CTAS.
• Gli alias di colonna nel set di risultati dell'istruzione SELECT devono essere nomi di colonna validi.
• I nomi utilizzati quando specifichi distribuzione, chiavi di ordinamento e 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 le ricostruzioni per le tabelle permanenti con trigger. Una tabella basata su trigger è una tabella derivata permanente (PDT) o una tabella aggregata che utilizza un attivatore come strategia di persistenza:

• Per le tabelle che utilizzano sql_trigger_value, l'attivatore è una query specificata nel parametro sql_trigger_value della tabella. Il rigeneratore Looker attiva una nuova creazione della tabella quando il risultato dell'ultimo controllo della query del trigger è diverso da quello del precedente controllo della query del trigger. Ad esempio, se la tabella derivata è persistente con la query SQL SELECT CURDATE(), il rigeneratore Looker ricostruisce la tabella la prossima volta che il rigeneratore controlla il trigger dopo la modifica della data.
• Per le tabelle che utilizzano interval_trigger, l'attivatore è una durata di tempo specificata nel parametro interval_trigger della tabella. Il rigeneratore Looker attiva una nuova creazione della tabella una volta trascorso il tempo specificato.
• Per le tabelle che utilizzano datagroup_trigger, l'attivatore può essere una query specificata nel parametro sql_trigger del gruppo di dati associato oppure può essere una durata di tempo specificata nel parametro interval_trigger del gruppo di dati.

Il rigeneratore Looker avvia anche le ricostruzioni delle tabelle persistenti che utilizzano il parametro persist_for, ma solo se la tabella persist_for è una cascata di dipendenze di una tabella persistente in trigger. In questo caso, il rigeneratore Looker avvierà le ricostruzioni di una tabella persist_for, poiché la tabella è necessaria per ricreare le altre tabelle nella cascata. In caso contrario, il rigeneratore non monitora le tabelle persistenti che utilizzano la strategia persist_for.

Il ciclo del rigeneratore Looker inizia a un intervallo regolare configurato dall'amministratore Looker nell'impostazione Pianificazione di manutenzione di gruppi di dati e PDT nella connessione al database (l'intervallo predefinito è 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 dell'ultimo ciclo. Ciò significa che se hai build PDT a lunga esecuzione, il ciclo del rigeneratore Looker potrebbe non essere eseguito con la stessa frequenza definita nell'impostazione Pianificazione della manutenzione di gruppi di dati e PDT. Il tempo necessario per ricreare le tabelle può essere influenzato da altri fattori, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle persistenti di questa pagina.

Nei casi in cui una PDT non viene creata, il rigeneratore potrebbe tentare di ricostruire la tabella nel successivo ciclo del rigeneratore:

• Se l'impostazione Riprova build PDT non riuscite è abilitata sulla connessione al database, il rigeneratore Looker tenterà di ricostruire la tabella durante il successivo ciclo del rigeneratore, anche se la condizione di trigger della tabella non è soddisfatta.
• Se l'impostazione Riprova build PDT non riuscite è disabilitata, il rigeneratore Looker non tenterà di ricreare la tabella fino a quando la condizione di trigger della PDT non sarà soddisfatta.

Se un utente richiede i dati dalla tabella persistente durante la creazione e i risultati della query non sono nella cache, Looker controlla 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ò verificarsi se la nuova tabella ha una definizione diversa, la nuova tabella utilizza una connessione al database diversa o la nuova tabella è stata creata con una versione diversa di Looker). Se la tabella esistente è ancora valida, Looker restituirà i dati dalla tabella esistente fino a quando non viene creata la nuova tabella. Altrimenti, se la tabella esistente non è valida, Looker fornirà i risultati della query dopo aver ricreato la nuova tabella.

Considerazioni importanti per l'implementazione delle tabelle persistenti

Considerando l'utilità delle tabelle persistenti (PDT e tabelle aggregate), è facile accumularne molte nell'istanza di Looker. È possibile creare uno scenario in cui il rigeneratore Looker deve creare molte tabelle contemporaneamente. In particolare con le tabelle a cascata o a lunga esecuzione, puoi creare uno scenario in cui le tabelle hanno un lungo ritardo prima di essere ricreato o in cui gli utenti riscontrano un ritardo nel recupero dei risultati delle query da una tabella mentre il database sta lavorando duramente per generare la tabella.

Il rigeneratore di Looker controlla i trigger PDT per verificare se deve ricreare le tabelle permanenti con trigger. Il ciclo del rigeneratore viene impostato a un intervallo regolare configurato dall'amministratore Looker nell'impostazione Pianificazione di manutenzione di gruppi di dati e PDT nella connessione al database (l'intervallo predefinito è un intervallo di cinque minuti).

Il tempo necessario per ricreare le tabelle può dipendere da diversi fattori:

• L'amministratore di Looker potrebbe aver modificato l'intervallo dei controlli del trigger del rigeneratore utilizzando l'impostazione Pianificazione di manutenzione di gruppi di dati e PDT nella connessione al database.
• Il rigeneratore Looker avvia un nuovo ciclo solo dopo che ha completato tutti i controlli e le rigenerazioni PDT dall'ultimo ciclo. Quindi, se hai build PDT a lunga esecuzione, il ciclo del rigeneratore Looker potrebbe non essere tanto frequente quanto l'impostazione Pianificazione della manutenzione di gruppi di dati e PDT.
• Per impostazione predefinita, il rigeneratore può avviare la ricostruzione di una PDT o di una tabella aggregata alla volta tramite una connessione. Un amministratore di Looker può regolare il numero consentito di ricostruzioni simultanee del rigeneratore utilizzando il campo Numero massimo di connessioni del generatore di PDT nelle impostazioni di una connessione.
• Tutte le PDT e le tabelle aggregate attivate dallo stesso datagroup verranno rigenerate durante lo stesso processo di rigenerazione. Questo può essere un carico elevato se molte tabelle utilizzano il gruppo di dati, direttamente o come risultato di dipendenze a cascata.

Oltre alle considerazioni precedenti, esistono anche alcune situazioni in cui è consigliabile evitare di aggiungere persistenza a una tabella derivata:

• Se le tabelle derivate sono extended: ogni estensione di una PDT crea una nuova copia della tabella nel database.
• Quando le tabelle derivate utilizzano filtri basati su modelli o parametri Liquid, la persistenza non è supportata per le tabelle derivate che utilizzano filtri basati su modelli o parametri Liquid.
• Quando le tabelle derivate native vengono create da esplorazioni che utilizzano attributi utente con access_filters o con sql_always_where, nel database verranno create copie della tabella per ogni possibile valore dell'attributo utente specificato.
• Quando i dati sottostanti cambiano spesso e il dialetto del database non supporta le PDT incrementali.
• Quando il costo e il tempo necessari per la creazione delle PDT sono troppo elevati.

A seconda del numero e della complessità delle tabelle permanenti nella connessione a Looker, la coda potrebbe contenere molte tabelle permanenti che devono essere controllate e ricreate a ogni ciclo, quindi è importante tenere a mente questi fattori durante l'implementazione delle tabelle derivate sull'istanza di Looker.

Gestione delle PDT su larga scala tramite API

Il monitoraggio e la gestione delle tabelle derivate permanenti (PDT) che si aggiornano in base a pianificazioni diverse diventano sempre più complesse man mano che si creano più PDT sull'istanza. Prendi in considerazione l'utilizzo dell'integrazione Apache Airflow di Looker per gestire le pianificazioni PDT insieme agli altri processi ETL ed ELT.

Monitoraggio e risoluzione dei problemi delle PDT

Se utilizzi tabelle derivate permanenti (PDT) e, in particolare, PDT a cascata a cascata, è utile visualizzare lo stato delle PDT. Puoi utilizzare la pagina di amministrazione delle tabelle derivate permanenti di Looker per visualizzare lo stato delle PDT. Per informazioni, consulta la pagina della documentazione Impostazioni amministratore - Tabelle derivate permanenti.

Quando cerchi di risolvere i problemi relativi alle PDT:

• Presta particolare attenzione alla distinzione tra tabelle di sviluppo e tabelle di produzione quando esamini il log eventi PDT.
• Verifica che non siano state apportate modifiche allo schema temporaneo in cui Looker archivia le tabelle derivate permanenti. Se sono state apportate modifiche, potrebbe essere necessario aggiornare le impostazioni di Connessione nella sezione Amministratore di Looker ed eventualmente riavviare Looker per ripristinare la normale funzionalità PDT.
• Determina se si verificano problemi con tutte le PDT o solo con una. Se si verifica un problema con uno di questi elementi, è probabile che sia causato da un errore di LookML o SQL.
• Determina se i problemi con la PDT corrispondono ai momenti in cui è pianificata la nuova creazione della PDT.
• Assicurati che la valutazione di tutte le query sql_trigger_value abbia esito positivo e che restituiscano solo una riga e una colonna. Per le PDT basate su SQL, puoi eseguire questa operazione in SQL Runner. L'applicazione di un LIMIT protegge dalle query inutili. Per ulteriori informazioni sull'utilizzo di SQL Runner per il debug delle tabelle derivate, consulta il post della scheda Community sull'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 LIMIT in SQL Runner per tempi di query ragionevoli.
• Per le tabelle derivate basate su SQL, evita di utilizzare espressioni di tabella comuni (CTE). L'utilizzo di CTE con DT crea istruzioni WITH nidificate che possono causare errori nelle PDT senza avviso. Utilizza invece l'SQL per il CTE per creare un trasferimento dati secondario e fare riferimento a questo trasferimento dal primo trasferimento dei dati con la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Verifica che tutte le tabelle da cui dipende il problema con PDT (sia le tabelle normali sia le PDT stesse) esistano e possano essere oggetto di query.
• Assicurati che tutte le tabelle da cui dipende il problema con PDT non abbiano blocchi condivisi o esclusivi. Affinché Looker possa creare correttamente una PDT, deve acquisire un blocco esclusivo sulla tabella da aggiornare. Questo sarà in conflitto con altri blocchi condivisi o esclusivi attualmente presenti nella tabella. Looker non potrà aggiornare la PDT finché tutti gli altri blocchi non saranno stati cancellati. Lo stesso vale per tutti i blocchi esclusivi nella tabella da cui Looker sta creando una PDT: se è presente un blocco esclusivo su una tabella, Looker non sarà in grado di acquisire un blocco condiviso per eseguire le query fino alla cancellazione di questo blocco.
• Utilizza il pulsante Mostra processi in SQL Runner. Se è attivo un numero elevato di processi, ciò potrebbe rallentare i tempi di query.
• Monitora i commenti nella query. Consulta la sezione Commenti delle query per le PDT in questa pagina.

Commenti delle query per le PDT

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

-- 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 di PDT verrà visualizzato nella scheda SQL di un'esplorazione se Looker ha dovuto generare una PDT per la query dell'esplorazione. Il commento verrà visualizzato nella parte superiore dell'istruzione SQL.

Infine, il commento relativo alla generazione di PDT viene visualizzato nel campo Messaggio della scheda Informazioni del popup Dettagli query per ogni query nella pagina di amministrazione Query.

Ricreare le PDT dopo un errore

Quando si verifica un errore in una tabella derivata permanente (PDT), ecco cosa succede quando viene eseguita una query sulla PDT:

• Looker utilizzerà i risultati nella cache se la stessa query è stata eseguita in precedenza. Per informazioni sul funzionamento, consulta la pagina della documentazione Memorizzazione nella cache.
• Se i risultati non sono nella cache, Looker estrarrà i risultati dalla PDT del database, se esiste una versione valida della PDT.
• Se il database non contiene alcuna PDT valida, Looker tenterà di ricrearla.
• Se non è possibile ricreare la PDT, Looker restituirà un errore per una query. Il rigeneratore di Looker tenterà di ricostruire la PDT alla successiva query sulla PDT o alla successiva attivazione della strategia di persistenza della PDT.

Con le PDT a cascading, si applica la stessa logica, tranne che per le PDT a cascata:

• Un errore di creazione per una tabella impedisce la creazione delle PDT lungo la catena delle dipendenze.
• Una PDT dipendente esegue essenzialmente una query sulla PDT su cui si basa, pertanto la strategia di persistenza di una tabella può attivare ricostruzioni delle PDT crescendo nella catena.

Rivediamo l'esempio precedente delle tabelle a cascata, in cui TABLE_D dipende da TABLE_C, che a sua volta da TABLE_B, che dipende da TABLE_A:

Se TABLE_B ha un errore, per TABLE_B si applica tutto il comportamento standard (non a cascata): se viene eseguita una query su TABLE_B, Looker prova prima a utilizzare la cache per restituire i risultati, quindi prova a utilizzare una versione precedente della tabella, se possibile, poi prova a ricreare la tabella e infine restituisce un errore se TABLE_B non riesce a ricreare la tabella. Looker proverà di nuovo a ricreare TABLE_B la prossima volta che viene eseguita una query sulla tabella o quando la strategia di persistenza della tabella attiva una nuova creazione.

Lo stesso vale anche per i dipendenti di TABLE_B. Quindi, se non è possibile creare TABLE_B e c'è una query su TABLE_C:

• Looker proverà a utilizzare la cache per la query su TABLE_C.
• Se i risultati non sono nella cache, Looker proverà a estrarre i risultati da TABLE_C nel database.
• Se non esiste una versione valida di TABLE_C, Looker proverà a ricreare TABLE_C, creando una query su TABLE_B.
• Looker proverà quindi a ricreare TABLE_B (operazione che non riuscirà se TABLE_B non è stato corretto).
• Se non è possibile ricreare TABLE_B, TABLE_C non può farlo, quindi Looker restituirà un errore per la query il giorno TABLE_C.
• Looker tenterà di ricreare TABLE_C in base alla consueta strategia di persistenza o la prossima volta che viene eseguita una query sulla PDT (incluso il successivo tentativo di creazione di TABLE_D, dato che TABLE_D dipende da TABLE_C).

Una volta risolto il problema con TABLE_B, TABLE_B e ciascuna delle tabelle dipendenti tenteranno di ricrearla in base alle rispettive strategie di persistenza o alla successiva query su cui viene eseguita una query (incluso il successivo tentativo di creazione di una PDT dipendente). Oppure, se una versione di sviluppo delle PDT nella cascata è stata creata in modalità di sviluppo, le versioni di sviluppo possono essere utilizzate come nuove PDT di produzione. Per sapere come funziona, consulta la sezione Tabelle persistenti in modalità di sviluppo di questa pagina. In alternativa, puoi utilizzare un'esplorazione per eseguire una query su TABLE_D e poi ricreare manualmente le PDT per la query, in modo da forzare una nuova creazione di tutte le PDT a partire dalla cascata delle dipendenze.

Migliorare le prestazioni PDT

Quando crei tabelle derivate permanenti (PDT), le prestazioni possono rappresentare un problema. Soprattutto quando la tabella è molto grande, l'esecuzione di query sulla tabella potrebbe essere lenta, proprio come per qualsiasi tabella di grandi dimensioni del database.

Puoi migliorare le prestazioni filtrando i dati o controllando il modo in cui i dati nella PDT vengono ordinati e indicizzati.

Aggiunta di filtri per limitare il set di dati

Con set di dati particolarmente grandi, avere molte righe rallenterà le query su una tabella derivata permanente (PDT). Se di solito esegui query solo su dati recenti, valuta la possibilità di aggiungere un filtro alla clausola WHERE della PDT per limitare la tabella a un massimo di 90 giorni di dati. In questo modo, solo i dati pertinenti verranno aggiunti alla tabella ogni volta che viene ricreato, in modo che le query in esecuzione siano molto più veloci. Successivamente, puoi creare una PDT separata e più grande per l'analisi storica, in modo da consentire sia query rapide sui dati recenti sia la possibilità di eseguire query sui vecchi dati.

Stai usando indexes o sortkeys e distribution

Quando crei una tabella derivata permanente (PDT) di grandi dimensioni, la sua indicizzazione (per dialetti come MySQL o Postgres) o l'aggiunta di chiavi di ordinamento e distribuzione (per Redshift) possono essere utili per le prestazioni.

In genere, è preferibile aggiungere il parametro indexes ai campi ID o data.

Per Redshift, di solito è preferibile aggiungere il parametro sortkeys ai campi ID o data e il parametro distribution al campo utilizzato per l'unione.

Impostazioni consigliate per migliorare le prestazioni

Le seguenti impostazioni controllano il modo in cui vengono ordinati e indicizzati i dati nella tabella derivata permanente (PDT). Queste impostazioni sono facoltative, ma vivamente consigliate:

• Per Redshift e Aster, utilizza il parametro distribution per specificare il nome della colonna il cui valore viene utilizzato per distribuire i dati intorno a un cluster. Quando due tabelle vengono unite dalla colonna specificata nel parametro distribution, il database può trovare i dati di join sullo stesso nodo, in modo che l'I/O tra nodi sia ridotto al minimo.
• Per Redshift, imposta il parametro distribution_style su all per indicare al database di conservare una copia completa dei dati su ciascun nodo. Viene spesso utilizzato per ridurre al minimo l'I/O tra nodi quando si uniscono tabelle relativamente piccole. Imposta questo valore su even per indicare al database di distribuire i dati in modo uniforme attraverso il cluster senza utilizzare una colonna di distribuzione. Questo valore può essere specificato solo quando distribution non è specificato.
• Per Redshift, utilizza il parametro sortkeys. I valori specificano quali colonne della PDT vengono utilizzate per ordinare i dati su disco e semplificare la ricerca. Su Redshift, puoi utilizzare sortkeys o indexes, ma non entrambi.
• Nella maggior parte dei database, utilizza il parametro indexes. I valori specificano quali colonne della PDT vengono indicizzate. Su Redshift, gli indici vengono utilizzati per generare chiavi di ordinamento con interleaving.