Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Modello di programmazione per processare ed elaborare grandi quantità di dati distribuiti su larga scala http://labs.google.com/papers/mapreduce.html Anche implementazione di un sistema che esegue i relativi programmi Alcuni esempi di applicazioni: Web indexing Reverse Web-link graph Distributed sort Web access statistics MapReduce fornisce Funzioni definite dall utente Parallelizzazione e distribuzione automatica Tolleranza ai guasti Scheduling dell I/O Monitoraggio Valeria Cardellini - SDCC 2012/13 1
Elaborazione in due stadi: Map e Reduce Map e Reduce sono scritte dallo sviluppatore Input ed output: insieme di coppie chiave/valore Map Esegue una funzione su valori individuali di un set di dati per creare una nuova lista di valori map (in_key, in_value) -> list(out_key, intermediate_value) Esempio: square x = x * x map square [1,2,3,4,5] returns [1,4,9,16,25] Reduce Combina valori in un set di dati per creare un nuovo valore reduce (out_key, list(intermediate_value)) -> list(out_value) Esempio: sum = (each elem in arr, total +=) reduce [1,4,9,16,25] returns 55 (la somma degli elementi) Valeria Cardellini - SDCC 2012/13 2 Contare il numero di occorrenze di ciascuna parola in una grande collezione di documenti (WordCount) Map(String key, String value): // key: document name // value: document contents for each word w in value: EmitIntermediate(w, 1 ); Map emette ciascuna parola con un semplice 1 associato Valeria Cardellini - SDCC 2012/13 3
Reduce (String key, Iterator values): // key: a word // values: a list of counts int result=0 for each v in values: result += ParseInt(v) Emit(AsString(result)) Reduce somma tutti gli 1 emessi per una parola per ottenere il totale Quello mostrato è pseudo-codice; per il codice completo dell esempio vedere http://labs.google.com/ papers/mapreduce.html Valeria Cardellini - SDCC 2012/13 4 Valeria Cardellini - SDCC 2012/13 5
Apache Hadoop provides open-source software for reliable, scalable, distributed computing Includes Hadoop MapReduce See http://hadoop.apache.org/docs/r0.20.2/mapred_tutorial.html for the WorkCount code YARN: MapReduce 2.0 Valeria Cardellini - SDCC 2012/13 6 Various forms of data storage in the Cloud: Distributed file systems Examples: Google File System (GFS), Hadoop Distributed File System (HDFS) Key-value storage systems Examples: Dynamo, Membase NoSQL databases Examples: BigTable, Cassandra, MongoDB, Hbase, SimpleDB, DynamoDB Goals: massive scaling on demand (elasticity) and simplified application development and deployment Some systems offered only as Cloud services either directly (e.g., Amazon SimpleDB) or as part of a programming environment Other systems used only within a particular company (e.g., Dynamo, GFS) Valeria Cardellini - SDCC 2012/13 7
NoSQL = Not Only SQL Main features of NoSQL databases support flexible schema scale horizontally do not support ACID properties store and replicate data in distributed systems, often across datacenters, to achieve scalability and reliability Useful when working with a huge quantity of data when the data's nature does not require a relational model Traditional join operations cannot be used Valeria Cardellini - SDCC 2012/13 8 Sistema di storage usato da numerosi servizi di base nella piattaforma di Amazon Sistema di storage di tipo chiave-valore altamente disponibile e scalabile Idea di base: gestire i fallimenti è la modalità standard di funzionamento Ad es., per il servizio di shopping cart: Customers should be able to view and add items to their shopping cart even if disks are failing, network routes are flapping, or data centers are being destroyed by tornados Garantire il rispetto di Service Level Agreements Ad es., service guaranteeing that it will provide a response within 300ms for 99.9% of its requests for a peak client load of 500 requests per second. G. DeCandia et al., "Dynamo: Amazon's highly available key-value store", Proc. of ACM SOSP 2007. Valeria Cardellini - SDCC 2012/13 9
Valeria Cardellini - SDCC 2012/13 10 Semplice interfaccia chiave/valore Semplici operazioni di lettura (get) e scrittura (put) su oggetti identificati in modo univoco da una chiave Oggetti di dimensione < 1MB Le operazioni coinvolgono un solo oggetto alla volta Elevata disponibilità con una finestra di consistenza definita (eventual consistency) Proprietà BASE (Basically Available, Soft-state, Eventual consistent) anziché ACID Uso efficiente delle risorse Schema semplice di scale-out per gestire l aumento di dimensione del set di dati o dei tassi di richieste Solo uso interno di Dynamo: ambiente operativo non ostile e quindi no requisiti relativi a sicurezza (ad es. autorizzazione ed autenticazione) Valeria Cardellini - SDCC 2012/13 11
Sacrificare la consistenza forte in favore della disponibilità (vedi teorema CAP) Uso di tecniche di replicazione ottimistiche Possono verificarsi aggiornamenti conflittuali che devono essere individuati e risolti: quando e chi risolve i conflitti? Quando: risoluzione dei conflitti eseguita durante operazioni di read anziché di write, ossia always writeable Chi: data store o applicazione; se data store si usa una politica semplice (ad es. last write wins ) Ulteriori principi: Scalabilità incrementale Aggiunta di nodi senza compromettere il funzionamento del sistema Simmetria e decentralizzazione Tecniche dei sistemi P2P Eterogeneità Valeria Cardellini - SDCC 2012/13 12 Ad ogni oggetto memorizzato è associata una chiave Semplice interfaccia che espone operazioni di get() e put() usata per accedere agli oggetti get(key): individua tutte le repliche dell oggetto associato alla chiave e restituisce un singolo oggetto o un elenco di oggetti con versioni contrastanti insieme a un contesto put(key, context, object): determina dove devono essere memorizzate le repliche dell oggetto in base alla chiave associata e scrive le repliche su disco Il contesto codifica i metadati di sistema, ad esempio la versione dell oggetto Sia la chiave che l oggetto sono trattati come un array di byte opaco Hash MD5 applicato alla chiave per generare un identificatore a 128 bit, usato per determinare i nodi del sistema di storage che sono responsabili per servire quella chiave Valeria Cardellini - SDCC 2012/13 13
Problem Technique Advantage Partitioning Consistent hashing Incremental scalability Vector clocks with Version size is decoupled High Availability for writes reconciliation during reads from update rates Handling temporary Sloppy Quorum and Provides high availability failures hinted handoff and durability guarantee when some of the replicas are not available Recovering from permanent failures Membership and failure detection Anti-entropy using Merkle trees Gossip-based membership protocol and failure detection Synchronizes divergent replicas in the background Preserves symmetry and avoids having a centralized registry for storing membership and node liveness information Valeria Cardellini - SDCC 2012/13 14 Consistent hashing: l intervallo di output della funzione di hash viene trattato come uno spazio circolare fisso o anello (in modo simile a Chord) Nodi e chiavi sono mappati sull anello A differenza di Chord: zero-hop DHT Nodi virtuali : ogni nodo fisico può essere responsabile di più di un nodo virtuale Valeria Cardellini - SDCC 2012/13 15
Ogni oggetto è replicato su N nodi N è un parametro configurabile dall applicazione che usa Dynamo Preference list: la lista di nodi che è responsabile per gestire una determinata chiave Contiene più di N nodi per gestire fallimenti In figura: oggetto identificato dalla chiave K replicato sui nodi B, C e D Valeria Cardellini - SDCC 2012/13 16 Problem Technique Advantage Partitioning Consistent hashing Incremental scalability Vector clocks with Version size is decoupled High availability for writes reconciliation during reads from update rates Handling temporary Sloppy Quorum and Provides high availability failures hinted handoff and durability guarantee when some of the replicas are not available Recovering from permanent failures Membership and failure detection Anti-entropy using Merkle trees Gossip-based membership protocol and failure detection Synchronizes divergent replicas in the background Preserves symmetry and avoids having a centralized registry for storing membership and node liveness information Valeria Cardellini - SDCC 2012/13 17
Una chiamata a put() può ritornare al chiamante prima che l aggiornamento sia stato applicato a tutte le repliche Una chiamata a get() può restituire molteplici versioni dello stesso oggetto Problema: un oggetto può avere diverse versioni, che il sistema dovrà riconciliare Soluzione: uso dei clock vettoriali per catturare la casualità tra diverse versioni dello stesso oggetto Valeria Cardellini - SDCC 2012/13 18 Problem Technique Advantage Partitioning Consistent hashing Incremental scalability Vector clocks with Version size is decoupled High Availability for writes reconciliation during reads from update rates Handling temporary Sloppy Quorum and Provides high availability failures hinted handoff and durability guarantee when some of the replicas are not available Recovering from permanent failures Membership and failure detection Anti-entropy using Merkle trees Gossip-based membership protocol and failure detection. Synchronizes divergent replicas in the background Preserves symmetry and avoids having a centralized registry for storing membership and node liveness information Valeria Cardellini - SDCC 2012/13 19
R/W è il minimo numero di nodi che devono partecipare ad un operazione di read/write L impostazione di R + W > N determina un sistema quorum-like In questo modello, la latenza di un operazione di get (o put) è determinata dalla replica più lenta tra le R (o W) repliche Per migliorare la latenza, R e W possono essere configurati in modo da essere minori di N Configurazione tipica in Dynamo: (N, R, W) = (3, 2, 2) Sloppy quorum Tutte le operazioni di read/write sono eseguite dai primi N nodi funzionanti presi dalla preference list (non sempre coincidono con i primi N nodi sull anello relativi alla data chiave) Valeria Cardellini - SDCC 2012/13 20 Sia N = 3; se A è temporaneamente giù o non raggiungibile durante una scrittura, si invia la replica a D D sa che la replica appartiene ad A: gliela inoltrerà appena A torna ad essere funzionante terminato con successo l invio ad A, D cancella la replica Viene applicato anche in questo caso il principio progettuale always writeable Valeria Cardellini - SDCC 2012/13 21
File system distribuito implementato in user space Gestione di file di dimensioni molto grandi (multi GB) File suddiviso in chunk di dimensione fissa (64MB) Chunk memorizzati come normali file sui chunk server Scrittura in modalità append: aggiungendo dati alla fine del file (possibili append concorrenti) Elevata affidabilità, ottenuta mediante replicazione dei chunk No caching dei dati S. Ghemawat, H. Gobioff, S.-T. Leung, "The Google File System", Proc. of ACM SOSP 2003. Valeria Cardellini - SDCC 2012/13 22 Due tipi di nodi Master Chunk server Chunk server Memorizzano i chunk Master Singolo master: per semplificare l architettura Coordina l accesso ai chunk Non memorizza chunk, ma soltanto metadati relativi ai chunk Gestisce il mantenimento dell opportuno grado di replicazione dei chunk Valeria Cardellini - SDCC 2012/13 23
Ogni chunk è replicato su più chunk server 3+ chunk server per ciascun chunk Grado di replicazione >3 per chunk soggetti ad elevato tasso di richieste Replicazione dei chunk gestita con schema primary-backup Integrità dei dati Checksum di 32B per ogni blocco di 64KB in ciascun chunk Valeria Cardellini - SDCC 2012/13 24 In figura: operazione di lettura - Chunk handle ~ file name del chunk - Il client interagisce con il master per aprire e trovare il file - Il client interagisce con il chunk server per i dati Valeria Cardellini - SDCC 2012/13 25
Quale è il punto debole potenziale di questa architettura? Il master singolo! Single point of failure Scalability bottleneck Valeria Cardellini - SDCC 2012/13 26 Soluzioni adottate in GFS per evitare problemi legati al master singolo: Per evitare single point of failure: presenza di più master ombra che forniscono accesso read-only al file system in caso di non disponibilità del master Per evitare scalability bottleneck: minimizzare il coinvolgimento del master Mai dati sul master, ma solo metadati In più caching dei metadati lato client Dimensione grande dei chunk Il master delega la propria autorità alle repliche primarie per gestire le mutazioni dei dati (lease dei chunk) Semplice! Valeria Cardellini - SDCC 2012/13 27
I file sono organizzati gerarchicamente in directory e identificati da pathname, ma GFS: Non ha una struttura dati per directory Non supporta alias Operazioni tradizionali su un file system: create, delete, open, close, read, write In più: snapshot: crea una copia di un file o dell albero di una directory record append: appende dati ad un file (supporta append atomiche, concorrenti) Valeria Cardellini - SDCC 2012/13 28 Chunk size is 64 MB (much larger than typical block sizes) Large chunk size reduces: number of interactions between client and master network overhead by keeping a persistent TCP connection to the chunk server over an extended period of time size of metadata stored on the master Potential disadvantage: chunks for small files may become hot spots (requires higher replication factor) Each chunk replica is stored as a plain Linux file and is extended as needed Valeria Cardellini - SDCC 2012/13 29
Metadati memorizzati sul master Spazio dei nomi di file e chunk Mapping da file a chunk Posizioni delle repliche di ciascun chunk Metadati memorizzati in memoria (64 B per chunk) Vantaggi: Veloce e facilmente accessibile Limitazione: numero di chunk limitato dalle dimensioni della memoria del master ( The cost of adding extra memory to the master is a small price to pay for the simplicity, reliability, performance, and flexibility gained ) Il master mantiene un log delle operazioni per registrare in modo persistente aggiornamenti critici sui metadati Persistenza su disco locale Replicato Checkpoint per recovery più veloce Valeria Cardellini - SDCC 2012/13 30 Mutazione = write o append Deve essere applicata ad ogni replica Obiettivo: minimizzare il coinvolgimento del master Meccanismo di lease: Il master sceglie una replica come primaria e le assegna un lease per le mutazioni Il primario definisce un ordine seriale delle mutazioni Tutte le repliche seguono quest ordine Flusso dei dati disaccoppiato del flusso di controllo Valeria Cardellini - SDCC 2012/13 31
Il client specifica i dati GFS appende i dati al file in modo atomico almeno una volta GFS sceglie l offset Funziona per scrittori concorrenti Molto usato dalle applicazioni di Google Ad es., per file che servono come code molteplici produttori/ singolo consumatore Valeria Cardellini - SDCC 2012/13 32 Modello di consistenza relaxed (eventual consistency) Consistente = tutte le repliche hanno lo stesso valore Definito = la replica riflette la mutazione, consistente Proprietà: Scritture concorrenti lasciano la regione in uno stato consistente, ma eventualmente non definito Il fallimento di scritture lascia la regione in uno stato inconsistente E un modello di consistenza semplice ed efficiente Aggiornamento dello spazio dei nomi atomico e serializzabile Valeria Cardellini - SDCC 2012/13 33
Memorizzazione dei metadati Gestione/locking dello spazio dei nomi Comunicazione periodica con i chunk server Invia istruzioni, raccoglie informazioni di stato, controlla lo stato di salute (messaggi di heartbeat) Creazione, re-replicazione, bilanciamento dei chunk Bilancia l utilizzazione dello spazio e la velocità di accesso Distribuisce le repliche tra i rack del cluster per ridurre la probabilità di fallimenti correlati Ri-replica i dati se il grado di replicazione scende sotto la soglia Ri-bilancia i dati per bilanciare il carico sullo storage e delle richieste Valeria Cardellini - SDCC 2012/13 34 Garbage collection Più semplice ed affidabile del tradizionale delete di file Registra la cancellazione e rinomina il file usando un nome nascosto Cancellazione di repliche vecchie Individua le repliche vecchie usando i numeri di versione dei chunk Valeria Cardellini - SDCC 2012/13 35
GFS was designed (in 2001) with MapReduce in mind But found lots of other applications Designed for batch applications with large files (web crawling and indexing) but wrong for applications like Gmail or YouTube, meant to serve data in near real-time Problems Single master node in charge of chunk servers All metadata about files stored in the master s memory: limits total number of files Problems when storage grew to tens of Pbytes Automatic failover added (but still takes 10 seconds) Designed for high throughput but delivers high latency: not appropriate for latency sensitive applications Delays due to recovering from a failed replica chunkserver delay the client Valeria Cardellini - SDCC 2012/13 36 Colossus (GFS2) Next-generation cluster-level file system at Google Specifically designed for real-time services Automatically sharded metadata layer Data typically written using Reed-Solomon (1.5x) Client-driven replication, encoding and replication Distributed masters Support smaller files: chunks go from 64 MB to 1 MB Valeria Cardellini - SDCC 2012/13 37
Servizio di lock a grana grossa Offre un implementazione affidabile e scalabile di un protocollo per il consenso distribuito (Paxos) incapsulata in un API Altri sistemi distribuiti (loosely-coupled) possono usarlo per sincronizzare l accesso a risorse condivise Servizio che fornisce Sincronizzazione (elezione del leader, informazioni condivise) Affidabilità e disponibilità Semantica semplice Alte prestazioni, throughput e capacità di storage solo aspetti secondari M. Burrows, "The Chubby Lock Service for Loosely-Coupled Distributed Systems", Proc. of OSDI 2006. Valeria Cardellini - SD A.A. 2010/11 38 GFS: elezione del master BigTable: elezione del master, discovery client, locking delle tabelle Posizione well-known per il bootstrap di sistemi distribuiti di grandi dimensioni Meccanismo di lock progettato per lock coarsegrained: mantenuti per ore o giorni Minor carico sul lock server I lock sopravvivono a fallimenti del lock server Definizione di lock fine-grained al di sopra di Chubby Valeria Cardellini - SD A.A. 2010/11 39
Presenta un semplice file system distribuito Insieme ridotto di operazioni su file rispetto ad un tradizionale FS distribuito I client possono eseguire operazioni di open/ close/read/write su file Letture e scritture solo di tipo whole-file Supporto per lock reader/writer di tipo advisory I client possono iscriversi per ricevere notifiche di aggiornamento dei file Valeria Cardellini - SD A.A. 2010/11 40 2 componenti principali: Server (Chubby cell) Client library Comunicazione via RPC Proxy Opzionale Valeria Cardellini - SD A.A. 2010/11 41
Cella: insieme di server replica Generalmente 5 server: 1 master e 4 repliche Usa un protocollo di consenso distribuito in ambienti non affidabili (Paxos) per eleggere il master Promessa di non eleggere un nuovo master per un certo tempo (lease del master) Il lease del master viene rinnovato periodicamente Mantiene copie di un database semplice Operazioni di write soddisfatte da un quorum di maggioranza Operazioni di read soddisfatte dal solo master Sistema di replacement per repliche fallite Valeria Cardellini - SD A.A. 2010/11 42 L elezione del master è semplice Tutte le repliche cercano di acquisire un lock in scrittura sul file indicato La replica che ottiene il lock è il master Il master può poi scrivere il suo indirizzo nel file Le altre repliche possono leggere questo file per scoprire chi è il master Chubby si comporta come un servizio di naming Valeria Cardellini - SD A.A. 2010/11 43
Interfaccia simile a file system Es. di nome: /ls/foo/wombat/pouch API specializzata Chubby non: Supporta spostamento di file (move), link hard o simbolici Mantiene semantica dei permessi dipendente dal path della directory Rivela data di modifica delle directory e data di ultimo accesso ai file Nodi (file o directory) Di tipo permanent oppure ephemeral Diversi metadati associati ad ogni nodo Handle Analoghi ai descrittori di file in Unix Valeria Cardellini - SD A.A. 2010/11 44 Chubby utilizza un file o una directory come lock lettore-scrittore Un client può tenere il lock in modo esclusivo (writer) Un qualunque numero di client può tenere il lock in modo condiviso (reader) I lock sono di tipo advisory (consultivo) E compito del client comportarsi bene e controllare che il lock non sia tenuto da altri client (in modo analogo ai mutex) Soluzione opposta: lock di tipo mandatory (vincolante) E costoso numerare tutte le interazioni in un SD In Chubby sono numerate solo le interazioni che usano i lock Sequencer: stringa di byte che descrive lo stato del lock dopo l'acquisizione Il possessore di un lock può richiedere il sequencer Un client passa il sequencer al server Valeria Cardellini - SD A.A. 2010/11 45
Open() Creazione dell handle Specifica come verrà usato l handle (controllo degli accessi, eventi che devono essere notificati, ) Close() e Poison() Close() per chiudere un handle aperto Poison() per far fallire le operazioni in corso o successive su un handle senza chiudelo Altre chiamate dell API: GetContentsAndStat(), GetStat, SetContents() per leggere contenuto e metadati di un file e scriverne il contenuto Delete() per cancellare un nodo Acquire(), TryAcquire(), Release() per acquisire e rilasciare lock GetSequencer(), SetSequencer(), CheckSequencer () per operazioni su sequencer Valeria Cardellini - SD A.A. 2010/11 46