Sensibilizzazione aggregata

Panoramica

Looker utilizza la logica di consapevolezza aggregata per trovare la tabella più piccola ed efficiente disponibile nel database per eseguire una query mantenendo la precisione.

Per le tabelle di grandi dimensioni nel database, gli sviluppatori di Looker possono creare tabelle aggregate di dati più piccole, raggruppate in base a varie combinazioni di attributi. Le tabelle aggregate fungono da aggregazioni o tabelle di riepilogo che Looker può utilizzare per le query, se possibile, anziché la grande tabella originale. Se implementata strategicamente, la consapevolezza aggregata può velocizzare la query media di diversi ordini di grandezza.

Ad esempio, potresti avere una tabella di dati su larga scala con una riga per ogni ordine effettuato sul tuo sito web. Da questo database, puoi creare una tabella aggregata con i totali giornalieri delle vendite. Se il tuo sito web riceve 1000 ordini ogni 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 possibili. Ad esempio:

  • Per una query sulle vendite mensili totali, Looker utilizza la tabella aggregata in base alle 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à, pertanto Looker recupera i risultati della query dalla tabella del database originale (orders_database). Tuttavia, se i tuoi utenti eseguono spesso questo tipo di query, puoi creare una tabella aggregata.
  • Per una query sulle vendite settimanali, non esiste una tabella aggregata settimanale, pertanto Looker utilizza la soluzione migliore successiva, ovvero la tabella aggregata basata sulle vendite giornaliere (sales_daily_aggregate_table).

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

Le tabelle aggregate non devono essere unite o aggiunte a un'esplorazione separata. Looker regola invece in modo dinamico la clausola FROM della query di esplorazione per accedere alla tabella aggregata migliore per la query. Ciò significa che le visualizzazioni dettagliate vengono mantenute e le esplorazioni possono essere consolidate. Con il riconoscimento degli aggregati, un'esplorazione può sfruttare automaticamente le tabelle aggregate, ma anche approfondire i dati granulari, se necessario.

Puoi anche utilizzare 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 Ottenere 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 per le tabelle di grandi dimensioni in un database. Le tabelle aggregate devono essere persistite nel database in modo che siano accessibili per la consapevolezza aggregata. 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 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 LookML da zero oppure recuperare il LookML della tabella aggregata da un'esplorazione o da una dashboard. Per informazioni dettagliate sul parametro aggregate_table e sui relativi sottoparametri, consulta la pagina della documentazione del parametro aggregate_table.

Progettazione di tabelle aggregate

Affinché una query di esplorazione possa utilizzare 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 di esplorazione sono un sottoinsieme dei campi della tabella aggregata (vedi la sezione Fattori dei campi in questa pagina). In alternativa, per gli intervalli di tempo, gli intervalli di tempo della query di esplorazione possono essere ricavati da quelli nella tabella aggregata (consulta la sezione Fattori relativi agli intervalli di tempo in questa pagina).
  • La query di esplorazione contiene tipi di misura supportati dalla notorietà aggregata (consulta la sezione Fattori del tipo di misura in questa pagina) oppure la query di esplorazione ha una tabella aggregata che corrisponde esattamente alle query di esplorazione (consulta la sezione Creare tabelle aggregate che corrispondono esattamente alle query di esplorazione in questa pagina).
  • Il fuso orario della query dell'esplorazione corrisponde a quello utilizzato dalla tabella aggregata (consulta la sezione Fattori relativi al fuso orario in questa pagina).
  • I filtri della query di esplorazione fanno riferimento a campi disponibili come dimensioni nella tabella aggregata oppure ciascuno dei filtri della query di esplorazione corrisponde a un filtro nella tabella aggregata (vedi la sezione Fattori di filtro in questa pagina).

Un modo per assicurarti 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 informazioni dettagliate, consulta la sezione Creare tabelle aggregate che corrispondono esattamente alle query di esplorazione 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à 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 contenere almeno A, B e D come dimensioni e C come misura.

