2011-01-04 18 views
30

Correggetemi se ho torto, ma la mia comprensione è che Hadoop non usa MPI per la comunicazione tra diversi nodi.Perché Hadoop non è implementato usando MPI?

Quali sono i motivi tecnici?

Potrei azzardare alcune ipotesi, ma non so abbastanza di come MPI sia implementato "sotto il cofano" per sapere se ho ragione o no.

Vieni a pensarci, non sono del tutto familiare con gli interni di Hadoop. Comprendo il framework a livello concettuale (map/combine/shuffle/reduce e come funziona a un livello elevato) ma non conosco i dettagli di implementazione nitty gritty. Ho sempre pensato che Hadoop trasmettesse strutture di dati serializzate (forse GPBs) su una connessione TCP, ad esempio durante la fase shuffle. Fammi sapere se questo non è vero.

risposta

23

Una delle grandi caratteristiche di Hadoop/map-reduce è la tolleranza ai guasti. La tolleranza ai guasti non è supportata nella maggior parte (eventuali?) Implementazioni MPI correnti. È stato pensato per le versioni future di OpenMPI.

Sandia labs ha una versione di map-reduce che utilizza MPI, ma manca la tolleranza di errore.

+0

Quindi, stai dicendo che la ragione non è inerente all'MPI paradigma stesso, solo implementazioni attuali? Quindi sembra che attualmente i messaggi di rete corrotti oi nodi volubili possano far cadere un sistema MPI. Diciamo che entrambi questi fattori sono stati rimossi. Ci sarebbe qualche motivo per non implementare Hadoop usando ancora MPI? – artif

+0

Penso che questa sia una risposta ragionevole. –

1

In MapReduce 2.0 (MRv2) o applicazioni di filato può essere scritta (o in fase di porting per funzionare) sulla parte superiore del filato.

Quindi essenzialmente ci sarà una prossima generazione di Apache Hadoop MapReduce (MAPREDUCE-279) e un modo per supportare più paradigmi di programmazione su di esso. Quindi si possono scrivere applicazioni MPI su YARN. Il paradigma di programmazione MapReduce sarà sempre supportato come predefinito.

http://wiki.apache.org/hadoop/PoweredByYarn Deve dare un'idea di ciò che tutte le applicazioni sono sviluppate su YARN incluso Open MPI.

+0

Hamster - https://issues.apache.org/jira/browse/MAPREDUCE-2911 –

18

MPI è l'interfaccia di trasferimento dei messaggi. Proprio lì nel nome - non c'è località dati. Si inviano i dati a un altro nodo per essere calcolato su. Quindi MPI è legato alla rete in termini di prestazioni quando si lavora con dati di grandi dimensioni.

MapReduce con il file system distribuito Hadoop duplica i dati in modo da poter eseguire il calcolo nella memoria locale, eseguendo lo streaming dal disco e direttamente al processore. Pertanto MapReduce sfrutta lo storage locale per evitare il collo di bottiglia della rete quando si lavora con dati di grandi dimensioni.

Questo non vuol dire che MapReduce non usi la rete ... lo fa: e lo shuffle è spesso la parte più lenta di un lavoro! Ma lo usa così poco e nel modo più efficiente possibile.

Per riassumere: Hadoop (e roba di Google prima di esso) non utilizzava MPI perché non poteva usare MPI e funzionava. I sistemi MapReduce sono stati sviluppati appositamente per risolvere le carenze di MPI alla luce delle tendenze nell'hardware: esplosione della capacità del disco (e dati con esso), velocità del disco stagnante, reti lente, picco del processore gigahertz, multi-core che riprende la legge di Moore.

+16

Questa è una risposta piuttosto fuorviante. La maggior parte dei programmi MPI non invia TUTTI i dati attraverso la rete. Solitamente sono simulazioni parallele e inviano solo aggiornamenti minimi ai vicini mentre la simulazione procede. Ad esempio, scambio di alone in un codice idrodinamico. Per MapReduce, l'MPI non ha senso perché non è affidabile: se un processo muore, l'intero lavoro muore. Questa è la ragione principale per cui MPI non è una buona base per MapReduce. MPI è per applicazioni strettamente accoppiate su reti veloci e affidabili (supercomputer), mentre MapReduce è progettato per eseguire carichi di lavoro imbarazzanti paralleli su hardware lento e inaffidabile. – tgamblin

