Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali - A. Mantuano (Cerved)

24 Febbraio 2017

Tra Innovazione e difficoltà su casi reali

Polyglot Persistence e Big Data

Antonello Mantuano – Chief Technology Officer

2

IndiceIl contesto aziendale

Il viaggio verso la Polyglot Persistence

I problemi che abbiamo affrontato

Idee e trade-off verso il futuro

Cos’è la Polyglot Persistence

Il contesto aziendale

4

Il contesto e i suoi numeri

CREDIT INFORMATIONTutelarsi dal rischio dicredito

MARKETING SOLUTIONSCrescere con nuove opportunità di business

CREDIT MANAGEMENTGestire e recuperare i crediti in sofferenza

Ricerche Anagrafiche:

110.000Blocchi di Informazione

Erogati:

2.200.000Chiamate a Servizi

8.500.000

Eventi su Dati

4.500.000Operazioni su Storage

documentale

6.500.000Calcoli Rating

300.000

40 milioni di righe di codice

Services e Microservices

2.500

2.000 Persone 34.000 Clienti

Ricavi 2015 353 Milioni €

1.100 Server On premise e 1.000

TB di Storage

IN UN GIORNO IN CERVED:

5

I nostri “Big Data”

Web Data

Open Data

Dati proprietari

Dato ufficiale non camerale

Dato ufficiale camerale

6

La nostra Evoluzione

MySql

1990.. 2000 2004 2006 2008 2010 2012 2013 2014 2015 2016

Negli ultimi anni ci siamo confrontati con la necessità di gestire tanti dati, di avere un’architettura in grado di elaborare ed erogare sempre meglio questi dati e sistemi in grado di reggere carico sempre crescente.

Rispetto a solo qualche anno fa, è cambiato tutto

01011010

2017

Il viaggio verso la Polyglot Persistence

8

L’evoluzione delle Architetture (fase 0)

DB Rel(Oracle)

Desktop, Browser

Jboss, Tomcat, J2EE

Reporting, BI, ecc…

• Per 2 decadi, i Database relazionali sono stati il core delle applicazioni

• Progettazione database era la fase iniziale di ogni progetto

• Professioni specializzate come i DBA

199x2010

9


DB Rel(Oracle)

Desktop, Browser

Jboss, Tomcat, J2EE


199x2010

DB Rel(Oracle)

Search Engine

(Lucene)

Web Service SOA

Web Server

Browser

Reporting, BI, Predictive Modeling,

ecc…

Graph DB(Neo4J)

20102012

• Affermazione dei Search Engine per ricerche testuali

• Le interrelazioni tra le informazioni sono diventate un valore e hanno messo in crisi il modello relazionale

• I Graph DB hanno reso efficiente la network analysis

10


DB Rel(Oracle)

Desktop, Browser

Jboss, Tomcat, J2EE


DB Rel(Oracle)

Search Engine(Solr)

Web Service SOA

Web Server

Browser


ecc…

• Le applicazioni web sono evolute ed è cresciuta l’esigenza di avere dati complessi disponibili subito

• E’ cresciuta la varietà dei dati, ovvero la fluidità della struttura dei dati

• I Document DB hanno permesso di avere una più alta variabilità dello schema dei dati

Graph DB(Neo4J)

Document DB

(MongoDB)

SOAP API

199x2010

2013

11


DB Rel(Oracle)

Desktop, Browser

Jboss, Tomcat, J2EE


DB Rel(Oracle)

Search Engine(Solr)

Back End for Front End

Web App


ecc…

Graph DB(Neo4J)

Document DB

(MongoDB)

Microservice MicroserviceMicroservice

Mobile App API Portal

199x2010

2014

• L’architettura Microservices ha ulteriormente messo in crisi i DB Rel

• La capacità di scalare delle applicazioni è cresciuta a dismisura ma il DB è rimasto su un unico server/cluster

• La capacità di scaling dei database machine è ridotta e molto costosa

• Mentre gli AS scalano molto facilmente e a costi bassi

12


DB Rel(Oracle)

Desktop, Browser

Jboss, Tomcat, J2EE


DB Rel(Oracle)

Search Engine(Solr)

Back End for Front End

Web App • Elaborare enormi moli di dati, gli algoritmi di Machine Learning e i modelli predittivi, hanno ulteriormente messo in crisi i Rel

• E anche gli altri NoSql hanno mostrato limitazioni

• I Data Lake, basati sull’ecosistema Hadoop, hanno permesso di avere a disposizione sistemi di persistenza pensati per i Big Data

Graph DB(Neo4J)

Document DB

(MongoDB)



Bulk Load Streaming

Hadoop Data Lake

Machine Learning

Predictive Modeling Reporting, BI

199x2010

2016

13

L’Enterprise Architecture 2017

DB Rel(Oracle)

Search Engine(Solr)

BackEnd for Front end

Web App • Obiettivo del 2017 è arricchire il Data Lake per aumentare la nostra capacità di fare algoritmi sui Big Data

• Stiamo passando da una logica ETL a una logica ELT

2017

Graph DB(Neo4J)

Document DB

