Modello di archiviazione dati per Data Workbench

Questo documento ha lo scopo di aiutare i nuovi amministratori e analisti che hanno appena terminato la formazione di Adobe Analytics Data Workbench. Dopo aver letto questo articolo, sarà più facile visualizzare come funziona questo software mentre si risolvono i problemi o si esegue un'analisi approfondita.

Le architetture convenzionali, come un database relazionale, organizzano i dati in tabelle interconnesse da chiavi. Al contrario, il componente Data Workbench in Adobe Analytics utilizza un processo fondamentalmente diverso, noto come architettura "a ruota". Questo articolo descrive il funzionamento dell'architettura a ruota rispetto a quelle convenzionali e ne identifica i punti deboli e di forza.  

Cos'è l'architettura a ruota?

Immagina che i dati dei visitatori del tuo sito Web siano valigie che circolano su un nastro trasportatore per il ritiro dei bagagli all'aeroporto. In questo esempio, il tuo obiettivo è quello di contare le valigie di colore simile man mano che compaiono davanti a te.   

Per eseguire la query delle valigie in circolo, puoi identificare la prima valigia e quindi contare le successive che ti passano davanti.

Ogni volta che passa una valigia corrispondente, identificala e calcola la somma dei diversi tipi di valigie. Questo ti permette di contare tutte le valigie e di raggrupparle in base al tipo.

Quando la prima valigia passa di nuovo davanti a te, ha completato l'intero circuito. A questo punto puoi interrompere il conteggio e riportare i risultati.

Se anche altre persone hanno bisogno di eseguire una query dei risultati, possono avvicinarsi al nastro e guardare le valigie esattamente per un giro, partendo dallo stesso o da diversi giri del nastro. Questo nastro, o ruota dati, è sempre in rotazione e un'interrogazione può iniziare in qualsiasi momento e continuare fino al completamento di una singola rotazione.

Inoltre, Data Workbench garantisce che le valigie sul nastro siano in ordine completamente casuale. (Anche le compagnie aeree sono brave in questo!) Ciò consente di visualizzare una query di dati circolari come un'istantanea casuale dei dati totali, consentendo di calcolare rapidamente le risposte approssimative estrapolando il risultato dell'intera popolazione.

Con 50 elementi di dati questo potrebbe non funzionare troppo bene. Ma con milioni o miliardi di dati, una stima molto accurata del conteggio finale si può estrarre quasi istantaneamente.

Esecuzione di query dettagliate 

Espandiamo ulteriormente questa analogia. Per query analitiche più dettagliate, estraiamo tutti gli articoli dalla valigia (ma li raggruppiamo sempre per viaggiatore). Il contenuto è composto da una piccola borsa, una borsa organizer ancora più piccola e singoli oggetti.

Ora che l'agente di query ha accesso immediato ai contenuti, una query più dettagliata come "quanti viaggiatori hanno una bottiglia blu?" può essere eseguita.  

Struttura gerarchica all'interno di una valigia

Traduciamo questa analogia del bagaglio in dati dei visitatori per l'analisi: Una valigia per ogni viaggiatore rappresenta tutti i dati di un visitatore, l'etichetta con il nome è l'ID visitatore, le borse piccole rappresentano una visita, gli organizzatori sono hit e i singoli elementi sono eventi.

Nel client Data Workbench, questa struttura può essere descritta come un diagramma di schema. Una descrizione del diagramma di schema è fornita qui.  

L'operazione di disposizione dei dati secondo questa architettura si chiama Elaborazione dei Log. Deve avvenire ogni volta che la struttura gerarchica cambia in modo significativo.  Questo processo richiede tempo, ma fornisce un set di dati ottimizzato per query analitiche molto veloci.

Tabelle relazionali nell'analogia delle valigie

Prima di descrivere come la ruota dati differisce dalle tabelle, consideriamo prima di tutto come questa analogia delle valigie cercherebbe un approccio convenzionale. In un database relazionale, i dati sarebbero qualcosa di simile a molti scaffali con delle borse. Questa architettura convenzionale offre un modo rapido per inserire una nuova borsa o estrarne una specifica.

Per un'analisi più dettagliata, i dati all'interno di ciascuna borsa dovranno essere estratti e normalizzati in scaffali separati come questo.

In questa configurazione, l'agente di query deve risolvere le chiavi esterne per collegare ciascuno degli articoli su tutti e quattro gli scaffali.  

