Tabelle derivate in Looker

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

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

Puoi quindi 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 due modi:

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

Ad esempio, i seguenti file di visualizzazione mostrano come utilizzare LookML per creare una visualizzazione da una tabella derivata customer_order_summary. Le due versioni di LookML mostrano come puoi 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 importa i campi customer_id, first_order e total_amount dal file della visualizzazione orders.
• La tabella derivata basata su SQL definisce la query utilizzando SQL nel parametro sql. In questo esempio, la query SQL è una query diretta della tabella orders nel database.

Versione 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 di 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 vista. 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 informazioni dettagliate sulla creazione di tabelle derivate native, consulta la pagina della documentazione Creare tabelle derivate native.

Tabelle derivate basate su SQL

Per creare una tabella derivata basata su SQL, definisci una query in termini SQL, creando colonne nella tabella utilizzando una query SQL. Non puoi fare riferimento alle dimensioni e alle misure di LookML in una tabella derivata basata su SQL. Consulta il file della vista 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 le tabelle derivate permanenti (PDT):

• create_process: quando utilizzi il parametro sql per una PDT, in background Looker inserisce l'istruzione DDL (Data Definition Language) CREATE TABLE del dialetto nella query per creare la PDT dalla query SQL. Alcuni dialetti non supportano un'istruzione CREATE TABLE SQL in un unico 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 del 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 di 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 ogni colonna un alias pulito utilizzando AS. Questo perché dovrai 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 con 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 è stata definita una strategia di persistenza nel parametro derived_table.

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

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 siano performanti e non mettano a dura prova 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 i dialetti che supportano le tabelle derivate nell'ultima release di Looker:

Dialetto	Supportato?
Actian Avalanche	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Apache Druid	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 e versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	Sì
Cloudera Impala 3.1 e versioni successive	Sì
Cloudera Impala 3.1 e 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 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	Sì
MySQL	Sì
MySQL 8.0.12 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 e versioni successive	Sì
SingleStore	Sì
SingleStore 7 e versioni successive	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 nel database e rigenerata secondo la pianificazione specificata con una strategia di persistenza.

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

Requisiti per i PDT

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

• Un dialetto del database che supporta i PDT. Consulta la sezione Dialetti di database supportati per le tabelle derivate permanenti di questa pagina per gli elenchi dei dialetti che supportano le tabelle derivate permanenti basate su SQL e le tabelle derivate native permanenti.

• Uno schema scratch nel database. Può essere qualsiasi schema nel database, ma ti consigliamo di crearne uno nuovo che verrà utilizzato solo per questo scopo. L'amministratore del database deve configurare lo schema con l'autorizzazione di scrittura per l'utente del database Looker.

  Avviso: se hai più istanze di Looker, ad esempio un'istanza di produzione e un'istanza di QA, assicurati di impostare schemi scratch diversi per ogni istanza per evitare conflitti di gestione dei PDT.

• Una connessione Looker configurata con l'opzione di attivazione/disattivazione Attiva PDT attivata. Di solito, questa operazione viene eseguita durante la configurazione iniziale della connessione di Looker (consulta la pagina della documentazione relativa ai dialetti di Looker per istruzioni sul tuo dialetto del database), ma puoi anche attivare le PDT per la connessione dopo la configurazione iniziale.

Dialetti del database supportati per i PDT

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

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

La seguente tabella 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ì
Apache Druid	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 e versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	No
Cloudera Impala 3.1 e versioni successive	Sì
Cloudera Impala 3.1 e 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
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 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 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 e versioni successive	Sì
SingleStore	Sì
SingleStore 7 e versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettoriale	Sì
Vertica	Sì

Per supportare le tabelle derivate native persistenti (con 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ì
Apache Druid	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 e versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	No
Cloudera Impala 3.1 e versioni successive	Sì
Cloudera Impala 3.1 e 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
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 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 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 e versioni successive	Sì
SingleStore	Sì
SingleStore 7 e versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettoriale	Sì
Vertica	Sì

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

Creazione incrementale delle 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 PDT utilizza una strategia di persistenza basata su trigger (datagroup_trigger, sql_trigger_value o interval_trigger), puoi definirla come incrementale.

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

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

Dialetti del database supportati per le tabelle 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 i PDT incrementali nell'ultima release di Looker:

Dialetto	Supportato?
Actian Avalanche	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sì
Apache Druid	No
Apache Druid 0.13 o versioni successive	No
Apache Druid 0.18 o versioni successive	No
Apache Hive 2.3 e 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 e versioni successive	No
Cloudera Impala 3.1 e 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
Fulmine	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
IBM Netezza	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 e versioni successive	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 e versioni successive	No
MongoBI	No
MySQL	Sì
MySQL 8.0.12 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 e versioni successive	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), devi definire una strategia di persistenza per la tabella. Per ottimizzare il rendimento, devi anche aggiungere una strategia di ottimizzazione.

