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 include queste metriche.

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

Per casi d'uso comuni delle tabelle derivate, consulta la pagina Libri di cucina 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 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 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 è basata su una vista orders esistente, che è 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 visualizzazione 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. Sia che definisci la query della tabella derivata con LookML o con 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 nel 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 tua tabella derivata nativa facendo riferimento alle dimensioni o alle misure LookML nel tuo modello. Guarda il file nativo di visualizzazione tabella derivata nell'esempio precedente.

Rispetto alle tabelle derivate basate su SQL, le tabelle derivate native sono molto più facili da leggere e comprendere quando modelli i 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.

Di solito, 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 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 una 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, il predittivo BigQuery ML di Google), puoi utilizzare il parametro sql_create per creare una PDT anziché il parametro sql. Per informazioni ed esempi, consulta la pagina della documentazione sql_create.

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 sono tutte considerate 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. Ecco perché l'esempio precedente utilizza MIN(DATE(time)) AS first_order anziché semplicemente MIN(DATE(time)).

Nota: per essere utilizzata come PDB incrementale, è necessario definire una tabella derivata basata su SQL con 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, c'è anche una distinzione tra una tabella derivata temporanea, che non è scritta nel database, e una tabella derivata persistente, che viene scritta in uno schema del tuo database.

Le tabelle derivate native e quelle 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.

Altrimenti, 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 richieda un po' di tempo, la PDT è spesso una scelta migliore.

Dialetti di database supportati per le tabelle derivate temporanee

Affinché Looker possa supportare le tabelle derivate nel tuo progetto Looker, è necessario che siano supportate anche dal dialetto del database. La tabella seguente mostra quali dialetti supportano le tabelle derivate nell'ultima release di Looker:

Dialetto	Supportata?
Valanga Actia	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 o 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 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ì
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ì
Greenplum	Sì
HyperSQL	Sì
Netezza di IBM	Sì
MariaDB	Sì
PostgreSQL Microsoft Azure	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 o versioni successive	Sì
MongoBI	Sì
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-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ì
Vettore	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 di 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 database. Può essere qualsiasi schema sul tuo 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 Abilita PDT attivata. In genere questa opzione è impostata durante la configurazione iniziale della connessione a Looker (consulta la pagina della documentazione sui dialetti di Looker per istruzioni sul dialetto del database), 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 database supporti le tabelle.

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 (di solito i database delle repliche hot-swap di Postgres). In questi casi, puoi utilizzare invece tabelle derivate temporanee.

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

Dialetto	Supportata?
Valanga Actia	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 o 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 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ì
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
Greenplum	Sì
HyperSQL	No
Netezza di IBM	Sì
MariaDB	Sì
PostgreSQL Microsoft Azure	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 o versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-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ì
Vettore	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	Supportata?
Valanga Actia	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 o 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 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ì
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
Greenplum	Sì
HyperSQL	No
Netezza di IBM	Sì
MariaDB	Sì
PostgreSQL Microsoft Azure	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 o versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
Oracle ADWC	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-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ì
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 nuovi dati alla tabella anziché ricrearla 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 alle PDT incrementali.

Dialetti di database supportati per le PDT incrementali

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

Dialetto	Supportata?
Valanga Actia	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 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 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ì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sì
HyperSQL	No
Netezza di IBM	No
MariaDB	No
PostgreSQL Microsoft Azure	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 o versioni successive	No
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	No
Oracle ADWC	No
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	No
PrestoSQL	No
SAP HANA 2 o versioni successive	No
SingleStore	No
SingleStore 7+	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), definisci una strategia di persistenza per la tabella. Per ottimizzare il rendimento, ti consigliamo di aggiungere anche 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 tuo database utilizzando le viste materializzate.

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

• Parametri di persistenza gestita da Looker:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parametri di persistenza gestita da 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 ricostruisce 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 ottenere le risposte alle query di esplorazione dalla PDT.

