Verso il Big Data Analytics cloud-native: il ruolo di Kubernetes.
L’analisi dei “Big Data”, negli ultimi anni, è diventata una necessità in molte realtà Enterprise, non solo nella Ricerca Scientifica; tuttavia, identificare l’architettura ideale per l’analisi dati su larga scala non è un’operazione semplice: ad oggi non c’è una soluzione, open source o meno, che sia percepita come lo “standard de-facto” del settore, a prescindere dallo specifico caso d’uso.
Il 15 ottobre 2013, giorno della “General Availability” della prima versione di Apache Hadoop 2, la situazione era molto diversa: la sfida del Big Data Analytics sembrava ormai vinta… restava solo da attendere la “prevista” adozione su larga scala dell’ecosistema Apache Hadoop, ed estrarre valore dall’analisi di enormi moli di dati non sarebbe stato più un problema, grazie al paradigma di programmazione MapReduce. In quel momento, le condizioni per una rapida adozione della Data Architecture della Apache Foundation erano decisamente favorevoli: gli IT Manager potevano contare non solo sulla versione open source di un prodotto ritenuto completo, scalabile ed economico, ma sul mercato erano presenti realtà come Cloudera, Hortonworks e MapR, aziende multinazionali per le quali l’ecosistema Apache Hadoop era al centro del proprio business; queste aziende impiegavano i loro tecnici da un lato per evolvere e “customizzare” il prodotto open-source, dall’altro per fornire tutti i servizi e la consulenza necessaria per semplificarne l’adozione in ambito Enterprise.
Da quei giorni sono trascorsi poco meno di 7 anni e sembra passata un’era geologica: la prevista adozione su larga scala di Apache Hadoop non c’è stata, nonostante alla fine del 2017 ne sia stata rilasciata la versione 3. Anche lo scenario del supporto di classe Enterprise è mutato in modo sostanziale: delle 3 realtà multinazionali indipendenti per le quali l’ecosistema Apache Hadoop era il cuore del business ne è rimasta solo una, Cloudera Inc., che nel gennaio del 2019 ha acquisito Hortonworks mentre nell’Agosto 2019 MapR è stata acquisita da HPE. Infine (forse sarebbe meglio dire “soprattutto”), alcune architetture per l’analisi dati su larga scala alternative all’approccio della Apache Foundation raccolgono un consenso crescente da parte dei principali esperti del settore: l’ecosistema Apache Hadoop non è più percepito come l’infrastruttura d’elezione per supportare la Big Data Analysis!
Ma come si è arrivati a questa “percezione” di oggi, partendo dalle aspettative dell’Ottobre 2013? Alcuni osservatori sostengono che l’ecosistema Apache Hadoop, semplicemente, non sia più “di moda” come lo era nel 2013, ma che rappresenti ancora un’ottima soluzione per l’analisi dei Big Data, tanto che diverse grandi aziende al mondo la usano tuttora con ottimi risultati; la diffusione su larga scala dell’architettura della Apache Foundation, secondo questa “corrente di pensiero” non c’è stata probabilmente perché non erano così tante le organizzazioni che avevano una reale necessità di elaborare “Big Data”! Altri sostengono, invece, che la crescita attesa nell’adozione dell’ecosistema Apache Hadoop non ci sia stata perché, sul campo, questa architettura non ha mantenuto la promessa di scalare semplicemente, efficientemente e, soprattutto, a costi bassi; per queste ragioni la Data Archicteture della Apache Foundation è ormai superata, molto vicina ad essere una di quelle soluzioni legacy che restano vive per un certo tempo solo perché sono stati fatti ingenti investimenti nello sviluppo di applicativi che la utilizzano e che, nel medio periodo, sia destinata a morire!
Due posizioni opposte, molto nette, che fanno pensare più ad una “guerra di religione” piuttosto che ad un’analisi razionale sul tema delle architetture abilitanti per l’analisi dei Big Data. Dal nostro punto di vista alcuni componenti dell’ecosistema Apache Hadoop, sono “vivi e vegeti” (si pensi ad esempio a Spark e Presto, solo per citare un paio d’esempi) ma la sua architettura complessiva presenta una peculiarità, che ne ha ridotto significativamente la capacità di scalare a costi ragionevoli in molti contesti: il core di Apache Hadoop è disegnato con una forte commistione tra le componenti compute e storage, con il risultato che, per analizzare efficientemente grosse moli di dati, non solo è necessario disporre del know-how del Data Scientist, ma anche del supporto, non solo in fase di startup della Data Architecture, da parte di figure professionali in grado di fare “fine tuning” on-demand del sottosistema di storage HDFS affinché non risulti un collo di bottiglia per l’intero processo d’analisi. Non è così sorprendente, pertanto, che solo le grandi organizzazioni siano riuscite a creare il contesto giusto per utilizzare l’ecosistema Apache Hadoop per Big Data Analytics scalabili: per avvalersi on premise della Data Architecture della Apache Foundation sono necessari ingenti investimenti, per dotarsi di un cluster monolitico dedicato che ospiti l’architettura e, per avere garanzia di ottenere risultati, il Team dei Data Scientist va affiancato da personale con una solida conoscenza degli internals di HDFS e YARN, lungo tutto il ciclo di vita dell’infrastruttura. Forse è vero che non tutte le organizzazioni hanno una reale necessità di analizzare Big Data, ma è anche vero che la complessità di gestione dell’ecosistema Apache Hadoop è tale da renderla una Data Architecture per pochi (molto ricchi)!
Una conferma che la complessità del mondo Hadoop sia stato un problema, la possiamo trovare “leggendo” le scelte architetturali operate della Apache Foundation stessa sui principali componenti di seconda generazione. Pensiamo per esempio ad Apache Spark: si tratta di un ambiente per il calcolo distribuito orientato all’analisi dati progettato per funzionare non solo all’interno dell’ecosistema Apache Hadoop, ma anche in ambienti distribuiti privi di HDFS e YARN, grazie alla possibilità di operare nativamente su Object Storage con interfaccia S3 e di fruire di servizi di scheduling alternativi rispetto a YARN. E’ senz’altro vero che la curva d’adozione in costante crescita di Apache Spark è da attribuire principalmente alle sue capacità di analisi in memory, che ne hanno moltiplicato le performance rispetto ad Apache Hadoop MapReduce, anche di un paio di ordine di grandezza, ma l’indipendenza dal core dell’ecosistema Hadoop (HDFS e YARN) ha posto le basi per quello che è oggi lo scenario più tipico di “prima adozione” di piattaforme per l’analisi dati su larga scala: l’utilizzo di risorse in cloud. Per tutte quelle aziende che vogliono approcciare la Data Analysis su larga scala evitando grandi investimenti iniziali, grazie al “disegno leggero” di Apache Spark, è possibile acquistare Object Storage su cloud per ospitare i dati da analizzare e utilizzare un pool di risorse di calcolo, per esempio orchestrate da Kubernetes, per eseguire i carichi di lavoro di analisi di grosse moli di dati utilizzando Spark. Naturalmente questo approccio all’analisi dati su larga scala può essere implementato efficientemente anche on-premise, non solo in cloud. Dunque, la sua indipendenza da YARN ed HDFS ha reso Spark una piattaforma per l’analisi dati flessibile, scalabile, elastica e dai costi molto più contenuti.
La parziale scalabilità d’accesso allo storage e l’eccessiva complessità di alcuni suoi componenti core non sono state le uniche ragioni che hanno limitato la diffusione su larga scala dell’ecosistema Apache Hadoop: negli ultimi anni, le tecnologie del Machine e Deep Learning sono diventate lo strumento principe per ottenere insight da grandi moli di dati ed i più interessanti framework per l’apprendimento automatico (scikit-learn, Tensorflow, Pytorch, FastAI, ..), pensati per ambienti di sviluppo basati su Python, non sono ancora stati integrati efficientemente con la Data Architecture della Apache Foundation e, molto probabilmente, lo saranno solo quando strumenti come Apache Arrow, una piattaforma per lo sviluppo cross-language di tool per l’analisi dati in memory, diventeranno l’elemento d’integrazione tra tutti i componenti della Data Architecture.
Infine è ragionevole ritenere che l’evoluzione dei paradigmi architetturali conseguente alla rivoluzione dei Container abbia contribuito a rendere l’ecosistema Hadoop “fuori moda”. Il forte accoppiamento tra le risorse compute, scheduling e storage rende le applicazioni sviluppate per l’ecosistema Hadoop decisamente poco cloud-native, paradigma per cui l’elasticità di sviluppo e deployment in ambiente differenti – e la conseguente astrazione da dettagli come compute, storage e network – rappresenta un requisito fondamentale.
In questo scenario, quali sono le scelte da fare per dotarsi di una Data Architecture efficiente, scalabile, flessibile, economica e in grado di ospitare i migliori componenti utili in tutte le fasi del life-cycle del dato? Il nostro reference design prevede, innanzitutto, l’adozione di un cluster Kubernetes, configurato in modo che possa beneficiare di un network interno ad alte prestazioni (RDMA), da utilizzare sia per la comunicazione inter-pod, sia per l’accesso alle risorse di storage distribuito. La piattaforma Kubernetes consente il deployment di un Object Storage distribuito ad alte prestazioni, basato, ad esempio su Minio, supporta motori di analisi dati come Spark, ma anche soluzioni emergenti come Dask o Ray, integra semplicemente il GPU computing ed è l’unica piattaforma target di ambienti per end-to-end Data Science quali Kubeflow.
Nella prossima puntata approfondiremo Kaptain, la nostra soluzione Kubernetes, come piattaforma abilitante per la Data Analysis su larga scala.
Sitografia:
