Aggrega awareness

Nota: per una guida sull'implementazione del riconoscimento aggregato, consulta anche la pagina delle nostre best practice relative all'awareness aggregata.

Panoramica

Looker utilizza la logica di riconoscimento dell'aggregazione per trovare la tabella più piccola ed efficiente disponibile nel tuo database per eseguire una query, pur mantenendo l'accuratezza.

Per le tabelle molto grandi del database, gli sviluppatori di Looker possono creare tabelle aggregate più piccole di dati, raggruppate in base a varie combinazioni di attributi. Le tabelle aggregate fungono da tabelle di aggregazione o di riepilogo che Looker può utilizzare per le query laddove possibile, al posto della tabella grande originale. Se implementata in modo strategico, la consapevolezza aggregata può accelerare la query media in base a ordini di grandezza.

Ad esempio, potresti avere una tabella di dati nell'ordine dei petabyte con una riga per ogni ordine che si è verificato sul tuo sito web. Da questo database, puoi creare una tabella aggregata con i totali delle vendite giornaliere. Se il tuo sito web riceve 1000 ordini ogni giorno, la tabella aggregata giornaliera rappresenterà ciascun giorno con 999 righe in meno rispetto alla tabella originale. Puoi creare un'altra tabella aggregata con i totali delle vendite mensili che sarà ancora più efficiente. Quindi ora, se un utente esegue una query per le vendite giornaliere o settimanali, Looker utilizzerà la tabella del totale delle vendite giornaliere. Se un utente esegue una query sulle vendite annuali e non hai una tabella aggregata annuale, Looker utilizzerà l'opzione successiva, ovvero la tabella aggregata delle vendite mensili di questo esempio.

Looker risponde alle domande degli utenti con le tabelle aggregate più piccole possibili, se possibile. Ad esempio:

• Per una query sulle vendite mensili totali, Looker utilizza la tabella aggregata basata sulle vendite mensili (sales_monthly_aggregate_table).
• Non esiste una tabella aggregata con questa granularità per una query sul totale di ogni vendita in un giorno, perciò Looker recupera i risultati della query dalla tabella del database originale (orders_database). Tuttavia, se gli utenti eseguono spesso questo tipo di query, potresti creare una tabella aggregata per la query in questione.
• Per una query sulle vendite settimanali, non esiste una tabella aggregata settimanale, perciò Looker utilizza la seconda cosa migliore, ovvero la tabella aggregata basata sulle vendite giornaliere (sales_daily_aggregate_table).

Utilizzando la logica di riconoscimento dell'aggregazione, Looker eseguirà query sulla tabella aggregata più piccola possibile per rispondere alle domande degli utenti. La tabella originale verrà utilizzata solo per le query che richiedono una maggiore granularità rispetto a quella fornita dalle tabelle aggregate.

Non è necessario unire le tabelle aggregate o aggiungerle a un'esplorazione separata. Looker regola invece in modo dinamico la clausola FROM della query Esplora per accedere alla tabella aggregata migliore per la query. Ciò significa che i drill vengono gestiti e le esplorazioni possono essere consolidate. Con il riconoscimento dell'aggregazione, un'esplorazione può sfruttare automaticamente le tabelle aggregate ma, se necessario, approfondire i dati granulari.

Puoi anche sfruttare le tabelle aggregate per migliorare drasticamente le prestazioni delle dashboard, in particolare per i riquadri che eseguono query su set di dati di grandi dimensioni. Per maggiori dettagli, consulta la sezione Ottenere il LookML di una tabella aggregata da una dashboard nella pagina della documentazione del parametro aggregate_table.

Aggiunta di tabelle aggregate al progetto

Nota: per essere accessibili per il rilevamento aggregato, le tabelle aggregate devono essere rese persistenti nel database. Poiché le tabelle aggregate sono un tipo di tabella derivata permanente (PDT), le tabelle aggregate hanno gli stessi requisiti delle PDT. Per maggiori dettagli, consulta la pagina della documentazione Tabelle derivate in Looker.

Gli sviluppatori di Looker possono creare tabelle aggregate strategiche che riducono al minimo il numero di query richieste nelle tabelle di grandi dimensioni di un database. Le tabelle aggregate devono essere permanenti al database in modo che possano essere accessibili per il riconoscimento dell'aggregazione. Le tabelle aggregate sono quindi un tipo di tabella derivata permanente (PDT).

Una tabella aggregata viene definita utilizzando il parametro aggregate_table in un parametro explore nel tuo progetto LookML.

Ecco un esempio di explore con una tabella aggregata in LookML:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

Per creare una tabella aggregata, puoi scrivere il codice LookML da zero oppure ottenere il codice LookML della tabella aggregata da un'esplorazione o da una dashboard. Consulta la pagina della documentazione relativa al parametro aggregate_table per le specifiche del parametro aggregate_table e dei relativi sottoparametri.

Progettazione di tabelle aggregate

