Sensibilizzazione aggregata

Panoramica

Looker utilizza la logica di consapevolezza degli aggregati per trovare la tabella più piccola ed efficiente disponibile nel tuo database per eseguire una query mantenendo comunque l'accuratezza.

Per le tabelle molto grandi nel database, gli sviluppatori di Looker possono creare tabelle aggregate più piccole di dati, raggruppati in base a varie combinazioni di attributi. Le tabelle aggregate fungono da tabelle di riepilogo che Looker può utilizzare per le query, se possibile, anziché la tabella di grandi dimensioni originale. Se implementato in modo strategico, il riconoscimento degli aggregati può velocizzare la query media di diversi ordini di grandezza.

Ad esempio, potresti avere una tabella di dati su scala di petabyte con una riga per ogni ordine effettuato 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 al giorno, la tabella aggregata giornaliera rappresenterà ogni 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. 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à la soluzione migliore successiva, ovvero la tabella aggregata delle vendite mensili in questo esempio.

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

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

Utilizzando la logica di consapevolezza degli aggregati, Looker eseguirà query sulla tabella degli aggregati più piccola possibile per rispondere alle domande degli utenti. La tabella originale viene utilizzata solo per le query che richiedono una granularità più precisa di quella che possono fornire le tabelle aggregate.

Non è necessario unire o aggiungere le tabelle aggregate a un'esplorazione separata. Looker, invece, regola dinamicamente la clausola FROM della query di esplorazione per accedere alla migliore tabella aggregata per la query. Ciò significa che i livelli di analisi vengono mantenuti e le esplorazioni possono essere consolidate. Grazie alla consapevolezza aggregata, un'esplorazione può sfruttare automaticamente le tabelle aggregate, ma anche analizzare in dettaglio i dati granulari, se necessario.

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

Aggiungere tabelle aggregate al progetto

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 persistenti nel database in modo che siano accessibili per la consapevolezza 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 puoi ottenere il codice LookML della tabella aggregata da un'esplorazione o da una dashboard. Consulta la pagina della documentazione del parametro aggregate_table per informazioni specifiche sul parametro aggregate_table e sui relativi sottoparametri.

Progettazione di tabelle aggregate

Affinché una query di esplorazione utilizzi una tabella aggregata, quest'ultima deve essere in grado di fornire dati accurati per la query di esplorazione. 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 (vedi la sezione Fattori dei campi in questa pagina). In alternativa, per i periodi di tempo, i periodi di tempo della query Esplora possono essere derivati dai periodi di tempo nella tabella aggregata (vedi la sezione Fattori del periodo di tempo in questa pagina).
• La query Esplora contiene tipi di misura supportati dalla consapevolezza aggregata (vedi la sezione Fattori del tipo di misura in questa pagina) oppure la query Esplora ha una tabella aggregata che corrisponde esattamente (vedi la sezione Creare tabelle aggregate che corrispondono esattamente alle query Esplora in questa pagina).
• Il fuso orario della query di esplorazione corrisponde a quello utilizzato dalla tabella aggregata (vedi la sezione Fattori del fuso orario in questa pagina).
• I filtri della query di esplorazione fanno riferimento a campi disponibili come dimensioni nella tabella aggregata oppure ogni filtro della query di esplorazione corrisponde a un filtro nella tabella aggregata (vedi la sezione Fattori di filtro in questa pagina).

Un modo per assicurarsi che una tabella aggregata possa fornire dati accurati per una query Esplora è creare una tabella aggregata che corrisponda esattamente a una query Esplora. Per informazioni dettagliate, consulta la sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di Esplora in questa pagina.

Fattori del campo

Per essere utilizzata per una query di esplorazione, una tabella aggregata deve contenere tutte le dimensioni e le misure necessarie per la query di esplorazione, inclusi i campi utilizzati per i filtri nella query di esplorazione. Se una query di esplorazione contiene una dimensione o una misura che non si trova in una tabella aggregata, Looker non può utilizzare la tabella aggregata e utilizzerà invece la tabella di base.

