Tabelle derivate in Looker

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

Ad esempio, potresti avere una tabella di database denominata orders con molte colonne. Vuoi calcolare alcune metriche aggregate a livello di cliente, come il numero di ordini effettuati da ciascun cliente o la data in cui 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 utilizzare la tabella derivata customer_order_summary come se fosse qualsiasi altra tabella del database.

Per i casi d'uso più comuni delle tabelle derivate, consulta 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 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 modi seguenti:

• 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 del codice 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 non mostrato in questo esempio. La query explore_source nella tabella derivata nativa inserisce i campi customer_id, first_order e total_amount dal file della 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.

A parte il parametro derived_table e i relativi sottoparametri, questa vista customer_order_summary funziona come qualsiasi altro file della vista. Indipendentemente dal fatto che tu definisca la query della tabella derivata con LookML o con SQL, puoi creare misure e dimensioni di 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 sulle 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. Consulta il file della visualizzazione 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 definizione del modello di dati.

Per maggiori dettagli sulla creazione di tabelle derivate native, consulta la pagina della documentazione 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 e creare colonne nella tabella utilizzando una query SQL. Non puoi fare riferimento alle dimensioni e alle misure LookML in una tabella derivata basata su SQL. Guarda il file di visualizzazione tabella derivata basata su SQL nell'esempio precedente.

In genere, la query SQL viene definita utilizzando il parametro sql all'interno del parametro derived_table di un parametro visualizzazione.

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 tabelle derivate permanenti (PDT):

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

Indipendentemente dal fatto che tu utilizzi il parametro sql, create_process o sql_create, in tutti questi casi stai definendo la tabella derivata con una query SQL, quindi si tratta di tabelle derivate basate su SQL.

Quando definisci una tabella derivata basata su SQL, assicurati di assegnare a ciascuna colonna un alias chiaro utilizzando AS. Il motivo è che devi fare riferimento ai nomi delle colonne del set di risultati nelle dimensioni, 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, è necessario definire una tabella derivata basata su SQL 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 permanente (PDT), che viene 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 è definita una strategia di persistenza nel parametro derived_table.

Le tabelle derivate temporanee non vengono scritte nel database. Quando un utente esegue una query Esplora che coinvolge una o più tabelle derivate, Looker genera una query SQL utilizzando una combinazione di SQL specifica per il dialetto per le tabelle derivate e i campi richiesti, i join e i valori dei filtri. Se la combinazione è stata eseguita in precedenza e i risultati sono ancora validi nella cache, Looker utilizza i risultati memorizzati nella cache. Per saperne di più sulla memorizzazione nella cache delle query in Looker, consulta la pagina della documentazione relativa alla memorizzazione delle query nella cache.

In caso contrario, se Looker non può utilizzare i risultati memorizzati nella cache, deve eseguire una nuova query sul 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 sovraccarichino eccessivamente il database. Nei casi in cui l'esecuzione della query richiede del tempo, spesso è preferibile utilizzare un PDT.

Dialetti di database supportati per le tabelle derivate temporanee

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

Dialetto	Supportato?
Actian Avalanche	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Druid Apache	Sì
Apache Druid 0.13 o versioni successive	Sì
Apache Druid 0.18 o 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 e versioni successive	Sì
Cloudera Impala 3.1 o versioni successive 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ì
Fulmine	Sì
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
PostgreSQL di Google Cloud	Sì
Google Cloud SQL	Sì
Google Spanner	Sì
Greenplum	Sì
HyperSQL	Sì
IBM Netezza	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Microsoft Azure Synapse Analytics	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 o versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	Sì
MySQL	Sì
MySQL 8.0.12 e versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL precedente alla versione 9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7+	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettoriale	Sì
Vertica	Sì

Tabelle derivate permanenti

Una tabella derivata permanente (PDT) è una tabella derivata scritta in uno schema temporaneo sul 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 tabelle derivate permanenti (PDT) nel tuo progetto Looker, è necessario quanto segue:

• Un dialetto del database che supporta i 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 database. Può trattarsi di uno schema qualsiasi nel database, ma ti consigliamo di crearne uno nuovo 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 di attivazione/disattivazione Attiva PDT attivata. In genere questa opzione è impostata quando configuri inizialmente la connessione a Looker (consulta la pagina della documentazione sui dialetti di Looker per istruzioni sul dialetto del tuo database), ma puoi anche abilitare le PDT per la tua connessione dopo la configurazione iniziale.

Dialetti di database supportati per le PDT

Affinché Looker supporti le tabelle derivate permanenti (PDT) nel progetto, anche il dialetto del database deve supportarle.

Per supportare qualsiasi tipo di PDT (basate su LookML o SQL), il dialetto deve supportare le scritture sul database, tra gli altri requisiti. Esistono alcune configurazioni di database di sola lettura che non consentono il funzionamento della persistenza (in genere i database di replica hot-swap Postgres). In questi casi, puoi utilizzare le tabelle derivate temporanee.

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