Affinché una query Esplora utilizzi una tabella aggregata, la tabella aggregata deve essere in grado di fornire dati accurati per la query Esplora. Looker può utilizzare una tabella aggregata per una query di esplorazione se si verificano tutte le seguenti condizioni:

• I campi della query Esplora sono un sottoinsieme dei campi della tabella aggregata (consulta la sezione Fattori campi in questa pagina). In alternativa, per i periodi di tempo, gli intervalli di tempo della query Esplora possono essere ricavati dagli intervalli di tempo nella tabella aggregata (consulta la sezione Fattori del periodo di tempo in questa pagina).
• La query Esplora contiene tipi di misure supportati dalla consapevolezza aggregata (consulta la sezione Misurare i fattori di tipo in questa pagina) oppure la query Esplora contiene una tabella aggregata con corrispondenza esatta (consulta la sezione Creazione di tabelle aggregate che corrispondono esattamente alle query Esplora in questa pagina).
• Il fuso orario della query Esplora corrisponde a quello utilizzato dalla tabella aggregata (consulta la sezione Fattori relativi al fuso orario in questa pagina).
• I filtri della query Esplora fanno riferimento ai campi disponibili come dimensioni nella tabella aggregata oppure ogni filtro della query Esplora corrisponde a un filtro nella tabella aggregata (consulta la sezione Fattori filtro in questa pagina).

Un modo per garantire che una tabella aggregata possa fornire dati accurati per una query di esplorazione consiste nel creare una tabella aggregata che corrisponde esattamente a una query di esplorazione. Per maggiori dettagli, consulta la sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di Esplora in questa pagina.

Fattori di campo

Per essere utilizzata per una query Esplora, una tabella aggregata deve avere tutte le dimensioni e le misure necessarie per la query Esplora, inclusi i campi utilizzati per i filtri nella query Esplora. Se una query di esplorazione contiene una dimensione o una misura che non è presente in una tabella aggregata, Looker non può utilizzare la tabella aggregata e utilizzerà al suo posto la tabella di base.

Ad esempio, se una query raggruppa per le dimensioni A e B, aggrega per misura C e filtri sulla dimensione D, la tabella aggregata deve contenere almeno A, B e D come dimensioni e C come misura.

La tabella aggregata può avere anche altri campi, ma deve includere almeno i campi di query Esplora affinché sia utilizzabile per l'ottimizzazione. L'unica eccezione sono le dimensioni dell'intervallo di tempo, poiché è possibile ricavare periodi di tempo con granularità più granulare da quelli con granularità più granulare.

Per queste considerazioni sui campi, una tabella aggregata è specifica per l'esplorazione in cui è definita. Una tabella aggregata definita in un'esplorazione non verrà utilizzata per le query su un'altra esplorazione.

Fattori del periodo di tempo

La logica della consapevolezza aggregata di Looker è in grado di ricavare un periodo di tempo da un altro. È possibile utilizzare una tabella aggregata per una query a condizione che il relativo periodo di tempo abbia una granularità maggiore (o uguale) rispetto alla query Esplora. Ad esempio, una tabella aggregata basata su dati giornalieri può essere utilizzata per una query Esplora che chiama altri periodi di tempo, come query per dati giornalieri, mensili e annuali o anche per dati relativi a giorno del mese, giorno dell'anno e settimana dell'anno. Tuttavia, non è possibile utilizzare una tabella aggregata annuale per una query Esplora che richiede dati orari, poiché i dati della tabella aggregata non hanno granularità sufficientemente granulare per la query Esplora.

Lo stesso vale per i sottoinsiemi di intervalli di tempo. Ad esempio, se hai una tabella aggregata filtrata in base agli ultimi tre mesi e un utente esegue una query sui dati con un filtro relativo agli ultimi due mesi, Looker può utilizzare la tabella aggregata per quella query.

Inoltre, la stessa logica si applica alle query con filtri del periodo di tempo: è possibile utilizzare una tabella aggregata per una query con un filtro per il periodo di tempo, purché il periodo di tempo della tabella aggregata abbia una granularità maggiore (o uguale) rispetto al filtro per il periodo di tempo utilizzato nella query Esplora. Ad esempio, una tabella aggregata con una dimensione di periodo di tempo giornaliero può essere utilizzata per una query Esplora che filtra per giorno, settimana o mese.

Misura i fattori del tipo

Affinché una query Esplora utilizzi una tabella aggregata, le misure nella tabella aggregata devono essere in grado di fornire dati accurati per la query Esplora.

Per questo motivo, sono supportati solo alcuni tipi di misure, come descritto nelle sezioni seguenti:

• Misure con tipi di misura supportati
• Misure definite dalle espressioni SQL
• Misure non definite con ${TABLE}
• Misure che approssimano conteggi distinti

Se una query di esplorazione utilizza un altro tipo di misura, per restituire i risultati Looker utilizzerà la tabella originale, non la tabella aggregata. L'unica eccezione è se la query Esplora è una corrispondenza esatta di una query su una tabella aggregata, come descritto nella sezione Creare tabelle aggregate che corrispondono esattamente alle query di esplorazione.

