Fondo di Crescita Sostenibile - Sportello “Fabbrica intelligente”
ID Posizione 108
Soggetti proponenti: Energent S.p.A. - Tecso s.r.l.
Progetto Laocoonte
Design Macroblocco 1 - Architettura ETL
Gli ETL (Extract, Transform, Load) tradizionali sono strumenti molto potenti in quanto consentono di agire sulle basi dati e trasformarle in formati utilizzabili da altri strumenti.
Spesso però sia prodotti commerciali sia open source richiedono una profonda conoscenza di strumenti informatici (es. Bonobo, open source scritto in python richiede l’utilizzo della command line per effettuare le operazioni sulle basi dati). Anche strumenti più evoluti come Pentaho (che saranno utilizzati durante il progetto) e con interfacce grafiche che ne rendono più semplice l’utilizzo, richiedono comunque una conoscenza delle strutture dei dati, dei database o dell’ambito di utilizzo (ad esempio il significato di tutti gli attributi del dataset).
In una prima fase del progetto l’utilizzo di questi strumenti è sicuramente indispensabile, tuttavia attraverso un approccio sistematico allo sviluppo, sarà realizzato un wizard che consentirà di effettuare la regolarizzazione, la pulizia e la selezione degli attributi più rilevanti da mantenere nell’analisi per le fasi successive, ovvero per la classificazione e la predizione.
Figura 1. Schema Macroblocco ETL
info@energent.it 2 Tale strumento consentirà di effettuare diverse funzionalità localmente e di interfacciare gli altri macroblocchi come descritto nei seguenti punti:
• Invio dati a blocchi o incrementali sul DB che conserva i dati ripuliti e pronti per essere utilizzati per la classificazione
• Elaborazione della strategia di aggiornamento (bulk, incrementale, con Transfer Learning)
• Acquisizione dei dati da gruppi di utenti (che valuteranno anche la user experience)
• Creazione della struttura dei form che successivamente dovranno aiutare l’esperto di dominio a comporre i record aggiuntivi da sottoporre ad analisi predittiva
L’architettura del macroblocco sarà organizzata come segue:
• Il modulo di elaborazione e trasformazione dei dati verrà realizzato mediante l’utilizzo del tool Pentaho
• Il modulo di calcolo del guadagno informativo, la regolarizzazione e la selezione degli attributi significativi avverrà utilizzando gli appositi moduli Weka
• Il modulo di presentazione dei form e che consentirà di caricare i dati aggiuntivi al momento di aggiornare sarà sviluppato in Angular e attraverso l’integrazione del framework Liferay
Tool Pentaho Data Integrator
• La suite di analisi e visualizzazione dei risultati sarà realizzata utilizzando il tool BIRT
• L’archivio dei dati di analisi e dei dati di sistema verrà realizzato su base dati relazionale, noSQL con metodologie innovative
Tool Weka - "Waikato Environment for Knowledge Analysis”
Il modulo di analisi predittiva sarà realizzato a partire da un motore open source denominato Weka. Weka, acronimo di "Waikato Environment for Knowledge Analysis", è un software per l'apprendimento automatico sviluppato nell'università di Waikato in Nuova Zelanda. È open source e viene distribuito con licenza GNU General Public License. Il workbench Weka è un sistema software interamente scritto in Java e consiste in una avanzata raccolta di algoritmi e tecniche di preprocessamento del machine learning. Weka è stato disegnato per testare su insiemi di dati diversi metodologie esistenti, velocemente e in modo flessibile; prevede infatti il supporto per tutto il processo sperimentativo del data mining: la preparazione dei dati di input, la
info@energent.it 3 valutazione statistica degli schemi di apprendimento, la visualizzazione grafica dei dati di input e del risultato dell‘apprendimento.
Tool Liferay
Il framework Liferay consentirà oltre a presentare una maschera di gestione e l’interfaccia di comunicazione con l’utente, anche la profilatura degli accessi, la libreria dei documenti e, aspetto di enorme rilevanza, l’amministrazione del portale stesso.
Sottosistema Data Cleansing e Data Masking
Il sottosistema “Data Masking” sarà elaborato attraverso una prima fase di analisi delle necessità di stakeholders per chiarire gli obiettivi prefigurati e circoscrivere il perimetro di pre-assessment. Successivamente sarà definito un piano di interviste che deve coinvolgere referenti e responsabili, per acquisire le informazioni necessarie alla conduzione di una GAP Analisys rispetto ad un benchmark di mercato. Le informazioni acquisite sono necessarie per la validazione dei requisiti della piattaforma al fine di predisporre un piano di remediation per gestire le problematiche emerse e per mostrare che una parte di queste problematiche sono risolte dalla piattaforma di Data Masking oggetto della ricerca, ovvero un Open-Data Engine che consenta di importare, esportare ed effettuare il mascheramento dei dati.
Obiettivo di questa fase del progetto di Ricerca e Sviluppo Sperimentale, originale e creativo, è la definizione del concept, il design e l’implementazione di un Open-Data Engine che consenta di importare, esportare ed effettuare il mascheramento dei dati.
Le funzionalità salienti che la contraddistinguono riunite in un'unica interfaccia sono:
• accesso a più DB Relazionali;
• definizione di Query di interrogazione ai dati;
• definizione di una o più aree di Staging;
• memorizzazione del risultato;
• esportazione del risultato in diversi formati;
• esportazione del DB o parte di esso in modalità Data Masking e GDPR Compliant;
• gestione degli accessi a livelli di sicurezza personalizzabili.
L’utente sarà in grado di ottenere in modo rapido ed intuitivo le informazioni, altrimenti ad attività separate dipendenti da più aree di interesse (IT, Applicativo, Business, Security), attraverso uno strumento basato su open source e procedure di caricamento sia on-demand che batch.
info@energent.it 4 La originalità del sottosistema consiste nello studio e nella creazione di nuovi algoritmi di mascheramento che mantengano inalterato il valore della stringa e del data type, la generazione della chiave per decriptare i dati in modo tale da mascherare i dati sensibili con dei cloni. In questo modo, se i dati sono estratti, scritti o manipolati da applicativi che usano gli attributi corrispondenti, continuano a lavorare senza soluzione di continuità sui dati mascherati.
Figura 2. Architettura sottosistema Data Masking
Poiché le sorgenti sono le più disparate e il clone creato per l’accesso ai dati può essere considerato un Data Lake noSql Big Data, in pratica si ribalta il modello adottato dalla maggioranza delle aziende in quanto più DB relazionali confluiscono in un data lake criptato, che è successivamente acceduto per BI, Analisi e Decision Making.
Il rischio tecnologico valutato è influenzato principalmente dalla funzionalità e dalla scalabilità dell’algoritmo di mascheramento e crittazione del dato, determinando così una incertezza dell’esito finale dell’intero sottosistema. Guardando ai prodotti presenti sul mercato, i DB cercano di integrare queste funzionalità, e in particolare mascherano, offuscano ma non decriptano e i prodotti che fanno un tipo di mascheramento simile sono molto costosi e soffrono di limiti di scalabilità, mentre utilizzando Pentaho per la visualizzazione, il tentativo è quello di realizzare una piattaforma economica, scalabile e che utilizzi front-end grafici open source (in questo caso Liferay).
I fattori di rischio non sono tuttavia solo tecnologici, in quanto l’utilizzo della piattaforma prevederebbe un cambiamento delle policy di accesso ai dati, dei tipi di dato consumabili
info@energent.it 5 e utilizzabili, implicando quindi dei cambiamenti di approccio da parte delle aziende che la dovessero adottare.
Sottosistema Wizard per la selezione degli attributi
Per la selezione degli attributi è stato pensato ad un approccio step-by-step conseguito attraverso l’interazione con un esperto di dominio che sia in grado di valutare i risultati ottenuti e selezionare gli attributi con l’ausilio della piattaforma.
Ad esempio, facendo riferimento come esercizio al dataset Titanic sulla piattaforma Open Source Kaggle (https://www.kaggle.com/c/titanic) ed effettuando una valutazione dei guadagni informativi apportati dai diversi attributi, il risultato è rappresentato di seguito ma un data scientist di supporto all’utente del prodotto (necessario nella fase iniziale del design) indicherebbe una possibile identità tra l’attributo “Ticket” e la variabile obiettivo “Survived”. Pertanto, in questo esempio specifico, gli attributi da selezionare sono i primi sei, ad eccezion fatta per l’attributo
“Ticket”.
Figura 3. Selezione degli attributi per Ranking
info@energent.it 6 Come rimuovere una colonna da un dataset, in questo caso utilizzando il dataset iris:
Confrontando i due file notiamo che la seconda colonna è stata rimossa:
Sottosistema Front-End
Il progetto Laocoonte si pone come obiettivo la possibilità di creare un modello, prendendo in considerazione vari algoritmi di Machine Learning, che vada ad incrementare l’accuratezza relativa alla predizione effettuata. Tale modello non è statico ma bensì potrà variare nel tempo in base alle nuove informazioni acquisite grazie all’utilizzo della piattaforma da parte dell’utente finale che andrà a validare o meno le predizioni effettuate.
Come visto nella sezione precedente, deve essere utilizzato il minimo set di informazioni che sono sufficienti ad effettuare la predizione, anche con un’accuratezza molto elevata, e saranno proprio queste informazioni quelle che saranno acquisite dall’utente.
info@energent.it 7 Tale progetto non restringe la tipologia di utente finale, ma deve aprire la possibilità di utilizzo a diversi ambiti e quindi c’è la necessità di creare un form dinamico che consenta l’inserimento e la visualizzazione di dati differenti sia in base allo scopo finale (medico, assicurativo) sia in base all’utente (alcuni utenti potrebbero di modificare/visualizzare solo un sottoinsieme di informazioni rispetto a quelle presenti).
Per la creazione del frontend la prima fase del progetto prevede l’utilizzo del framework Angular ma è prevista l’integrazione con Liferay.
Per la creazione di un form dinamico sarà utilizzato un oggetto JSON contenente tutte le informazioni necessarie per la sua corretta realizzazione. Tale oggetto sarà utilizzato per la creazione del form e sarà restituito dal back-end dopo la creazione del modello e la memorizzazione nel database.
L’oggetto JSON è strutturato in questo modo:
- title: stringa contenente il titolo del form;
- dialogInfo: boolean che indica se è possibile, per il modello preso in esame, visualizzare un popup con le informazioni relative al modello che si sta prendendo in esame ed i possibili cluster;
- dialogInfoForm: un oggetto con le informazioni necessarie a creare il popup contenente le informazioni del modello. Tale oggetto verrà utilizzato solo se dialogInfo è true. Quest’oggetto contiene:
o title: titolo del popup;
o description: una stringa contenente una breve descrizione del modello;
o descriptionCluster: un oggetto contenente le informazioni di ogni cluster ed è composto dalle chiavi:
§ id: identificativo numerico del cluster;
§ name: nome del cluster;
§ description: una breve descrizione;
§ icon: un’eventuale icona associata al cluster;
- cluster: array contenente le informazioni relative ai possibili cluster; ogni elemento della lista è un oggetto contenente le chiavi:
o id: identificativo numerico associato al cluster;
o name: nome del cluster e sarà l’informazione che andrà visualizzata nella variabile target;
- form: array contenente tutti gli elementi che faranno parte del form. Tali elementi sono le informazioni che durante lo studio del modello sono risultati fondamentali per il calcolo della predizione. Ogni oggetto dell’array contiene le chiavi:
o name: nome che identifica l’elemento. Tale chiave sarà restituita, con il valore definito dall’utente, per il calcolo della predizione;
o label: descrizione dell’elemento;
o default: se è associato un valore di default che può essere una stringa o un numero;
o placeholder: è una stringa che permette all’utente di comprendere il campo che sta esaminando. Tale stringa, a differenza della tooltip che sarà resa
info@energent.it 8 visibile solo dal passaggio del mouse sull’etichetta, verrà resa visibile all’interno del componente di inserimento dei dati;
o type: tipologia dell’elelemento ( text, number, select, radio );
o min: indica il minimo numero di caratteri che formano la stringa o il minimo valore che un numero può assumere ( ciò dipende dalla chiave
‘type’ ossia se ‘text’ o ‘number’);
o max: indica il massimo numero di caratteri che formano la stringa o il massimo valore che un numero può assumere ( ciò dipende dalla chiave
‘type’ ossia se ‘text’ o ‘number’);
o options: tale chiave è presente per i type ‘select’ e ‘radio’. Essa contiene le possibili opzioni ed è a sua volta un array di oggetti. Ogni oggetto indica una voce ed è formato da:
§ id: può assumere un valore numerico o una stringa, sarà il valore restituito per il calcolo della predizione;
§ name: l’etichetta leggibile.
o pattern: indica la regular expression che deve rispettare la stringa o il numero per essere considerata corretta;
o patternLabel: una stringa che spiega, in modo comprensibile, l’errore relativo al pattern (altrimenti l’errore restituito sarebbe la regular expression che risulterebbe difficile da comprendere);
o tooltip: stringa descrittiva che aiuta l’utente nella comprensione del campo;
o target: è di tipo boolean ed indica se tale attributo è l’obiettivo dell’analisi, quindi conterrà la predizione e verrà resa non editabile;
o required: indica se tale campo è obbligatorio.
• Una chiave che non è presente all’interno dell’oggetto JSON ma che farà parte del form è accuracy. Tale chiave indica l’accuratezza relativa alla predizione effettuata ed è un numero nel range [0,100]. Essendo presente per tutti i modelli viene aggiunta automaticamente alla fine dell’oggetto.
Il dialogo tra ETL e back-end avverrà attraverso la memorizzazione delle strutture nel database e la successiva acquisizione da parte del back-end al momento di effettuare la classificazione, il calcolo dei modelli e la predizione.