Dialetto	Supportato?
Actian Avalanche	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Druid Apache	No
Apache Druid 0.13 o versioni successive	No
Apache Druid 0.18 o 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 e versioni successive	Sì
Cloudera Impala 3.1 o versioni successive 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ì
Fulmine	No
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
PostgreSQL di Google Cloud	Sì
Google Cloud SQL	Sì
Google Spanner	No
Greenplum	Sì
HyperSQL	No
Netezza di IBM	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Microsoft Azure Synapse Analytics	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 o versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 e versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL precedente alla versione 9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7+	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettoriale	Sì
Vertica	Sì

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

Dialetto	Supportato?
Actian Avalanche	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Druid Apache	No
Apache Druid 0.13 o versioni successive	No
Apache Druid 0.18 o 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 e versioni successive	Sì
Cloudera Impala 3.1 o versioni successive 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ì
Fulmine	No
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
PostgreSQL di Google Cloud	Sì
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sì
HyperSQL	No
Netezza di IBM	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Microsoft Azure Synapse Analytics	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 o versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 e versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL precedente alla versione 9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7+	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettoriale	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 persistente (PDT) creata da Looker aggiungendo nuovi dati alla tabella anziché ricostruirla nella sua interezza.

Se il tuo dialetto supporta le PDT incrementali e la tua 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 ai PDT incrementali.

Dialetti di database supportati per le PDT incrementali

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

Dialetto	Supportato?
Actian Avalanche	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sì
Druid Apache	No
Apache Druid 0.13 o versioni successive	No
Apache Druid 0.18 o versioni successive	No
Apache Hive 2.3 o versioni successive	No
Apache Hive 3.1.2 e versioni successive	No
Apache Spark 3 e versioni successive	No
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	No
Cloudera Impala 3.1 o versioni successive 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ì
PostgreSQL di Google Cloud	Sì
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sì
HyperSQL	No
Netezza di IBM	No
MariaDB	No
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	No
Microsoft Azure Synapse Analytics	Sì
Microsoft SQL Server 2008 e versioni successive	No
Microsoft SQL Server 2012 o versioni successive	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 e versioni successive	No
MongoBI	No
MySQL	Sì
MySQL 8.0.12 e versioni successive	Sì
Oracle	No
Oracle ADWC	No
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL precedente alla versione 9.5	Sì
PrestoDB	No
PrestoSQL	No
SAP HANA 2 e versioni successive	No
SingleStore	No
SingleStore 7+	No
Snowflake	Sì
Teradata	No
Trino	No
Vettoriale	No
Vertica	Sì

Creazione di PDT

Per trasformare una tabella derivata in una tabella derivata permanente (PDT), definisci 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 gestita dal database:
  • materialized_view: yes

Con le strategie di persistenza basate su trigger (datagroup_trigger, sql_trigger_value e interval_trigger), Looker mantiene la PDT nel database finché non ne viene attivata la ricostruzione. Quando la PDT viene attivata, Looker la ricostruisce per sostituire la versione precedente. Ciò significa che, con le PDT basate su trigger, gli utenti non dovranno attendere la creazione della PDT per ottenere risposte alle query di esplorazione dalla PDT.

Nota: alcuni utenti possono ignorare l'impostazione di persistenza di una PDT. Un utente con autorizzazione develop può utilizzare l'opzione Ricostruisci tabelle derivate ed esegui dal menu di un'esplorazione per ignorare l'impostazione di persistenza e ricreare tutte le PDT richieste per la query corrente nell'esplorazione. Per informazioni dettagliate, 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 datagroup con sql_trigger o interval_trigger, puoi utilizzare il parametro datagroup_trigger per avviare la rigenerazione delle tabelle derivate permanenti (PDT).

Looker gestisce il PDT nel database finché il relativo gruppo di dati non viene attivato. 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 i dati dalla PDT mentre è in fase di creazione e i risultati della query non sono nella cache, Looker restituirà i dati dalla PDT esistente fino a quando non verrà creata la nuova PDT. Per una panoramica dei gruppi di dati, consulta Memorizzazione nella cache delle query.

Per ulteriori informazioni su come il rigeneratore crea i PDT, consulta la sezione Il rigeneratore di 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. Se il risultato dell'istruzione SQL è diverso dal valore precedente, il PDT viene rigenerato. In caso contrario, la PDT esistente viene mantenuta nel database. Ciò significa che, nella maggior parte dei casi, gli utenti non dovranno attendere la compilazione del PDT. Se un utente richiede dati dalla PDT durante la sua creazione e i risultati della query non sono nella cache, Looker restituirà i dati della PDT esistente fino alla creazione della nuova PDT.

Per ulteriori informazioni su come il rigeneratore crea i PDT, consulta la sezione Il rigeneratore di Looker.

interval_trigger

