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)

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

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

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

PTDR Disaster Recovery for oracle database

PTDR Disaster Recovery for oracle database PTDR Disaster Recovery for oracle database INTRODUZIONE... 3 INTRODUZIONE... 3 I MECCANISMI BASE DI ORACLE DATA GUARD... 3 COSA SONO I REDO LOG?... 4 IMPATTO SULL'ARCHITETTURA COMPLESSIVA... 4 CONCLUSIONI...

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

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

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

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

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 (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

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

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

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

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

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

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

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

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

Introduzione ai Sistemi Operativi

Introduzione ai Sistemi Operativi Introduzione ai Sistemi Operativi Sistema Operativo Software! Applicazioni! Sistema Operativo! È il livello di SW con cui! interagisce l utente! e comprende! programmi quali :! Compilatori! Editori di

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

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

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

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

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

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi:

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: 1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: compile time, load time, execution time. Quale delle modalità precedenti necessita di un supporto hardware per poter essere

Dettagli

Sfrutta appieno le potenzialità del software SAP in modo semplice e rapido

Sfrutta appieno le potenzialità del software SAP in modo semplice e rapido Starter Package è una versione realizzata su misura per le Piccole Imprese, che garantisce una implementazione più rapida ad un prezzo ridotto. E ideale per le aziende che cercano ben più di un semplice

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

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

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

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

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

Architettura di un sistema di calcolo

Architettura di un sistema di calcolo Richiami sulla struttura dei sistemi di calcolo Gestione delle Interruzioni Gestione della comunicazione fra processore e dispositivi periferici Gerarchia di memoria Protezione. 2.1 Architettura di un

Dettagli

Componenti Web: client-side e server-side

Componenti Web: client-side e server-side Componenti Web: client-side e server-side side Attività di applicazioni web Applicazioni web: un insieme di componenti che interagiscono attraverso una rete (geografica) Sono applicazioni distribuite logicamente

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

INFORMATICA. Il Sistema Operativo. di Roberta Molinari

INFORMATICA. Il Sistema Operativo. di Roberta Molinari INFORMATICA Il Sistema Operativo di Roberta Molinari Il Sistema Operativo un po di definizioni Elaborazione: trattamento di di informazioni acquisite dall esterno per per restituire un un risultato Processore:

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

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

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo.

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo. Pro COMMERCIALE (La farmacia può decidere di accettare o meno l allineamento commerciale di un prodotto) ACCETTARE IL PRODOTTO SOSTI- TUTIVO (La farmacia può decidere di accettare o meno il prodotto sostitutivo)

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

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

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

Descrizione della piattaforma software MPS Monitor

Descrizione della piattaforma software MPS Monitor Descrizione della piattaforma software MPS Monitor MPS Monitor è il più completo sistema di monitoraggio remoto e di gestione integrata ed automatizzata dei dati e degli allarmi relativi ai dispositivi

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

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

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 software. la parte contro cui si può solo imprecare. Il software

Il software. la parte contro cui si può solo imprecare. Il software Il software la parte contro cui si può solo imprecare Il software L hardware da solo non è sufficiente per il funzionamento dell elaboratore ma è necessario introdurre il software ovvero un insieme di

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

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8 Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

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

Basi di Dati Distribuite

Basi di Dati Distribuite Basi di Dati Distribuite P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone (McGraw-Hill Italia) Basi di dati: architetture linee di evoluzione - seconda edizione Capitolo 3 Appunti dalle lezioni SQL come DDL

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

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

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

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

IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione

IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione Indice Capitolo 1. Introduzione a IBM SPSS Modeler Social Network Analysis.... 1 Panoramica di IBM SPSS Modeler

Dettagli

Laboratorio di Informatica

Laboratorio di Informatica per chimica industriale e chimica applicata e ambientale LEZIONE 4 - parte II La memoria 1 La memoriaparametri di caratterizzazione Un dato dispositivo di memoria è caratterizzato da : velocità di accesso,

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

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa.

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa. La trasmissione dell informazione N.R2 La comunicazione tra due calcolatori si realizza tramite lo scambio di dati su un canale di comunicazione, esiste quindi un TRASMETTITORE che invia dei dati e un

Dettagli

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

Un sistema operativo è un insieme di programmi che consentono ad un utente di

Un sistema operativo è un insieme di programmi che consentono ad un utente di INTRODUZIONE AI SISTEMI OPERATIVI 1 Alcune definizioni 1 Sistema dedicato: 1 Sistema batch o a lotti: 2 Sistemi time sharing: 2 Sistema multiprogrammato: 3 Processo e programma 3 Risorse: 3 Spazio degli

Dettagli

Software di controllo AquaView. Monitoraggio più sicuro e controllo più semplice

Software di controllo AquaView. Monitoraggio più sicuro e controllo più semplice Software di controllo AquaView Monitoraggio più sicuro e controllo più semplice Il primo sistema di controllo dedicato, espressamente progettato per le stazioni di pompaggio Soluzioni innovative dall azienda

Dettagli

TEORIA DEI SISTEMI OPERATIVI

TEORIA DEI SISTEMI OPERATIVI TEORIA DEI SISTEMI OPERATIVI Classificazione dei sistemi operativi (Sistemi dedicati, Sistemi batch, Sistemi interattivi multiutente) CLASSIFICAZIONE DEI SISTEMI OPERATIVI Le tre principali configurazioni

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

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

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito LEZIONE 3 Il pannello di amministrazione di Drupal, configurazione del sito Figura 12 pannello di controllo di Drupal il back-end Come già descritto nella lezione precedente il pannello di amministrazione

Dettagli

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Corso di Sistemi di Elaborazione delle informazioni Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Una definizione di Rete Una moderna rete di calcolatori può essere definita come:

Dettagli

SETTE DOMANDE SU «Protocollo 2»

SETTE DOMANDE SU «Protocollo 2» SETTE DOMANDE SU «Protocollo 2» 1. Che cosa è «Protocollo 2»? 2. A chi serve «Protocollo 2»? 3. Quali sono le principali funzionalità di «Protocollo 2»? 4. Quanto può essere adattato «Protocollo 2» alle

Dettagli

STRUTTURE DEI SISTEMI DI CALCOLO

STRUTTURE DEI SISTEMI DI CALCOLO STRUTTURE DEI SISTEMI DI CALCOLO 2.1 Strutture dei sistemi di calcolo Funzionamento Struttura dell I/O Struttura della memoria Gerarchia delle memorie Protezione Hardware Architettura di un generico sistema

Dettagli

Altri metodi di indicizzazione

Altri metodi di indicizzazione Organizzazione a indici su più livelli Altri metodi di indicizzazione Al crescere della dimensione del file l organizzazione sequenziale a indice diventa inefficiente: in lettura a causa del crescere del

Dettagli

Protocolli di accesso multiplo

Protocolli di accesso multiplo Protocolli di accesso multiplo Quando l accesso ad una risorsa può avvenire da parte di più utenti indipendenti, si parla di risorsa condivisa ed è necessaria l implementazione di particolari protocolli

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

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

Veloce, economico e sicuro: rendete più agile il vostro lavoro, diminuite il TCO e migliorate la vostra sicurezza grazie alla soluzione di job

Veloce, economico e sicuro: rendete più agile il vostro lavoro, diminuite il TCO e migliorate la vostra sicurezza grazie alla soluzione di job Veloce, economico e sicuro: rendete più agile il vostro lavoro, diminuite il TCO e migliorate la vostra sicurezza grazie alla soluzione di job scheduling senza agente White paper preparato per BMC Software

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

M46 GDS documentazione Verticale R0

M46 GDS documentazione Verticale R0 1. Introduzione 2. Soluzione proposta 1. Inserimento e/o modifica dei contratti 2. Inserimento e/o modifica dati anagrafici degli articoli 3. Avanzamento flusso documentale ordine di acquisto 3. Personalizzazione

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1 + Programmazione concorrente in Java 1 + Introduzione al multithreading 2 La scomposizione in oggetti consente di separare un programma in sottosezioni indipendenti. Oggetto = metodi + attributi finalizzati

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

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

TRANSAZIONI. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso.

TRANSAZIONI. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso. Nel caso di successo, i risultati delle operazioni effettuate devono essere resi definitivi; invece,

Dettagli

Informatica di Base - 6 c.f.u.

Informatica di Base - 6 c.f.u. Università degli Studi di Palermo Dipartimento di Ingegneria Informatica Informatica di Base - 6 c.f.u. Anno Accademico 2007/2008 Docente: ing. Salvatore Sorce Il Sistema Operativo Gerarchia del software

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

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Complementi: Buffer I/O Gestione dei buffer e I/O scheduling: 1. Richiami sulle tecniche

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

INTERNET INTRANET EXTRANET

INTERNET INTRANET EXTRANET LEZIONE DEL 17/10/08 Prof.ssa Antonella LONGO In un sistema WEB possono esserci tre configurazioni possibili: internet, intranet ed extranet. La differenza viene fatta dalla presenza o meno di firewall

Dettagli

Ordinamento degli eventi. Lezione 11. Osservazioni. Relazione verificato prima. Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita

Ordinamento degli eventi. Lezione 11. Osservazioni. Relazione verificato prima. Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita Lezione 11 Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita Ordinamento degli eventi Un sistema monoprocessore Unico clock Unica memoria Ordinamento degli eventi Mutua esclusione Deadlock

Dettagli

Struttura dei dischi

Struttura dei dischi Università di Udine Facoltà di Scienze MM.FF.NN. A.A. 2007-2008 Copyright c 2000 04 Marino Miculan (miculan@dimi.uniud.it) La copia letterale e la distribuzione di questa presentazione nella sua integrità

Dettagli

Struttura del calcolatore

Struttura del calcolatore Struttura del calcolatore Proprietà: Flessibilità: la stessa macchina può essere utilizzata per compiti differenti, nessuno dei quali è predefinito al momento della costruzione Velocità di elaborazione

Dettagli

Introduzione alla consultazione dei log tramite IceWarp Log Analyzer

Introduzione alla consultazione dei log tramite IceWarp Log Analyzer Introduzione alla consultazione dei log tramite IceWarp Log Analyzer L Analizzatore di Log è uno strumento che consente un'analisi statistica e logica dei file di log generati dal server. Lo strumento

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

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

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

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5.1. Introduzione Due macchine si parlano solo se conoscono l'indirizzo fisico di sottorete Due applicazioni si parlano solo se conoscono

Dettagli

Descrizione della piattaforma software MPS Monitor

Descrizione della piattaforma software MPS Monitor Descrizione della piattaforma software MPS Monitor MPS Monitor è il più completo sistema di monitoraggio remoto e di gestione integrata ed automatizzata dei dati e degli allarmi relativi ai dispositivi

Dettagli