26/11/2020

In questo articolo vogliamo analizzare l’architettura e le funzionalità del nuovo servizio Microsoft Azure Synapse, confrontandolo con lo storico Database Sql Server. Sulla base della nostra esperienza, evidenzieremo le differenti modalità di gestione dei dati che le due tecnologie richiedono in un contesto di Enterprise Data Warehouse.

 

Synapse

 

Annunciato a novembre 2019, Azure Synapse è l’evoluzione di Azure SQL Data Warehouse. Microsoft lo definisce come uno strumento che permette di unire i big data all’enterprise data warehouse (EDWH), portando i vantaggi dei due mondi in un unico servizio cloud ad alte prestazioni e facilmente scalabile. Il passaggio a questa tecnologia però, rispetto all’EDWH tradizionale basato su SQL Server, prevede un diverso approccio alla gestione dei dati e un cambio di mentalità nei confronti dell’ingestion classica dei dati.

 

Cominciamo delineando brevemente le caratteristiche di Azure Synapse e come esso si differenzi profondamente da SQL Server: Synapse si basa su un motore di Massively Parallel Processing (MPP), la cui architettura permette di scalare l’esecuzione delle query su più nodi. La computazione è completamente disaccoppiata dall’archiviazione dei dati (basata su Azure Storage), consente quindi di mettere in pausa il servizio di calcolo, fermando i suoi consumi, ma preservando i dati archiviati.

 

 

L’architettura MPP si compone quindi di diverse componenti:

 

• Nodo di controllo, che riceve le query T-SQL e le distribuisce sui nodi computazionali;
• Nodi computazionali, che eseguono in parallelo i vari processi prima di restituire i risultati al nodo di controllo;
• Data Movement Service, che trasporta i dati tra i nodi computazionali per la corretta esecuzione delle query;
• Azure Storage per l’archiviazione delle tabelle.

 

Le tabelle sono partizionate per l’ottimizzazione delle prestazioni, la scelta del metodo di partizionamento viene fatta in fase di creazione della tabella e può essere di tre tipi:

 

• Hash, dove la tabella viene distribuita utilizzando una funziona di hash calcolata in base al valore di una o più colonne della tabella – questo metodo permette migliori performance delle query;
• Round-robin, dove il dato viene distribuito equamente sulle varie distribuzioni – metodo ideale per le tabelle di staging;
• Replica, dove la tabella è replicata interamente sulle varie distribuzioni – questo metodo è consigliabile per una maggiore velocità di accesso a tabelle di dimensioni ridotte.

 

Sql Server

 

L’architettura di Synapse è molto differente da quella di SQL Server: i dati ed il motore del database di SQL Server risiedono sullo stesso server e quest’ultimo si occupa di eseguire le query utilizzando la potenza computazionale a disposizione del servizio di database. Il modello computazionale non è quindi parallelo, nel senso che le query non vengono eseguite su più macchine in contemporanea e le tabelle non sono (nativamente) ripartite su distribuzioni e non vengono interrogate separatamente; queste ultime sono archiviate utilizzando algoritmi differenti rispetto a quelli di Synapse, principalmente si distinguono tabelle heap, clustered e colonnari.

 

ETL vs ELT

 

Questa differenza nelle modalità di archiviazione e elaborazione dei dati comporta la necessità di affrontare l’acquisizione dei dati su Synapse utilizzando un paradigma diverso da quello dell’ETL classico, l’ELT. L’ELT prevede di trasformare i dati dopo averli caricati sull’ambiente di destinazione, avvantaggiandosi delle prestazioni offerte dal motore del database nell’integrare, calcolare ed aggregare le informazioni.

 

 

Azure Synapse rappresenta un ambiente ideale per l’utilizzo di una logica di tipo ELT grazie all’archiviazione diretta sul file system Azure Storage e alle elevate prestazioni nel trattamento di grandi volumi di dati. Queste caratteristiche consentono di importare nello storage Azure i dati dalle fonti sorgenti e utilizzare l’architettura MPP per caricare i dati direttamente dallo storage all’interno delle tabelle di staging, combinando la semplicità di scrittura e lettura da un file system con i vantaggi della definizione di uno schema per le tabelle durante l’importazione.

 

 