+2

-1 per informazioni errate. I "messaggi" che vengono passati non sono l'intero set di dati e le applicazioni MPI possono sicuramente avere localita 'dei dati. MPI e Hadoop sono in qualche modo ortogonali e dove si sovrappongono non è dove hai risposto a questa domanda. I lavori eseguiti utilizzando Hadoop potrebbero assolutamente utilizzare MPI e funzionare bene, è solo un ambiente molto più semplice da utilizzare che fa meno pesantemente di quanto non faccia Hadoop (ma con il vantaggio di maggiori opportunità di ottimizzazione). –

4

La verità è che Hadoop potrebbe essere implementato utilizzando MPI. MapReduce è stato utilizzato tramite MPI fino a quando MPI è stato in giro. MPI ha funzioni come 'bcast' - trasmette tutti i dati, 'alltoall' - invia tutti i dati a tutti i nodi, 'reduce' e 'allreduce'. Hadoop rimuove il requisito di implementare esplicitamente la distribuzione dei dati e raccogliere i metodi dei risultati confezionando un comando di comunicazione in uscita con un comando di riduzione.Il lato positivo è che è necessario assicurarsi che il problema si adatti alla funzione 'reduce' prima di implementare Hadoop. Potrebbe essere il tuo problema è un adattamento migliore per 'scatter'/'gather' e dovresti usare Torque/MAUI/SGE con MPI invece di Hadoop. Infine, MPI non scrive i dati su disco come descritto in un altro post, a meno che non si segua il metodo di ricezione con una scrittura su disco. Funziona esattamente come fa Hadoop inviando i tuoi processi/dati da qualche altra parte per fare il lavoro. La parte importante è capire il tuo problema con un dettaglio sufficiente per essere sicuro che MapReduce sia la strategia di parallelizzazione più efficiente ed essere consapevole del fatto che esistono molte altre strategie.

1

Non esiste alcuna restrizione che impedisca ai programmi MPI di utilizzare dischi locali. E naturalmente i programmi MPI tentano sempre di lavorare localmente sui dati - nella RAM o sul disco locale - proprio come tutte le applicazioni parallele. In MPI 2.0 (che non è una versione futura, è qui da un decennio) è possibile aggiungere e rimuovere processi in modo dinamico, il che rende possibile implementare applicazioni che possono recuperare da es. un processo che muore su qualche nodo.

Forse hadoop non usa MPI perché MPI di solito richiede la codifica in C o Fortran e ha una cultura di sviluppo più scientifica/accademica, mentre hadoop sembra essere più guidato dai professionisti IT con una forte inclinazione Java. MPI è molto basso e soggetto a errori. Permette un uso molto efficiente dell'hardware, della RAM e della rete. Hadoop cerca di essere di alto livello e robusto, con una penalità di efficienza. La programmazione MPI richiede disciplina e grande cura per essere portabile, e richiede ancora la compilazione da codice sorgente su ogni piattaforma. Hadoop è altamente portatile, facile da installare e consente lo sviluppo di applicazioni abbastanza veloci e sporche. È un ambito diverso.

Ancora, forse l'hype di hadoop sarà seguito da alternative più efficienti in termini di risorse, forse basate su MPI.

0

Se osserviamo solo i passi Map/Reduce e la parte di programmazione di Hadoop, direi che MPI è una metodologia/tecnologia molto migliore. MPI supporta molti diversi modelli di scambio come broadcast, barrier, gather all, scatter/gather (o chiamalo map-reduce). Ma Hadoop ha anche l'HDFS. Con questo, i dati possono sedersi molto più vicino ai nodi di elaborazione. E se guardi al problema dello spazio come le tecnologie Hadoop, per cui gli output dei passaggi di riduzione erano in realtà abbastanza grandi, e non vorrai avere tutte quelle informazioni inondare la tua rete. Ecco perché Hadoop salva tutto su disco. Ma i messaggi di controllo avrebbero potuto usare MPI e i messaggi MPI potevano avere solo puntatori (url o handle di file) ai dati reali sul disco ...