Oggi il tema non è più SI o NO ai sistemi NoSQL. Il problema sta nella capacità di essere “poliglotti” nell’uso di tecnologie per la gestione di dati e informazioni. Le strategie di innovazione sui Big Data nelle aziende non può prescindere dalla Polyglot Persistence, ma le difficoltà sono tante, specie in ambienti complessi ed enterprise. Ma la necessità di fare innovazione non è forte solo nelle startup, anzi…

1. 24 Febbraio 2017
Tra Innovazione e difficoltà su casi reali
Polyglot Persistence e Big Data
Antonello Mantuano – Chief Technology Officer

2. 2
Indice
Il contesto aziendale
Il viaggio verso la Polyglot Persistence
I problemi che abbiamo affrontato
Idee e trade-off verso il futuro
Cos’è la Polyglot Persistence

3. Il contesto aziendale

4. 4
Il contesto e i suoi numeri
CREDIT INFORMATION
Tutelarsi dal rischio di
credito
MARKETING SOLUTIONS
Crescere con nuove
opportunità di business
CREDIT MANAGEMENT
Gestire e recuperare i
crediti in sofferenza
Ricerche Anagrafiche:
110.000
Blocchi di Informazione
Erogati:
2.200.000
Chiamate a Servizi
8.500.000
Eventi su Dati
4.500.000
Operazioni su Storage
documentale
6.500.000
Calcoli 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. 5
I nostri “Big Data”
Web Data
Open Data
Dati proprietari
Dato ufficiale non
camerale
Dato ufficiale
camerale

6. 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
0101
1010
2017

7. Il viaggio verso la Polyglot Persistence

8. 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
199x
2010

9. 9
L’evoluzione delle Architetture (fase 1)
DB Rel
(Oracle)
Desktop,
Browser
Jboss, Tomcat,
J2EE
Reporting, BI,
ecc…
199x
2010
DB Rel
(Oracle)
Search
Engine
(Lucene)
Web Service
SOA
Web Server
Browser
Reporting, BI,
Predictive Modeling,
ecc…
Graph DB
(Neo4J)
2010
2012
• 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. 10
L’evoluzione delle Architetture (fase 2)
DB Rel
(Oracle)
Desktop,
Browser
Jboss, Tomcat,
J2EE
Reporting, BI,
ecc…
DB Rel
(Oracle)
Search
Engine
(Solr)
Web Service
SOA
Web Server
Browser
Reporting, BI,
Predictive Modeling,
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
199x
2010
2013

11. 11
L’evoluzione delle Architetture (fase 3)
DB Rel
(Oracle)
Desktop,
Browser
Jboss, Tomcat,
J2EE
Reporting, BI,
ecc…
DB Rel
(Oracle)
Search
Engine
(Solr)
Back End for
Front End
Web App
Reporting, BI,
Predictive Modeling,
ecc…
Graph DB
(Neo4J)
Document
DB
(MongoDB)
Microservice MicroserviceMicroservice
Mobile App API Portal
199x
2010
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. 12
L’evoluzione delle Architetture (fase 4)
DB Rel
(Oracle)
Desktop,
Browser
Jboss, Tomcat,
J2EE
Reporting, BI,
ecc…
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)
Microservice MicroserviceMicroservice
Mobile App API Portal
Bulk Load Streaming
Hadoop Data Lake
Machine
Learning
Predictive
Modeling
Reporting, BI
199x
2010
2016

13. 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)
Microservice MicroserviceMicroservice
Mobile App API Portal
Bulk Load Streaming
Hadoop Data Lake
Machine
Learning Predective
Modeling
Reporting, BI

14. 14
Sourcing
Liv.2
Sourcing
Liv. 1
REPOS
SYNTH Pragma
Mond
Dati
Lince
CR-RIBA
(Payline)
Dati
client
NCA
ERG
EBS
HUB
Mambo
Michel
ang
DWH
MBD
Teradata
Tabula
Mongo
4DW
DB4You
XPCH 2
CDR
SpazioDati
Match
ing
Idx
Mondo
3
Quaes
tio
MBD
2
Tabula
(su AWS)
Ara
cne
Clienti
Fornitori
G 4
you
MBD
1
Splu
nk
R3
CAS
Quanto siamo “Poliglotti”
Dedalo

15. Cos’è la Polyglot Persistence

16. 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. 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. 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. 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-Value
Le 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
Graph
Informazioni correlate fra di loro,
fino ad avere un grafo con nodi e
archi
Network Analysis
Accesso ad algortimi e funzioni
native dei grafi
Neo4J, Titan, Giraph
Search Engine Gestione di dati in formato testo
Ricerca 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. 20
Polyglot Persistence driven Innovation
Innovazione = Sopravvivenza
Innovazione
Algoritmi
Nuovi DatiProdotti

21. 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. 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

23. Ma è un percorso difficile…

24. 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
Implementazione
Come 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. 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. 26
Immaturità NoSql
Le 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. 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. 28
Sourcing
Liv.2
Sourcing
Liv. 1
REPOS
SYNTH Pragma
Mond
Dati
Lince
CR-RIBA
(Payline)
Dati
client
NCA
ERG
EBS
HUB
Mambo
Michela
ng
DWH
MBD
Teradata
Tabula
Mongo
4DW
DB4You
XPCH 2
CDR
SpazioDati
Match
ing
Idx
Mondo
3
Quaes
tio
MBD
2
Tabula
(su AWS)
Ara
cne
Clienti
Fornitori
G 4
you
MBD
1
Splu
nk
R3
CAS
Un caso di Incident reale
Esecuzione update accidentale su Milioni di numeri di telefono presenti su DB SYNTH
Dedalo

29. 29
Organizzazione e Know How
La 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

30. Sfide per il futuro

31. 31
Supportare sempre più l’innovazione
Creare il contesto aziendale
Allargare l’uso delle nuove tecnologie
Superare 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. 32
Consolidare la Governance tecnologica
La 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

33. ANTONELLO MANTUANO
antonello.mantuano@cerved.com
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/
https://creativecommons.org/licenses/by-nc-sa/3.0/