Nota: alcuni utenti possono ignorare 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 richieste per la query attuale 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 gruppo di dati con sql_trigger o interval_trigger, puoi utilizzare il parametro datagroup_trigger per avviare la rigenerazione delle tabelle derivate permanenti (PDT).

Looker conserva la PDT nel database fino a quando non viene attivato il 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 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.

Consulta la sezione Il rigeneratore Looker per maggiori informazioni su come il rigeneratore crea le PDT.

sql_trigger_value

Il parametro sql_trigger_value attiva la rigenerazione di una tabella derivata permanente (PDT) in base a un'istruzione SQL da te fornita. 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 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.

Consulta la sezione Il rigeneratore Looker per maggiori informazioni su come il rigeneratore crea le PDT.

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". Analogamente al parametro sql_trigger, questo significa che in genere la PDT viene creata automaticamente quando gli utenti la eseguono query. 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.

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 di essere contrassegnata come scaduta, in modo che non venga più utilizzato per le query e venga eliminata dal database.

Una tabella derivata (PDT) persist_for viene creata quando un utente esegue una query per la prima volta. Looker mantiene 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 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 ricreate automaticamente dal rigeneratore di Looker, tranne nel caso di una cascade di dipendenza 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 in uso, una vista materializzata può consumare risorse di grandi dimensioni, quindi è importante comprendere l'implementazione delle viste materializzate nel dialetto. Consulta la documentazione del dialetto per informazioni sul comportamento del dialetto e sulla frequenza con cui quest'ultimo aggiorna i dati per le 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 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à della vista materializzata richiede una conoscenza avanzata del dialetto e delle caratteristiche dell'utente. Nella maggior parte dei casi, il database aggiorna la vista materializzata ogni volta che rileva nuovi dati nelle tabelle sottoposte a query dalla vista materializzata. Le viste materializzate sono ideali per 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, è consigliabile ottimizzarle utilizzando le strategie seguenti, supportate dal dialetto in uso:

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

Ad esempio, per aggiungere persistenza all'esempio di tabella derivata, puoi impostarla in modo che venga ricreata quando si attiva il gruppo di dati orders_datagroup e aggiungere indici sia customer_id che 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 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 modellare i dati senza utilizzare le 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 dover creare una PDT. Assicurati di analizzare i piani di esecuzione delle query lente utilizzando lo strumento Spiega da SQL Runner.

Oltre a ridurre il tempo e il carico del database per le query eseguite spesso, esistono diversi altri casi d'uso per le 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 vi sia un modo ragionevole per identificare una riga univoca in una tabella come chiave primaria.

Utilizzo delle 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 LookML iniziale per la vista potrebbe essere simile al seguente:

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 la PDT. Poi esegui le query di prova 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.

Utilizzo delle PDT per pre-unire o aggregare i dati

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, supponi di voler generare report sui clienti per 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 una sola volta e poi 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]
  }
}

Cascading delle tabelle derivate

È 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 e TABLE_B da TABLE_A.

Nota: prima di configurare le tabelle derivate a cascata, è importante sapere in che modo queste tabelle vengono ricreate automaticamente dal rigeneratore di Looker e come possono essere ricreate manualmente dagli utenti. Ci sono 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 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 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 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 event_summary PDT è un riepilogo della clean_events PDT. 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 particolare esempio potrebbe 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 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 vengono denominate con lunghi codici nel tuo 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, allora TABLE_D dipende 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. Prima deve però ricreare TABLE_C.

Ora prendiamo in considerazione uno scenario di tabelle derivate temporanee 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, Looker creerà tutte le tabelle necessarie per la query. Looker creerà TABLE_A, poi TABLE_B e infine TABLE_C:

In questo scenario, TABLE_A deve terminare la generazione prima che Looker possa iniziare a generare TABLE_B e così via, fino al termine di TABLE_C e Looker può fornire i risultati della query. Poiché TABLE_D non è necessario per rispondere a questa query, al momento Looker non creerà di nuovo TABLE_D.