Questo tipo di scenario però, unito alle limitazioni rispetto ad alcuni costrutti SQL disponibili su SQL Server, rende necessario ripensare la trasformazione dei dati, le modalità di gestione dello storico e più in generale il disegno della base dati EDWH su Synapse.

 

Se infatti la velocità nell’importazione dei dati su Synapse è molto elevata, una volta create le tabelle di staging sul DataWarehouse, alcuni comandi SQL non sono disponibili; in particolare non è disponibile il comando MERGE (o un comando analogo in grado di effettuare UPSERT) e ci sono limitazioni nell’uso delle JOIN esplicite nelle clausole FROM nei comandi di UPDATE e DELETE. Questo ha certamente un impatto sul modo di caricare i dati in un EDWH.

 

Su SQL Server, una volta caricati i dati sorgenti nelle tabelle di staging, questi vengono portati nelle tabelle finali tramite operazioni di JOIN, vengono effettuati eventuali controlli di coerenza dei dati e applicate le opportune politiche per la gestione delle variazioni e della storicizzazione dei dati.

 

Per effettuare queste operazioni in Synapse, ci sono diversi modi. Una prima soluzione “di forza bruta” è quella di sfruttare le enormi potenzialità dello strumento. Se le condizioni lo consentono (per dimensioni dei dati e velocità di estrazione dall’origine, oppure per la preponderanza di dati nuovi o modificati sul totale) possiamo importare per intero la tabella ad ogni caricamento, creando delle fotografie complete della base dati. Questa soluzione è funzionale per i casi in cui la nuova versione della tabella sostituisce completamente la precedente, oppure se il dato storico non è oggetto di frequenti query.

 

Questa prima soluzione fa leva sulle maggiori capacità di elaborazione ed archiviazione del dato di Synapse rispetto a SQL Server e sottende un modo di vedere l’EDWH diverso da quello classico: prima si importa il dato e si demanda alle estrazioni l’applicazione delle logiche.

 

Una seconda soluzione è invece quella di implementare la parte d’identificazione delle variazioni dei dati attraverso l’uso dei comandi disponibili in Synapse. Questo si ottiene facendo ricorso al comando CREATE TABLE AS SELECT (CTAS): questo comando consente di creare delle tabelle leggendo direttamente i dati da un’altra tabella o da un file. Utilizzando il CTAS per creare delle tabelle temporanee di appoggio, si possono materializzare i passaggi necessari a eseguire MERGE o UPDATE non supportate dalla sintassi di Synapse. Per esempio, è possibile materializzare il risultato di una JOIN necessaria per un UPDATE, per poi aggiornare la tabella di destinazione mediante una JOIN implicita con la tabella temporanea.

 

Ma non è finita qui, tra le funzionalità in preview sono presenti alcune possibilità per venire incontro a queste necessità. Una di queste possibilità prevede l’utilizzo di Azure Data Factory, lo strumento Azure per l’orchestrazione dei dati. All’interno di una pipeline creata utilizzando Azure Data Factory è possibile utilizzare Synapse come destinazione e impostare il metodo di UPDATE che consente di gestire gli UPSERT.

 

Un’altra tecnologia in preview è Delta Lake, layer che consente di gestire le transazioni ACID tramite Spark. L’interazione con Synapse avviene tramite Azure Databricks, che consente di spostare i dati da Azure Storage verso Synapse e di trasformarli usufruendo dei vantaggi della computazione parallela forniti da Spark. È doveroso sottolineare che l’utilizzo congiunto di Spark e Synapse va oltre l’alimentazione del layer dati, apre infatti scenari estremamente interessanti in termini di analisi avanzate e modelli predittivi.

 

Conclusioni

 

Abbiamo visto come si differenziano tra di loro SQL Server e Azure Synapse e dei differenti approcci da utilizzare per la creazione di un EDWH utilizzando quest’ultima tecnologia. Anche se rispetto al classico approccio su SQL Server, è necessario un cambio di paradigma, i vantaggi in fatto di scalabilità, parallelismo, gestione dei big data e integrazione con Spark rendono Synapse una scelta potenzialmente migliore di SQL Server.

 

