Il documento analizza il panorama dei big data in Italia nel 2013, evidenziando la scarsità di aziende che necessitano effettivamente di gestire grandi volumi di dati e la prevalenza di strumenti tradizionali come business intelligence e data mining. Viene discussa l'importanza di creare architetture integrative per ottimizzare la gestione dei dati e le opportunità di business derivanti da un uso efficace dei big data all'interno delle aziende, con riferimenti a casi reali e sfide operative. Infine, emergono considerazioni sull'evoluzione verso modelli predittivi e sulla necessità di adattare le competenze professionali alle nuove esigenze del mercato.

1. • Stefano Fantin
• www.stefanofantin.it
1
Corso Big Data

2. Corso Big Data
INTRODUZIONE: BIG DATA NEL MERCATO ITALIANO : “il relativismo”
Situazione Italiana dei Big Data anno 2013 senza il mobile:
In Italia è quasi impossibile trovare aziende che necessitano di immagazzinare dimensioni enormi di
dati (la differenza tra Big Data e Data Mining è proprio dell’ordine di grandezza di gran lunga
superiore dei Big Data) e anche nel mondo sono poche le aziende che necessitano di tali dimensioni.
Vediamo alcuni esempi italiani:
• Twitter: considerando i casi in cui è stato più usato erano attivi 3,5 milioni di italiani (campagna
elettorale) e durante il Festival di Sanremo si sono verificati 150mila tweet durante la sola finale; un
volume che può essere racchiuso in 77MB, senza compressioni, caricato su strumenti personali
(Excel), e analizzato per correlazione senza ricorrere ai big data.
•Banche: in Italia ci sono 30 milioni di conti correnti bancari e 8 milioni di conti correnti postali.
Considerando 20 operazioni al mese otteniamo 600 operazioni totali mensili. In un anno potremmo
valutarne 7 miliardi. E’ un numero elevato ma gestibile tranquillamente dalle basi di dati comuni e
server aziendali. Il volume complessivo è di alcuni TB
2

3. Corso Big Data
INTRODUZIONE: BIG DATA NEL MERCATO ITALIANO : “il relativismo”
Situazione Italiana dei Big Data anno 2013 senza il mobile:
D’altronde le società che impiegano strumenti che possono inquadrarsi come Big Data sono
poche: Facebook,Twitter, Amazon, Microsoft, Google.
In Italia, spesso, l’etichetta “Big Data” viene associata ad operazioni più tradizionali ma
comunque altrettanto efficaci quali Business Intelligence e Data Mining.
Nei fatti, molte delle tecniche di data mining sono oggi associate a volumi di dati sempre
maggiori, magari ottenuti da struenti di big data, anche se a oggi le analisi sono effettuate in
momenti e tecnologie differenti.
3

4. Corso Big Data
Big Bang Data Theory - Filippo Rizzante - CTO, Reply
50 miliardi di oggetti connessi in rete entro il 2020, miliardi di informazioni scambiate in rete quotidianamente.
E' lo spazio dei Big Data, dove eterogeneità, volumi, velocità nell'analisi e valore estratto dal singolo dato sono
le qualità che impongono nuove architetture e nuovi paradigmi di utilizzo. Il 2013 è stato l'anno in cui per le
tecnologie Big Data si è passati dalla fase di studio a quella del lancio di iniziative da parte delle aziende, che
sempre più intendono estrarre valore da una mole di dati eterogenea e molte volte distribuita.
Big Data: opportunità di business e strategie IT - Giuseppe Rossini - REsponsabile Sviluppo Sistemi
Informativi e Architetture, Poste Italiane
Poste Italiane eroga servizi per oltre 50 milioni di transazioni economiche al giorno, composte da oltre 200
milioni di transazioni tecniche elementari. Più di 4 miliardi di invii all'anno di prodotti postali. Il sistema
informativo di Poste Italiane è generatore e consumatore di "Big Data", che costituiscono una opportunità
concreta di business. In questo contesto, la sfida di Poste è mettere in comune le infrastrutture dati tra più
business (bancario, assicurativo, logistico, ...) per sfruttare sinergie, opportunità di sviluppo ed integrazione
delle offerte. Questa centralizzazione porta ad efficientamento, miglior governo e più facile innovazione.
In questo contesto, anche un obbligo normativo o di compliance bancaria diventa opportunità di innovazione,
e tutte le divisioni di business arrivano a beneficiare, condividendo gli investimenti e le infrastrutture.
4

5. Corso Big Data
1. Building a Unified Information Architecture - a Data Reservoir fo All your Data - Enrico Proserpio (Oracle)
& Alberto Guzzi (Technology Reply)
Per sfruttare al meglio tutte le opportunità offerte dal mondo dei Big Data, è importante creare un'unica
information architecture in cui vanno a convergere il mondo dei dati tradizionali già analizzati dalle aziende nei
data warehouse e nuovi dati trattati all'interno di un cluster Hadoop. Oracle presenta gli elementi della sua
soluzione integrata per gestire questo bacino di dati esteso con l'affidabilità e la sicurezza richiesta nelle
imprese e per esplorarli rapidamente con strumenti di Data Discovery. Elemento fondamentale della soluzione
sono le componenti per trattare i "Fast Data" di cui verrà mostrata una realizzazione fatta insieme a
Technology Reply per un cliente italiano all'interno dell'iniziativa Customer Profile Enrichment & Social
Network Analysis, con un sistema che consente di intercettare le esigenze lato customer tramite un'analisi
incrociata delle sue azioni sui diversi canali diretti (Home Banking o Mobile Bankig), sugli strumenti della banca
(carte di pagamento, POS) e sui social network.
2. Data Warehouse Optimization - Eli COllins (CLoudera) & Fabio Ardossi (Target Reply)
I data warehouse sono stati per decenni una parte critica nei sistemi di gestione dei dati. Quando le aziende si
trovano a dover gestire molti formati dati differenti e maggiori volumi did ati, i data warehouse e le
infrastrutture faticano a rispondere efficacemente. Durante la sessione si discuterà come le aziende sfruttano
Hadoop per gestire vari tipi di dati e processi di elaborazione all'interno della propria infrastruttura per
analizzare grandi volumi di dati e allo stesso tempo mantenere i costi e le performance sotto controllo. Infine
verranno presentati alcuni use case reali.
5

6. Corso Big Data
3. Search & Spark as part of the Cloudera Enterprise Data Hub - Paolo Castagna (Cloudera)
& Michele Giusto (Target Reply)
Apache Hadoop sta abilitando le aziende a collezionare dataset sempre più ampi e
differenti, ma una volta collezionati come vengono trovati? Gli utenti si aspettano di riuscire
a cercare informazioni facendo interrogazioni basate su parole semplici, senza preoccuparsi
della dimensione e complessità. Allo stesso tempo inoltre gli utenti si aspettano risposte
veloci e con bassa latenza.
Con MapReduce, il popolare motore alla base di Hadoop e Cloudera Enterprise Data Hub,
l'entusiasmo per Hadoop e per la sua capacità di gestire i processi complessi ricschia però di
essere temperato da diverse critcihe sull'alta latenza e risposte batch-oriented. Ciò di cui
l'ecosistema Hadoop ha bisogno è di strumenti performanti ed efficaci che rispondano alle
attuali esigenze di cui gli utenti sentono la necessità.
Durante la sessione si discuterà di come garantire la copertura di questi requisiti
sfruttando Cloudera Search come integrazione di Cloudera Enterprise Data Hub, e Spark,
confrontandolo con gli altri motori presenti nell'Enterprise Data Hub di Cloudera.
6

7. 7

8. 8

9. 9

10. Corso Big Data
10

11. Corso Big Data
11

12. Corso Big Data
12

13. • I Big Data si distinguono per le seguenti caratteristiche :
• Volume: si generano dati dell’ordine dei Terabytes (TB) al giorno;
• Varietà: i dati sono di tutti i tipi, di diversi formati;
• Velocità: IBM stima che più del 90% dei dati esistenti ai giorni d’oggi sono stati
creati soltanto negli ultimi 2 anni.
Eric Schmidt, presidente del consiglio d’amministrazione di Google, così
affermava nel 2010: ”ogni due giorni creiamo una quantità di dati pari al numero
totale dei dati generati dagli albori della civiltà sino al 2003”. Per avere un’idea
generale sui numeri che descrivono i Big Data, si possono osservare i
seguenti dati facenti riferimento all’anno 2010 :
• • il numero di messaggi inviati tramite Twitter (tweet) arriva a 340 milioni al
giorno;
• Google riceve più di 2 milioni di query di ricerca al minuto;
• l’Organizzazione Europea per la Ricerca Nucleare (CERN) genera 40 Terabyte al
secondo;
• i sensori di un jet producono 10 Terabyte di dati ogni 30 minuti.
Corso Big Data
13

14. Conferenza sui Big Data e Analitics. Cosa sono i big data?
La conferenza è attuale del 2014 e si è parlato di due argomenti nel 2014 cioè i Big Data e le
Analitics. Sono due argomenti perchè sono nuovi in Italia e non si ha ancora nessuna definizione
autorevole che sta bene a tutti. Ripeto siamo in Italia, stando a un direttore per l'europa a San
Francisco negli USA si ha una definizione di Big Data coincidente con la parola Analitics infatti nella
sua azienda i Big Data è l'evoluzione delle analitics. La definizione è quindi Big Data uguale Analitcs di
nuova generazione. Nei big data si è parlato nella conferenza di not only SQL cioè non solo SQL e
questo lo diceva nella sua multinazionale con sede a San Francisco mentre la IBM su IBM DB2 parla
di Big SQL che è contrastante con il not only sql. La verità è nel mezzo ogni azienda ha il suo modello
di business e siccome il modello E/R è nato alla IBM questa azienda vende il Big SQL con derivate le
Big Query.
Si è parlato di investimenti in materializzazione del dato questo significa che prima i ricchi erano
quelli che avevano le terre, poi i ricchi erano le aziende che erano grandi ad esempio la FORD e le
industrie non informatiche e poi i ricchi erano chi aveva il denaro, questo sempre secondo il dirigente
con sede a San Francisco. Adesso con la crisi globale i ricchi sono chi ha la materializzazione del dato
quindi chi ha i dati grandi quindi altissime capacità di memorizzazione. Si potrebbe pensare anche a
vendere la propria privacy come moneta di scambio per accedere e barattare le informazioni sempre
secondo questo responsabile per l'europa perchè non ci si ostacola con la privacy.
14

15. Conferenza sui Big Data e Analitics. Cosa sono i big data?
Rimanendo sempre nei Big Data non si è parlato per la pubblica amministrazione di open data argomento
invece insegnato in università bicocca in una lezione di informatica per l'organizzazione.
Gli open data significano anche rendere pubblici tutti i dati aziendali ad esempio nella pubblica
amministrazione e poi li si studia e si capisce se ci sono anomalie.
Nei Big Data ci sono le 3V del valore cioè varietà, voraticità e velocità dei dati che hanno valore.
Nella conferenza non si è parlato di gestione della conoscenza che ha il know how. Il know how è anche
l'intelligenza delle persone della azienda che si distingue in aziende a qualità minima cioè Mac Donalds e
azienda a qualità distintiva cioè Apple. La gestione della conoscenza è importantissima nei Big Data perchè ci
deve essere la seguente uguaglianza dato = informazione = conoscenza. Attualmente si ha che tutto il
software legacy non è flessibile quindi si ha solo l'uguaglianza dato=informazione mentre con l'intelligenza
artificiale e l'inferenza e la logica combinatoria e sistemi ibridi di calcolo numerico e inferenza si ottiene il
trinomio notevole che cresce esponenzialmente e con sistema di dati lineari quindi linear file system si arriva a
dato=informazione=conoscenza. La gestione della conoscenza è perchè ebay ha un database di 65 peta byte e
profila i suoi utenti. Il direttore di ebay per l'europa ha detto che amazon forse ha un database più grande
perchè loro vendono anche i loro prodotti mentre ebay vende solo i prodotti degli altri. Attualmente ci sono
sistemi di gestione dei contenuti che fanno anche da e-commerce ed è conveniente e certi sono a impatto
zero cioè gratis ma diceva questo direttore che non hanno il database di e-bay e non riescono a profilare gli
utenti quindi è giusto un sito web come wordpress e joomla mentre è sbagliato l'ecommerce.
15

16. Conferenza sui Big Data e Analitics. Cosa sono i big data?
Il CIO del sole 24 ore oltre a dire che il sito web è importante come un database ha detto anche che il presente
è la multicanilità e il mobile perchè servono questi dati da mettere nella base di dati. La multicanilità è
importante come il mobile ed entrambi generano traffico e generano grosse moli di dati. Si è parlato di
passato come modelli diagnostici e di futuro come modelli predittivi cioè di modelli che avvisano prima e
fanno le previsioni. Si tratta di modelli matematici che si usano in finanza come i classificatori bayesiani
complessi e probabilistic relational model quindi modelli probalistici di ricerca operativa. Il presente ha già
modelli predittivi per i device ad esempio il mainframe avvisa prima di rompersi e chiama il tecnico per la
assistenza. Nei modelli predittivi oltre alla relazione diretta con il cliente bisogna intercettare tutto compreso i
social. Gli ERP e il CRM concorrono al cliente. Si è parlato di sito web e di web e social media perchè sono dati
non strutturati e serve strutturarli e poi la qualità dei dati. Nella qualità dei dati la certezza è importante, dalla
certezza dei dati bisogna farli diventare un valore.
In Italia siamo arretrati perchè pensiamo le analitycs e il marketing come due cose diverse mentre il CIO del
Sole 24 ore afferma che secondo lui sono una cosa sola infatti il sole 24 ore ha implementato un solo db che
coincide tra marketing e analitycs. Quindi Big Data = Analitycs = Marketing secondo il sole 24 ore perchè nelle
analitycs ci deve essere anche il marketing.
Nel governo del dato nell'uguaglianza Big Data=Analitycs=Marketing la politica aziendale deve evitare che
diversi dipartimenti aziendali contattano il cliente tutti assieme come fanno alla TIM...
Il sole 24 prevede nuove professionalità da costruire cioè informatica e statistica e miste, in particolare
matematica e statistica per la ricerca operativa, gli informatici per ERP e CRM e architetture dei dati e infine i
processi aziendali.
16

