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 gruppo di dati, oltre a sottoparametri 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 permanenza 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 gruppo di dati utilizzando solo lettere, numeri e trattini bassi. Non sono consentiti altri caratteri.

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

  • label: specifica un'etichetta facoltativa per il gruppo di dati. Per i dettagli, consulta la sezione label e description in 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 i dettagli, consulta la sezione label e description in questa pagina.

Specifica i dettagli del criterio di memorizzazione nella cache e di permanenza 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 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, il gruppo di dati passa a uno stato attivato. Per i dettagli, 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 i dettagli, 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, quindi 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 di tempo massimo per l'utilizzo dei risultati memorizzati nella cache dalle query di esplorazione 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. 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 ricreazione 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 lasci una tabella derivata assegnata a un gruppo di dati con solo un parametro max_cache_age, la tabella derivata verrà creata quando viene eseguita la query per la prima volta, ma rimarrà nello schema temporaneo a tempo indeterminato e non verrà mai ricreata, anche se viene eseguita di nuovo la query. Se intendi ricreare una PDT a un intervallo di tempo specifico, devi aggiungere un parametro interval_trigger al gruppo di dati 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 ricreazione 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, se necessario, per raggiungere l'ora desiderata, ad esempio le 4:00.

Tieni presente i seguenti punti importanti relativi 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 database ed eseguire la query specificata nel parametro sql_trigger. Quando le PDT sono attivate, 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, se le PDT sono disattivate e la connessione utilizza OAuth o attributi utente, non puoi fornire a Looker le credenziali utente statiche richieste per le query sql_trigger.
  • 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 il trigger nel fuso orario per cui è configurato il database.

Per trovare idee su come configurare le query SQL per attivare un gruppo di dati, consulta questi esempi nella documentazione del parametro sql_trigger.

interval_trigger

Puoi utilizzare il sottoparametro facoltativo interval_trigger per specificare una durata per la ricreazione. 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 delle impostazioni internazionali.

Questi sottoparametri vengono visualizzati nella pagina Gruppi di dati nella 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 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 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 assegnare un nome al criterio di memorizzazione nella cache.
  • Utilizza il parametro sql_trigger per specificare la query che indica che sono presenti 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 a livello di modello è specificato un gruppo di dati predefinito, puoi utilizzare il parametro persist_with in un explore per eseguire l'override dell'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 sotto il parametro derived_table e specificare il orders_datagroup:

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

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

Potresti voler creare una pianificazione che invii una consegna 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 le consegne di 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 Redshift SQL e potrebbe richiedere lievi modifiche per database diversi.

    Questa istruzione SQL restituisce il mese in cui si trova 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.

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

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

Utilizzo di un gruppo di dati con PDT a cascata

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

Ad esempio, ecco una 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 con la visualizzazione user_facts_pdt_2. Entrambe queste visualizzazioni si basano su PDT che utilizzano il gruppo di dati user_facts_etl come trigger di permanenza. 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 dei 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 del gruppo di dati incompatibili.

Il rigeneratore Looker controlla lo stato e avvia le ricreazioni di queste PDT nel seguente modo:

  • Per impostazione predefinita, il rigeneratore Looker controlla la query del gruppo di dati sql_trigger ogni cinque minuti (l'amministratore di Looker può specificare questo intervallo utilizzando l'impostazione Pianificazione della manutenzione di 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 ricrea 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 ricrea user_facts_pdt_1, quindi ricrea user_facts_pdt_2.

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

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

  • Una volta che 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 l'esplorazione user_stuff.

  • Verranno inviate tutte le consegne di contenuti pianificate basate sul gruppo di dati user_facts_etl. In questo esempio, se è presente una consegna 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 in quanto, se devi modificare un gruppo di dati, devi modificarlo 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 include parametro per include il file dei gruppi di dati nei file dei modelli.

Creazione di un file di gruppi di dati

Crea un file .lkml separato per contenere i gruppi di dati. Puoi creare un file di gruppi di dati .lkml nello stesso modo in cui puoi creare un file Explore .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 dei gruppi di dati nei file dei modelli

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 alle singole esplorazioni nei modelli o a tutte le esplorazioni in un modello.

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

Questo file è denominato ecommerce.model.lkml. Il gruppo di dati daily viene utilizzato a livello di explore in modo che si applichi solo all'esplorazione orders:

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

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

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

explore: items {
}

explore: products {
}