Consapevolezza aggregata

Panoramica

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

Per tabelle molto grandi nel database, gli sviluppatori di Looker possono creare tabelle aggregate più piccole, 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 quando possibile, al posto della tabella di grandi dimensioni originale. Se implementata in modo strategico, la consapevolezza degli aggregati può accelerare la query media per ordini di grandezza.

Ad esempio, potresti avere una tabella di dati dell'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 presenterebbe ogni giorno con 999 righe in meno rispetto alla tabella originale. Puoi creare un'altra tabella aggregata con i totali delle vendite mensili che saranno ancora più efficienti. Perciò ora, se un utente esegue una query per le vendite giornaliere o settimanali, Looker utilizzerà la tabella totale delle vendite giornaliere. Se un utente esegue una query sulle vendite annuali e non disponi di una tabella aggregata annuale, Looker utilizzerà l'opzione migliore successivamente, ovvero la tabella aggregata delle vendite mensili di questo esempio.

Looker risponde alle domande degli utenti con le tabelle aggregate più piccole 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 questo livello di granularità, pertanto Looker riceve i risultati della query dalla tabella di database originale (orders_database). Tuttavia, se i tuoi utenti eseguono spesso questo tipo di query, potresti creare una tabella aggregata per tale query.
  • Per una query sulle vendite settimanali, non esiste una tabella aggregata settimanale, per cui Looker utilizza l'opzione migliore, ovvero la tabella aggregata basata sulle vendite giornaliere (sales_daily_aggregate_table).

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

Le tabelle aggregate non devono essere unite o aggiunte a un'esplorazione separata. Invece, Looker regola dinamicamente la clausola FROM della query Esplora per accedere alla tabella aggregata migliore per la query. Ciò significa che i livelli vengono mantenuti e le esplorazioni possono essere consolidate. Con il riconoscimento degli aggregati, un'esplorazione può sfruttare automaticamente le tabelle aggregate, ma continuare a approfondire i dati granulari se necessario.

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 enormi. Per maggiori dettagli, consulta la sezione Recupero del LookML della tabella aggregata da una dashboard nella pagina della documentazione del parametro aggregate_table.