Il parametro interval_trigger attiva la rigenerazione di una tabella derivata permanente (PDT) in base a un intervallo di tempo specificato, ad esempio "24 hours" o "60 minutes". Come per il parametro sql_trigger, ciò significa che in genere la PDT verrà precompilata quando gli utenti eseguono query. Se un utente richiede dati dalla PDT durante la sua creazione e i risultati della query non sono nella cache, Looker restituisce i dati della PDT esistente fino alla creazione della nuova PDT.

persist_for

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

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

Dopo persist_for, Looker cancella la PDT dal tuo database e la PDT verrà ricreata alla successiva query dell'utente, il che significa che la query dovrà attendere la ricompilazione.

Le PDT che utilizzano persist_for non vengono ricostruite automaticamente dal rigeneratore di Looker, tranne nel caso di una cascata di dipendenze delle PDT. Quando una tabella persist_for fa parte di una cascata delle 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 vista materializzata è una funzionalità avanzata. A seconda del dialetto, una vista materializzata può consumare molte risorse, quindi è importante comprendere l'implementazione delle viste materializzate del dialetto. Consulta la documentazione del tuo dialetto per informazioni sul suo comportamento e sulla frequenza con cui aggiorna i dati per le visualizzazioni con dati materiali.

Le viste materializzate consentono di sfruttare la funzionalità del database per rendere persistenti le tabelle derivate nel progetto Looker. Se il dialetto del tuo database supporta le viste materializzate e la connessione a 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 permanente (PDT), una vista materializzata è il risultato di una query che viene archiviato 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 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à di visualizzazione materializzata richiede una conoscenza avanzata del 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 viene eseguita la query dalla vista materializzata. Le viste materializzate sono ottimali per gli scenari che richiedono dati in tempo reale.

Per informazioni sul supporto dei dialetti, sui requisiti e su importanti considerazioni, consulta la pagina della documentazione relativa al parametro materialized_view.

Strategie di ottimizzazione

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

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

Ad esempio, per aggiungere la persistenza all'esempio di tabella derivata, puoi impostarla in modo che venga ricostruita quando viene attivato il gruppo di dati orders_datagroup e aggiungere indici sia su customer_id sia su first_order, come segue:

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 il rendimento delle query.

Casi d'uso per i PDT

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

Come best practice generale, gli sviluppatori devono cercare di modellare i dati senza utilizzare i PDT, a meno che non sia 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 dover creare una PDT. Assicurati di analizzare i piani di esecuzione delle query lente utilizzando lo strumento Spiega di SQL Runner.

Oltre a ridurre il tempo di query e il carico del database sulle query eseguite di frequente, esistono diversi altri casi d'uso per i PDT, tra cui:

• Ottimizzazioni dei test
• Pre-unione o 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 in una tabella come chiave primaria.

Utilizzare i PDT per testare le ottimizzazioni

Puoi utilizzare le PDT per testare l'indicizzazione, le distribuzioni e altre opzioni di ottimizzazione diverse senza bisogno di una grande quantità di supporto da parte degli sviluppatori DBA o ETL.

Considera un caso in cui hai una tabella, ma vuoi testare indici diversi. Il tuo 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 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 volta per generare il report PDT. Poi esegui le query di test e confronta i risultati. Se i risultati sono positivi, puoi chiedere al team DBA o ETL di aggiungere gli indici alla tabella originale.

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

Utilizzare le tabelle PDT per eseguire il join o l'aggregazione dei dati in precedenza

Può essere utile pre-unire o pre-aggregare i dati per regolare 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 calcolarla una sola volta e riutilizzare i risultati con un 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 con struttura 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 con struttura 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 con gerarchia, è importante sapere in che modo le tabelle con gerarchia vengono ricostruite automaticamente dal rielaboratore di Looker e in che modo possono essere ricostruite manualmente dagli utenti. Ci sono anche altre considerazioni importanti per l'implementazione delle tabelle persistenti. Tutti questi argomenti sono 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 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 datagroup, 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 ricompilazioni delle PDT.

Nel prossimo esempio, la PDT clean_events viene creata dalla tabella events nel database. La PDT clean_events esclude le righe indesiderate dalla tabella del database events. Quindi 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.

Le PDT event_summary e le clean_events PDT sono PDT a cascata, in cui event_summary dipende da clean_events (poiché event_summary è definito utilizzando la PDT clean_events). Questo esempio specifico potrebbe essere eseguito 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 obbligatorio, 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

Nell'esempio precedente:

${clean_events.SQL_TABLE_NAME} AS clean_events

È utile utilizzare un alias perché, dietro le quinte, le PDT sono denominate con codici lunghi 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. Un alias può aiutare 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 creerà tutte le tabelle derivate necessarie per la query. Se hai un TABLE_D la cui definizione contiene un riferimento a TABLE_C, TABLE_D è dipendente da TABLE_C. Ciò significa che se esegui una query su TABLE_D e la query non è nella cache di Looker, Looker creerà di nuovo TABLE_D. Ma prima deve ricostruire TABLE_C.