La tabella aggregata può contenere anche altri campi, ma deve avere almeno i campi di query dell'esplorazione per essere valida per l'ottimizzazione. L'unica eccezione sono le dimensioni relative agli intervalli di tempo, poiché gli intervalli di tempo con una granularità più elevata possono essere ricavati da quelli con una granularità più fine.

A causa di 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 in un'altra esplorazione.

Fattori relativi al periodo di tempo

La logica di consapevolezza aggregata 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 dell'esplorazione. Ad esempio, una tabella aggregata basata su dati giornalieri può essere utilizzata per una query di esplorazione che richiede altri periodi di tempo, ad esempio query per dati giornalieri, mensili e annuali o addirittura per dati relativi a giorno del mese, giorno dell'anno e 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à sufficiente 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 potrà utilizzare la tabella aggregata per quella query.

Inoltre, la stessa logica si applica alle query con filtri relativi all'intervallo di tempo: una tabella aggregata può essere utilizzata per una query con un filtro relativo all'intervallo di tempo, a condizione che l'intervallo di tempo della tabella aggregata abbia una granularità più fine (o uguale) rispetto al filtro relativo all'intervallo di tempo utilizzato nella query dell'esplorazione. Ad esempio, una tabella aggregata con una dimensione relativa al periodo di tempo giornaliero può essere utilizzata per una query di esplorazione che filtra in base a giorno, settimana o mese.

Fattori del tipo di misura

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 alcuni tipi di misurazioni, come descritto nelle sezioni seguenti:

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 è se la query di esplorazione corrisponde esattamente a una query della 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 notorietà aggregata può essere utilizzata per le query di esplorazione che utilizzano misure con i seguenti tipi di misura:

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 notorietà aggregata perché puoi sommare più somme: una tabella aggregata di somme settimanali può essere sommata per ottenere una somma mensile accurata. Analogamente, è possibile utilizzare una misura con type: max perché è possibile utilizzare una tabella aggregata dei massimi giornalieri per trovare il massimo settimanale preciso.

Nel caso delle misure con type: average, la notorietà aggregata è supportata perché Looker utilizza i dati di somma e conteggio per dedurre con precisione i valori medi dalle tabelle aggregate.

Misure definite con espressioni SQL

La notorietà aggregata 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:

La notorietà aggregata è supportata per le 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 notorietà aggregata è 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) ;;
}

Inoltre, la consapevolezza aggregata è supportata per le misure in cui le operazioni MIN, MAX e CONTA 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 di LookML

Quando nelle misure vengono utilizzate espressioni sql, la notorietà aggregata supporta i seguenti tipi di riferimenti a 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 notorietà 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 della documentazione Incorporazione di SQL e riferimenti 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 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 conteggi distinti

In generale, i conteggi distinti non sono supportati con la notorietà aggregata perché non puoi ottenere dati accurati se provi ad aggregare conteggi distinti. Ad esempio, se stai conteggiando gli utenti distinti su un sito web, potresti trovare un utente che ha visitato il sito web due volte a tre settimane di distanza. Se provassi ad applicare una tabella aggregata settimanale per ottenere un conteggio mensile degli utenti distinti sul tuo sito web, l'utente verrebbe conteggiato due volte nella query di conteggio distinto mensile e i dati sarebbero errati.

Una soluzione alternativa consiste nel creare una tabella aggregata che corrisponda esattamente a una query di esplorazione, come descritto nella sezione Creare tabelle aggregate che corrispondono esattamente alle query di esplorazione di questa pagina. Quando la query dell'esplorazione e una query della tabella aggregata sono uguali, le misure di conteggio distinte forniscono dati accurati, pertanto possono essere utilizzate per la notorietà aggregata.

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

È noto che l'algoritmo HyperLogLog presenta un errore del 2% circa. Il parametro allow_approximate_optimization: yes richiede che gli sviluppatori di Looker confermino che è consentito utilizzare dati approssimativi per la misura in modo che la misura possa essere calcolata approssimativamente 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 relativi al fuso orario