17. Conferenza sui Big Data e Analitics. Cosa sono i big data?
Si è parlato di “data gravity” con libri in inglese che ne parlano e si può riassumere come una
maniera separata del dato.
Il problema principale è che c'è l'errore di comunicazione con il cliente e dal modello a cascata si è
arrivati alle metodologie agili. Fanno parte delle metodologie agili la fiducia e la collaborazione e nel
cambio di progetto è più adeguata la progettazione agile perchè un progetto che non fa nulla non
serve a nulla.
In Intesa San Paolo ci sono le ennesime analitycs e non c'è innovazione e non c'è il beneficio per il
cliente con contenuti vicino alla aspettativa per il cliente e il legame con l'utilizzo dei clienti delle basi
di dati aziendali. Se non conosci il cliente non puoi offrire il servizio. Dovrebbe valere la condivisione
dell'informazione mentre il valore della informazione è segreta nella privacy.
Un altro argomento che hanno consigliato vivamente di leggere un libro è perchè nei Big Data =
Analitycs c'è il data driven. La data driven organization è importante perchè si prevede una richiesta
alta di lavoro pari a 4 milioni di posti di lavoro nel mondo tra econometria e statistica e matematica e
economia e informatica. La data driven organization ha come elemento di misurazione la data
quality e consiglio un libro di Carlo Batini sulla data quality. La leadership sono persone con skill in
analitycs, poi c'è l'infrastruttura agile e il decision making process.
Infine si è parlato di determinismo cioè la discretizzazione e aggiungo anche di macchine di Turing
deterministiche in tempo polinomiale.
17

18. Corso Big Data
18

19. Corso Big Data
19

20. Corso Big Data
20

21. Corso Big Data
21

22. Corso Big Data
22

23. Corso Big Data
23

24. Corso Big Data
24

25. CLASSIFICAZIONE DI DATO INFORMAZIONE E CONOSCENZA
25

26. CLASSIFICAZIONE DI DATO INFORMAZIONE E CONOSCENZA
Il nuovo paradigma che ci aiuterà ad archiviare grandi quantità di dati non strutturati è
l'Object Storage, ed è dove il fenomeno Big Data si sta spingengo per affrontare la sfida di
archivi sempre più grandi
Dispositivi mobili
Il numero di gadget di registrazione e di trasmissione dati, dagli smartphone ai frigoriferi
intelligenti, dai sensori industriali alle telecamere a circuito chiuso, ha proliferato a livello
globale, portando ad una esplosione del volume di dati.
E stando alle previsioni di penetrazione della telefonia mobile da circa il 61% della
popolazione mondiale nel 2013 a quasi il 70% entro il 2017, queste cifre possono solo
crescere.
26

27. CLASSIFICAZIONE DI DATO INFORMAZIONE E CONOSCENZA
27

28. HW economico
Archiviazione a basso costo
Circa il 90% di tutti i dati oggi presenti al mondo è stato creato negli ultimi anni. Secondo
IBM, 2,5 exabyte - ovvero 2,5 miliardi di gigabyte – sono stati generati ogni giorno nel 2012.
"Circa il 75% sono dati non strutturati provenienti da fonti quali testo, voce e video",
afferma Miles.
Per le grandi imprese "il costo di archiviazione dei dati è crollato", dice Andrew Carr,
amministratore delegato della società di consulenza IT Bull. Le aziende possono sia
mantenere tutti i loro dati on-site, nei propri data center, o presso provider "cloud-based".
Un certo numero di piattaforme open source sono cresciute appositamente per gestire
queste enormi quantità di dati in modo rapido ed efficiente, tra cui Hadoop, MongoDB,
Cassandra, e NoSQL, contribuendo ulteriormente ad abbattere i costi di archiviazione dei Big
Data.
28

29. Privacy
Ma a chi appartengono tutti questi dati?
Molto dipende dal fornitore di servizi, dalla legge applicabile al luogo in cui i dati sono
conservati, e alle modalità tramite le quali sono stati generati.
Ad esempio, i metadata relativi ad una chiamata vocale fatta tramite smartphone
appartengono al chiamante, al carrier o all’agenzia governativa di turno che sta spiando la
telefonata per combattere il sempreverde terrorista o per superiori esigenze di sicurezza
nazionale?
I social network sostengono che i dati appartengono agli utenti, ma poi si riservano il diritto
di condividerli con terze parti. Per cui è bene essere consapevoli del fatto che ogni volta che
immettiamo nostre informazioni personali su questi media di fatto ne perdiamo il controllo.
29

30. Dati strutturati vs dati non strutturati. Le previsioni di IDC
Dati non strutturati: rappresentano il 67% delle capacità di storage enterprise consegnata
nel 2013. IDC stima che nel 2015, per quanto riguarda i sistemi di storage enterprise, i dati
non strutturati supereranno sia di capacità rilasciata che di spesa utente.
30

31. Dati strutturati vs dati non strutturati. Le previsioni di IDC
31

32. RICAVARE VALORE DALLE INFORMAZIONI
NEL 2012:
VARIETY
Dati interni (CRM, Sito Web, Pagina Facebook Aziendale, ...) ed esterni (Profili social dei competitor, Open Data, ...).
Dati strutturati (10%)
Dati non strutturati (90%).
VELOCITY
Online ogni 60 secondi: 2 milioni di ricerche su Google, 2460 post su Facebook, 278 mila tweet, 83 mila $ di fatturato su Amazon,
...
VOLUME
2012
2.837 Exabytes di dati
1,8 milioni di GB di informazioni create mediamente da ogni azienda, 4,1 milioni di GB di informazioni riguardanti il business di
ciascuna di esse.
2020
40,026 Exabytes di dati previsti
VERACITY
1 business leader su 3 non crede alle informazioni che usa per prendere le sue decisioni.
La scarsa qualità dei dati può costare fino a 3.1 trilioni di dollari.
32

33. IR : information retrieval
33

34. IR : information retrieval
34

35. IR : information retrieval
35

36. IR : information retrieval
36

37. IR : information retrieval
37

38. GIS
38

39. GIS
39

40. Analisi predittiva
40

41. Analisi predittiva
41

42. Analisi predittiva
42

43. Big Data = Analytics con analisi predittiva
43

44. Analisi predittiva
44

45. Corso Big Data
45

46. Analisi predittiva
Tutto il valore potenziale dei big data sta nelle analisi che vi si possono applicare per capire
sempre meglio tutto ciò che riguarda dinamiche di mercato e soprattutto specificità del
cliente. In altre parole, il contesto socioeconomico in cui viviamo.
46

47. Obiettivo : capire i big data. Introduzione al calcolo parallelo.
Cosa è un dato?
Un dato è la rappresentazione del valore di una informazione
Informazione
Non esiste dato se non c’è l’informazione a cui è associato
L’informazione è condizione necessaria per l’esistenza del dato
• Il dato è condizione necessaria per la conservazione, elaborazione e trasmissione dell’informazione
Dato, informazione, Conoscenza
SOCIETA’ DELL’INFORMAZIONE E DELLA CONOSCENZA
SOCIETA’ DEI DATI
Siamo immersi in un mondo di dati … noi stessi siamo portatori di dati … e dalla biologia ci fanno sapere …che alcuni di questi
dati ci segnano per sempre …
Dal Mainframe al Calcolo Parallelo
Agli inizi degli anni 70 c’era un calcolatore centrale. Il calcolatore centrale era pensato per la legge di Moore e la miniaturizzazione
sempre più spinta del mainframe. Agli inizi degli anni 90 con l’avvento del calcolo parallelo il calcolatore centrale ha avuto un
periodo di profonda crisi perché era più conveniente il calcolo parallelo. Per arrivare all’attuale mondo nosql dei big data serve
avere dei concetti di calcolo parallelo.
47

48. Corso Big Data
48

49. Corso Big Data
49

50. Corso Big Data
Tassonomia di Flynn:
Si cerca di mettere ordine in una situazione di questo tipo cercando di costruire delle vere e proprie
Tassonomie dei sistemi di elaborazione parallela (figura (2.3)). Tra le più note vi `e certamente la
Tassonomia di Flynn (1972), mostrata in figura (2.3). La tassonomia di Flynn è basata su due concetti:
• Il flusso delle istruzioni, che corrisponde ad un contatore di programma; un sistema con
N CPU ha n contatori di programma, quindi n flussi d’istruzione;
• il flusso dei dati è costituito da un insieme di operandi; un programma che calcola una funzione su un elenco di dati ha un flusso
di dati, quello che calcola la stessa funzione su più elenchi diversi di dati ha più flussi di dati
• SISD (Single Istruction Single Data), come la tipica macchina di von Neumann;
• SIMD (Single Istruction Multiple Data), nella quale vi `e una sola unità di controllo che esegue una sola istruzione alla volta e più
ALU per eseguire simultaneamente la stessa istruzione su diversi
data-set;
• MISD è una categoria anomala in quanto dovrebbero esserci più istruzioni che operano sugli stessi dati; molti annoverano in
questa categoria le macchine a pipeline;
• MIMD, cioè macchine costituite da più CPU distinte e indipendenti che operano come parte di un sistema più grande. Molti
processori o sistemi paralleli appartengono a questa categoria
50

51. Corso Big Data
51

52. Corso Big Data
Vi sono esenzialmente tre modelli di programmazione parallela utilizzati nella maggior parte dei sistemi scalabili:
• il modello di programmazione message passing;
Modello message-passing:
Nel modello basato sul passaggio esplicito di messaggi, i processi di un’applicazione parallela hanno ciascuno il proprio spazio
d’indirizzamento privato e condividono i dati attraverso l’uso esplicito di messaggi; il processo sorgente esplicitamente manda
(primitiva SEND) un messaggio ed il processo target esplicitamente lo riceve (primitiva RECEIVE). I processi evolvono nel senso che
seguono il flusso di condivisione dei dati esplicitato direttamente nel programma attraverso le primitive SEND e RECEIVE.
I programmi generalmente hanno una struttura SPMD ( Single Program Multiple Data), ossia lo stesso programma agisce su
porzioni parzialmente disgiunte dei dati. Il programma in esecuzione evolve secondo la modalità non perfettamente sincrona
(loosely synchronous style) nella quale si alternano una fase di calcolo con una di comunicazione. Durante la fase di calcolo,
ciascuno dei processi effettua i calcoli sulla porzione di dati assegnatagli e nella fase di comunicazione i processi scambiano dati
utilizzando le librerie message-passing. Un esempio di linguaggio che supporta la programmazione message passing è l’OCCAM,
inoltre attraverso il FORTRAN possono essere costruite librerie, quali MPI e PVM, di supporto al modello di programmazione.
Generalmente, tra i maggiori vantaggi espressi dalla programmazione message passing vi è la concreta possibilità di creare
implementazioni estremamente veloci degli algoritmi, dipendentestrettamente dalla natura del problema e dall’abilità del
programmatore.
Tra i difetti riconosciuti bisogna ricordare che la portabilità non è garantita e che la programmazione presenta delle difficoltà da
non sottovalutare nell’implementazione di codici complessi
52

53. Corso Big Data
2) • il modello di programmazione shared memory ;
Nel modello a memoria condivisa i processi facenti capo ad una applicazione parallela
condividono uno spazio d’indirizzamento ed in esso effettuano le operazioni di
ingresso/uscita in modo asincrono; i dati, in questo modo,sono condivisi rispetto allo spazio
direttamente referenziato senza bisogno di azioni esplicite per individuare i dati da
condividere. La sincronizzazione
dei processi deve essere esplicitata utilizzando dei costrutti particolari.
Il modello di programmazione shared memory viene spesso associato al controllo dinamico
del parallelismo, nel quale porzioni logicamente indipendenti dello stesso flusso di
programma possono essere considerati come blocchi funzionali o come cicli di iterazione
indipendenti
53

