il Real-time data warehouse e l'epopea di Gilgamesh

Anticipare l'aggiornamento dei dati di un DW fino al real-time DW, alcune considerazioni in merito.

Tutto evolve.
In una sorta di selezione naturale tecnologica anche le tematiche inerenti il datawarehousing propongono molte mutazioni, la maggior parte muoiono così velocemente che spesso la comunità tecnico-scientifica nemmeno se ne accorge, altre (ovviamente) sopravvivono, si adattano spesso prosperano (per poi comunque estinguersi...).
Uno degli ultimi paradigmi (datato comunque "anno 2000") riguarda il concetto di real-time data warehouse (RTDW), paradigma indicante quasi una rivoluzione più che un'evoluzione.

Rimando al pluripremiato articolo di Michael Haisten "The Real time data warehouse: the next stage in data warehouse evolution" per un puntuale escursus sulla storia del data warehouse dal 1978 ad oggi.

Parlare di real-time data warehouse a chi è fortemente legato alla tradizione dei padri fondatori delle metodologie DW suona quasi come una simpatica burla, una ridicola contraddizione, qualcosa di insensato.
Suona così però solo di fronte ad un'analisi superficiale del concetto di RTDW.
Do per scontata la conoscenza di alcune caratteristiche tipiche del concetto di DW, e rimando il lettore al corretto topic di Openskill, non senza però sottolineare alcune caratteristiche relative all'acquisizione dei dati e al loro refresh, che permetteranno una migliore comprensione del RTDW.
La trasformazione di dati operazionali in dati utili all'analisi attraverso l'utilizzo di "oggetti di business" è il motivo generatore del DW dalla sua remota e primordiale ideazione; tutto (architettura, modellazione, tools di analisi, ecc.) ruota attorno a questo fondamentale requirement.
Al secondo posto (o al primo a pari merito ?) c'è la tempestività delle informazioni, la linfa vitale di qualunque analisi, oltre che una potenziale Sibilla Cumana in grado di prevedere il probabile andamento aziendale conseguentemente a scelte di business basate sull'analisi dei numeri...

Personalmente il progetto di DW con tempi di refresh più bassi sul quale abbia mai avuto modo di confrontarmi aveva tempi di aggiornamento di mezz'ora (il progetto doveva fornire dati di consumo di centrali elettriche e i tools di reporting dovevamo costruire una storia running dell'andamento con acquisizione di dati ogni mezz'ora) all'epoca sarebbe stato impossibile pensare di accorciare ulteriormente quei tempi e rimanere nel concetto corretto di DW, la classica architettura di riferimento semplicemente non è compatibile con un flusso di dati real-time da un sistema operazionale ad uno analitico (al netto di qualche sofisticato accrocchio ad hoc, del quale non posso evidentemente discutere qui); inoltre, tipicamente, i tempi di refresh vanno dall'aggiornamento quotidiano in su (settimanale, mensile, ecc.).

Se ci fermiamo a ragionare sul concetto di tempestività dell'informazione la necessità di un abbassamento dei tempi di aggiornamento fino al limite inferiore (il real time) sembra giustificato solo per certe tipologie di business e la necessità sembra si sia generata con l'avvento del Web su scala globale e il conseguente quantum leap che ha sovvertito e reinventato la definizione di "dato aggiornato, in linea e temporalmente conforme" che pare, in taluni casi appunto, essere stato ridotto di uno o due ordini di grandezza.
Comunque sia questa nuova esigenza è stata catturata, analizzata e ha prodotto un framework di riferimento (ancora giovane per la verità) con l'obiettivo di permettere un allineamento in tempo reale dei sistemi operazionali e analitici.
Il ribaltamento del paradigma passa attraverso lo strato applicativo di acquisizione dei dati che non può funzionare con attività batch gestita da tools di ETL (extraction, transformation e loading), ma attraverso l'utilizzo di tools di CTF (capture, transform e flow) che evidenziano una logica completamente diversa non solo nella gestione dei dati sorgenti, ma anche in tutta l'architettura del DW (anzi RTDW).
Un tool di CTF non funziona in modalità batch (come potrebbe ?) ma come un demone sempre attivo in grado di innescarsi come un trigger ad ogni cambio di dati nei sistemi operazionali (C), il cambio scatena una serie di eventi che recuperano i dati, i quali "galleggiano" su un flusso più o meno continuo dai sistemi transazionali a quelli analitici (F) passando attraverso le logiche definite di trasformazione (T).
Per questo un RTDW ha alcune peculiarità distintive: tutta l'eventuale parte batch di generazione di datamarts, indicizzazione, creazione di cubi multidimensionali deve essere smembrata e reingenierizzata affinchè il concetto di real-time possa essere effettivo, alcune attività tipiche di un DW saranno poi semplicemente incompatibili o irrealizzabili (do per scontato che non voglio considerare l'esistenza di un super hardware in grado eseguire in tempo infinitesimale l'attività batch ETL di un DW).

Temo inoltre, ma non ho un'esperienza diretta, che il rischio di dover gestire l'enorme complessità manutentiva di alcune soluzioni DW possa aumentare esponenzialmente nel caso di un RTDW (non solo dal punto di vista concettuale, ma anche dal punto di vista sistemistico).

Concludo infine con una considerazione che mi ricorda, con una forzata analogia, il destino di Gilgamesh alla ricerca dell'immortalità, sempre sfiorata ma mai raggiunta; la mia modesta opinione è che il RTDW per essere tale debba rinunciare ad una porzione di autentica creazione dell'informazione di business (risultato anche di complesse trasformazioni dei dati) a favore del real-time, tale rinuncia lo trasforma al limite in un elisir di lunga vita, ma non nella pozione per l'immortalità.
Nell'epopea di Gilgamesh, il re di Uruk rinuncia alla ricerca della pozione dell'immortalità accontentandosi proprio di una piccola pianta elisir di lunga vita, ma nel suo cammino di ritorno verso casa, distratto, la smarrirà...

Privacy Policy