Tutorial sull'awareness aggregata

Per ulteriori dettagli, consulta la pagina della documentazione relativa a Aggregate awareness.

Introduzione

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

Che cos'è l'awareness aggregata?

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

Spesso potresti incontrare set di dati o tabelle di grandi dimensioni che, per offrire prestazioni elevate, richiedono tabelle di aggregazione o roll-up.

In genere, puoi creare tabelle di aggregazione, ad esempio una tabella orders_daily, che contiene dimensioni limitate. Questi elementi devono essere trattati separatamente e modellati separatamente nell'esplorazione e non si collocano in modo ordinato nel modello. Queste limitazioni comportano un'esperienza utente scadente quando l'utente deve scegliere tra più esplorazioni per gli stessi dati.

Ora, con il rilevamento degli aggregati di Looker, puoi pre-costruire tabelle aggregate a vari livelli di granularità, dimensionalità e aggregazione, nonché informare Looker su come utilizzarle nelle esplorazioni esistenti. Le query sfrutteranno quindi queste tabelle di aggregazione, dove Looker lo ritiene appropriato, senza alcun input utente. Questo ridurrà le dimensioni delle query, i tempi di attesa e l'esperienza utente migliorerà.

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 delle PDT.

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

Per verificare se il dialetto del tuo database supporta il rilevamento aggregato, consulta la pagina della documentazione relativa al consapevolezza dell'aggregazione.

Il valore della consapevolezza aggregata

Esistono diverse proposte di valore significative che aggregano offerte di awareness per generare valore extra dal tuo modello Looker esistente:

• Miglioramento del rendimento: l'implementazione del riconoscimento aggregato velocizza le query degli utenti. Looker utilizzerà una tabella più piccola se contiene dati necessari per completare la query dell'utente.
• Risparmio sui costi: alcuni dialetti vengono addebitati in base alle dimensioni della query su un modello di consumo. In questo modo, puoi eseguire query su tabelle più piccole di Looker e ridurre il costo per query utente.
• Miglioramento dell'esperienza utente: oltre a un'esperienza migliorata che recupera le risposte più velocemente, il consolidamento elimina la creazione ridondante di Esplora.
• Riduzione dell'impatto di LookML: la sostituzione delle strategie di sensibilizzazione degli aggregati esistenti basate sui liquidi con un'implementazione nativa flessibile porta a una maggiore resilienza e a una riduzione degli errori.
• Possibilità di sfruttare LookML esistente: le tabelle aggregate utilizzano l'oggetto query, che riutilizza la logica modellata esistente anziché duplicare la logica con SQL personalizzato esplicito.

Esempio di base

Ecco un'implementazione molto semplice in un modello Looker per dimostrare quanto possa essere semplice la consapevolezza dei dati aggregati. Data un'ipotetica tabella flights nel database con una riga per ogni volo registrato tramite la FAA, possiamo modellare questa tabella in Looker con una propria visualizzazione e una propria esplorazione. Ecco il LookML per 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 sfrutterà automaticamente la tabella aggregata definita in precedenza e userà la tabella aggregata per rispondere alle query. L'utente non dovrà comunicare a Looker condizioni speciali, ma utilizzerà solo quella tabella se è adatta ai campi selezionati dall'utente.

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:

Consulta la pagina della documentazione relativa al consapevolezza dell'aggregazione per informazioni dettagliate su come determinare se le tabelle aggregate vengono utilizzate per una query.

Identificare le opportunità

Per massimizzare i vantaggi della consapevolezza aggregata, devi identificare i casi in cui questa può svolgere un ruolo nell'ottimizzazione o nel generare i valori menzionati sopra.

Identifica le dashboard con un runtime elevato

