Tutorial sulla notorietà aggregata

Per ulteriori dettagli, consulta la pagina della documentazione relativa alla consapevolezza aggregata.

Introduzione

Questa pagina è una guida per l'implementazione della consapevolezza aggregata in uno scenario pratico, inclusa l'identificazione delle opportunità di implementazione, il valore generato dalla consapevolezza aggregata e un semplice flusso di lavoro per l'implementazione in un modello reale. Questa pagina non fornisce una spiegazione approfondita di tutte le funzionalità di consapevolezza aggregata o dei casi limite, né è un catalogo esaustivo di tutte le sue funzionalità.

Che cos'è la notorietà aggregata?

In Looker, esegui principalmente query su tabelle o viste non elaborate nel database. A volte si tratta di tabelle derivate permanenti (PDT) di Looker.

Spesso potresti riscontrare set di dati o tabelle molto grandi che, per essere performanti, richiedono tabelle di aggregazione o aggregazioni.

In genere, puoi creare tabelle di aggregazione come una tabella orders_daily contenente una dimensionalità limitata. Questi devono essere trattati e modellati separatamente nell'esplorazione e non si inseriscono correttamente nel modello. Queste limitazioni comportano esperienze utente scadenti quando l'utente deve scegliere tra più esplorazioni per gli stessi dati.

Ora, con la consapevolezza aggregata di Looker, puoi pre-costruire tabelle aggregate a vari livelli di granularità, dimensionalità e aggregazione e puoi indicare a Looker come utilizzarle all'interno delle esplorazioni esistenti. Le query utilizzeranno quindi queste tabelle di aggregazione dove Looker ritiene opportuno, senza alcun input dell'utente. In questo modo, ridurrai le dimensioni delle query, i tempi di attesa e migliorerai l'esperienza utente.

NOTA: le tabelle aggregate di Looker sono un tipo di tabella derivata permanente (PDT). Ciò significa che le tabelle aggregate hanno gli stessi requisiti di database e connessione dei PDT.

Per verificare se il dialetto del database e la connessione a Looker possono supportare le tabelle PDT, consulta i requisiti elencati nella pagina della documentazione Tabelle derivate in Looker.

Per verificare se il tuo dialetto del database supporta la conoscenza aggregata, consulta la pagina della documentazione Conoscenza aggregata.

Il valore della notorietà aggregata

Esistono una serie di proposte di valore significative che aggregano le offerte di consapevolezza per generare un valore aggiuntivo dal tuo modello Looker esistente:

• Miglioramento delle prestazioni: l'implementazione della consapevolezza aggregata velocizzerà le query degli utenti. Looker utilizzerà una tabella più piccola se contiene i dati necessari per completare la query dell'utente.
• Risparmio sui costi:alcuni dialetti addebitano in base alle dimensioni della query su un modello di consumo. Se fai in modo che Looker esegua query su tabelle più piccole, il costo per query utente sarà ridotto.
• Miglioramento dell'esperienza utente: oltre a un'esperienza migliorata che recupera le risposte più velocemente, il consolidamento elimina la creazione di esplorazioni ridondanti.
• Impronta di LookML ridotta: la sostituzione delle strategie di consapevolezza aggregate esistenti basate su Liquid con un'implementazione nativa flessibile comporta una maggiore resilienza e un numero inferiore di errori.
• Possibilità di sfruttare il LookML esistente: le tabelle aggregate utilizzano l'oggetto query, che riutilizza la logica modellata esistente anziché duplicarla con SQL personalizzato esplicito.

Esempio di base

Ecco un'implementazione molto semplice in un modello Looker per dimostrare quanto può essere leggera la consapevolezza aggregata. Data una tabella ipotetica flights nel database con una riga per ogni volo registrato tramite la FAA, possiamo modellare questa tabella in Looker con la relativa visualizzazione ed esplorazione. Ecco il codice LookML di una tabella aggregata che possiamo definire per l'esplorazione:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Con questa tabella aggregata, un utente può eseguire query sull'esplorazione flights e Looker utilizzerà automaticamente la tabella aggregata definita in LookML per rispondere alle query. L'utente non dovrà comunicare a Looker alcuna condizione speciale: se la tabella è adatta ai campi selezionati dall'utente, Looker la utilizzerà.

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. Ecco un esempio di scheda SQL di Looker per una query che utilizza la tabella aggregata flights:flights_by_week_and_carrier in teach_scratch:

