Il Mangiabidoni

Oggi ti parlo di una “creatura”, capace, in sole 300 righe di codice, di spazzare via, per performance, stabilità e costo, tutti i mostri sacri del mondo ETL. Tutti!

Il suo nome è Mangiabidoni e, per lavoro, estrae, trasforma e carica grandi quantità di dati, come nessuno ha mai fatto fino ad ora.

Il suo nome può sembrarti buffo ma, ti prego, non lo prendere in giro.

Ha una missione estremamente importante e merita rispetto: rende facilmente disponibili grandi quantità di dati. Velocemente!

Sì, perché oggi la competitività di tutte le aziende, compresa la tua, dipende dalla capacità di elaborare agilmente i tuoi dati. Ogni decisione strategica va presa sulla base di informazioni precise e non è consentito indugiare, aspettando infiniti tempi tecnici.

Occorre agire prima dei concorrenti e, per poterlo fare, per costruire solide basi per il futuro della tua azienda, hai bisogno di un sistema di archiviazione dati affidabile, sostenibile e a bassa, se non nulla, manutenzione, tutte caratteristiche difficilmente riscontrabili in tutte le soluzioni ETL disponibili sul mercato.

In decenni di carriera, le ho provate tutte: Attunity, Talend, Mulesoft, Denodo, Azure Data Factory, Apache Flume e TIBCO, per citare quelle più quotate sul mercato.

Nessuna soluzione ETL ha mai soddisfatto in pieno le mie esigenze e quelle delle aziende per le quali ho lavorato.

È per questo che ho creato il Mangiabidoni, un software scritto in C#, a dire il vero, piuttosto semplice, che guardi funzionare e pensi “come ho fatto fino ad ora senza?”.

Finalmente è possibile Implementare un sistema Big Data e organizzare il trasferimento continuo ed efficiente di dati eterogenei senza mal di testa, senza limitazioni e, perfino, senza costi di licenza.

Ma prima di svelarti come funziona il Mangiabidoni, seguimi nel racconto di tutte le inefficienze nelle quali questa meravigliosa “creatura” ti evita di incappare quando costruisci un Sistema Big Data.

Vuoi perdere tempo, soldi e opportunità?

Bene. Allora, la prossima volta che devi costruire un sistema Big Data, adotta un approccio destrutturato, improvvisato e attivati solo per rispondere alle immediate esigenze o, peggio, urgenze, del tuo business o di quello dei tuoi clienti.

In questo modo, puoi starne certo, il tuo progetto è destinato al fallimento perché incapace di crescere nel tempo.

È questo il punto: il tuo repository, y deve essere talmente bene organizzato da poter evolvere organicamente con te e la tua azienda. Altrimenti, periodicamente, sei costretto a reinvestire da zero in tecnologie e ore uomo.

Un esempio di cattiva prassi sono le estrazioni puntuali provenienti dalle basi dati applicative, fatte su richiesta e prodotte in formato CSV, Excel o testuali. La produzione continua di questi file tende a popolare Il sistema Big Data in maniera piuttosto disordinata fino a raggiungere la totale inutilizzabilità dei dati.

La chiave è l’omogeneità!

L’esigenza di elaborare Big Data richiede una capacità di archiviazione importante, oltre che la necessità di parallelizzare i processi di elaborazione e di computo.

Ciò è possibile solo se possiedi un repository di dati omogenei, anche se provenienti da tante fonti diverse, che non coincide con un database relazionale o colonnare.

Con dati eterogenei, invece, risulta complicato costruire un sistema “Big Data” funzionante e duraturo e le insidie nelle scelte tecniche che vanno fatte per estrarre i dati dalle fonti legacy sono sempre dietro l’angolo.

Vuoi peggiorare la situazione?

Generalmente, per costruire un sistema Big Data, viene utilizzata una raccolta, di framework e utility software open source, presa dalla fondazione Apache. Questo per risolvere problemi che implicano l’elaborazione di enormi quantità di dati.

Tuttavia, queste suite di framework, si presentano come una pletora di sistemi e utility che dovrebbero cooperare insieme per rendere possibile la realizzazione di un sistema scalabile “Big Data”, ma la realtà è diversa da come viene prospettata.

Il fatto che il framework sia realizzato come agglomerato di tanti progetti open source differenti rende la curva di apprendimento all’uso poco inclinata, tanto tempo impiegato per poco apprendimento. Spesso le soluzioni architetturali che si ottengono assomigliano a veri e propri bazar delle tecnologie.

Come si risolve sto casino?

Non c’è dubbio: punta sempre alla costruzione di un’infrastruttura semplice e minimale.