Una grande opportunità per il riconoscimento degli aggregati è la creazione di tabelle aggregate per le dashboard maggiormente utilizzate, con un runtime molto elevato. Gli utenti potrebbero venire a conoscenza di dashboard lente, ma se hai see_system_activity, puoi anche utilizzare l'esplorazione della cronologia dell'attività di sistema di Looker per trovare dashboard con un tempo di esecuzione più lento della media. Come scorciatoia, puoi aprire questo link Esplorazione della cronologia delle attività di sistema in un browser e sostituire "nome host" nell'URL con il nome dell'istanza di Looker. Vedrai una visualizzazione Esplorazione con dati sulle dashboard della tua istanza, tra cui Titolo, Cronologia, Conteggio delle esplorazioni, Razione dalla cache rispetto al database e È peggio della media:

In questo esempio, sono presenti diverse dashboard ad alto utilizzo con prestazioni peggiori della media, come la dashboard Visualizzazioni di esempio. La dashboard Visualizzazioni di esempio utilizza due esplorazioni, quindi una buona strategia potrebbe essere quella di creare tabelle aggregate per entrambe le esplorazioni.

Identifica le esplorazioni lente e con molte query da parte degli utenti

Un'altra opportunità per conoscere l'aggregazione è costituita dalle esplorazioni che sono oggetto di molte query da parte degli utenti e hanno una risposta alle query inferiore alla media.

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

In Esplorazione della cronologia, puoi identificare i seguenti tipi di esplorazioni sulla tua istanza:

• Esplorazioni a cui vengono eseguite query dagli utenti (anziché query dall'API o query da pubblicazioni pianificate)
• Esplorazioni con query frequenti
• Le esplorazioni con un rendimento scarso (rispetto ad altre esplorazioni)

Nell'esempio precedente di Esplorazione della cronologia di attività di sistema, le esplorazioni flights e order_items sono probabili candidati per l'implementazione dell'awareness aggregata.

Identifica i campi più utilizzati nelle query

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

Usa l'esplorazione dell'utilizzo dei campi dell'attività di sistema per comprendere i campi selezionati comunemente nelle esplorazioni che hai identificato in precedenza. Come scorciatoia, puoi aprire questo link Esplorazione dell'utilizzo dei campi dell'attività di sistema in un browser, quindi sostituire "nome host" nell'URL con il nome dell'istanza di Looker. Sostituisci i filtri di conseguenza. Vedrai un'esplorazione con un grafico a barre che indica il numero di volte in cui un campo è stato utilizzato in una query:

Nell'esplorazione dell'attività di sistema mostrata sopra, puoi vedere che flights.count e flights.depart_week sono i due campi più comunemente selezionati per l'esplorazione. Sono quindi ideali per i campi da includere nelle tabelle aggregate.

Dati concreti come questo sono utili, ma ci sono elementi soggettivi che guideranno i tuoi criteri di selezione. Ad esempio, osservando i quattro campi precedenti, puoi presumere che gli utenti di solito guardino il numero di voli pianificati e il numero di voli cancellati e che desiderano suddividere tali dati sia per settimana sia per vettore. Questo è un esempio di una combinazione chiara, logica e reale di campi e metriche.

Riepilogo

I passaggi precedenti dovrebbero fungere da guida per trovare dashboard, esplorazioni e campi che devono essere presi in considerazione per l'ottimizzazione. È inoltre bene comprendere che tutte e tre le dashboard possono escludono a vicenda: 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 aiuto per queste dashboard. È possibile che si tratti di tre implementazioni di awareness aggregate discrete.

Progettazione di tabelle aggregate

Dopo aver identificato le opportunità per creare awareness aggregata, puoi progettare tabelle aggregate che ti consentono di rispondere al meglio a queste opportunità. Consulta la pagina della documentazione relativa alla consapevolezza dell'aggregazione per informazioni su campi, misure e periodi di tempo supportati nelle tabelle aggregate, nonché altre linee guida per la progettazione di tabelle aggregate.

NOTA: per utilizzare le tabelle aggregate, non è necessario che siano corrispondenze esatte. Se la query è alla granularità della settimana e disponi di una tabella di aggregazione giornaliera, Looker utilizzerà la tabella aggregata anziché la tabella non elaborata a livello di timestamp. Allo stesso modo, se hai una tabella aggregata a livello di brand e date e un utente esegue query solo a livello di brand, può ancora essere utilizzata da Looker per il rilevamento dei dati aggregati.

La consapevolezza aggregata è supportata per le seguenti misure:

• Misure standard: misure di tipo SUM, COUNT, AVERAGE, MIN e MAX
• Misure composite : misure di tipo NUMBER, STRING, YESNO e DATE
• Misure distinte approssimative: Dialetti che possono utilizzare la funzionalità HyperLogLog.

La consapevolezza aggregata non è supportata per le seguenti misure:

• Misure distinte: poiché la distinzione può essere calcolata solo su dati atomici e 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 percentili non possono essere preaggregati e non sono supportati. 

NOTA: se conosci una potenziale query di un utente con tipi di misura che non sono supportati dal rilevamento dell'aggregazione, 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 il rilevamento dei dati aggregati.

Granularità della tabella aggregata

Prima di creare tabelle per le combinazioni di dimensioni e misure, devi determinare modelli comuni di utilizzo e selezione dei campi in modo da creare tabelle aggregate che verranno utilizzate il più spesso possibile e con il massimo impatto. Tieni presente che tutti i campi utilizzati nella query (selezionati o filtrati) devono essere presenti nella tabella aggregata affinché possa essere utilizzata per la query. Tuttavia, come indicato in precedenza, la tabella aggregata non deve necessariamente essere una corrispondenza esatta per una query utilizzata per la query. Puoi rispondere a molte potenziali query degli utenti all'interno di una singola tabella aggregata e riscontrare comunque notevoli miglioramenti delle prestazioni.

Dall'esempio di identificazione dei campi molto utilizzati nelle query riportato sopra, sono disponibili due dimensioni selezionate molto frequentemente (flights.depart_week e flights.carrier), oltre a due misure (flights.count e flights.cancelled_count). Sarebbe quindi 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 delle tabelle aggregate più frequente rispetto a due diverse tabelle aggregate 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;;
      }
    }
  }