Consulta la pagina della documentazione del parametro datagroup per uno scenario di esempio di PDT 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 sia necessario ricompilarle. Con le query utente standard sulle PDT a cascata, Looker ricostruisce le PDT in questa fase 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 l'esecuzione di query sulla PDT da cui dipende. Ciò è significativo soprattutto per le 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.

Ricreando manualmente le tabelle permanenti per una query

Gli utenti possono selezionare l'opzione Ricrea 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 richieste 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 Ricrea 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. Include tutte le tabelle e le PDT aggregate nella query attuale, nonché le tabelle e le PDT aggregate a cui viene fatto riferimento dalle tabelle e dalle PDT aggregate nella query corrente.

In caso di PDT incrementali, l'opzione Ricrea le 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. Questo è lo stesso comportamento di quando esegui una query su una tabella in una casa di tabelle derivate temporanee:

Tieni presente quanto segue sulla ricreazione manuale delle tabelle derivate:

• Per l'utente che avvia l'operazione Ricrea le tabelle derivate ed esegui, la query attenderà che la tabella venga ricompilata prima di caricare i risultati. Le query degli altri utenti continueranno a utilizzare le tabelle esistenti. Una volta ricreate le tabelle permanenti, tutti gli utenti utilizzeranno le tabelle create di nuovo. Sebbene questo processo sia progettato per evitare l'interruzione delle query di altri utenti durante la ricreazione 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 ricompilazione durante l'orario di apertura potrebbe mettere a dura prova il tuo database, potresti dover comunicare agli utenti che non dovrebbero mai ricreare alcune PDT o tabelle aggregate durante questi orari.

• Se un utente è in modalità di sviluppo e l'esplorazione è basata 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à 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, 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 nuova creazione della tabella non riuscirà 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 persistente, che include tabelle aggregate e 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. Questa tabella di sviluppo ti consente di testare le modifiche senza disturbare gli utenti finali.

Che cosa spinge Looker a creare una tabella di sviluppo

Quando possibile, Looker utilizza la tabella di produzione esistente per rispondere alle query, indipendentemente dal fatto che 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 creerà una tabella di sviluppo se sei in modalità di sviluppo ed esegui 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 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 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 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):

• 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 dall'effettiva strategia di persistenza della tabella, Looker tratta le tabelle persistenti di sviluppo come se avessero una strategia di persistenza di persist_for: "24 hours". Looker lo fa per garantire che le tabelle di sviluppo non siano persistenti per più di un giorno, dato che 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 regolarmente dal database.

Altrimenti, Looker crea tabelle derivate permanenti (PDT) e aggrega tabelle in modalità di sviluppo allo stesso modo in cui crea tabelle permanenti in modalità di produzione.

Se una tabella di sviluppo è 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 essere comunque necessario ricreare la tabella per poter eseguire query in produzione, a seconda della situazione:

• Se sono trascorse più di 24 ore dall'esecuzione di query sulla tabella in modalità di sviluppo, la versione di sviluppo della tabella è 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 persistente 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 è persistente nel database quando esegui il deployment delle modifiche a una tabella derivata permanente (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. Per ulteriori dettagli, consulta le sezioni Per quanto tempo Looker mantiene le tabelle di sviluppo e Cosa spinge Looker a creare una tabella di sviluppo in questa pagina.

Pertanto, è consigliabile creare tutte le PDT al momento del 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 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 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 cessa di esistere, Looker contrassegna la tabella come scaduta.

Questo approccio comporta 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 trasferite le modifiche dalla modalità di sviluppo alla modalità di produzione, la precedente definizione di produzione non esiste più, quindi 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ù, quindi le tabelle di sviluppo non necessarie vengono contrassegnate come scadute e verranno eliminate.

