Tabelle derivate in Looker

In Looker, una tabella derivata è una query i cui risultati vengono utilizzati come se fosse una tabella reale 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 il momento in cui ciascun cliente ha effettuato il primo ordine. Utilizzando una tabella nativa derivata o una tabella derivata basata su SQL, puoi creare una nuova tabella di database denominata customer_order_summary che includa queste metriche.

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

Tabelle derivate native e tabelle derivate basate su SQL

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

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

Versione tabella nativa derivata 
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 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 chiamata customer_order_summary basata sulla tabella orders, con le colonne customer_id, first_order, e total_amount.

Ad eccezione del parametro derived_table e dei relativi sottoparametri, questa vista customer_order_summary funziona come qualsiasi altro file di visualizzazione. Indipendentemente dal fatto che tu definisca 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 tuo database.

Tabelle derivate native

Le tabelle native derivate si basano su query che definisci utilizzando i termini LookML. Per creare una tabella nativa derivata, devi utilizzare il parametro explore_source all'interno del parametro derived_table di un parametro view. Per creare le colonne della tabella nativa derivata, fai riferimento alle dimensioni o alle misure LookML nel modello. Visualizza il file nativo della visualizzazione tabella derivata nell'esempio precedente.

Rispetto alle tabelle derivate basate su SQL, le tabelle native derivate sono molto più facili da leggere e comprendere quando modella i tuoi dati.

Per informazioni dettagliate sulla creazione di tabelle derivate native, consulta la pagina di documentazione relativa alla creazione di tabelle native derivate.

Tabelle derivate basate su SQL

Per creare una tabella derivata da SQL, definisci una query in termini SQL, creando colonne nella tabella utilizzando una query SQL. Non puoi fare riferimento alle dimensioni e alle misure LookML in una tabella derivata basata su SQL. Vedi il file di visualizzazione della tabella basata su SQL nell'esempio precedente.

Più comunemente, le query SQL vengono definite 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 la definizione di una query SQL per le tabelle derivate persistenti (PDT):

  • create_process: quando utilizzi il parametro sql per una PDT, in background Looker esegue l'avvolgimento dell'istruzione CREATE TABLE DDL (Data Definition Language) del dialetto intorno alla query per creare la PDT dalla 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 la tecnologia DDL (ad esempio, BigQuery ML di Google per la previsione), puoi utilizzare il parametro sql_create per creare una PDT anziché utilizzare il parametro sql. Per informazioni ed esempi, consulta la pagina della documentazione relativa a sql_create.

Indipendentemente dal fatto che tu stia utilizzando il parametro sql, create_process o sql_create, in tutti questi casi stai definendo la tabella derivata con una query SQL, quindi tutte sono considerate tabelle derivate basate su SQL.

Quando definisci una tabella basata su SQL, assicurati di assegnare a ogni colonna un alias utilizzando AS. Il motivo è che dovrai 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)).

Tabelle derivate temporanee (PDT)

Oltre alla distinzione tra tabelle native derivate e tabelle basate su SQL, esiste anche una distinzione tra una tabella derivata temporanea (non scritta nel database) e una tabella derivata permanente o PDT (scritta in uno schema temporaneo sul tuo database).

Le tabelle native derivate 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 Explore che coinvolge una o più tabelle derivate, Looker crea una query SQL utilizzando una combinazione specifica di dialetto di SQL per le tabelle derivate oltre ai campi richiesti, alle unioni e ai 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 ulteriori informazioni sulla memorizzazione nella cache delle query in Looker, consulta la pagina della documentazione dedicata a memorizzazione nella cache delle query e ricreazione delle PDT con i gruppi di dati.

In caso contrario, se Looker non può utilizzare i risultati memorizzati nella cache, Looker deve eseguire una nuova query sul tuo database ogni volta che un utente richiede dati da una tabella derivata temporaneamente. Per questo motivo, devi assicurarti che le tue tabelle derivate temporanee abbiano un buon rendimento e non sovraccarichino il database. Nei casi in cui la query richiederà del tempo, una PDT è spesso un'opzione migliore.

Dialetti di database supportati per le tabelle derivate temporanee

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

Tabelle derivate permanenti (PDT)

Una tabella derivata permanente (PDT) è una tabella derivata che viene 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 le PDT nel tuo progetto Looker, devi disporre di:

  • Un dialetto del database che supporta le PDT. Consulta la sezione Dialetti di database supportati per le PDT più avanti in questa pagina per l'elenco dei dialetti che supportano le tabelle derivate permanenti e le tabelle native persistenti.
  • Uno schema temporaneo sul tuo database. Può essere uno schema qualsiasi nel 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 l'autorizzazione di scrittura per l'utente del database Looker.
  • Una connessione Looker configurata con l'opzione Persistent Derived Tables (Tabelle derivate permanenti) attiva. L'impostazione è solitamente configurata durante la configurazione iniziale della connessione di Looker (vedi la pagina della documentazione relativa ai dialetti di Looker per le istruzioni relative al dialetto del database), ma puoi anche attivare le PDT per la connessione dopo la configurazione iniziale.

