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.

“Eureka! I dati non mentono:

possiamo investire tutte le risorse della nostra azienda in questo progetto!”

Sei (tristi e caotici) mesi dopo, la stessa azienda fallì.

Come è possibile che i dati possano portarci a compiere cattive decisioni?

Sono numeri e dovrebbe essere facile interpretarli con le tecnologie disponibili sul mercato e promosse dalle big della consulenza.

Il punto è che non esiste nessuna tecnologia “pronta all’uso” che possa garantirti di scoprire il “Sacro Graal” nascosto nei dati della tua azienda o di quella dei tuoi clienti.

Dipende tutto dalle capacità delle persone che prendono in carico l’analisi e l’elaborazione dei tuoi dati.

Allora, dato che si sente sempre più spesso parlare di strategie e approcci Data Driven e che questa è diventata una delle aree di maggior investimento delle aziende, anche in Italia, è arrivato il momento di fare luce sulle principali cause che portano all’errata interpretazione dei dati.

Sono “Lo Scienziato”, ogni giorno aiuto imprenditori e manager a prendere decisioni informate e ad acquisire concreti vantaggi competitivi, e oggi ti parlerò dei 6 errori che, troppo spesso, vedo compiere.

Leggi con attenzione quanto segue perché è facile gridare “Eureka” per poi accorgersi di aver semplicemente preso un abbaglio.

1) Anche se hai odiato l’esame di statistica, conoscerla è fondamentale!

Che tu sia il professionista che conduce l’analisi o il manager che gestisce il gruppo di data scientist, le conoscenze sono tutto quando maneggi i dati.

Ad esempio, la differenza tra media e mediana e il tipo di filtro che entrambe introducono sui dati sono delle nozioni elementari che ti permettono di evitare errori grossolani.

Facciamo un esempio.

Immagina che la tua azienda voglia calcolare l’efficienza dei suoi corrieri per premiare i più meritevoli: quello che verrebbe in mente è di cercare un valore significativo che rappresenti l’efficienza di un corriere e studiarne l’evoluzione nel tempo.

Sicuramente, andresti alla ricerca di un sistema per tenere traccia dell’istante in cui viene fatta ogni consegna: una prima intuizione, ragionevole e corretta, potrebbe essere quella di utilizzare il tempo intercorso tra due consegne come indicazione del tempo di consegna.

Potresti voler “normalizzare” questo valore in base alla distanza percorsa, tenendo conto del traffico: ti troveresti così davanti a una serie di tempi normalizzati sicuramente interessanti.

Ora, la tentazione di calcolare la media, magari giorno per giorno, è sicuramente forte. In questo modo, forse, potresti rispondere prontamente alla richiesta di ottimizzazione dei processi dei corrieri. Ma è l’approccio giusto?

Andando a studiare i dati così raccolti e messi a sistema (in media), quello che si noterebbe è che c’è una consegna ogni giorno che dura un’ora più delle altre (quella fatta a cavallo dell’ora di pranzo) e un’altra che dura ben 14 ore più delle altre (quella di fine giornata).

In più, probabilmente, ogni giorno, potresti incorrere nell’errore di calcolare 2-4 consegne che, in realtà, non avvengono mai (una per ogni pausa del corriere).

In questo caso-esempio la mediana avrebbe risolto il problema, essendo un filtro particolarmente efficace nell’eliminazione di outlier sistematici (valori anomali).

Prendendo infatti quel valore che divide a metà i tempi di consegna e non quel valore che li somma tutti, andresti a cancellare quei pochi cicli poco significativi (fasce orarie nelle quali i poveri corrieri che stai valutando erano in pausa o, addirittura, a casa con moglie e figli).

2) Non confondere la causalità con la casualità!

Alcune volte, potresti notare che c’è una fortissima correlazione fra due tipologie di eventi.

Attenzione! Esistono tantissimi esempi famosi di variabili che sono fortemente correlate ma senza nessun legame di causalità.

Si tratta di fortunati o sfortunati casi che complicano la vita quando si lavora coi dati. Quindi, prima di generare dei falsi insight (quindi giungere a conclusioni errate), è necessario prendere il giusto tempo per riflettere su quanto trovato.

Ma come farlo in maniera “scientifica”?

3) Prima di cominciare, decidi come ti valuterai!

