Qual è la novità di MapReduce?


68

Alcuni anni fa, MapReduce è stato salutato come una rivoluzione della programmazione distribuita. Ci sono stati anche critici, ma in generale c'era un clamore entusiasta. È stato persino brevettato! [1]

Il nome ricorda mape reducenella programmazione funzionale, ma quando leggo (Wikipedia)

Passaggio della mappa: il nodo principale accetta l'input, lo divide in piccoli problemi secondari e li distribuisce ai nodi di lavoro. Un nodo di lavoro può farlo di nuovo a sua volta, portando a una struttura ad albero a più livelli. Il nodo di lavoro elabora il problema più piccolo e restituisce la risposta al nodo principale.

Riduzione del passaggio: il nodo principale raccoglie quindi le risposte a tutti i problemi secondari e li combina in qualche modo per formare l'output: la risposta al problema che originariamente stava cercando di risolvere.

o [2]

Internals di MAP: [...] MAP divide il valore di input in parole. [...] MAP intende associare ciascuna data coppia chiave / valore dell'input a potenzialmente molte coppie chiave / valore intermedie.

Internals di REDUCE: [...] [REDUCE] esegue l'aggregazione imperativa (diciamo, riduzione): accetta molti valori e li riduce a un singolo valore.

Non posso fare a meno di pensare: questo è dividere e conquistare (nel senso di Mergesort), chiaro e semplice! Quindi, c'è novità (concettuali) in MapReduce da qualche parte o è solo una nuova implementazione di vecchie idee utili in determinati scenari?


  1. Brevetto USA 7.650.331: "Sistema e metodo per un efficiente trattamento dei dati su larga scala" (2010)
  2. Modello di programmazione MapReduce di Google - Rivisitato da R. Lämmel (2007)

7
Non c'è novità. Non voglio che questa sia una risposta, ma sono fermamente convinto che MapReduce non abbia scoperto nulla di nuovo nel calcolo, o persino calcolo distribuito.
edA-qa mort-ora-y,

@Aryabhata: se c'è novità, questa domanda ha una buona risposta costruttiva. In caso contrario, si può dire poco per dimostrarlo (tranne forse ridurre esplicitamente MapReduce a una tecnica precedente), vero. Ma se la pensi così, vota!
Raffaello

@ edA-qamort-ora-y: In tal caso, dovremmo essere in grado di esprimere MapReduce in termini più vecchi, e ciò costituirebbe una buona risposta!
Raffaello

1
@Raphael, sono d'accordo, ma non sono sicuro di poterlo fare. Tuttavia, posso osservare che, come descritto qui (prima citazione), unisci ordinamento utilizza il metodo esatto di mappa / riduzione. In effetti, può essere distribuito senza alterazioni.
edA-qa mort-ora-y

Risposte:


47

Non posso fare a meno di pensare: questo è dividere e conquistare, chiaro e semplice!

M / R non è divisione e conquista. Non comporta l'applicazione ripetuta di un algoritmo a un sottoinsieme più piccolo dell'input precedente. È una pipeline (una funzione specificata come una composizione di funzioni più semplici) in cui le fasi della pipeline alternano mappa e riducono le operazioni. Diverse fasi possono eseguire diverse operazioni.


Quindi, c'è novità (concettuali) in MapReduce da qualche parte o è solo una nuova implementazione di vecchie idee utili in determinati scenari?

MapReduce non apre nuove basi nella teoria del calcolo, non mostra un nuovo modo di scomporre un problema in operazioni più semplici. Mostra che operazioni particolari più semplici sono pratiche per una particolare classe di problemi.


Il contributo del documento MapReduce è stato

  1. valutazione di una pipeline di due operatori ortogonali ben comprensibili che possono essere distribuiti in modo efficiente e tollerante ai guasti su un problema particolare: creazione di un indice di testo di corpus di grandi dimensioni
  2. benchmarking map-ridurre su quel problema per mostrare quanti dati vengono trasferiti tra i nodi e in che modo le differenze di latenza nelle fasi influenzano la latenza complessiva
  3. mostra come rendere il sistema tollerante ai guasti in modo che i guasti della macchina durante il calcolo possano essere compensati automaticamente
  4. identificare scelte e ottimizzazioni specifiche utili per l'implementazione