Considerazioni generali per la query analitica

Quando una query ha come target un'entità, il database relazionale può completare la query molto rapidamente. Per esempio, una query del tipo "quanti eventi ha attivato il Sig. Taro con Adobe?" richiederebbe all'agente di query di cercare un dato sulla tabella dei visitatori, diversi sulla tabella delle visite e altri sulla tabella degli hit e degli eventi. Richiederebbe anche un conteggio del numero di eventi. Questi sono passaggi costosi per l'uso di queste chiavi esterne da parte del database, ma per una persona sono ancora pratici.

Tuttavia, una query analitica è più aperta e richiede una risposta alla domanda: "Quanti utenti attivano quanti eventi per sessione?" Questo richiede una query attraverso molti dati con l'agente di query che ripete i passaggi costosi per tutti gli utenti. Di conseguenza, quando si hanno milioni o miliardi di visitatori, questo diventa rapidamente poco funzionale.

Utilizzando le ruote dati, i dati di ciascun visitatore sono organizzati in una singola borsa, in modo che l'agente di query possa valutare ogni borsa in una volta e passare alla successiva, consentendo alla ruota di completare una query in un'unica scansione.  Pertanto, l'architettura della ruota è più adatta per le query analitiche.

Il Cubo OLAP

Per migliorare la velocità della query analitica, il tipico software di Business Intelligence (BI) si basa su una struttura multidimensionale con dati di sintesi precalcolati noti come cubo OLAP. Eseguendo una query contro questi sommari, il tempo di risposta diventa significativamente più breve per alcune applicazioni, ma si imbatte in problemi con le query avanzate.

Ad esempio, un'azienda ha clienti in 50 stati diversi, 1000 linee di prodotti e 10 miliardi di transazioni all'anno. I dati sono memorizzati utilizzando cubi tridimensionali basati su ora, prodotto e stato. Ciò richiede calcoli preliminari di 1,2 milioni di cubi.

In questa architettura, la query analitica "quanti prodotti abbiamo venduto ora per ogni ora in ogni stato?" si può rispondere molto rapidamente guardando un riepilogo dei cubi. Si tratta di un notevole miglioramento rispetto alle tabelle di query standard con riferimenti esterni.

Aumento della granularità e della scala

Tuttavia, una query più dettagliata come "quanti prodotti abbiamo venduto per minuto in ogni stato"? richiederà precalcoli moltiplicati per 60 per il cubo OLAP. L'aggiunta di nuovi prodotti, l'ampliamento del conteggio tra paesi o l'introduzione di nuove dimensioni (in base a dimensione, genere, materiale, ecc.) farà sì che il riepilogo del cubo OLAP moltiplichi lo stack ad un ritmo esponenziale.  

Man mano che lo stack del cubo cresce, il pre-calcolo e l'aggiornamento dei dati aumenta il tempo di overhead e costringe l'analista ad interrogare un dataset che spesso è in ritardo di giorni. Questo overhead transazionale e la crescita esponenziale dei dati attraverso le tabelle aumenta la latenza e limita fortemente le query analitiche utilizzando l'architettura del cubo OLAP.

Al contrario, l'aumento di granularità equivalente sulla ruota si tradurrà in una crescita incrementale minore.

Inoltre, senza costi generali di pre-calcolo, i nuovi dati aggiunti diventano disponibili subito dopo l'arrivo. Questo permette agli analisti di eseguire query in tempo quasi reale. Nel prossimo articolo discuterò di più su come funzionerà l'elaborazione in tempo reale.

Query su dati effettivi vs. riepilogo dei dati effettivi

Anche quando un'organizzazione ha una grande capacità di aggiornare il riepilogo in tempo quasi reale, si dovrebbe considerare un fattore in più: Una query contro un cubo OLAP è una query contro il riepilogo dei dati, che lo rende meno granulare e intrinsecamente "con perdite".  Al contrario, i risultati della query sulla ruota sono calcolati direttamente dai dati elaborati.

Conclusione:

Come descritto in questo documento, il funzionamento di Adobe Analytics Data Workbench può essere descritto al meglio come dati del visitatore collocati su una ruota invece di essere interconnessi come tabelle lineari o scaffali. È più adatto ad eseguire query analitiche per il sondaggio di grandi quantità di dati.

Comprendere il funzionamento interno di questo modello di database ti aiuterà a sfruttare i suoi vantaggi.