Dal nostro punto di vista non riteniamo però che si debba pensionare Sql Server ed optare sempre e comunque su Synapse per la creazione di un Data Warehouse, perché dipende molto dal contesto di utilizzo. Ci sono degli specifici scenari per i quali Synapse è stato pensato e delle condizioni senza le quali la sua scelta non comporta sostanziali vantaggi, soprattutto in termini di volumi di dati e necessità di analisi. Un suggerimento che riteniamo utile aldilà della piattaforma tecnologica è quello di valutare attentamente la logica (ETL/ELT) di caricamento di un EDWH, come abbiamo visto il paradigma ELT può portare dei benefici in termini di semplificazione e velocità dei processi.

[hfcm id=”39″]

28/09/2020

Aubay Italia è il partner tecnologico del Napoli Fintech Lab, promosso dal DISAQ | Dipartimento di Studi Aziendali e Quantitativi dell’Università di Napoli Parthenope, insieme a tre partner finanziari: UBI Banca, BPER Banca, ING.

 

l Napoli FinTech Lab è un laboratorio di alta formazione per lo studio e l’applicazione delle nuove tecnologie nel settore finanziario.

 

Siamo felici di aderire alla proposta di un modello formativo nuovo che offre ai migliori studenti e startupper un percorso di alta formazione a titolo gratuito e si propone di creare il primo Ecosistema Verticale del Sud Italia con focus sul FinTech.

 

La nostra partecipazione alla fase di selezione, formazione, start-up e open innovation, contribuisce al disegno di un modo virtuoso di fare formazione e impresa con un impatto sociale tangibile.

 

Inoltre il progetto si inserisce nel nostro processo interno di talent management e alcuni di coloro che risulteranno idonei potranno partecipare al percorso di alta formazione del Napoli Fintech Lab.

 

Chi fosse interessato può trovare ulteriori informazioni sul sito del Dipartimento di Studi Aziendali e Quantitativi

[hfcm id=”39″]

23/09/2020

È lunedì mattina di una calda e stanca settimana settembrina. Cado giù dal letto, in ritardo. Mi muovo tra la cucina ed il tavolo come in un percorso ad ostacoli, sembro un equilibrista: in una mano la tazzina di caffè troppo calda e nell’altra le dita corrono veloci per abbottonare il colletto troppo stretto di una camicia alla koreana. Lo smart working ha abbattuto quel confine sottile tra la confezione di biscotti e le briciole sulla tastiera del pc.

 

Dicevo, in ritardo perché alle 9.15 si tiene un incontro su piattaforma cisco webex, la nuova sala riunioni, sicuramente più informale ma altrettanto rumorosa, coi microfoni lasciati accesi che intercettano i rumori di sottofondo delle nostre case e dei personaggi che le abitano.

 

Questa volta, però, è un incontro speciale, la Welcome Hour, un incontro di onboarding dove come struttura Hr, diamo il benvenuto alle nuove risorse che ci hanno scelto, nonostante la smaterializzazione degli spazi, nonostante il momento di incertezza nazionale e mondiale. Ho sempre trovato la parola crisi etimologicamente speciale, uno di quei casi in cui dietro un’accezione apparentemente negativa si cela un’opportunità, un’occasione: crisi, infatti, è scelta e quello che abbiamo fatto in Aubay Italia con la Welcome Hour è stato scegliere di utilizzare il distanziamento per raggiungere tutti nello stesso momento, abbattere barriere invece di costruirne e potenziare il linguaggio delle immagini al posto della stretta di mano. Durante l’incontro si condividono idee, aspettative, perplessità rispetto al nuovo habitat aziendale e come struttura Hr raccontiamo il nostro caleidoscopico contesto aziendale, fornendo una mappa con cui muovere i primi passi.

 

Mi piace pensare a questo momento con le nuove risorse come ad una festa, dove persone con storie diverse s’incontrano con la stessa volontà di condivisone e senso di appartenenza. Con la Welcome Hour, infatti, vogliamo celebrare, trasformare un limite in un punto di forza, spingere l’elemento umano, vera forza, oltre i limiti fisici dello spazio.

 

