Hadoop Ecosystem. Richiamo concetti precedenti

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Hadoop Ecosystem. Richiamo concetti precedenti"

Transcript

1 Hadoop Ecosystem

2 Hadoop Ecosystem Richiamo concetti precedenti

3 Hadoop Ecosystem The Four V

4 Hadoop Ecosystem HDFS: a distributed filesystem

5 Hadoop Ecosystem MapReduce: a dataflow programming framework

6 Hadoop Ecosystem MapReduce: a simplified data processing language

7 Hadoop Ecosystem Hadoop Scripting Pig

8 Hadoop Ecosystem NoSQL

9 Hadoop Ecosystem Dunque... sappiamo cosa si intende per BigData; sappiamo dove memorizzare questi dati; sappiamo come elaborarli in modalità batch con MapReduce; possiamo usare linguaggi di scripting come Pig e Hive, che ci tengono al riparo dalla complessità del MapReduce; sappiamo anche come memorizzare i risultati di queste elaborazioni su sistemi NoSQL che ci garantiscono una elevata scalabilità orizzontale nell'accesso ai dati; Ma... come raccogliamo i dati? come li trasferiamo su HDFS? come creiamo un dataflow?

10 Hadoop Ecosystem Data Acquisition

11 Data Acquisition Sorgenti distribuite ed eterogenee external data services LAN WAN BigData System

12 Data Acquisition Producer-Consumer Pattern Le sorgenti di dati di BigData System sono variegate, distribuite e tipicamente non sono sotto il controllo degli sviluppatori. Tuttavia, essendo l'approvvigionamento dei dati un problema comune, è naturale che nell'ecosistema Hadoop si siano sviluppate delle tecnologie che facilitano l'acquisizione e l'accentramento di dati provenienti da sorgenti esterne. E poiché la maggior parte di esse si basa sul modello produttore-consumatore è utile introdurre il modello generale in modo da poterci poi concentrare solo sugli aspetti particolari che caratterizzano ciascuna tecnologia.

13 Data Acquisition Producer-Consumer Pattern Il modello produttore-consumatore è nato per risolvere un problema di sincronizzazione tra processi : un processo che produce dei dati un processo che elabora quei dati producer Channel consumer Tipicamente questi processi sono implementati come dei loop e, altrettanto tipicamente, la velocità con cui i dati sono prodotti è diversa da quella con cui vengono elaborati. Questo impone un qualche meccanismo di sincronizzazione.

14 Data Acquisition Producer-Consumer Pattern La strategia generale è quella di implementare il Channel come una coda in cui i dati prodotti dal Produttore possono essere accumulati in attesa che il Consumatore li elabori. La coda ha, per definizione, una capacità limitata per cui : se il problema che si sta trattando consente di interrompere la generazione dei dati, quando la coda è piena il produttore può fermarsi ed attendere che il consumatore svuoti la coda; se questo non è possibile (ad esempio perché produttore e consumatore sono due applicazioni indipendenti che nulla sanno l'uno dell'altro) allora in caso di coda piena i nuovi dati verranno scartati fino a che non si libererà dello spazio nella coda.

15 Data Acquisition Producer-Consumer Pattern Effettuare un opportuno dimensionamento della coda diventa un passo fondamentale per ridurre al minimo la probabilità che parte dei dati vada perduta. Una generalizzazione del modello prevede la presenza di più produttori che immettono dati su una coda e di più consumatori che elaborano i dati presenti nella coda. Si possono avere così casi in cui ogni messaggio viene elaborato da un solo consumatore, e dunque più consumatori collaborano per evitare che la coda saturi ogni messaggio viene elaborato da tutti i consumatori, creando in tal modo una biforcazione nella pipeline (o nel dataflow)

16 Data Acquisition Producer-Consumer Pattern Questo secondo caso pone però nuovi problemi, ad esempio come garantisco che il messaggio venga rimosso dalla coda solo dopo esser stato correttamente elaborato da tutti i consumatori? I vari tool che vedremo implementano strategie diverse per cercare di rispondere in maniera efficace a queste ed altre problematiche.

17 Data Acqusition Flume

18 Data Acquisition Data are business L'idea alla base del mondo BigData è che i dati sono una ricchezza tutti i dati sono una ricchezza dunque essere in grado di raccogliere, collezionare ed elaborare dati dei tipi più svariati e in qualunque quantità significa avere la possibilità di creare molti nuovi business.

19 Data Acquisition Gestione Manuale Dovendo gestire manualmente l'acquisizione e l'accentramento dei dati, si dovrebbero realizzare degli script o dei servizi dedicati da installare nelle diverse macchine da monitorare. Questo approccio presenta diversi problemi: manutenzione onerosa, in quanto gli script o i servizi andrebbero scritti e modificati di volta in volta ed adattati continuamente ad ogni modifica sulla macchina; difficoltà nella gestione monitoraggio dell'esecuzione compressione dei dati uniformità nel formato dei dati prodotti probabilità di avere delay elevati onere e complessità della scalabilità completamente a nostro carico Flume nasce per risolvere questi problemi.

20 Flume Architettura L'architettura di Flume si basa sul concetto di Agent che, come si può vedere dall'illustrazione, è un'implementazione del modello produttore consumatore. WEB Client Riceve EVENTI FLUME AGENT SOURCE SINK Inoltra EVENTI CHANNEL Nelle prossime slide illustreremo i concetti fondamentali dell'architettura. Destinazione, es HDFS

21 Flume Eventi In Flume Event un evento è un dato prodotto da una sorgente esterna ed inoltrato alla destinazione finale WEB Client materialmente è un bytearray composto da un header e un payload Riceve EVENTI FLUME AGENT SOURCE SINK Inoltra EVENTI CHANNEL Destinazione, es HDFS Il dato esterno viene inserito nel payload e rimane opaco per Flume. Tutte le informazioni necessaria alla gestione ed elaborazione degli eventi vengono accumulate nell'header sotto forma di coppie chiave-valore. EVENT HEADER PAYLOAD Map< String, String> byte[]

