Lo spazio dei dati (3Vs): Volume, Velocità e Varietà Il CAP theorem Data Modeling Data Platform Azure solutions Big Data and ML Azure solutions Cosmos DB More Data Consistency options: Bounded staleness, Session, Consistent Prefix Cosmos DB Security & Compliance Quality Assurance with TLA+ A Case Study: Venice Time Machine

2. Keynote
Nicolò Carandini
Vito Lorusso

3. Agenda
09:30 - 10:00 Keynote
10:00 - 11:00 Nicolò Carandini "Ottimizzazione gestione dati sul Cloud"
11:00 - 11:15 Pausa caffè
11:15 - 12:10 Vito Flavio Lorusso: "Azure Compute"
12:10 - 13:00 Lorenzo Barbieri: "Strategie di migrazione"
13:00 - 14:30 Pausa pranzo
14:30 - 15:30 Alessandro Melchiori: "Works on my Docker container"
15:30 - 16:30 Massimo Bonanni: "Service Fabric"
16:30 - 17:30 Andrea Saltarello: "Azure tales: CQRS & Event Sourcing in azione"

4. Ottimizzazione
della gestione dei dati sul Cloud
Nicolò Carandini [MVP]
@tpcware
n.carandini@outlook.com

5. Ogni cosa al suo posto
• Qual è la “forma” dei dati che vogliamo gestire ?
• Quali soluzioni abbiamo a disposizione ?
• Per fare cosa ?

6. Il ruolo di Chief Data Officer (CDO)
As the CDO role is fast emerging in general
and new for many organizations,
expectations are high, but the deliverables
and best practices are still taking shape.
Because of this, it's easy for CDOs to
struggle and fail in various ways.
“
”
Doug Laney
VP and Distinguished Analyst,
Chief Data Officer Research
10 years at Gartner, 30 years in IT industry

7. Variety
VelocityVolume
Batch
Periodic
Near real Time
MB
GB
TB
PB Real Time
Table
Database
Web content
Unstructured data
Lo spazio dei dati (3Vs)
Descritto per la prima volta in uno studio
di Doug Laney del 2001 intitolato:
“3-D Data Management: Controlling Data
Volume, Velocity and Variety”
E’ uno spazio tridimensionale formato
dalle dimensioni di:
• Volume
• Velocità
• Varietà

8. Volume di dati
Il volume dei dati rappresenta la quantità di informazione necessaria per la
conservazione dell’informazione, e dipende dall’uso che se ne deve fare.
Un grande volume di dati offre diverse opportunità di ottimizzazione:
• Segmentazione dei dati in diversi tipi di storage in ragione della loro frequenza
d’uso (hot/cold)
• Segmentazione dei dati in repository multi-tenant
• Partitioning/Sharding con framework NoSQL
• Utilizzo di strumenti di "Big Data" (HDFS di Hadoop)

9. Velocità dei dati
Per quanto riguarda la velocità dei dati siamo interessati a misurare:
• La frequenza d’uso
• La frequenza di variazione del dato nel tempo (TTL: Time To Live)
• Il tempo medio di attesa per la fruizione del dato (Latency)
Una bassa frequenza d’uso, se unita ad un alto volume di dati, suggerisce la
segmentazione in diversi tipi di storage (hot/cold), mentre TTL e Latency
determinano l’uso di sistemi di:
• CDN per i contenuti statici
• Cache per TTL significativi rispetto al contesto d’uso
• Cache e Georeplicazione se la latency deve rimanere molto bassa anche se
l’accesso avviene da diverse parti del mondo

10. Varietà dei dati
La varietà dei dati, sia di formato (sintassi) che di significato (semantica)
rappresenta l’aspetto di maggior complessità per chi deve progettarne la
gestione e la successiva elaborazione per la fruizione dei risultati.
Il formato dei dati viene tipicamente classificato in:
• Tabelle
• DBMS
• Contenuti semi-strutturati (immagini, documenti HTML, suoni e video, …)
• Contenuti non strutturati
Qui l’ottimizzazione consiste nell’utilizzo degli strumenti opportuni a secondo
della forma dei dati e del loro utilizzo.

11. A fonti, impieghi
Per ogni tipo di dato esiste almeno una corrispondente soluzione per la
gestione (archiviazione / elaborazione) che meglio si adatta allo scopo.
Ma poiché l’erba voglio cresce solo nel giardino del re, ecco servito il
famigerato teorema di Brewer, meglio noto come il "CAP theorem":
Eric Allen Brewer
Tenured professor of
Computer Science at UC Berkeley
Di tre cose ne puoi avere solo due!“ ”

12. Paghi tre, prendi due!
Il CAP theorem sostiene che per ogni “networked shared-data system”
possiamo ottenere solo due delle tre desiderabili proprietà:
• Consistency
che equivale ad avere una singola copia dei dati sempre “up-to-date”
• Availability
ovvero immediata disponibilità dei dati;
• Partitions tolerance
ovvero la possibilità di avere i dati in partizioni connesse via network

