Sono un programmatore pigro! Questo è stato un dettaglio importante che ho imparato da Roelant Vos nella sua formazione della scorsa settimana. Ma c’erano molti altri argomenti interessanti. Un riassunto personale di una lezione di 3 giorni su Data Warehouse Design Patterns.
La settimana scorsa ho avuto l’opportunità di partecipare alla lezione Data Warehouse Design Patterns di Roelant Vos. Ho visto Roelant nelle presentazioni alle conferenze sulla modellazione dei dati, e ho apprezzato il suo blog con un sacco di informazioni utili sull’architettura del Data Warehouse e l’implementazione del Data Vault. Così, quando ho ricevuto l’informazione dai miei colleghi di Trivadis che avrebbe tenuto una formazione a Zurigo, ho colto l’occasione per partecipare a questo corso di 3 giorni.
Non scriverò una recensione dettagliata dell’intero corso in questo post del blog. Ma nelle righe seguenti troverete alcune note su tre argomenti che sono stati – dal mio punto di vista – importanti in questa formazione: Pattern Based Design, Persistent Staging Area e Virtual Data Warehouse.
Una tipica architettura di data warehouse consiste in più livelli per caricare, integrare e presentare informazioni di business da diversi sistemi sorgente. Il numero e i nomi dei livelli possono variare in ogni sistema, ma nella maggior parte degli ambienti i dati sono copiati da un livello all’altro con strumenti ETL o dichiarazioni SQL pure. Con una buona architettura, i modelli per trasformare e caricare i dati in un particolare livello sono sempre simili. Questo rende più facile (e più veloce) lo sviluppo dei processi ETL, perché i modelli ripetibili possono essere generati con lo strumento di automazione del data warehouse (DWA). Sul blog di Roelant, si può trovare una panoramica del suo Data Integration Framework. Gli esempi di codice sono disponibili su GitHub.
Perché sono un programmatore pigro? Come molti altri sviluppatori, non mi piace scrivere codice ripetitivo. Anche Roelant è un programmatore pigro. Ecco perché ha speso molto tempo per sviluppare strumenti e metodi per accelerare i compiti di sviluppo generando il codice SQL per costruire e caricare i magazzini di dati. Durante il corso, ha spiegato molti modelli di progettazione con il generatore SQL VDW (Virtual Data Warehouse). Può essere scaricato gratuitamente dal suo sito web ed è utile per prototipi veloci e test di regressione dei cambiamenti di pattern.
Persistent Staging Area
Un livello importante nell’architettura proposta è il PSA (Persistant Staging Area). Anche se quest’area del livello di staging è opzionale, è molto pratica e altamente raccomandata, specialmente quando i requisiti di business non sono ancora chiari all’inizio del progetto. Il PSA è un archivio storico dei dati dai sistemi sorgente e sostituisce la classica Staging Area volatile. Il PSA viene caricato o con meccanismi CDC (Change Data Capture) o con un rilevamento delta tra il sistema sorgente e la versione corrente del PSA. La Persistent Staging Area è la fonte unica per caricare le tabelle del Data Vault (Hubs, Links e Satellites) nel livello di integrazione.
Il vantaggio di una Persistent Staging Area è che solo le parti di informazione attualmente necessarie devono essere caricate nelle tabelle del Data Vault. Non dobbiamo preoccuparci dei requisiti futuri, perché i dati originali sono ancora disponibili nel PSA e possono essere ricaricati quando sono necessari. Ho visto e usato questo approccio in diversi progetti dei clienti, ed è una buona assicurazione contro i requisiti di business sconosciuti.
Virtual Data Warehouse
Quando ho visto Roelant Vos per la prima volta alla conferenza Data Modeling Zone 2017 a Düsseldorf, sono rimasto molto colpito da un interessante approccio architettonico che ha spiegato: L’unico strato persistente di un data warehouse è il PSA, e tutto il resto è implementato sopra le tabelle del PSA con le viste. Questa è l’implementazione coerente di un Virtual Data Warehouse che è supportato dal software VDW di Roelant. Ho visto questo in teoria e in alcune presentazioni, ma mai nella sua forma completa in un progetto reale.
Questo approccio “NoETL” ha diversi vantaggi: 1. È molto facile cambiare la logica di trasformazione senza ricaricare tutti i livelli del vostro data warehouse. 2. Non appena i nuovi dati vengono caricati nel livello PSA, sono immediatamente visibili in tutti i livelli successivi. 3. È una specie di data warehouse schema-on-read dove si può decidere al momento della query come i dati di origine devono essere interpretati. Tutto questo sembra molto bello, ma vedo ancora la sfida di una buona performance di query. Penso che, nella maggior parte delle situazioni, almeno i dati comunemente usati devono essere persistiti. Ma con l’approccio della vista, questo può essere fatto senza molto sforzo, per esempio con le viste materializzate.
Il corso di 3 giorni ha più che soddisfatto le mie aspettative. Anche se ho già usato alcuni dei concetti da solo (ad essere onesti, la maggior parte di ciò che Roelant ha spiegato mi era già familiare), mi è piaciuta molto la costruzione passo dopo passo di un’architettura di data warehouse utilizzando molti esempi di codice e demo dal vivo. O come ho detto come feedback spontaneo alla fine del corso: “È stato divertente”.