54. Corso Big Data
3) • il modello di programmazione data parallel
Con il nome modello data-parallel s’intende individuare quella classe di linguaggi che permettono di realizzare il parallelismo eseguendo una stessa
operazione, ovvero una serie di istruzioni, in modo concorrente su insiemi di dati parzialmente disgiunti, facenti parte di una stessa struttura dati
complessiva. In questo modo ciascuna delle operazioni su ciascuno degli elementi del
dataset può vedersi come un processo indipendente dagli altri,ciò porta a dire che la naturale granularità di un linguaggio data parallel è una
granularità fine.
Il modello di programmazione con parallelismo nei dati viene supportato
da linguaggi quali l’High Performance FORTRAN (HPF). I programmi sono scritti utilizzando il FORTRAN 90 sequenziale per specificare le operazioni
sui dati, attraverso l’uso di costrutti particolari per le operazioni su vettori e matrici oltrechè direttive intrinseche dell’HPF per mappare i dati in
modo che possano essere distribuiti sui vari processori. Il preprocessore o il compilatore HPF traducono il codice sorgente scritto utilizzando
FORTRAN 90 più le direttive del linguaggio HPF in un codice equivalente SPMD con chiamate message passing
(se il sistema supporta un’architettura message passing come nel caso dell’SP2) oppure con le
appropriate sincronizzazioni (se il sistema supporta un’architettura time sharing). Il carico di calcolo viene distribuito ai processi paralleli secondo le
specificazioni fornite attraverso le direttive di distribuzione HPF. Questo approccio ha il grande vantaggio di liberare il programmatore dal compito di
distribuire matrici globali su matrici locali, sostituendo indici e rinominandoli oltre che indicare esplicitamente le chiamate per la trasmissione e la
ricezione dei dati o la loro sincronizzazione. Un’altro vantaggio notevoledello scrivere codici in HPF è la compatibilit à con il FORTRAN standard,
agevolando il porting e la manutenzione dei codici, oltre che lo sviluppo su
workstation monoprocessore.
Esempi di linguaggi che supportano la programmazione data parallel sono CM FORTRAN, CRAFT, C ∗, FORTRAN D e VIENNA FORTRAN.
54

55. Corso Big Data
55

56. Corso Big Data
Overhead totale: tempo extra oltre all’algoritmo sequenziale
L’utilizzo di un maggior numero di processori non è sempre una garanzia di sviluppo
di algoritmi paralleli efficaci 56

57. Corso Big Data
57

58. Corso Big Data
58

59. Corso Big Data
59

60. Corso Big Data
In generale la parte parallela non sempre coinvolge tutti i processori. Durante l’algoritmo alcuni
processori possono essere inattivi.
60

61. Corso Big Data
61

62. Corso Big Data
62

63. Corso Big Data
63

64. Corso Big Data
64

65. Corso Big Data
Un algoritmo si dice scalabile se l’efficienza rimane costante (o non degrada) al
crescere del numero dei processori e della dimensione del problema.
65

66. Corso Big Data
Cosa è un database?
E’ un insieme di elementi la cui esistenza e disponibilità è condizione necessaria per la operatività del
contesto.
Base Informativa BI e sistema informativo
Diremo Sistema Informativo il complesso di competenze e risorse umane, di macchine ed impianti, di
procedure organizzato, strutturato e dedicato alla definizione, manutenzione ed evoluzione della BI, alla
raccolta, circolazione ed elaborazione dei dati della BI
• La BI viene, in generale, considerata una componente del SI
66

67. Corso Big Data
I modelli
il modello reticolare e quello gerarchico sono basati su puntatori, utilizzati come riferimenti espliciti fra record di tipi
diversi
il modello relazionale e’ basato su valori, nel senso che le corrispondenze fra dati in relazioni diverse sono rappresentate
per mezzo della presenza di valori comuni
MODELLO GERARCHICO
Il primo modello gerarchico si affermò nel 1968 si chiamava IMS (Information Management System) e fu sviluppato da
IBM. Oggi resistono sui mainframe.
I dati sono organizzati in record connessi tra loro secondo strutture ad albero. L’albero è formato da 2 tipi di record: il
record OWNER (proprietario) e il record MEMBER (componente).
Ogni record del database, che non sia la radice dell' albero, deve avere uno e un solo padre
Es. il file system del sistema operativo: ogni cartella è contenuta in una cartella padre tranne che la root
Limiti:
non si presta a rappresentare in modo efficiente le associazioni N:M
67

68. Corso Big Data
MODELLO RETICOLARE
Si affermò CODASYL (fine anni 70) sviluppato dal gruppo di standardizzazione del linguaggio COBOL
Un record puo’ avere uno o piu’ record padre e cio’ permette di evitare i problemi di ridondanza
Il modello reticolare e’ così chiamato poiche’ ogni suo schema puo essere rappresentato per mezzo di un grafo (o una
rete), con nodi e archi.
Limiti: Complessa la gestione difficile il progetto
MODELLO RELAZIONALE
Lo progettò nel 1970 Edgar Codd(IBM) . Insieme di tabelle messe in relazione tra loro tramite i campi
Campi comuni tra tabelle stabiliscono le relazioni della base di dati
68

69. Corso Big Data
Overview sui sistemi DBMS. L’elaborato valuta le possibilità offerte dai DBMS orientati a colonne.
• Database system orizzontali: tradizionali DBMS relazionali. • Database system orientati a colonne: nuovi sistemi
proposti per datawarehousing e read/only reporting, OLAP (On-Line Analytical Processing) insieme di tecniche software
per l’analisi interattiva e veloce di grandi quantità di dati. • I DBMS a colonne memorizzano i dati a colonne invece che a
righe.
Benefici dei DBMS a colonne
• Query recupera solo valori da determinate colonne e non da tutta la riga. • Colonne, composte da tipi di dati uniformi,
più facili da comprimere aumento velocità di esecuzione e storicizzazione arrivando a gestire svariati petabyte
Sap Hana
Sviluppato e commercializzato da Sap nel 2012 punto di incontro tra tecnologia relazionale e colonnare traendo i
migliori aspetti da entrambe e costituendo una sorta di passaggio graduale tra le due tecnologie miglioramento
prestazioni grazie al motore in-memory. • Memorizza una tabella nella colonna di archiviazione come sequenza di
colonne in locazioni di memoria contigue massimizza località spaziale delle colonne della tabella. • CPU accede ai dati
in modo consecutivo senza tempi di attesa per operazioni di indirizzamento in memoria velocità di esecuzione elevate. •
Storage delle tabelle in colonna compressione molto elevata dei dati.
69

70. Corso Big Data
Lambda Architecture : una soluzione [ functional ]
La Lambda Architecture è una prima proposta di alto livello che cerca di dare una risposta al problema dei Big Data,
che oggi è tanto di moda.
La proposta di Nathan Marz, è nata quando si occupava dei sistemi in Twitter.
Il big del 140 caratteri aveva una stack applicativo interamente progettato in Ruby, che però non riusciva a reggere
l’enorme mole di utenti e messaggi che ogni mese incrementavano.
Nonostante gli sforzi di ottimizazzione, che si sono spinti fino alla riscrittura di parti dell’interprete, la conclusione è
stata la necessità di abbandonare Ruby.
La nuova proposta era basata sulla Java Virtual Machine, ma anche in questo caso non c’era a disposizione una
architettura che garantisse la scalabilità con le performance richieste da Twitter.
70

71. Corso Big Data
La ragione è che da una parte occorreva garantire un near real time, dall’altra un sistema robusto,
affidabile ed in grado di garantire la scalabilità operativa su moli di dati crescenti.
Infine, c’era il problema di contenere la complessità in una azienda che ha la necessità di introdurre
rapidamente nuovi servizi in produzione, senza avere impatti sull’esistente e garantendo anche la
maggiore semplicità possibile di debugging.
Ecco perché la risposta di design è stata per necessità innovativa e quasi ardita nella sua semplicità.
71

72. Corso Big Data
Principi di base
L’idea alla base della Lambda Architecture è quella di adottare una soluzione basata sul principio dei linguaggi
funzionali, ma in chiave architetturale, quindi ad alto livello.
Il che consente di lavorare sia sul parallelismo delle operazioni sia sulla flessibilità dell’insieme di strumenti da
utilizzare.
Una query può essere rappresentata in maniera ideale come l’esecuzione di una funzione arbitraria eseguita
sull’insieme totale dei dati:
query = functuion (allData);
Quindi occorre innanzitutto pensare a quali siano le nostre query, quindi semplificarle il più possibile,
scomponendole se necessario, e questo permette di ottenere processi parallelizzabili.
In questo modo la scalabilità hardware è resa più semplice attraverso la realizzazione di un cluster di macchine
che esegue in parallelo le singole query. 72

73. Corso Big Data
Un altro punto cardine della Lambda Architecture è il Master Record, inteso come l’insieme dei dati in input al
sistema.
La cosa importante in questa diventa una master copy acquisita dal sistema in read only e preservata nel
tempo. Ogni nuovo input sarà semplicemente un append ai dati esistenti senza la possibilità di alcun update o
remove.
Queste operazioni saranno di competenza della funzione che elabora le viste che alimenteranno le nostre query.
In questo modo, sarà possibile ricostruire in ogni momento il sistema, rendendolo maggiormente fault tollerant.
Infine, un’altro principio importante è quello di predisporre due “canali”, uno dedicato al processamento massivo
di tutta la master copy dei dati, l’altro con il compito di elaborare solamente i dati più recente per fornire dei
risultati in tempi rapidi e garantire il near real time.
In sostanza una specie di parallelizzazione focalizzata ad alto livello.
73

74. Corso Big Data
Schema e Componenti
74

75. Corso Big Data
Batch Layer
Questo componente ha i seguenti compiti:
● tenere una copia dei dati in input
● eseguire le funzioni che producono le viste
● aggiornare il Serving Layer
● essere semplice e distribuibile
Questo componente è sicuramente la parte dove dovremmo piazzare la nostra logica di business, pensata in
modo da poter essere il più semplice possibile.
Un’approccio implementativo potrebbe essere, sempre prendendo in prestito la terminologia dai linguaggi
funzionali, quello di adottare un modello a Map/Reduce.
In sostanza una funzione di aggregazione di dati (Map), alla quale segue una funzione che esegue delle
elaborazioni ed applica dei filtri (Reduce).
75

76. Corso Big Data
I dati, in questo caso, vengono visti come tuple, che vanno identificati come chiave e valore, per avere una
interfaccia generica e flessibile.
L’importante è che queste funzioni non siano eccessivamente complicate per garantire che le si possa
parallelizzare e anche debuggare in modo semplice.
Questi Map/Reduce possono essere pensati sia in modo indipendente fra loro, sia un flusso in cascata, per
poter garantire le esigenze di semplicità, debuggabilità e anche di parallelizzazione.
Il risultato prodotto dal componente è la realizzazione di viste chiamate Batch View.
Queste rappresentano la base dati che sarà interrogata dalle query che risiedono sull’applicazione client.
Le Batch View non sono delle viste in senso classico di database. Si tratta di query precomputate prodotte in un
formato che è utile al sistema per completare le richieste delle applicazioni client.
Possono essere anche dei file in formato Comma Separated Value o XML.
76

77. Corso Big Data
Serving Layer
Questo componente ha i seguenti compiti:
● indicizzale le Batch View
● fornire l’accesso alle Batch View da parte delle query
Il Serving Layer è sostanzialmente un database, ma non ha necessità di accedere ai dati in scrittura.
Infatti, dal punto di vista della Lambda Architecture, l’accesso in scrittura avviene solo attraverso il canale di
input a sinistra, mentre da destra si accede solo alle viste precomputate in sola lettura.
Il compito principale è quindi, di provvedere all’indicizzazione ed a tutte quelle pratiche atte a velocizzare
l’accesso alle viste.
77

78. Corso Big Data
Speed Layer
Come abbiamo detto precedentemente, la master copy del dataset viene conservata dal Batch Layer, che
provvede ad eseguire continuamente le funzioni su tutti i dati. Ma i più recenti sono anche inviati a questo
componente.
Il ruolo dello Speed Layer è di provvedere ad eseguire le varie query, sull’ultima porzione di dati, con
l’obbiettivo di produrre delle viste near real time.
In questo modo si risolve il problema del tempo necessario al Batch Layer per precomputare le varie query
sull’intero dataset.
Anche se le query restano le stesse, il flusso viene diversificato perché è opportuno scegliere uno strumento
che consenta una prestazione migliore.
Occorre tenere presente, che l’insieme di dati sarà comunque notevolmente inferiore a quella processata dal
Batch Layer.
78

79. Corso Big Data
Query
A questo punto abbiamo un componente che può rappresentare una API utilizzata dalle applicazioni client, che ha la
conoscenza per decidere se accedere alle Near Real Time View o alle Batch View.
Questa parte, dipende dalle scelte fatte in precedenza, dalla complessità del sistema e dal tipo di funzionalità che s
desidera fornire in tempo reale all’utente.
Conclusioni
Il risultato è:
● robusto e resistente agli errori
● generico
● estensibile
● aperto alle eccezioni
● pensato per una manutenzione minima
● debuggabile
● e near real time
79

80. Corso Big Data
La cosa più importante è che si tratta di una prima soluzione architetturale che si occupa di dare una risposta al
problema dei Big Data.
Ma anche se gli strumenti a disposizione per realizzare un sistema basato sulla Lambda Architecture, sono
potenti ed estremamente evoluti, restano ancora molto grezzi.
Se vogliamo, sono paragonabili agli strumenti che può utilizzare un alpinista per scalare una montagna.
Come le picozze, i moschettoni, le corde, gli scarpini, i ramponi, gli indumenti e così via.
La tecnologia migliora ogni giorno questi strumenti, ma per quanto possano essere vantaggiosi, scalare la
montagna fino alla vetta è un compito che resta nelle capacità dell’alpinista.
80

81. Corso Big Data
81

82. Corso Big Data
82

83. Corso Big Data
83