Ora prendiamo in considerazione uno scenario di tabelle derivate temporanee con struttura a cascata in cui 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, creerà tutte le tabelle di cui ha bisogno per la query. Pertanto, Looker creerà TABLE_A, poi 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 alla possibilità di fornire i risultati della query. Poiché TABLE_D non è necessario per rispondere a questa query, al momento Looker non ricostruirà TABLE_D.

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

Per le PDT si applica la stessa logica di base: Looker crea qualsiasi tabella necessaria per rispondere a una query, fino alla catena delle dipendenze. Tuttavia, con le PDT capita spesso che le tabelle esistano già e non debbano essere ricostruite. Con le query utente standard sulle PDT con struttura a cascata, Looker ricostruisce le PDT nella struttura a cascata solo se non esiste una versione valida delle PDT nel database. Se vuoi forzare una nuova creazione per tutte le PDT in una cascata, puoi ricostruire manualmente le tabelle per una query tramite un'esplorazione.

Un punto logico importante da capire è che, nel caso di una PDT a cascata, una PDT dipendente sta essenzialmente eseguendo una query sulla PDT da cui dipende. Questo è importante soprattutto per i PDT che utilizzano la strategia persist_for. In genere, le PDT persist_for vengono create quando un utente esegue una query, rimangono nel database fino a quando non viene raggiunto l'intervallo di persist_for e poi non vengono ricreate finché non viene eseguita la successiva query da parte di 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), viene essenzialmente eseguita una query sulla PDT persist_for ogni volta che le PDT dipendenti vengono ricreate. Pertanto, in questo caso, la PDT persist_for verrà ricreata in base alla pianificazione delle PDT dipendenti. Ciò significa che le PDT persist_for possono essere influenzate dalla strategia di persistenza dei loro dipendenti.

Ricostruzione manuale delle 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 necessarie per la query corrente nell'esplorazione:

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

L'opzione Ricostruisci tabelle derivate ed esegui ricostruisce tutte le tabelle persistenti (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é 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 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 PDT incrementali per alcuni scenari di esempio che mostrano come si creano le PDT incrementali, a seconda della loro configurazione.

Nel caso delle Cascade PDT, ciò significa ricreare tutte le tabelle derivate nella cascata, a partire dall'alto. Si tratta dello stesso comportamento che si verifica quando esegui una query su una tabella in una cascata di tabelle derivate temporanee:

Tieni presente quanto segue sulla ricreazione manuale delle tabelle derivate:

• Per l'utente che avvia la procedura Ricrea le tabelle derivate e Esegui, la query attenderà che le tabelle vengano ricreate prima di caricare i risultati. Le query degli altri utenti continueranno a utilizzare le tabelle esistenti. Una volta ricostruite, tutte le tabelle persistenti verranno utilizzate da tutti gli utenti. Questo processo è studiato per evitare di interrompere le comunicazioni di altri utenti durante la ricreazione delle tabelle, questi utenti potrebbero essere comunque interessati dal carico aggiuntivo sul database. Se ti trovi in una situazione in cui l'attivazione di una ricostruzione durante l'orario di apertura potrebbe comportare un carico inaccettabile sul tuo database, potresti dover comunicare agli utenti che non devono mai ricostruire determinati PDT o tabelle aggregate durante queste ore.

• Se un utente si trova in modalità di sviluppo e l'esplorazione è basata su una tabella di sviluppo, l'opzione Ricrea le tabelle derivate e 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à ricostruita. Per informazioni sulle tabelle di sviluppo e sulle tabelle di produzione, vedi Tabelle permanenti in modalità di sviluppo.

• Per le istanze ospitate da Looker, se la nuova creazione della tabella derivata richiede più di un'ora, la tabella non verrà ricreata correttamente e la sessione del browser scadrà. Per ulteriori informazioni sui timeout che potrebbero influire sui processi di Looker, consulta la sezione Timeout e accodamento delle query nella pagina della documentazione Impostazioni di amministrazione - Query.

Tabelle permanenti in modalità di sviluppo

Looker presenta alcuni comportamenti speciali per la gestione delle tabelle persistenti in modalità di sviluppo.

Nota: questi comportamenti si applicano a qualsiasi tipo di tabella permanente, incluse 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 di quella tabella. Se apporti una modifica alla definizione della tabella che influisce sui dati della tabella o sul modo in cui vengono eseguite query sulla tabella, alla successiva query in modalità di sviluppo verrà creata una nuova versione di sviluppo della tabella. Una tabella di sviluppo di questo tipo ti consente di testare le modifiche senza disturbare gli utenti finali.

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 ti trovi 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 restringe il set di dati per funzionare più velocemente in modalità di sviluppo
• Se hai apportato modifiche alla definizione della tabella persistente che influiscono sui dati della tabella

Looker crea 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 è vero per le tabelle derivate native con il parametro dev_filters. 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 modifichi la definizione della tabella e poi esegua 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 query sulla tabella in modalità di sviluppo. Questo vale per qualsiasi modifica alla tabella che influisce sui dati della tabella o sul modo in cui vengono eseguite le query sulla tabella.