22 Flume Client Client Un Client è FLUME AGENT Riceve EVENTI un'entità che raccoglie i dati, li incapsula in eventi SOURCE SINK Inoltra EVENTI CHANNEL e li invia ad uno o più Agenti Destinazione, es HDFS Può essere un processo indipendente che colleziona dati prodotti da applicazioni esterne secondo formati standard (es. Apache, Log4j,...) oppure, qualora non sia possibile usare uno dei client disponibili, può essere sviluppato ad hoc o integrato in una propria applicazione. Flume espone un interfaccia RPC basata su Apache Thrift per cui il client può esser scritto nella maggior parte dei linguaggi di programmazione.

23 Flume Agent L'Agent è il cuore di Flume, e si occupa di WEB Client ricevere gli eventi generati da un client esterno, Riceve EVENTI FLUME AGENT SOURCE SINK Inoltra EVENTI CHANNEL accumularli in una coda interna, e inviarli ad una o più destinazioni finali Destinazione, es HDFS I componenti fondamentali di un Agent sono tre il source (produttore) il channel (coda) il sink (consumatore) Tuttavia il concetto di Agent è un modello teorico, per cui un singolo processo che opera come Agent può gestire più source, più channel e più sink contemporaneamente.

24 Flume Agent Poll Riceve eventi Source Push Channel Sink Inoltra eventi Read Agent Per ragioni di ottimizzazione il Source ha una coda interna in cui raccoglie gli eventi prima di inviarli al canale in gruppi di dimensioni prefissate (configurabili). Il Canale è un componente passivo che si limita a conservare quanto ricevuto dal Source inviare quanto richiesto dal Sink Il Sink invia delle richieste periodiche al Channel e quando ci sono sufficienti dati disponibili richiede un blocco di eventi di dimensioni prefissate (configurabili) che poi inoltra ad una destinazione remota.

25 Flume Agent : Source Il Source è il componente interno all'agent che si occupa di ricevere gli eventi esterni Poll Riceve eventi Source Push Channel e memorizzarli in uno o più canali. Sink Inoltra eventi Read Agent Un Source deve essere collegato ad almeno un canale. Esistono tre tipologie principali di Source standard : ricevono gli eventi dall'esterno via HTTP o RPC (Avro, Thrift) exec: eseguono un comando via shell che genera i dati sullo STDOUT monitor: monitora una cartella locale e ogni qual volta viene aggiunto un file genera un evento che contiene il file stesso

26 Flume Agent : Source - Internals All'interno di un Source troviamo tre componenti: Poll Riceve eventi Source Push Channel Sink Inoltra eventi Read Agent un Channel Processor che coordina tutte le attività interne di elaborazione degli SOURCE Channel Processor Interceptor 1 eventi; un insieme di Interceptor che operano come dei filtri ed aggiungono dei tag Interceptor 3 Interceptor 2 Interceptor N Channel Selector all'header dell'evento per caratterizzane il contenuto; esistono degli interceptor predefiniti (che aggiungono ad esempio un timestamp, l'hostname, e simili) ma è anche possibile di definirne dei propri che aggiungono tag in base al contenuto del payload

27 Flume Agent : Source - Internals un Channel Selector che in base ai dati contenuti nell'header identifica i canali su Poll Riceve eventi Source Push Channel Sink Read cui andrà inoltrato l'evento. Agent SOURCE Channel Processor Interceptor 1 Interceptor 3 Interceptor 2 Interceptor N Channel Selector Inoltra eventi

28 Flume Agent : Source Event Lifecycle

29 Flume Agent : Channel Il Channel è un componente passivo che opera come buffer tra il Source e il Sink. Poll Riceve eventi Source Push Channel Sink Inoltra eventi Read Agent un Channel può ricevere dati da più Source e può fornire dati a più Sink esistono tre principali tipologie di Channel che si differenziano per il modello di persistenza: MemoryChannel (volatile): conserva i dati in RAM col rischio che vadano perduti in cado di riavvio del processo; FileChannel (durable): conserva i dati su file JDBCChannel (durable): conserva i dati su una tabella di un DB I Channel sono transazionali ovvero garantiscono che tutto ciò che viene scritto dal Source venga poi letto dal Sink

30 Flume Agent : Channel - Transactions Il Channel non è fully transactional, ma solo le operazioni di scrittura e lettura (singolarmente) Poll Riceve eventi Source Push Channel sono racchiuse in una transazione. Sink Inoltra eventi Read Agent A: garanzia di scrittura dei dati del Source una singola transazione può scrivere più di un evento se la transazione fallisce tutti gli eventi della transazione vengono riscritti sul channel La ripetizione della transazione può portare alla creazione di duplicati sul canale. Flume non gestisce la rimozione di eventi duplicati, sarà dunque cura dell'utilizzatore finale rimuoverli. E' quindi prassi comune inserire nell'header, attraverso un custom interceptor, un ID che identifichi univocamente ogni evento.

31 Flume Agent : Channel - Transactions Il Channel non è fully transactional, ma solo le operazioni di scrittura e lettura (singolarmente) Poll Riceve eventi Source Push Channel sono racchiuse in una transazione. Sink Inoltra eventi Read Agent B: garanzia di lettura dei dati da parte del Sink la transazione garantisce che ogni evento venga letto dal Sink e scritto sulla destinazione esterna La transazione si considera completata con successo solo dopo aver ricevuto la conferma che la scrittura sulla destinazione esterna sia avvenuta con successo. In questo modo si ha la garanzia che nessun dato venga perso nella pipeline gestita da Flume stesso.