(MongoDB)



Bulk Load Streaming

Hadoop Data Lake

Machine Learning Predective

ModelingReporting, BI

14

Sourcing Liv.2

Sourcing Liv. 1

REPOS

SYNTH PragmaMond

Dati Lince

CR-RIBA(Payline)

Daticlient

NCA

ERG

EBS

HUB

Mambo

Michelang

DWH MBD

Teradata

Tabula

Mongo4DW

DB4You

XPCH 2

CDRSpazioDati

Matching

Idx Mondo

3

Quaestio

MBD2

Tabula (su AWS)

Aracne

ClientiFornitori

G 4 you

MBD1

Splunk

R3

CAS

Quanto siamo “Poliglotti”

Dedalo

Cos’è la Polyglot Persistence

16

Polyglot Programming

Applications should be written in a mix of languages to take advantage of the fact that different languages are suitable for tackling different problems. Complex applications combine different types of problems, so picking the right language for the job may be more productive than trying to fit all aspects into a single language

2006

Polyglot Persistence

A complex enterprise application uses different kinds of data, and already usually integrates information from different sources. Increasingly we'll see such applications manage their own data using different technologies depending on how the data is used. This trend will be complementary to the trend of breaking up application code into separate components integrating through web services

2011

Cosa si intende per Polyglot Persistence

17

Perchè ci siamo arrivati?

Scalabilità

Funzionalità

DB machine

Browser

Web Server

Web Server

Web Server

Browser Browser

…

…

NoSql

Browser

Web Server

Web Server

Web Server

Browser Browser

…

…

NoSql NoSql…

I DB Machine faticano a scalare all’aumento del carico

I costi di scaling sono elevati

I NoSql nascono per scalare facilmente

Query Gerarchiche

Gestione moli di dati enormi

Query su dati testuali

Mapping Object->Table

Informazioni non strutturate

Aggregate Data Model

Ci sono alcune funzionalità non presenti o non efficienti nei database relazionali

Non sempre il modello relazionale riesce a risolvere tutte le necessità di modellazione

18

Perchè ci siamo arrivati?

Fluidità

Big Data

• I database relazionali richiedono una fase di modellazione onerosa

• La manutenzione del modello è onerosa e il refactoring non è semplice

• Ma le informazioni sono sempre più “fluide”:

• cambiano più facilmente

• non sono definite dall’inizio dei progetti

• le metodologie agili richiedono capacità di adattamento continuo

• Il volume dei dati prodotti ogni anno è in continuo aumento

• I database relazionali non sono pensati per essere efficienti con volumi molto grandi

• Con Hadoop si è sviluppato un ecosistema nato per gestire volumi molto alti, e andare oltre il classico DWH

19

Lista delle principali tipologie di sistemi NoSql

Descrizione Casi d’uso Vantaggi Player di mercato

Multi-colonnari Strutture a record con un numero infinito di colonne raggruppabili

Logging real time, analytics, data

warehousing, caching

Query veloci su enormi quantità di dati, gestione di dati

denormalizzati

Cassandra, Hbase, Accumulo,

Key-ValueLe informazioni sono record individuati da una chiave di

accesso univoca

Caching di informazioni frequentemente accedute

(dati di login)

Scalabilità, store e get molto performanti

Redis, Memcached, Riak, EhCache, Hazelcast

Document Documenti a struttura gerarchica schema-less

Recupero rapido di informazioni in applicaizoni

web

Scalabilità, adattabilità, performance, query complesse

MongoDb, DinamoDB, CouchBase, CouchDB

GraphInformazioni correlate fra di loro, fino ad avere un grafo con nodi e

archiNetwork Analysis Accesso ad algortimi e funzioni

native dei grafi Neo4J, Titan, Giraph

Search Engine Gestione di dati in formato testoRicerca di informazioni,

ricerche su documenti, siti, ecc…

Query mirate alle caratteristiche del testo

Solr, ElasticSearch, Splunk

Multi Model NoSql che aggregano più tipologie OrientDB, ArangoDB

Altri Tipi XML, Time Series, Content Store, MultiValue, Object Oriented, ecc…

NoSql Type

20

Polyglot Persistence driven Innovation

Innovazione = Sopravvivenza

Innovazione

Algoritmi

Nuovi DatiProdotti

21

-

Esempi di Prodotti Innovativi

Credit Suite: Portfolio Analysis

Graph4You: Network Analysis

GeoData: Space Analysis

Marketing Plus: Analytics

Stima Immobiliare 2.0: Predictive Analysis

Atoka: lead generation

22

Il poliglottismo è già realtà Il tema non è più NoSql si o NoSql no

Bensì riuscire a trarre valore e qualità per il cliente dalla Polyglot Persistence

Cerved

Ma è un percorso difficile…

24

Difficoltà Il percorso seguito finora non è stato semplice e privo di difficoltà

Sono tante le sfide affrontate

Scelte tecnologiche

Ci sono tanti sistemi NoSql. Quali

scegliere per la propria applicazione?

Organizzazione e Know/How

Come cambiano i modelli organizzativi?

Come evolvono le esigenze di Know