Valutare quello che stai facendo o sapere come il tuo gruppo di lavoro si valuterà è di fondamentale importanza.

Facciamo un altro esempio.

Immagina di trovarti davanti a una classe di ingegneria informatica di 100 persone e di voler prevedere il sesso delle stesse conoscendo l’altezza e il peso: niente di più semplice, penserai. Statisticamente, è molto probabile che le persone più alte e pesanti siano uomini e, viceversa, le altre saranno donne.

Bene. Cosa accadrebbe se ti dicessi che in questa classe ci sono 99 aspiranti ingegneri e una sola aspirante ingegnera?

Un algoritmo che dice sempre “uomo” avrà un’efficacia altissima: indovinerà il 99% delle volte (si può, quindi, parlare di precisione). Avrà però una scarsissima capacità di riconoscere le donne (definita recall@donna), riconoscendone lo 0%.

Allo stesso modo, un algoritmo che massimizza invece la capacità di riconoscere le donne (recall@donna) sarà quello che dice sempre donna, non riconoscendo la presenza di neanche un uomo.

Insomma, non esiste IL modo per classificare un algoritmo in assoluto.

Esiste solo IL modo migliore rispetto al problema che la tua azienda o i tuoi clienti stanno cercando di risolvere con il modello utilizzato.

Ogni volta che il tuo modello commette un errore, l’azienda ne pagherà le conseguenze a livello economico (come mancato incasso, come mancata previsione di un guasto, …).

Insomma, quando lavori con i dati o affidi questo compito a uno specialista, devi sempre calcolare il costo economico di ogni errore e cercare di ottimizzare il modello per minimizzarlo.

4) Se ottieni un risultato troppo buono al primo colpo, hai sbagliato qualcosa!

Ottenere una precisione del 99% al primo colpo può voler dire due cose (entrambe non entusiasmanti):

– hai uno sbilanciamento fortissimo fra le due classi che vuoi prevedere (vedi l’esempio precedente);

– hai codificato alcune informazioni del dataset di test nel dataset di training e il modello, trovando situazioni che già conosce, ti restituisce sempre la risposta “giusta”.

Questa situazione, definita tecnicamente “leaking”, è estremamente complessa da riconoscere: infatti, quando succede bisogna entrare nel merito applicativo di come sono state estratte e poi combinate le features.

5) Hai tante frecce al tuo arco. Sai come utilizzarle?

L’hype sulle nuove tecnologie è altissimo.

Dal mondo del deep learning con complesse architetture di rete, ad algoritmi ottimizzati su hardware: le nuove possibilità sono infinite e, non lo nego, eccitanti.

Il punto, però, è che ci sono tante conoscenze e modelli del mondo tradizionale che spesso vengono deliberatamente ignorate.

Ad esempio, se devi pulire i dati da un segnale periodico, la scelta migliore è quella di lavorare sul piano delle frequenze, utilizzando una trasformata di Fourier, un filtro a spillo e un’antitrasformata di Fuorier.

Inutile cercare soluzioni più complesse, solo perché “alla moda”!

Allo stesso modo, se hai due distribuzioni di campioni da confrontare, il mondo dei test d’ipotesi può tornarti molto utile.

Infatti, se ti aspetti un segnale Gaussiano ma, dopo una prima analisi, dovessi ritrovartene uno appartenente ad altre distribuzioni, potresti trovarti di fronte a un problema di carattere sistematico che non stai considerando.

6) Ci sono conoscenze tecniche di dominio che vanno sempre ricordate!
Ancora una volta, devi fare sempre attenzione verso quello che stai facendo.

Se devi lavorare su segnali elettrici, ricordati di togliere il rumore di rete.

Se devi lavorare con un segnale continuo, ricordati il teorema di Shannon che ci insegna infatti che bisogna campionare un segnale con una frequenza pari al doppio della massima frequenza presente nel segnale (+1).

Ovviamente, se non conosci la frequenza massima, campiona alla massima frequenza che fisicamente sei in grado di campionare. Così, potrai calcolare la frequenza massima presente e poi utilizzare questa informazione per scegliere la frequenza di campionamento.

Se devi lavorare con un’immagine, ricordati sempre di partire applicando un filtro gaussiano.

Se devi lavorare con del testo, rimuovi con cura le stop word e ricordati che ogni dominio ha le sue stop word.