Dialetti supportati per i database per le PDT

Affinché Looker supporti le PDT, anche il tuo dialetto del database deve supportarle.

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

La tabella seguente mostra i dialetti che supportano le tabelle derivate basate su SQL persistenti nella versione più recente di Looker:

Per supportare le tabelle native permanenti 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 native native (basate su LookML) nell'ultima release di Looker:

Creazione incrementale delle PDT

Puoi creare PDT incrementali nel tuo progetto se il dialetto le supporta. Una PDT incrementale è una tabella derivata permanente (PDT) che Looker crea aggiungendo dati aggiornati alla tabella invece di ricrearla nella sua interezza. 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, devono essere supportati anche il dialetto del tuo database. La tabella seguente mostra quali dialetti supportano le PDT incrementali nell'ultima release di Looker:

Creazione di tabelle derivate permanenti (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 tuo database utilizzando le viste materializzate.

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

Con le strategie di persistenza basate sul trigger (datagroup_trigger, sql_trigger e interval_trigger), Looker mantiene la PDT nel database finché quest'ultima non viene attivata per la ricostruzione. Quando si attiva la PDT, Looker ricostruisce la PDT per sostituire la versione precedente. Ciò significa che, con le PDT basate su trigger, i tuoi utenti non devono attendere la creazione di PDT per ricevere risposte alle query di Explore dalla PDT.

datagroup_trigger

I gruppi di dati sono il metodo più flessibile per creare persistenza. Se hai definito un datagroup per i tuoi criteri di memorizzazione nella cache, puoi utilizzare il parametro datagroup_trigger per avviare la ricostruzione della PDT nella stessa pianificazione dei criteri di memorizzazione nella cache.

Looker mantiene la PDT nel database finché 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 generazione della PDT. Se un utente richiede dati dalla PDT durante la sua creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dalla PDT esistente fino a quando non viene creata la nuova PDT. Per una panoramica dei gruppi di dati, consulta la pagina Documentazione sulla memorizzazione nella cache e ricostruzione delle PDT con gruppi di dati.

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

sql_trigger_value

Il parametro sql_trigger_value attiva la rigenerazione di una PDT basata su un'istruzione SQL da te fornita. Se il risultato dell'istruzione SQL è diverso dal valore precedente, la PDT viene rigenerata. In caso contrario, le PDT esistenti vengono mantenute nel database. Ciò significa che, nella maggior parte dei casi, gli utenti non dovranno attendere la generazione della PDT. Se un utente richiede dati dalla PDT mentre è in fase di creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dalla PDT esistente finché non viene creata la nuova PDT.

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

interval_trigger

Il parametro interval_trigger attiva la rigenerazione di una PDT in base a un intervallo di tempo da te specificato, ad esempio "24 hours" o "60 minutes". Analogamente al parametro sql_trigger, significa che in genere la PDT è predefinita quando gli utenti eseguono una query. Se un utente richiede dati dalla PDT mentre è in fase di creazione e i risultati della query non sono presenti nella cache, Looker restituirà i dati dalla PDT esistente finché non viene creata la nuova PDT.

persist_for

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

Una PDT persist_for viene creata quando un utente esegue per la prima volta una query su di essa. Looker manterrà 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 il tempo indicato in persist_for, Looker utilizza i risultati memorizzati nella cache, se possibile, o esegue la query sulla PDT.

Dopo persist_for volta, Looker cancella la PDT dal tuo database e la PDT viene ricreata alla successiva esecuzione di una query da parte di un utente, il che significa che la query deve 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 PDT. Quando una tabella persist_for fa parte di una cascata di dipendenze con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), il rigeneratore monitora e ricostruisce la tabella persist_for per ricostruire le altre tabelle. Vedi la sezione In che modo Looker crea tabelle derivate a cascata in questa pagina.

materialized_view: yes

Le viste materializzate ti consentono di utilizzare la funzionalità del tuo database per rendere persistenti le tabelle derivate nel tuo progetto Looker. Se il dialetto del tuo database supporta le viste materializzate e la tua connessione Looker è configurata con l'opzione Persistent Derived Tables (Tabelle derivate permanenti), puoi creare una vista materializzata specificando materialized_view: yes per una tabella derivata. Le viste materializzate sono supportate sia per le tabelle derivate native che per le tabelle derivate basate su SQL.

Analogamente a una tabella derivata permanente (PDT), una visualizzazione materializzata è un risultato della query che viene archiviato come tabella nello schema temporaneo del database. La differenza principale tra una PDT e una visualizzazione materializzata consiste nel modo in cui le tabelle vengono aggiornate:

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