In caso contrario, Looker utilizzerà la tabella originale, non la tabella aggregata, per restituire i risultati.

Misure con tipi di misura supportati

La consapevolezza aggregata può essere utilizzata per le query Esplora che utilizzano misure con questi tipi di misure:

• sum
• count
• min
• max
• average

Nota: se un'esplorazione unisce più tabelle di database, Looker può eseguire il rendering delle misure di tipo SUM, COUNT e AVERAGE rispettivamente come SUM DISTINCT, COUNT DISTINCT e AVERAGE DISTINCT. Looker esegue questa operazione per evitare errori di calcolo del fanout, come descritto nella sezione Aggregazioni simmetriche per le esplorazioni con join di questa pagina.

Per utilizzare una tabella aggregata per una query di esplorazione, Looker deve essere in grado di utilizzare le misure della tabella aggregata per fornire dati accurati nella query Esplora. Ad esempio, una misura con type: sum può essere utilizzata per l'awareness aggregata perché è possibile sommare diverse somme: per ottenere una somma mensile precisa, è possibile sommare una tabella aggregata di somme settimanali. Allo stesso modo, è possibile utilizzare una misura con type: max perché per trovare il valore massimo settimanale preciso è possibile utilizzare una tabella aggregata di valori massimi giornalieri.

Nel caso di misure con type: average, è supportato il riconoscimento aggregato perché Looker utilizza i dati di somma e conteggio per ricavare con precisione i valori medi dalle tabelle aggregate.

Misure definite con espressioni SQL

La consapevolezza aggregata può essere utilizzata anche con le misure definite con espressioni nel parametro sql. Quando vengono definiti con espressioni SQL, sono supportati anche i seguenti tipi di misura:

• number
• date
• string
• yesno

La consapevolezza aggregata è supportata per misure definite come combinazioni di altre misure, come in questo esempio:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

La consapevolezza aggregata è supportata anche per le misure in cui i calcoli sono definiti nel parametro sql, come questa misura:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

Inoltre, il riconoscimento aggregato è supportato per le misure in cui le operazioni MIN, MAX e COUNT sono definite nel parametro sql, come questa misura:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

Avviso: il riconoscimento aggregato è supportato solo per le operazioni MIN(), MAX() e COUNT(). Se vuoi utilizzare una misura media o somma nella tabella aggregata, puoi creare una misura pari a type: average o type: sum, entrambi supportati per l'awareness aggregata.

Misure che fanno riferimento ai campi LookML

Quando le espressioni sql vengono utilizzate nelle misure, la consapevolezza aggregata supporta i seguenti tipi di riferimenti ai campi:

• Riferimenti che utilizzano il formato ${view_name.field_name}, che indica i campi in altre viste
• Riferimenti che utilizzano il formato ${field_name}, che indica i campi nella stessa visualizzazione

La consapevolezza aggregata non è supportata per le misure definite utilizzando il formato ${TABLE}.column_name, che indica una colonna in una tabella. Per una panoramica sull'utilizzo dei riferimenti in LookML, consulta la pagina della documentazione Incorporamento di SQL e riferimento agli oggetti LookML.

Ad esempio, una misura definita con questo parametro sql non sarebbe supportata in una tabella aggregata, poiché utilizza il formato ${TABLE}.column_name:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

Se vuoi includere questa misura in una tabella aggregata, puoi creare una dimensione definita con il formato ${TABLE}.column_name e poi creare una misura che faccia riferimento alla dimensione, in questo modo:

 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

Ora puoi utilizzare l'unità di misura wholesale_value nella tabella aggregata.

Misure che approssimano conteggi distinti

In generale, i conteggi distinti non sono supportati con il riconoscimento aggregato perché non è possibile ottenere dati precisi se tenti di aggregare conteggi distinti. Ad esempio, se stai conteggiando i singoli utenti di un sito web, è possibile che un utente sia arrivato sul sito due volte, a distanza di tre settimane. Se provassi ad applicare una tabella aggregata settimanale per ottenere un conteggio mensile di utenti distinti sul tuo sito web, quell'utente verrà contato due volte nella query di conteggio mensile distinti e i dati sarebbero errati.

Una soluzione alternativa è creare una tabella aggregata che corrisponde esattamente a una query Esplora, come descritto nella sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di esplorazione di questa pagina. Quando la query Esplora e una query sulla tabella aggregata sono uguali, misure di conteggio distinte forniscono dati accurati, pertanto possono essere utilizzate per la consapevolezza aggregata.

Un'altra opzione è utilizzare le approssimazioni per conteggi distinti. Per i dialetti che supportano gli schizzi HyperLogLog, Looker può utilizzare l'algoritmo HyperLogLog per approssimare i conteggi distinti per le tabelle aggregate.