Strategie di persistenza

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

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

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

Con le strategie di persistenza basate su trigger (datagroup_trigger, sql_trigger_value e interval_trigger), Looker gestisce la PDT nel database finché non viene attivata per 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 un 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 Ricompilare 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 ricostruzione 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 ricostruisce la PDT per sostituire la versione precedente. 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 restituisce i dati della PDT esistente fino alla creazione della nuova PDT. Per una panoramica dei gruppi di dati, consulta Memorizzazione nella cache delle query.

Per 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, il PDT esistente viene mantenuto 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 restituisce i dati della PDT esistente fino a quando non viene creata la 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 a quando non viene creata la nuova PDT.

persist_for

Un'altra opzione è utilizzare il parametro persist_for per impostare il periodo di tempo per cui la tabella derivata deve essere archiviata prima che venga contrassegnata come scaduta, in modo che non venga più utilizzata 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 l'ora persist_for, Looker cancella la PDT dal database e la ricostruisce la volta successiva che un utente esegue una query, il che significa che la query dovrà attendere la ricostruzione.

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 struttura a cascata di dipendenze con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), il rigeneratore monitora e ricostruisce la tabella persist_for per ricostruire le altre tabelle nella cascata. Consulta la sezione In che modo Looker crea tabelle derivate con struttura a cascata in questa pagina.

materialized_view: yes

Nota: la funzionalità 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 ti consentono di sfruttare la funzionalità del database per rendere persistenti le tabelle derivate nel progetto Looker. Se il dialetto del database supporta le viste materializzate e la connessione a Looker è configurata con l'opzione di attivazione/disattivazione Attiva 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.

Come una tabella derivata permanente (PDT), una vista materializzata è un risultato di query archiviato come tabella nello schema temporaneo del database. La differenza principale tra un PDT e una vista materializzata riguarda il 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 gestione e dell'aggiornamento dei dati nella tabella.

Per questo motivo, la funzionalità di vista 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.

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

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 mantenendone i risultati 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 tabella 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-join 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 i PDT per testare diverse indicizzazioni, distribuzioni e altre opzioni di ottimizzazione senza richiedere un'assistenza eccessiva da parte dei tuoi DBA o degli sviluppatori ETL.

Considera un caso in cui hai una tabella, ma vuoi testare diversi indici. Il codice LookML iniziale per la visualizzazione 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 a LookML come segue:

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 PDT. Quindi, 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 modificare nuovamente il codice della visualizzazione per rimuovere il PDT.

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

Può essere utile eseguire una prejoin o una preaggregazione dei 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 con gerarchia o tabelle derivate permanenti con gerarchia, 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. Esistono anche altre considerazioni importanti per l'implementazione delle tabelle permanenti. 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 la stessa sintassi per fare riferimento a una vista LookML. Anche in questo caso, SQL_TABLE_NAME è una stringa letterale.

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

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

