tabella_aggregata

Utilizzo

play: Explore_name:

Gerarchia File modello explore aggregate_table

Valore predefinito Nessuna Accetta Un nome per la tabella aggregata, il sottoparametro query per definire la tabella e il sottoparametro materialization per definire la strategia di persistenza della tabella Regole speciali table_name deve essere univoco all'interno di un determinato explore Nel sottoparametro materialization devi specificare una strategia di persistenza per la tabella aggregata

Definizione

Il parametro aggregate_table viene utilizzato per creare tabelle aggregate che riducono al minimo il numero di query richieste per le tabelle di grandi dimensioni nel database.

Looker utilizza la logica di awareness aggregata per trovare la tabella aggregata più piccola e più efficiente a disposizione nel database per eseguire una query mantenendo la correttezza. Per una panoramica e le strategie di creazione di tabelle aggregate, consulta la pagina Documentazione relativa all'awareness aggregata.

Per tabelle di grandi dimensioni nel tuo database, puoi creare tabelle di dati aggregati più piccoli, raggruppati in base a varie combinazioni di attributi. Le tabelle aggregate agiscono come tabelle roll-up o di riepilogo che Looker può utilizzare per le query quando possibile, anziché la tabella grande originale.

Per essere accessibili per l'awareness aggregata, le tabelle aggregate devono essere persistenti nel tuo database. La strategia di persistenza è specificata nel parametro materialization della tabella aggregata. Inoltre, poiché le tabelle aggregate sono un tipo di tabella derivata permanente (PDT), le tabelle aggregate hanno gli stessi requisiti di dialetto e connessione al database delle PDT. Per maggiori dettagli, consulta la pagina della documentazione Tabelle derivate in Looker.

Dopo aver creato le tabelle aggregate, puoi eseguire query in Explore per vedere quali tabelle aggregate utilizza Looker. Per ulteriori informazioni, consulta la sezione Determinare quale tabella aggregata viene utilizzata per una query nella pagina della documentazione Awareness complessiva.

Consulta la sezione Risoluzione dei problemi nella pagina della documentazione relativa al consapevolezza degli aggregati per conoscere i motivi comuni per cui non vengono utilizzate le tabelle aggregate.

Definizione di una tabella aggregata in LookML

Anziché creare il LookML da zero, puoi utilizzare un pannello Esplora o una dashboard per creare un LookML da tabella aggregato per te. Per maggiori dettagli, consulta le sezioni Ottenere il codice LookML della tabella aggregato da un'esplorazione e Ottenere il LookML della tabella aggregata da una dashboard su questa pagina.

Ogni parametro aggregate_table deve avere un nome univoco all'interno di un determinato campo explore.

Il parametro aggregate_table ha i sottoparametri query e materialization.

query

Il parametro query definisce la query per la tabella aggregata, comprese le dimensioni e le misure da utilizzare. Il parametro query include i seguenti sottoparametri:

Questa sezione si riferisce al parametro query che fa parte di aggregate_table.

query può essere utilizzato anche come parte di explore, come descritto nella pagina della documentazione relativa al parametro query.

Nome parametro	Descrizione	Esempio
dimensions	Un elenco separato da virgole di dimensioni dalla sezione Esplora da includere nella tabella aggregata. Il campo dimensions utilizza questo formato: dimensions: [dimension1, dimension2, ...] Ogni dimensione in questo elenco deve essere definita come dimension nel file di visualizzazione per l'esplorazione della query. Se vuoi includere un campo definito come filter nella query Esplora, puoi aggiungerlo all'elenco filters della query della tabella aggregata.	dimensions:   [orders.created_month, orders.country]
measures	Un elenco separato da virgole di misure dalla sezione Esplora da includere nella tabella aggregata. Il campo measures utilizza questo formato: measures: [measure1, measure2, ...] Per informazioni sui tipi di misurazioni supportate per l'awareness aggregata, consulta la sezione Fattori di tipo di misurazione nella pagina della documentazione Notorietà aggregata.	measures:   [orders.count]
filters	Facoltativamente, puoi aggiungere un filtro a query. I filtri vengono aggiunti alla clausola WHERE dell'SQL che genera la tabella aggregata. Il campo filters utilizza questo formato: filters: [field1: "value1", field2: "value2", ...] Per informazioni su come i filtri possono impedire l'utilizzo della tabella aggregata, consulta la sezione Filtrare i fattori nella pagina della documentazione relativa all'awareness aggregata.	filters: [orders.country: "United States", orders.state: "California"]
sorts	Facoltativamente, puoi specificare i campi di ordinamento e la direzione di ordinamento (in ordine crescente o decrescente) per query. Il campo sorts utilizza questo formato: sorts: [field1: asc|desc, field2: asc|desc, ...]	[orders.country: asc, orders.state: desc]
timezone	Imposta il fuso orario per query. Se il fuso orario non è specificato, la tabella aggregata non eseguirà alcuna conversione del fuso orario e utilizzerà invece il fuso orario del database. Per informazioni sull'impostazione del fuso orario in modo che la tabella aggregata venga utilizzata come origine di query, consulta la sezione Fattori di fuso orario nella pagina della documentazione Informazioni aggregate. L'IDE suggerisce automaticamente il valore del fuso orario quando digiti il parametro timezone nell'IDE. L'IDE mostra anche l'elenco dei valori di fuso orario supportati nel riquadro della Guida rapida.	timezone: America/Los_Angeles