Sostanzialmente hai bisogno di 2 sole componenti importanti, necessarie e implementabili in tempi relativamente “normali”:

  • Hadoop Distributed File System (HDFS) che ti permette di implementare un File System Distribuito, detto solitamente Data Lake, deputato a essere il contenitore di tutte le informazioni aziendali. In questo modo, ti garantisci un accesso ad alta velocità ai file e ai dati, con costi di storage molto bassi, più bassi di qualsiasi altra scelta tecnologica.
  • Apache Spark che implementa il motore di calcolo generale per i dati su HDFS e fornisce un modello di programmazione parallela, relativamente semplice ed espressivo, che utilizza il paradigma “Map-Reduce” con diversi linguaggi e si presta a una vasta gamma di applicazioni, tra cui Machine Learning ed elaborazione di flussi e calcolo.

Quindi il segreto è puntare su un Data Lake?

Sì!

Il repository ideale per un sistema Big Data è un Data Lake, ovvero un File System generico e non un database tradizionale, perché fornisce l’opportunità di trattare e organizzare i dati in maniera aperta e avulsa da formati proprietari, attraverso un’operazione chiamata serializzazione.

La serializzazione dei dati consiste nel leggere le informazioni da fonti diverse, interpretarle secondo le strutture contenute su di esse e riportarle sul Data Lake in un formato testuale strutturato e comprensibile, generalmente Json, XML o CSV. Per esempio, le tabelle di un database relazionale vengono lette all’origine e scritte sul Data Lake come file flat, in formato testo.

È su questi dati serializzati che successivamente vengono organizzate le logiche di elaborazioni massiva e parallela dei processi con Apache Spark.

La soluzione è Il Mangiabidoni

Il famoso Mangiabidoni nasce per mangiare agnosticamente sorgenti dati e copiarle su Data Lake in maniera incrementale.

È un software molto semplice, scritto in C#, che permette la connessione ai DB, utilizzando native clients, a Salesforce, con le sue API, a qualsiasi log testuale, con una classe di parser dedicata, e a Sharepoint, con la capacità di ricorrere tutti i siti e ottenere il contenuto di tutti i documenti. E, ancora, a Teamcenter, Jira, SAP, passando dal layer DB, file pdf, zip che possono essere scaricati da Fornitori di informazioni, cartelle di rete con presentazioni e immagini e ERP basati su mainframe.

La nascita del Mangiabidoni

Ero a lavoro presso un importante cliente quando ho dovuto affrontare la sfida di dover realizzare un sistema di serializzazione per un Data Lake basato su HDFS.

Mi sono messo, quindi, a vagliare le possibili strategie offerte dai tanti prodotti sul mercato, senza, però, trovare nulla di soddisfacente.

L’esigenza del cliente, una multinazionale del manufacturing italiana, era quella di creare in sistema in grado di attingere i dati da diverse fonti, File Log Testuali provenienti dalle linee di produzione, tabelle di database nei vari MES di fabbrica, tabelle di database provenienti dal CRM SAP DB2 e messaggi provenienti da eventi di diversa natura, con lo scopo di serializzarli sul Data Lake.

I principi che regolano il Mangiabidoni

I principi che si è deciso di seguire per creare una corretta architettura di importazione e serializzazione dei dati provenienti da diverse fonti sono i seguenti:

  • agente software multipiattaforma;
  • non necessita di database o altri sistemi di supporto;
  • configurazione centralizzata su Data Lake;
  • lettura e scrittura, in modalità streaming, a basso consumo di memoria;
  • serializzazione Json con formato dato che si auto-descrive;
  • auto-riparazione in caso di interruzione accidentale del processo;
  • log di esecuzione centralizzati su Data Lake;
  • sincronizzazione dei dati per differenza (change data capture – CDC – pattern).

Le sfide. Ecco perché non lo avevano ancora inventato

Le sfide più grandi che ho dovuto superare sono state:

  • l’assenza di un Datawarehouse;
  • l’implementazione di un pattern CDC:
    1. senza poter modificare il layer applicativo delle sorgenti dati;
    2. dovendo lavorare con stratificazioni software che in alcuni casi nascevano negli anni 90 (mi è capitato più di un PC su linea produttiva con sopra windows 95) e senza poter fare affidamento sulla corretta compilazione delle tabelle;
    3. senza poter arricchire le tabelle con colonne di cambio stato;
  • l’organizzazione sensata del Data Lake, battagliando con giovani e baldanzosi Data Scientist pieni di idee molto creative e poco tecniche;
  • disegnare una soluzione sicura, GDPR compliant, e farla accettare al gruppo CyberSecurity, al gruppo infrastrutture e al gruppo network e firewall;
  • garantire la compliance JSOX;
  • convincere il top management che non fosse il tool la chiave di volta, il punto non era scegliere soluzioni best of breed come TIBCO o Mulesoft, ma la forte spinta verso un’architettura software enterprise per la gestione di questi flussi;
  • garantire l’assenza del vendor lock-in.

Tutti questi 7 punti sono stati molto interessanti da affrontare, qualcuno di questi merita sicuramente un approfondimento.

La prima sfida si è rivelata cruciale: l’assenza di un Datawarehouse, quindi del tentativo di fare questo lavoro in modo strutturato negli ultimi 30 anni, mi ha dato l’opportunità di partire da un terreno vergine per costruire.