Per questo motivo, la funzionalità di visualizzazione materializzata richiede una conoscenza avanzata del dialetto e delle sue caratteristiche. Nella maggior parte dei casi, il database aggiorna la vista materializzata ogni volta che rileva nuovi dati nelle tabelle oggetto della query. 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 informazioni sull'assistenza per il dialetto e sui requisiti e alcune considerazioni importanti.

Strategie di ottimizzazione

Le PDT sono archiviate nel tuo database, pertanto devi ottimizzarle utilizzando le strategie seguenti, supportate dal tuo dialetto:

Ad esempio, per aggiungere 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 che su first_order in questo modo:

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

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

Casi d'uso delle PDT

Le PDT sono utili perché, quando un utente richiede dati da una tabella, spesso questa è già stata creata, riducendo il tempo della query e il carico del database.

Come best practice generale, gli sviluppatori dovrebbero provare a modellare i dati senza utilizzare le PDT, finché non sono assolutamente necessarie.

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 di query e il carico del database per le query eseguite di frequente, esistono diversi altri casi d'uso per le PDT, tra cui:

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 le PDT per testare le ottimizzazioni

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

Considera un caso in cui disponi di una tabella ma vuoi testare indici diversi. Il LookML iniziale della vista potrebbe avere il seguente aspetto:

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

Per testare le strategie di ottimizzazione, puoi utilizzare il parametro indexes per aggiungere indici al LookML nel seguente 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. Quindi esegui le query di test e confronta i risultati. Se i risultati sono favorevoli, puoi chiedere al tuo team DBA o ETL di aggiungere gli indici alla tabella originale.

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

Utilizzare le PDT per pre-aggregare o aggregare i dati

Può essere utile pre-aggregare o preaggregare 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 in base alla coorte basata su quando hanno effettuato il primo ordine. Questa query potrebbe essere costosa da eseguire più volte ogni volta che i dati sono necessari in tempo reale; tuttavia, puoi calcolare la query solo una volta per 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]
  }
}

Tabelle derivate a cascata

È possibile fare riferimento a una tabella derivata nella definizione di un'altra, creando una catena di tabelle derivate a cascata o PDT a cascata, a seconda dei casi. Un esempio di cascata delle tabelle derivate sarebbe 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.

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.

Nell'esempio successivo, la PDT clean_events viene creata dalla tabella events nel database. La PDT clean_events tralascia le righe indesiderate dalla tabella di database events. Viene visualizzata una seconda PDT (event_summary PDT), una sintesi 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 clean_events sono a cascata, in cui event_summary dipende da clean_events (poiché event_summary viene definito utilizzando la PDT clean_events). Questo esempio particolare potrebbe essere fatto 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 ti riferisci 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 questa operazione:

${clean_events.SQL_TABLE_NAME} AS clean_events

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

In che modo Looker crea tabelle derivate a cascata

Se hai un TABLE_D la cui definizione contiene un riferimento a TABLE_C, TABLE_D dipende dipende da TABLE_C. Ciò significa che se esegui una query su TABLE_D e questa non è presente nella cache di Looker, Looker verrà ricreato TABLE_D. Prima di tutto, deve ricreare TABLE_C.

Ora prendiamo in uno scenario di cascata le tabelle derivate 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. Quindi 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. Dal momento che TABLE_D non è necessario per rispondere a questa query, Looker al momento non ricostruisce TABLE_D.

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

Per le PDT viene applicata la stessa logica di base: Looker creerà una tabella necessaria per rispondere a una query, arrivando fino alla catena delle dipendenze. Tuttavia, con le PDT, spesso capita che le tabelle esistano già e non debbano essere ricostruite. Con le query utente standard sulle cascate PDT, Looker ricostruisce le PDT a cascata solo se non esiste una versione valida delle PDT nel database. Se vuoi forzare una ricreazione 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 dipende essenzialmente dalla query 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 le esegue una query, rimangono nel database finché l'intervallo persist_for non aumenta e poi non vengono ricreate finché non viene interrogato da un utente. Tuttavia, se una PDT persist_for fa parte di una cascata con PDT basate su trigger (PDT che utilizzano la strategia di persistenza datagroup_trigger, interval_trigger o sql_trigger_value), viene praticamente interrogata ogni volta che le PDT dipendenti vengono ricostruite. In questo caso, la PDT persist_for verrà ricreata in base alla pianificazione delle PDT dipendenti. Ciò significa che le PDT di persist_for possono essere interessate dalla strategia di persistenza dei dipendenti.

Ricreazione manuale di tabelle permanenti per una query

Gli utenti possono selezionare l'opzione Rebuild Derived Tables & Run (Ricostruisci tabelle derivate ed eseguire) da un menu di Explore (Esplora) per eseguire l'override delle impostazioni di persistenza e ricreare tutte le PDT e le tabelle aggregate necessarie per la query corrente in Explore (Esplora):

Se fai clic sul pulsante Esplora azioni si apre il menu Esplora, da cui puoi selezionare Ricostruisci tabelle derivate e amp.

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

