Perché l'invio di un lavoro a mapreduce richiede così tanto tempo in generale?

Question

Quindi, in genere, per il processo di invio del cluster da 20 nodi elaborare 3 GB (200 divisioni) di dati richiede circa 30 secondi e l'esecuzione effettiva di circa 1 m. voglio capire che cosa è il collo di bottiglia nel processo di presentazione di lavoro e capire prossima citazione

Per-MapReduce overhead è significativo: inizio/fine lavoro MapReduce costa tempo

qualche processo Sono consapevole: 1. dati frantumazione 2. file jar condivisione

Answer 1

alcune cose da capire su HDFS e M/R che aiuta a capire questa latenza:

1. HDFS archivia i file come porzioni di dati distribuiti su più macchine denominate datanodes
2. M/R esegue più programmi chiamati mapper su ciascuno dei blocchi o blocchi di dati. L'output (chiave, valore) di questi mappatori viene compilato insieme come risultato dai riduttori. (Pensa a sommare i vari risultati di più mapper)
3. Ogni mapper e riduttore è un programma completo che viene generato su questi sistemi distribuiti. Ci vuole del tempo per generare un programma completo, anche se diciamo che non hanno fatto nulla (la mappa No-OP riduce i programmi).
4. Quando la dimensione dei dati da elaborare diventa molto grande, questi tempi di generazione diventano insignificanti e cioè quando Hadoop brilla.

Se si dovesse elaborare un file con un contenuto di 1000 righe, è preferibile utilizzare un normale file di lettura e un programma di elaborazione. L'infrastruttura Hadoop per generare un processo su un sistema distribuito non produrrà alcun vantaggio, ma contribuirà solo al sovraccarico aggiuntivo di localizzazione di datanode contenenti blocchi di dati rilevanti, avviando i programmi di elaborazione su di essi, monitorando e raccogliendo i risultati.

Ora espandilo a 100 byte Peta di dati e questi overheads sembrano completamente insignificanti rispetto al tempo necessario per elaborarli. La parallelizzazione dei processori (mapper e riduttori) mostrerà il suo vantaggio qui.

Quindi, prima di analizzare le prestazioni del tuo M/R, dovresti prima cercare di confrontare il tuo cluster in modo da comprendere meglio i costi generali.

Quanto tempo è necessario per eseguire un programma di riduzione della mappa senza operazioni su un cluster?

Usa MRBench per questo scopo:

1. MRbench loop un piccolo lavoro di un certo numero di volte
2. Verifica se piccole serie di posti di lavoro sono sensibili e in esecuzione in modo efficiente nel cluster.
3. Il suo impatto sullo strato di HDFS è molto limitata

Per eseguire questo programma, provare quanto segue (Verificare il corretto approccio per le versioni più recenti:

hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50 

Sorprendentemente su uno dei nostri cluster dev esso era 22 secondi.

Un altro problema è la dimensione del file.

Se le dimensioni del file sono inferiori alla dimensione del blocco HDFS, i programmi di mappatura/riduzione hanno un sovraccarico significativo. Generalmente Hadoop tenta di generare un mapper per blocco. Ciò significa che se hai 30 file da 5 KB, allora Hadoop potrebbe finire per spawnare fino a 30 mapper per blocco, anche se la dimensione del file è piccola. Questo è un vero spreco poiché ogni overhead del programma è significativo rispetto al tempo che impiegherebbe a elaborare il file di piccole dimensioni.

Answer 2

Per quanto ne so, non esiste un singolo collo di bottiglia che causa la latenza di esecuzione del lavoro; se ci fosse, sarebbe stato risolto molto tempo fa.

Ci sono diversi passaggi che richiedono tempo e ci sono motivi per cui il processo è lento. Cercherò di elencarli e stimare dove posso:

1. Eseguire client hadoop. È in esecuzione Java e penso che sia possibile ipotizzare un sovraccarico di 1 secondo.
2. Inserire il lavoro nella coda e lasciare che lo scheduler corrente esegua il lavoro. Non sono sicuro di cosa sia l'overhead, ma, a causa della natura asincrona del processo, dovrebbe esistere una certa latenza.
3. Calcolo delle divisioni.
4. Attività di sincronizzazione e sincronizzazione. Qui ci troviamo di fronte al fatto che TaskTrackes esegue il polling di JobTracker, e non di fronte. Penso che sia fatto per il bene della scalabilità. Significa che quando JobTracker vuole eseguire qualche compito, non chiama task tracker, ma aspetta che il tracker appropriato esegua il ping per ottenere il lavoro. I tracker delle attività non possono eseguire il ping su JobTracker di frequente, altrimenti lo uccideranno in grandi cluster.
5. Attività in esecuzione. Senza riutilizzo JVM ci vogliono circa 3 secondi, con un sovraccarico di circa 1 secondo per attività.
6. Client track tracker dei sondaggi per i risultati (almeno io la penso così) e aggiunge anche un po 'di latenza per ottenere informazioni che il lavoro è finito.

Answer 3

ho visto problema simile e posso affermare la soluzione per essere rotto in seguenti fasi:

1. quando i negozi HDFS troppi piccoli file con dimensione del blocco fisso, non ci saranno problemi in materia di efficienza in HDFS, il modo migliore sarebbe rimuovere tutti i file non necessari e i file di piccole dimensioni contenenti dati. Riprova.

2. Prova con i nodi di dati e nodi nome:

   • Arrestare tutti i servizi utilizzando stop-all.sh. Nome nodo
   • Formato
   • macchina Reboot
   • avviare tutti i servizi che utilizzano start-all.sh
   • Controllare i dati e nodi di nomi.

3. Provare a installare la versione inferiore di hadoop (hadoop 2.5.2) che ha funzionato in due casi e ha funzionato in hit e trial.