13. Semplice dimostrazione del CAP theorem
Per meglio comprendere il senso dell’enunciato, consideriamo l’uso di almeno
due partizioni, ad esempio una a New York e una in Australia.
Usando tali partizioni (P), se vogliamo avere la consistenza (C), dobbiamo
aspettare che i dati vengano sincronizzati tra le due partizioni e non possiamo
avere la disponibilità (A).
Sempre usando le partizioni (P), se vogliamo l’immediata disponibilità (A)
dobbiamo optare per la "eventually consistency" e dunque dovremo rinunciare
alla consistenza (C).
L’unico modo per avere contemporaneamente la disponibilità (A) e la
consistenza (C) è quello di tenere tutti i dati nello stesso server e di rinunciare
all’uso delle partizioni (P) di fatto rinunciando alla scalabilità, che solitamente
non è un’opzione disponibile.

14. Data Modeling
Le tre V e il teorema di Brewer ci guidano nella scelta della rappresentazione
dei dati e per conseguenza nella scelta delle soluzioni tecnologiche che meglio
implementano tali modelli, come ad esempio:

15. Data Platform Azure solutions
• Messaging Queue
Apache Kafka in Apache Hadoop, Azure IoT Hubs (high throughput),
Event Hubs (high throughput), Service Bus, Storage Queue
• Near-Real-Time
Apache Storm in Apache Hadoop, Stream Analytics, Apache Spark streaming
• Hot/OLTP Data Stores
SQL DB, Cosmos DB, Table Storage, Mongo DB, Azure Postgres, Azure
MySQL, Cassandra, Redis Cache
• Archival/Cold Store or Warm Store
HDFS in Apache Hadoop, Data Lake Store, Blob Storage

16. Big Data and ML Azure solutions
• Big Data Processing tools
Data Lake Analytics, Apache Hadoop, Apache Spark, SQL Data Warehouse,
Microsoft R Server
• Analytical Stores
SQL DB, Cosmos DB, Mongo DB, Azure Postgres, Azure MySQL, Cassandra,
Azure Analysis Services
• Advanced Analytical Stores
Azure ML, Cognitive Services, Microsoft R Server, Apache Spark ,
Cognitive Toolkit/Deep Learning

17. Cosmos DB

18. Cosmos DB: Turn-key Global Distribution
• Disponibile in tutte le regioni inclusa Cina e Germania
• Replica automatica in tutte le regioni selezionate
• E’ possibile associare un numero qualunque di regioni al proprio database account
• Policy based geo-fencing
• Multi-homing APIs
• Le applicazioni non hanno bisogno di essere spostate durante un regional failover
• Supporta il manual failover oltre a quello automatico
• Test manuale di failover
• Definizione manuale della catena di failover management (per priorità)

19. Cosmos DB: Multi-Model
Sostituisce ed estende Document DB
Key-Value Column-family Documents Graph

20. Cosmos DB: Multi-API

21. Cosmos DB: Low Latency
• Le operazioni di Read e Write utilizzano i dati della regione locale
• Viene garantita una latenza di millisecondi in ogni regione del mondo
• L’indexing è completamente automatico
< 2 ms
< 10 ms
50th
99th
< 6 ms
< 15 ms
Reads (1KB) Indexed writes (1KB)

22. Cosmos DB: Limitless scale
Horizontally scale out storage & throughput

23. Cosmos DB: Scale at will
• Si può scalare lo storage e il throughput in
modo indipendente
• Storage: da Gigabytes a Petabytes
• Throughput: da 100 a 100 milioni di RPS
• Si paga solo per quello di cui si ha bisogno,
in ogni momento per ciascuna regione

24. Cosmos DB: Data Consistency
Cosmos DB offre cinque modelli di data consistency per mitigare gli effetti
del CAP Theorem

25. Data Consistency: Bounded staleness
• Bounded staleness consistency guarantees that the reads may lag behind
writes by at most K versions or prefixes of an item or t time-interval.
• Therefore, when choosing bounded staleness, the "staleness" can be
configured in two ways: number of versions K of the item by which the reads
lag behind the writes, and the time interval t
• Bounded staleness offers total global order except within the "staleness
window." The monotonic read guarantees exists within a region both inside
and outside the "staleness window."

26. Data Consistency: Session
• Session consistency is scoped to a client session.
• Session consistency is ideal for all scenarios where a device or user session is
involved since it guarantees monotonic reads, monotonic writes, and read
your own writes (RYW) guarantees.
• Session consistency provides predictable consistency for a session, and
maximum read throughput while offering the lowest latency writes and reads.