La PDT event_summary e la PDT clean_events sono PDT con struttura a cascata, in cui event_summary dipende da clean_events (poiché event_summary è definita 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 necessario, quando fai riferimento a una tabella derivata in questo modo, è spesso utile creare un alias per la tabella utilizzando questo formato:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

L'esempio precedente esegue le seguenti operazioni:

${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 (in particolare con le clausole ON) è facile dimenticare che devi utilizzare la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME} per recuperare questo nome lungo. Un alias può aiutarti a evitare questo tipo di errore.

Come Looker crea tabelle derivate con struttura a cascata

Nel caso di tabelle derivate temporanee con struttura 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 ricostruirà 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 necessarie 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 creerà qualsiasi tabella necessaria per rispondere a una query, fino alla cima della catena di dipendenze. Tuttavia, con i PDT, spesso le tabelle esistono già e non devono 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 ricostruzione per tutte le PDT in cascata, puoi ricostruire manualmente le tabelle per una query tramite un'esplorazione.

Un punto logico importante da comprendere è che, nel caso di una serie di PDT, un PDT dipendente esegue essenzialmente una query sul PDT da cui dipende. Questo è importante soprattutto per i PDT che utilizzano la strategia persist_for. In genere, i PDT persist_for vengono creati quando un utente li richiede, rimangono nel database fino al termine dell'intervallo persist_for e non vengono ricostruiti fino alla successiva query da parte di un utente. Tuttavia, se una PDT persist_for fa parte di una struttura a cascata con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), la PDT persist_for viene in sostanza sottoposta a query ogni volta che le PDT dipendenti vengono ricostruite. In questo caso, la PDT persist_for verrà ricostruita in base alla pianificazione delle PDT dipendenti. Ciò significa che le persist_for PDT possono essere interessate dalla strategia di persistenza dei relativi elementi 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 autorizzazione develop e solo dopo il caricamento della query dell'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 compilazione di un nuovo incremento. Con i PDT incrementali, un incremento include il periodo di tempo specificato nel parametro increment_key, nonché il numero di periodi di tempo precedenti specificati nel parametro increment_offset, se presenti. Consulta la pagina della documentazione relativa alle PDT incrementali per alcuni scenari di esempio che mostrano come vengono create le PDT incrementali, a seconda della loro configurazione.

Nel caso di PDT con struttura a cascata, ciò significa ricostruire tutte le tabelle derivate nella struttura a cascata, partendo 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 ricostruzione manuale delle tabelle derivate:

• Per l'utente che avvia l'operazione Ricostruisci tabelle derivate ed esegui, la query attenderà la ricostruzione delle tabelle prima di caricare i risultati. Le query degli altri utenti continueranno a utilizzare le tabelle esistenti. Una volta ricostruite, tutte le tabelle persistenti verranno utilizzate da tutti gli utenti. Sebbene questa procedura sia progettata per evitare di interrompere le query di altri utenti durante la ricostruzione delle tabelle, questi utenti potrebbero comunque essere interessati dal carico aggiuntivo sul database. Se ti trovi in una situazione in cui l'attivazione di una 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 è in modalità di sviluppo e l'esplorazione si basa su una tabella di sviluppo, l'operazione Ricostruisci tabelle derivate ed esegui ricostruirà la tabella di sviluppo, non la tabella di produzione, per l'esplorazione. Tuttavia, se 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, consulta Tabelle permanenti in modalità di sviluppo.

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

Tabelle permanenti in modalità di sviluppo

Looker ha alcuni comportamenti speciali per la gestione delle tabelle permanenti 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 relativa definizione, Looker eseguirà una query sulla versione di produzione della tabella. Se apporti una modifica alla definizione della tabella che influisce sui dati al suo interno o sul modo in cui viene eseguita la query, verrà creata una nuova versione di sviluppo della tabella alla successiva esecuzione di una query in modalità di sviluppo. 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

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

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

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: non è così 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 permanenti 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 poi esegua una query sulla tabella in modalità di sviluppo. Questo vale per qualsiasi modifica alla tabella che influisca sui dati al suo interno o sul modo in cui viene eseguita la query.

Di seguito sono riportati alcuni esempi dei tipi di modifiche che inducono Looker a creare una versione di sviluppo di una tabella permanente (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 permanente, ad esempio la modifica del parametro explore_source, sql, query, sql_create o create_process nella tabella permanente stessa o in qualsiasi tabella richiesta (nel caso di tabelle derivate con struttura a cascata)
• Modifica della strategia di persistenza della tabella, ad esempio la modifica del parametro datagroup_trigger, sql_trigger_value, interval_trigger o persist_for della tabella
• Modificare il nome di view di una tabella derivata
• Modifica di increment_key o increment_offset di una PDT incrementale
• Modifica dell'attributo connection utilizzato dal modello associato

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

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 ingombrino il database, Looker applica la strategia persist_for: "24 hours" per assicurarsi che le tabelle vengano eliminate dal database di frequente.

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, potrebbe essere necessario ricostruire la tabella per poter eseguire 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 hai PDT non create, puoi eseguire query su di esse in modalità di sviluppo appena prima di apportare le modifiche in modo che la tabella di sviluppo sia disponibile per l'utilizzo 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 una 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.

In caso contrario, se esegui il deployment delle modifiche quando non è presente una tabella di sviluppo valida che può essere utilizzata come tabella di produzione, Looker la ricostruirà la volta successiva che verrà eseguita una query in modalità di produzione (per le tabelle permanenti che utilizzano la strategia persist_for) o la volta successiva che verrà eseguito Regenerator (per le tabelle permanenti che utilizzano datagroup_trigger, interval_trigger o sql_trigger_value).

Verificare la presenza di PDT non create in modalità di sviluppo

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 se nel progetto sono presenti PDT non compilati nel riquadro Integrità del progetto. Fai clic sull'icona Stato del progetto nell'IDE di Looker per aprire il riquadro Stato del progetto. Quindi, fai clic sul pulsante Convalida stato PDT.

Se sono presenti PDT non create, il riquadro Stato del progetto li elenca:

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

Una volta identificata una PDT non creata nel progetto, puoi creare una versione di sviluppo aprendo un'esplorazione che esegue query sulla tabella e poi utilizzando l'opzione Ricostruisci tabelle derivate ed esegui dal menu Esplora. Consulta la sezione Ricompilazione manuale delle 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 ulteriori informazioni, 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 esegua una query sulla tabella in modalità di sviluppo (consulta la sezione Che cosa fa sì che Looker crei una tabella di sviluppo in questa pagina della documentazione).

Condivisione e pulizia delle tabelle

All'interno di una determinata istanza di Looker, le tabelle persistenti verranno condivise 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 accade 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 una 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 esegua una 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ù, pertanto la vecchia tabella di produzione viene contrassegnata come scaduta e verrà eliminata.
• Se decidi di ignorare le modifiche apportate in modalità di sviluppo, la definizione di tabella non esiste più, pertanto 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 chiedere 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 parametro secondario 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 in modo che 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 una 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 ulteriori dettagli sull'utilizzo delle tabelle di sviluppo in produzione, consulta la sezione Per quanto tempo Looker mantiene le tabelle di sviluppo in questa pagina.

Come 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 ricostruire 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

Ecco alcune implicazioni importanti:

• 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 colonne validi.
• I nomi utilizzati per specificare la distribuzione, le chiavi di ordinamento e gli indici devono essere i nomi delle colonne elencati nella definizione SQL della tabella derivata, non i nomi dei campi definiti in LookML.

Il rigeneratore di Looker

Il rigeneratore Looker controlla lo stato e avvia le ricostruzioni per le tabelle con persistenza tramite trigger. Una tabella resa permanente da trigger è una tabella derivata permanente (PDT) o una tabella aggregata che utilizza un trigger come strategia di permanenza:

• 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 di Looker ricostruirà la tabella la volta successiva che il rigeneratore controlla l'attivatore 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 avvia le ricostruzioni per una tabella persist_for, poiché è necessaria per la ricostruzione delle altre tabelle nella cascata. In caso contrario, il rigeneratore non monitora le tabelle permanenti che utilizzano la strategia persist_for.

Il ciclo del rigeneratore di Looker inizia a 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). Tuttavia, il rigeneratore Looker non avvia un nuovo ciclo finché non ha completato tutti i controlli e le ricostruzioni delle 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.

Se la creazione di una PDT non riesce, il rigeneratore potrebbe tentare di ricostruire la tabella nel ciclo 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 degli trigger del rigeneratore utilizzando l'impostazione Pianificazione manutenzione PDT e gruppi di dati nella connessione al 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 di Looker può modificare 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 vengono estese: ogni estensione di una PDT crea una nuova copia della tabella nel database.
• Quando le tabelle derivate utilizzano filtri basati su modelli o parametri Liquid: la persistenza non è supportata per le tabelle derivate che utilizzano filtri basati su modelli o parametri Liquid.
• Quando le tabelle derivate native vengono create da esplorazioni che utilizzano gli attributi utente con access_filters o con sql_always_where, nel database vengono create copie della tabella per ogni possibile valore dell'attributo utente specificato.
• Quando i dati sottostanti cambiano di frequente e il tuo dialetto del database non supporta i 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 persistenti (PDT) che vengono aggiornate in base a pianificazioni diverse diventa sempre più complesso man mano che crei più PDT nella tua 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 tabelle derivate permanenti a cascata, è utile visualizzare il loro stato. Puoi utilizzare la pagina di amministrazione Tabelle derivate permanenti di Looker per visualizzare lo stato delle PDT. Per informazioni, consulta la pagina di documentazione Impostazioni amministratore - Tabelle derivate permanenti.

Quando provi a risolvere i problemi relativi ai 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 e, eventualmente, riavviare Looker per ripristinare la normale funzionalità del PDT.
• Determina se ci sono problemi con tutte le PDT o solo con una. Se si verifica un problema con uno di questi, è probabile che sia causato da un errore di 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 i PDT basati su SQL, puoi eseguirli in SQL Runner. L'applicazione di un LIMIT protegge dalle query inutilizzate. Per ulteriori informazioni sull'utilizzo di SQL Runner per eseguire il debug delle tabelle derivate, consulta il post della community Utilizzare SQL Runner per testare le tabelle derivate .
• Per i PDT basati su SQL, utilizza SQL Runner per verificare che il codice SQL del PDT venga eseguito senza errori. Assicurati di applicare un LIMIT in SQL Runner per mantenere ragionevoli i tempi di query.
• Per le tabelle derivate basate su SQL, evita di utilizzare le espressioni di tabella comuni (CTE). L'utilizzo di CTE con DT crea istruzioni WITH nidificate che possono causare l'errore dei PDT senza avviso. Utilizza invece il codice SQL per la CTE per creare un DT secondario e fai riferimento a questo DT dal 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 possa creare correttamente un PDT, deve acquisire un blocco esclusivo sulla tabella da aggiornare. Questo sarà in conflitto con altri blocchi condivisi o esclusivi attualmente presenti nella tabella. Looker non potrà aggiornare il PDT finché non saranno stati rimossi tutti gli altri blocchi. Lo stesso vale per tutti i blocchi esclusivi sulla tabella da cui Looker sta creando una PDT. Se esiste un blocco esclusivo su una tabella, Looker non potrà acquisire un blocco condiviso per eseguire query finché il blocco esclusivo non viene rimosso.
• Utilizza il pulsante Mostra processi in SQL Runner. Se sono attivi un numero elevato di processi, i tempi di query potrebbero rallentare.
• Monitora i commenti nella query. Consulta la sezione Eseguire query sui commenti per i dati proprietari 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 sulla generazione della PDT viene visualizzato nella scheda SQL di un'esplorazione se Looker ha dovuto generare una PDT per la query dell'esplorazione. Il commento verrà visualizzato nella parte superiore dell'istruzione SQL.

Infine, il commento relativo alla generazione del 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 ricostruirla.
• Se non è possibile ricostruire la PDT, Looker restituirà un errore per una query. Il rigeneratore Looker tenterà di ricostruire la PDT alla successiva query o alla successiva attivazione di una ricostruzione da parte della strategia di persistenza della PDT.

Con le PDT a cascata si applica la stessa logica, tranne per il fatto che con le PDT a cascata:

• 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 di cui si basa, pertanto la strategia di permanenza di una tabella può attivare la ricostruzione delle PDT più in alto nella catena.

Ritorniamo all'esempio precedente di tabelle con struttura a cascata, in cui TABLE_D dipende da TABLE_C, che dipende da TABLE_B, che dipende da TABLE_A:

Se si verifica un errore in TABLE_B, a TABLE_B si applicano tutti i comportamenti standard (non a cascata): se viene eseguita una query su TABLE_B, Looker tenta prima di utilizzare la cache per restituire i risultati, poi tenta di utilizzare una versione precedente della tabella, se possibile, poi tenta di ricostruire la tabella e infine restituisce un errore se non riesce a ricostruire TABLE_B. Looker tenterà di nuovo di ricostruire TABLE_B alla successiva query sulla tabella o quando la strategia di persistenza della tabella attiverà una nuova ricostruzione.

Lo stesso vale 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 (l'operazione non andrà a buon fine se TABLE_B non è stato corretto).
• Se non è possibile ricostruire TABLE_B, non è possibile ricostruire TABLE_C, pertanto 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 essere ricostruite in base alle relative strategie di persistenza o alla successiva query (inclusa la successiva ricostruzione di una PDT dipendente). 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 in questa pagina. In alternativa, puoi utilizzare un'esplorazione per eseguire una query su TABLE_D e poi ricreare manualmente le PDT per la query, il che comporterà la forzata ricostruzione di tutte le PDT che risalgono la gerarchia delle dipendenze.

Migliorare le prestazioni del PDT

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

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

Aggiunta di filtri per limitare il set di dati

Con set di dati particolarmente grandi, la presenza di molte righe rallenta le query su una tabella derivata permanente (PDT). Se di solito esegui query solo sui dati recenti, ti consigliamo di aggiungere un filtro alla clausola WHERE del tuo set di dati di analisi predittiva 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 query rapide sui dati recenti e la possibilità di eseguire query sui dati precedenti.

Utilizzo di indexes o sortkeys e distribution

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

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 nello stesso nodo, quindi l'I/O tra i nodi viene ridotta al minimo.
• 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 nel 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 del file PDT vengono utilizzate per ordinare i dati sul disco per 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. Su Redshift, gli indici vengono utilizzati per generare chiavi di ordinamento interlacciate.