84. Corso Big Data
SISTEMI NO-SQL: INDICI ED EFFICIENZA
Con il termine “Cloud Computing” si vuole indicare un tipo d’infrastruttura di elaborazione distribuita che è solitamente
composta da un certo numero di nodi.
Per sfruttare a pieno la forza del Cloud, è necessaria una gestione efficiente dei dati, per governarne l’enorme volume e
supportare un grosso numero di utenti concorrenti. Per raggiungere tale obiettivo, è richiesto uno schema d’indicizzazione
scalabile e con alte performance.
Indici Primari e Secondari
Dato un file f con campo chiave k, ricordando che un campo chiave è un valore attraverso il quale è possibile individuare la
locazione fisica dei dati, un indice secondario è un altro file, in cui ciascun record è logicamente composto di due campi,
uno contenente un valore della chiave k del file f e l’altro contenente l’indirizzo o gli indirizzi fisici dei record di f che hanno
quel valore chiave. L’indice secondario è ordinato in base al valore della chiave e consente quindi una rapida ricerca in
conformità a tale valore. Pertanto, l’indice secondario può essere utilizzato da un programma per accedere rapidamente ai
dati del file primario, supponendo che l’interrogazione cui dare risposta abbia un criterio basato sul campo k. Quando
invece l’indice contiene al suo interno i dati esso viene detto primario, perché garantisce non solo un accesso in base alla
chiave, ma contiene anche i record fisici necessari per memorizzare i dati. Ovviamente, un file può avere un solo indice
primario e più indici secondari. 84

85. Corso Big Data
Il CG-Index
Il CG-index(Cloud Global Index) è uno schema d’indicizzazione secondario sviluppato per piattaforme Cloud, progettato
per query online e mantenuto in modo incrementale. Tale schema condivide alcune delle strategie d’implementazioni
comuni ai database sharednothing, ai sistemi peer-to-peer e agli attuali sistemi di memorizzazione Cloud.
Un CG-index consiste di due componenti: una libreria collegata con le applicazioni utente e un set di server indice dove
sono memorizzati gli indici.
I server indice lavorano in un gruppo di nodi di elaborazione condivisi, mentre il processo server di indicizzazione pu
risiedere anche sulla stessa macchina fisica del processo server di memorizzazione.
Tutti i sistemi di memorizzazione esistenti implementano uno schema di partizionamento orizzontale per memorizzare
grossi “dataset” in un cluster. L’idea è di partizionare il dataset in parti più piccole chiamate “data shards”. Ogni data
shard è un’unità distribuita e archiviata su un unico nodo.
Il CG-index è progettato per offrire buone performance con questo sistema di partizionamento. Infatti, esso costruisce un
indice locale B+-tree per ogni data shard, chiamato shard index. Le query sono quindi servite con una ricerca di tutti gli
indici shards qualificati.
85

86. Corso Big DataB+-tree
Un B+-tree è una struttura ad albero dinamica (cioè efficiente anche in presenza di aggiornamenti) tra le più
utilizzate per la realizzazione di indici. Ogni albero è caratterizzato da un nodo radice, vari nodi intermedi, e
molteplici nodi foglia; ogni nodo coincide con una pagina o blocco a livello del file system. I legami tra nodi
vengono stabiliti da puntatori che collegano fra di loro le pagine; in genere ogni nodo ha un numero di figli
abbastanza grande, che dipende dall’ampiezza della pagina.
Un requisito importante per il corretto funzionamento della struttura è che gli alberi siano bilanciati, cioè che
la lunghezza di un cammino che collega il nodo radice da un qualunque nodo foglia sia costante, in questo
modo il tempo di accesso ai dati è lo stesso per tutte le foglie ed è pari alla profondità dell’albero.
86

87. Corso Big Data
Architettura di un Sistema Cluster
Un set di macchine a basso costo costituisce i nodi di elaborazione del cluster. Questo è un sistema shared-
nothing dove ogni nodo ha la propria memoria e i propri hard disk.
Per facilitare la ricerca, i nodi sono connessi secondo il protocollo BATON. In BATON, ogni nodo è responsabile di
una chiave e ogni nodo mantiene puntatori d’instradamento verso il predecessore, il successore e la radice.
Questa forma di indicizzazione è molto simile a quella del B-tree.
87

88. Corso Big Data
88

89. Corso Big Data
In questi sistemi, i dati sono partizionati in data shards, i quali sono distribuiti in modo casuale ai nodi di elaborazione.
Per facilitare la ricerca per una chiave secondaria, ogni nodo costruisce un B+-tree per indicizzare i dati locali. In questo
modo, dato un valore chiave, si riceve efficientemente “l’handle” corrispondente. L’handle è una stringa di bit arbitraria
che viene utilizzata per estrarre il valore corrispondente dal sistema di memorizzazione.
Per risolvere le query nel cluster, uno schema tradizionale distribuisce le query in broadcast a tutti i nodi, dove le
ricerche in locale vengono svolte in parallelo. Questa strategia, per quanto semplice, non è efficiente e scalabile.
Un altro approccio è di mantenere le informazioni sul partizionamento dei dati in un server centrale, ma anche questa
soluzione, come tutte quelle che prevedono un nodo centrale, presenta uno svantaggio: il nodo centrale diverrebbe il
collo di bottiglia del sistema.
89

90. Corso Big Data
Dunque, dato un valore chiave o un intervallo di ricerca, per localizzare il corrispondente B+tree, costruiremo un indice
globale ( CG-index ) sul B+-tree locale. In particolare, alcuni nodi del B+-tree locale sono pubblicizzati e indicizzati nei
nodi remoti di elaborazione secondo il protocollo di routing sovrastante. Per evitare costi di memoria eccessivi, inoltre,
vengono memorizzati solo i meta-data di un nodo B+-tree pubblico: il blk, disk block number del nodo, il range del
nodo, le chiavi di ricerca del B+-tree e l’IP del corrispondente nodo di computazione. In questo modo, manteniamo un
indice remoto per il B+-tree locale in ogni nodo del cluster. L’insieme di questi indici costituisce il CG-index.
90

91. Corso Big Data
Risoluzione delle Query
Data una query su un intervallo Q, abbiamo bisogno di ricercare il CG-index per localizzare il nodo B+-tree il cui
intervallo coincide con Q. Proviamo a simulare l’algoritmo di ricerca per risolvere la query. Partendo dal limite inferiore
di Q, seguiamo i collegamenti adiacenti per cercare nodi di pari livello fino a raggiungere il limite superiore di Q.
Tale algoritmo di ricerca può essere ulteriormente ottimizzato. Supponendo che k nodi coincidano con Q, il costo medio
di una ricerca su intervallo in BATON è all’incirca ½log2N+k, dove N è il numero di nodi di elaborazione totale del
sistema.
La prima ottimizzazione può essere fatta sul punto di partenza della ricerca che andrebbe spostato all’interno
dell’intervallo. Ipotizzando, infatti, che i dati sono distribuiti uniformemente tra i nodi e chiamato R l’intervallo totale,
quest’ottimizzazione riduce il costo medio di ricerca da ½log2N+k a ½log2 QN/R +k.
91

92. Corso Big Data
Gli studi esistenti ignorano gli effetti di k, il quale, di fatto, domina le prestazioni di ricerca in una rete su larga scala. Un
semplice esempio, in una rete di 10'000 nodi, supponiamo i dati partizionati uniformemente tra i nodi, avremo k = 100
se Q/R = 0.01.
Per ridurre la latenza della ricerca per intervallo, la seconda ottimizzazione comporta l’aumento del parallelismo
inviando la query in broadcast a tutti i nodi di elaborazione che si sovrappongono con l’intervallo di ricerca.
In conclusione, il nuovo algoritmo di ricerca può essere riassunto come: 1. Localizzare i nodi di calcolo nell’intervallo di
ricerca. 2. Seguire i collegamenti adiacenti e individuare il nodo radice del sotto-albero BATON. 3. Inviare la query in
broadcast ai soli nodi figli del sotto-albero. 4. In ogni nodo di elaborazione, dopo aver ricevuto la richiesta di ricerca,
eseguire una ricerca locale per il CG-index corrispondente.
L’introduzione del parallelismo riduce il costo medio di ricerca a ½log2 QR/N + log2N, dove quest’ultimo contributo
additivo è il massimo valore dell’albero BATON.
92

93. Corso Big Data
Hadoop:
- Librerie di alto livello (più semplici da utilizzare)
- Hardware di alta disponibilità normalmente, Hadoop cluster di hardware economico
- Scalabilità, aggiungendo nodi al cluster
- HDFS: Hadoop file system. File system distribuito che fornisce una efficace modalità di
accesso ai dati. HDFS garantisce che i dati siano ridondati nel cluster rendendo le
operazioni sui dati stessi immuni dall’eventuale guasto del nodo. HDFS accetta dati in
qualsiasi formato strutturato o non strutturato.
- YARN: un framework che permette di creare applicazioni o infrastrutture per il calcolo
distribuito. Esso si occupa delle risorse (memoria/cpu/storage) del cluster
- Map reduce: sistema di parallel processing di grandi quantità di dati. Utilizza il divide
et impera. Un problema complesso che utilizza grandi moli di dati, è suddiviso
assieme ai dati stessi, in piccole parti processate in modo autonomo e una volta che
ciascuna parte è calcolata, i vari risultati parziali sono “ridotti” a un unico risultato
finale.
- Pig: libreria che semplifica la creazione di job di trasformazione dei dati. Pig con il suo
linguaggio Pig Latin, consente di scrivere sequenze di operazioni di trasformazione in
maniera semplicistica che Pig stesso converte in comandi map reduce. cluster. 93

94. Corso Big Data
- Hive: è definito come sistema di dataware housing costruito su Hadoop, che consente di aggregare i dati, eseguire
query e analizzare grandi dataset. Hive utilizza il linguaggio HiveQL, simile a SQL.
- Hcatalog: sistema di gestione dei metadati che permette a chi utilizza Pig, Map Reduce, Hive di leggere o scrivere i
dati in modo più semplice su tutto il
94
- Hbase, database noSQL distribuito basato su Hadoop e HDFS, simile a BigTable di Google;
- Mohaut, libreria Hadoop per l'intelligenza articiale ed il datamining;
- Chukwa, strumento per l'analisi di log distribuita utilizzando Hadoop e HBase. Può essere utilizzata per analizzare i
log di Hadoop;

95. Corso Big Data
95

96. Corso Big Data
96

97. Corso Big Data
97

98. Corso Big Data
Hadoop
Hadoop è un framework che permette di controllare e gestire insiemi di dati di dimensioni particolarmente elevati,
fortemente orientato alla distribuzione di questi su cluster che presentino un alto numero di nodi. Il componente
principale di questo framework è il file system distribuito HDFS Hadoop Distributed File System, capace di organizzare e
distribuire i dati fornitogli dalle applicazioni che sono costruite su di esso, fornendo prestazioni di I/O particolarmente
elevate.
Blocks
Così come qualunque file system, anche HDFS presenta questa unità fondamentale, in cui però questi sono
particolarmente grandi rispetto ad un normale file system: la dimensione di default è di 64 MB o 128 MB, contro i 512 KB
di un comune file system. La ragione per cui questi file sono estremamente grandi è data dal fatto che, essendo esso
distribuito e finalizzato alla gestione di enormi quantità di dati, si vuole ridurre al massimo il tempo di seek time, cioè il
tempo speso dalla testina del disco fisso per raggiungere l’inizio del blocco dati.
98