È noto che l'algoritmo HyperLogLog genera un errore di circa il 2%. Il parametro allow_approximate_optimization: yes richiede agli sviluppatori di Looker di confermare l'autorizzazione a utilizzare dati approssimativi per la misura, in modo che la misura possa essere calcolata approssimativamente da tabelle aggregate.

Per saperne di più e per consultare l'elenco dei dialetti che supportano il conteggio distinto utilizzando HyperLogLog, consulta la pagina della documentazione relativa al parametro allow_approximate_optimization.

Fattori relativi al fuso orario

In molti casi, gli amministratori dei database utilizzano il fuso orario UTC come fuso orario per i database. Tuttavia, molti utenti potrebbero non trovarsi nel fuso orario UTC. Looker offre diverse opzioni per la conversione dei fusi orari, in modo che gli utenti ricevano i risultati delle query nel proprio fuso orario:

• Fuso orario query, un'impostazione che si applica a tutte le query sulla connessione al database. Se tutti gli utenti si trovano nello stesso fuso orario, puoi impostare un fuso orario query singola in modo che tutte le query vengano convertite dal fuso orario del database a quello della query.
• Fusi orari specifici dell'utente, che consentono di assegnare gli utenti e di selezionare i fusi orari singolarmente. In questo caso, le query vengono convertite dal fuso orario del database al fuso orario del singolo utente.

Per ulteriori informazioni su queste opzioni, consulta la pagina della documentazione relativa all'utilizzo delle impostazioni del fuso orario.

Questi concetti sono importanti per comprendere il riconoscimento degli aggregati perché, affinché una tabella aggregata possa essere utilizzata per una query con dimensioni di data o filtri per data, il fuso orario nella tabella aggregata deve corrispondere all'impostazione del fuso orario utilizzata per la query originale.

Le tabelle aggregate utilizzano il fuso orario del database se non viene specificato alcun valore timezone. La connessione al database utilizzerà anche il fuso orario del database se una delle seguenti condizioni è vera:

• Il database non supporta i fusi orari.
• Il fuso orario della query della connessione al database è impostato sullo stesso fuso orario del fuso orario del database.
• La connessione al database non ha né un fuso orario query specificato né fusi orari specifici dell'utente. In questo caso, la connessione al database utilizzerà il fuso orario del database.

Se una di queste condizioni è vera, puoi omettere il parametro timezone per le tabelle aggregate.

In caso contrario, è necessario definire il fuso orario della tabella aggregata in modo che corrisponda alle possibili query e aumentare le probabilità di utilizzo della tabella aggregata:

• Se la connessione al database utilizza un fuso orario singola query, il valore timezone della tabella aggregata deve corrispondere al valore del fuso orario della query.
• Se la connessione al database utilizza fusi orari specifici dell'utente, devi creare tabelle aggregate identiche, ciascuna con un valore timezone diverso in modo da corrispondere ai possibili fusi orari dei tuoi utenti.

Avviso: Looker non può utilizzare una tabella aggregata per una query di esplorazione se il fuso orario nella tabella aggregata non corrisponde a quello nella query Esplora. Se la connessione al database ha fusi orari specifici degli utenti, significa che è necessaria una tabella aggregata separata per ogni fuso orario dell'utente.

Filtra fattori

Fai attenzione quando includi filtri nella tabella aggregata. I filtri in una tabella aggregata possono restringere i risultati al punto in cui la tabella aggregata è inutilizzabile. Ad esempio, supponiamo che crei una tabella aggregata per i conteggi giornalieri degli ordini e che la tabella aggregata filtri solo gli ordini di occhiali da sole provenienti dall'Australia. Se un utente esegue una query Esplora per il conteggio giornaliero degli ordini di occhiali da sole in tutto il mondo, Looker non può utilizzare la tabella aggregata per quella query di esplorazione, poiché la tabella aggregata contiene solo i dati per l'Australia. La tabella aggregata filtra i dati in modo troppo limitato per essere utilizzati dalla query Esplora.

Inoltre, presta attenzione ai filtri che gli sviluppatori Looker potrebbero aver integrato nell'esplorazione, ad esempio:

• access_filters: applica restrizioni relative ai dati specifiche dell'utente.
• always_filter: richiedi agli utenti di includere un determinato insieme di filtri per una query di Esplora. Gli utenti possono modificare il valore del filtro predefinito per la query, ma non possono rimuovere completamente il filtro.
• conditionally_filter: definisce un insieme di filtri predefiniti che gli utenti possono ignorare se applicano almeno un filtro da un secondo elenco definito anche nell'esplorazione.

Questi tipi di filtri si basano su campi specifici. Se la tua esplorazione dispone di questi filtri, devi includere i relativi campi nel parametro dimensions di aggregate_table.

Ad esempio, ecco un'esplorazione con un filtro di accesso basato sul campo orders.region:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

Per creare una tabella aggregata da utilizzare per questa esplorazione, la tabella aggregata deve includere il campo su cui si basa il filtro di accesso. Nel prossimo esempio, il filtro di accesso si basa sul campo orders.region e questo stesso campo è incluso come dimensione nella tabella aggregata:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

