gruppo di dati

Utilizzo

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}
Gerarchia
datagroup
Valore predefinito
Nessuno

Accetta
Un identificatore per il tuo gruppo di dati, più i parametri secondari che definiscono le proprietà del gruppo di dati.

Definizione

Utilizza datagroup per assegnare un criterio di memorizzazione nella cache per le esplorazioni e/o per specificare una strategia di persistenza per le tabelle derivate permanenti (PDT). Se vuoi più criteri per esplorazioni e PDT diverse, utilizza un parametro datagroup separato per specificare ogni criterio.

Fornisci un nome univoco per il datagruppo utilizzando solo lettere, numeri e trattini bassi. Non sono consentiti altri caratteri.

Puoi aggiungere un'etichetta e una descrizione per il datagruppo:

  • label: specifica un'etichetta facoltativa per il gruppo di dati. Per maggiori dettagli, consulta la sezione label e description di questa pagina.
  • description: specifica una descrizione facoltativa per il gruppo di dati che può essere utilizzata per spiegare lo scopo e il meccanismo del gruppo di dati. Per maggiori dettagli, consulta la sezione label e description di questa pagina.

Specifica i dettagli dei criteri di memorizzazione nella cache e persistenza 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 informazioni dettagliate, consulta la sezione max_cache_age in 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 informazioni dettagliate, consulta la sezione sql_trigger in questa pagina.
  • interval_trigger: specifica una pianificazione oraria per l'attivazione del gruppo di dati, ad esempio "24 hours". Per informazioni dettagliate, consulta la sezione interval_trigger in 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 che corrisponda al caricamento di dati (ETL) nel database, poi specifica un valore max_cache_age che invaliderà i dati precedenti se l'ETL dà errore. Il parametro max_cache_age garantisce che, se la cache per un gruppo di dati non viene cancellata da sql_trigger o interval_trigger, le voci della cache scadranno entro un certo 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 delle risorse del database durante l'esecuzione di query sul database.

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

Senza gli override delle PDT, puoi comunque utilizzare un gruppo di dati per il modello e le sue esplorazioni, purché tu definisca il criterio di memorizzazione nella cache del gruppo di dati utilizzando solo max_cache_age, ma non sql_trigger.

max_cache_age

Il parametro max_cache_age specifica una stringa contenente un numero intero seguito da "seconds", "minutes" o "hours". Questo periodo di tempo è il periodo massimo di utilizzo dei risultati memorizzati nella cache da parte delle query di esplorazione che utilizzano il gruppo di dati.

Quando l'età della cache di una query supera il valore 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 su per quanto tempo i dati vengono archiviati nella cache, consulta la pagina della documentazione Memorizzazione nella cache delle query.

Il parametro max_cache_age definisce solo quando la cache viene invalidata; non attiva la rigenerazione delle PDT. Se definisci un datagruppo con solo max_cache_age, riceverai un avviso di convalida LookML se a quest'ultimo sono assegnate tabelle derivate. Se lasci una tabella derivata assegnata a un datagruppo con un solo parametro max_cache_age, la tabella derivata verrà creata quando viene eseguita la prima query, ma rimarrà nello schema temporaneo a tempo indeterminato e non verrà mai ricreata, anche se viene eseguita di nuovo una query. Se vuoi che una PDT venga ricreata a un intervallo di tempo specifico, devi aggiungere un parametro interval_trigger al datagroup per definire una pianificazione di ricreazione della 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 Pianificazione della manutenzione di PDT e gruppi di dati della connessione al database. Se la query restituisce un valore diverso dal 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 parametro datagroup_trigger. Al termine della ricostruzione della PDT, il gruppo di dati passa allo stato pronto e Looker invalida i risultati memorizzati nella cache di tutte le esplorazioni che utilizzano quel gruppo di dati.

In genere, sql_trigger specifica una query SQL che indica quando si è verificato un nuovo caricamento di dati (ETL), ad esempio eseguendo una query su max(ID) in una tabella. Puoi anche utilizzare sql_trigger per specificare una determinata ora del giorno eseguendo una query sulla data corrente e aggiungendo ore aggiuntive al timestamp in base alle esigenze per raggiungere l'ora che preferisci, ad esempio le 4:00.

Tieni presente quanto segue in merito a sql_trigger:

  • Non puoi utilizzare sql_trigger se la connessione al database utilizza OAuth o attributi utente e hai disattivato le PDT per la connessione. Questo perché Looker ha bisogno di credenziali statiche per accedere al tuo database ed eseguire la query specificata nel parametro sql_trigger. Quando le PDT sono abilitate, puoi utilizzare i campi Override PDT per fornire a Looker credenziali di accesso statiche separate per i processi PDT, anche se la connessione utilizza credenziali dinamiche come OAuth o attributi utente. Tuttavia, con le PDT disattivate, se la connessione utilizza OAuth o gli attributi utente, non puoi fornire a Looker le credenziali utente statiche necessarie per le query sql_trigger.
  • Looker non esegue la conversione del fuso orario per sql_trigger. Se vuoi attivare il datagruppo a una determinata ora del giorno, imposta il trigger nel fuso orario per cui è configurato il database.

Consulta questi esempi della documentazione del parametro sql_trigger per trovare idee su come configurare le query SQL per attivare un datagroup.

interval_trigger