L'opzione Rebuild Derived Tables & Run (Ricostruisci tabelle derivate ed esegui) ricostruisce tutte le tabelle permanenti (tutte le PDT e le tabelle aggregate) necessarie per rispondere alla query, indipendentemente dalla strategia di persistenza. Questo include tutte le tabelle e le PDT aggregate nella query corrente e include anche le tabelle e le PDT aggregate a cui viene fatto riferimento nelle tabelle e nelle PDT aggregate nella query corrente.

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

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

Se la tabella_c dipende dalla tabella_b e la tabella_b dipende dalla tabella_a, la ricostruzione della tabella_c prevede di ricreare la tabella_a, quindi la tabella_b e infine la tabella_c.

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

  • Per l'utente che avvia l'operazione Ricostruisci tabelle derivate ed esegui, la query attende la ricostruzione delle tabelle prima di caricare i risultati. Le query di altri utenti continueranno a utilizzare le tabelle esistenti. Una volta che le tabelle permanenti vengono ricostruite, tutti gli utenti utilizzeranno quelle ricostruite. Sebbene questo processo sia progettato per evitare di interrompere le query di altri utenti durante la ricostruzione delle tabelle, questi utenti potrebbero comunque essere interessati dal carico aggiuntivo sul database. Se ti trovi in una situazione in cui l'attivazione di una ricostruzione durante l'orario di lavoro potrebbe compromettere il tuo database, potresti dover comunicare agli utenti che non devono mai ricreare determinate PDT o tabelle aggregate durante tali orari.

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

  • 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 l'articolo del Centro assistenza Timeout di query e coda.

Tabelle persistenti in modalità sviluppatore

Looker ha alcuni comportamenti speciali per gestire le tabelle persistenti in modalità di sviluppo.

Se esegui una query su una tabella permanente in modalità sviluppatore senza apportare modifiche alla definizione, Looker esegue una query sulla versione di produzione della tabella. Se apporti una modifica alla definizione della tabella che influisce sui dati contenuti nella tabella o nel modo in cui viene eseguita una query sulla tabella, ne verrà creata una nuova versione la prossima volta che eseguirai una query in modalità di sviluppo. Una tabella di sviluppo di questo tipo consente di testare le modifiche senza disturbare gli utenti finali.

Che cosa suggerisce a Looker di creare una tabella di sviluppo

Quando possibile, Looker utilizza la tabella di produzione esistente per rispondere alle query, indipendentemente dalla tua modalità di sviluppo. Tuttavia, in alcuni casi Looker non può utilizzare la tabella di produzione per le query in modalità Development (Sviluppo).

Looker creerà una tabella di sviluppo se sei in modalità Development (Sviluppo) ed esegui una query su una tabella derivata su SQL che viene definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev.

Per le tabelle persistenti che non hanno un parametro per limitare 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 in seguito esegui una query sulla tabella in modalità di sviluppo. Questo vale per tutte le modifiche alla tabella che interessano i dati al suo interno o per il modo in cui vengono cercate le tabelle.

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 successivamente eseguirai una query sulla tabella dopo aver apportato queste modifiche):

Per le modifiche che non modificano i dati della tabella o che 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à Development (Sviluppo), se modifichi solo l'impostazione publish_as_db_view per una tabella derivata, Looker non deve ricreare la tabella derivata, quindi non creerà una tabella di sviluppo.

Per quanto tempo Looker continua a utilizzare le tabelle di sviluppo

Indipendentemente dalla strategia di persistenza effettiva della tabella, Looker tratta le tabelle permanenti di sviluppo come se avessero una strategia di persistenza di persist_for: "24 hours". Looker esegue questa operazione per garantire che le tabelle di sviluppo non vengano mantenute per più di un giorno, perché 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 occupino dati nel database, Looker applica la strategia persist_for: "24 hours" per assicurarsi che le tabelle vengano eliminate di frequente dal database.

Altrimenti, Looker crea PDT e aggrega tabelle in modalità Sviluppo allo stesso modo in cui crea tabelle persistenti in modalità Produzione.

Se una tabella di sviluppo è presente in modo permanente nel tuo database quando esegui il deployment di modifiche a una PDT o a una tabella aggregata, spesso Looker può utilizzarla come tabella di produzione, in modo che i tuoi utenti non debbano attendere che venga creata quando eseguono una query sulla tabella.

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

  • Se sono trascorse più di 24 ore da quando hai eseguito la query sulla tabella in modalità sviluppo, la versione di sviluppo della tabella è contrassegnata come scaduta e non può essere utilizzata per le query. Puoi controllare le PDT non create utilizzando l'IDE di Looker oppure utilizzando la scheda Development (Sviluppo) della pagina Persistent Derived Tables (Tabelle derivate permanenti). Se hai PDT non create, puoi interrogarle in modalità Development (Sviluppo) prima di apportare le 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 condizione WHERE condizionale che utilizza le istruzioni if prod e if dev (per 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 e quindi eseguire una query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che può essere utilizzata per la produzione quando esegui il deployment delle modifiche.