materialization

Il parametro materialization specifica la strategia di persistenza per la tabella aggregata, nonché altre opzioni di distribuzione, partizionamento, indici e clustering che potrebbero essere supportate dal dialetto SQL.

Per essere accessibile per l'awareness aggregata, la tabella deve essere continuata nel tuo database. Una tabella aggregata deve avere una delle seguenti strategie di persistenza:

• datagroup_trigger
• sql_trigger_value
• persist_for (sconsigliato)

A seconda del dialetto SQL, potrebbero essere supportate altre opzioni di materialization per la tabella aggregata:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

Infine, per creare una tabella aggregata incrementale, utilizza i seguenti sottoparametri materialization:

• increment_key
• increment_offset

datagroup_trigger

Utilizza il parametro datagroup_trigger per attivare la rigenerazione della tabella aggregata in base a un datagroup esistente definito nel file modello:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: order_datagroup
    }
    query: {
      ...
    }
  }
  ...
}

sql_trigger_value

Utilizza il parametro sql_trigger_value per attivare la rigenerazione della tabella aggregata in base a un'istruzione SQL da te fornita. Se il risultato dell'istruzione SQL è diverso dal valore precedente, la tabella viene rigenerata. Questa istruzione sql_trigger_value attiverà la rigenerazione quando la data cambia:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      sql_trigger_value: SELECT CURDATE() ;;
    }
    query: {
      ...
    }
  }
  ...
}

persist_for

Il parametro persist_for è supportato anche per le tabelle aggregate. Tuttavia, la strategia persist_for potrebbe non offrire il miglior rendimento per l'awareness aggregata. Questo perché, quando un utente esegue una query che si basa su una tabella persist_for, Looker controlla l'età della tabella rispetto all'impostazione persist_for. Se la tabella è precedente all'impostazione persist_for, viene rigenerata prima dell'esecuzione della query. Se l'età è inferiore all'impostazione persist_for, viene utilizzata la tabella esistente. Pertanto, a meno che un utente non esegua una query entro persist_for, la tabella aggregata deve essere ricreata prima di poter essere utilizzata per l'awareness aggregata.

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      persist_for: "90 minutes"
    }
    query: {
      ...
    }
  }
  ...
}

A meno che tu non abbia compreso le limitazioni e abbia un caso d'uso specifico per l'implementazione di persist_for, è meglio utilizzare datagroup_trigger o sql_trigger_value come strategia di persistenza per le tabelle aggregate.

cluster_keys

Il parametro cluster_keys consente di aggiungere una colonna in cluster alle tabelle partizionate in BigQuery o Snowflake. Il clustering ordina i dati in una partizione in base ai valori nelle colonne in cluster e organizza le colonne in cluster in blocchi di archiviazione di dimensioni ottimali.

Per BigQuery, il clustering è supportato su tabelle aggregate che sono anche partizionate utilizzando il parametro partition_keys.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro cluster_keys.

distribution

Il parametro distribution consente di specificare la colonna di una tabella aggregata a cui applicare una chiave di distribuzione. distribution funziona solo con i database Redshift e Aster. Per altri dialetti SQL (come MySQL e Postgres), utilizza indexes.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro distribution.

distribution_style

Il parametro distribution_style consente di specificare in che modo la query per una tabella aggregata viene distribuita tra i nodi in un database Redshift:

• distribution_style: all indica che tutte le righe sono state copiate completamente in ogni nodo.
• distribution_style: even specifica la distribuzione uniforme, in modo che le righe siano distribuite a nodi diversi in base al round robin.

Per distribuire la query in base a valori univoci in una determinata colonna (chiavi di distribuzione), puoi utilizzare il parametro distribution.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro distribution_style.