Ora, però, è tempo di iniziare, la camicia è sistemata, la cam accesa e gli ospiti in attesa… << benvenuti! >>

[hfcm id=”39″]

05/08/2020

Il nostro Competence Center Big Data & Advanced Analytics, composto da oltre di 250 risorse con solide competenze su processi, tecnologie e metodologie che afferiscono a queste tematiche, ha il compito di erogare servizi in ambito Enterprise Information Management. Dal disegno strategico fino alla gestione delle applicazioni, dal supporto tecnologico allo sviluppo di progettualità in ambito BI sia tradizionale che innovativa, abbiamo solide competenze ed esperienze da mettere a disposizione dei clienti.

 

Oggi vi raccontiamo un caso di successo che hanno portato a termine i colleghi del competence center grazie all’integrazione della tecnologia AWS nel sistema di analisi dati Mediaset Play, ottenendo come valore per il cliente la riduzione dei tempi e un’analisi migliore delle informazioni.

 

L’Azienda aveva la necessità di monitorare, su base storica, il comportamento degli utenti tenuto durante la visione dei canali Mediaset tramite l’app Mediaset Play. Aubay ha quindi realizzato un sistema basato su architettura AWS che raccoglie tutti i dati provenienti dai connected device (Smart TV, set-top-box) sintonizzati sui canali Mediaset utilizzando il canale di comunicazione broadband. I dati prodotti dalle connected device venivano collezionati attraverso Amazon Kinesys all’interno di un data lake S3. Il progetto ha previsto la pulizia e l’aggregazione del dato attraverso Amazon Pipeline, l’integrazione all’interno di Redshift ed infine l’analisi su Dashboard QlikSense.

 

L’App finale “Mediaset Play KPI” consente di visualizzare i principali KPI di interesse per analizzare l’attività degli utenti tramite l’utilizzo dell’Enabler presente sulle Smart TV.

 

I principali benefici ottenuti, rispetto alla soluzione precedente, sono:

 

• Riduzione dei tempi di elaborazione e disponibilità del dato aggiornato ad inizio giornata.

 

• Alleggerimento del carico di lavoro sul DataLake.

 

• Possibilità di scalare in termini computazionali/prestazionali in qualsiasi momento all’aumentare dei volumi dati.

 

• Possibilità di fare analisi su dati storici pre aggregati.

 

[hfcm id=”39″]

07/07/2020

La vicinanza al cliente è uno dei valori principali di Aubay; come UX Designer abbiamo la possibilità, ogni giorno, di sostenere questo valore perché la nostra professione è orientata alle persone.
L’utente, con i suoi bisogni, è al centro del nostro lavoro.

 

Come consulenti IT esperti nel campo della User Experience, abbiamo da sempre cercato di tradurre le esigenze dei Clienti in soluzioni che soddisfino gli obiettivi di business, guidandoli nelle scelte tecnologiche più adatte ed innovative.

 

Abbiamo reso questo nostro approccio ancora più professionale con la nascita del User Experience Design (UXD), metodologia che ha come obiettivo quello di rendere l’esperienza utente la migliore possibile. Ci siamo aggiornati e formati su queste nuove tecniche, migliorando e velocizzando la progettazione delle soluzioni e dei servizi per i nostri Clienti.

 

La nostra crescita professionale è stata nel tempo arricchita da corsi di formazione specifici ed esperienza sul campo, dando modo al Competence Center Microsoft di Aubay di aggiungere una nuova “focus area”: Microsoft User Experience & User Interface.

 

Negli ultimi quattro anni, abbiamo messo in pratica le conoscenze acquisite in ogni applicazione web e mobile, portale pubblico o intranet che abbiamo implementato, cercando sempre di rendere ogni azione utilizzabile e accattivante per l’utente finale.

 

