La data observability sta rivoluzionando il modo di gestire i dati aziendali. Come soddisfare le esigenze di scalabilità, flessibilità e autonomia dei team di sviluppo all’interno di un’organizzazione
Nell’ultimo anno, molti hanno probabilmente sentito parlare del termine “osservabilità dei dati”, con molte nuove startup che offrono software a tale scopo. Prima di spiegare cos’è l’osservabilità dei dati e perché è necessaria, è opportuno fare un salto indietro nel tempo. Negli anni 80, gestivo una pipeline di dati in batch su un mainframe. La pipeline caricava i dati ogni notte in un database, li elaborava e aggiornava centinaia di tabelle in un database applicativo. A questo punto, i dati appena aggiornati venivano prelevati e ulteriormente elaborati per essere inseriti in un secondo database applicativo. La pipeline è stata in produzione per circa 10 mesi senza alcun problema. Poi, una mattina sono arrivato presto in ufficio e ho scoperto che gli operatori dell’helpdesk avevano ricevuto molte chiamate da utenti di diversi settori dell’azienda che si lamentavano perché i dati erano tutti errati. Così ho controllato l’esecuzione del batch e tutto sembrava indicare che fosse stato eseguito con successo. Era davvero strano!
Ulteriori indagini hanno rivelato che due database erano stati danneggiati. I dati erano passati attraverso una pipeline perfettamente funzionante in produzione da quasi un anno, senza errori apparenti, eppure due database erano stati compromessi lungo il percorso. L’impatto è stato che diversi sistemi sono rimasti inattivi per quasi una settimana, e un team composto da diverse persone ha impiegato tre giorni solo per individuare la causa principale, con un processo di recupero che ha richiesto altre 72 ore di lavoro non-stop per risolvere il problema. Alla fine, tutto è stato recuperato e il problema non si è più ripresentato.
La tendenza verso lo sviluppo collaborativo
Oggi, invece, la maggior parte delle aziende gestisce le proprie attività in un ambiente informatico ibrido e distribuito. I dati e le applicazioni non si trovano in un unico luogo, ma sono distribuiti in diversi tipi di archivi di dati on-premise, più cloud e applicazioni SaaS, nonché trasmessi in streaming da dispositivi edge. Questo significa che la complessità delle pipeline di dati è notevolmente aumentata rispetto a più di 30 anni fa. La stessa complessità si riscontra nel mondo dell’analisi dati: molte aziende oggi dispongono di diversi tipi di sistemi di analisi dati, sia on premise che nel cloud, come data warehouse, data lake, storage o Hadoop in cloud, database NoSQL Graph e streaming analytics. In tutti questi ambienti vengono eseguite pipeline di data engineering che integrano i dati provenienti da sistemi di origine e archivi di dati in un panorama complesso di dati distribuiti, per l’uso in diversi sistemi di analisi. Inoltre, stanno emergendo molte nuove fonti di dati e approcci architetturali più distribuiti per la gestione dei dati. La nuova tendenza si chiama data mesh. Questo sistema supporta la democratizzazione dello sviluppo delle pipeline di data engineering, al fine di superare il collo di bottiglia dell’IT, dove i professionisti dei data engineer sono sovraccaricati dalle richieste di dati provenienti dal business.
L’obiettivo del data mesh è di aumentare il numero di data engineer in azienda e il numero di pipeline di dati costruite per pulire e integrare i dati per l’analisi. Il data mesh promuove l’idea che i “citizen data engineer” basati sui domini sviluppino pipeline di dati per creare prodotti di dati che possono essere pubblicati, consumati e utilizzati da altri. Questi ultimi, a loro volta, possono sviluppare pipeline di dati per combinare questi dati con altri dati della loro parte di azienda per creare nuovi prodotti di dati da aggiungere al data mesh. Tuttavia, coloro che scelgono di costruire un data mesh devono essere consapevoli delle dipendenze che potrebbero emergere tra le pipeline di data engineering, dove diverse pipeline di dati dipenderanno in ultima analisi da altre pipeline di dati, aggiungendo potenzialmente ulteriore complessità. Inoltre, decentralizzare il data engineering comporta che diversi citizen data engineer potrebbero scegliere di sviluppare pipeline di dati utilizzando molti strumenti diversi, tra cui: strumenti ETL, strumenti di preparazione dei dati self-service, strumenti di data mining drag and drop, strumenti di virtualizzazione dei dati, strumenti di trasformazione dei dati, software di data fabric, strumenti di orchestrazione DataOps che orchestrano pipeline tra più strumenti, strumenti di gestione dei dati in workbench di scienza dei dati, notebook di data science come Jupyter, script SQL personalizzati, e infine codice personalizzato oppure altri linguaggi di codifica. Inoltre, l’emergere di DataOps ha portato alla tendenza verso lo sviluppo collaborativo basato su componenti, in cui le pipeline di dati possono coinvolgere più tecnologie e richiamare altre pipeline di componenti in altri strumenti “best of breed”.
La crescente ridondanza dei dati tra archivi diversi
Cosa c’entra tutto questo con l’osservabilità dei dati? In sintesi, oggi abbiamo a che fare con un panorama di dati sempre più distribuiti e con una crescente ridondanza dei dati tra i diversi archivi. Il numero di data engineer e di pipeline di dati è in costante crescita, con lo sviluppo collaborativo di pipeline basate su componenti da parte di molteplici “citizen data engineer” e informatici, che potenzialmente utilizzano più strumenti per costruire pipeline e componenti di pipeline. Inoltre, esistono anche prodotti di dati, mercati di dati e condivisione di dati, insieme ad altre pipeline che consumano prodotti di dati e creano dipendenze di pipeline. Ora, ripensando al problema che mi era capitato negli anni 80 su un singolo sistema, sorge una domanda: “Che cosa succede se una pipeline costruita in modo collaborativo utilizzando più strumenti e in esecuzione su più motori di esecuzione oggi funziona ma i dati sono corrotti?” oppure “Che cosa succede se una pipeline fallisce a causa dei dati che sta elaborando?”. Come si fa a sapere qual è il problema o dove cercare nella pipeline? Come si fa a trovarlo? Quali componenti sono stati eseguiti? Quale codice è stato utilizzato? Dove si trovano i dati? Come sono stati creati i dati? Ci sono dati intermedi? Se sì, dove si trovano? Come si può spiegare la causa del problema?
In un ambiente complesso come quello attuale, l’operazione manuale potrebbe richiedere settimane per esaminare il codice e seguire passo dopo passo la pipeline, analizzando i dati in entrata e in uscita da ogni fase. Ciò richinerebbe di esaminare attentamente anche i componenti delle pipeline e chi li ha costruiti, nonché guardare ai dati grezzi in un patrimonio di dati distribuito. Per individuare il problema, è necessario risalire al passato. Inoltre, più dati si hanno, più aumenta il rischio che dati errati possano interrompere pipeline di dati altrimenti perfettamente valide. Per fare tutto questo sarebbe necessario un software in grado di monitorare costantemente l’esecuzione delle pipeline di dati e raccogliere automaticamente i metadati. Non solo. Dovrebbe produrre metriche e prevedere eventuali problemi nelle pipeline, utilizzando il lineage per individuare i guasti e intervenendo automaticamente quando necessario, rispettando le regole imposte. E se il software fosse anche in grado di autoapprendere sarebbe un ulteriore vantaggio.
Pipeline resilienti e prestazioni ottimali
L’osservabilità dei dati è fondamentale per la governance e le implementazioni di data mesh. Si tratta della capacità di monitorare continuamente lo stato, l’utilizzo dei dati e la salute delle pipeline, raccogliendo, consolidando e analizzando i segnali provenienti da più livelli tecnologici durante l’esecuzione. Ciò consente di rilevare modifiche e incidenti, di emettere ticket, avvisi e azioni per garantire che le pipeline siano più resilienti nella progettazione, migliorino le prestazioni, funzionino a costi ottimali e producano dati affidabili, conformi e tempestivi. Il software di osservabilità dei dati raccoglie i segnali di esecuzione e monitora le attività delle pipeline, le prestazioni, la latenza dei lavori. Esamina il percorso e i fallimenti della pipeline e le regole di monitoraggio create e violate, mostrando i set di dati e le altre pipeline interessate dai guasti. Inoltre, monitora la lo stato di aggiornamento dei dati, le modifiche allo schema, il conteggio delle righe, la qualità dei dati, compresa la loro completezza (per esempio, i NULL), la duplicazione dei dati, i valori dei dati rispetto ai valori attesi, le anomalie, l’elaborazione di dati sensibili non protetti e altri problemi. Tutto questo consente di individuare eventuali problemi e intervenire prontamente per garantire la massima affidabilità dei dati.
Mike Ferguson
Managing director di Intelligent Business Strategies e analista specializzato in business intelligence ed enterprise business integration. Con oltre trent’anni di esperienza in ambito IT, ha svolto attività di consulenza per importanti aziende su temi quali la business intelligence, l’enterprise architecture, la business process integration, l’application integration e la data integration. Oltre a essere frequentemente speaker in numerosi eventi e seminari in tutto il mondo, è anche autore di svariati articoli tecnici.
Mike Ferguson presenterà per Technology Transfer i seguenti seminari online live streaming: “Linee guida pratiche per implementare un data mesh” il 26-27 aprile 2023, “Migrare il data warehouse nel cloud” il 28 aprile 2023, “La modernizzazione del data warehouse” il 15-16 maggio 2023, “Analitica embedded, app intelligenti e automazione dell’intelligenza artificiale” il 17 maggio 2023 e “Data Governance centralizzata in un ambiente di dati distribuiti” il 22-23 giugno 2023.