Altrimenti, se esegui il deployment delle modifiche quando non esiste una tabella di sviluppo valida che possa essere utilizzata come tabella di produzione, Looker ricrea la tabella la prossima volta che viene eseguita una query sulla tabella in modalità Production (per tabelle persistenti che utilizzano la strategia persist_for) o la volta successiva che viene eseguito il regenerator (per tabelle persistenti che utilizzano datagroup_trigger, interval_trigger o sql_trigger_value).

Controllo delle PDT non create in modalità sviluppo

Se una tabella di sviluppo è presente in modo permanente nel tuo database quando esegui il deployment di modifiche a una PDT o a una tabella aggregata, spesso Looker può utilizzarla come tabella di produzione, in modo che i tuoi utenti non debbano attendere che venga creata quando eseguono una query sulla tabella. Per maggiori dettagli, vedi le sezioni Durata della configurazione delle tabelle di sviluppo e Che cosa richiede a Looker di creare una tabella di sviluppo in questa pagina.

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

Puoi controllare le PDT non create nel progetto nel riquadro Stato del progetto. Fai clic sull'icona Project Health nell'IDE di Looker per aprire il riquadro Project Health. Quindi, fai clic sul pulsante Convalida stato PDT.

Se sono presenti PDT non create, nel riquadro Stato del progetto saranno elencate le seguenti informazioni:

Il riquadro integrità del progetto mostra un elenco di PDT non create per il progetto e un pulsante Vai a Gestione PDT.

Se disponi dell'autorizzazione see_pdts, puoi fare clic sul pulsante Vai a Gestione PDT. Looker aprirà la scheda Development (Sviluppo) della pagina Persistent Derived Tables (Tabelle derivate permanenti) e filtra i risultati in base al progetto LookML specifico. Da qui puoi vedere quali PDT di sviluppo sono create e non create e accedere ad altre informazioni per la risoluzione dei problemi. Per ulteriori informazioni, consulta la pagina della documentazione Impostazioni amministratore - Tabelle derivate permanenti.

Dopo aver identificato una PDT non creata nel tuo progetto, puoi creare una versione di sviluppo aprendo un'esplorazione che esegue query sulla tabella, quindi utilizzando l'opzione Rebuild Derived Tables & Run (Crea build di tabelle derivate ed esegui). Consulta la sezione Ricreazione manuale di tabelle permanenti per una query in questa pagina.

Condivisione e pulizia delle tabelle

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

Questo processo presenta numerosi vantaggi:

  • Se non hai apportato alcuna modifica a una tabella in modalità Sviluppo, le query utilizzeranno le tabelle di produzione esistenti. Questo si verifica se la tabella non è una tabella derivata su SQL che viene definita utilizzando una clausola WHERE condizionale con istruzioni if prod e if dev. Se la tabella è definita con una clausola WHERE condizionale, Looker creerà una tabella di sviluppo se esegui una query sulla tabella in modalità Development (Sviluppo). Per le tabelle derivate native con il parametro dev_filters, Looker ha la logica di utilizzare la tabella di produzione per rispondere alle query in modalità Development (Sviluppo), a meno che non modifichi la definizione della tabella e quindi esegui una query sulla tabella in modalità Development (Sviluppo).
  • Se due sviluppatori apportano la stessa modifica a una tabella in modalità di sviluppo, condividono la stessa tabella di sviluppo.
  • Dopo aver eseguito il push delle modifiche dalla modalità di sviluppo alla modalità di produzione, la definizione di produzione precedente non esiste più, pertanto la tabella di produzione precedente è contrassegnata come scaduta e verrà eliminata.
  • Se decidi di annullare le modifiche apportate alla modalità di sviluppo, la definizione della tabella non esiste più, pertanto le tabelle di sviluppo non necessarie sono contrassegnate come scadute e verranno eliminate.

Lavorare più velocemente in modalità sviluppo

In alcuni casi, la PDT che stai creando richiede molto tempo, il che può richiedere molto tempo se provi molte modifiche in modalità Sviluppo. In questi casi, puoi chiedere a Looker di creare versioni più piccole di una tabella derivata quando sei in modalità Development (Sviluppo).

Per le tabelle derivate native, puoi utilizzare il sottoparametro dev_filters di explore_source per specificare filtri applicati solo alle versioni di sviluppo della tabella derivata:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa../_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

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

Il parametro dev_filters agisce insieme al parametro filters in modo che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se dev_filters e filters specificano i filtri per la stessa colonna, dev_filters ha la precedenza per la versione di sviluppo della tabella. In questo esempio, la versione di sviluppo della tabella filtrerà i dati per gli 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 dal 2000 in poi nella modalità di produzione, ma solo quelli dal 2020 in poi nella modalità di sviluppo. L'utilizzo di questa funzionalità in modo strategico per limitare il set di risultati e aumentare la velocità delle query può rendere molto più semplice convalidare le modifiche apportate alla modalità di sviluppo.