Lavoro più rapido in modalità Sviluppo

In alcuni casi, la tabella derivata permanente (PDT) che stai creando richiede molto tempo per la generazione, 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 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 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 affinché tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se sia dev_filters sia 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 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 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 i dati dal 2020 in poi in modalità Sviluppo. L'uso strategico di questa funzionalità per limitare il set di risultati e aumentare la velocità delle query può rendere molto più facile la convalida delle modifiche alla modalità di sviluppo.

Nota :se una tabella persistente ha il parametro dev_filters o la clausola WHERE condizionale, non è possibile utilizzare la tabella di sviluppo 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 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 aver definito una tabella derivata permanente (PDT) e averla eseguita per la prima volta o attivata dal rigeneratore per la ricostruzione in base alla sua strategia di persistenza, Looker esegue i seguenti passaggi:

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

Ci sono alcune importanti implicazioni:

• 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 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 Looker

Il rigeneratore Looker controlla lo stato e avvia le ricompilazioni per le tabelle permanenti da 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 Looker attiva la ricreazione della tabella quando il risultato dell'ultimo controllo delle query trigger è diverso da quello del precedente controllo delle query trigger. 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 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 una durata specificata nel parametro interval_trigger del gruppo di dati.

Il rigeneratore Looker avvia anche le ricompilazioni per le tabelle persistenti che utilizzano il parametro persist_for, ma solo quando la tabella persist_for è una dipendenza cascade di una tabella permanente con 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. Questo significa che se disponi di build PDT a lunga esecuzione, il ciclo del rigeneratore Looker potrebbe non essere eseguito con la frequenza definita nell'impostazione Datagroup e PDT Manutenzione pianificazione. Altri fattori possono influire sul tempo necessario per ricreare le tabelle, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle permanenti in questa pagina.

Nei casi in cui non si riesca a creare una PDT, il rigeneratore può tentare di ricreare la tabella nel successivo ciclo del rigeneratore:

• Se l'impostazione Riprova build PDT non riuscite è abilitata sulla connessione del database, il rigeneratore Looker tenterà di ricreare 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 viene soddisfatta.

Se un utente richiede i dati della tabella persistente mentre è in fase di 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 di database diversa o se 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 verrà 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 sull'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 ricrearle o in cui gli utenti riscontrano un ritardo nel recupero dei risultati delle query da una tabella mentre il database lavora duramente per generare la tabella.

Il rigeneratore di Looker controlla gli attivatori PDT per verificare se deve ricreare le tabelle permanenti dei trigger. Il ciclo del rigeneratore viene impostato 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).

Diversi fattori possono influire sul tempo necessario per ricreare 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 disponi di build PDT a lunga esecuzione, il ciclo del rigeneratore Looker potrebbe non essere frequente come l'impostazione Datagroup e PDT Manutenzione pianificazione.
• Per impostazione predefinita, il rigeneratore può avviare la ricostruzione di una PDT o di una tabella aggregata alla volta su 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 PDT e le tabelle aggregate attivate dalla stessa datagroup verranno create nuovamente durante lo stesso processo di rigenerazione. Questo può essere un carico elevato se disponi di molte tabelle che utilizzano il gruppo di dati, direttamente o come risultato di dipendenze a cascata.

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

• Quando le tabelle derivate verranno extended: ogni estensione di una PDT crea una nuova copia della tabella nel tuo database.
• Se le tabelle derivate utilizzano filtri con 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 necessari per la creazione delle PDT sono troppo elevati.

