Come funziona l'algoritmo di ordinamento MapReduce?

Uno dei principali esempi che viene utilizzato per dimostrare la potenza di MapReduce è il benchmark Terasort . Ho problemi a comprendere le basi dell'algoritmo di ordinamento utilizzato nell'ambiente MapReduce.

Per me l'ordinamento implica semplicemente la determinazione della posizione relativa di un elemento in relazione a tutti gli altri elementi. Quindi l'ordinamento implica il confronto di "tutto" con "tutto". Il tuo algoritmo di ordinamento medio (veloce, bolla, ...) lo fa semplicemente in modo intelligente.

Nella mia mente, dividere il set di dati in molti pezzi significa che puoi ordinare un singolo pezzo e poi devi ancora integrare questi pezzi nel set di dati completamente ordinato "completo". Dato il set di dati terabyte distribuito su migliaia di sistemi, mi aspetto che questo sia un compito enorme.

Allora come si fa davvero? Come funziona questo algoritmo di ordinamento MapReduce?

Grazie per avermi aiutato a capire.

Ecco alcuni dettagli sull'implementazione di Hadoop per Terasort :

TeraSort è un ordinamento mappa / riduzione standard, ad eccezione di un partitioner personalizzato che utilizza un elenco ordinato di chiavi campionate N - 1 che definiscono l'intervallo di chiavi per ciascuna riduzione. In particolare, tutte le chiavi tali che sample [i - 1] <= key <sample [i] vengono inviate per ridurre i. Questo garantisce che l'output di reduce i sia inferiore all'output di reduce i + 1. "

Quindi il loro trucco sta nel modo in cui determinano le chiavi durante la fase della mappa. Essenzialmente assicurano che ogni valore in un singolo riduttore sia garantito per essere "pre-ordinato" rispetto a tutti gli altri riduttori.

Ho trovato il riferimento cartaceo tramite il post sul blog di James Hamilton .

Riferimento di Google: MapReduce: elaborazione dei dati semplificata su cluster di grandi dimensioni

Apparso in :
OSDI'04: Sixth Symposium on Operating System Design and Implementation,
San Francisco, CA, dicembre 2004.

Quel collegamento ha un riferimento PDF e HTML-Slide.

C'è anche una pagina Wikipedia con una descrizione con riferimenti all'implementazione.

Anche le critiche,

David DeWitt e Michael Stonebraker, esperti pionieri in database paralleli e architetture non condivise, hanno fatto alcune affermazioni controverse sull'ampiezza dei problemi per i quali MapReduce può essere utilizzato. Hanno definito la sua interfaccia di livello troppo basso e si sono chiesti se rappresenti davvero il cambiamento di paradigma che i suoi sostenitori hanno affermato che sia. Sfidano le affermazioni di novità dei sostenitori di MapReduce, citando Teradata come un esempio di arte anteriore che esiste da oltre due decenni; hanno confrontato i programmatori MapReduce con i programmatori Codasyl, notando che entrambi "scrivono in un linguaggio di basso livello eseguendo manipolazioni di record di basso livello". L'utilizzo di file di input da parte di MapReduce e la mancanza di supporto dello schema impedisce i miglioramenti delle prestazioni abilitati da funzionalità di sistema di database comuni come B-tree e partizionamento hash,

Ho avuto la stessa domanda durante la lettura del documento MapReduce di Google. @Yuval F 's risposta praticamente risolto il mio puzzle.

Una cosa che ho notato durante la lettura del documento è che la magia avviene nel partizionamento (dopo la mappa, prima della riduzione).

Il documento utilizza hash(key) mod Rcome esempio di partizionamento, ma questo non è l'unico modo per partizionare i dati intermedi in diverse attività di riduzione.

Basta aggiungere condizioni al contorno per @Yuval F 's risposta per renderla completa: supponiamo min (S) e Max (S) è la chiave minima e massima della chiave tra i tasti campionati; tutte le chiavi <min (S) sono partizionate in un'attività di riduzione; viceversa, tutte le chiavi> = max (S) sono partizionate in un'attività di riduzione.

Non ci sono limiti rigidi sulle chiavi campionate, come min o max. Solo, più uniformemente queste chiavi R distribuite tra tutte le chiavi, più "parallelo" è questo sistema distribuito e meno probabile che un operatore di riduzione abbia problemi di overflow della memoria.

Tiravo a indovinare...

Dato un enorme set di dati, si partizioneranno i dati in alcuni blocchi da elaborare in parallelo (forse per numero di record, ad esempio record 1 - 1000 = partizione 1 e così via).

Assegna / pianifica ogni partizione a un particolare nodo nel cluster.

Ciascun nodo del cluster suddividerà (mapperà) ulteriormente la partizione nella propria mini partizione, forse in base all'ordine alfabetico delle chiavi. Quindi, nella partizione 1, procurami tutte le cose che iniziano con A e stampale nella mini partizione A di x. Crea una nuova A (x) se attualmente c'è già una A (x). Sostituisci x con un numero sequenziale (forse questo è il lavoro dello scheduler per farlo). Vale a dire Dammi il prossimo ID univoco A (x).

Consegnare (pianificare) i lavori completati dal mapper (passaggio precedente) ai nodi del cluster di "riduzione". Riduci cluster di nodi raffinerà ulteriormente il tipo di ciascuna parte A (x) che accadrà solo quando tutte le attività di mappatura saranno completate (non è possibile iniziare a ordinare tutte le parole che iniziano con w / A quando ci sono ancora possibilità che ci siano ancora sarà un'altra mini partizione in costruzione). Produce il risultato nella divisione ordinata finale (cioè Ordinato-A, Ordinato-B, ecc.)

Una volta terminato, combina nuovamente la partizione ordinata in un unico set di dati. A questo punto è solo una semplice concatenazione di n file (dove n potrebbe essere 26 se stai solo facendo A - Z), ecc.

Potrebbero esserci passaggi intermedi nel mezzo ... non sono sicuro :). Cioè mappare ulteriormente e ridurre dopo la fase di riduzione iniziale.