Poiché la query sulla tabella aggregata include la dimensione orders.region, Looker può filtrare dinamicamente i dati nella tabella aggregata in modo che corrispondano al filtro della query Esplora. Di conseguenza, Looker può comunque utilizzare la tabella aggregata per le query dell'esplorazione, anche se quest'ultima dispone di un filtro di accesso.

Questo vale anche per le query Esplora che utilizzano una tabella derivata nativa configurata con bind_filters. Il parametro bind_filters passa i filtri specificati da una query Esplora alla sottoquery della tabella derivata nativa. In caso di riconoscimento dell'aggregazione, se la query di esplorazione richiede una tabella derivata nativa che utilizza bind_filters, la query Esplora può usare una tabella aggregata solo se tutti i campi utilizzati nel parametro bind_filters della tabella derivata nativa hanno gli stessi valori di filtro nella query Esplora e nella tabella aggregata.

Creare tabelle aggregate che corrispondono esattamente alle query Esplora

Un modo per assicurarti che sia possibile utilizzare una tabella aggregata per una query di esplorazione consiste nel creare una tabella aggregata che corrisponda esattamente alla query Esplora. Se la query Esplora e la tabella aggregata utilizzano entrambi le stesse misure, dimensioni, filtri, fusi orari e altri parametri, per definizione i risultati della tabella aggregata verranno applicati alla query Esplora. Se una tabella aggregata corrisponde esattamente a una query di esplorazione, Looker può utilizzare tabelle aggregate che includono qualsiasi tipo di misura.

Puoi creare una tabella aggregata da un'esplorazione utilizzando l'opzione Ottieni LookML dal menu a forma di ingranaggio di un'esplorazione. Puoi anche creare corrispondenze esatte per tutti i riquadri di una dashboard utilizzando l'opzione Ottieni LookML dal menu a forma di ingranaggio di una dashboard.

Determinare quale tabella aggregata viene utilizzata per una query

Gli utenti con autorizzazioni see_sql possono utilizzare i commenti nella scheda SQL di un'esplorazione per vedere quale tabella aggregata verrà utilizzata per una query. I commenti della scheda SQL vengono visualizzati anche in modalità di sviluppo, per cui gli sviluppatori possono testare nuove tabelle aggregate per verificare in che modo Looker le utilizza prima di eseguire il push di nuove tabelle in produzione.

Ad esempio, sulla base della tabella aggregata mensile di esempio mostrata in precedenza, puoi accedere a Esplora ed eseguire una query per i totali delle vendite annuali. Quindi, puoi fare clic sulla scheda SQL per visualizzare i dettagli della query creata da Looker. Se sei in modalità di sviluppo, Looker mostra i commenti per indicare la tabella aggregata che ha utilizzato per la query.

Dai seguenti commenti sulla scheda SQL, puoi vedere che Looker sta utilizzando la tabella aggregata sales_monthly per questa query e informazioni sul motivo per cui non sono state utilizzate altre tabelle aggregate per la query:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

Consulta la sezione Risoluzione dei problemi in questa pagina per conoscere i possibili commenti visualizzati nella scheda SQL e i suggerimenti per risolverli.

Stime dei risparmi di calcolo per la consapevolezza aggregata

Se la connessione al database supporta le stime dei costi e se è possibile utilizzare una tabella aggregata per una query, la finestra Esplora mostrerà i risparmi in termini di calcolo derivanti dall'utilizzo della tabella aggregata invece di eseguire query direttamente sul database. I risparmi per la consapevolezza aggregata sono mostrati accanto al pulsante Esegui in un'esplorazione prima dell'esecuzione della query.

Prima di eseguire la query, se vuoi vedere quale tabella aggregata viene utilizzata per la query, puoi fare clic sulla scheda SQL, come descritto nella sezione Determinare la tabella aggregata utilizzata per una query della pagina della documentazione.

Dopo l'esecuzione della query, nella finestra Esplora viene visualizzata la tabella aggregata utilizzata per rispondere alla query accanto al pulsante Esegui.

I risparmi per la consapevolezza dell'aggregazione vengono mostrati per le connessioni ai database abilitate per le stime dei costi. Per ulteriori informazioni, consulta la pagina della documentazione Esplorazione dei dati in Looker .

Looker unisce nuovi dati alle tabelle aggregate

Per le tabelle aggregate con filtri temporali, Looker può unire i dati aggiornati nella tabella aggregata. Potresti avere una tabella aggregata che include i dati dei tre giorni precedenti, ma questa potrebbe essere stata creata ieri. Nella tabella aggregata mancano le informazioni relative alla data odierna, pertanto non ti aspetti di utilizzarla per una query Esplora sulle informazioni giornaliere più recenti.

Tuttavia, Looker può comunque utilizzare i dati contenuti nella tabella aggregata per la query, perché eseguirà una query sui dati più recenti e unirà questi risultati nei risultati della tabella aggregata.