99. Corso Big Data
Architettura
Un cluster HDFS ha due fondamentali unità che devono essere correttamente configurate per il funzionamento del
sistema: un Namenode e uno o piu` Datanode, rispettivamente il master e i workers del file system distribuito. Il
Namenode contiene tutti i metadata e l’albero del file system, memorizzandoli persistentemente sul disco fisso, oltre
a conoscere tutti i datanode su cui sono memorizzati tutti i blocchi di un dato file. Quest’ultima informazione non è
persistente, ma ricostruita comunicando direttamente coi datanode nel momento in cui il sistema viene avviato. I
Datanode sono coloro che si occupano di recuperare e memorizzare i blocchi, comunicando periodicamente il loro
stato e la mappa dei loro dati direttamente al Namenode. Il Namenode risulta essere quindi un punto critico per
HDFS, poichè un suo malfunzionamento causerebbe l’interruzione dell’intero servizio. La soluzione piu` utilizzata per
ovviare a questo problema è data dall’istanziare una terza unità, generalmente affidata ad una macchina diversa da
quelle su cui girano Namenode e Datanode, denominata Secondary Namenode. Il nome non deve però trarre in
inganno, perchè questa non si occupa di rimpiazzare il Namenode in caso questo abbia guasti o dare supporto ad
esso. Il suo compito è invece quello, non meno importante, di tenere periodicamente traccia delle operazioni svolte
dal master tenendo una copia del log operativo e di memorizzare il file system namespace. In caso di guasto, questa
unità servirà per poter fornire al Namenode, una volta ripristinato, una lista di operazioni da rielaborare o da
controllarne l’integrità. Da notare che è possibile eseguire il Namenode, piu` Datanode e anche il Secondary
Namenode, tutte su una stessa macchina, oppure distribuirle a piacimento su piu` nodi, soluzione sicuramente piu`
affidabile ed usata 99

100. Corso Big Data
Replicazione
HDFS è in grado di replicare i propri blocchi di dati su tutti i nodi da cui è composto. Di default il sistema è configurato per
creare due copie del dato, distribuendone una sullo stesso nodo dove viene memorizzato il dato originale. Nel caso le
singole macchine eseguano piu` istanze del processo datanode, la seconda copia va nello stesso nodo della prima, su
un’istanza differente di datanode, altrimenti viene scelto un secondo nodo dove memorizzare la copia. I vari nodi sono in
grado di comunicare tra loro lo stato e la quantità dei propri dati, permettendo una distribuzione di questi lungo tutto il
cluster. Alle applicazioni soprastanti queste operazioni appaiono completamente trasparenti.
L’analisi di Hadoop è stata svolta per permettere una piu` facile comprensione di alcune proprietà e di alcuni meccanismi
di HBase.
100

101. Corso Big Data
101

102. Corso Big Data
Map Reduce
102

103. Corso Big Data
103

104. Corso Big Data
104

105. Corso Big Data
105

106. Corso Big Data
106

107. Corso Big Data
107

108. Corso Big Data
108

109. Corso Big Data
109

110. Corso Big Data
110

111. Corso Big Data
111

112. Corso Big Data
112

113. Corso Big Data
113

114. Corso Big Data
114

115. Corso Big Data
115
CASSANDRA
E’ un data storage open source nato inizialmente come progetto interno a Facebook, per poi diventare nel marzo 2009
parte del progetto Incubator di Apache Software Foundation. Ancora prima di essere rilasciata la versione 1.0, questo
database contava già importanti utilizzi in produzione per grandi compagnie quali Facebook, Twitter, e Cisco.
Tipologia
Appartiene alla famiglia dei column-oriented database, fornendo tramite il concetto di Column Family una versione
estesa del metodo key-value store costruito su una struttura column-oriented, oltre che introdurre una struttura
aggiuntiva, le Super Column Families. Questo database rispetta le proprietà di partitioning e availability rispetto a quanto
detto nella sezione precedente riguardo al CAP theorem. I nodi, anche se non comunicanti tra loro, rendono sempre
disponibile la possibilità di scrivere e leggere i propri dati, lasciando poi decidere all’utente quali politiche di merge
adottare nel momento in cui la comunicazione tra nodi torni stabile.

116. Corso Big Data
116
Architettura
La sua architettura è basata sulla costruzione di una ring network, una rete ad anello in cui ogni nodo è gerarchicamente
uguale agli altri.Non ci sono configurazioni master-slave o simili, permettendo di avere un sistema no-single-point-of-
failure, cioè in grado di essere disponibile anche dopo la caduta di un qualsiasi nodo della rete. Il protocollo peer-to-peer
permette comunicazione tramite i vari nodi della ring. Ad ogni nodo viene assegnato un determinato range di token, valore
attribuito poi ad ogni dato inserito per permettere di determinare su quale nodo della rete andrà collocato, permettendo
una facile distribuzione dei dati su tutta la rete con una funzione di hash. I nodi che si prendono carico di gestire le
richieste dei clients sono detti entry point e questo ruolo può ovviamente essere ricoperto da un numero desiderato di
nodi, senza dover essere preventivamente specificato, dipendendo solamente dalle impostazioni del client.

117. Corso Big Data
117
Clusters
Creare un singolo anello è una soluzione comunemente usata, soprattutto per la sua semplicità implementativa. E’
possibile comunque disporre, in caso si voglia riservare particolare attenzione alla distribuzione fisica dei dati, di piu`
anelli cooperanti tra loro, soluzione in cui ovviamente tutti i nodi sono considerati ancora uguali. La possibilità di
avere una rete multi clusters viene utilizzata spesso per la replicazione dei dati, aumentando la reliability dell’intero
sistema.

118. Corso Big Data
118

119. Corso Big Data
119
Gossip protocol
Per verificare il corretto funzionamento della rete e controllarne l’integrità, Cassandra utilizza un protocollo di tipo
gossip, protocollo basato sulla distribuzione casuale e continua dell’informazione da un nodo all’altro, quest’ultimo
scelto casualmente dal primo. In Cassandra il gossip protocol implementato funziona proprio come detto:
periodicamente, un primo nodo ne sceglie un secondo a caso nella rete ed inizia con lui una gossip session, composta da
tre scambi di messaggi simile a quanto avviene nella procedura three-way handshake nel protocollo TCP. Colui che vuole
iniziare una sessione manda al nodo scelto un messaggio contenente le informazioni di cui dispone, quali la sua
conoscenza della rete e lo stato attuale dei dati. Il secondo nodo riceve il messaggio, modifica il proprio stato nel caso ce
ne fosse bisogno, e invia le proprie informazioni al primo nodo, il quale utilizza l’informazione ricevuta per modificare la
sua conoscenza, prima di terminare la comunicazione instaurata tramite un messaggio di chiusura.

120. Corso Big Data
120
Elastic scalability
Proprio per la semplicità strutturale della ring, l’elasticità dell’intero anello viene gestita in modo facile e
completamento automatico. L’aggiunta di un nodo prevede il suo inserimento all’interno dell’anello, la
ridistribuzione dei token per permettere un bilanciamento del carico dei dati e del lavoro, quindi la
riassegnazione/migrazione dei dati da un nodo all’altro in base al nuovo assegnamento dei token. Stessa cosa, al
contrario, avviene nel caso un nodo venga tolto dalla rete o non riesca ad essere piu` raggiungibile, caso in cui i
nodi rimanenti si occuperanno di distribuire tra loro i dati del nodo rimosso, riassegnando anche in questo caso i
token per un piu` equilibrato bilanciamento del database.

121. Corso Big Data
121

122. Corso Big Data
122
Keyspace
Si vuole ora introdurre il concetto di Keyspace. Questo `e l’unità informativa di piu` alto livello per Cassandra,
associabile ad un intero database di un modello relazionale, che deve essere creato prima di poter effettuare qualsiasi
operazione. Esso conterrà quindi tutte le singole tabelle, le quali erediteranno gli attributi definiti sul Keyspace che le
contiene. Questi attributi sono essenzialmente tre: Replication factor e Replica placement strategy, i cui funzionamenti
verranno illustrati a breve, indicanti quante copie del dato si vuole tenere nella rete e il modo in cui si voglia distribuire
queste copie, e le Column families, introdotte già nelle sezioni precedenti, paragonabili alle tabelle di un database
relazionale ed appartenenti ad uno e un solo keyspace.
L’ordine di importanza riguardo ai singoli elementi che compongono Cassandra è indicato tramite una classica
interrogazione, generalmente definita come get (keyspace, column family, row key).

123. Corso Big Data
123
Replicazione: Replication Factor e Replica placement strategy
La replicazione in un database consiste nel creare una copia del dato originale, permettendo di disporre dei dati anche
nel momento in cui un nodo presenti degli errori. Cassandra crea tante copie del dato originale quante ne sono state
definite tramite l’attributo Replication factor del relativo Keyspace nel quale si sta lavorando. Le copie sono recuperabili
in qualunque momento dal database, permettendo la disponibilità dei dati anche nel caso di malfunzionamento del
nodo contenente i dati originali. Le copie ricoprono inoltre un ruolo di controllo di correttezza e consistenza, illustrato a
breve, che può avere impatti anche molto rilevanti riguardo alle prestazioni.
Le copie così create possono essere distribuite sui vari nodi in accordo a due principali strategie tra cui scegliere: Simple
Strategy o Network Topology Strategy. Il primo, come mostrato in Fig.2.9, distribuisce i dati seguendo l’ordine dell’anello:
se si vuole creare una singola copia del dato originale, memorizzato nel nodo numero due, la copia andrà collocata nel
prossimo nodo seguendo la rete, vale a dire nel nodo numero tre. Si segue, all’aumentare del replication factor, la
circolarità dell’anello fino alla memorizzazione di tutte le copie. Il secondo distribuisce i dati in base alla propria
conoscenza della rete, dando priorità alla distribuzione su vari anelli poichè ci si aspetta che nodi appartenenti alla
stessa ring abbiano piu` probabilità di fallire piuttosto che nodi inseriti in anelli diversi, tenendo anche in considerazione
la vicinanza fisica delle macchine. Si noti che Cassandra permette di avere un replication factor maggiore del numero dei
nodi che compongono il database.

124. Corso Big Data
124

125. Corso Big Data
125
Eventual consistency
Cassandra sceglie un modello eventual consistency, facendo decidere al client che tipo di consistenza voglia essere
utilizzato. Questa indica quanti nodi devono confermare l’avvenuta operazione prima che questa possa essere
considerata conclusa, permettendo inoltre di controllare periodicamente la consistenza tra tutte le copie del dato
richiesto presenti nella rete. Si può allora attribuire a questo attributo il valore ONE, in cui la conferma da parte di un
solo nodo è necessario per considerare la transazione riuscita, TWO, in cui si attende la conferma di due nodi, e così
via, oltre ad altre possibilità quali ANY per l’attesa di tutti i nodi della rete o QUORUM, effettuando quindi un majority
voting tra i nodi dell’anello

126. Corso Big Data
126
MONGODB
MongoDB è un database sviluppato da MongoDB Inc., divenuto il principale database NoSQL utilizzato grazie alla sua
estrema facilità di installazione e manutenzione. Questa semplicità non preclude però di ottenere ottime prestazioni da
questo database, che grazie ad una campagna di vendita aggressiva e un supporto continuo, oltre alla fornitura di API in
molti linguaggi di programmazione, continua la sua scalata verso le prime posizioni tra i database piu` usati, anche piu` di
alcuni database relazionali.
Tipologia
MongoDB `e un database document-oriented, in cui quindi l’unità fondamentale sono i documenti[41], equivalenti alle
singole tabelle di un database relazionale ma molto piu` espressivi. Questi sono identificati tutti da una chiave speciale ed
univoca, id, che li identifica. A questi si aggiunge il concetto di collection, insieme di documenti, paragonabili a schemi. La
possibilit`a di innestare documenti o di avere delle referenze tra essi rende molto potente, flessibile e dinamico questo
modello. Per quanto riguarda il CAP theorem, MongoDB utilizza le proprietà di partitioning e consistency. I dati non sono
infatti disponibili nel momento in cui il nodo principale, detto primario e spiegato nel paragrafo successivo, non sia piu`
disponibile, dovendo aspettare un suo recupero prima di poter accedere ai dati in esso contenuti.

127. Corso Big Data
127
Replica set
La replicazione in MongoDB avviene creando un replica set. Questo `e un gruppo di nodi in cui, tramite una votazione
interna al set, uno di questi viene eletto come primario, mentre gli altri vengono catalogati come secondari. Questi ultimi
memorizzano solo copie esatte degli stessi dati contenuti nella macchina primaria, permettendo, nel caso questa non
dovesse essere piu` funzionante, di essere sostituita con una delle secondarie, scelta tramite una votazione effettuata
dall’intero gruppo. Importante è sottolineare che, mentre la macchina primaria può eseguire sia operazioni di scrittura
che di lettura, le secondarie possono servire solo operazioni di lettura, portando MongoDB ad essere particolarmente
efficace in applicazioni che fanno uso intensivo di read. Di default MongoDB permette comunque la sola lettura sul nodo
primario, attribuendo ai nodi secondari una funzione finalizzata solo al recupero dati in caso di guasto. Un replica set è
vincolato ad avere una sola macchina primaria e al massimo fino a sei macchine secondarie, a cui possono essere
aggiunte fino a cinque macchine che entrano in funzione solamente durante la fase di votazione per eleggere un nuovo
nodo primario. Le macchine dedicate a questa funzione sono denominate arbiter, e al contrario delle macchine
secondarie che possono diventare primarie, non cambiano mai il proprio stato. Un esempio di replica set `e mostrato in
Fig.2.10, in cui sono presenti tutti ruoli. Si noti che, al contrario di Cassandra, questo sistema permette quindi fino ad un
massimo di sette replicazioni, limitazione dovuta al numero di macchine secondarie implementabili in un replica set.

128. Corso Big Data
128

129. Corso Big Data
129
Wire protocol e Heartbeat message
Tutti i nodi che compongono una implementazione di MongoDB comunicano attraverso un protocollo denominato wire
protocol, che è sostanzialmente un protocollo TCP/IP semplificato. Questo consiste nel creare un contenitore con un
header, al cui interno sono descritti il tipo di operazione da eseguire, la lunghezza del messaggio, il nome della
collezione sulla quale eseguire la richiesta e un documento, generalmente in JSON, rappresentante l’informazione. Un
altro messaggio scambiato è il heartbeat request, richiesta inviata ogni due secondi tra ogni macchina per verificare lo
stato del cluster. Altra interessante funzione di questa richiesta è verificare che il nodo primario possa raggiungere la
maggioranza degli altri nodi e, in caso contrario, questo si auto-squalifica come primario della rete, procedendo a far
partire una votazione tra i membri del cluster per una nuova elezione.

130. Corso Big Data
130
Sharding e processi
Per distribuire i dati ed eseguire il partizionamento di questi sui diversi nodi della rete, MongoDB utilizza il processo detto
sharding. Ogni shard, il cui numero non `e limitato, diventa così proprietaria di un certo numero di dati, i quali possono essere
replicati rendendo la shard un replica set. Questo abilita l’interessante caratteristica di poter avere un numero di repliche
diverso per ogni shard. Per consentire il corretto funzionamento di questa struttura, devono essere eseguiti diversi processi,
che possono essere eseguiti su una o piu` macchine.
• mongod: mongod è il processo base per MongoDB. Esso può essere eseguito per avere un cluster di MongoDB composto da
un solo nodo, oppure decidere di avviarne molti per creare un replica set. Questi processi sono in grado di comunicare tra loro
ed eseguire votazioni per dichiarare il nodo primario, oltre alla possibilità di essere eseguiti con un particolare attributo per
definirli arbiter. Questi processi sono quindi incaricati di eseguire le interrogazioni richieste dai client, compiendo le relative
operazioni di lettura e scrittura in base al ruolo della macchina (primaria o secondaria).

