Strategie per gestire in modo efficiente i cambiamenti di dimensione e la riformulazione dei dati nel data warehousing aziendale
Immagina questo, sei un ingegnere dei dati che lavora per una grande azienda di vendita al dettaglio che utilizza la tecnica del caricamento incrementale nel data warehousing. Questa tecnica prevede l’aggiornamento o il caricamento selettivo solo dei dati nuovi o modificati dall’ultimo aggiornamento. Cosa potrebbe accadere quando il dipartimento di ricerca e sviluppo del prodotto decide di cambiare il nome o la descrizione di un prodotto attuale? Che impatto avrebbero tali aggiornamenti sulla pipeline di dati e sul data warehouse esistenti? Come pensi di affrontare sfide come queste? Questo articolo fornisce una guida completa con soluzioni, utilizzando Slowly Changing Dimensions (SCD), per affrontare potenziali problemi durante la riaffermazione dei dati.
Cosa sono le dimensioni a cambiamento lento (SCD)?
Le dimensioni a modifica lenta si riferiscono a modifiche poco frequenti nei valori delle dimensioni, che si verificano sporadicamente e non sono legate a una pianificazione giornaliera o regolare basata sul tempo, poiché le dimensioni in genere cambiano meno frequentemente rispetto alle voci delle transazioni in un sistema. Ad esempio, un’azienda di gioielleria i cui clienti effettuano un nuovo ordine sul proprio sito Web diventerà una nuova riga nella tabella dei fatti dell’ordine. D’altra parte, l’azienda di gioielleria cambia raramente il nome del prodotto e la descrizione del prodotto, ma ciò non significa che ciò non accadrà mai in futuro.
La gestione dei cambiamenti in queste dimensioni richiede l’utilizzo di tecniche di gestione delle dimensioni a modifica lenta (SCD), che sono classificate in tipi SCD definiti, che vanno dal tipo 0 al tipo 6, comprese alcune combinazioni o tipi ibridi. Possiamo utilizzare uno dei seguenti metodi:
SCD tipo 0: ignora
Le modifiche ai valori delle dimensioni vengono completamente ignorate e i valori delle dimensioni rimangono invariati dal momento in cui sono stati inizialmente creati nel data warehouse.
SCD Tipo 1: Sovrascrivi/Sostituisci
Questo approccio è applicabile quando il valore precedente dell’attributo dimensione non è più rilevante o importante. Tuttavia, il monitoraggio cronologico delle modifiche non è necessario.
SCD tipo 2: crea una nuova riga di dimensione
Questo approccio è consigliato come tecnica principale per affrontare la modifica dei valori delle dimensioni, prevedendo la creazione di una seconda riga per la dimensione con una data di inizio, una data di fine e potenzialmente un flag “corrente/scaduto”. È adatto ai nostri scenari come la descrizione del prodotto o la modifica dell’indirizzo, garantendo una chiara suddivisione della cronologia. La nuova riga di dimensione è collegata alle righe di fatti appena inserite, con ciascun record di dimensione collegato a un sottoinsieme di righe di fatti in base ai tempi di inserimento: quelli prima della modifica collegati alla vecchia riga di dimensione e quelli successivi collegati alla nuova riga di dimensione.
PRODUCT_KEY = “cd3004” è la riaffermazione per PRODUCT_KEY = “cd3002”SCD tipo 3: crea una colonna “PREV”.
Questo metodo è adatto quando sono rilevanti sia il vecchio che il nuovo valore e gli utenti potrebbero voler condurre un’analisi storica utilizzando uno dei due valori. Tuttavia, non è pratico applicare questa tecnica a tutti gli attributi delle dimensioni, poiché comporterebbe la fornitura di due colonne per ciascun attributo nelle tabelle delle dimensioni o più se è necessario conservare più valori “PREV”. Dovrebbe essere utilizzato selettivamente ove appropriato.
SCD tipo 4: grandi dimensioni in rapida evoluzione
Cosa accadrebbe se in uno scenario dovessi catturare ogni cambiamento in ogni attributo dimensionale per una dimensione molto ampia di vendita al dettaglio, diciamo più di un milione di clienti della tua grande azienda di gioielleria? L’utilizzo del tipo 2 riportato sopra farà esplodere molto rapidamente il numero di righe nella tabella delle dimensioni del cliente fino a decine o addirittura centinaia di milioni di righe e l’utilizzo del tipo 3 non è fattibile.
Una soluzione più efficace per le tabelle delle dimensioni che cambiano rapidamente e di grandi volumi consiste nel categorizzare gli attributi (per esempio, categoria di età del cliente, sesso, potere d’acquisto, compleanno, ecc.) e separarli in una dimensione secondaria, come la dimensione del profilo cliente. Questa tabella, agendo come una tabella dimensionale a “copertura completa” di tutti i valori potenziali per ogni categoria di attributi dimensionali precaricati nella tabella, può gestire meglio la granularità delle modifiche evitando un’eccessiva espansione delle righe nella dimensione cliente principale.
Ad esempio, se abbiamo 8 categorie di età, 3 generi diversi, 6 categorie di potere d’acquisto e 366 possibili compleanni. La nostra tabella delle dimensioni “copertura completa” per i profili cliente che contiene tutte le combinazioni di cui sopra sarà 8 x 3 x 6 x 366 combinazioni o 52704 righe.
Dovremo generare surrogate_key per questa tabella delle dimensioni e stabilire una connessione a una nuova chiave esterna nella tabella dei fatti. Quando si verifica una modifica in una di queste categorie di dimensioni, non è necessario aggiungere un’altra riga alla dimensione cliente. Generiamo invece una nuova riga dei fatti e la associamo sia alla dimensione cliente che alla nuova dimensione profilo cliente.
SCD Tipo 5: un’estensione al Tipo 4
Per migliorare l’approccio di Tipo 4 menzionato in precedenza, possiamo stabilire una connessione tra la dimensione del cliente e la dimensione del profilo del cliente. Questo collegamento consente il tracciamento del profilo cliente “attuale” per un cliente specifico. La chiave facilita la connessione del cliente con il profilo cliente più recente, consentendo il passaggio continuo dalla dimensione del cliente alla dimensione del profilo cliente più recente senza la necessità di collegarsi tramite la tabella dei fatti.
SCD tipo 6: una tecnica ibrida
Con questo approccio, integri sia il tipo 2 (nuova riga) che il tipo 3 (colonna “PREV”). Questo approccio misto offre i vantaggi di entrambe le metodologie. Puoi recuperare i fatti utilizzando la colonna ” PREV “, che fornisce valori storici e presenta fatti associati alla categoria di prodotto in quel momento specifico. Allo stesso tempo, l’interrogazione tramite la colonna “nuovo” fornisce tutti i fatti sia per il valore corrente che per tutti quelli precedenti della categoria di prodotto.
Bonus e conclusione
Normalmente, l’estrazione dei dati avviene nello schema STAR, che include una tabella dei fatti e più tabelle delle dimensioni in un’azienda. Mentre le tabelle delle dimensioni memorizzano tutti i dati descrittivi e le chiavi primarie, la tabella dei fatti contiene dati numerici e additivi che fanno riferimento alle chiavi primarie di ciascuna dimensione attorno ad essa.
Tuttavia, se l’estrazione dei dati sulle vendite di marketing viene fornita come un’unica tabella denormalizzata senza tabelle delle dimensioni distinte e non dispone della chiave primaria per i relativi dati descrittivi, i futuri aggiornamenti ai nomi dei prodotti potrebbero presentare problemi. Gestire tali scenari nella pipeline esistente può essere più complicato.
L’assenza di chiavi primarie nei dati descrittivi può portare a problemi durante la riformulazione dei dati, soprattutto quando si ha a che fare con set di dati di grandi dimensioni. Ad esempio, se il nome di un prodotto viene aggiornato nell’estratto di riaffermazione senza un nome univoco product_keyla pipeline di carico incrementale potrebbe trattarlo come un nuovo prodotto, influenzando i dati storici nel livello di consumo. Per affrontare questo problema, creare surrogate_key per la dimensione del prodotto e una tabella di mappatura per collegare i nomi dei prodotti originali e riformulati è necessaria per mantenere l’integrità dei dati.
In conclusione, ogni aspetto della progettazione del data warehouse dovrebbe essere considerato attentamente, tenendo conto dei potenziali casi limite.
Fonte: towardsdatascience.com