32 Flume Agent : Sink Il Sink recupera gli eventi conservati sul Channel e li inoltra verso una destinazione esterna Poll Riceve eventi Source Push Channel Sink Inoltra eventi Read Agent esistono Sink predefiniti per una gran varietà di destinazioni differenti HDFS, Hbase, Solr, ElasticSearch File, Logger Flume Agent (Avro, Thrift) è possibile creare dei Sink Personalizzati implementando l'interfaccia CustomSink Il SinkProcessor decide, in base al contenuto dell'header, se un particolare evento debba esser inoltrato o meno su una certa destinazione esterna.

33 Flume Agent Pipelines E' possibile costruire delle pipelines di Agent facendo si che un Sink invii gli eventi ad un altro Agent SOURCE SOURCE SINK SINK Channel Channel Qualora si debbano trasferire grandi quantità di eventi attraverso network differenti (ad esempio attraverso una WAN con banda limitata e latenza elevata) è possibile creare delle pipeline per avere diversi livelli di aggregazione ed avere maggiore flessibilità nella configurazione del sistema.

34 Flume Agent Pipelines E' importante dimensionare correttamente la capacità del Channel SOURCE SOURCE SINK SINK Channel Channel Un eccessivo ritardo nella scrittura sulla destinazione finale porterebbe alla saturazione del canale più a valle nella Pipeline. A cascata questo si ripercuoterebbe nel tier precedente della pipeline ma consentirebbe di ridurre il rischio di perdita di dati. Non appena la scrittura sulla destinazione finale riprende entrambe le code iniziano nuovamente a svuotarsi.

35 Flume Complex Flows

36 Flume Complex Flows

37 Flume Complex Flows

38 Flume Complex Flows Realizzare un flusso di dati convergente verso la destinazione. Tier-1 Tier-2 Tier-3 Il traffico dei dati viene aggregato da Tier-2 e Tier-3 prima di inserirlo nella detinazione; Più un Tier è vicino alla destinazione e maggiore è la dimensione dei dati in ogni operazione batch.

39 Messaging System Kafka

40 Kafka A high throughput distributed messaging system Kafka, come Flume, si basa sul modello produttore-consumatore e per tale ragione ha un'architettura generale simile. Tuttavia il suo posizionamento in un BigData System è leggermente diverso ed infatti gli stessi sviluppatori non lo definiscono come un sistema per l'acquisizione dei dati ma un sistema distribuito per la gestione dei messaggi ad altissime prestazioni. Infatti l'obiettivo principale di Flume è quello di raccogliere dati da macchine remote, aggregarli e memorizzarli in maniera persistente (e indipendente..quasi batch) sul cluster per future elaborazioni. Kafka si propone invece come sistema per lo scambio in real-time di messaggi (e dati sotto forma di messaggi) tra applicazioni distribuite sul cluster.

41 Kafka Requirements L'obiettivo degli sviluppatori di Kafka era quello di costruire una piattaforma unificata per la gestione di tutti i flussi di dati e di messaggi di una grande azienda. Questo richiedeva il soddisfacimento di alcuni requisiti fondamentali: avere la capacità di gestire velocemente ed in maniera affidabile un elevatissimo numero di eventi organizzati in stream differenti; avere la capacità di gestire archivi di grandi dimensioni in modo da poter consentire anche l'import periodico di grandi archivi provenienti da sistemi offline o batch; garantire la possibilità di elaborazione in real-time degli eventi e la produzione di nuovi stream di eventi; avere un'intrinseco supporto alla fault-tolerance in modo da garantire il funzionamento anche in caso di guasto su qualunque macchina del cluster

42 Kafka Architettura Come risultato di quei requisiti un cluster Kafka è un sistema distribuito per la gestione ottimizzata di un elevato numero di catene produttore consumatore: ogni catena rappresenta uno stream di messaggi e viene detto Topic (o feed); ogni Topic è gestito da un certo numero di macchine del cluster (broker) e può avere associati un numero arbitrario di Producer e Consumer.

43 Kafka Topic L'elemento fondamentale in Kafka è il Topic e rappresenta un flusso (stream) di messaggi; può anche esser visto come un argomento che caratterizza un insieme di messaggi. Tutti i messaggi pubblicati su un Topic sono salvati su un file detto log-file. Per aumentare le performance del sistema ogni Topic può essere suddiviso in diverse partizioni ed ogni partizione costituisce una sequenza ordinata ed immutabile di messaggi. Un messaggio può essere inserito in una sola partizione e riceve un ID numerico (offset) che lo identifica univocamente nella partizione.

44 Kafka Topic Le partizioni sono il meccanismo con cui Kafka costruisce la scalabilità: ad ogni partizione viene associato un file tutti i messaggi di una partizione devono essere contenuti su una singola macchina dati di partizioni diverse possono stare su macchine diverse In questo modo un singolo log-file può essere suddiviso in più file fisici e distribuito nel cluster e, teoricamente, può raggiungere dimensioni arbitrarie. Inoltre ad ogni Topic è associato un replication-factor, che impone che i dati di una partizione siano replicati su più macchine distinte in modo da garantire che il sistema continui a funzionare anche in caso di guasto su una macchina

45 Kafka Topic Ad ogni partizione è associato un nodo, detto leader, che si occupa di gestire tutte le interazioni (letture e scritture) con la partizione stessa. In caso di replica-factor>1 alla partizione sono associati anche N-1 nodi follower che si occupano di replicare sugli altri nodi quanto avviene sul nodo leader. I nodi follower si comportano come qualunque altro consumer associato alla partizione e hanno il compito di mantenere una replica aggiornata del log della partizione in modo da poter sostituire il leader in caso di guasto. Tuttavia non è possibile interagire direttamente con essi. Ogni leader conserva un elenco aggiornato dei follower che sono in sync, ovvero che sono attivi e riescono a restare al passo con quanto accade sul nodo leader. Solo un follower che sia in sync può prendere il posto del leader.