Di seguito sono riportati alcuni esempi dei tipi di modifiche che inducono Looker a creare una versione di sviluppo di una tabella persistente (la tabella verrà creata da Looker solo se esegui successivamente una query sulla tabella dopo aver apportato queste modifiche):

• Modifica della query su cui si basa la tabella persistente, ad esempio modifica del parametro explore_source, sql, query, sql_create o create_process nella tabella persistente stessa o in qualsiasi tabella richiesta (nel caso di tabelle derivate a cascata)
• Modifica della strategia di persistenza della tabella, ad esempio modificando il parametro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for della tabella
• Modifica del nome dell'elemento view di una tabella derivata
• Modifica di increment_key o increment_offset di una PDT incrementale
• Modifica il valore 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 creerà 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 ne creerà una.

Per quanto tempo Looker mantiene le tabelle di sviluppo

Indipendentemente dalla strategia di persistenza effettiva della tabella, Looker tratta le tabelle di persistenza per lo sviluppo come se avessero una strategia di persistenza pari a persist_for: "24 hours". Looker esegue questa operazione per garantire che le tabelle di sviluppo non vengano conservate per più di un giorno, poiché uno sviluppatore di Looker potrebbe 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 regolarmente dal database.

In caso contrario, Looker crea tabelle derivate permanenti (PDT) e tabelle aggregate in modalità di sviluppo nello stesso modo in cui crea tabelle permanenti in modalità di produzione.

Se una tabella di sviluppo viene mantenuta nel database quando esegui il deployment delle modifiche a una PDT o a una tabella aggregata, spesso Looker può utilizzare la tabella di sviluppo come tabella di produzione in modo che gli utenti non debbano attendere la compilazione della tabella quando eseguono query sulla tabella.

Tieni presente che, quando esegui il deployment delle modifiche, la tabella potrebbe dover essere ricostruita per poter essere sottoposta a query in produzione, a seconda della situazione:

• Se sono trascorse più di 24 ore dall'ultima 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 di Looker o la scheda Sviluppo della pagina Tabelle derivate permanenti. Se disponi di PDT non create, puoi interrogarle in modalità di sviluppo subito prima di apportare modifiche, in modo che la tabella di sviluppo sia disponibile per l'uso in produzione.
• Se una tabella permanente ha 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.