Looker può unire i dati aggiornati a quelli della tabella aggregata in base alle seguenti circostanze:

• La tabella aggregata ha un filtro temporale.
• La tabella aggregata include una dimensione basata sullo stesso campo temporale del filtro temporale.

Ad esempio, la seguente tabella aggregata ha una dimensione basata sul campo orders.created_date e un filtro temporale ("3 days") basato sullo stesso campo:

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

Se questa tabella aggregata è stata creata ieri, Looker recupererà i dati più recenti non ancora inclusi nella tabella aggregata e poi unirà i risultati aggiornati a quelli della tabella aggregata. Ciò significa che i tuoi utenti riceveranno i dati più recenti e al contempo ottimizzeranno il rendimento utilizzando l'awareness aggregata.

Se sei in modalità di sviluppo, puoi fare clic sulla scheda SQL di un'esplorazione per visualizzare la tabella aggregata utilizzata da Looker per la query e l'istruzione UNION utilizzata da Looker per importare dati più recenti non inclusi nella tabella aggregata.

Nota: se Looker non è in grado di unire i dati aggiornati alla tabella aggregata, utilizzerà i dati esistenti della tabella aggregata.

Le tabelle aggregate devono essere rese persistenti

Per essere accessibile per il rilevamento dell'aggregazione, la tabella aggregata deve essere permanente nel database. La strategia di persistenza è specificata nel parametro materialization della tabella aggregata. Poiché le tabelle aggregate sono un tipo di tabella derivata permanente (PDT), le tabelle aggregate hanno gli stessi requisiti delle PDT. Per maggiori dettagli, consulta la pagina della documentazione Tabelle derivate in Looker.

Puoi creare PDT incrementali nel progetto, se il dialetto le supporta. Looker crea PDT incrementali aggiungendo alla tabella dati aggiornati, invece di ricreare la tabella nella sua interezza. Poiché le tabelle aggregate sono a loro volta un tipo di PDT, puoi creare anche tabelle aggregate incrementali. Per ulteriori informazioni sulle PDT incrementali, consulta la pagina della documentazione relativa alle PDT incrementali. Consulta la pagina della documentazione relativa al parametro increment_key per un esempio di tabella aggregata incrementale.

Un utente con l'autorizzazione develop può eseguire l'override delle impostazioni di persistenza e ricreare tutte le tabelle aggregate per una query per ottenere i dati più aggiornati. Per ricreare le tabelle per una query, seleziona l'opzione Ricrea le tabelle derivate ed esegui dal menu a forma di ingranaggio Esplora azioni.

Affinché questa opzione sia disponibile, devi attendere il caricamento della query Esplora.

L'opzione Ricrea le tabelle derivate ed esegui ricrea tutte le tabelle derivate a cui viene fatto riferimento nella query, nonché tutte le tabelle derivate che dipendono dalle tabelle nella query. Sono incluse le tabelle aggregate, che a loro volta sono un tipo di tabella derivata permanente.

Per l'utente che avvia l'opzione Ricrea le tabelle derivate ed esegui, la query attende che le tabelle vengano create di nuovo prima di caricare i risultati. Le query di altri utenti continueranno a utilizzare le tabelle esistenti. Dopo aver ricreato le tabelle permanenti, tutti gli utenti utilizzeranno le tabelle rigenerate.

Consulta la pagina della documentazione Tabelle derivate in Looker per ulteriori dettagli sull'opzione Ricrea le tabelle derivate ed esegui.

Risoluzione dei problemi

Come descritto nella sezione Determinare la tabella aggregata utilizzata per una query, se sei in modalità di sviluppo, puoi eseguire query nell'esplorazione e fare clic sulla scheda SQL per visualizzare eventuali commenti sulla tabella aggregata utilizzata per la query.

La scheda SQL include anche commenti sul motivo per cui le tabelle aggregate non sono state utilizzate per una query, se questo è il caso. Per le tabelle aggregate che non vengono utilizzate, il commento inizia con:

Did not use [explore name]::[aggregate table name];

Ad esempio, ecco un commento sul motivo per cui la tabella aggregata sales_daily definita nell'esplorazione order_items non è stata utilizzata per una query:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

In questo caso, i filtri nella query hanno impedito l'utilizzo della tabella aggregata.

La seguente tabella mostra alcuni altri possibili motivi per cui una tabella aggregata non può essere utilizzata, insieme ai passaggi che puoi intraprendere per aumentare l'usabilità della tabella aggregata.