46 Kafka Topic e performance In Kafka ogni messaggio viene scritto su file non appena ricevuto. Questa scelta sorprendente è in realtà la chiave delle prestazioni di Kafka. Infatti non avendo una cache in RAM dei messaggi si occupa meno RAM, lasciandone di più a disposizione degli altri processi e del Sistema Operativo; si riduce il peso della Java Virtual Machine e del Garbage Collector; si delega al file system del Sistema Operativo sottostante l'onere di gestire il caching verso il disco, che essendo ottimizzato per questo scopo riesce a farlo con tempi prossimi a quelli di un accesso sequenziale e quindi molto elevati.

47 Kafka Produttore Un produttore è un qualunque processo che pubblica dei messaggi. E' compito del produttore indicare il Topic su cui pubblicare il messaggio; effettuare un Load Balancing per distribuire i messaggi in maniera uniforme sulle varie partizioni; il load balancing può esser fatto in maniera casuale o attraverso un hash su un campo chiave per ottenere una sorta di partizionamento semantico I messaggi vengono inviati in maniera asincrona.

48 Kafka Performance Nello sviluppo di Kafka è stata posta grande cura nell'ottimizzazione del trasferimento dei messaggi dal produttore al Topic e dal Topic al consumatore. Gli aspetti che si è cercato di gestire con maggior cura sono un accesso efficiente al disco (risolto con le scelte di persistenza legate al Topic) evitare un numero eccessivo di piccole operazioni di I/O evitare un numero eccessivo di operazioni di byte-copying

49 Kafka Small I/O minimization In un sistema di messaging è probabile che nelle operazioni tra client e server e in quelle di persistenza del server stesso si generi un elevato numero di messaggi di piccole dimensioni (scambio di messaggi ). Il rischio è quello di saturare la rete e limitare le performance generali del sistema. Per evitare questo è stato sviluppato un protocollo di comunicazione interna basato sui concetti di Invio Asincrono e Message Set. In questo modo chiunque debba inviare dei messaggi tende ad accumulare dei dati in memoria per poter inviare più messaggi con una sola richiesta (batch send).

50 Kafka Small I/O minimization Questo processo è configurabile ponendo un limite massimo alla quantità di dati da accumulare (es. 64k) ponendo un limite massimo di tempo di attesa (es. 10ms) ponendoli entrambe (in tal caso la richiesta verrà inviata al raggiungimento del primo limite) In questo modo è possibile trovare il miglior compromesso tra un po di latenza addizionale e un miglior througput.

51 Kafka Byte-Copying reduction Un altro problema tipico dei Message System è l'eccessivo numero di copie effettuate su ciascun messaggio nel passaggio da un componente all'altro del sistema. Cosa che ha un impatto ancor più rilevante su sistemi scritti in Java per via del Garbage Collector. Per ridurre questo problema in Kafka è stato definito un formato binario standard, condiviso da tutti i componenti, che ad un messaggio di attraversare l'intero sistema passando da un componente all'altro senza subire copie. La stessa cura si è posta nel trasferimento del pacchetto verso la rete, in cui è stata utilizzata una tecnica, denominata zero-copy, che garantisce che l'unica copia del pacchetto sia quella dalla RAM verso il buffer fisico della scheda di rete prima dell'invio fisico del segnale sulla rete stessa. Questo ha consentito un incremento delle performance di oltre il 60%.

52 Kafka Consumers Un consumatore che vuole leggere dei messaggi da un Topic invia un messaggio di fetch al leader di una partizione specificando la posizione di lettura (offset). In risposta riceve un gruppo ordinato di messaggi a partire da quello in posizione offset. Dunque una strategia di tipo pull. Vediamo di capire perché si è scelta questa strategia.

53 Kafka Consumers Le possibili strategie per un sistema di messaging sono due pull : i consumer richiedono i dati al broker quando è in grado di elaborarli push : il broker invia i messaggi ai consumer non appena questi sono disponibili Entrambe hanno vantaggi e svantaggi, legati principalmente alla diversa velocità con cui produttore e consumatore sono in grado di produrre/elaborare dati: pull : se la velocità di elaborazione è molto maggiore di quella di produzione si rischia di avere tanti consumer che sommergono il broker di richieste di nuovi messaggi, col rischio di saturare il broker; push: si ha il problema contrario, in caso di picchi di produzione il broker può sommergere il consumer di nuovi messaggi, saturando le sue capacità e generando una specie di Denial of Service;

54 Kafka Consumers Entrambe le strategie richiedono dunque accorgimenti particolari per poter essere implementate efficacemente. In Kafka si è optato per la strategia pull perché: consente di gestire internamente ed in maniera ottimizzata (a livello di broker) il caching e la persistenza dei messaggi, liberando il consumer da quest'onere; consente di avere un utilizzo ottimizzato della banda ed un throughput ottimale; Infatti gli accorgimenti sul protocollo per il contenimento del numero di richieste, ovvero l'uso di micro-batch le cui occorrenze sono determinate dal raggiungimento di una certa soglia di dati o dal passaggio di un certo intervallo di tempo, consentono di evitare che dei client, eventualmente scarichi, inondino i broker di messaggi di fetch.

55 Kafka Consumers - Performance Sorprendentemente uno dei fattori fondamentali per le performance di un messaging system è il modo con cui si tiene traccia della posizione di lettura di un consumatore. Tipicamente viene utilizzato un sistema di metadati che viene aggiornato ad ogni lettura in risposta ad un ACK fornito dal consumatore. Questo funziona bene con sistemi di piccole dimensioni, ma su un sistema distribuito di grosse dimensioni rischia di diventare un collo di bottiglia che limita le performance del sistema nel suo complesso. Cosa succede infatti se un ACK viene perso?