In molti casi, gli amministratori dei database utilizzano UTC come fuso orario per i database. Tuttavia, molti utenti potrebbero non trovarsi nel fuso orario UTC. Looker offre più opzioni per convertire i 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 a quello delle query.
  • Fusi orari specifici degli utenti, in cui è possibile assegnare e selezionare i fusi orari singolarmente per gli utenti. 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 dedicata all'uso 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 o filtri 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 query della connessione al database è impostato sullo stesso fuso orario del fuso orario del database.
  • La connessione al database non ha un fuso orario delle query specificato né fusi orari specifici per 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 possibili query, in modo che la tabella aggregata abbia maggiori probabilità di essere utilizzata:

  • Se la connessione al database utilizza un unico fuso orario per le query, devi associare 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, ciascuna con un valore timezone diverso per corrispondere ai possibili fusi orari dei tuoi utenti.

Filtra fattori

Fai attenzione quando includi i filtri nella tabella aggregata. I filtri in una tabella aggregata possono restringere i risultati al punto che la tabella aggregata non è utilizzabile. Ad esempio, supponiamo che tu crei una tabella aggregata per il conteggio degli ordini giornalieri 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 il conteggio giornaliero 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 limitato per essere utilizzata dalla query di esplorazione.

Inoltre, tieni presente i filtri che gli sviluppatori di Looker potrebbero aver incorporato nell'esplorazione, ad esempio:

  • access_filters: applica limitazioni ai dati specifiche per utente.
  • always_filter: richiede 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 rimuoverlo del tutto.
  • conditionally_filter: definisce un insieme di filtri predefiniti che gli utenti possono sostituire se applicano almeno un filtro da un secondo elenco definito anche nell'esplorazione.

Questi tipi di filtro si basano su campi specifici. Se l'esplorazione contiene questi filtri, devi includerne i campi nel parametro dimensions di aggregate_table.

Ad esempio, di seguito è riportata 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 seguente, 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 dell'esplorazione. Di conseguenza, Looker può comunque utilizzare la tabella aggregata per le query dell'esplorazione, anche se l'esplorazione ha un filtro di accesso.

Questo 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 notorietà 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 gli stessi valori di filtro nella query di esplorazione e nella tabella aggregata.

Creazione di tabelle aggregate che corrispondono esattamente alle query di esplorazione

Un modo per assicurarti 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 di esplorazione e la tabella aggregata utilizzano entrambe le stesse misure, dimensioni, filtri, fusi orari e altri parametri, per definizione i risultati della tabella aggregata verranno applicati alla query di esplorazione. Se una tabella aggregata corrisponde esattamente a una query di esplorazione, Looker è in grado di utilizzare tabelle aggregate che includono qualsiasi tipo di misura.

Puoi creare una tabella aggregata da un'esplorazione utilizzando l'opzione Recupero LookML nel menu a forma di ingranaggio di un'esplorazione. Puoi anche creare corrispondenze esatte per tutti i riquadri di una dashboard utilizzando l'opzione Recupero 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 vengono utilizzate da Looker prima di inviarle in produzione.

Ad esempio, in base all'esempio di tabella aggregata mensile mostrato in precedenza, puoi andare all'esplorazione 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 sei in modalità di 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 le 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 eventuali commenti che potresti visualizzare nella scheda SQL e suggerimenti su come risolverli.

Stime del risparmio computazionale per la notorietà 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 computazionale derivante dall'utilizzo della tabella aggregata anziché eseguire query direttamente sul database. Il risparmio aggregato in termini di notorietà viene mostrato 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 Determinare quale tabella aggregata viene utilizzata per una query di questa pagina della 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 per la notorietà viene mostrato per le connessioni al database abilitate per 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ò union i dati aggiornati nella tabella aggregata. Potresti avere una tabella aggregata che include i dati degli ultimi tre giorni, ma che potrebbe essere stata creata ieri. Nella tabella aggregata mancheranno le informazioni di oggi, quindi non dovresti 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é eseguirà una query sui dati più recenti, quindi unirà questi 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 della data del filtro della data.

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 a quelli della tabella aggregata. Ciò significa che i tuoi utenti riceveranno i dati più recenti, ottimizzando al contempo il rendimento utilizzando la notorietà 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 i dati più recenti non inclusi nella tabella aggregata.