Puoi utilizzare il parametro secondario facoltativo interval_trigger per specificare una durata per la ricompilazione. Nel parametro interval_trigger passi una stringa contenente un numero intero seguito da "seconds", "minutes" o "hours".

label e description

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

Questi sottoparametri vengono visualizzati nella pagina Gruppi di dati della sezione Database del riquadro Amministrazione. Per ulteriori informazioni su come vengono visualizzati, consulta la pagina della documentazione Impostazioni di amministrazione - Gruppi di dati.

Esempi

Gli esempi seguenti mettono in evidenza i casi d'uso di datagroup, tra cui:

Creazione di una policy di memorizzazione nella cache per recuperare nuovi risultati ogni volta che sono disponibili nuovi dati o almeno ogni 24 ore

Per creare una policy di memorizzazione nella cache che recuperi nuovi risultati ogni volta che sono disponibili nuovi dati o almeno ogni 24 ore:

  • Utilizza il gruppo di dati orders_datagroup (nel file del modello) per denominare il 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, questa 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 predefinito 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 orders_datagroup per un'esplorazione specifica, aggiungi il parametro persist_with sotto il parametro explore e specifica orders_datagroup. Se è specificato un gruppo di dati predefinito a livello di modello, puoi utilizzare il parametro persist_with in un 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 al parametro derived_table e specificare orders_datagroup:

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

Creazione di un gruppo di dati per programmare le consegne l'ultimo giorno di ogni mese

Potresti voler creare una pianificazione che invii la pubblicazione dei contenuti alla fine di ogni mese. Tuttavia, non tutti i mesi hanno lo stesso numero di giorni. Puoi creare un datagruppo per attivare le pubblicazioni di contenuti alla fine di ogni mese, indipendentemente dal numero di giorni di un mese specifico.

  1. Crea un datagruppo 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 Redshift SQL e potrebbe richiedere lievi adattamenti per database diversi.

    Questa istruzione SQL restituisce il mese in cui cade domani. L'ultimo giorno del mese, domani è il mese successivo, quindi il gruppo di dati verrà attivato. A giorni alterni, il giorno successivo è nello stesso mese, quindi il gruppo di dati non viene attivato.

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

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

Utilizzo di un gruppo di dati con PDT a cascata

Nel caso di tabelle derivate a cascata persistenti, in cui una tabella derivata persistente (PDT) viene citata 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 una parte di un file del modello che definisce un gruppo di dati chiamato user_facts_etl e un'esplorazione chiamata user_stuff. L'esplorazione user_stuff viene mantenuta 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 vista user_facts_pdt_1 alla vista user_facts_pdt_2. Entrambe queste visualizzazioni si basano su PDT che utilizzano il gruppo di dati user_facts_etl come trigger di persistenza. La tabella derivata user_facts_pdt_2 fa riferimento alla tabella derivata user_facts_pdt_1, quindi si tratta di PDT a cascata. Ecco alcuni codici LookML dei file di visualizzazione 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 hai PDT a cascata, devi assicurarti che le PDT non abbiano criteri di memorizzazione nella cache dei gruppi di dati incompatibili.

Il rigeneratore Looker controlla lo stato e avvia le ricostruzioni di queste 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 utilizzando l'impostazione Pianificazione manutenzione PDT e gruppi di dati nella connessione al database).
  • Se il valore restituito dalla query sql_trigger è diverso dal risultato della query nel controllo precedente, lo stato del gruppo di dati risulta 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 ricostruisce tutte le PDT che utilizzano il gruppo di dati (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 user_facts_pdt_2.

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

  • Quando il rigeneratore ricostruisce tutte le PDT nel gruppo di dati, il gruppo di dati user_facts_etl non è più nello 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 (ovvero tutti i modelli e le esplorazioni definiti con persist_with: user_facts_etl). In questo esempio, ciò significa che Looker reimposta la cache per l'esplorazione user_stuff.

  • Verranno inviate tutte le pubblicazioni di contenuti programmate basate sul gruppo di dati user_facts_etl. In questo esempio, se è presente una distribuzione pianificata che include una query dall'esplorazione user_stuff, la query pianificata verrà recuperata dal database per ottenere nuovi risultati.

Condivisione di gruppi di dati tra file di modelli

Questo esempio mostra come condividere i gruppi di dati con più file di modelli. Questo approccio è vantaggioso perché, se devi modificare un gruppo di dati, devi farlo in un solo posto per applicare le modifiche a tutti i modelli.

Per condividere i gruppi di dati con più file di modelli, crea prima un file separato che contenga solo i gruppi di dati, quindi utilizza il parametro include per include il file dei gruppi di dati nei file dei modelli.

Creare un file di gruppi di dati

Crea un file .lkml separato che contenga i tuoi gruppi di dati. Puoi creare un file di gruppo di dati .lkml nello stesso modo in cui puoi creare un file di esplorazione .lkml separato.

In questo esempio, il file dei gruppi di dati è denominato datagroups.lkml:

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

Inclusione del file datagroups nei file del modello

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

Ad esempio, i seguenti due file modello include il file datagroups.lkml.

Questo file si chiama ecommerce.model.lkml. Il gruppo di dati daily viene utilizzato a livello explore in modo che si applichi solo a Esplora orders:

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

Il file successivo si chiama 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 del modello:

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

explore: items {
}

explore: products {
}