Alcune delle critiche rientrano in queste classi:

  1. "Mappa / Riduci non apre nuove basi nella teoria del calcolo." Vero. Il contributo del documento originale era che questi operatori ben compresi con una serie specifica di ottimizzazioni erano stati utilizzati con successo per risolvere problemi reali in modo più semplice e tollerante ai guasti rispetto alle soluzioni singole.
  2. "Questo calcolo distribuito non si decompone facilmente in mappa e riduce le operazioni". Abbastanza giusto, ma molti lo fanno.
  3. "Una pipeline di n mappe / stadi di riduzione richiede una latenza proporzionale al numero di passaggi di riduzione della pipeline prima che vengano prodotti risultati." Probabilmente vero. L'operatore di riduzione deve ricevere tutti i suoi input prima di poter produrre un output completo.
  4. "Mappa / riduci è eccessivo per questo caso d'uso." Può essere. Quando gli ingegneri trovano un nuovo martello lucido, tendono a cercare qualcosa che assomigli a un chiodo. Ciò non significa che il martello non sia uno strumento ben fatto per una determinata nicchia.
  5. "Mappa / riduci è una sostituzione scadente per un DB relazionale." Vero. Se un DB relazionale si adatta al tuo set di dati, allora è fantastico per te: hai opzioni.

Bene, chiamano il documento originale "seminale", quindi mi aspetto qualcosa di nuovo. Non capisco il tuo primo paragrafo: chiaramente ci sono molte tecniche algoritmiche che non si dividono e conquistano . Se MapReduce è "solo" un'implementazione efficiente di d & c per una specifica serie di problemi, non è certamente nulla di fondamentale o di brevetto in algoritmo (imho). Ciò non significa che non sia un buon sistema. Nota che la mia critica è meno con MapReduce stesso (suppongo sia buono per quello per cui è stato creato) che con la sua ricezione da parte della comunità.
Raffaello

1
@Raphael, non penso che M / R sia dividere e conquistare nel senso in cui ti colleghi. Non comporta l'applicazione ripetuta di un algoritmo a un sottoinsieme più piccolo dell'input originale. È una pipeline in cui le fasi della pipeline alternano mappa e riducono le operazioni.
Mike Samuel,

Eh vero. Ho interpretato "Un nodo di lavoro può farlo di nuovo a sua volta, portando a una struttura ad albero a più livelli". in questo modo, ma ciò ovviamente non implica che lo stesso accada ad ogni livello.
Raffaello

1
@ ex0du5, penso che potresti condannarlo per affermazioni che non ha fatto. "Molti sistemi hanno fornito modelli di programmazione limitati e hanno utilizzato le restrizioni per parallelizzare automaticamente il calcolo ... MapReduce può essere considerato una semplificazione e distillazione di alcuni di questi modelli in base alla nostra esperienza con grandi calcoli del mondo reale ... ... Al contrario , la maggior parte dei sistemi di elaborazione parallela è stata implementata solo su scale più piccole e lascia al programmatore i dettagli della gestione dei guasti della macchina. " Cita articoli di Rabin e Valiant su questo, ma non quello di Liskov.
Mike Samuel,

1
@ ex0du5, abbastanza giusto. Ho pensato "" Mappa / Riduci non apre nuove basi nella teoria del calcolo. "Vero." era abbastanza chiaro ma ho riscritto l'elenco dei contributi.
Mike Samuel,

21

EDIT (marzo 2014) Devo dire che da allora ho lavorato di più sugli algoritmi per i modelli di calcolo di tipo MapReduce e mi sento come se fossi stato eccessivamente negativo. La tecnica Divide-Compress-Conquer di cui parlo di seguito è sorprendentemente versatile e può essere la base di algoritmi che ritengo non banali e interessanti.


Consentitemi di offrire una risposta che sarà molto inferiore a quella di Mike in termini di completezza, ma da un modello di teoria computazionale / teorica algoritmica.