131. Corso Big Data
131
• config server[37]: Nel momento in cui si decide di avere una rete multi shard, bisogna inserire due nuovi processi
all’interno dell’architettura di MongoDB. Il primo tra questi è il config server, processo chiave dell’intero cluster. Questo
contiene tutti i metadata riguardo a quale nodo contiene quale dato, diventando così un nodo estremamente importante
per la vita del database. Esso è una particolare istanza del processo mongod ed è possibile, nell’intero cluster, istanziarne
solamente uno o tre, per permettere un risultato sicuro ed immediato nel momento in cui debba svolgersi un majority
voting, necessario nel caso di inconsistenza dati.
• mongos: è il secondo processo necessario qualora si decida di creare piu` shard. Questo dispone di un elenco
contenente tutti i nodi che compongono il database e il relativo replica set di appartenenza, dati recuperati e
continuamente aggiornati attraverso la continua comunicazione con i config server. E’ inoltre l’unico processo ad essere
abilitato a comunicare con i client, reindirizzando la loro richiesta ai nodi delle varie shard e restituendo i risultati al
richiedente del servizio. Non ci sono limiti sul numero di istanze possibili di questo processo, definendo quindi il numero
di entry point per MongoDB uguale al numero di processi mongos istanziati.

132. Corso Big Data
132
Journal
Per ogni istanza del processo mongod viene creato, sulla stessa macchina, il suo rispettivo journal, sul quale vengono
memorizzati l’esatta locazione sul disco, ed i relativi byte
cambiati, riguardo ai dati inseriti in seguito ad una operazione di scrittura. Questo permette, in seguito ad un crash di
alcuni nodi della rete, di poter recuperare e rieseguire i cambiamenti svolti sul database dalle write che non sono state
fisicamente scritte su disco. Le operazioni vengono infatti memorizzate su disco ogni 60 secondi (di default), perciò il
journal necessita di memorizzare solo gli ultimi 60 secondi circa di quanto accaduto al database riguardo le scritture.

133. Corso Big Data
133

134. Corso Big Data
134
Write concern
Questa voce rappresenta quanta garanzia MongoDB fornisce all’applicazione client riguardo al successo di una operazione
di tipo write. Ci sono diversi livelli di garanzia, sviluppati per favorire la scelta di quella che può essere considerata
sufficiente per la propria specifica applicazione. I livelli di write concern sono:
• error ignored: con questa configurazione, al client non viene mai dato errore, indipendentemente dalla tipologia di
questo.
• unacknowledged: con questa modalità, il client viene reso consapevole di errori dovuti solamente a problemi di rete.
• normal: MongoDB fornisce al client una risposta sull’avvenuta ricezione dell’operazione di scrittura.
• journaled: con un journaled write concern il client viene avvisato della corretta esecuzione della scrittura solo una volta
che il database abbia non solo eseguito l’operazione, ma anche aver eseguito una commit di essa sul journal.
• replica acknowledged: l’ultima possibilità offerta prevede un invio di avvenuta esecuzione della scrittura solo quando
questa `e stata eseguita sul nodo primario oltre ad essere stato replicato sull’intero replica set.

135. Corso Big Data
135

136. Corso Big Data
136

137. Corso Big Data
137

138. Corso Big Data
138
Entry point

139. Corso Big Data
139

140. Corso Big Data
140

141. Corso Big Data
141

142. Corso Big Data
142
Mongo DB

143. Corso Big Data
143

144. Corso Big Data
144
Replicazione

145. Corso Big Data
145

146. Corso Big Data
146
Conclusioni

147. Corso Big Data
147
CLASSI DI COMPLESSITA’:
Espressività
L'algebra relaziona ha l'espressività del calcolo dei predicati al prim'ordine.
Questo risultato fissa l'espressività dell'algebra relazionale: le operazioni fondamentali su cui l'algebra è definita e che
sono alla base di SQL permettono di specificare tutte le formule del calcolo dei predicati al prim'ordine. Inoltre questo
risultato fissa anche i limiti dell'algebra relazionale (e di SQL). Ad esempio, è ben noto che l'operazione di chiusura
transitiva di una relazione non è definibile al prim'ordine. Tale operazione dunque non sarà definibile nè in algebra
relazionale nè in SQL.
Complessità
Il problema della valutazione, cioè del calcolo del risultato, di una espressione dell'algebra relazionale rispetto ad una base
di dati è completo nella classe di complessità PSPACE, cioè nella classe dei problemi risolubili in spazio polinomiale.
Questa sembra essere una brutta notizia, in quanto significa che non esistono con ogni probabilità algoritmi polinomiali per
tale problema. In realtà non lo è fino in fondo. Infatti, la complessità della valutazione di una espressione è esponenziale
nella dimensione della espressione e polinomiale nella dimensione della base di dati. La dimensione della base di dati è
di gran lunga superiore a quella dell'interrogazione, tanto che spesso si considera la complessità dell'interrogazione come
una costante e non più come un parametro di complessità. Fissando dunque la dimensione dell'interrogazione come
costante, e quindi riferendoci solo alla complessità dei dati, possiamo affermare che:

148. Corso Big Data
148
Il problema della valutazione dell'algebra relazionale è in PTIME, la classe dei problemi risolubili in tempo polinomiale. In
particolare, tale problema sta nella classe LOGSPACE, una sottoclasse di PTIME, che corrisponde ai problemi risolubili in
spazio logaritmico.
La classe LOGSPACE è una classe molto bassa nella gerarchia delle classi di complessità computazionale. In particolare i
problemi contenuti in questa classe si prestano ad essere risolti in modo parallelo.

149. Corso Big Data
149
Ottimizzazione
Questa proprietà è connessa al risultato di espressività già esposto. In particolare abbiamo che:
Ogni espressione di SQL può essere trasformata, con complessità polinomiale rispetto alla sua dimensione, in una
equivalente espressione del dell'algebra relazionale e viceversa.
Questa proprietà caratterizza l'algebra relazionale come la controparte procedurale di SQL. Si noti che la
trasformazione da SQL a algebra è efficiente.
Questo risultato apre le porte ad una serie di ottimizzazioni che è possibile intraprendere durante la valutazione di una
interrogazione SQL. Una interrogazione SQL, per essere valutate, viene prima trasformata una espressione in algebra
relazionale. Tale espressione viene poi riscritta in qualche versione equivalente ma ottimizzata rispetto a qualche misura
di complessità. Dato che l'operazione più costosa dell'algebra relazionale è il join e che la complessità del join dipende
dalla cardinalità delle tabelle argomento, l'obiettivo della riscrittura delle espressioni relazionali è quello di minimizzare
il numero di operazioni di join e di eseguire tali operazioni su tabelle di piccole dimensioni. Quest'ultimo risultato si
ottiene spingendo la selezione all'interno dei join in modo da filtrare le tabelle prima di sottoporle all'operazione di
congiunzione.
In sostanza, le motivazione teoriche che stanno dietro al successo di SQL sono la sua espressività e la possibilità di
risolvere efficientemente le sue interrogazioni.

150. Corso Big Data
150
Multitenancy e Data Isolation
Un’architettura software si definisce multitenant se più sue istanze sono in grado
di girare su un server ed essere così utilizzate ciascuna dall’applicazione di una
data organizzazione cliente, chiamata tenant, locatario in italiano. La
multitenancy è indispensabile per garantire l’isolamento del dato tra le varie
applicazioni tenant, evitando violazioni di privacy (un dato visto
dall’applicazione di un concorrente).

151. Corso Big Data
151
Il concetto di Multi-tenancy
Un tenant (in italiano vuol dire un inquilino) come indica il significato del
termine è un inquilino di una determinata infrastruttura, o anche di una
determinata applicazione o software, che però può essere condivisa da più
coinquilini, e contemporaneamente, in tempo reale. La multi-tenancy si riferisce ad
un principio nell’architettura del software o dell’hardware in cui una singola
istanza del software viene eseguita su un server, offrendo il proprio servizio a
più client (i tenant precedentemente citati). Il concetto di multi-tenancy non deve
essere confuso con quello di architettura multi-istanza, in cui istanze software
separate o sistemi hardware separati sono resi disponibili a diverse
organizzazioni. In un’architettura multi-tenant un’applicazione software è
progettata per partizionare virtualmente i suoi dati e la sua configurazione, ed
ogni tenant opera con una di queste istanze applicative personalizzate.
La multi-tenancy costituisce una conseguenza fondamentale della tecnologia di
virtualizzazione, grazie alla quale possiamo concretizzare un approccio multi-
tenant sulle risorse infrastrutturali, in quanto si assiste alla creazione di
ambienti virtuali logicamente separati sui medesimi componenti fisici condivisi.
L’aggettivo virtuale vuole evidenziare come tale tecnologia consenta di costruire
una separazione logica delle risorse.

152. Corso Big Data
152
Nonostante il concetto di multi-tenancy indichi che ci sono delle infrastrutture
condivise, ciò che fa la differenza è il livello nel quale le risorse diventano
multi-tenant. Per esempio Amazon AWS è multi-tenant a livello hardware in quanto i
suoi utenti possono trovarsi in uno stato di condivisione della stessa macchina
fisica. Force.com invece è multi-tenant a livello di database in quanto i suoi
utenti condividono i dati nelle stesse tabelle del DB. Mentre Amazon si affida ad
un hypervisor per fornire l’isolamento tra tenant (fondamentale perché le loro
attività non entrino in conflitto), Salesforce per ottenere la stessa proprietà si
basa su un query re-writer.

153. Corso Big Data
153
Approccio Salesforce alla
multitenancy

154. Corso Big Data
154
Un meccanismo di multi-tenancy a livello più alto quindi sostiene un approccio di
shared DB, ma questo non ammette automaticamente delle possibilità di miglior
collaborazione e condivisione tra diversi tenant. Per ottenere questo e formare
magari workgroup ed esplicitare membership c’è bisogno di un approccio SOA di
accesso ai dati ed autenticazione, che risulta migliore di un accesso diretto ad
un database condiviso. L’approccio multitenant di Amazon basato sull’hypervisor
isolation e quello di Salesforce basato sulla DB isolation sono entrambi validi,
ma afferenti ad una diversa clientela.

155. Corso Big Data
155
In un caso come quello di Salesforce il principio di multi-tenancy è
concretizzabile solo se vengono garantite alcune proprietà alle applicazioni
quali affidabilità, configurabilità, sicurezza, usabilità e rapidità per gli
utenti coinvolti. Applicazioni compilate staticamente difficilmente incontrano
tali requisiti. Sorge quindi la necessità di utilizzo di metadati, sia relativi
alle funzionalità comuni del programma che in associazione alle con figurazioni
dei diversi tenant, consentendo un’evoluzione real-time dei singoli componenti.

156. Corso Big Data
156
LA COMPLESSITA’ COMPUTAZIONALE
La complessità computazionale di un algoritmo è definita come l'ordine di grandezza della funzione
che determina il numero di passi elementari da svolgere per eseguirlo, al crescere della dimensione dei dati di ingresso.
La complessità computazionale, in questo senso, è quindi una misura di tempo astratta che ha, al più,
una relazione di proporzionalità con il tempo effettivo di esecuzione.
Si parla anche di complessità computazionale spaziale, intesa come dimensione della struttura dati necessaria a
supportare l’esecuzione di un algoritmo. Tuttavia, non si dovrebbe associare la complessità (computazionale) spaziale
alla memoria e computazionale al tempo, poiché in entrambi i casi si sta valutando l’ordine di grandezza delle quantità
associate (tempo e memoria).
L’analisi della complessità temporale di un algoritmo consente di determinare l’ordine di grandezza del tempo necessario
per eseguirlo senza nemmeno iniziare la computazione.

157. Corso Big Data
157

158. Corso Big Data
158

159. Corso Big Data
159

160. Corso Big Data
160
#P Conta le soluzioni di un problema NP
#P-complete I problemi più duri in #P
AM Problemi risolubili in tempi polinomiali da un protocollo di Arthur - Merlin
BPP
Problemi risolubili in tempi polinomiali da algoritmi randomizzati (la risposta è
probabilmente corretta)
BQP
Problemi risolubili in tempi polinomiali da un computer quantistico (la risposta è
probabilmente corretta)
Co-NP Risposte NO verificabili in tempi polinomiali
Co-NP-complete I problemi più duri in Co-NP
DSPACE(f(n)) Risolubili da una macchina deterministica in spazio di memoria O(f(n)).
DTIME(f(n)) Risolubili da una macchina deterministica in tempi O(f(n)).
E Risolubili in tempi esponenziali con esponenti lineari nel tempo
ELEMENTARY Unione delle classi nella gerarchia esponenziale
ESPACE Risolubili in spazi esponenziali con esponente lineare nello spazio
EXP Sinonimo di EXPTIME
EXPSPACE Risolubili in spazi esponenziali
EXPTIME Risolubili in tempi esponenziali
FNP Analogo di NP per problemi di funzione
FP Analogo di P per problemi di funzione
FPNP
Analogo di PNP per problemi di funzione; qui si colloca il problema del commesso
viaggiatore

161. Corso Big Data
161
IP Risolubili in tempi polinomiali da un sistema per dimostrazioni interattive
MA Risolubili in tempi polinomiali da un protocollo Merlin - Arthur
NC Risolubili efficientemente (in tempi polilogaritmici) con computers paralleli
NE
Risolubili da una macchina non-deterministica in tempi esponenziali con esponente
lineare
NESPACE
Risolubili da una macchina non-deterministica in spazio esponenziale con
esponente lineare
NEXP Sinonimo di NEXPTIME
NEXPSPACE Risolubili da una macchina non-deterministica in spazi esponenziali
NEXPTIME Risolubili da una macchina non-deterministica in tempi esponenziali
NP Risposte YES verificabili in tempi polinomiali (vedi classi di complessità P e NP)
NP-complete I problemi più duri in NP
NP-easy Analogo a PNP per problemi di funzione; sinonimo di FPNP
NP-equivalent I problemi più duri in FPNP
NP-hard O NP-complete o più duro
NSPACE(f(n)) Risolubili da una macchina non-deterministica in uno spazio O(f(n)).
NTIME(f(n)) Risolubili da una macchina non-deterministica in tempi O(f(n)).