indexes

Il parametro indexes consente di applicare gli indici alle colonne di una tabella aggregata.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro indexes.

partition_keys

Il parametro partition_keys definisce un array di colonne in base alle quali verrà eseguito il partizionamento della tabella aggregata. partition_keys supporta i dialetti del database che possono eseguire il partizionamento delle colonne. Quando viene eseguita una query filtrata in base a una colonna partizionata, il database esegue la scansione solo delle partizioni che includono i dati filtrati, anziché della scansione dell'intera tabella. partition_keys è supportato solo con i dialetti Presto e BigQuery.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro partition_keys.

sortkeys

Il parametro sortkeys consente di specificare una o più colonne di una tabella aggregata a cui applicare una chiave di ordinamento standard.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro sortkeys.

increment_key

Puoi creare PDT incrementali nel tuo progetto se il linguaggio le supporta. Una PDT incrementale è una tabella derivata permanente (PDT) che Looker crea aggiungendo alla tabella dati aggiornati, anziché ricreare la tabella nella sua interezza. Per ulteriori informazioni, consulta la pagina Documentazione sulle PDT incrementali.

Le tabelle aggregate sono un tipo PDT e possono essere create in modo incrementale aggiungendo il parametro increment_key. Il parametro increment_key specifica l'incremento di tempo per il quale eseguire query su dati aggiornati e aggiungerli alla tabella aggregata.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro increment_key.

increment_offset

Il parametro increment_offset definisce il numero di periodi di tempo precedenti (al livello di granularità della chiave di incremento) che verrà ricreato quando aggiungi i dati alla tabella aggregata. Il parametro increment_offset è facoltativo per le PDT incrementali e le tabelle aggregate.

Per ulteriori informazioni, consulta la pagina della documentazione del parametro increment_offset.

Recupero di LookML di tabella aggregato da un'esplorazione

In alternativa, gli sviluppatori Looker possono utilizzare una query Explore (Esplora) per creare una tabella aggregata e copiare il codice LookML nel progetto LookML:

1. In Esplora, seleziona tutti i campi e i filtri da includere nella tabella aggregata.
2. Fai clic su Esegui per ottenere i risultati.
3. Seleziona Get LookML (Seleziona LookML) dal menu a forma di ingranaggio di Explore (Esplora). Questa opzione è disponibile solo per gli sviluppatori Looker.
4. Fai clic sulla scheda Tabella aggregata.
5. Looker fornisce il perfezionamento LookML per un'esplorazione che aggiungerà la tabella aggregata all'esplorazione. Copia il codice LookML e incollalo nel file di modello associato, come indicato nel commento sopra il perfezionamento Esplora. Se l'esplorazione è definita in un file Explore separato e non in un file modello, puoi aggiungere il perfezionamento al file dell'esplorazione anziché al file del modello. Entrambe le località funzioneranno.

Looker assegna alla tabella aggregata un nome basato sulle dimensioni in Explore (Esplora). Looker utilizzerà lo stesso nome per la tabella aggregata ogni volta che fornisce il LookML della tabella aggregata per Explore. Tieni presente altri perfezionamenti alla stessa esplorazione che potrebbero essere stati aggiunti in precedenza. Se tu o un altro sviluppatore avete già ottenuto il LookML della tabella aggregata da Explore, Looker assegna lo stesso nome alla tabella aggregata. Se un'esplorazione ha più perfezionamenti, ciascuno con tabelle aggregate con lo stesso nome, un perfezionamento sostituirà gli altri, come descritto nella sezione Perfezionamenti applicati in ordine della pagina della documentazione Perfezionamenti LookML.

Se devi modificare la tabella aggregata LookML, puoi farlo con i parametri descritti nella sezione definire una tabella aggregata in LookML in questa pagina. Puoi rinominare la tabella aggregata senza modificarne l'applicabilità per la query Esplora originale. Tuttavia, qualsiasi altra modifica alla tabella aggregata può influire sulla capacità di Looker di utilizzare la tabella aggregata per la query Explore. Consulta la sezione Progettazione di tabelle aggregate nella pagina della documentazione relativa all'awareness in modo aggregato per suggerimenti su come ottimizzarle e assicurarti che vengano utilizzate per l'awareness.

Ottenere LookML di tabella aggregata da una dashboard

Un'altra opzione per gli sviluppatori di Looker è ottenere la tabella aggregata LookML per tutti i riquadri su una dashboard, quindi copiare il codice LookML nel progetto LookML.