56 Kafka Consumers - Performance Il fallimento nella ricezione di un ACK comporta il rischio di elaborare più volte lo stesso messaggio: se fosse un messaggio in cui si comunica di ridurre l'importo disponibile su un conto bancario, cosa accadrebbe elaborandolo due o più volte? Per evitare situazioni simili diventerebbe necessario associare uno stato ad ogni messaggio per sapere da quali consumer è stato realmente elaborato e da quali no; generare un elevato numero di messaggi di sincronizzazione tra broker e consumer per accertarsi della posizione di lettura...con buona pace delle performance...

57 Kafka Consumers - Performance In Kafka si è quindi adottata cercato di rendere l'operazione di lettura da parte dei consumer la più leggera possibile. Come abbiamo visto un Topic è suddiviso in partizioni, ognuna delle quali contiene un insieme ordinato di messaggi. Il segreto è nell'imporre che ogni consumer possa leggere da una sola partizione. In questo modo l'unico stato necessario è la posizione di lettura di ciascun consumer, che si riduce ad un intero (l'offset) che, come abbiamo visto, deve essere gestito dal consumer stesso. Un vantaggio collaterale di questo approccio è che il consumer può decidere di tornare indietro e rielaborare un set di messaggi che ha già elaborato.

58 Kafka Semantica di Invio dei Messaggi Idealmente si vorrebbe che un messaging system garantisse che ogni messaggio sia consegnato una ed una sola volta a ciascun consumer. In un sistema distribuito questa è difficile garantire questo risultato in qualunque condizione operativa perché dipende strettamente dalle scelte fatte in termini di durabilità e modalità di consumo dei messaggi. In pratica le possibili modalità sono tre Exactly once: ogni messaggio viene consegnato una ed una sola volta At most once: si garantisce di non consegnare due volte lo stesso messaggio, anche a rischio di perderne qualcuno At least once: si garantisce di non perdere messaggi, anche a costo di consegnare due volte lo stesso messaggio

59 Kafka Semantica lato Producer La semantica di base è piuttosto semplice: un messaggio pubblicato da un producer si considera committed (salvato sul log) solo quando tutti i follower in sync lo hanno salvato un messaggio pubblicato non viene perso fintanto che almeno una replica della partizione è attiva Tuttavia non esiste un ACK per il producer, quindi in caso di network-error il producer non ha modo di sapere se il messaggio sia stato realmente pubblicato o meno. Per tale ragione è buona prassi rendere l'operazione di pubblicazione idempotente, ad esempio associando una ID univoca ad ogni messaggio in modo che una ripubblicazione si traduca in una sovrascrittura.

60 Kafka Semantica lato Producer Poiché non tutti gli use-cases hanno le stesse necessità è in fase di sviluppo un sistema che consenta al producer di specificare il livello di durabilità desiderato: attendere che il messaggio sia effettivamente committed (tutti i follower hanno completato la scrittura) attendere solo che il leader abbia completato la scrittura inviare il messaggio in maniera completamente asincrona senza preoccuparsi di quanto accade lato server.

61 Kafka Semantica lato Consumer Abbiamo visto che tutte le repliche hanno lo stesso log con gli stessi offset, e che ogni Consumer ha il controllo sulla propria posizione di lettura. In una condizione ideale, un Consumer si avvia ed inizia a leggere dal primo messaggio aggiorna l'offset procede nella lettura dei messaggi successivi Cosa succede in caso di crash del Consumer? Idealmente vorremmo che venisse automaticamente instanziato un nuovo processo e che questo riprendesse esattamente da dove l'altro si era interrotto. Come si può garantire che questo avvenga?

62 Kafka Semantica lato Consumer Sostanzialmente ci sono due strategie applicabili lato Consumer leggo un messaggio, salvo la posizione, lo elaboro in caso di crash potrei perdere dei messaggi (at most once) leggo un messaggio, lo elaboro, salvo la posizione in caso di crash potrei elaborare due volte un messaggio (at least once) Per ottenere la strategia ideale exactly once si può rendere l'elaborazione idempotente (per cui rielaborando il messaggio sostanzialmente riscrivo il risultato) oppure realizzare un sistema analogo al two-phase commit per cui segnalo di aver letto un messaggio ma non aver ancora completato la sua elaborazione.

63 Kafka Producer Performance Comparison

64 Kafka Consumer Performance Comparison

65 Hadoop Ecosystem Panoramica Tecnologie

66 Hadoop Ecosystem Ecosystem?

67 Hadoop Ecosystem Principali Categorie Cluster Management Data Collector Data Serialization KV Graph Document ColumnStore Distributed FS Frameworks Libraries Query engines

68 Hadoop Ecosystem Ecosistema o giungla Per quelle categorie di problemi in cui le tecnologie hanno raggiunto una certa maturità e stabilità si può parlare di ecosistema perché: - le tecnologie sono poche - ognuna ha una chiara funzionalità - esiste un equilibrio abbastanza stabile tra le varie tecnologie In altre categorie di problemi invece - la soluzione non è chiara - ci sono diverse tecnologie che cercano di risolvere il problema con approcci spesso molto diversi - le funzionalità ed i comportamenti sono soggetti a repentini mutamenti - molte soluzioni sono incomplete e coprono solo una porzione degli use-cases

69 Hadoop Ecosystem Come orientarsi I problemi BigData sono tipicamente di tipo Data Driven, perciò le tecnologie vengono scelte in base alle tipologie di dati da trattare ed i problemi da risolvere. Tuttavia aver selezionato le tecnologie è solo una parte della soluzione. Come organizzo le tecnologie pere farle interagire efficacemente ed avere un sistema efficiente? Per provare a rispondere a questa domanda recentemente è stato proposto un modello architetturale, denominato l-architecture, che può essere usato come modello per costruire la propria soluzione.

70 Hadoop Ecosystem Architettura di riferimento