162. Corso Big Data
162
P Risolubili in tempi polinomiali
P-complete I problemi più duri risolubili in P da computers paralleli
PCP Dimostrazioni verificabili probabilisticamente
PH Unione delle classi della gerarchia polinomiale
PNP Risolubili in tempi polinomiali da un oracolo per un problema in NP; sinonimo di Δ2P
PP
Probabilisticamente polinomiali (risposta corretta con probabilità leggermente
superiore a 1/2)
PSPACE Risolubili con memoria polinomiale in tempi illimitati
PSPACE-complete I problemi più duri in PSPACE
RP
Risolubili in tempi polinomiali da algoritmi randomizzati (la risposta NO è
probabilmente corretta, la YES certamente corretta)
UP Funzioni valutabili in tempi polinomiali non ambigui non-deterministici.
ZPP
Risolubili da algoritmi randomizzati (risposta sempre corretta, tempo medio di
esecuzione polinomiale)

163. Corso Big Data
163
SOA
 Argomenti
 introduzione
 SOA come stile architetturale [SAP]
 SOA e obiettivi di business I
 dai servizi alle SOA
 principi per la progettazione dei servizi
 SOA e obiettivi di business II
 SOA e Layers
 enterprise service bus
 discussione

164. Corso Big Data
164
 La tecnologia (middleware) a servizi
 è una tecnologia per l’integrazione di applicazioni distribuite –
volta a risolvere problemi pragmatici di interoperabilità, basata
su standard accettati dalla maggior parte dei produttori di
software
 i Web Services rappresentano la tecnologia “dominante” in
questa arena
 L’architettura orientata ai servizi (SOA)
 fornisce il contesto metodologico (e di business) in cui utilizzare
al meglio le tecnologie basate su servizi

165. Corso Big Data
165
 L’architettura orientata ai servizi è basata sui servizi come
costrutto (tipo di componente software) per sostenere sviluppo e
composizione di applicazioni distribuite
 un servizio ha l’obiettivo di incapsulare una ben precisa
funzionalità di business (logica applicativa), per renderla
disponibile e accessibile come servizio software da parte di
client software sul web – ciascun servizio può essere usato per
costruire diverse applicazioni e processi di business
 SOA (Service-Oriented Architecture, ovvero architettura
orientata ai servizi) è uno stile architetturale per la costruzione
di una molteplicità di sistemi o applicazioni sulla base della
composizione di un insieme di servizi – e non semplicemente
per la costruzione di un singolo sistema come composizione di
un insieme di servizi

166. Corso Big Data
166
 Alcuni confondono WS e SOA – tuttavia, i due concetti sono ben
distinti
 i WS sono una tecnologia per l’implementazione di servizi
 basata su standard specifici
 una tecnologia abilitante alla realizzazione di soluzioni SOA
 una tecnologia è necessaria per realizzare una SOA – ma
non è sufficiente
 SOA è un approccio per progettare sistemi
 con lo scopo specifico di favorire la condivisione e
l’integrazione di servizi
 l’adozione di una SOA è resa più semplice dalla tecnologia
dei WS

167. Corso Big Data
167
 Un Web Service
 è un modulo o componente software, auto-contenuto e autodescrittivo, accessibile mediante Internet, in
modo indipendente
dalla piattaforma
 rappresenta un servizio, ovvero ha lo scopo di svolgere un
compito, risolvere un problema, o condurre transazioni per
conto di un utente o applicazione
 I Web Services
 possono essere messi in corrispondenza e composti –
favorendo l’integrazione di servizi, per creare processi di
business completi, con un costo di sviluppo ridotto
 questa possibilità è basata sulle capacità di descrivere servizi
(WSDL), scoprire servizi (UDDI), invocare servizi (SOAP),
comporre servizi (BPEL), definire livelli di qualità dei servizi
(WS-*)

168. Corso Big Data
168
 SOA è uno stile architetturale che (come ogni altro stile) si
propone di perseguire un certo numero di obiettivi di qualità
 SOA (come altri stili architetturali) sostiene attributi di qualità
“tecnologica”
 in primo luogo l’interoperabilità – ma anche sicurezza,
affidabilità, disponibilità, ...
 inoltre, SOA (diversamente da altri stili architetturali) cerca
anche di sostenere obiettivi di “business”, correnti e futuri, delle
organizzazioni
 agilità di business – integrazione dei processi di business
all’interno dell’organizzazione – integrazione dei processi di
business con partner, fornitori e clienti – possibilità di
monitorare/governare l’efficacia dei miglioramenti nei
processi di business

169. Corso Big Data
169
SOA e obiettivi di business
 Le architetture software sono il ponte tra gli obiettivi di business di
un’organizzazione e i loro sistemi software
 le tecnologie e gli stili architetturali studiati finora (ad es.,
l’architettura a componenti) si pongono l’obiettivo di sostenere
attributi di qualità “tecnologica” – prestazioni, scalabilità,
sicurezza, ...
 nell’architettura orientata ai servizi – grazie anche alla maggior
maturità delle tecnologie sottostanti – l’attenzione si sposta
anche e soprattutto sugli aspetti e gli obiettivi di “business”,
correnti e futuri, delle organizzazioni

170. Corso Big Data
170
 Il contesto in cui si muovono oggi le grandi organizzazioni
 alta competitività e alta incertezza
 integrazione globale – di informazioni e processi
 le organizzazioni richiedono agilità
 per offrire i propri servizi (in senso aziendale) in modo più
efficiente/efficace
 per offrire servizi innovativi, per offrire servizi a nuovi mercati
 un’organizzazione deve poter cambiare rapidamente – e
poter continuare a cambiare in modo flessibile – i propri
processi di business (processi aziendali)
 inoltre, il ruolo delle tecnologie informatiche (IT) è tale che il
business di un’organizzazione può essere flessibile solo quanto
la sua infrastruttura IT

171. Corso Big Data
171
 Lo stile SOA si propone di far sì che l’IT sostenga – anziché
ostacolare – l’agilità di business delle organizzazioni
In un’architettura a servizi
 ciascun servizio incapsula una funzionalità di business
 i servizi sono integrati e composti per formare applicazioni e
sistemi
 i servizi sono debolmente accoppiati – per rendere più facile,
più flessibile e più agile la loro integrazione e composizione

172. Corso Big Data
172
 L’innovazione può essere definita come il processo di effettuare
un cambiamento per realizzare/fare qualcosa di nuovo
 nei sistemi tradizionali, hardware, software e reti sono integrati
in modo rigido – quindi effettuare cambiamenti è difficile
 SOA rende più semplici i cambiamenti e l’innovazione
 in una SOA, l’IT è realizzato come un insieme di “componenti”
che è facile assemblare e riconfigurare
 ciascuno di questi “componenti” è un servizio di business –
erogato dalla propria oppure anche da un’altra organizzazione
 in una SOA, questi servizi possono assemblati come si vuole –
sostenendo cambiamento e innovazione – risparmiando tempo
e denaro

173. Corso Big Data
173
 Ai fini del successo di un’organizzazione (o di un’azienda), è di
fondamentale importanza la costruzione di sistemi informatici che
soddisfano e sostengono gli obiettivi di business, correnti e futuri,
dell’organizzazione – in questo contesto, SOA affronta i seguenti
problemi e obiettivi di business
 allineare business e IT, in modo che possano variare insieme
 sostenere agilità di business
 sulla base dello sviluppo agile di nuove applicazioni
 realizzate come applicazioni composte
 basate sul riuso di servizi software già esistenti all’interno
dell’organizzazione
 nonché sulla possibilità di fruire anche di servizi software
esterni all’organizzazione

174. Corso Big Data
174
Dai servizi alle SOA
Come già detto, SOA è uno stile per la costruzione di sistemi o
applicazioni sulla base della composizione di un insieme di servizi
 SOA è un approccio architetturale per la costruzione di sistemi
o applicazioni che usano un insieme di servizi
 e non semplicemente per la costruzione di un sistema come
un insieme di servizi
 un servizio è un’implementazione di un ben definito pezzo di
funzionalità di business, con un’interfaccia pubblicata e che può
essere scoperta e che può essere usata dai consumatori del
servizio nel costruire diverse applicazioni e processi di business
 si noti che, nella definizione di una SOA, non si fa riferimento a
nessuna particolare tecnologia per l’implementazione dei
servizi
 inoltre, in una SOA è fondamentale la composizione dei servizi

175. Corso Big Data
175
 Organizzazione di una SOA
 ogni servizio implementa una funzionalità di business discreta
 ogni applicazione che ha bisogno di eseguire quella
particolare funzionalità, può usare quel servizio condiviso
 ogni applicazione è creata assemblando e coordinando le
attività tra quell’insieme appropriato di servizi che serve a
realizzare un processo di business di interesse
 il sistema orientato ai servizi di un’organizzazione comprende
più applicazioni/processi di business
 ciascun servizio può essere riusato in più applicazioni
 i servizi sono debolmente accoppiati – tra loro e con le
applicazioni/processi
 anche la granularità dei servizi è importante
 può essere raccomandato avere servizi a grana grossa, da
utilizzare scambiando pochi messaggi a grana grossa
anziché tanti messaggi a grana fine

176. Corso Big Data
176
 Dunque, una SOA è organizzata soprattutto attorno a due livelli
(strati) fondamentali, i cui componenti rappresentano,
rispettivamente
 servizi di business
 processi di business
 Inoltre, i processi di business sono definiti come composizione di
servizi
 la composizione è di solito un’attività di assemblaggio – e solo
raramente un’attività di sviluppo
 per questo i processi di business possono essere definiti o
modificati “rapidamente”

177. Corso Big Data
177
- Ciclo di vita nelle SOA
 In una SOA, lo sviluppo del software non avviene sulla base di un
processo tradizionale progetta/compila/esegui, ma piuttosto sulla
base di un processo iterativo modella/ assembla/ rilasciaconfigura/ monitora-gestisci
 Ciclo di vita SOA
 model
 trova i requisiti (di business) – modella (il business, e non
l’applicazione) e simula – progetta (i servizi)
 assemble
 scopri – costruisci e verifica – componi
 poiché il green-field development è raro, questa attività può
essere di solito svolta piuttosto rapidamente
 deploy
 essenzialmente integrazione – di persone, processi e
informazioni
 manage
 gestisci (i servizi e i processi di business, e non le
applicazioni) – monitora (metriche di business)

178. Corso Big Data
178
 SOA – Service-Oriented Architecture [SEI]
 un servizio è un’implementazione di un pezzo ben definito di
funzionalità di business – con un’interfaccia che è pubblicata e
può essere cercata/trovata – che può essere usato da
consumatori di servizi nella costruzione di diversi processi di
business e applicazioni
 SOA è un approccio architetturale per costruire sistemi e
applicazioni che usano un insieme di servizi – e non solo un
singolo sistema come un insieme di servizi

179. Corso Big Data
179
 SOA – Service-Oriented Architecture [Marks&Bell]
 un servizio è una funzionalità di business con un’interfaccia
esposta, che può essere invocato dai suoi consumatori
mediante messaggi
 SOA è un’architettura concettuale di business in cui le
funzionalità di business (logica applicativa) vengono esposte
agli utenti SOA come servizi riusabili e condivisi in rete
 un servizio è un’unità, modulare e riusabile, di capacità di
business, processo o funzione tecnica, che può essere
acceduto/utilizzato in modo ripetuto da una molteplicità di
consumatori
 i servizi sono la risorsa architetturale primaria di una SOA
 SOA è una disciplina critica per far sì che i servizi lavorino
insieme per aiutare l’organizzazione a raggiungere i propri
obiettivi di business

180. Corso Big Data
180
 SOA – Service-Oriented Architecture [Papazoglou]
 lo scopo essenziale di una SOA è di abilitare l’interoperabilità
tra tecnologie esistenti, nonché l’estendibilità a scopi e
architetture futuri ....
 SOA è uno stile architetturale il cui obiettivo è consentire alle
organizzazioni di sviluppare, connettere e mantenere
applicazioni e servizi di tipo enterprise in modo efficiente ed
economico
 una SOA fornisce un insieme di linee guida, principi e tecniche
per cui i beni, le informazioni, e i processi di business di
un’organizzazione possono essere ri-organizzati efficacemente
per sostenere e abilitare piani strategici e livelli di produttività
come richiesto da ambienti di business competitivi

181. Corso Big Data
181
 Il cloud computing è [NIST]
 un modello di elaborazione
 che abilita un accesso in rete, su richiesta, ubiquo e
conveniente
 a un pool di risorse di calcolo (CPU, storage, reti, sistemi
operativi, servizi e/o applicazioni) condivise e configurabili
 che possono essere acquisite e rilasciate rapidamente e in
modo dinamico
 con uno sforzo di gestione minimo, o comunque con
un’interazione minima con il fornitore del servizio

182. Corso Big Data
182
 Il cloud computing prevede tre modelli di servizio principali
 Software as a Service – SaaS
 il cloud fornisce servizi (applicazioni) – che vengono utilizzati
direttamente dall’utente finale
 Platform as a Service – PaaS
 il cloud fornisce servizi che sono piattaforme runtime, che