Le tabelle aggregate devono essere permanenti

Per essere accessibile per la consapevolezza aggregata, la tabella aggregata deve essere memorizzata 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), hanno gli stessi requisiti delle tabelle PDT. Per informazioni dettagliate, consulta la pagina della documentazione dedicata alle tabelle derivate in Looker.

Puoi creare PDT incrementali nel tuo progetto se il dialetto li supporta. Looker crea PDT incrementali aggiungendo nuovi dati alla tabella, anziché ricostruirla nella sua interezza. Poiché le tabelle aggregate sono a loro volta 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 autorizzazione develop può ignorare le impostazioni di persistenza e ricreare 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 esplorazione.

Devi attendere il caricamento della query di esplorazione 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é eventuali tabelle derivate a cui fanno riferimento 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 ricostruite, tutte le tabelle persistenti verranno utilizzate da tutti gli utenti.

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

Risoluzione dei problemi

Come descritto nella sezione Determinare quale tabella aggregata viene utilizzata per una query, se sei in modalità di sviluppo, puoi eseguire query sull'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 non utilizzate, il commento inizierà con:

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

Ad esempio, di seguito è riportato 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 non è possibile utilizzare una tabella aggregata, oltre ai passaggi che puoi svolgere per aumentarne l'usabilità.

Motivo per cui non utilizzare la tabella aggregata Spiegazione e possibili passaggi
Nessun campo di questo tipo nell'esplorazione. Esiste un errore di tipo di convalida di LookML. Molto probabilmente la causa del problema è che la tabella aggregata non è stata definita correttamente o che è presente un errore ortografico nel LookML della tabella aggregata. Un probabile colpevole è 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. Per ulteriori informazioni su come definire una tabella aggregata, consulta la pagina della documentazione del 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 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à la tabella di base. Per informazioni dettagliate, consulta la sezione Fattori del campo in questa pagina. L'unica eccezione sono le dimensioni relative agli intervalli di tempo, poiché gli intervalli di tempo con una granularità più elevata possono essere ricavati da quelli con una granularità più fine.

Per risolvere il problema, verifica che i campi della query di esplorazione siano inclusi nella definizione della tabella aggregata.
La query conteneva i seguenti filtri che non erano inclusi come campi né corrispondevano esattamente ai filtri nella tabella aggregata. I filtri nella query di esplorazione 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 alla tabella aggregata il campo utilizzato dal filtro.
  • Rimuovi i filtri dalla query di esplorazione.
Per maggiori dettagli, 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 misura non supportati per la notorietà aggregata, ad esempio conteggio distinto, media 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 l'esplorazione contiene unioni, verifica che le misure non vengano convertite in misure distinte (aggregate simmetriche) tramite unioni a ventaglio. Per una spiegazione, consulta la sezione Aggregati simmetrici per le esplorazioni con join in questa pagina.
Una tabella aggregata diversa era più adatta per l'ottimizzazione. Esistono più tabelle aggregate valide per la query e Looker ha trovato una tabella aggregata più ottimale da utilizzare. In questo caso non devi 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 ne impedisce l'utilizzo di una clausola GROUP BY e, pertanto, Looker non può utilizzare alcuna tabella aggregata per la query.

Per risolvere il problema, verifica che il parametro primary_key della visualizzazione e il parametro cancel_grouping_fields dell'esplorazione siano configurati correttamente.
La tabella aggregata conteneva filtri non presenti nella query. La tabella aggregata ha un filtro non relativo al tempo che non è presente nella query.

Per risolvere il problema, puoi rimuovere il filtro dalla tabella aggregata. Per maggiori dettagli, consulta la sezione Fattori di filtro in questa pagina.
Un campo è definito come campo solo con filtri nella query di esplorazione, ma è elencato nel parametro dimensions della tabella aggregata. Il parametro dimensions della tabella aggregata elenca un campo definito solo come campo filter nella query di esplorazione.

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 limite. Se vedi questo messaggio per una query di esplorazione utilizzata di frequente, puoi creare una tabella aggregata che corrisponda esattamente alla query di esplorazione. Puoi ottenere facilmente il LookML della tabella aggregata da un'esplorazione, come descritto nella pagina del parametro aggregate_table.