How?

Strategia e ImplementazioneCome integrare una soluzione NoSql in

un sistema DB-centrico?

Immaturità NOSQL

Non tutti i sistemi NoSql sono maturi

per un uso in ambito enterprise

25

Scelte Tecnologiche

• Districarsi tra tutti i NoSql esistenti non è facile

• Tecnologie in continua evoluzione• Mercato con molta concorrenza

03

POC / Assessment• Realizzazione POC su

casi d’uso reali• Assessment su

performance, tuning, gestione operativa

02

01

Funzionalità• Conoscenza

approfondita delle esigenze applicative

• Mapping tra funzionalità applicative e tecnologiche

Studio• Funzionalità sistemi

NoSql• Aggiornamento continuo• Accesso difficile a

documentazione• Analisi dei casi d’uso

26

Immaturità NoSqlLe performance e la velocità

sono irrinunciabili

Spesso è più importante essere adattabili, scalabili, robusti, controllabili

Scalabilità: quanto un sistema NOSQL effettivamente scala all’aumentare del carico o all’aumentare dei dati da gestire?

Robustezza: quanto un sistema NOSQL è robusto nel tempo e non presenta continui bug o necessità di intervento?

Adattabilità: quanto un sistema NOSQL è effettivamente adattabile alle nostre esigenze? Spesso i NoSql non sono transazionali, non hanno un linguaggio di interrogazione, nel teorema CAP sacrificano la consistenza

Controllabilità: quanto un sistema NOSQL ha strumenti ad hoc per il monitoring, il tuning e la gestibilità in produzione? Quali sono i livelli di security?

27

Strategia e Implementazione

• Nuova applicazione• Nessun DB già esistente• Possibile scelta tra Rel e NoSql per gestire la persistenza• Non ci sono particolari problemi

Nuovo Sistema

• Applicazione già esistente• DB Relazionali al centro dell’architettura• Dati persistenti in DB Relazionali e NoSql• Processi ETL e ELT da DB Relazionali verso NoSql• Gestione Consistency e Availability (teorema CAP) e tempi di aggiornamento

Sistema Legacy esistente

Caso Cerved

28

Sourcing Liv.2

Sourcing Liv. 1

REPOS

SYNTH PragmaMond

Dati Lince

CR-RIBA(Payline)

Daticlient

NCA

ERG

EBS

HUB

Mambo

Michelang

DWH MBD

Teradata

Tabula

Mongo4DW

DB4You

XPCH 2

CDRSpazioDati

Matching

Idx Mondo

3

Quaestio

MBD2

Tabula (su AWS)

Aracne

ClientiFornitori

G 4 you

MBD1

Splunk

R3

CAS

Un caso di Incident reale

Esecuzione update accidentale su Milioni di numeri di telefono presenti su DB SYNTH

Dedalo

29

Organizzazione e Know HowLa Polyglot Persistence porta a confrontarsi con temi relativi all’organizzazione e al Know How

• I DB relazionali hanno affermato professioni come DBA, DB Expert, DB Architect.

• Quali professioni nascono con i NoSql?• Chi amministra i sistemi NoSql? (Dev, Ops, DevOps, New DBA?)• La progettazione del modello dati è professionalizzabile?• Spesso i NoSql sono visti come AS evoluti; ma chi ne effettua

monitoring e tuning?

Organizzazione

Know How• Know How dei developers• Know How degli IT operations• Know How di altri utilizzatori di dati:

• Centralità dell’SQL, strumento di analisi dei dati per oltre venti anni• Cypher, GraphQL, JSonIq, Specific Laguage, ecc… sono poco naturali

per chi usa SQL da anni• E’ in corso la “guerra” dei vendor al supporto dell’SQL e sono nati i NewSql

Sfide per il futuro

31

Supportare sempre più l’innovazioneCreare il contesto aziendale

Allargare l’uso delle nuove tecnologieSuperare le barriere di SQL e NoSql

Data Democratization: estendere a tutti l’accesso ai dati in azienda

Supportare e abilitare i Data Scientist, il Business, l’intera azienda a creare nuovo valore sui dati e a portarlo sul mercato

32

Consolidare la Governance tecnologicaLa Polyglot Persistence richiede approcci strutturati su tutte le tipologie di persistenza

Consolidamento ruoli Dev e Ops specializzati sui NoSql

Consolidamento Hadoop Data Lake

On Premises vs On Cloud

Maggiore scalabilità della farm anche sui sistemi di persistenza

ANTONELLO MANTUANO

[email protected]

Twitter: @manant74

Grazie!

“L’innovazione non nasce dal possedere tanti dati, ma dalla capacità di analizzarli, conoscerli, correlarli per creare

valore.Ed è questa capacità a dover essere continuamente alimentata”

Lezione di vita appresa in Cerved

E’ l’industria 4.0 che ritorna ai principi dello sviluppo dell’agricoltura

Licensing

https://creativecommons.org/licenses/by-nc-sa/3.0/



Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali - A. Mantuano (Cerved)

Data & Analytics

Transcript of Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali - A. Mantuano (Cerved)