Come Looker crea PDT

Dopo che una PDT è stata definita e viene eseguita per la prima volta oppure viene attivata dal regenerator per la ricostruzione in base alla strategia di persistenza, Looker esegue i passaggi seguenti:

  1. Utilizza la SQL derivata per modellare un'istruzione CREATE TABLE AS SELECT (o CTAS) ed eseguirla. Ad esempio, per ricostruire una PDT denominata customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
  2. Utilizza le istruzioni per creare gli indici al momento della creazione della tabella
  3. Rinomina la tabella da LC$.. ("Looker Create") a LR$.. ("Looker Read"), per indicare che la tabella è pronta per essere utilizzata
  4. Elimina qualsiasi versione precedente della tabella che non deve più essere utilizzata

Esistono alcune implicazioni importanti:

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

Il rigeneratore Looker

Il rigeneratore Looker controlla lo stato e avvia la ricostruzione per le tabelle con trigger. Una tabella persistente del trigger è una PDT 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 una ricostruzione della tabella quando il risultato dell'ultimo controllo query trigger è diverso dal risultato del precedente controllo query query. Ad esempio, se la tabella derivata viene mantenuta con la query SQL SELECT CURDATE(), il rigeneratore Looker ricostruisce la tabella la prossima volta che il rigeneratore controlla l'attivatore dopo la modifica della data. Per impostazione predefinita, i controlli del rigeneratore di Looker attivano le query ogni cinque minuti per verificare se la tabella persistente viene attivata e deve essere ricostruita. Tuttavia, altri fattori possono influire sul tempo necessario per ricreare le tabelle, come descritto nella sezione Considerazioni importanti per l'implementazione delle tabelle persistenti in questa pagina.
  • 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 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 l'attivatore può essere una durata specificata nel parametro interval_trigger del gruppo di dati.

Il rigeneratore Looker avvia anche le ricostruimenti per le tabelle persistenti che utilizzano il parametro persist_for, ma solo quando la tabella persist_for è una cascata di dipendenze di una tabella basata su trigger. In questo caso, il rigeneratore Looker avvia la ricostruzione di una tabella persist_for, poiché è necessaria per la ricostruzione delle altre tabelle nella cascata. In caso contrario, il rigeneratore non monitora le tabelle persistenti che utilizzano la strategia persist_for.

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

  • Se l'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) è attivata per la connessione al database, il rigeneratore Looker tenta di ricostruire la tabella durante il ciclo successivo del rigeneratore, anche se la condizione di trigger della tabella non è soddisfatta.
  • Se l'impostazione Always Retry Failed PDT Builds (Ritenta sempre le ricostruzioni PDT non riuscite) è disabilitata, il rigeneratore Looker non tenterà di ricostruire la tabella fino a quando la condizione di trigger di PDT non sarà soddisfatta.

Se un utente richiede dati dalla tabella persistente mentre è in fase di creazione e i risultati della query non sono presenti 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, se la nuova tabella utilizza una connessione al 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 di quella esistente fino alla creazione di quella nuova. Altrimenti, se la tabella esistente non è valida, Looker fornirà i risultati della query una volta ricreata la nuova tabella.

Considerazioni importanti per l'implementazione delle tabelle persistenti

Considerando l'utilità delle tabelle persistenti (PDT e tabelle aggregate), è facile accumulare molte di queste sulla tua istanza di Looker. È possibile creare uno scenario in cui il rigeneratore Looker deve creare più tabelle contemporaneamente. In particolare con le tabelle a cascata, o le tabelle a lunga esecuzione, puoi creare uno scenario in cui le tabelle hanno un ritardo elevato prima della ricreazione o in cui gli utenti subiscono un ritardo nel recupero dei risultati di query da una tabella mentre il database si sta impegnando per generarla.

Per impostazione predefinita, il rigeneratore di Looker controlla gli attivatori PDT ogni cinque minuti per vedere se deve ricreare le tabelle che supportano il trigger (PDT e tabelle aggregate che utilizzano le strategie di persistenza datagroup_trigger, interval_trigger o sql_trigger_value).

Tuttavia, altri fattori possono influire sul tempo necessario per ricreare le tabelle:

  • L'amministratore di Looker potrebbe aver modificato l'intervallo dei controlli del trigger del rigeneratore utilizzando l'impostazione PDT and Datagroup Manutenzione Schedule (Pianificazione manutenzione PDT) sulla connessione al tuo database.
  • Per impostazione predefinita, il rigeneratore può avviare la ricostruzione di una PDT o di una tabella aggregata alla volta su una connessione. Un amministratore di Looker può regolare il numero consentito di ricostruzioni simultanee del rigeneratore utilizzando il campo Max PDT Builder Connections (Numero massimo di connessioni a generatore PDT), nelle impostazioni di una connessione.
  • Tutte le PDT e le tabelle aggregate attivate dalla stessa datagroup verranno ricostruite durante lo stesso processo di rigenerazione. Questo può richiedere un carico elevato se hai molte tabelle che utilizzano il gruppo di dati, direttamente o a causa delle dipendenze a cascata.