Motivo per il mancato utilizzo della tabella aggregata	Spiegazione e possibili passaggi
Nessun campo di questo tipo nell'esplorazione.	Si è verificato un errore di tipo di convalida di LookML. Ciò è probabilmente dovuto al fatto che la tabella aggregata non è stata definita correttamente o esiste un errore di battitura in LookML per la tabella aggregata. Un probabile responsabile è un nome di campo errato o simili. Per risolvere il problema, verifica che le dimensioni e le misure nella tabella aggregata corrispondano ai nomi dei campi nell'esplorazione. Consulta la pagina della documentazione relativa al parametro aggregate_table per saperne di più su come definire una tabella aggregata.
La tabella aggregata non include i seguenti campi nella query.	Per essere utilizzata per una query Esplora, una tabella aggregata deve avere tutte le dimensioni e le misure necessarie per la query Esplora, inclusi i campi utilizzati per i filtri nella query Esplora. Se una query di esplorazione contiene una dimensione o una misura che non è presente in una tabella aggregata, Looker non può utilizzare la tabella aggregata e utilizzerà al suo posto la tabella di base. Per informazioni dettagliate, consulta la sezione Fattori di campo in questa pagina. L'unica eccezione sono le dimensioni dell'intervallo di tempo, poiché è possibile ricavare periodi di tempo con granularità più granulare da quelli con granularità più granulare. Per risolvere il problema, verifica che i campi della query Esplora siano inclusi nella definizione della tabella aggregata.
La query conteneva i seguenti filtri che non sono stati inclusi come campi né corrispondevano esattamente ai filtri nella tabella aggregata.	I filtri nella query Esplora impediscono a Looker di utilizzare la tabella aggregata. Per risolvere il problema, puoi eseguire una delle seguenti operazioni: Aggiungi lo stesso filtro alla tabella aggregata. Aggiungi il campo utilizzato dal filtro alla tabella aggregata. Rimuovi i filtri dalla query Esplora. Per informazioni dettagliate, consulta la sezione Fattori di filtro in questa pagina.
La query contiene le seguenti misure che non possono essere aggregate.	La query contiene uno o più tipi di misure non supportati per la consapevolezza aggregata, ad esempio conteggio distinto, mediana o percentile. Per risolvere il problema, controlla il tipo di ogni misura nella query e assicurati che sia uno dei tipi di misura supportati. Inoltre, se la tua esplorazione ha join, verifica che le misure non vengano convertite in misure distinte (aggregazioni simmetriche) tramite join fantasiati. Per una spiegazione, consulta la sezione Dati aggregati simmetrici per le esplorazioni con join in questa pagina.
Una tabella aggregata diversa era più adatta per l'ottimizzazione.	Erano presenti più tabelle aggregate valide per la query e Looker ha trovato una tabella aggregata più ottimale da utilizzare. In questo caso non è necessario fare nulla.
Looker non ha eseguito alcun raggruppamento (a causa di un parametro primary_key o cancel_grouping_fields) e pertanto la query non può essere aggregata.	La query fa riferimento a una dimensione che impedisce che abbia una clausola GROUP BY, pertanto Looker non può utilizzare alcuna tabella aggregata per la query. Per risolvere il problema, verifica che i parametri primary_key della vista e i parametri cancel_grouping_fields dell'esplorazione siano impostati correttamente.
La tabella aggregata conteneva filtri non presenti nella query.	La tabella aggregata ha un filtro non temporale che non è presente nella query. Per risolvere questo problema, puoi rimuovere il filtro dalla tabella aggregata. Per informazioni dettagliate, consulta la sezione Fattori di filtro in questa pagina.
Un campo viene definito come campo con solo filtro nella query Esplora, ma viene elencato nel parametro dimensions della tabella aggregata.	Il parametro dimensions della tabella aggregata elenca un campo definito solo come campo filter nella query Esplora. Per risolvere il problema, rimuovi il campo dall'elenco dimensions della tabella aggregata. Se questo campo è necessario per la tabella aggregata, aggiungilo all'elenco filters nella query della tabella aggregata.
L'ottimizzatore non è in grado di determinare il motivo per cui non è stata utilizzata la tabella aggregata.	Questo commento è riservato alle richieste d'angolo. Se lo vedi per una query Esplora utilizzata spesso, puoi creare una tabella aggregata che corrisponde esattamente alla query Esplora. Puoi ottenere facilmente un LookML della tabella aggregata da un'esplorazione, come descritto nella pagina del parametro aggregate_table.

Aspetti da considerare

Dati aggregati simmetrici per le esplorazioni con join

Una cosa importante da notare è che in un'esplorazione che unisce più tabelle di database, Looker può eseguire il rendering delle misure di tipo SUM, COUNT e AVERAGE rispettivamente come SUM DISTINCT, COUNT DISTINCT e AVERAGE DISTINCT. Looker lo fa per evitare calcoli errati del fanout. Ad esempio, una misura count viene visualizzata come tipo di misura count_distinct. Questo consente di evitare calcoli errati del fanout per i join e fa parte della funzionalità di aggregazione simmetrica di Looker. Per una spiegazione di questa funzionalità di Looker, consulta la pagina delle best practice sui dati aggregati simmetrici.

La funzionalità di aggregazioni simmetriche previene errori di calcolo, ma può anche impedire l'utilizzo delle tabelle aggregate in alcuni casi, pertanto è importante comprenderle.

Per i tipi di misure supportati dall'awareness aggregata, questo vale per sum, count e average. Looker eseguirà il rendering di questi tipi di misure come DISTINCT se:

• La misura proviene dalla vista "one" dei join many-to-one o one-to-many.
• La misura proviene da entrambe le visualizzazioni di un join many-to-many.

Consulta la pagina della documentazione del parametro relationship per una spiegazione di questi tipi di join.

Se noti che la tabella aggregata non viene utilizzata per questo motivo, puoi creare una tabella aggregata in modo che corrisponda esattamente a una query Esplora in modo da utilizzare questi tipi di misure per un'esplorazione con join. Per saperne di più, consulta la sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di Esplora in questa pagina.

Inoltre, se disponi di un dialetto SQL che supporta gli schizzi HyperLogLog, puoi aggiungere il parametro allow_approximate_optimization: yes alla misura. Quando una misura del conteggio viene definita con allow_approximate_optimization: yes, Looker può utilizzarla per il riconoscimento aggregato, anche se viene visualizzato come un conteggio distinto.

Per informazioni dettagliate e per un elenco dei dialetti SQL che supportano gli schizzi HyperLogLog, consulta la pagina della documentazione relativa al parametro allow_approximate_optimization.

Supporto dei dialetti per la consapevolezza aggregata

La possibilità di utilizzare il riconoscimento degli aggregati dipende dal dialetto del database utilizzato dalla connessione Looker. Nella release più recente di Looker, i seguenti dialetti supportano il riconoscimento aggregato:

Nota: l'SQL precedente di BigQuery supporta il riconoscimento aggregato, ma non supporta l'unione di dati aggiornati con quelli della tabella aggregata.

Dialetto	Supportato?
Valanga atiana	Sì
Amazon Athena	Sì
Amazon Aurora MySQL	Sì
Amazon Redshift	Sì
Apache drud	No
Apache Druid 0.13 e versioni successive	No
Apache Druid 0.18 e versioni successive	No
Apache Hive 2.3 e versioni successive	Sì
Apache Hive 3.1.2 o versioni successive	Sì
Apache Spark 3 e versioni successive	Sì
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	Sì
Cloudera Impala 3.1+ con driver nativo	Sì
Cloudera Impala con driver nativo	Sì
DataVirtuality	No
Databricks	Sì
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11+	No
Exasol	Sì
Firebolt	No
SQL precedente di Google BigQuery	Sì
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	No
Google Spanner	No
Verde prugna	Sì
HyperSQL	No
IBM Netezza	Sì
MariaDB	Sì
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	Sì
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	Sì
Microsoft SQL Server 2012 e versioni successive	Sì
Microsoft SQL Server 2016	Sì
Microsoft SQL Server 2017 e versioni successive	Sì
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	Sì
ADWC Oracle	Sì
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	Sì
PrestoSQL	Sì
SAP HANA 2 o versioni successive	Sì
SingleStore	Sì
SingleStore 7 o versioni successive	Sì
Snowflake	Sì
Teradata	Sì
Trino	Sì
Vettore	Sì
Vertica	Sì

Supporto dei dialetti per la creazione incrementale di tabelle aggregate

Affinché Looker supporti le tabelle aggregate incrementali nel tuo progetto Looker, è necessario che anche il dialetto del database le supporti. La tabella seguente mostra quali dialetti supportano la creazione incrementale di PDT nell'ultima release di Looker:

Dialetto	Supportato?
Valanga atiana	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sì
Apache drud	No
Apache Druid 0.13 e versioni successive	No
Apache Druid 0.18 e versioni successive	No
Apache Hive 2.3 e versioni successive	No
Apache Hive 3.1.2 o versioni successive	No
Apache Spark 3 e versioni successive	No
ClickHouse	No
Cloudera Impala 3.1 o versioni successive	No
Cloudera Impala 3.1+ con driver nativo	No
Cloudera Impala con driver nativo	No
DataVirtuality	No
Databricks	Sì
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11+	No
Exasol	No
Firebolt	No
SQL precedente di Google BigQuery	No
SQL standard di Google BigQuery	Sì
Google Cloud PostgreSQL	Sì
Google Cloud SQL	No
Google Spanner	No
Verde prugna	Sì
HyperSQL	No
IBM Netezza	No
MariaDB	No
Microsoft Azure PostgreSQL	Sì
Database SQL di Microsoft Azure	No
Analisi di Microsoft Azure Synapse	Sì
Microsoft SQL Server 2008 e versioni successive	No
Microsoft SQL Server 2012 e versioni successive	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 e versioni successive	No
MongoBI	No
MySQL	Sì
MySQL 8.0.12 o versioni successive	Sì
Oracle	No
ADWC Oracle	No
PostgreSQL 9.5 e versioni successive	Sì
PostgreSQL pre-9.5	Sì
PrestoDB	No
PrestoSQL	No
SAP HANA 2 o versioni successive	No
SingleStore	No
SingleStore 7 o versioni successive	No
Snowflake	Sì
Teradata	No
Trino	No
Vettore	No
Vertica	Sì