Aggiunta di tabelle aggregate al progetto in corso...

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 persiste nel database in modo che possano essere accessibili per il rilevamento degli aggregati. 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 Esplorazione utilizzi una tabella aggregata, quest'ultima deve essere in grado di fornire dati accurati per la query Esplorazione. Looker può utilizzare una tabella aggregata per una query di esplorazione se tutte le seguenti condizioni sono vere:

  • I campi della query Esplora sono un sottoinsieme dei campi della tabella aggregata (consulta la sezione Fattori di campo in questa pagina). In alternativa, per gli intervalli di tempo, i periodi di tempo della query Esplora possono essere ricavati dagli intervalli di tempo nella tabella aggregata (consulta la sezione Fattori di tempo in questa pagina).
  • La query Esplora contiene tipi di misure supportati dal rilevamento degli aggregati (consulta la sezione Misurare i fattori di tipo in questa pagina) oppure la query Esplora ha una tabella aggregata con una corrispondenza esatta (consulta la sezione Creare tabelle aggregate che corrispondono esattamente alle query Esplora in questa pagina).
  • Il fuso orario della query Esplora corrisponde al fuso orario utilizzato dalla tabella aggregata (consulta la sezione Fattori di 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 è creare una tabella aggregata che corrisponda esattamente a una query di esplorazione. Per maggiori dettagli, consulta la sezione Creare tabelle aggregate che corrispondono esattamente alle query Esplora in questa pagina.

Fattori di campo

Per essere utilizzata per una query di esplorazione, una tabella aggregata deve avere 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 Esplora contiene una dimensione o una misura che non si trova in una tabella aggregata, Looker non può utilizzare la tabella aggregata e userà invece la tabella di base.

Ad esempio, se una query raggruppa per le dimensioni A e B, aggrega per 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ò avere anche altri campi, ma per poter essere ottimizzata deve contenere almeno i campi di query Esplora. L'unica eccezione sono le dimensioni dei periodi di tempo, poiché intervalli di tempo con granularità più bassa possono essere ricavati da periodi con granularità più fine.

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

Fattori di tempo

La logica di rilevamento degli aggregati di Looker è in grado di ricavare un periodo di tempo da un altro. Una tabella aggregata può essere utilizzata per una query purché il periodo di tempo della tabella aggregata abbia una granularità più fine (o uguale) rispetto alla query di esplorazione. Ad esempio, è possibile utilizzare una tabella aggregata basata su dati giornalieri per una query Esplora che richiede altri periodi di tempo, ad esempio 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 sono sufficientemente granulari per la query Esplora.

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

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

Misurare i fattori relativi al tipo di misurazione

Affinché una query Esplora utilizzi una tabella aggregata, le misure in quest'ultima 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:

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

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

Misure con tipi di misure supportati

L'awareness degli aggregati può essere utilizzata per le query Esplora che utilizzano misure con questi tipi di misure:

di Gemini Advanced.

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 Esplora. Ad esempio, puoi utilizzare una misura con type: sum per il rilevamento aggregato perché puoi sommare diverse somme. È possibile sommare una tabella aggregata di somme settimanali per ottenere una somma mensile accurata. Analogamente, è possibile utilizzare una misura con type: max perché è possibile utilizzare una tabella aggregata di valori massimi giornalieri per trovare il massimo settimanale accurato.

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

Misure definite con espressioni SQL

L'awareness degli aggregati può essere utilizzata anche con misure definite con espressioni nel parametro sql. Quando vengono definiti con espressioni SQL, sono supportati anche i seguenti tipi di misure:

L'awareness aggregata è supportata per misure definite come combinazioni di altre misure, come questo esempio:

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

L'awareness degli aggregati è 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 degli aggregati è supportato per 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 nelle misure vengono utilizzate espressioni sql, il riconoscimento degli aggregati supporta i seguenti tipi di riferimenti di campo:

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

Il riconoscimento degli aggregati non è supportato per le misure definite utilizzando il formato ${TABLE}.column_name, che indica una colonna in una tabella. (consulta la pagina della documentazione Incorporare SQL e fare riferimento agli oggetti LookML per una panoramica sull'utilizzo dei riferimenti in 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, come questa:


 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 conteggi distinti

In generale, i conteggi distinti non sono supportati con il rilevamento aggregato perché non puoi ottenere dati precisi se provi a aggregare i conteggi distinti. Ad esempio, se conteggi i singoli utenti su un sito web, è possibile che un utente abbia visitato il sito due volte, a tre settimane di distanza. Se provassi ad applicare una tabella aggregata settimanale per ottenere un conteggio mensile di utenti distinti sul sito web, quell'utente verrebbe conteggiato due volte nella query di conteggio mensile distinto e i dati non sarebbero corretti.

Una soluzione alternativa a questo problema è creare una tabella aggregata che corrisponda esattamente a una query Esplora, come descritto nella sezione Creazione di tabelle aggregate che corrispondono esattamente a query di esplorazione in questa pagina. Quando la query Esplora e una query sulla tabella aggregata sono le stesse, le misure di conteggio distinte forniscono dati accurati e possono quindi essere utilizzate per rilevare gli aggregati.

Un'altra opzione è l'utilizzo di 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 ha un errore di circa il 2%. Il parametro allow_approximate_optimization: yes richiede agli sviluppatori di Looker di accettare l'utilizzo di dati approssimativi per la misura, in modo che quest'ultima possa essere calcolata approssimativamente dalle tabelle aggregate.

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

Fattori del fuso orario

In molti casi, gli amministratori di database utilizzano il fuso orario UTC come fuso orario per i database. Tuttavia, molti utenti potrebbero non utilizzare il fuso orario UTC. Looker offre più 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 singola per la query, in modo che tutte le query vengano convertite dal fuso orario del database al fuso orario della query.
  • Fusi orari specifici dell'utente, a cui è possibile assegnare i singoli utenti e selezionare i fusi orari individualmente. In questo caso, le query vengono convertite dal fuso orario del database a quello del singolo utente.

Per ulteriori informazioni su queste opzioni, consulta la pagina della documentazione Utilizzo delle impostazioni del fuso orario.

Questi concetti sono importanti per comprendere il riconoscimento degli aggregati poiché, affinché una tabella aggregata possa essere utilizzata per una query con dimensioni di data o filtri di 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 un valore timezone. La connessione al database utilizzerà anche il fuso orario del database se una delle seguenti condizioni è vera:

  • Il tuo database non supporta i fusi orari.
  • Il fuso orario delle 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 specificato per le query 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 da corrispondere alle query possibili in modo che sia più probabile che venga utilizzata:

  • Se la connessione al database utilizza un fuso orario con una singola query, devi far corrispondere il valore timezone della tabella aggregata con il 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 base ai possibili fusi orari dei tuoi utenti.
di Gemini Advanced.

Fattori di filtro

Fai attenzione quando includi filtri nella tabella aggregata. I filtri su 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 filtri solo per 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 questa query, poiché quest'ultima contiene solo i dati relativi all'Australia. La tabella aggregata filtra i dati in modo troppo restrittivo per essere utilizzati dalla query Esplora.

Inoltre, tieni presente i filtri che gli sviluppatori di Looker potrebbero aver integrato nella tua esplorazione, ad esempio:

  • access_filters: applica restrizioni relative ai dati specifici dell'utente.
  • always_filter: richiede agli utenti di includere un determinato insieme di filtri per una query 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 di un secondo elenco definito anche in Esplora.

Questi tipi di filtri si basano su campi specifici. Se l'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, questa 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 viene 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 Esplora. Di conseguenza, Looker può comunque utilizzare la tabella aggregata per le query dell'esplorazione, anche se quest'ultima ha 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 trasmette i filtri specificati di una query Esplora alla sottoquery della tabella derivata nativa. Nel caso del rilevamento degli aggregati, se la query Esplora richiede una tabella derivata nativa che utilizza bind_filters, la query Esplora può utilizzare una tabella aggregata solo se tutti i campi utilizzati nel parametro bind_filters della tabella derivata nativa hanno esattamente gli stessi valori del filtro nella query Esplora e nella tabella aggregata.

Creazione di tabelle aggregate che corrispondono esattamente alle query Esplora

Un modo per assicurarsi che una tabella aggregata possa essere utilizzata per una query di esplorazione è creare una tabella aggregata che corrisponda esattamente alla query di esplorazione. 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 Esplora, Looker è in grado di utilizzare le tabelle aggregate che includono qualsiasi tipo di misura.

Puoi creare una tabella aggregata da un'esplorazione utilizzando l'opzione Ottieni LookML dal menu con l'ingranaggio di un'esplorazione. Puoi anche creare corrispondenze esatte per tutti i riquadri di una dashboard utilizzando l'opzione Ottieni LookML dal menu con l'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 mostrati anche in modalità di sviluppo, in modo che gli sviluppatori possano testare nuove tabelle aggregate per vedere in che modo Looker le utilizza prima di eseguire il push di nuove tabelle in produzione.

Ad esempio, in base all'esempio di tabella aggregata mensile mostrata in precedenza, puoi andare su 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à sviluppo, Looker mostra i commenti per indicare la tabella aggregata utilizzata per la query.

Dai seguenti commenti sulla scheda SQL, possiamo vedere che Looker utilizza la tabella aggregata sales_monthly per questa query, nonché 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 di questa pagina per conoscere i possibili commenti nella scheda SQL e i suggerimenti su come risolverli.

Stime dei risparmi sul calcolo per il rilevamento degli aggregati

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 di calcolo derivanti dall'uso della tabella aggregata anziché dall'esecuzione di query direttamente sul database. I risparmi sul rilevamento degli aggregati 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 verrà utilizzata per la query, puoi fare clic sulla scheda SQL, come descritto nella sezione Determinazione della tabella aggregata utilizzata per una query di questa pagina della documentazione.

Una volta eseguita la query, la finestra Esplora mostra la tabella aggregata utilizzata per rispondere alla query accanto al pulsante Esegui.

I risparmi relativi al rilevamento aggregato vengono mostrati per le connessioni ai database abilitate per le stime dei costi. Consulta la sezione Esplorazione dei dati in Looker per saperne di più.

Looker unisce i nuovi dati alle tabelle aggregate

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

Tuttavia, Looker può comunque utilizzare i dati della tabella aggregata per la query perché eseguirà una query sui dati più recenti, per poi unirli ai risultati della tabella aggregata.

Looker può unire 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 unirà i risultati nuovi a quelli della tabella aggregata. Ciò significa che gli utenti riceveranno i dati più recenti pur continuando a ottimizzare 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.

Le tabelle aggregate devono essere rese persistenti

Per essere accessibile per il rilevamento degli aggregati, 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 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 tuo progetto se il tuo dialetto le supporta. Looker crea PDT incrementali aggiungendo dati aggiornati alla tabella, invece di ricrearla nella sua interezza. Poiché le tabelle aggregate sono a loro volta un tipo di PDT, puoi anche creare tabelle aggregate incrementali. Per saperne di più 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ò ignorare le impostazioni di persistenza e ricreare tutte le tabelle aggregate per una query al fine di ottenere i dati più aggiornati. Per ricreare le tabelle per una query, seleziona Ricrea le tabelle derivate e Esegui dal menu a forma di ingranaggio Esplora azioni.

Devi attendere il caricamento della query Esplora affinché questa opzione sia disponibile.

La sezione Ricrea le tabelle derivate e 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 la procedura Ricrea le tabelle derivate e Esegui, la query attenderà che le tabelle vengano ricreate prima di caricare i risultati. Altri utenti utilizzeranno comunque le tabelle esistenti. Una volta ricreate le tabelle permanenti, tutti gli utenti utilizzeranno le tabelle create di nuovo.

Consulta la pagina della documentazione Le tabelle derivate in Looker per ulteriori dettagli su come Ricreare tabelle derivate e Esegui.

Risoluzione dei problemi

Come descritto nella sezione Determinazione della tabella aggregata utilizzata per una query, se sei in modalità 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, in questo 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 tabella seguente mostra altri possibili motivi per cui una tabella aggregata non può essere utilizzata, insieme ai passaggi da seguire per migliorarne l'usabilità.

Motivo per il mancato utilizzo della tabella aggregata Spiegazione e possibili passaggi
Campo non presente in Esplora. Si è verificato un errore del tipo di convalida LookML. Probabilmente questo è dovuto al fatto che la tabella aggregata non sia stata definita correttamente o che c'era un errore di battitura in LookML per la tabella aggregata. Una probabile causa è il nome di un campo errato o simili.

Per risolvere il problema, verifica che le dimensioni e le misure nella tabella aggregata corrispondano ai nomi dei campi in Esplora. Per ulteriori informazioni su come definire una tabella aggregata, consulta la pagina della documentazione relativa al parametro aggregate_table.
La tabella aggregata non include i seguenti campi nella query. Per essere utilizzata per una query di esplorazione, una tabella aggregata deve avere 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 Esplora contiene una dimensione o una misura che non si trova in una tabella aggregata, Looker non può utilizzare la tabella aggregata e userà invece la tabella di base. Per informazioni dettagliate, consulta la sezione Fattori dei campi in questa pagina. L'unica eccezione sono le dimensioni dei periodi di tempo, poiché intervalli di tempo con granularità più bassa possono essere ricavati da periodi con granularità più fine.

Per risolvere questo 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é corrispondenti esattamente ai filtri nella tabella aggregata. I filtri nella query Esplora impediscono a Looker di utilizzare la tabella aggregata.

Per risolvere il problema, puoi procedere in uno dei seguenti modi:
  • Aggiungi lo stesso filtro alla tabella aggregata.
  • Aggiungi il campo utilizzato dal filtro alla tabella aggregata.
  • Rimuovi i filtri dalla query Esplora.
di Gemini Advanced. Per informazioni dettagliate, consulta la sezione Fattori filtro di questa pagina.
La query contiene le seguenti misure che non è possibile aggregare. La query contiene uno o più tipi di misure non supportati per il riconoscimento aggregato, come 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 misure supportati. Inoltre, se l'esplorazione ha join, verifica che le misure non vengano convertite in misure distinte (aggregati simmetrici) tramite join con fan-out. Per una spiegazione, consulta la sezione Aggregazioni simmetriche per le esplorazioni con join di 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. Non è necessario fare nulla in questo caso.
Looker non ha eseguito alcun raggruppamento (a causa di un parametro primary_key o cancel_grouping_fields), pertanto la query non può essere raggruppata. La query fa riferimento a una dimensione che impedisce di avere una clausola GROUP BY, pertanto Looker non può utilizzare alcuna tabella aggregata per la query.

Per risolvere il problema, verifica che il parametro primary_key della vista e il parametro cancel_grouping_fields di Esplora siano configurati 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 filtro di questa pagina.
Un campo è definito come campo con solo filtri nella query Esplora, ma è 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 la tabella aggregata non è stata utilizzata. Questo commento è riservato ai casi d'angolo. Se visualizzi questo messaggio per una query Esplora utilizzata spesso, puoi creare una tabella aggregata che corrisponde esattamente alla query Esplora. Puoi ottenere facilmente il LookML della tabella aggregata da un'esplorazione, come descritto nella pagina del parametro aggregate_table.

Aspetti da considerare

Dati aggregati simmetrici per 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 con fanout errato. Ad esempio, una misura count viene visualizzata come un tipo di misura count_distinct. Ciò consente di evitare calcoli errati del fanout per i join e fa parte della funzionalità degli aggregati simmetrici di Looker. Per una spiegazione di questa funzionalità di Looker, consulta la pagina delle best practice sugli aggregati simmetrici.

La funzionalità degli aggregati simmetrici impedisce i calcoli errati, ma può anche impedire l'utilizzo delle tabelle aggregate in determinati casi, perciò è importante comprenderlo.

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

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

Se noti che la tua tabella aggregata non viene utilizzata per questo motivo, puoi crearne una che corrisponda esattamente a una query Esplora per utilizzare questi tipi di misure per un'esplorazione con join. Per ulteriori informazioni, consulta la sezione Creare tabelle aggregate che corrispondono esattamente alle query 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 viene definita con allow_approximate_optimization: yes, Looker può utilizzare la misura per il rilevamento aggregato, anche se viene visualizzato come conteggio distinto.

Consulta la pagina della documentazione del parametro allow_approximate_optimization per ulteriori dettagli e per un elenco di quali dialetti SQL supportano gli schizzi HyperLogLog.

Supporto dei dialetti per la consapevolezza dei dati aggregati

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

Dialetto Supportata?
Valanga Actia
Sì
Amazon Athena
Sì
Amazon Aurora MySQL
Sì
Amazon Redshift
Sì
Druid Apache
No
Apache Druid 0.13 o versioni successive
No
Apache Druid 0.18 o versioni successive
No
Apache Hive 2.3 o 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 o versioni successive 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
Greenplum
Sì
HyperSQL
No
Netezza di IBM
Sì
MariaDB
Sì
PostgreSQL Microsoft Azure
Sì
Database SQL di Microsoft Azure
Sì
Microsoft Azure Synapse Analytics
Sì
Microsoft SQL Server 2008 e versioni successive
Sì
Microsoft SQL Server 2012 o versioni successive
Sì
Microsoft SQL Server 2016
Sì
Microsoft SQL Server 2017 o versioni successive
Sì
MongoBI
No
MySQL
Sì
MySQL 8.0.12 o versioni successive
Sì
Oracle
Sì
Oracle ADWC
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+
Sì
Snowflake
Sì
Teradata
Sì
Trino
Sì
Vettoriale
Sì
Vertica
Sì

Supporto dei dialetti per la creazione incrementale di tabelle aggregate

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

Dialetto Supportata?
Valanga Actia
No
Amazon Athena
No
Amazon Aurora MySQL
No
Amazon Redshift
Sì
Druid Apache
No
Apache Druid 0.13 o versioni successive
No
Apache Druid 0.18 o versioni successive
No
Apache Hive 2.3 o 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 o versioni successive 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
Greenplum
Sì
HyperSQL
No
Netezza di IBM
No
MariaDB
No
PostgreSQL Microsoft Azure
Sì
Database SQL di Microsoft Azure
No
Microsoft Azure Synapse Analytics
Sì
Microsoft SQL Server 2008 e versioni successive
No
Microsoft SQL Server 2012 o versioni successive
No
Microsoft SQL Server 2016
No
Microsoft SQL Server 2017 o versioni successive
No
MongoBI
No
MySQL
Sì
MySQL 8.0.12 o versioni successive
Sì
Oracle
No
Oracle ADWC
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+
No
Snowflake
Sì
Teradata
No
Trino
No
Vettoriale
No
Vertica
Sì