Perché c'è entusiasmo : MapReduce interlaccia il calcolo parallelo e sequenziale; ciascun processore ha accesso a un blocco non banale (ad es. ) dell'input e può eseguire un'operazione non banale su di esso; è molto diverso dai modelli PRAM e sembra un'idea interessante che potrebbe portare a nuove tecniche algoritmiche. In particolare, alcuni problemi possono essere risolti in pochi round di calcolo (costanti nella dimensione dell'input), mentre nessun problema non banale può essere risolto in PRAM in time.o ( registro n )O(nϵ)o(logn)

Perché il modello sta diventando leggermente frustrante per me : l'unica tecnica algoritmica che sembra funzionare per ottenere round algoritmi ed è in qualche modo nuova è la seguenteO(1)

  • Partizionare l'istanza del problema (spesso in modo casuale)
  • Effettuare un calcolo su ciascuna partizione in parallelo e rappresentare in modo compatto il risultato del calcolo
  • Combina tutte le soluzioni dei sottoproblemi rappresentate in modo compatto su un singolo processore e finisci il calcolo lì

Esempio molto semplice di tecnica: calcolare la somma di numeri. Ogni processore ha dell'array e calcola la somma di quella porzione. Quindi tutte le somme possono essere combinate su un singolo processore per calcolare la somma totale. Un esercizio leggermente più interessante è calcolare tutte le somme dei prefissi in questo modo (ovviamente in questo caso l'output deve essere rappresentato in modo distribuito). O calcola un albero spanning di un grafico denso.O ( nO(n)n

Ora, penso che questa sia in realtà una svolta interessante su divide e conquistare, il twist è che dopo la fase di divide è necessario comprimere le soluzioni dei sottoproblemi in modo che un singolo processore possa conquistare. Tuttavia, questa sembra davvero essere l'unica tecnica che abbiamo escogitato finora. Non riesce su problemi con grafici sparsi, come ad esempio la connettività sparsa. In contrasto con il modello di streaming, che ha portato a moltissime nuove idee, come l'ingegnoso algoritmo di campionamento di Flajolet e Martin, l'algoritmo di accoppiamento deterministico di Misra e Gries, il potere di semplici tecniche di schizzo, ecc.

Come paradigma di programmazione, la riduzione delle mappe ha avuto molto successo. I miei commenti considerano la riduzione della mappa come un interessante modello di calcolo. I buoni modelli teorici sono un po 'strani. Se seguono la realtà troppo da vicino sono ingombranti, ma soprattutto, (per prendere in prestito un termine dall'apprendimento automatico) i teoremi provati per modelli troppo specifici non si generalizzano, cioè non si applicano ad altri modelli. Ecco perché vogliamo sottrarre il maggior numero possibile di dettagli, lasciando comunque abbastanza da sfidarci a inventare nuovi algoritmi. Infine, queste nuove idee dovrebbero essere in grado di ritrovare la strada per tornare al mondo reale. La PRAM è un modello non realistico che ha portato a idee interessanti ma quelle idee si sono rivelate raramente applicabili al calcolo parallelo del mondo reale. D'altro canto, anche lo streaming non è realistico, ma ha ispirato idee algoritmiche che sono effettivamente impiegate nel mondo reale. Vedereconteggio dei minuti . Le tecniche di sketch sono infatti utilizzate anche nei sistemi basati sulla riduzione delle mappe.


Probabilmente M / R è però un modello più realistico (utile) di PRAM o stream. (Almeno per qualche serie ragionevolmente ampia di problemi.)
Xodarap,

"è necessario comprimere le soluzioni dei sottoproblemi in modo che un singolo processore possa conquistare" - Sembra che tu stia dicendo che l'insieme di problemi che possono essere risolti da M / R è un sottoinsieme di quelli per i quali esiste tracciabile compatibile con cache o cache -lucide soluzioni. Se è vero, allora mi sembra che questa affermazione si applichi ugualmente bene alla maggior parte degli schemi di calcolo distribuiti.
Mike Samuel,

1
@Xodarap che potrebbe anche essere. qui sto usando un punto di vista teorico puramente algoritmi: un modello è utile se conduce a nuove prospettive algoritmiche. in base a ciò, lo streaming non è del tutto realistico ma ha portato a numerose nuove tecniche che sono effettivamente utili nella pratica. il punto è qual è la giusta astrazione che porta a un nuovo pensiero. le astrazioni MR attuali hanno un successo misto (ma un certo successo, immagino)
Sasho Nikolov