71 Hadoop Ecosystem l Architecture E' stata proposta da Nathan Marz ( Twitter ) verso la fine del 2013, come modello standard per la creazione di sistemi per la gestione di BigData. Per capire il modello architetturale proposto nella Lambda Architecture è importante delineare quali sono le caratteristiche che vorremmo trovare in un BigData System. Ma prima ancora..cosa è un Data System e quindi un BigData System? Un Data System è un sistema che è in grado di memorizzare dei dati, combinarli assieme in svariati modi e fornire delle risposte alle nostre domande.

72 Hadoop Ecosystem l Architecture In prima approssimazione possiamo suddividere i dati in due tipi dati grezzi (raw data): che sono quelli che noi riceviamo dai sistemi esterni lista transazioni bancarie, elenco amici dati derivati : che sono ottenuti attraverso elaborazioni sui raw-data saldo disponibile sul conto, numero di amici Per moderare le ambiguità può esser utile far riferimento ai primi con il termine dati ed ai secondi con il termine informazioni. Possiamo quindi definire un Data System come un sistema in grado di memorizzare dati storici, analizzarli e fornire risposte basate su di essi, ovvero Data System: query = function ( All Data)

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 24/09/2014 Indice 1. Aspetti di Data Management CouchBase 2. Aspetti Architetturali Infrastruttura

Dettagli

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque?

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque? NOSQL Data Model HBase si ispira a BigTable di Google e perciò rientra nella categoria dei column store; tuttavia da un punto di vista logico i dati sono ancora organizzati in forma di tabelle, in cui

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli

Indice generale. Introduzione...xiii. Gli autori...xvii. I revisori...xix

Indice generale. Introduzione...xiii. Gli autori...xvii. I revisori...xix Indice generale Introduzione...xiii Struttura del libro... xiii Cosa serve per questo libro...xiv Lo scopo del libro...xiv Convenzioni...xv Codice degli esempi...xv Gli autori...xvii I revisori...xix Capitolo

Dettagli

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A.

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Linguaggi e Tecnologie Web A. A. 2011-2012 NoSQL http://nosql nosql-database.org/ Eufemia TINELLI Cosa è NoSQL? 1998 il termine NoSQL è

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Kickoff Progetto DaSSIA 29 Settembre 2014

Kickoff Progetto DaSSIA 29 Settembre 2014 www.crs4.it Kickoff Progetto DaSSIA 29 Settembre 2014 Ordine del giorno Breve Presentazione del CRS4 CRS4 & Big Data Il Progetto DaSSIA Sviluppo di un caso test paradigmatico L'Attività di Formazione Discussione

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 20/10/2014 1 Indice 1. HBase e Hrider Caratteristiche chiave Modello dati Architettura Installazione

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

LOGSTASH Introduzione

LOGSTASH Introduzione LOGSTASH LOGSTASH Introduzione Logstash è un tool per la gestione di eventi e log: è possibile utilizzarlo per l'acquisizione di log (o più genericamente di file), il loro parsing e la conservazione per

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

File system. Realizzazione del file system. Struttura del file system. Struttura del file system. Realizzazione del file system

File system. Realizzazione del file system. Struttura del file system. Struttura del file system. Realizzazione del file system Realizzazione del file system Struttura del file system Metodi di allocazione: Contigua Concatenata Indicizzata Gestione dello spazio libero Realizzazione delle directory Efficienza e prestazioni Ripristino

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

Realizzazione del file system

Realizzazione del file system Realizzazione del file system Struttura del file system Metodi di allocazione: Contigua Concatenata Indicizzata Gestione dello spazio libero Realizzazione delle directory Efficienza e prestazioni Ripristino

Dettagli

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

Dettagli

19 aprile 2013. Activ1st Descrizione prodotto

19 aprile 2013. Activ1st Descrizione prodotto 19 aprile 2013 Activ1st Descrizione prodotto Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

Big data ed eventi: quasi un tutorial. Prof. Riccardo Melen melen@disco.unimib.it

Big data ed eventi: quasi un tutorial. Prof. Riccardo Melen melen@disco.unimib.it Big data ed eventi: quasi un tutorial Prof. Riccardo Melen melen@disco.unimib.it Big Data Monitoraggio di reti e infrastrutture IT performance: data center, SOA/ESB, infrastrutture virtuali, configurazione

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

Diego GUENZI Rodolfo BORASO

Diego GUENZI Rodolfo BORASO Diego GUENZI Rodolfo BORASO NOSQL Movimento che promuove una classe non ben definita di strumenti di archiviazione di dati Un nuovo modo di vedere la persistenza Si differenziano dai RDBMS: Non utilizzano

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1 IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Sperimentazione del file system distribuito HDFS in ambiente grid

Sperimentazione del file system distribuito HDFS in ambiente grid Sperimentazione del file system distribuito HDFS in ambiente grid Giovanni Marzulli INFN Bari Tutor: dott. Domenico Diacono 4 Borsisti Day 13/09/2013 Outline Cosa è HDFS Attività svolta nel 2012 Test e

Dettagli

LabVIEW offre un ambiente di programmazione grafica

LabVIEW offre un ambiente di programmazione grafica 03 COME OTTIMIZZARE IN LABVIEW APPLICAZIONI DI TEST AUTOMATIZZATI PER PROCESSORI MULTICORE David Hall Vediamo come delle applicazioni scritte in LabVIEW possono essere ottimizzate sfruttando tecniche di

Dettagli

Supporto per servizi di File Hosting

Supporto per servizi di File Hosting Supporto per servizi di File Hosting Progetto per il corso di Reti di Calcolatori LS a.a 2005-2006 Valerio Guagliumi 0000236769 Abstract Questa relazione descrive il progetto realizzato di un sistema di

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

ASPETTI PRINCIPALI DELLA GESTIONE AUTOMATIZZATA DI UN ARCHIVIO