Aspetti da considerare

Aggregati simmetrici per le esplorazioni con unioni

Un aspetto importante da notare è che in un'esplorazione che unisce più tabelle di database, Looker può visualizzare le 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 del fanout. Ad esempio, una misura count viene visualizzata come tipo di misura count_distinct. Questo serve a evitare errori di calcolo del fanout per le unioni e fa parte della funzionalità degli aggregati simmetrici di Looker. Per una spiegazione di questa funzionalità di Looker, consulta la pagina Best practice sugli aggregati simmetrici.

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

Per i tipi di misura supportati dalla notorietà 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 del parametro relationship.

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

Inoltre, se hai un dialetto SQL che supporta gli sketch 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 notorietà aggregata, anche se viene visualizzata come conteggio distinto.

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

Supporto dei dialetti per la notorietà aggregata

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

Dialetto Supportato?
Actian Avalanche
Sì
Amazon Athena
Sì
Amazon Aurora MySQL
Sì
Amazon Redshift
Sì
Apache Druid
No
Apache Druid 0.13 e versioni successive
No
Apache Druid 0.18 o versioni successive
No
Apache Hive 2.3 e versioni successive
Sì
Apache Hive 3.1.2 e versioni successive
Sì
Apache Spark 3 e versioni successive
Sì
ClickHouse
No
Cloudera Impala 3.1 e versioni successive
Sì
Cloudera Impala 3.1 e 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ì
Fulmine
No
SQL precedente di Google BigQuery
Sì
SQL standard di Google BigQuery
Sì
PostgreSQL di Google Cloud
Sì
Google Cloud SQL
No
Google Spanner
No
Greenplum
Sì
HyperSQL
No
IBM Netezza
Sì
MariaDB
Sì
Microsoft Azure PostgreSQL
Sì
Database SQL di Microsoft Azure
Sì
Microsoft Azure Synapse Analytics
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 e versioni successive
Sì
Oracle
Sì
Oracle ADWC
Sì
PostgreSQL 9.5 e versioni successive
Sì
PostgreSQL precedente alla versione 9.5
Sì
PrestoDB
Sì
PrestoSQL
Sì
SAP HANA 2 e versioni successive
Sì
SingleStore
Sì
SingleStore 7 e versioni successive
Sì
Snowflake
Sì
Teradata
Sì
Trino
Sì
Vettoriale
Sì
Vertica
Sì

Supporto dei dialetti per la creazione incrementale di tabelle aggregate

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

Dialetto Supportato?
Actian Avalanche
No
Amazon Athena
No
Amazon Aurora MySQL
No
Amazon Redshift
Sì
Apache Druid
No
Apache Druid 0.13 e versioni successive
No
Apache Druid 0.18 o versioni successive
No
Apache Hive 2.3 e versioni successive
No
Apache Hive 3.1.2 e versioni successive
No
Apache Spark 3 e versioni successive
No
ClickHouse
No
Cloudera Impala 3.1 e versioni successive
No
Cloudera Impala 3.1 e 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
Fulmine
No
SQL precedente di Google BigQuery
No
SQL standard di Google BigQuery
Sì
PostgreSQL di Google Cloud
Sì
Google Cloud SQL
No
Google Spanner
No
Greenplum
Sì
HyperSQL
No
IBM Netezza
No
MariaDB
No
Microsoft Azure PostgreSQL
Sì
Database SQL di Microsoft Azure
No
Microsoft Azure Synapse Analytics
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 e versioni successive
Sì
Oracle
No
Oracle ADWC
No
PostgreSQL 9.5 e versioni successive
Sì
PostgreSQL precedente alla versione 9.5
Sì
PrestoDB
No
PrestoSQL
No
SAP HANA 2 e versioni successive
No
SingleStore
No
SingleStore 7 e versioni successive
No
Snowflake
Sì
Teradata
No
Trino
No
Vettoriale
No
Vertica
Sì