A questo scopo si è rivelato cruciale, per convincere il top management, un famoso report di Gartner che spiegava come, nel caso in cui l’azienda non avesse ancora un Datawarehouse, il loro consiglio fosse di partire con la creazione di un Data Lake come single point of truth e di riversarlo a batch time sul Datawarehouse che sarebbe nato di lì a poco.

Il Mangiabidoni e la sua estrazione incrementale

La parte tecnicamente più sfidante è stata la creazione di un pattern di estrazione incrementale.

Tutto è partito dalla definizione di un insieme pieno: i dati possono essere o log (quindi dati scritti in modalità append only e con una colonna che ne rappresenta la cronosequenza) o dati di tipo anagrafici (quindi dati scritti con tutti e tre i verbi del SQL, insert, append e delete).

Definito questo insieme pieno, ho creato due strategie:

  • una strategia che andasse bene con i dati di log, definendo di volta in volta una condizione “where” dedicata;
  • un’altra che andasse bene con le anagrafiche, similmente a quello che fa github quando deve mergiare due commit.

Il lasciapassare del team di Cybersecurity

La soluzione disegnata doveva essere validata dal team di Cybesecurity, motivo per il quale l’attenzione dedicata alle tematiche di security è stata molta.

Per quanto su questo punto stiamo ancora lavorando, alla fine del rilascio attuale la soluzione sarà al 100% compliant col GDPR, tracciando tutti gli spostamenti dei dati e garantendone la cifratura, e sarà anche compliant col JSOX, garantendo che nessuno abbia modificato dei dati at rest e che ogni processo venga tracciato e curato a dovere.

Gli ultimi due punti in realtà collassano in uno. I problemi organizzativi sono stati:

  • questa soluzione non è stata implementata da una top 4 e non è stata neanche validata da una top 3 (anche se Microsoft, Databricks e Gartner sono state inchiestate e tutte e 3 le aziende hanno confermato l’assoluta innovatività e validità della soluzione)
  • questa soluzione non utilizza quello che Gartner avrebbe messo in alto a DX – quello che dico sempre io è che “se l’ha scritto Gartner in un suo quadrante, non è abbastanza innovativo”; 😀
  • non voglio legarmi mani e piedi a un fornitore software – come già fatto in passato;

Il Mangiabidoni – non ha costi di licenza!

Per convincere il top management, la scelta concordata con il referente interno è stata quella di proporre una soluzione senza costi di licenze.

Si hai capito bene: l’architettura che gestisce circa 250M di inserimenti e update al giorno non ha costi di licenze. Da una parte, l’utilizzo sapiente di alcuni servizi PAAS di Microsoft ha permesso di creare un cost model che scalasse coi dati (quindi niente stime esoteriche del numero di core da comprare). Dall’altra, un make di qualità sulle sfide più complicate ha permesso di andare oltre i migliori tool di mercato.

File excel. Un esempio applicativo

Una specializzazione particolare è stata fatta verso i file excel, che su questo cliente svolgono compiti svariati: dal supporto alle funzioni finance, al metodo con cui vengono valutate le gare del purchasing, passando per la gestione applicativa dei KPI del manufacturing come OEE e OLE.

Il connettore mangiabidoni excel riesce infatti a estrarre dati da qualsiasi versione di excel, dal 97 in poi, superare fogli protetti da password – senza bucarli ma sapendo la password 😀 – gestire macro, connessioni OLE DB con database, leggere da remoto e fare copie di valori per evitare lock.

I competitor del Mangiabidoni

Ecco.

A questo punto, avrai capito che non esistono veri competitor per questo software e che non è il suo nome a essere buffo, ma piuttosto i tanti limiti delle altre soluzioni ETL.

Con la semplicità predicata dall’approccio KISS (keep it simple, stupid), 300 righe di codice hanno battuto mostri sacri come:

  1. Attunity, per via della sua configurazione non ottimale;
  2. Talend che litiga con le tabelle senza chiavi primarie;
  3. Mulesoft, dal costo per core elevato e dalla complessità di implementazione molto alta;
  4. Denodo, non essendo chiaro quale componente ospiti i processi di integrazione;
  5. Azure Data Factory che richiede un lock-in molto forte verso Microsoft;
  6. Apache Flume che non riesce a gestire il CDC senza entrare nel merito della tabella e utilizzando il pattern CDC della colonna di stato;
  7. TIBCO, visto i costi progettuali.

In più, il Mangiabidoni garantisce un tempo di configurazione che varia dalle 4 ore ai 5 giorni, per integrare una nuova sorgente: difficile da battere con qualsiasi tool di mercato.

Ti interessa scoprire se anche tu e la tua azienda potete sfruttare l’unico software in grado di “mangiare bidoni di dati” a una velocità impressionante?

Compila il form in basso per richiedermi una consulenza gratuita.







AccettoNon accetto


AcconsentoNon acconsento