Ad esempio, se una query raggruppa in base alle dimensioni A e B, aggrega in base alla misura C e filtra in base alla dimensione D, la tabella aggregata deve avere almeno A, B e D come dimensioni e C come misura.

La tabella aggregata può contenere anche altri campi, ma deve contenere almeno i campi della query Esplora per essere valida per l'ottimizzazione. L'unica eccezione sono le dimensioni dell'intervallo di tempo, poiché gli intervalli di tempo con granularità più grossolana possono essere derivati da quelli con granularità più fine.

A causa di queste considerazioni sui campi, una tabella aggregata è specifica dell'esplorazione in cui è definita. Una tabella aggregata definita in un'esplorazione non verrà utilizzata per le query in un'esplorazione diversa.

Fattori relativi al periodo di tempo

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

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

Inoltre, la stessa logica si applica alle query con filtri temporali: una tabella aggregata può essere utilizzata per una query con un filtro temporale, a condizione che il periodo di tempo della tabella aggregata abbia una granularità più precisa (o uguale) rispetto al filtro temporale utilizzato nella query Esplora. Ad esempio, una tabella aggregata con una dimensione del periodo di tempo giornaliero può essere utilizzata per una query di esplorazione che filtra per giorno, settimana o mese.

Fattori del tipo di misurazione

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

Per questo motivo, sono supportati solo determinati tipi di metriche, come descritto nelle sezioni seguenti:

• Misure con tipi di misura supportati
• Misure definite da espressioni SQL
• Misure non definite con ${TABLE}
• Misure che approssimano i conteggi univoci

Se una query di esplorazione utilizza un altro tipo di misura, Looker utilizzerà la tabella originale, non quella aggregata, per restituire i risultati. L'unica eccezione si verifica se la query di esplorazione corrisponde esattamente a una query della tabella aggregata, come descritto nella sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di esplorazione.

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

Misure con tipi di misure supportati

L'awareness aggregata può essere utilizzata per le query di esplorazione che utilizzano misure con questi tipi di misure:

• sum
• count
• min
• max
• average

Per utilizzare una tabella aggregata per una query di esplorazione, Looker deve essere in grado di operare sulle misure della tabella aggregata per fornire dati accurati nella query di esplorazione. Ad esempio, una misura con type: sum può essere utilizzata per la consapevolezza aggregata perché puoi sommare diverse somme: una tabella aggregata di somme settimanali può essere sommata per ottenere una somma mensile accurata. Allo stesso modo, è possibile utilizzare una metrica con type: max perché una tabella aggregata dei massimi giornalieri può essere utilizzata per trovare il massimo settimanale accurato.

Nel caso di misure con type: average, l'aggregazione consapevole è supportata perché Looker utilizza i dati di somma e conteggio per derivare con precisione i valori medi dalle tabelle aggregate.

Misure definite con espressioni SQL

L'aggregazione della consapevolezza può essere utilizzata anche con le misure definite con espressioni nel parametro sql. Se definiti con espressioni SQL, sono supportati anche i seguenti tipi di misura:

• number
• date
• string
• yesno

L'aggregazione è supportata per le metriche definite come combinazioni di altre metriche, come in questo esempio:

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

L'aggregazione della consapevolezza è supportata anche per le misure in cui i calcoli sono definiti nel parametro sql, ad esempio questa misura:

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

L'aggregazione consapevole è supportata per le misure in cui le operazioni MIN, MAX e COUNT sono definite nel parametro sql, ad esempio questa misura:

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

Misure che fanno riferimento ai campi LookML

Quando le espressioni sql vengono utilizzate nelle metriche, l'aggregazione consapevole supporta i seguenti tipi di riferimenti ai campi:

• Riferimenti che utilizzano il formato ${view_name.field_name}, che indica i campi in altre visualizzazioni
• 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 dell'utilizzo dei riferimenti in LookML, consulta la pagina di documentazione Incorporare SQL e fare 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 invece creare una dimensione definita con il formato ${TABLE}.column_name, poi creare una misura che faccia riferimento alla dimensione, ad esempio:

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

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

