gruppo di dati

Utilizzo

datagroup: datagroup_name {
max_cache_age: "24 ore"
sql_trigger: SELECT max(id) FROM my_tablename ;;
interval_trigger: "12 hours"
label: """
Gerarchia
datagroup
Valore predefinito
Nessuna

Accetta
Un identificatore del gruppo di dati, più i sottoparametri che definiscono le proprietà del gruppo.

Definizione

Utilizza datagroup per assegnare un criterio per la cache alle esplorazioni e/o alle tabelle derivate persistenti (PDT). Se vuoi criteri di memorizzazione nella cache diversi per esplorazioni e/o PDT diverse, utilizza un parametro datagroup separato per specificare ciascun criterio.

Puoi aggiungere un'etichetta e una descrizione per il gruppo di dati:

  • label: consente di specificare un'etichetta facoltativa per il gruppo di dati. Per i dettagli, consulta le sezioni label e description.
  • description: consente di specificare una descrizione facoltativa del gruppo di dati che può essere utilizzata per spiegare lo scopo e il meccanismo del gruppo di dati. Per i dettagli, consulta le sezioni label e description.

Specifica i dettagli del criterio di memorizzazione nella cache utilizzando i sottoparametri datagroup:

  • max_cache_age: specifica una stringa che definisce un periodo di tempo. Quando l'età della cache di una query supera il periodo di tempo, Looker invalida la cache. La volta successiva che la query viene eseguita, Looker la invia al database per ottenere nuovi risultati. Per i dettagli, consulta la sezione max_cache_age di questa pagina.
  • sql_trigger: specifica una query SQL che restituisce una riga con una colonna. Se il valore restituito dalla query è diverso dai risultati precedenti della query, lo stato del gruppo di dati risulta attivato. Per i dettagli, consulta la sezione sql_trigger di questa pagina.
  • interval_trigger: consente di specificare una pianificazione temporale per l'attivazione del gruppo di dati, ad esempio "24 hours". Per i dettagli, consulta la sezione interval_trigger di questa pagina.

Spesso la soluzione migliore è utilizzare max_cache_age in combinazione con sql_trigger o interval_trigger. Specifica un valore sql_trigger o interval_trigger corrispondente al carico dei dati (ETL) nel database, quindi specifica un valore max_cache_age che invalidi i vecchi dati se l'ETL non riesce. Il parametro max_cache_age garantisce che, se la cache di un gruppo di dati non viene cancellata da sql_trigger o interval_trigger, le voci della cache scadranno di un determinato tempo. In questo modo, la modalità di errore per un gruppo di dati consisterà nell'eseguire una query sul database anziché fornire dati non aggiornati dalla cache di Looker.

Un gruppo di dati non può avere entrambi i parametri sql_trigger e interval_trigger. Se definisci un gruppo di dati con entrambi i parametri, il gruppo di dati utilizzerà il valore interval_trigger e ignorerà il valore sql_trigger, poiché il parametro sql_trigger richiede l'utilizzo di risorse di database per l'esecuzione di query sul database.

Per le connessioni che utilizzano attributi utente per specificare i parametri di connessione, devi creare una connessione separata con i campi di override PDT per definire un criterio di memorizzazione nella cache del gruppo di dati utilizzando un trigger query SQL.

Senza le sostituzioni PDT, puoi comunque utilizzare un gruppo di dati per il modello e le relative esplorazioni, purché tu definisca i criteri di memorizzazione nella cache del gruppo di dati utilizzando solo max_cache_age, non sql_trigger.

max_cache_age

Il parametro max_cache_age specifica una stringa contenente un numero intero seguito da "seconds", "minutes" o "hours". Si tratta del periodo di tempo massimo durante il quale i risultati memorizzati nella cache possono essere utilizzati dalle query Esplora che utilizzano il gruppo di dati.

Quando l'età della cache di una query supera max_cache_age, Looker invalida la cache. La volta successiva che la query viene eseguita, Looker la invia al database per ottenere nuovi risultati. Quando l'età della cache di una query supera max_cache_age, Looker invalida la cache. La volta successiva che la query viene eseguita, Looker la invia al database per ottenere nuovi risultati. Per informazioni sulla durata della memorizzazione dei dati nella cache, consulta la pagina Documentazione relativa alla memorizzazione nella cache e alla ricostruzione delle PDT con i gruppi di dati.

Se la funzionalità Dashboard istantanee Looker Labs è abilitata, le query eseguite da una dashboard vengono sempre eseguite sul database. I dati delle esecuzioni precedenti vengono mostrati nella dashboard fino a quando non viene restituito il risultato della query, indipendentemente dal valore max_cache_age.

Il parametro max_cache_age definisce solo quando la cache non è valida; non attiva la ricostruzione delle PDT. Se definisci un gruppo di dati solo con max_cache_age, riceverai un avviso di convalida LookML se al gruppo di dati sono assegnate tabelle derivate. Se esci da una tabella derivata assegnata a un gruppo di dati con un solo parametro max_cache_age, viene creata quando viene eseguita una prima query, ma la tabella deriva viene inserita nello schema temporaneo a tempo indeterminato e non verrà mai ricreata, anche se viene nuovamente eseguita una query. Se intendi eseguire una ricostruzione delle PDT a un intervallo di tempo specifico, devi aggiungere un parametro interval_trigger al gruppo di dati per definire una pianificazione di ricostruzione delle PDT.

sql_trigger

Utilizza il parametro sql_trigger per specificare una query SQL che restituisce esattamente una riga con una colonna. Looker esegue la query SQL a intervalli specificati nel campo PDT and Datagroup Maintenance Schedule (Pianificazione manutenzione PDT) e gruppi di dati della connessione al database. Se la query restituisce un valore diverso rispetto al risultato precedente, lo stato del gruppo di dati risulta attivato. Una volta attivato il gruppo di dati, Looker ricrea tutte le PDT con il gruppo di dati specificato nel suo parametro datagroup_trigger. Una volta completata la ricreazione delle PDT, il gruppo di dati passa allo stato pronto e Looker invalida i risultati memorizzati nella cache di tutte le esplorazioni che lo utilizzano.

In genere, sql_trigger specifica una query SQL che indica quando si è verificato un nuovo carico di dati (ETL), ad esempio tramite query a max(ID) in una tabella. Puoi anche utilizzare sql_trigger per specificare una determinata ora del giorno, interrogando la data corrente e aggiungendo ulteriori ore al timestamp per raggiungere l'ora desiderata, ad esempio le 04:00.

Looker non esegue la conversione del fuso orario per sql_trigger. Se vuoi attivare il gruppo di dati a una determinata ora del giorno, imposta l'attivatore nel fuso orario per cui è configurato il database.

Consulta questi esempi del parametro sql_trigger per trovare idee per la configurazione di query SQL per attivare un gruppo di dati.

interval_trigger

Puoi utilizzare il sottoparametro facoltativo interval_trigger per specificare una durata per la ricostruzione. Nel parametro interval_trigger trasmetti una stringa contenente un numero intero seguito da "secondi", "minuti" o "ore".

label e description

Puoi utilizzare i sottoparametri label e description facoltativi per aggiungere un'etichetta personalizzata e una descrizione del gruppo di dati. Puoi anche localizzare questi sottoparametri utilizzando i file delle stringhe locali.

Questi sottoparametri vengono visualizzati nella pagina Datagroups della sezione Database del riquadro Admin. Per ulteriori informazioni sulla visualizzazione di queste impostazioni, consulta la pagina della documentazione Impostazioni amministratore - Gruppi di dati.

Esempi

I seguenti esempi evidenziano i casi d'uso di datagroup, tra cui:

Creazione di un criterio di memorizzazione nella cache per recuperare nuovi risultati ogni volta che sono disponibili nuovi dati o almeno ogni 24 ore.

Per creare un criterio di memorizzazione nella cache che recuperi i nuovi risultati ogni volta che sono disponibili nuovi dati o almeno ogni 24 ore, procedi nel seguente modo:

  • Utilizza il gruppo di dati orders_datagroup (nel file modello) per assegnare un nome al criterio di memorizzazione nella cache.
  • Utilizza il parametro sql_trigger per specificare la query che indica la presenza di dati aggiornati: select max(id) from my_tablename. Ogni volta che i dati vengono aggiornati, la query restituisce un nuovo numero.
  • Utilizza l'impostazione max_cache_age per invalidare i dati se sono stati memorizzati nella cache per 24 ore.
  • Utilizza i parametri facoltativi label e description per aggiungere un'etichetta personalizzata e una descrizione del gruppo di dati.
datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

Per utilizzare il criterio di memorizzazione nella cache orders_datagroup come impostazione predefinita per le esplorazioni in un modello, utilizza il parametro persist_with a livello di modello e specifica orders_datagroup:

persist_with: orders_datagroup

Per utilizzare il criterio di memorizzazione nella cache di orders_datagroup per una specifica esplorazione, aggiungi il parametro persist_with sotto il parametro explore e specifica orders_datagroup. Se è stato specificato un gruppo di dati predefinito a livello di modello, puoi utilizzare il parametro persist_with in explore per sostituire l'impostazione predefinita.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Per utilizzare il criterio di memorizzazione nella cache del gruppo di dati orders_datagroup per ricreare una PDT, puoi aggiungere datagroup_trigger nel parametro derived_table e specificare orders_datagroup:

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

Creazione di un gruppo di dati per pianificare le distribuzioni l'ultimo giorno di ogni mese

Ti consigliamo di creare una programmazione per l'invio di contenuti alla fine di ogni mese. Tuttavia, non tutti i mesi hanno lo stesso numero di giorni. Puoi creare un gruppo di dati per attivare la pubblicazione dei contenuti alla fine di ogni mese, indipendentemente dal numero di giorni di un mese specifico.

  1. Crea un gruppo di dati utilizzando un'istruzione SQL da attivare alla fine di ogni mese:
  datagroup: month_end_datagroup {
  sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
  description: "Triggered on the last day of each month"
  }

Questo esempio è in SQL Redshift e potrebbe richiedere lievi adattamenti per database diversi.

Questa istruzione SQL restituisce il mese in cui si terrà domani, l'ultimo giorno del mese, domani il mese successivo, quindi il gruppo di dati verrà attivato. Per tutti gli altri giorni, domani è nello stesso mese, quindi il gruppo di dati non viene attivato.

  1. Seleziona il gruppo di dati in una pianificazione nuova o esistente.

Le pianificazioni basate sui gruppi di dati vengono inviate solo dopo il completamento del processo di rigenerazione per tutte le PDT persistenti con tale parametro del gruppo di dati, garantendo che la distribuzione includa i dati più recenti.

Utilizzo di un gruppo di dati con PDT a cascata

Nel caso delle tabelle derivate a cascata in cui viene fatto riferimento a una tabella derivata (PDT) permanente nella definizione di un'altra, puoi utilizzare un gruppo di dati per specificare una strategia di persistenza per la catena di PDT a cascata.

Ad esempio, ecco parte di un file modello che definisce un gruppo di dati denominato user_facts_etl e un'esplorazione denominata user_stuff. L'esplorazione user_stuff persiste con il gruppo di dati user_facts_etl:

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

L'esplorazione user_stuff unisce la visualizzazione user_facts_pdt_1 alla vista user_facts_pdt_2. Entrambe le viste sono basate su PDT che utilizzano il gruppo di dati user_facts_etl come attivatore di persistenza. La tabella derivata user_facts_pdt_2 fa riferimento alla tabella derivata user_facts_pdt_1, pertanto sono presenti PDT a cascata. Ecco alcune delle LookML dei file di vista per queste PDT:

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

Se disponi di PDT a cascata, devi assicurarti che non abbiano criteri di memorizzazione nella cache del gruppo di dati incompatibili.

Il rigeneratore Looker controlla lo stato e avvia la ricostruzione delle PDT nel seguente modo:

  • Per impostazione predefinita, il rigeneratore Looker controlla la query sql_trigger del gruppo di dati ogni cinque minuti. L'amministratore di Looker può specificare questo intervallo mediante l'impostazione PDT and Datagroup Maintenance Schedule (Pianificazione manutenzione PDT e gruppi di dati) sulla connessione al tuo database.
  • Se il valore restituito dalla query sql_trigger è diverso dal risultato della query nel controllo precedente, il gruppo di dati passa allo stato attivato. In questo esempio, se la tabella etl_jobs ha un nuovo valore ID, viene attivato il gruppo di dati user_facts_etl.

  • Una volta attivato il gruppo di dati user_facts_etl, il rigeneratore Looker ricrea tutte le PDT che lo utilizzano (in altre parole, tutte le PDT definite con datagroup_trigger: user_facts_etl). In questo esempio, il rigeneratore ricostruisce user_facts_pdt_1 e poi ricrea user_facts_pdt_2.

    Quando le PDT condividono lo stesso elemento datagroup_trigger, il rigeneratore ricrea le PDT in ordine di dipendenza, creando prima tabelle a cui le altre tabelle fanno riferimento. Consulta la pagina della documentazione Tabelle derivate in Looker per ulteriori informazioni su come Looker ricrea le tabelle derivate a cascata.

  • Quando il rigeneratore ricostruisce tutte le PDT presenti nel gruppo di dati, rimuove il gruppo di dati user_facts_etl dallo stato attivato.

  • Quando il gruppo di dati user_facts_etl non è più nello stato attivato, Looker reimposta la cache per tutti i modelli e le esplorazioni che utilizzano il gruppo di dati user_facts_etl (in altre parole, tutti i modelli e le esplorazioni definiti con persist_with: user_facts_etl). In questo esempio, ciò significa che Looker reimposta la cache per user_stuff Explore.

  • Verrà inviata qualsiasi pubblicazione di contenuti pianificata basata sul gruppo di dati user_facts_etl. In questo esempio, se è presente una distribuzione pianificata che include una query da user_stuff Explore (Esplora), la query pianificata verrà recuperata dal database per ottenere nuovi risultati.

Condivisione di gruppi di dati tra i file modello

Questo esempio mostra come condividere gruppi di dati con più file modello. Questo approccio è vantaggioso in quanto, se devi modificare un gruppo di dati, devi modificarlo in un unico posto per applicare le modifiche in tutti i modelli.

Per condividere gruppi di dati con più file modello, crea prima un file separato contenente solo i gruppi di dati, poi utilizza il parametro include per include il file di dati nei file del modello.

Creazione di un file dei gruppi di dati

Crea un file .lkml separato per contenere i tuoi gruppi di dati. Puoi creare un file di un gruppo di dati .lkml nello stesso modo in cui puoi creare un file Esplora .lkml separato.

In questo esempio il file datagroups è denominato datagroups.lkml:

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

Includere il file datagroups nei file modello

Ora che hai creato il file dei gruppi di dati, puoi include utilizzarlo in entrambi i modelli e utilizzare persist_with per applicare il gruppo di dati alle singole esplorazioni dei modelli o per applicare le modifiche a tutti i modelli di un modello.

Ad esempio, i seguenti due file di modello sono entrambi include e il file datagroups.lkml.

Questo file è denominato ecommerce.model.lkml. Il gruppo di dati daily viene utilizzato a livello di explore, quindi si applica solo alla funzionalità Esplora di orders:

include: "datagroups.model.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

Il prossimo file è denominato inventory.model.lkml. Il gruppo di dati daily viene utilizzato a livello di model in modo che si applichi a tutte le esplorazioni nel file modello:

include: "datagroups.model.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}