ASPETTI PRINCIPALI DELLA GESTIONE AUTOMATIZZATA DI UN ARCHIVIO ARCHIVIO è un insieme di informazioni che hanno tra di loro un nesso logico (sono inerenti ad uno stesso argomento) e sono organizzate in modo tale da renderne facile la consultazione Le informazioni di

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l.

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l. 2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011 Andrea Carnevali R&D Director GESINF S.r.l. Il progetto 2G è il nome della piattaforma che consentirà l evoluzione tecnologica

Dettagli

Il sistema di elaborazione

Il sistema di elaborazione Il sistema di elaborazione Stefano Brocchi stefano.brocchi@unifi.it Stefano Brocchi Il sistema di elaborazione 1 / 37 Informatica Il termine informatica deriva dalle parole informazione e automatica Stefano

Dettagli

Reti di Calcolatori IL LIVELLO RETE

Reti di Calcolatori IL LIVELLO RETE Reti di Calcolatori IL LIVELLO RETE D. Talia RETI DI CALCOLATORI - UNICAL 3-1 Il Livello RETE Servizi del livello Rete Organizzazione interna Livello Rete basato su Circuito Virtuale Livello Rete basato

Dettagli

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario L hardware di I/O Struttura Interazione tra computer e controllori

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28 Corso di Elettronica dei Sistemi Programmabili Sistemi Operativi Real Time Introduzione Aprile 2014 Stefano Salvatori 1/28 Sommario Definizioni livelli di astrazione processi di tipo batch e processi interattivi

Dettagli

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS 1 Tecnologia delle BD: perché studiarla? File e indici I DBMS offrono i loro servizi in modo "trasparente": per questo abbiamo potuto finora ignorare molti aspetti realizzativi abbiamo considerato il DBMS

Dettagli

CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL

CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL CONFRONTO TRA DBMS RELAZIONALI, A COLONNE E NOSQL Università degli Studi di Modena e Reggio Emilia Dipartimento di Ingegneria Enzo Ferrari di Modena Corso di Laurea in Ingegneria Informatica (L.270/04)

Dettagli

Elaborazione dati parallela con map/reduce. Roberto Congiu rcongiu@yahoo.com

Elaborazione dati parallela con map/reduce. Roberto Congiu rcongiu@yahoo.com Elaborazione dati parallela con map/reduce Roberto Congiu rcongiu@yahoo.com Indice delle slide Introduzione a Map/Reduce Descrizione del modello Implementazione Ottimizzazioni Introduzione Map/Reduce e

Dettagli

Openmosix e Beowulf: introduzione e confronto

Openmosix e Beowulf: introduzione e confronto Openmosix e Beowulf: introduzione e confronto Giovanni Perbellini Cluster Introduzione Cluster ESD Openmosix Comandi principali Beowulf (PVM) Comandi principali Libreria PVM API Agenda 1 Introduzione -

Dettagli

MapReduce. Progettazione del Software a.a. 2012/13. Università degli Studi di Milano Dept. of Computer Science. Matteo Camilli

MapReduce. Progettazione del Software a.a. 2012/13. Università degli Studi di Milano Dept. of Computer Science. Matteo Camilli Università degli Studi di Milano Dept. of Computer Science MapReduce Matteo Camilli matteo.camilli@unimi.it http://camilli.di.unimi.it Progettazione del Software a.a. 2012/13 1 Motivazioni Vogliamo processare

Dettagli

Architettura di un computer

Architettura di un computer Architettura di un computer Modulo di Informatica Dott.sa Sara Zuppiroli A.A. 2012-2013 Modulo di Informatica () Architettura A.A. 2012-2013 1 / 36 La tecnologia Cerchiamo di capire alcuni concetti su

Dettagli

Sistemi RAID. Sistemi RAID. Sistemi RAID

Sistemi RAID. Sistemi RAID. Sistemi RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

Dettagli

Sistemi RAID. Sistemi RAID

Sistemi RAID. Sistemi RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

Basi di Dati prof. A. Longheu. 5 Progettazione fisica

Basi di Dati prof. A. Longheu. 5 Progettazione fisica Basi di Dati prof. A. Longheu 5 Progettazione fisica Progettazione Fisica Per effettuare la progettazione fisica, ossia l implementazione reale del modello logico creato nella fase della progettazione

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Alla scoperta dei Graph Database

Alla scoperta dei Graph Database Alla scoperta dei Graph Database Matteo Pani 24 ottobre 2015 One size doesn t fit all Modellare le relazioni I Graph Database Il Labeled Property Graph Model I Graph-DBMS Neo4j Neo4j Internals Cypher Interagire

Dettagli

Sistemi RAID tutti i dati che contiene RAID

Sistemi RAID tutti i dati che contiene RAID Sistemi RAID 1 Sistemi RAID Dei tre elementi fondamentali di un qualsiasi sistema computerizzato: processore, memoria primaria, memoria secondaria, quest ultimo è di gran lunga il più lento. Inoltre, il

Dettagli

Linee di evoluzione dei Database

Linee di evoluzione dei Database Linee di evoluzione dei Database DB NoSQL Linked Open Data Semantic Web Esigenze e caratteristiche Presenza di grandi volumi di dati..crescenti Struttura non regolare dei dati da gestire Elementi relativamente

Dettagli

Programmazione per Bioinformatica Il Calcolatore e la Programmazione. Dr Damiano Macedonio Università di Verona

Programmazione per Bioinformatica Il Calcolatore e la Programmazione. Dr Damiano Macedonio Università di Verona Programmazione per Bioinformatica Il Calcolatore e la Programmazione Dr Damiano Macedonio Università di Verona Architettura del calcolatore La prima decomposizione di un calcolatore è relativa a due macrocomponenti:

Dettagli

GridGain. Aumentare scalabilità e performance con l'aiuto del Open Source e della Grid Computing. Alfonso Focareta, Christian Mongillo.

GridGain. Aumentare scalabilità e performance con l'aiuto del Open Source e della Grid Computing. Alfonso Focareta, Christian Mongillo. GridGain Aumentare scalabilità e performance con l'aiuto del Open Source e della Grid Computing Alfonso Focareta, Christian Mongillo Pro-netics Introduzione Enterprise Cms? ECMS: un caso di studio Problematiche

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Principi fondamentali