I tuoi utenti aziendali e le prove aneddotiche, nonché i dati dell'attività di sistema di Looker, possono aiutarti a orientare il tuo processo decisionale.

Bilanciare applicabilità e prestazioni

L'esempio seguente mostra una query Esplora per i campi Settimana di partenza dei voli, Vettore dettagli voli, Conteggio voli e Conteggio dettagliato dei voli annullati dalla tabella aggregata flights_by_week_and_carrier:

L'esecuzione di questa query dalla tabella di database originale ha richiesto 15,8 secondi e ha analizzato 38 milioni di righe senza join utilizzando Amazon Redshift. Il pivot della query, che sarebbe una normale operazione 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 analizzato 4592 righe. Le dimensioni della tabella sono ridotte del 99,98%. Il pivot della query ha richiesto 9,8 secondi.

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

Anche se abbiamo stimato in modo modesto che il 25% di queste query utilizzasse tutti e quattro i campi nel modo più semplice (selezione semplice, nessun pivot), 3379 x 8,6 secondi = 8 ore, 4 minuti nel tempo di attesa aggregato dell'utente eliminato.

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

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

Origine	Tempo query	Righe scansionate
Tavolo 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 sono stati utilizzati per un totale di 11.000 volte. Stimando lo stesso utilizzo combinato di circa il 25%, il risparmio aggregato per gli utenti sarebbe 6 ore, 6 minuti (8 s * 2750 = 22.000 s). La creazione della tabella aggregata ha richiesto 17,9 secondi.

Osservando questi risultati, vale la pena soffermarti un attimo indietro e valutare i ritorni potenzialmente ottenuti grazie a:

• Ottimizzazione di esplorazioni/modelli più grandi e complessi che hanno un rendimento "accettabile" e che potrebbero registrare miglioramenti del rendimento derivanti da migliori pratiche di definizione del modello