Per informazioni dettagliate su come determinare se le tabelle aggregate vengono utilizzate per una query, consulta la pagina della documentazione Riconoscimento degli aggregati.

Identificazione delle opportunità

Per massimizzare i vantaggi della notorietà aggregata, devi identificare dove la notorietà aggregata può svolgere un ruolo nell'ottimizzazione o nell'incremento del valore della notorietà aggregata.

Identificare le dashboard con un tempo di esecuzione elevato

Un'ottima opportunità per il riconoscimento degli aggregati è creare tabelle aggregate per dashboard molto utilizzate con un tempo di esecuzione molto elevato. Potresti ricevere segnalazioni da parte degli utenti relative a dashboard lente, ma se hai see_system_activity, puoi anche utilizzare l'esplorazione della cronologia delle attività di sistema di Looker per trovare dashboard con un tempo di esecuzione più lento della media. Come scorciatoia, puoi aprire questo link all'esplorazione della cronologia dell'attività di sistema in un browser, quindi sostituire "hostname" nell'URL con il nome della tua istanza di Looker. Viene visualizzata una visualizzazione di esplorazione con i dati delle dashboard dell'istanza, tra cui Titolo, Cronologia, Numero di esplorazioni, Rapporto dalla cache al database e Il rendimento è peggiore della media:

In questo esempio, sono presenti diverse dashboard con un utilizzo elevato che hanno un rendimento inferiore alla media, ad esempio la dashboard Visualizzazioni di esempio. La dashboard Visualizzazioni di esempio utilizza due esplorazioni, quindi una buona strategia sarebbe creare tabelle aggregate per entrambe.

Identifica le esplorazioni lente e sottoposte a query da parte degli utenti

Un'altra opportunità per aumentare la notorietà aggregata è rappresentata dalle esplorazioni su cui vengono eseguite molte query dagli utenti e che hanno una risposta alle query inferiore alla media.

Puoi utilizzare l'esplorazione Cronologia attività di sistema come punto di partenza per identificare opportunità di ottimizzazione delle esplorazioni. Come scorciatoia, puoi aprire il link all'esplorazione della cronologia dell'attività di sistema in un browser, quindi sostituire "hostname" nell'URL con il nome dell'istanza di Looker. Viene visualizzata una visualizzazione di esplorazione con i dati sulle esplorazioni dell'istanza, tra cui Esplorazione, Modello, Numero di esecuzioni di query, Numero di utenti e Tempo di esecuzione medio in secondi:

Nell'esplorazione della cronologia puoi identificare i seguenti tipi di esplorazioni nella tua istanza:

• Esplorazioni su cui vengono eseguite query dagli utenti (a differenza delle query dall'API o dalle importazioni pianificate)
• Esplorazioni su cui vengono eseguite query di frequente
• Esplorazioni con un rendimento scadente (rispetto ad altre esplorazioni)

Nell'esempio precedente dell'esplorazione della cronologia delle attività di sistema, le esplorazioni flights e order_items sono probabili candidate per l'implementazione della consapevolezza aggregata.

Identifica i campi molto utilizzati nelle query

Infine, puoi identificare altre opportunità a livello di dati comprendendo i campi che gli utenti includono comunemente in query e filtri.

Utilizza l'esplorazione Utilizzo dei campi dell'attività di sistema per comprendere i campi comunemente selezionati all'interno delle esplorazioni che hai identificato come lenti e di uso intensivo. Come scorciatoia, puoi aprire questo link all'esplorazione Utilizzo dei campi dell'attività di sistema in un browser e sostituire "hostname" nell'URL con il nome della tua istanza Looker. Sostituisci i filtri di conseguenza. Vedrai un'esplorazione con una visualizzazione del grafico a barre che indica il numero di volte in cui un campo è stato utilizzato in una query:

Nell'esempio di esplorazione dell'attività di sistema mostrato nell'immagine, puoi vedere che flights.count e flights.depart_week sono i due campi selezionati più di frequente per l'esplorazione. Pertanto, questi campi sono buoni candidati per essere inclusi nelle tabelle aggregate.

Dati concreti come questi sono utili, ma ci sono elementi soggettivi che guideranno i tuoi criteri di selezione. Ad esempio, esaminando i quattro campi precedenti, puoi presumere con sicurezza che gli utenti di solito controllano il numero di voli programmati e il numero di voli annullati e che vogliono suddividere questi dati per settimana e compagnia aerea. Questo è un esempio di combinazione chiara, logica e reale di campi e metriche.

Riepilogo

I passaggi descritti in questa pagina della documentazione dovrebbero fungere da guida per trovare dashboard, esplorazioni e campi da considerare per l'ottimizzazione. Inoltre, è importante capire che tutti e tre potrebbero essere mutuamente esclusivi: le dashboard problematiche potrebbero non essere basate sulle esplorazioni problematiche e la creazione di tabelle aggregate con i campi di uso comune potrebbe non essere di alcuna utilità per queste dashboard. È possibile che si tratti di tre implementazioni distinte di consapevolezza aggregata.

Progettazione di tabelle aggregate

Dopo aver identificato le opportunità per la notorietà aggregata, puoi progettare tabelle aggregate che rispondano al meglio a queste opportunità. Consulta la pagina della documentazione relativa alla consapevolezza aggregata per informazioni sui campi, sulle misure e sui periodi di tempo supportati nelle tabelle aggregate, nonché su altre linee guida per la progettazione delle tabelle aggregate.

NOTA: le tabelle aggregate non devono corrispondere esattamente alla query per poter essere utilizzate. Se la query ha una granularità settimanale e hai una tabella di aggregazione giornaliera, Looker utilizzerà la tabella aggregata anziché la tabella non elaborata a livello di timestamp. Analogamente, se hai una tabella aggregata aggregata a livello di brand e date e un utente esegue query solo a livello di brand, questa tabella è ancora una candidata per essere utilizzata da Looker per la notorietà aggregata.

La consapevolezza aggregata è supportata per le seguenti misure:

• Misure standard: misure di tipo SOMMA, CONTA, MEDIA, MIN e MAX
• Misure composite: misure di tipo NUMBER, STRING, YESNO e DATE
• Misure approssimative distinte: dialetti che possono utilizzare la funzionalità HyperLogLog

La notorietà aggregata non è supportata per le seguenti misure:

• Misure distinte: poiché l'esattezza può essere calcolata solo su dati atomici non aggregati, le misure *_DISTINCT non sono supportate al di fuori di queste approssimazioni che utilizzano HyperLogLog.
• Misure basate sulla cardinalità:come per le misure distinte, le mediane e i percentile non possono essere preaggregati e non sono supportati. 

NOTA: se conosci una potenziale query utente con tipi di misura non supportati dalla notorietà aggregata, ti consigliamo di creare una tabella aggregata che corrisponda esattamente a una query. Una tabella aggregata che corrisponde esattamente alla query può essere utilizzata per rispondere a una query con tipi di misura che altrimenti non sarebbero supportati per la consapevolezza aggregata.

Granularità della tabella aggregata

Prima di creare tabelle per combinazioni di dimensioni e misure, devi determinare schemi comuni di utilizzo e selezione dei campi per creare tabelle aggregate che verranno utilizzate il più spesso possibile con il massimo impatto. Tieni presente che tutti i campi utilizzati nella query (siano selezionati o filtrati) devono trovarsi nella tabella aggregata affinché la tabella possa essere utilizzata per la query. Tuttavia, come indicato in precedenza, la tabella aggregata non deve corrispondere esattamente a una query per essere utilizzata. Puoi rispondere a molte potenziali query degli utenti all'interno di un'unica tabella aggregata e ottenere comunque notevoli incrementi delle prestazioni.

Nell'esempio di identificazione dei campi molto utilizzati nelle query, ci sono due dimensioni (flights.depart_week e flights.carrier) che vengono selezionate molto di frequente, nonché due misure (flights.count e flights.cancelled_count). Pertanto, sarebbe logico creare una tabella aggregata che utilizzi tutti e quattro questi campi. Inoltre, la creazione di una singola tabella aggregata per flights_by_week_and_carrier comporterà un utilizzo più frequente della tabella aggregata rispetto a due tabelle aggregate diverse per le tabelle flights_by_week e flights_by_carrier.

Ecco un esempio di tabella aggregata che potremmo creare per le query sui campi comuni:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Gli utenti aziendali, le prove aneddotiche e i dati dell'attività di sistema di Looker possono aiutarti a prendere decisioni.

Trovare il giusto equilibrio tra applicabilità e rendimento

Il seguente esempio mostra una query di esplorazione dei campi Flights Depart Week, Flights Details Carrier, Flights Count e Flights Detailed Cancelled Count della tabella aggregata flights_by_week_and_carrier:

L'esecuzione di questa query dalla tabella di database originale ha richiesto 15,8 secondi e ha scansionato 38 milioni di righe senza unioni utilizzando Amazon Redshift. L'applicazione del pivot alla query, che sarebbe un'operazione normale per l'utente, ha richiesto 29,5 secondi.

Dopo aver implementato la tabella aggregata flights_by_week_and_carrier, la query successiva ha richiesto 7,2 secondi e ha scansionato 4592 righe. Si tratta di una riduzione del 99,98% delle dimensioni della tabella. L'applicazione del pivot alla query ha richiesto 9,8 secondi.

Dall'esplorazione Utilizzo dei campi dell'attività di sistema, possiamo vedere la frequenza con cui i nostri utenti includono questi campi nelle query. In questo esempio, flights.count è stato utilizzato 47.848 volte, flights.depart_week 18.169 volte, flights.cancelled_count 16.570 volte e flights.carrier 13.517 volte.

Anche se stimiamo molto modestamente che il 25% di queste query abbia utilizzato tutti e quattro i campi nel modo più semplice (selezione semplice, nessun pivot), 3379 x 8, 6 secondi = 8 ore e 4 minuti di tempo di attesa aggregato degli utenti eliminati.

NOTA:il modello di esempio utilizzato qui è molto semplice. Questi risultati non devono essere utilizzati come benchmark o quadro di riferimento per il modello.

Dopo aver applicato lo stesso flusso al nostro modello di e-commerce order_items, l'esplorazione più utilizzata nell'istanza, i risultati sono i seguenti:

Origine	Ora di esecuzione della query	Righe scansionate
Tabella di base	13,1 secondi	285.000
Tabella aggregata	5,1 secondi	138.000
Delta	8 secondi	147.000

I campi utilizzati nella query e nella successiva tabella aggregata erano brand, created_date, orders_count e total_revenue, utilizzando due join. I campi erano stati utilizzati in totale 11.000 volte. Se si stima lo stesso utilizzo combinato di circa il 25%, il risparmio aggregato per gli utenti sarà di 6 ore e 6 minuti (8 secondi * 2750 = 22000 secondi). La creazione della tabella aggregata ha richiesto 17,9 secondi.

Esaminando questi risultati, vale la pena fare un passo indietro e valutare i ritorni potenzialmente ottenuti da:

• Ottimizzazione di modelli/esplorazioni più grandi e complessi con prestazioni "accettabili" che potrebbero registrare miglioramenti delle prestazioni grazie a pratiche di modellazione migliori

rispetto a

• Utilizzo della notorietà aggregata per ottimizzare modelli più semplici che vengono utilizzati più di frequente e hanno un rendimento scarso

I risultati ottenuti non saranno proporzionali agli sforzi compiuti per ottenere il massimo rendimento da Looker e dal tuo database. Devi sempre tenere presente le aspettative di rendimento di base, in particolare da parte degli utenti aziendali, e le limitazioni imposte dal tuo database (come concorrenza, soglie di query, costo e così via). Non dovresti aspettarti che la notorietà aggregata superi queste limitazioni.

Inoltre, quando progetti una tabella aggregata, ricorda che un maggior numero di campi comporterà una tabella aggregata più grande e lenta. Le tabelle più grandi possono ottimizzare più query e quindi essere utilizzate in più situazioni, ma non saranno veloci come le tabelle più piccole e semplici.

Ad esempio:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Di conseguenza, la tabella aggregata verrà utilizzata per qualsiasi combinazione di dimensioni mostrate e per qualsiasi misura inclusa, pertanto potrà essere utilizzata per rispondere a molte query degli utenti. Tuttavia, per utilizzare questa tabella per una semplice query SELECT di carrier e count, è necessaria la scansione di una tabella con 885.000 righe. Al contrario, la stessa query richiederebbe solo l'analisi di 4592 righe se la tabella fosse basata su due dimensioni. La tabella con 885.000 righe comporta comunque una riduzione del 97% delle dimensioni della tabella (rispetto alle 38 milioni di righe precedenti); ma l'aggiunta di un'altra dimensione aumenta le dimensioni della tabella a 20 milioni di righe. Di conseguenza, i risultati diminuiscono man mano che includi più campi nella tabella aggregata per aumentarne l'applicabilità a più query.

Creazione di tabelle aggregate

Prendendo come esempio l'esplorazione Voli che abbiamo identificato come un'opportunità di ottimizzazione, la strategia migliore sarebbe creare tre diverse tabelle aggregate:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

Il modo più semplice per creare queste tabelle aggregate è ottenere il LookML della tabella aggregata da una query di esplorazione o da una dashboard e aggiungerlo ai file di progetto di Looker.

Dopo aver aggiunto le tabelle aggregate al progetto LookML ed aver eseguito il deployment degli aggiornamenti in produzione, le esplorazioni utilizzeranno le tabelle aggregate per le query degli utenti.

Persistenza

Per essere accessibili per la consapevolezza aggregata, le tabelle aggregate devono essere permanenti nel database. È buona prassi allineare la rigenerazione automatica di queste tabelle aggregate ai tuoi criteri di memorizzazione nella cache utilizzando i datagroup. Devi utilizzare lo stesso gruppo di dati per una tabella aggregata utilizzata per l'esplorazione associata. Se non puoi utilizzare i gruppi di dati, un'opzione alternativa è utilizzare il parametro sql_trigger_value. Di seguito è riportato un valore generico basato sulla data per sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Le tabelle aggregate verranno create automaticamente a mezzanotte ogni giorno.

Logica del periodo di tempo

Quando Looker crea una tabella aggregata, include i dati fino al momento in cui è stata creata. In genere, tutti i dati aggiunti successivamente alla tabella di base nel database vengono esclusi dai risultati di una query che utilizza la tabella aggregata.

Questo diagramma mostra la sequenza temporale in cui gli ordini sono stati ricevuti e registrati nel database rispetto al momento in cui è stata creata la tabella aggregata Ordini. Oggi sono stati ricevuti due ordini che non saranno presenti nella tabella aggregata Ordini, poiché sono stati ricevuti dopo la creazione della tabella aggregata:

Tuttavia, Looker può unire i dati aggiornati alla tabella aggregata quando un utente esegue una query per un periodo di tempo che si sovrappone alla tabella aggregata, come mostrato nello stesso diagramma della sequenza temporale:

Poiché Looker può unire i dati aggiornati a una tabella aggregata, se un utente filtra per un periodo di tempo che si sovrappone alla fine sia della tabella aggregata che della tabella di base, gli ordini ricevuti dopo la creazione della tabella aggregata verranno inclusi nei risultati dell'utente. Per informazioni dettagliate e sulle condizioni da soddisfare per unire i dati aggiornati alle query sulle tabelle aggregate, consulta la pagina della documentazione Conoscenza degli aggregati.

Riepilogo

Per riepilogare, per creare un'implementazione della notorietà aggregata sono necessari tre passaggi fondamentali:

1. Identifica le opportunità in cui l'ottimizzazione mediante tabelle aggregate è appropriata e efficace.
2. Progetta tabelle aggregate che offrano la massima copertura per le query degli utenti comuni, pur rimanendo sufficientemente piccole da ridurre sufficientemente le dimensioni di queste query.
3. Crea le tabelle aggregate nel modello di Looker, associando la persistenza della tabella alla persistenza della cache dell'esplorazione.