La creazione di tabelle aggregate può migliorare drasticamente le prestazioni di una dashboard, in particolare per i riquadri che eseguono query su set di dati enormi.

Se disponi dell'autorizzazione develop, puoi ottenere il LookML per creare tabelle aggregate per una dashboard aprendo la dashboard, selezionando Get LookML dal menu con tre puntini della dashboard e scegliendo la scheda Aggregate Tables (Tabelle aggregate):

Per ogni riquadro non ancora ottimizzato con il riconoscimento degli aggregati, Looker fornisce il perfezionamento LookML per l'esplorazione che aggiungerà la tabella aggregata all'esplorazione. Se la dashboard include più riquadri della stessa esplorazione, Looker inserisce tutte le tabelle aggregate in un singolo perfezionamento di esplorazione. Per ridurre il numero di tabelle aggregate generate, Looker determina se una tabella aggregata generata può essere utilizzata per più riquadri e, in tal caso, elimina eventuali tabelle aggregate ridondanti che possono essere utilizzate per un numero inferiore di riquadri.

Copia e incolla ogni perfezionamento Esplora nel file del modello associato, come indicato nel commento sopra il perfezionamento Esplora. Se l'esplorazione è definita in un file Explore separato e non in un file modello, puoi aggiungere il perfezionamento al file Esplora anziché al file modello. Entrambe le località funzioneranno.

Tieni presente che Looker assegna a ogni tabella aggregata un nome basato sulle dimensioni nella query del riquadro. Looker utilizzerà lo stesso nome per la tabella aggregata ogni volta che fornisce il LookML della tabella aggregata per una query di riquadri. Devi quindi tenere conto di altri perfezionamenti che potrebbero essere stati aggiunti in precedenza al riquadro Esplora. Se tu o un altro sviluppatore avete già ottenuto il LookML della tabella aggregata dalla query del riquadro della dashboard, Looker fornirà lo stesso nome per la tabella aggregata. Se un'esplorazione ha più perfezionamenti, ciascuno con tabelle aggregate con lo stesso nome, un perfezionamento sostituirà gli altri, come descritto nella sezione Perfezionamenti applicati in ordine della pagina della documentazione Perfezionamenti LookML.

Se a un riquadro è applicato un filtro della dashboard, Looker ne aggiunge la dimensione alla tabella aggregata in modo che quest'ultima possa essere utilizzata per il riquadro. Questo perché le tabelle aggregate possono essere utilizzate per una query solo se i filtri della query fanno riferimento a campi disponibili come dimensioni nella tabella aggregata. Per informazioni, consulta la pagina Documentazione relativa all'awareness aggregata.

Se devi modificare la tabella aggregata LookML, puoi farlo con i parametri descritti nella sezione definire una tabella aggregata in LookML in questa pagina. Puoi rinominare la tabella aggregata senza cambiarne l'applicabilità nel riquadro della dashboard originale, ma qualsiasi altra modifica alla tabella aggregata potrebbe influire sulla capacità di Looker di utilizzare la tabella aggregata per la dashboard. Consulta la sezione Progettazione di tabelle aggregate nella pagina della documentazione relativa all'awareness in modo aggregato per suggerimenti su come ottimizzarle e assicurarti che vengano utilizzate per l'awareness.

Esempio

L'esempio seguente crea una tabella aggregata monthly_orders per l'esplorazione event. La tabella aggregata crea un conteggio mensile degli ordini. Looker utilizzerà la tabella aggregata per le query sul numero di ordini che possono sfruttare la granularità mensile, come quelle per i conteggi annuali, trimestrali e mensili.

La tabella aggregata viene configurata in modo permanente utilizzando il gruppo di dati orders_datagroup.

La definizione della tabella aggregata ha il seguente aspetto:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_month]
      measures: [orders.count]
      filters: [orders.created_date: "1 year", orders.status: "fulfilled"]
      timezone: America/Los_Angeles
    }
  }
}

Aspetti da considerare

Per suggerimenti sulla creazione strategica delle tabelle aggregate, consulta la sezione Progettazione di tabelle aggregate nella pagina della documentazione relativa all'awareness in modo aggregato.

• Fattori relativi al periodo di tempo
• Fattori relativi al fuso orario
• Fattori di filtro
• Fattori sul campo
• Misurare i fattori dei tipi

Supporto del dialetto per l'awareness aggregata

La possibilità di utilizzare l'awareness aggregata dipende dal dialetto del database utilizzato dalla connessione di Looker. Nell'ultima release di Looker i seguenti dialetti supportano l'awareness aggregata: