Cos’è Hive: Return Code 2 da org.apache.hadoop.hive.ql.exec.MapRedTask

Sto ottenendo:

FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.MapRedTask 

Durante il tentativo di creare una copia di una tabella partizionata utilizzando i comandi nella console hive:

 CREATE TABLE copy_table_name LIKE table_name; INSERT OVERWRITE TABLE copy_table_name PARTITION(day) SELECT * FROM table_name; 

Inizialmente ho avuto alcuni errori di analisi semantica e ho dovuto impostare:

 set hive.exec.dynamic.partition=true set hive.exec.dynamic.partition.mode=nonstrict 

Anche se non sono sicuro di ciò che fanno le proprietà di cui sopra?

Uscita completa dalla console dell’hive:

 Total MapReduce jobs = 1 Launching Job 1 out of 1 Number of reduce tasks determined at compile time: 1 In order to change the average load for a reducer (in bytes): set hive.exec.reducers.bytes.per.reducer= In order to limit the maximum number of reducers: set hive.exec.reducers.max= In order to set a constant number of reducers: set mapred.reduce.tasks= Starting Job = job_201206191101_4557, Tracking URL = http://jobtracker:50030/jobdetails.jsp?jobid=job_201206191101_4557 Kill Command = /usr/lib/hadoop/bin/hadoop job -Dmapred.job.tracker=master:8021 -kill job_201206191101_4557 2012-06-25 09:53:05,826 Stage-1 map = 0%, reduce = 0% 2012-06-25 09:53:53,044 Stage-1 map = 100%, reduce = 100% Ended Job = job_201206191101_4557 with errors FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.MapRedTask 

Questo non è il vero errore, ecco come trovarlo:

Vai al cruscotto web di jobtracker di hadoop, trova l’hive che ridisegna i lavori che hanno avuto esito negativo e controlla i registri delle attività fallite. Questo ti mostrerà il vero errore.

Gli errori di output della console sono inutili, in gran parte beati non ha una visione dei singoli lavori / attività per tirare gli errori reali (potrebbero esserci errori in più attività)

Spero possa aiutare.

So che sono in ritardo di 3 anni su questa discussione, tuttavia continuerò a fornire i miei 2 centesimi per casi simili in futuro.

Di recente ho affrontato lo stesso problema / errore nel mio cluster. Il JOB otterrebbe sempre una riduzione dell’80% + e fallirà con lo stesso errore, senza che nulla vada avanti nei log di esecuzione. Su diverse iterazioni e ricerche ho scoperto che tra la pletora di file caricati alcuni non erano conformi alla struttura fornita per la tabella di base (tabella utilizzata per inserire dati nella tabella partizionata).

Il punto da notare qui è ogni volta che ho eseguito una query di selezione per un particolare valore nella colonna di partizionamento o creato una partizione statica che ha funzionato correttamente, poiché in quel caso venivano saltati i record degli errori.

TL; DR: Controlla i dati / file in arrivo per incongruenza nella strutturazione in quanto HIVE segue la filosofia Schema-On-Read.

Aggiungendo alcune informazioni qui, mi ci è voluto un po ‘per trovare il dashboard web di hadoop jobtracker in HDInsight (Azure’s Hadoop), e finalmente un collega mi ha mostrato dov’era. C’è un collegamento sul nodo principale chiamato “Hadoop Yarn Status” che è solo un collegamento a una pagina http locale ( http: // headnodehost: 9014 / cluster nel mio caso). Quando è stato aperto, il dashboard si presentava così:

inserisci la descrizione dell'immagine qui

In tale dashboard è ansible trovare l’applicazione non riuscita, quindi, dopo aver fatto clic su di essa, è ansible esaminare i registri della singola mappa e ridurre i lavori.

Nel mio caso sembrava essere ancora a corto di memoria nei riduttori, anche se avevo già inserito la memoria nella configurazione. Per qualche motivo non è emerso gli errori “java outofmemory” che ho avuto prima.

Ho rimosso il file _SUCCESS dal percorso di uscita EMR in S3 e ha funzionato correttamente.

Anche io ho affrontato lo stesso problema – quando ho controllato sul cruscotto ho trovato il seguente errore. Dato che i dati stavano arrivando attraverso Flume e si erano interrotti nel frattempo a causa dei quali poteva esserci stata un’incoerenza in pochi file.

 Caused by: org.apache.hadoop.hive.serde2.SerDeException: org.codehaus.jackson.JsonParseException: Unexpected end-of-input within/between OBJECT entries 

Funzionando con meno file funzionava. La consistenza del formato era la ragione nel mio caso.

Stavo anche affrontando lo stesso errore quando stavo inserendo i dati nella tabella esterna HIVE che puntava al cluster di ricerca elastico.

Ho sostituito il vecchio JAR elasticsearch-hadoop-2.0.0.RC1.jar con elasticsearch-hadoop-5.6.0.jar , e tutto ha funzionato bene.

Il mio suggerimento è usare lo specifico JAR come per la versione di ricerca elastica. Non utilizzare JAR più vecchi se si utilizza la versione più recente della ricerca elastica.

Grazie a questo post Hive-Elasticsearch Write Operation # 409

La risposta migliore è corretta, che il codice di errore non ti dà molte informazioni. Una delle cause comuni che abbiamo visto nel nostro team per questo codice di errore è stata quando la query non è stata ottimizzata bene. Un motivo noto è stato quando eseguiamo un join interno con le grandezze del lato sinistro più grandi rispetto al tavolo sul lato destro. Scambiare questi tavoli in genere farebbe il trucco in questi casi.