supportano l’esecuzione di programmi – ad es., una
piattaforma per l’esecuzione di applicazioni web
 l’utente è uno sviluppatore di applicazioni per quella
piattaforma
 Infrastructure as a Service – IaaS
 il cloud fornisce servizi infrastrutturali – come server (CPU e
sistemi operativi), storage e connettività
 l’utente è uno sviluppatore o un amministratore di sistema
per un’infrastruttura che va configurata

183. Corso Big Data
183
 Alcuni esempi
 Software as a Service – SaaS
 Google Apps (Gmail, Google Docs, ...)
 Microsoft Office Live
 le applicazioni di Salesforce.com (es., CRM)
 Platform as a Service – PaaS
 Google App Engine
 Microsoft Windows Azure
 Amazon Elastic Beanstalk
 Infrastructure as a Service – IaaS
 molti prodotti/servizi di Amazon Web Services (Amazon
AWS) – tra cui Amazon Elastic Compute Cloud (EC2) e
Amazon Simple Storage Service (S3)

184. Corso Big Data
184
 Cinque caratteristiche essenziali per il cloud computing [NIST]
 pooling di risorse
 le risorse di calcolo del fornitore del servizio sono riunite per
servire una molteplicità di consumatori, secondo un modello
multi-tenant (letteralmente, “con più affittuari”)
 le risorse fisiche e virtuali sono assegnate e riassegnate
dinamicamente ai consumatori, sulla base delle loro richieste
 c’è inoltre un’indipendenza dalla locazione – i consumatori
non hanno né controllo né conoscenza della locazione
esatta delle risorse che gli sono assegnate
 è tuttavia possibile che i consumatori abbiano controllo
sulla locazione a un livello di astrazione più alto, ad
esempio la nazione (spesso è necessario per motivi di
legge)

185. Corso Big Data
185
 Cinque caratteristiche essenziali per il cloud computing [NIST]
 elasticità rapida
 le capacità di calcolo possono essere ottenute in modo
rapido e elastico, e in alcuni casi questo può avvenire
automaticamente
 elasticità – è possibile scalare rapidamente queste capacità
di calcolo – sia all’insù che all’ingiù
 per il consumatore del servizio, queste capacità di calcolo
spesso appaiono illimitate, e possono essere acquisite in
qualunque momento e in qualunque quantità

186. Corso Big Data
186
 Cinque caratteristiche essenziali per il cloud computing [NIST]
 misura dei servizi
 i sistemi di cloud computing controllano e ottimizzano in
modo automatico l’uso delle risorse, sulla base di misure
appropriate per il tipo del servizio – ad es., per lo storage,
sia la quantità memorizzata che la quantità mossa nel tempo
 la misurazione dell’uso delle risorse fornisce trasparenza sia
al fornitore che al consumatore del servizio utilizzato

187. Corso Big Data
187
 Il cloud computing è [Vaquero]
 un grande insieme di risorse (come hardware, piattaforme di
sviluppo e/o servizi)
 che sono virtualizzate
 e sono facilmente accessibili e usabili
 queste risorse
 possono essere dinamicamente riconfigurate – per adattarle
a un carico variabile (sono scalabili) – favorendo un utilizzo
ottimale delle risorse
 sono tipicamente utilizzate sulla base di un modello di
pagamento a consumo
 sono dotate di garanzie – sulla base di SLA personalizzate –
offerte dal loro fornitore

188. Corso Big Data
188
Enterprise Service Bus
 Nelle SOA è necessaria un’infrastruttura di comunicazione
distribuita per sostenere concretamente l’interoperabilità tra
diverse tecnologie, in modo flessibile e scalabile
 infatti, in una SOA devono convivere, interoperando, numerose
applicazioni e componenti sviluppati autonomamente
 Una possibile infrastruttura per la realizzazione e il deployment di
una SOA è fornita dal pattern architetturale Enterprise Service Bus
 un ESB affronta le problematiche di deployment della SOA –
sicuramente significative in presenza di servizi realizzati in
ambienti distribuiti/eterogenei
 consente così di affrontare separatamente gli aspetti funzionali
da quelli di deployment
 ESB è un pattern architetturale per il brokering tra servizi – in
generale, dunque, il termine ESB non indica un prodotto

189. Corso Big Data
189
 Enterprise Service Bus (ESB)
 è un’infrastruttura di connettività flessibile
 per integrare applicazioni, sistemi eterogenei e servizi
 sulla base di standard e funzionalità MOM
 riducendo numero, dimensione e complessità delle
interfacce
 al fine di abilitare implementazione, deployment e
gestione di
soluzioni basate su SOA

190. Corso Big Data
190
 Alcune funzionalità e caratteristiche essenziali di un ESB
 supporto fondamentale per i web services, per la loro
invocazione e composizione
 routing di messaggi tra applicazioni e servizi – anche basato sul
contenuto dei messaggi
 conversione di protocolli di trasporto
 validazione e trasformazione di dati e messaggi
 distribuzione di eventi di business
 possibilità di distribuire (e coordinare) le funzionalità su più
server
 supporto per la connessione a sistemi legacy
 supporto per sicurezza, transazioni, affidabilità, ...
 strumenti per l’amministrazione integrata, la gestione della
sicurezza, per il monitoraggio runtime dei servizi e dei processi

191. Corso Big Data
191
 Elementi di un ESB – per fornire le facilitazioni di supporto ai
diversi stili di interazione
 integration broker
 facilita il movimento (e la trasformazione) di informazioni tra
più partecipanti
 application server
 offrono un ambiente integrato di sviluppo ed esecuzione, per
il deployment di applicazioni basate (o meno) sul web
 business process management
 supporta l’esecuzione e il coordinamento di processi di
business di lunga durata, che coinvolgono più applicazioni e
più utenti
 supportano il monitoraggio della qualità dei servizi erogati

192. Corso Big Data
192
Approccio Object-Oriented (OO) e persistenza
• Un sistema informativo che non preserva dati al suo spegnimento è di poca utilità
• I linguaggi di programmazione OO non offrono soluzioni “native” al problema della
persistenza, ovvero al problema della gestione di dati persistenti da parte di
applicazioni OO
• i dati vivono più a lungo di qualsiasi
applicazione
• La soluzione al problema della persistenza richiede un
meccanismo per specificare la corrispondenza tra il
dominio dell’applicazione e la base di dati che risolva
opportunamente il problema dell’impedance mismatch
• Tale meccanismo è comunemente chiamato
object-relational mapping (ORM)

193. Corso Big Data
193
• Idea: si identificano le classi di oggetti dell’applicazione
di tipo persistente e si fa in modo che i loro attributi e
proprietà siano “mappati” su dati memorizzati in una
base di dati relazionale
• Su tali oggetti saranno definite ed invocate operazioni
di creazione, modifica, cancellazione, con l’obiettivo di
effettuare letture e modifiche sulla base dati sottostante

194. Corso Big Data
194

195. Corso Big Data
195

196. Corso Big Data
196
Persistence classes gestiscono l’accesso ai dati,
incapsulando le modalità di accesso
Domain classes (Business Objects) Sono le classi che
rappresentano i concetti pertinenti al dominio
dell’applicazione. Ogni classe deve incorporare il
comportamento specifico delle sue istanze.
Controller Classes Le classi di controllo incorporano la
logica di business. Le operazioni implementate in una
classe di controllo possono coinvolgere più di una
domain class ed eventualmente altre classi di controllo.
User Interface Classes Sono le classi che incorporano
l’interfaccia offerta direttamente all’utente.
Utility Classes Ogni applicazione ha un insieme
infrastrutturale di classi, chiamate Utility classes, che
sono usate ad ogni livello dell’applicazione (e.g. Class
Exception)

197. Corso Big Data
197
Object-relational mapping
In informatica l'Object-Relational Mapping (ORM) è una tecnica di programmazione che favorisce
l'integrazione di sistemi software aderenti al paradigma della programmazione orientata agli oggetti con
sistemi RDBMS.
Un prodotto ORM fornisce, mediante un'interfaccia orientata agli oggetti, tutti i servizi inerenti
alla persistenza dei dati, astraendo nel contempo le caratteristiche implementative dello specifico RDBMS
utilizzato.

198. Corso Big Data
198
Descrizione
I principali vantaggi nell'uso di un tale sistema sono i seguenti.
 Il superamento (più o meno completo) dell'incompatibilità di fondo tra il progetto orientato agli oggetti ed
il modello relazionale sul quale è basata la maggior parte degli attuali RDBMS utilizzati; con una metafora
legata al mondo dell'elettrotecnica, si parla in questo caso di disadattamento dell'impedenza tra paradigma
relazionale e ad-oggetti (object/relational impedance mismatch).
 Un'elevata portabilità rispetto alla tecnologia DBMS utilizzata: cambiando DBMS non devono essere
riscritte le routine che implementano lo strato di persistenza; generalmente basta cambiare poche righe
nella configurazione del prodotto per l'ORM utilizzato.
 Drastica riduzione della quantità di codice sorgente da redigere; l'ORM maschera dietro semplici comandi
le complesse attività di creazione, prelievo, aggiornamento ed eliminazione dei dati (dette CRUD - Create,
Read, Update, Delete). Tali attività occupano di solito una buona percentuale del tempo di stesura, testing
e manutenzione complessivo. Inoltre, sono per loro natura molto ripetitive e, dunque, favoriscono la
possibilità che vengano commessi errori durante la stesura del codice che le implementa.
 Suggerisce la realizzazione dell'architettura di un sistema software mediante approccio stratificato,
tendendo pertanto ad isolare in un solo livello la logica di persistenza dei dati, a vantaggio
della modularità complessiva del sistema.

199. Corso Big Data
199
I prodotti per l'ORM attualmente più diffusi offrono spesso nativamente funzionalità che altrimenti andrebbero
realizzate manualmente dal programmatore:
 Caricamento automatico del grafo degli oggetti secondo i legami di associazione definiti a livello di
linguaggio. Il caricamento di un'ipotetica istanza della classe Studente, potrebbe automaticamente produrre
il caricamento dei dati collegati sugli esami sostenuti. Tale caricamento, in più, può avvenire solo se il dato è
effettivamente richiesto dal programma, ed è altrimenti evitato (tecnica nota con il nome di lazy-
initialization).
 Gestione della concorrenza nell'accesso ai dati durante conversazioni. Conflitti durante la modifica di un
dato da parte di più utenti in contemporanea, possono essere automaticamente rilevati dal sistema ORM.
 Meccanismi di caching dei dati. Per esempio, se accade che uno stesso dato venga prelevato più volte dal
RDBMS, il sistema ORM può fornire automaticamente un supporto al caching che migliori le prestazioni
dell'applicazione e riduca il carico sul sistema DBMS.
 Gestione di una conversazione mediante uso del design pattern Unit of Work, che ritarda tutte le azioni di
aggiornamento dei dati al momento della chiusura della conversazione; in questo modo le richieste inviate
al RDBMS sono quelle strettamente indispensabili (per es. viene eseguita solo l'ultima di una serie di
update su uno stesso dato, oppure non viene eseguita affatto una serie di update su di un dato che in
seguito viene eliminato); inoltre il colloquio con il DBMS avviene mediante composizione di query multiple in
un unico statement, limitando così al minimo il numero di round-trip-time richiesti e, conseguentemente, i
tempi di risposta dell'applicazione.
L'uso di un ORM favorisce il raggiungimento di più alti standard qualitativi software, migliorando in particolare le
caratteristiche di correttezza, manutenibilità, evolvibilità e portabilità.

200. Corso Big Data
200
ORM: DAO
• Prevede di realizzare uno strato dell’applicazione
(chiamato appunto DAO) demandato completamente a
gestire la comunicazione fra l’applicazione ed il DBMS
• anche in questo caso il mapping è realizzato
manualmente attraverso l’uso di JDBC/SQL
• l’accesso al DB viene però opportunamente
incapsulato nelle classi DAO:
– nasconde alla logica di business codice JDBC
complesso e SQL non-portabile
– fornisce un interfacciamento esplicito del codice
– migliora la modularità, risolve problemi di
accoppiamento tipici dell’approccio forza bruta

201. Corso Big Data
201
Un oggetto di una classe di business, per accedere al
database
• invoca metodi di una classe demandata a gestire gli
accessi al DB (relativamente alle informazioni richieste)
• è questa classe che costruisce lo statement SQL e lo
passa al driver, riceve i risultati dal database e li inoltra
alla classe di business che la ha interrogata
• la classe di business effettua poi le sue elaborazioni sui
dati ricevuti

202. Corso Big Data
202
• Tutta la logica di accesso al DB è completamente
incapsulata nelle classi DAO
• Cambiamenti del DB influenzano solo le DAO
• La classe CustomerData si fa carico di gestire il codice
SQL, mentre tutto ciò è trasparente rispetto alla classe
Customer (che è una domain class), la quale invoca
metodi indipendenti dal DB
• L’approccio tipico è quello di avere un DAO per
ciascuna domain class

203. Corso Big Data
203
DAO
Vantaggi:
• incapsulamento
• possibilità di accedere a DB mal progettati o
pre-esistenti all’applicazione
• facilità di riuso dell’applicazione
• minore accoppiamento fra le classi di dominio (solo
dovuto alle dipendenze esplicitate dal class diagram)
Svantaggi:
• c’è ancora accoppiamento tra persistence classes e DB
• chi sviluppa l’applicazione (le persistence classes) deve
conoscere dettagli sul DB
• può essere dipendente dalla tecnologia