Dagli albori di Google alla rivoluzione Big Data: passato, presente e futuro dell’ingegneria dei dati. Chi si avventura per la prima volta in questo territorio farebbe bene a capire cosa è successo prima. Perché chi non conosce la storia è destinato a ripeterla
All’inizio c’è Google. Quando la società di Mountain View si accorge dell’enorme espansione di Internet, capisce subito di avere bisogno di sistemi scalabili. Nel 2004, crea MapReduce e HDFS, e nello stesso anno pubblica la documentazione tecnica. Nel 2005, basandosi su quelle stesse informazioni, Doug Cutting crea Apache Hadoop. Il 2008 è l’anno della nascita di Cloudera, seguita da HortonWorks nel 2011. Sono le prime aziende a commercializzare tecnologie open source per i big data, promuovendo attivamente il marketing e la commercializzazione di Hadoop.
La programmazione su Hadoop risulta complessa, pertanto, nel 2010 viene introdotta Apache Hive per integrare il linguaggio SQL. Nel 2008, fa la sua comparsa anche Apache Pig, sebbene la sua adozione non è destinata a raggiungere livelli significativi. Con un file system immutabile come HDFS, emerge subito la necessità di database scalabili per la lettura e la scrittura di dati in modo casuale. Apache HBase fa la sua comparsa nel 2007, seguito da Apache Cassandra nel 2008. Lungo il percorso assistiamo a un aumento significativo di database specializzati, ciascuno progettato per affrontare specifiche categorie di dati. Questi database si sono differenziati per soddisfare esigenze particolari, coprendo ambiti come la gestione di dati grafici (GPU), la rappresentazione di dati in formato JSON, l’organizzazione di dati in colonne, l’elaborazione in parallelo massiccia (MPP) e la gestione di dati chiave-valore. Questa diversificazione riflette la crescente complessità delle richieste nel campo dei database, con soluzioni mirate a ottimizzare l’archiviazione e l’accesso a tipi specifici di informazioni. Hadoop non è in grado di fornire supporto per operazioni in tempo reale. Per colmare questa lacuna, nel 2011 viene introdotto Apache Storm. Anche la sua adozione su larga scala risulta limitata, forse perché è ancora troppo presto per le operazioni in tempo reale e l’API correlata risulta complessa da utilizzare. Nel 2009 arriva Apache Spark che rivoluziona l’elaborazione dati fornendo un motore unificato sia per il batch che per lo streaming. Grazie alle sue capacità avanzate, l’adozione di Apache Spark continua a crescere, fino a soppiantare completamente Hadoop. Nel 2011, è la volta di Apache Flink che introduce il primo motore di streaming vero e proprio, gestendo con eleganza i problemi di stato in tempo reale.
A questo punto, è ormai matura la necessità di avere un sistema efficiente, capace di gestire un volume crescente di dati e di adattarsi alle esigenze di scalabilità in un contesto in cui i dati devono essere trasmessi in modo distribuito e dinamico. L’introduzione di Apache Kafka nel 2011 risponde a questa esigenza, fornendo un sistema pub/sub scalabile e migliorando il trasferimento di dati in tempo reale. Tuttavia, anche Apache Kafka ha i suoi limiti architetturali e per affrontare queste limitazioni nel 2016 viene rilasciato Apache Pulsar.
Big Data in azione
Strata e Hadoop World sono le due conferenze di riferimento per la community di programmatori e sviluppatori di software. Le loro strade si fondono nel 2012. Questo evento costituisce un punto di svolta fondamentale, dove le menti più brillanti si riuniscono per condividere idee e scoperte. La gestione di queste conferenze è affidata a personalità di spicco, come Ben Lorica, Doug Cutting e Alistair Croll, che contribuiscono significativamente a rendere queste occasioni non solo momenti di conoscenza, ma anche di scambio e collaborazione tra esperti del settore. In quel momento, c’è un problema generalizzato, ancora oggi non completamente risolto: la maggior parte dei progetti fatica a entrare in produzione. Alcuni addossano la colpa soprattutto alle tecnologie. I progetti legati ai Big Data affidati a team di data scientist e data warehouse spesso falliscono. Sebbene oggi possa sembrare ovvio, le mie riflessioni sulla necessità di ingegnerizzare i dati andavano molto controcorrente rispetto a quanto si scriveva all’epoca. Allora come oggi, la mera funzionalità delle tecnologie non è sufficiente. L’ingegnerizzazione dei dati resta essenziale per il successo dei progetti nel campo dei big data.
Dati e Business
Nel 2008, DJ Patil conia il termine “data scientist”. Da quel momento, per la maggior parte delle aziende, gli scienziati dei dati sono gli unici deputati a risolvere problemi legati ai dati su larga scala.
Nel 2016, inizio a scrivere di gestione dei big data, mettendo in evidenza la complessità specifica dell’ingegneria dei dati, rispetto ad altri trend del settore. Nel 2017, approfondisco ulteriormente queste idee parlando della complessità dei big data e pubblicando il mio primo libro, “Data Engineering Teams”.
Nel 2018, proseguo nell’illustrare l’importanza di avere figure specializzate come i data engineer, discutendo le differenze tra data scientist e data engineer. Nel 2019, approfondisco ulteriormente l’argomento dimostrando che i data scientist non sono equivalenti agli ingegneri dei dati.
Nel 2020, pubblico il mio terzo libro, “Data Teams”, con l’obiettivo di spiegare come i team dedicati a dati e business dovrebbero collaborare per ottenere successo nell’era dei dati.
Nel 2017, Maxime Beauchemin, uno dei creatori di Apache Airflow, ha già iniziato la sua personale esplorazione dell’ingegneria dei dati. Nel suo articolo “The Rise of the Data Engineer”, evidenzia i cambiamenti in atto nel settore, delineando l’ascesa di questa disciplina. Successivamente, nello stesso anno, pubblica “The Downfall of the Data Engineer”, affrontando le sfide e le difficoltà connesse alla crescita della data engineering. Nel 2019, Zhamak Dehghani introduce il concetto di data mesh, presentandolo come un approccio sociotecnico ai dati. Nel 2022, approfondisce questo concetto con la pubblicazione del libro “Data Mesh”. Gene Kim, nel suo libro “The Unicorn Project” del 2019, si occupa della gestione dei team dedicati ai dati, offrendo una prospettiva preziosa su come affrontare le sfide in continua evoluzione.
Anche i cambiamenti nelle preferenze e nelle tendenze riguardanti i linguaggi di programmazione sono soggetti alle mode del momento. Ci sono periodi in cui un linguaggio è particolarmente popolare o in voga tra gli sviluppatori. Abbiamo attraversato diverse fasi in cui Java, Scala e Python erano al centro dell’attenzione. Ora tutti sono entusiasti di Rust. Le grandi basi di codice non tipizzate, ovvero codice in cui il tipo delle variabili non è dichiarato esplicitamente, non sono solo complesse da gestire ma possono anche rappresentare una sorta di “terreno minato”, e per questo richiedono un approccio attento e competente.
Conclusione
Questa cronaca dell’evoluzione dell’ingegneria dei dati non copre tutte le tecnologie e le aziende coinvolte. Nel corso del tempo, alcune sono scomparse, altre hanno subito declini graduati, alcune stanno ancora cercando di affermarsi, mentre altre hanno grande successo. Le decisioni errate in termini di tecnologia possono portare a fallimenti, anche in fasi avanzate del processo. È importante sottolineare che chi non comprende la propria storia è destinato a ripeterla. Molti ingegneri dei dati, specialmente quelli nuovi nel campo, potrebbero non essere pienamente consapevoli della storia o delle tecnologie che utilizzano. Nonostante la centralità della tecnologia e dei linguaggi di programmazione nel determinare il successo o il fallimento di un progetto di data management, è cruciale riconoscere che le persone e la struttura organizzativa sono i principali fattori che influenzano il destino di tali progetti.
Esaminando i progressi tecnologici nel corso degli anni, sono emersi strumenti migliori, ma ciò non ha semplificato in modo significativo i problemi. Nessuno di questi strumenti ha trasformato radicalmente un problema complesso in qualcosa di così accessibile da essere affrontato da chiunque. Indubbiamente, ci sono stati miglioramenti nel processo di ingegneria dei dati, con un incremento che possiamo quantificare tra il cinque e il dieci percento in termini di facilità di utilizzo. In altre parole, le modifiche apportate hanno reso il lavoro degli ingegneri dei dati leggermente più agevole.
Adesso, è possibile dedicare più tempo alla risoluzione dei problemi specifici del Business perché la soluzione ai problemi di ingegneria dei dati è già integrata negli strumenti o nei sistemi utilizzati, senza la necessità di scrivere soluzioni personalizzate da zero. Nonostante questi miglioramenti, nessun sistema distribuito progettato per un uso generale renderà l’ingegneria dei dati un compito facile. L’ingegneria dei dati rimane una sfida che richiede competenza e attenzione, anche con le tecnologie più avanzate a disposizione.
Jesse Anderson
Ingegnere dei dati, creativo e direttore esecutivo del Big Data Institute, con una profonda esperienza internazionale nel settore dei Big Data. Specializzato in formazione, ha istruito migliaia di manager provenienti sia da startup che da aziende Fortune 100. Pubblica con O’Reilly e Pragmatic Programmers ed è stato citato da numerosi media quali Wall Street Journal, CNN, BBC, NPR, Engadget e Wired.