1
@MikeSamuel il "bisogno" in quella frase significa che questo è ciò che la tecnica richiede per funzionare, non che sia l'unica cosa possibile da fare. non ci sono risultati teorici negativi per MR che conosco. la mia lamentela non è che MR sia strettamente meno potente di CO. è che non abbiamo visto molti nuovi pensieri algoritmici ispirati dal modello (che va bene per un sistema, ma deludente per un modello di calcolo). d'altra parte cache obliviousness stessa è un'idea incredibile imo
Sasho Nikolov

@SashoNikolov, capito. Grazie per aver spiegato.
Mike Samuel,

6

Sono pienamente d'accordo con te. Dal punto di vista concettuale, non c'è nulla di veramente nuovo: Map / Reduce era originariamente noto in Parallel Computing come modello di programmazione del flusso di dati. Tuttavia, da un punto di vista pratico, Map / Reduce come proposto da Google e con le successive implementazioni open source ha anche alimentato il Cloud Computing ed è ora abbastanza popolare per le scomposizioni e l'elaborazione parallele molto semplici. Naturalmente, non è adatto a qualsiasi altra cosa che richieda domini complessi o decomposizioni funzionali.


3

Penso che tu abbia colpito l'unghia sulla testa con il tuo commento.

Non è vero che in qualsiasi lingua funzionale le mappe possano essere parallelizzate - la lingua deve essere pura . (Credo che Haskell sia l'unico linguaggio vagamente mainstream puramente funzionale. Lisp, OCaml e Scala sono tutti non puri.)

Conosciamo i vantaggi del codice puro sin da prima della multiproprietà, quando gli ingegneri hanno pipeline per la prima volta i loro processori. Allora come mai nessuno usa un linguaggio puro?

È davvero molto, molto difficile. Programmare in un linguaggio puro spesso sembra come programmare con entrambe le mani legate dietro la schiena.

Quello che fa MR è di rilassare un po 'il vincolo di purezza e fornire un quadro per altri pezzi (come la fase shuffle) che rende abbastanza facile scrivere codice distribuibile per una grande frazione di problemi.

Penso che speravi in ​​una risposta del tipo "Dimostra questo importante sotto-lemma di " e non credo che faccia qualcosa del genere. Ciò che fa è mostrare che una classe di problemi noti per essere distribuibili sono "facilmente" distribuibili - se questa è una "rivoluzione" secondo te probabilmente dipende da quanto tempo hai dedicato al debug del codice distribuito in una pre-Mappa / Riduci mondo.NC=P


Non ho familiarità con MapReduce, ma la tua presentazione non sembra diversa da quella che ricordo di essere stata presentata come il caso ideale nel parallelismo 101 nel secolo precedente.
Gilles 'SO- smetti di essere malvagio' il

@Gilles: La mia intenzione era solo per dimostrare che "divide & Conquer" =! " Distribuibile divide e impera". M / R è meno banale, anche se probabilmente ancora non originale.
Xodarap,

Nella programmazione funzionale, tutte le mappe possono essere parallelizzate (in modo imbarazzante), quindi perché non attenersi a quel paradigma? Non vedo come countsia una variabile condivisa nel tuo pseudo codice; semplicemente passando il suo valore attuale a do_somethingdovrebbe funzionare. Puoi fare un esempio di un algoritmo d & c "reale" (Mergesort, Quicksort, ...) per il quale le chiamate ricorsive dipendono l'una dall'altra (dopo che la chiamata è stata emessa)?
Raffaello

@Raphael: ho riscritto la mia risposta per rispondere meglio al tuo commento. Posso aggiungere un esempio di quando la purezza è fastidiosa, se vuoi ancora.
Xodarap,

1
@Raphael: Sono d'accordo sul fatto che la mia risposta sarebbe molto migliore se potessi citare un documento che mostra che il tempo di programmazione scende da X ore a Y usando M / R, o aumenta da A a B applicando la purezza, ma penso che tutto ciò che posso fare è agitare le mani furiosamente e insistere sul fatto che le differenze non sono banali.
Xodarap,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.