Principi fondamentali Principi fondamentali Elementi di base Definizione di rete di calcolatori Tipologia di connessioni Architettura di rete Prestazioni di una rete di calcolatori Conclusioni 1 1 Bit e Byte BIT = BInary digit

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

UX model e Architetture di SI web-based. B. Pernici D. Ardagna

UX model e Architetture di SI web-based. B. Pernici D. Ardagna UX model e Architetture di SI web-based B. Pernici D. Ardagna Conallen, cap. 7,9 Bibliografia Modellazione concettuale: UX model Primo passo di analisi UX: user experience Schermate Modellare la navigazione,

Dettagli

Distributed Data Stream Processing

Distributed Data Stream Processing Distributed Data Stream Processing Sistemi Distribuiti e Cloud Computing A.A. 2014/15 Matteo Nardelli Matteo Nardelli Big Data Source: http://www.intel.it/content/www/it/it/communications/internet-minute-infographic.html

Dettagli

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley CASE STUDY N#1 Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley Enter srl - ISO 9001/27001 Quality System Certification - All rights reserved - www.entercloudsuite.it

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file 11 Realizzazione del File System 1 Metodi di allocazione Allocazione contigua Allocazione concatenata e varianti Allocazione indicizzata e varianti Gestione dello spazio libero 11.1.1 Struttura a livelli

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Cosa è un Sistema Operativo (S.O.)

Cosa è un Sistema Operativo (S.O.) Cosa è un Sistema Operativo (S.O.) Modulo software costituito da un insieme di programmi per: permettere all utente l uso dell elaboratore senza la conoscenza approfondita dell hardware S.O. supporto all

Dettagli

PROGETTAZIONE FISICA

PROGETTAZIONE FISICA PROGETTAZIONE FISICA Memorizzazione su disco, organizzazione di file e tecniche hash 2 Introduzione La collezione di dati che costituisce una BDD deve essere fisicamente organizzata su qualche supporto

Dettagli

Big Data. Davide Giarolo

Big Data. Davide Giarolo Big Data Davide Giarolo Definizione da Wikipedia Big data è il termine usato per descrivere una raccolta di dati così estesa in termini di volume, velocità e varietà da richiedere tecnologie e metodi analitici

Dettagli

Componenti del Sistema di Elaborazione

Componenti del Sistema di Elaborazione Componenti del Sistema di Elaborazione Il Sistema di Elaborazione Monitor Tastiera Processore Memoria Centrale (Programmi + Dati) Memorie di massa Altre periferiche Rete Rete a.a. 2002-03 L. Borrelli 2

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Memorizzazione dei dati: Dischi e File

Memorizzazione dei dati: Dischi e File Memorizzazione dei dati: Dischi e File Query\update Query plan Execution Engine richieste di indici, record e file Index/file/record Manager comandi su pagine Query Compiler Buffer Manager Lettura/scrittura

Dettagli

MongoDB. Un database NoSQL Open-Source

MongoDB. Un database NoSQL Open-Source MongoDB Un database NoSQL Open-Source Database Relazionali I dati sono divisi in tabelle. Ogni tabella è composta da diverse colonne fisse. Le tabelle possono avere riferimenti tra loro. A.C.I.D. I database

Dettagli

Database MySQL: 10 trucchi per migliorarne le performance

Database MySQL: 10 trucchi per migliorarne le performance Database MySQL: 10 trucchi per migliorarne le performance Scopriamo i segreti che molti amministratori professionisti di database usano per migliorare le performance Contenuti a cura di HostingTalk #e-commerce

Dettagli

Windows Azure. introduzione. 16 Maggio 2013. Gianni Rosa Gallina giannishub@hotmail.com. Fabrizio Accatino fhtino@gmail.com

Windows Azure. introduzione. 16 Maggio 2013. Gianni Rosa Gallina giannishub@hotmail.com. Fabrizio Accatino fhtino@gmail.com 16 Maggio 2013 Windows Azure introduzione Gianni Rosa Gallina giannishub@hotmail.com Twitter: @giannirg Blog: http://giannishub.cloudapp.net/it/ Fabrizio Accatino fhtino@gmail.com Twitter: @fhtino Sito

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Lezione 11. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata.

Lezione 11. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata. Lezione 11 system Sistemi operativi 12 maggio 2015 System Programming Research Group Università degli Studi di Roma Tor Vergata SO 15 11.1 Di cosa parliamo in questa lezione? L interfaccia : system 1 Il

Dettagli

Interfaccia del file system

Interfaccia del file system Interfaccia del file system Concetto di file Modalità di accesso Struttura delle directory Montaggio di un file system Condivisione di file Protezione 9.1 File E un insieme di informazioni correlate e

Dettagli

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache... Appunti di Calcolatori Elettronici Concetti generali sulla memoria cache Introduzione... 1 Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

Funzioni del Sistema Operativo

Funzioni del Sistema Operativo Il Software I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono il cosiddetto Hardware (ferramenta). La struttura del calcolatore può essere schematizzata come una serie di

Dettagli

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Sistemi di gestione delle basi di dati 1 Cos è un DBMS? Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni (ad esempio, Madonna

Dettagli

Un architettura per lo streaming multimediale in ambiente distribuito

Un architettura per lo streaming multimediale in ambiente distribuito tesi di laurea Anno Accademico 2012/2013 relatore Ch.mo prof. Simon Pietro Romano correlatori Ing. Tobia Castaldi candidato Alessandro Arrichiello Matr. M63/43 Contesto: o Content Distribution Networks

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 15/10/2014 1 Indice 1. Processo di analisi/elaborazione dei 1. Hadoop Caratteristiche chiave Architettura

Dettagli