Ora puoi utilizzare la misura wholesale_value nella tabella aggregata.

Misure che approssimano i conteggi distinti

In generale, i conteggi univoci non sono supportati con la consapevolezza aggregata perché non è possibile ottenere dati accurati se si tenta di aggregare i conteggi univoci. Ad esempio, se stai conteggiando gli utenti unici su un sito web, potrebbe esserci un utente che ha visitato il sito web due volte, a distanza di tre settimane. Se hai provato ad applicare una tabella aggregata settimanale per ottenere un conteggio mensile degli utenti unici sul tuo sito web, l'utente verrà conteggiato due volte nella query di conteggio mensile degli utenti unici e i dati non saranno corretti.

Una soluzione alternativa consiste nel creare una tabella aggregata che corrisponda esattamente a una query di esplorazione, come descritto nella sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di esplorazione di questa pagina. Quando la query di esplorazione e la query di una tabella aggregata sono uguali, le misure di conteggio univoco forniscono dati accurati, quindi possono essere utilizzate per la consapevolezza aggregata.

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

È noto che l'algoritmo HyperLogLog ha un errore di circa il 2%. Il parametro allow_approximate_optimization: yes richiede agli sviluppatori di Looker di confermare che è possibile utilizzare dati approssimativi per la misura, in modo che possa essere calcolata in modo approssimativo dalle tabelle aggregate.

Per ulteriori informazioni e per l'elenco dei dialetti che supportano il conteggio distinto utilizzando HyperLogLog, consulta la pagina della documentazione del parametro allow_approximate_optimization.

Fattori del fuso orario

In molti casi, gli amministratori di database utilizzano il fuso orario UTC 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 delle 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 unico fuso orario delle query in modo che tutte le query vengano convertite dal fuso orario del database in quello delle query.
• Fusi orari specifici degli utenti, in cui gli utenti possono essere assegnati e 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 relative al fuso orario.

Questi concetti sono importanti per comprendere la consapevolezza aggregata perché, affinché una tabella aggregata possa essere utilizzata per una query con dimensioni data o filtri data, il fuso orario della 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 si verifica una delle seguenti condizioni:

• Il tuo database non supporta i fusi orari.
• Il fuso orario query della connessione al database è impostato sullo stesso fuso orario del database.
• La connessione al database non ha un fuso orario delle 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, il fuso orario della tabella aggregata deve essere definito in modo che corrisponda alle possibili query, in modo che la tabella aggregata abbia maggiori probabilità di essere utilizzata:

• Se la connessione al database utilizza un unico fuso orario della query, devi far corrispondere il valore timezone della tabella aggregata al valore del fuso orario della query.
• Se la connessione al database utilizza fusi orari specifici per utente, devi creare tabelle aggregate identiche, ognuna con un valore timezone diverso in modo che corrisponda ai possibili fusi orari dei tuoi utenti.

Fattori di filtro

Fai attenzione quando includi i filtri nella tabella aggregata. I filtri su una tabella aggregata possono restringere i risultati al punto da rendere inutilizzabile la tabella aggregata. Ad esempio, supponiamo che tu 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 di esplorazione per i conteggi giornalieri degli ordini di occhiali da sole in tutto il mondo, Looker non può utilizzare la tabella aggregata per questa query di esplorazione, poiché la tabella aggregata contiene solo i dati per l'Australia. La tabella aggregata filtra i dati in modo troppo restrittivo per essere utilizzata dalla query Esplora.

Inoltre, tieni conto dei filtri che gli sviluppatori di Looker potrebbero aver integrato nell'esplorazione, ad esempio:

• access_filters: applica limitazioni ai dati specifici dell'utente.
• always_filter: richiedi agli utenti di includere un determinato insieme di filtri per una query di esplorazione. Gli utenti possono modificare il valore predefinito del filtro 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 in Esplora.

Questi tipi di filtri si basano su campi specifici. Se l'esplorazione include 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. Nell'esempio successivo, 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 della tabella aggregata include la dimensione orders.region, Looker può filtrare dinamicamente i dati nella tabella aggregata in modo che corrispondano al filtro della query di esplorazione. Pertanto, Looker può comunque utilizzare la tabella aggregata per le query dell'Explore, anche se l'Explore ha un filtro di accesso.

Ciò vale anche per le query di esplorazione che utilizzano una tabella derivata nativa configurata con bind_filters. Il parametro bind_filters passa i filtri specificati da una query di esplorazione alla sottoquery della tabella derivata nativa. Nel caso della consapevolezza aggregata, se la query di esplorazione richiede una tabella derivata nativa che utilizza bind_filters, la query di esplorazione può utilizzare una tabella aggregata solo se tutti i campi utilizzati nel parametro bind_filters della tabella derivata nativa hanno esattamente gli stessi valori di filtro nella query di esplorazione e nella tabella aggregata.

Creazione di tabelle aggregate che corrispondono esattamente alle query di Esplora

Un modo per assicurarsi che una tabella aggregata possa essere utilizzata per una query di Esplora è creare una tabella aggregata che corrisponda esattamente alla query di Esplora. Se la query Esplora e la tabella aggregata utilizzano 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 è in grado di utilizzare tabelle aggregate che includono qualsiasi tipo di metrica.

Puoi creare una tabella aggregata da un'esplorazione utilizzando l'opzione Recupera 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, in modo che gli sviluppatori possano testare le nuove tabelle aggregate per vedere come le utilizza Looker prima di trasferirle in produzione.

Ad esempio, in base alla tabella aggregata mensile di esempio mostrata in precedenza, puoi andare su Esplora ed eseguire una query per i totali delle vendite annuali. Poi puoi fare clic sulla scheda SQL per visualizzare i dettagli della query creata da Looker. Se ti trovi in modalità Development (Sviluppo), Looker mostra i commenti per indicare la tabella aggregata utilizzata per la query.

Dai seguenti commenti nella scheda SQL, possiamo vedere che Looker utilizza la tabella aggregata sales_monthly per questa query e informazioni sul motivo per cui altre tabelle aggregate non sono state utilizzate 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 di questa pagina per possibili commenti che potresti visualizzare nella scheda SQL e suggerimenti su come risolverli.

Stime del risparmio di calcolo per l'awareness aggregata

Se la connessione al database supporta le stime dei costi e se è possibile utilizzare una tabella aggregata per una query, la finestra Esplora mostra il risparmio di calcolo derivante dall'utilizzo della tabella aggregata anziché dall'esecuzione di query direttamente nel database. Il risparmio aggregato in termini di notorietà viene visualizzato accanto al pulsante Esegui in un'esplorazione prima dell'esecuzione della query.

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

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

Il risparmio aggregato di consapevolezza viene mostrato per le connessioni al database per cui sono abilitate le stime dei costi. Per ulteriori informazioni, consulta la pagina della documentazione Esplorazione dei dati in Looker .

Looker unisce i 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 degli ultimi tre giorni, ma questa tabella potrebbe essere stata creata ieri. Nella tabella aggregata mancherebbero le informazioni di oggi, quindi non ti aspetteresti di utilizzarla per una query di esplorazione sulle informazioni giornaliere più recenti.

Tuttavia, Looker può comunque utilizzare i dati nella tabella aggregata per la query perché esegue una query sui dati più recenti, quindi unisce i risultati a quelli della tabella aggregata.

Looker può unire i dati aggiornati con quelli della tabella aggregata nelle 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, quindi unirà i risultati aggiornati con quelli della tabella aggregata. Ciò significa che i tuoi utenti riceveranno i dati più recenti e continueranno a ottimizzare il rendimento utilizzando la consapevolezza aggregata.