In caso contrario, se esegui il deployment delle modifiche in assenza di una tabella di sviluppo valida utilizzabile come tabella di produzione, Looker creerà di nuovo la tabella la prossima volta che verrà eseguita una query sulla tabella in modalità di produzione (per le tabelle persistenti che utilizzano la strategia persist_for) o la prossima volta in cui viene eseguito il rigeneratore (per le tabelle persistenti che utilizzano datagroup_trigger, interval_trigger o sql_trigger_value{/13).

Controllo di PDT non create in modalità di sviluppo in corso...

Se una tabella di sviluppo viene mantenuta nel database quando esegui il deployment delle modifiche a una tabella derivata permanente (PDT) o a una tabella aggregata, spesso Looker può utilizzare la tabella di sviluppo come tabella di produzione in modo che gli utenti non debbano attendere la compilazione della tabella quando eseguono query sulla tabella. Per ulteriori dettagli, consulta le sezioni Per quanto tempo Looker mantiene le tabelle di sviluppo e Che cosa fa sì che Looker crei una tabella di sviluppo in questa pagina.

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

Puoi controllare la presenza di PDT non create nel 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, nel riquadro Project Health le verranno elencate:

Se disponi dell'autorizzazione see_pdts, puoi fare clic sul pulsante Vai a Gestione 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 vengono create e non create e accedere ad altre informazioni per la risoluzione dei problemi. Per ulteriori informazioni, consulta la pagina della documentazione Impostazioni di amministrazione - Tabelle derivate permanenti.

Dopo aver identificato una PDT non creata nel progetto, puoi crearne una versione di sviluppo aprendo un'esplorazione che esegue una query sulla tabella, quindi utilizzando il pulsante Ricrea le tabelle derivate e 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 mantiene le 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 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 delle tabelle

All'interno di una determinata 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 non esiste più, Looker la contrassegna come scaduta.

Questo approccio presenta diversi vantaggi:

• Se non hai apportato modifiche a una tabella in modalità di sviluppo, le query utilizzeranno le tabelle di produzione esistenti. Questo è il caso, a meno che la tabella non sia una tabella derivata basata su SQL definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev. Se la tabella è definita con una clausola WHERE condizionale, Looker creerà una tabella di sviluppo se esegui query sulla tabella in modalità di sviluppo. (per le tabelle derivate native con il parametro dev_filters, Looker ha la 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.
• Una volta inviate le modifiche 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 eliminare le modifiche alla modalità di sviluppo, la definizione della tabella non esiste più, quindi le tabelle di sviluppo non necessarie vengono contrassegnate come scadute e verranno eliminate.

Lavorare più velocemente in modalità di sviluppo

In alcuni casi, la generazione della tabella derivata permanente (PDT) che stai creando richiede molto tempo, il che può essere dispendioso 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 da applicare 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 negli ultimi 90 giorni e un parametro filters che filtra i dati negli ultimi 2 anni e per l'aeroporto di Yucca Valley.

Il parametro dev_filters agisce in combinazione con il parametro filters affinché tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se sia dev_filters che filters specificano 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 WHERE condizionale con opzioni diverse 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 in modalità di produzione, ma solo i dati dal 2020 in poi in modalità di sviluppo. L'utilizzo strategico di questa funzionalità per limitare il set di risultati e aumentare la velocità delle query può semplificare notevolmente la convalida delle modifiche in modalità di sviluppo.

Nota: se una tabella persistente ha il parametro dev_filters o la clausola WHERE condizionale, 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. Quando esegui il deployment delle modifiche, Looker creerà una versione completa della tabella che potrà essere utilizzata per la produzione. Per saperne di più sull'utilizzo delle tabelle di sviluppo in produzione, consulta la sezione Per quanto tempo Looker mantiene le tabelle di sviluppo in questa pagina.

In che modo Looker crea le PDT

Dopo che una tabella derivata permanente (PDT) è stata definita ed è stata eseguita per la prima volta o attivata dal rigeneratore per la ricostruzione in base alla relativa strategia di persistenza, Looker eseguirà i seguenti passaggi:

1. Utilizza l'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. Esegui 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 è pronta per l'uso
4. Elimina qualsiasi versione precedente della tabella che non deve più essere in uso

Ci sono alcune importanti implicazioni:

• Il codice 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 per specificare distribuzione, sortkey 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 di Looker

Il rigeneratore Looker controlla lo stato e avvia le ricompilazioni per le tabelle permanenti dal trigger. Una tabella permanente da trigger è una tabella derivata permanente (PDT) o una tabella aggregata che utilizza un trigger 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 di Looker attiva una 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 è persistente con la query SQL SELECT CURDATE(), il rigeneratore Looker ricrea la tabella al successivo controllo del trigger dopo la modifica della data.
• Per le tabelle che utilizzano interval_trigger, l'attivatore è una durata specificata nel parametro interval_trigger della tabella. Il rigeneratore Looker attiva una ricostruzione della tabella dopo 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 una durata specificata nel parametro interval_trigger del gruppo di dati.

Il rigeneratore Looker avvia anche le ricostruzioni per le tabelle permanenti che utilizzano il parametro persist_for, ma solo quando la tabella persist_for è una dipendenza a cascata di una tabella resa permanente da trigger. In questo caso, il rigeneratore Looker avvierà le ricompilazioni 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 di Looker inizia a intervalli regolari configurati dall'amministratore di Looker nell'impostazione Pianificazione della manutenzione di PDT e gruppi di dati sulla connessione del 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 dell'ultimo ciclo. Ciò significa che, se hai ricostruzioni PDT di lunga durata, il ciclo del rigeneratore Looker potrebbe non essere eseguito con la frequenza definita nell'impostazione Pianificazione manutenzione PDT e gruppi di dati. Altri fattori possono influire sul tempo necessario per ricostruire le tabelle, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle permanenti di questa pagina.

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

• Se l'impostazione Retry Failed PDT Builds (Ritenta le ricostruzioni PDT non riuscite) è abilitata nella connessione al database, il rigeneratore Looker tenterà di ricostruire la tabella durante il ciclo successivo del rigeneratore, anche se la relativa condizione trigger non è soddisfatta.
• Se l'impostazione Retry Failed PDT Builds (Riprova le ricostruzioni PDT non riuscite) è disabilitata, il rigeneratore Looker non tenterà di ricostruire la tabella finché la condizione di attivazione della PDT non sarà soddisfatta.

Se un utente richiede dati dalla tabella persistente durante la sua 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ò 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 della tabella esistente fino alla creazione della nuova tabella. In caso contrario, 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 permanenti

Data l'utilità delle tabelle permanenti (PDT e tabelle aggregate), è facile accumularne molte nella tua istanza di Looker. È possibile creare uno scenario in cui il rigeneratore Looker debba creare molte tabelle contemporaneamente. In particolare, con le tabelle con struttura a cascata o con quelle che richiedono molto tempo, puoi creare uno scenario in cui le tabelle hanno un lungo ritardo prima della ricostruzione o in cui gli utenti riscontrano un ritardo nell'ottenere i risultati delle query da una tabella mentre il database lavora duramente per generarla.

Il rigeneratore di Looker controlla gli trigger PDT per verificare se deve ricostruire le tabelle rese permanenti da trigger. Il ciclo del rigeneratore è impostato su un intervallo regolare configurato dall'amministratore di Looker nell'impostazione Pianificazione manutenzione PDT e gruppi di dati nella connessione al database (il valore predefinito è un intervallo di cinque minuti).

Diversi fattori possono influire sul tempo necessario per ricostruire le tabelle:

• L'amministratore di Looker potrebbe aver modificato l'intervallo dei controlli dei trigger del rigeneratore utilizzando l'impostazione Pianificazione della manutenzione di PDT e gruppi di dati sulla connessione del tuo database.
• Il rigeneratore Looker non avvia un nuovo ciclo finché non ha completato tutti i controlli e le ricostruzioni delle PDT dell'ultimo ciclo. Pertanto, se hai ricostruzioni PDT di lunga durata, il ciclo del rigeneratore di Looker potrebbe non essere così frequente come l'impostazione Pianificazione manutenzione PDT e gruppi di dati.
• Per impostazione predefinita, il rigeneratore può avviare la ricostruzione di una sola tabella PDT o aggregata alla volta tramite una connessione. Un amministratore 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 tabelle PDT e aggregate attivate dallo stesso datagroup verranno ricostruite durante lo stesso processo di rigenerazione. Questo può essere un carico elevato se hai molte tabelle che utilizzano il gruppo di dati, direttamente o a seguito di dipendenze a cascata.

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

• Quando le tabelle derivate verranno estese: ogni estensione di una PDT crea una nuova copia della tabella nel tuo 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 di frequente e il dialetto del database non supporta le PDT incrementali.
• Quando il costo e il tempo necessario per creare i PDT sono troppo elevati.

A seconda del numero e della complessità delle tabelle permanenti nella connessione di Looker, la coda potrebbe contenere molte tabelle permanenti che devono essere controllate e ricostruite a ogni ciclo, pertanto è importante tenere presente questi fattori quando implementi le tabelle derivate nell'istanza di Looker.

Gestione dei 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 crei più PDT nell'istanza. Valuta la possibilità di utilizzare l'integrazione di Apache Airflow di Looker per gestire le pianificazioni dei PDT insieme agli altri processi ETL ed ELT.

Monitoraggio e risoluzione dei problemi relativi ai PDT

Se utilizzi tabelle derivate permanenti (PDT), in particolare a cascata, è utile visualizzare il relativo stato. 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 di amministrazione - Tabelle derivate permanenti.

Quando tenti 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 scratch in cui Looker memorizza le tabelle derivate permanenti. Se sono state apportate modifiche, potrebbe essere necessario aggiornare le impostazioni di connessione nella sezione Amministrazione di Looker, quindi riavviare Looker per ripristinare la normale funzionalità della PDT.
• Determina se ci sono problemi con tutte le PDT o solo con una. Se c'è un problema con uno, è probabile che la causa sia un errore LookML o SQL.
• Determina se i problemi relativi al PDT corrispondono agli orari in cui è pianificata la ricostruzione.
• Assicurati che tutte le query sql_trigger_value vengano valutate correttamente e che restituiscano una sola riga e una sola colonna. Per le PDT basate su SQL, puoi farlo eseguendole in SQL Runner. L'applicazione di un LIMIT protegge dalle query incontrollate. Per ulteriori informazioni sull'uso di SQL Runner per eseguire il debug delle tabelle derivate, consulta Utilizzo di SQL Runner per testare le tabelle derivate Post della scheda Community.
• Per le PDT basate su SQL, utilizza SQL Runner per verificare che l'SQL della PDT venga eseguito senza errori. Assicurati di applicare un valore LIMIT in SQL Runner per garantire 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 delle PDT senza avviso. Utilizza invece il codice SQL per il CTE per creare un DT secondario e fare riferimento a quel DT del tuo primo DT utilizzando la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Verifica che le tabelle su cui dipende la PDT problematica, siano tabelle normali o PDT stesse, esistano e che sia possibile eseguire query su di esse.
• Assicurati che le tabelle su cui dipende il problema PDT non abbiano blocchi condivisi o esclusivi. Affinché Looker crei correttamente una PDT, deve acquisire un blocco esclusivo nella tabella da aggiornare. Ciò causerà un conflitto con altri blocchi condivisi o esclusivi attualmente presenti nella tabella. Looker non potrà aggiornare il PDT finché non saranno stati rimossi tutti gli altri blocchi. Lo stesso vale per qualsiasi blocco esclusivo sulla tabella da cui Looker crea una PDT: Se è presente un blocco esclusivo su una tabella, Looker non sarà in grado di acquisire un blocco condiviso per eseguire query finché il blocco esclusivo non viene cancellato.
• Utilizza il pulsante Mostra processi in SQL Runner. Con un numero elevato di processi attivi, i tempi delle query potrebbero diminuire.
• Monitora i commenti nella query. Consulta la sezione Commenti sulle query per le PDT in questa pagina.

Esegui query sui commenti per le PDT

Gli amministratori di database possono distinguere facilmente le query normali da quelle che generano tabelle derivate persistenti (PDT). Looker aggiunge commenti all'istruzione CREATE TABLE ... AS SELECT ... che include il modello e la vista LookML del PDT, oltre a un identificatore univoco (slug) per l'istanza di Looker. Se il file PDT viene generato per conto di un utente in modalità di sviluppo, nei commenti verrà indicato l'ID dell'utente. I commenti relativi alla generazione del file 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 della 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 viene visualizzato nella parte superiore dell'istruzione SQL.

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

Ricostruzione delle 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 una spiegazione di come funziona, consulta la pagina della documentazione Memorizzazione nella cache delle query.
• Se i risultati non sono nella cache, Looker li estrae dalla PDT nel database, se esiste una versione valida della PDT.
• Se nel database non è presente una PDT valida, Looker tenterà di ricrearla.
• Se non è possibile ricostruire la PDT, Looker restituirà un errore per una query. Il rigeneratore Looker tenterà di ricostruire la PDT alla successiva query su quest'ultima o la prossima volta che la strategia di persistenza della PDT attiva una ricostruzione.

Per le PDT a cascata si applica la stessa logica, fatta eccezione per le PDT:

• Un errore di compilazione per una tabella impedisce la compilazione delle PDT lungo la catena di dipendenza.
• Una PDT dipendente esegue essenzialmente una query sulla PDT a cui fa riferimento, pertanto la strategia di permanenza di una tabella può attivare la ricostruzione delle PDT più in alto nella catena.

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

Se TABLE_B presenta un errore, viene applicato tutto il comportamento standard (non a cascata) per TABLE_B: se viene eseguita una query su TABLE_B, Looker tenta innanzitutto di utilizzare la cache per restituire i risultati, poi prova a utilizzare una versione precedente della tabella, se possibile, quindi riprova a creare la tabella e infine restituisce un errore se TABLE_B non può ricreare la tabella. Looker tenterà di nuovo di ricostruire TABLE_B alla successiva query sulla tabella o quando la strategia di persistenza della tabella attiverà di nuovo una ricostruzione.

Lo stesso vale anche per i dipendenti di TABLE_B. Pertanto, se non è possibile creare TABLE_B ed esiste una query su TABLE_C:

• Looker tenterà di utilizzare la cache per la query su TABLE_C.
• Se i risultati non sono nella cache, Looker tenterà di recuperarli da TABLE_C nel database.
• Se non esiste una versione valida di TABLE_C, Looker tenterà di ricostruire TABLE_C, creando una query su TABLE_B.
• Looker tenterà quindi di ricostruire TABLE_B (il che non andrà a buon fine se TABLE_B non è stato corretto).
• Se non è possibile ricreare TABLE_B, TABLE_C non può essere ricreato, quindi Looker restituirà un errore per la query su TABLE_C.
• Looker tenterà quindi di ricostruire TABLE_C in base alla consueta strategia di persistenza o alla successiva query della PDT (inclusa la successiva compilazione di TABLE_D, poiché TABLE_D dipende da TABLE_C).

Una volta risolto il problema con TABLE_B, TABLE_B e ciascuna delle tabelle dipendenti tenteranno di ricreare la build in base alle proprie strategie di persistenza o la prossima volta che viene eseguita una query (inclusa la volta successiva in cui una PDT dipendente tenta di ricreare). In alternativa, se è stata creata una versione di sviluppo delle PDT nella struttura a cascata in modalità di sviluppo, le versioni di sviluppo possono essere utilizzate come nuove PDT di produzione. Per informazioni su come funziona, consulta la sezione Tabelle permanenti in modalità di sviluppo di questa pagina. In alternativa, puoi utilizzare un'esplorazione per eseguire una query su TABLE_D e poi ricostruire manualmente le PDT per la query, in modo da forzare una nuova creazione di tutte le PDT a salire nella cascata delle dipendenze.

Migliorare le prestazioni del PDT

Quando crei tabelle derivate permanenti (PDT), le prestazioni possono essere un problema. In particolare quando la tabella è molto grande, l'esecuzione di query sulla tabella può essere lenta, così come può essere per qualsiasi tabella di grandi dimensioni nel 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

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

Utilizzo di indexes o sortkeys e distribution

Quando crei una tabella derivata permanente (PDT) di grandi dimensioni, l'indicizzazione della tabella (per i dialetti come MySQL o Postgres) o l'aggiunta di sortkey e distribuzione (per Redshift) può migliorare le prestazioni.

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

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

Impostazioni consigliate per migliorare il rendimento

Le seguenti impostazioni controllano il modo in cui i dati nella tabella derivata permanente (PDT) vengono ordinati e indicizzati. 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 in 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 da ridurre al minimo l'I/O tra nodi.
• Per Redshift, imposta il parametro distribution_style su all per indicare al database di conservare una copia completa dei dati su ogni nodo. Questo viene spesso utilizzato per ridurre al minimo l'I/O tra i nodi quando vengono unite 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 al fine di 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 le colonne del file PDT che devono essere indicizzate. (In Redshift, gli indici vengono utilizzati per generare chiavi di ordinamento con interleaving).