Oltre alle considerazioni precedenti, esistono anche alcuni casi in cui dovresti evitare di aggiungere la persistenza a una tabella derivata:

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

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

Gestione delle PDT su larga scala con l'API

Il monitoraggio e la gestione delle PDT che si aggiornano con orari diversi sono sempre più complesse man mano che crei più PDT sulla tua istanza. Valuta la possibilità di utilizzare l'integrazione di Apache Airflow di Looker per gestire le tue pianificazioni PDT insieme agli altri processi ETL ed ELT.

Monitoraggio e risoluzione dei problemi relativi alle PDT

Se utilizzi le PDT, in particolare cascate, è utile controllare lo stato di queste PDT. Puoi utilizzare la pagina per l'amministratore di Persistent Derived Tables di Looker per visualizzare lo stato delle tue PDT. Per informazioni, consulta la pagina della documentazione Impostazioni amministratore - Tabelle derivate permanenti.

Quando si tenta di risolvere i problemi relativi alle PDT:

  • Presta particolare attenzione alla differenza tra le tabelle di sviluppo e le tabelle di produzione quando si analizza il log eventi PDT.
  • Verifica che non siano state apportate modifiche allo schema temporaneo in cui Looker archivia le tabelle derivate permanenti. Se sono state apportate modifiche, potresti dover aggiornare le impostazioni di Connection nella sezione Admin (Amministrazione) di Looker e quindi riavviare Looker per ripristinare la normale funzionalità PDT.
  • Determina se ci sono problemi con tutte le PDT o solo con una. Se c'è un problema, è probabile che sia dovuto a un errore LookML o SQL.
  • Determina se i problemi con la PDT corrispondono ai momenti in cui è prevista la ricostruzione.
  • Assicurati che tutte le query di sql_trigger_value vengano valutate correttamente e restituiscano una sola riga e colonna. Per le PDT basate su SQL, puoi farlo eseguendole in SQL Runner. L'applicazione di un LIMIT protegge da query fuoristrada. Per ulteriori informazioni sull'utilizzo di SQL Runner per il debug delle tabelle derivate, consulta questo argomento della community.
  • Per le PDT basate su SQL, utilizza SQL Runner per verificare che quest'ultimo venga eseguito senza errori. Assicurati di applicare un attributo LIMIT in SQL Runner per mantenere ragionevoli i tempi di query.
  • Per le tabelle derivate basate su SQL, evita di utilizzare espressioni tabella comuni (CTE). L'utilizzo di CTE con DT crea istruzioni WITH nidificate che possono causare un errore nelle PDT senza avviso. Utilizza invece l'SQL per la DT per creare un DT secondario e fare riferimento a DT dal primo DT utilizzando la sintassi ${derived_table_or_view_name.SQL_TABLE_NAME}.
  • Controlla che eventuali tabelle da cui dipende il problema PDT (indipendentemente dal fatto che siano tabelle normali o PDT) esistono e possono essere oggetto di query.
  • Assicurati che le tabelle da cui dipende la PDT del problema non abbiano blocchi condivisi o esclusivi. Affinché Looker possa creare correttamente una PDT, deve acquisire un blocco esclusivo nella tabella da aggiornare. In conflitto con altri blocchi condivisi o esclusivi attualmente presenti nella tabella. Looker non potrà aggiornare la PDT finché tutti gli altri blocchi non sono stati cancellati. Lo stesso vale per i blocchi esclusivi sul tavolo da cui Looker sta creando una PDT. Se è presente un blocco esclusivo in un tavolo, Looker non può acquisire un blocco condiviso per eseguire query finché il blocco esclusivo non viene cancellato.
  • Utilizza il pulsante Mostra processi in SQL Runner. Se sono presenti molti processi attivi, ciò potrebbe rallentare i tempi di query.
  • Monitora i commenti nella query. Consulta la sezione Commenti alle query per le PDT in questa pagina.

Commenti query per PDT

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

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

Il commento alla generazione delle PDT verrà visualizzato nella scheda SQL di Explore (Esplora) se Looker ha dovuto generare una PDT per la query Explore (Esplora). Il commento verrà visualizzato nella parte superiore dell'istruzione SQL.

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

Ricostruzione delle PDT dopo un errore

In caso di errore in una PDT, ecco cosa succede quando viene eseguita una query sulla PDT:

  • Looker utilizzerà i risultati nella cache se la stessa query è stata eseguita in precedenza. Per informazioni su come funziona, consulta la pagina della documentazione dedicata a memorizzazione nella cache delle query e nella loro creazione di PDT con i gruppi di dati.
  • Se i risultati non vengono memorizzati nella cache, Looker estrarrà i risultati dalla PDT nel database, se ne esiste una versione valida.
  • Se nel database non è presente una PDT valida, Looker tenta di ricostruire la PDT.
  • Se non è possibile ricreare la PDT, Looker restituirà un errore per una query. Il rigeneratore Looker proverà a ricostruire la PDT la prossima volta che la query viene eseguita o la volta successiva che la strategia di persistenza della PDT ne attiva una.