A tal proposito, una case history interessante è quella del progetto BeepCar realizzata per una delle principali realtà nel settore automotive presente da più di 60 anni sul mercato della vendita delle autovetture e dei veicoli industriali.
BeepCar è un’applicazione mobile per la gestione e l’ottimizzazione della movimentazione dei veicoli sulle bisarche da una sede all’altra del Cliente.
Le necessità del Cliente erano facilitare e snellire il lavoro dei bisarchisti (addetti al carico e scarico delle bisarche), aggiornare in tempo reale lo status del veicolo e pianificare i viaggi delle singole bisarche con il relativo documento di trasporto.
Le fasi che hanno scandito la vita del progetto sono state seguite dal tutto il gruppo di lavoro creando la sinergia ottimale tra noi e il Cliente:

 

– Analisi requisiti
– Studio UX
– Integrazione sistema Ottimizzazione Bloomy Decision
– Integrazione sistema DMS Infinity
– Sviluppo APP in tecnologia Xamarin

 

La fase dello Studio UX è stata orientata alla visione più attuale, e maggiormente utilizzata dagli esperti del settore, che si fonda sulla risoluzione pratica e creativa dei problemi, il Design Thinking.
Una metodologia estremamente incentrata sul Cliente. Un processo iterativo che favorisce la sperimentazione in corso d’opera, fino a trovare la giusta soluzione.
Di seguito le 5 fasi che caratterizzano l’approccio e che abbiamo utilizzato nel progetto.

 

 

Primo obiettivo è stato quello di creare empatia con il Cliente che si pone così al centro dell’iniziativa non solo dal punto di vista del business. La raccolta dei requisiti è avvenuta osservando ed interagendo con le persone, senza imporre regole assolute o standard precodificati, ma personalizzando l’analisi all’esigenza degli utenti che utilizzeranno la soluzione proposta.
Una volta definite chiaramente le necessità del Cliente, le abbiamo tradotte in un Concept, per poi trovare soluzioni e idee, scegliere le tecnologie più adatte, determinare gli attori da coinvolgere nella realizzazione del progetto.

 

Abbiamo così dato il via alla terza fase del processo di Design Thinking, l’ideazione: una delle fasi più interessanti e “divertenti”, dove chi ha raccolto i requisiti si confronta con lo User Interface Designer.
In questo caso, con la tecnica del brainstorming, abbiamo definito l’Interaction Design dell’applicazione disegnando i wireframe per descrivere l’interattività.
I wireframe sono poi stati tradotti nella User Interface dal designer, cioè nel mock up, definendo così il look & feel dell’applicazione, creando infine la Flow Interaction utile per presentare concretamente l’idea al Cliente.

 

Il Cliente, approvando la nostra proposta, ha autorizzato lo sviluppo del prototipo dell’APP: una APP installabile su device con le principali funzionalità attive. Questo passaggio è stato fondamentale per mettere alla prova ogni soluzione ed evidenziare eventuali vincoli e difetti di design.
Il prototipo è stato testato dal Cliente portando alla luce use case che non rientravano nei requisiti iniziali, ma in grado di arricchire la soluzione finale.
Gli sviluppatori hanno poi corretto e migliorato l’interazione interfacciandosi con il team di “user Interface”, così da avvicinare ancor più il risultato finale ai desiderata dell’Utente stesso.

 

Questa metodologia ha reso poi possibile la nascita vera e propria dell’APP BeepCar!
In brevissimo tempo più di 1000 utenti hanno scaricato dagli store la BeepCar unica nel suo genere, la quale è diventata indispensabile in diverse aziende europee. Processo che ha reso possibile un upgrade in brevissimo tempo rendendola Multilingua.

 

La competenza del team “UX Designer” è a disposizione dei colleghi delle varie Business Unit di Aubay.
I nostri servizi migliorano con il tempo, in quanto sempre più progetti arrivano sulle nostre scrivanie permettendoci di essere innovativi e di aiuto ai colleghi; la teoria alla base della User Experience è caratterizzata da svariate tecniche e strumenti perciò ogni progetto è diverso e nuovo allo stesso tempo.

 

La User Experience è essenziale! Deve essere centrale in ogni fase di sviluppo del progetto; sono ormai risaputi i benefici di questo approccio che i nostri Clienti richiedono sempre di più.

“Il design era il condimento che spruzzavi per gusto; ora è la farina di cui hai bisogno all’inizio della ricetta.” – John Maeda, designer e tecnologo.