Se ti trovi in modalità Development (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 i dati più recenti non inclusi nella tabella aggregata.

Le tabelle aggregate devono essere persistenti

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

Puoi creare PDT incrementali nel tuo progetto se il tuo dialetto le supporta. Looker crea PDT incrementali aggiungendo nuovi dati alla tabella, anziché ricostruirla interamente. Poiché le tabelle aggregate sono un tipo di PDT, puoi creare anche tabelle aggregate incrementali. Per ulteriori informazioni sui PDT incrementali, consulta la pagina della documentazione relativa ai PDT incrementali. Per un esempio di tabella aggregata incrementale, consulta la pagina della documentazione del parametro increment_key.

Un utente con l'autorizzazione develop può ignorare le impostazioni di persistenza e ricompilare tutte le tabelle aggregate per una query per ottenere i dati più aggiornati. Per ricostruire le tabelle per una query, seleziona l'opzione Ricostruisci tabelle derivate ed esegui dal menu a forma di ingranaggio Azioni di esplorazione.

Devi attendere il caricamento della query Esplora prima che questa opzione sia disponibile.

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

Per l'utente che avvia l'opzione Ricostruisci tabelle derivate ed esegui, la query attenderà la ricostruzione delle tabelle prima di caricare i risultati. Le query degli altri utenti continueranno a utilizzare le tabelle esistenti. Una volta ricreate le tabelle permanenti, tutti gli utenti le utilizzeranno.

Per ulteriori dettagli sull'opzione Ricostruisci tabelle derivate ed esegui, consulta la pagina della documentazione Tabelle derivate in Looker.

Risoluzione dei problemi

Come descritto nella sezione Determinare quale tabella aggregata viene utilizzata per una query, se ti trovi in modalità di sviluppo, puoi eseguire query in Esplora e fare clic sulla scheda SQL per visualizzare i commenti sulla tabella aggregata utilizzata per la query, se presenti.

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 non utilizzate, il commento inizierà con:

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

Ad esempio, ecco un commento sul motivo per cui la tabella aggregata sales_daily definita in order_items Esplora 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 non è possibile utilizzare una tabella aggregata, insieme ai passaggi che puoi eseguire per aumentare l'usabilità della tabella aggregata.

Aspetti da considerare

Aggregati simmetrici per le esplorazioni con unioni

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 come SUM DISTINCT, COUNT DISTINCT e AVERAGE DISTINCT, rispettivamente. Looker esegue questa operazione per evitare errori di calcolo della distribuzione. Ad esempio, una misura count viene visualizzata come tipo di misura count_distinct. Questo per evitare errori di calcolo del fanout per i join e fa parte della funzionalità di aggregazioni simmetriche di Looker. Per una spiegazione di questa funzionalità di Looker, consulta la pagina delle best practice sugli aggregati simmetrici.

La funzionalità di aggregazione simmetrica impedisce errori di calcolo, ma in alcuni casi può anche impedire l'utilizzo delle tabelle aggregate, pertanto è importante comprenderla.

Per i tipi di misura supportati dalla consapevolezza degli aggregati, questo vale per sum, count e average. Looker eseguirà il rendering di questi tipi di misure come DISTINCT se:

• La misura proviene dalla visualizzazione "uno" di un join molti-a-uno o uno-a-molti.
• La misura proviene da una delle due visualizzazioni di un join molti-a-molti.

Per una spiegazione di questi tipi di join, consulta la pagina della documentazione del parametro relationship.

Se noti che la tabella aggregata non viene utilizzata per questo motivo, puoi crearne una che corrisponda esattamente a una query di Esplora per utilizzare questi tipi di misura per un'esplorazione con unioni. Per ulteriori informazioni, consulta la sezione Creazione di tabelle aggregate che corrispondono esattamente alle query di Esplora in questa pagina.

Inoltre, se hai un dialetto SQL che supporta gli schizzi HyperLogLog, puoi aggiungere il parametro allow_approximate_optimization: yes alla misura. Quando una misura di conteggio è definita con allow_approximate_optimization: yes, Looker può utilizzarla per la consapevolezza aggregata, anche se viene visualizzata come conteggio distinto.

Consulta la pagina della documentazione del parametro allow_approximate_optimization per i dettagli e per un elenco dei dialetti SQL che supportano gli schizzi HyperLogLog.

Supporto dei dialetti per la consapevolezza aggregata

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

Supporto dei dialetti per la creazione incrementale di tabelle aggregate

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