Per le PDT a cascata viene applicata la stessa logica, tranne che per le PDT a cascata:

  • La mancata creazione di una tabella impedisce la generazione delle PDT in tutta la catena delle dipendenze.
  • Una PDT dipendente è essenzialmente una query sulle PDT su cui si basa, quindi la strategia di persistenza di una tabella può attivare le ricostruzioni delle PDT in alto nella catena.

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

In caso di errore di TABLE_B, viene applicato tutto il comportamento standard (non a cascata) per TABLE_B: se viene eseguita una query su TABLE_B, Looker prova prima a utilizzare la cache per restituire i risultati, poi tenta di utilizzare una versione precedente della tabella se possibile, quindi tenta di ricostruire la tabella; infine, restituirà un errore se TABLE_B non può ricostruire. Looker proverà di nuovo a ricostruire TABLE_B quando alla tabella verrà eseguita una query successiva o quando la strategia di persistenza della tabella attiverà una ricostruzione.

Lo stesso vale anche per le dipendenze di TABLE_B. Pertanto, se non è possibile creare TABLE_B e c'è una query su TABLE_C:

  • Looker proverà a utilizzare la cache per la query su TABLE_C.
  • Se i risultati non vengono memorizzati nella cache, Looker tenterà di estrarre i risultati 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 (che avrà esito negativo se TABLE_B non è stato corretto).
  • Se TABLE_B non può essere ricostruito, TABLE_C non può ricostruire, quindi Looker restituirà un errore per la query il giorno TABLE_C.
  • Looker tenterà quindi di ricostruire TABLE_C in base alla sua consueta strategia di persistenza o alla successiva query sulla PDT (che include la successiva 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 ricostruire in base alle loro strategie di persistenza o alla successiva query (che include la prossima volta che una PDT dipendente tenta di ricostruire). In alternativa, se una versione di sviluppo delle PDT nella cascata è stata creata in modalità di sviluppo, le versioni di sviluppo possono essere utilizzate come nuove PDT di produzione. Per informazioni su come funziona, consulta la sezione Tabelle persistenti in modalità sviluppo di questa pagina. In alternativa, puoi utilizzare un'esplorazione per eseguire una query su TABLE_D e poi ricreare manualmente le PDT per la query, in modo da forzare una ricreazione di tutte le PDT a salire nella cascata delle dipendenze.

Migliorare le prestazioni delle PDT

Quando crei le PDT, le prestazioni possono essere fonte di preoccupazione. Soprattutto quando la tabella è molto grande, l'esecuzione di query sulla tabella potrebbe essere lenta, così come può essere per qualsiasi tabella di grandi dimensioni nel tuo database.

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

Aggiungere filtri per limitare il set di dati

Con set di dati particolarmente grandi, avere più righe rallenta le query su una PDT. Se di solito esegui query solo sui dati recenti, ti consigliamo di aggiungere un filtro alla clausola WHERE della PDT in modo da limitare la tabella a un massimo di 90 giorni di dati. In questo modo, ogni volta che viene ricreato, vengono aggiunti alla tabella solo i dati pertinenti, in modo che le query in esecuzione siano molto più veloci. Quindi, puoi creare una PDT più ampia e separata per l'analisi storica, in modo da consentire query rapide sui dati recenti e la possibilità di eseguire query sui dati precedenti.

In uso: indexes o sortkeys e distribution

Quando crei una PDT di grandi dimensioni, l'indicizzazione della tabella (per dialetti come MySQL o Postgres) o l'aggiunta di parole chiave e distribuzione (per Redshift) può essere utile per migliorare le prestazioni.

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

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

Le seguenti impostazioni controllano il modo in cui i dati nella 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 intorno a un cluster. Quando due tabelle vengono unite dalla colonna specificata nel parametro distribution, il database può trovare i dati di unione sullo stesso nodo, quindi l'I/O tra nodi è ridotto al minimo.
  • Per Redshift, imposta il parametro distribution_style su all per indicare al database di conservare una copia completa dei dati su ciascun nodo. Questo spesso viene utilizzato per ridurre al minimo l'I/O tra nodi quando vengono associate in modo relazionale tabelle 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 della PDT vengono utilizzate per ordinare i dati su disco per semplificare la ricerca. Su Redshift, puoi utilizzare sortkeys o indexes, ma non entrambi. Ad esempio:
* On most databases, use the [`indexes`](/reference/view-params/indexes) parameter. The values specify which columns of the PDT are indexed. (On Redshift, indexes are used to generate interleaved sort keys.)