27. Data Consistency: Consistent Prefix
• Consistent prefix guarantees that in absence of any further writes, the replicas
within the group eventually converge.
• Consistent prefix guarantees that reads never see out of order writes. If writes
were performed in the order [A], [B], [C], then a client sees either [A], [A,B] or
[A,B,C], but never out of order like [A,C] or [B,A,C].

28. Cosmos DB: SLAs
Le altre soluzioni offrono solo la garanzia sull’availability, Cosmos DB offre:

29. Cosmos DB: Security & Compliance
• Enterprise grade security
• I dati sono criptati sia nello storage che in trasmissione
• Sono criptati anche gli indici, i backup e gli allegati
• La crittografia è abilitata di default, senza impatto su performance,
throughput o availability
• Certificazione completa ed esaustiva
• ISO 27001, ISO 27018, EUMC, HIPPA, PCI
• SOC1 e SOC2 (audit completato, la certificazione disponibile dal Q2 2017)
• FedRAMP, IRS 1075, UK Official (IL2) (Q2 2017)
• HITRUST (H2 2017)

30. Cosmos DB: Sviluppo basato su TLA+
Leslie Lamport
Winner of the 2013 Turing Award for imposing clear,
well-defined coherence on the seemingly chaotic
behavior of distributed computing systems, in which
several autonomous computers communicate with
each other by passing messages.
A distributed system is one in which
the failure of a computer you didn’t
even know existed can render your
own computer unusable.
“
”

31. TLA+
TLA+ (Temporal Logic of Actions) è il linguaggio sviluppato da Leslie Lamport
che utilizza delle espressioni matematiche per definire formalmente le
specifiche di un sistema.
Il vantaggio di usare un formalismo matematico consiste nel poter fare una
verifica rigorosa della validità del modello e scoprire errori di progettazione
(rispetto ai soli errori di implementazione) del sistema stesso.
Even if is strange to describe a concurrent system as
a sequence of steps, it's possible because we can
simulate a concurrent system with a sequential
program, and with TLA+ it's simple and works well.
“
”

32. Altri casi d’uso di TLA+
• Il Sistema Operativo di Rosetta è stato progettato utilizzando TLA+

33. Conviene usare Cosmos DB ?
• Si, se hai bisogno di quello che offre.
• Ogni raccolta viene fatturata su base oraria a seconda della quantità di dati
archiviati (in GB) e della velocità effettiva riservata in unità di 100 UR/secondo,
con un minimo di 400 UR/secondo.
• Esempio:

34. Recap
• Conosci i tuoi dati e dividili nelle diverse categorie definite tramite "le tre V".
• Comprendi e accetta le limitazioni del cloud, enunciate dal "CAP theorem".
• Utilizza gli strumenti a tua disposizione scegliendo per ogni tipo di dato
quello più adatto (a fonti, impieghi).
• Se la tua applicazione lo richiede, usa Cosmos DB invece di provare a
reinventare la ruota, perché replicare le sue funzionalità non è cosa da
poco, sia in termini di prestazioni che di sicurezza e certificazione.

35. Case Study: Venice Time Machine
Un sistema informativo multimediale per la storia di Venezia
Modellizzazione multidimensionale della città e del suo impero mediterraneo,
consistente nel connettere i diversi domini di storia:
• Ambientale (evoluzione della laguna)
• Urbana (morfogenesi della città)
• Umana (demografia e circolazione)
• Culturale (politica, commercio ed evoluzione artistica)

36. Venice Time Machine: le tre sfide
La Venice Time Machine comporta tre ordini di complessità:
• Digitalizzazione
archivi immensi e molto antichi (milioni di documenti)
• Modellizzazione
ricostruzione cartografica e gestione dell’incertezza intrinseca delle fonti
storiche
• Museografia
come rendere conto di questa storia complessa

37. Dalla scansione alla fruizione
Use and experience
Documents acquisition
Doc. processing
digitalization
Doc. modeling
Trans. & Annotation
Knowledge rep.
Inference
Interlinking
Data processing
search
Visualisation
Complex queries
Exploitation

38. Interlinking

39. Search

40. Grafo sociale

41. Venice Time Machine: il team
• Team multidisciplinare:
Digital Humanities Laboratory at the Swiss Federal Institute of Technology in
Lausanne (EPFL) e Venezia, con collaborazioni con altre università ed enti:
• Ca’ Foscari
• Archivio di Stato di Venezia
• Biblioteca Marciana
• Ist. Veneto di Scienze, Lettere e Arti
• BEIC Milano
• ICCU Roma
• Università di Udine
• CWTS Leiden
• Università di Oxford

42. Question time

43. Thanks to our Sponsor

44. Feedback Form
Aiutateci a migliorare la qualità dei nostri eventi
compilando il feedback form:
1drv.ms/xs/s!Au9T1EY0TwHfn6RdsXBllmc3qTesWA