A seconda del numero e della complessità delle tabelle persistenti sulla tua connessione Looker, la coda potrebbe contenere molte tabelle permanenti che devono essere controllate e ricreate a ogni ciclo, per cui è importante tenere a mente questi fattori quando implementi le 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 crei più PDT nell'istanza. Prendi in considerazione l'utilizzo dell'integrazione Apache Airflow di Looker per gestire le tue 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, è utile controllarne lo 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 le tabelle di sviluppo e quelle di produzione quando esamini il log degli eventi PDC.
• Verifica che non siano state apportate modifiche allo schema temporaneo in cui Looker archivia le tabelle derivate permanenti. Se sono state apportate modifiche, potresti dover aggiornare le impostazioni 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 con una solo. Se c'è un problema con uno, è probabile che la causa sia un errore LookML o SQL.
• Determina se i problemi con la PDT corrispondono agli orari in cui è pianificata la ricompilazione.
• Assicurati che tutte le query sql_trigger_value vengano valutate correttamente e che restituiscano solo una riga e una 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'utilizzo di SQL Runner per eseguire il debug delle tabelle derivate, consulta il post della 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 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 preavviso. 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}.
• Controlla che esistano tabelle da cui dipende il problema della PDT, che siano tabelle normali o PDT stesse, e che sia possibile eseguire query.
• Assicurati che tutte le tabelle da cui dipende la PDT del problema non abbiano blocchi condivisi o esclusivi. Affinché Looker crei correttamente una PDT, deve acquisire un blocco esclusivo nella tabella da aggiornare. Questa operazione è in conflitto con altri blocchi condivisi o esclusivi attualmente presenti nella tabella. Looker non sarà in grado di aggiornare la PDT fino a quando tutti gli altri blocchi non saranno stati cancellati. Lo stesso vale per tutti i blocchi esclusivi nella 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 Query commenti 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 include il modello e la vista 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 relativi alla generazione di 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.

Ricreazione di PDT dopo un errore

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

• Looker utilizzerà i risultati nella cache se la stessa query è stata eseguita in precedenza. Per una spiegazione del funzionamento, consulta la pagina della documentazione Memorizzazione nella cache delle query.
• Se i risultati non sono presenti nella cache, Looker estrarrà i risultati 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 ricreare 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 creazione di PDT lungo la catena delle dipendenze.
• Una PDT dipendente esegue effettivamente query sulla PDT su cui si basa, quindi la strategia di persistenza di una tabella può attivare la rigenerazione delle PDT fino a salire della 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 proverà di nuovo a ricreare la creazione di TABLE_B alla successiva query sulla tabella o al momento in cui la strategia di persistenza della tabella attiva una nuova creazione.

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

• Looker proverà a utilizzare la cache per la query su TABLE_C.
• Se i risultati non sono presenti nella cache, Looker proverà a eseguire il pull dei 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 la build di TABLE_B (operazione che non andrà a buon fine se TABLE_B non è stato risolto).
• 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à di ricreare TABLE_C in base alla sua solita strategia di persistenza o la prossima volta che viene eseguita una query sulla PDT (che include il successivo tentativo di creazione 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). Oppure, se una versione di sviluppo delle PDT in cascade è stata creata in modalità di sviluppo, queste 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 la ricreazione di tutte le PDT a salire nella cascata delle dipendenze.

Miglioramento delle prestazioni delle PDT

Quando crei tabelle derivate permanenti (PDT), le prestazioni possono rappresentare 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, solo i dati pertinenti verranno aggiunti alla tabella ogni volta che viene creata una nuova build, in modo che l'esecuzione delle query sia molto più veloce. Quindi, puoi creare una PDT separata e più ampia per l'analisi storica, in modo da consentire sia query rapide per dati recenti sia la possibilità di eseguire query su vecchi dati.

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, è consigliabile aggiungere il parametro indexes nei campi ID o Data.

Per Redshift, di solito è preferibile aggiungere il parametro sortkeys nei campi ID o Data e il parametro distribution nel 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 ciascun nodo. Questa opzione viene spesso utilizzata per ridurre al minimo l'I/O tra nodi quando vengono unite tabelle molto 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 quali colonne delle PDT vengono indicizzate. (In Redshift, gli indici vengono utilizzati per generare chiavi di ordinamento con interleaving).