rispetto a

• Utilizzare il riconoscimento aggregato per ottimizzare i modelli più semplici che vengono utilizzati più spesso e hanno un rendimento scarso

Vedrai rendimenti decrescenti per i tuoi sforzi mentre cercherai di ottenere le ultime prestazioni da Looker e dal tuo database. Devi sempre essere a conoscenza delle aspettative di base delle prestazioni, in particolare degli utenti aziendali, e delle limitazioni imposte dal tuo database (come contemporaneità, soglie delle query, costi e così via). Non aspettarti che l'awareness aggregata superi questi limiti.

Inoltre, quando progetti una tabella aggregata, ricorda che avere più campi comporterà una tabella aggregata più grande e più lenta. Le tabelle più grandi possono ottimizzare più query e quindi essere utilizzate in più situazioni, ma le tabelle di grandi dimensioni non saranno veloci quanto 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;;
      }
    }
  }

In questo modo, la tabella aggregata verrà utilizzata per qualsiasi combinazione di dimensioni mostrate e per qualsiasi misura inclusa. Pertanto, questa tabella può essere utilizzata per rispondere a molte query diverse degli utenti. Tuttavia,l'utilizzo di questa tabella per una semplice query SELECT di carrier e count richiederebbe l'analisi di una tabella di 885.000 righe. Al contrario, la stessa query richiederebbe una scansione di 4592 righe solo se la tabella si basasse su due dimensioni. La tabella di 885.000 righe presenta ancora una riduzione del 97% delle dimensioni della tabella (rispetto alle precedenti 38 milioni di righe), ma aggiungendo un'altra dimensione la dimensione della tabella aumenta a 20 milioni di righe. Di conseguenza, i rendimenti diminuiscono man mano che includi più campi nella tabella aggregata per aumentarne l'applicabilità a più query.

Creazione di tabelle aggregate

Prendendo il nostro esempio di esplorazione Flights che abbiamo identificato come un'opportunità di ottimizzazione, la strategia migliore potrebbe essere creare tre diverse tabelle aggregate relative:

• 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 Esplora o da una dashboard e aggiungere il LookML ai file di progetto di Looker.

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

Persistenza

Per essere accessibili per il rilevamento dei dati aggregati, le tabelle aggregate devono essere salvate in modo permanente nel database. Ti consigliamo di allineare la rigenerazione automatica di queste tabelle aggregate ai tuoi criteri di memorizzazione nella cache sfruttando i datagroups. Devi utilizzare lo stesso gruppo di dati per una tabella aggregata che viene usata per l'esplorazione associata. Se non puoi utilizzare i gruppi di dati, un'alternativa consiste nell'utilizzare il parametro sql_trigger_value. Di seguito è mostrato un valore generico basato sulla data per sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

In questo modo, le tabelle aggregate verranno create automaticamente a mezzanotte di tutti i giorni.

Logica dell'intervallo di tempo

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

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

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

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 della tabella aggregata e della tabella di base, gli ordini ricevuti dopo la creazione della tabella aggregata verranno inclusi nei risultati dell'utente. Consulta la pagina della documentazione relativa al consapevolezza dell'aggregazione per conoscere i dettagli e le condizioni da soddisfare per unire i dati aggiornati e aggregare le query delle tabelle.

Riepilogo

Riassumendo, per creare un'implementazione aggregata per l'awareness, ci sono tre passaggi fondamentali:

1. Identifica le opportunità per le quali l'ottimizzazione con le tabelle aggregate è appropriata ed efficace.
2. Progetta tabelle aggregate che offrano la massima copertura per le query degli utenti più comuni, pur rimanendo sufficientemente piccole da ridurre sufficientemente la dimensione di queste query.
3. Crea le tabelle aggregate nel modello Looker, associando la persistenza della tabella a quella della cache dell'esplorazione.