2015-08-04 17 views
5

Sto scrivendo un file parquet da DataFrame a S3. Quando guardo all'interfaccia utente di Spark, sono in grado di vedere tutte le attività tranne una completata in fase di scrittura (ad esempio 199/200). Quest'ultima operazione sembra richiedere sempre un completamento e, molto spesso, non riesce a causa del superamento del limite di memoria dell'esecutore.Spark scrive Parquet a S3 l'ultima operazione richiede per sempre

Mi piacerebbe sapere cosa sta succedendo in quest'ultimo compito. Come ottimizzarlo? Grazie.

+0

Mi accorgo che quest'ultimo task executor ha una lettura molto più casuale rispetto agli altri esecutori completati. Questo significa che il partizionamento non è ottimale? Come evitarlo? – user2680514

+0

Sto usando Spark 1.3.1 – user2680514

+0

Per determinare se il problema di inclinazione dei dati è il problema, abbiamo bisogno di maggiori informazioni sulla dimensione di quest'ultimo file rispetto agli altri. Dato quello che hai detto sugli errori di OOM, penso che il problema sia dovuto all'oscillazione dei dati. Senza un po 'di codice sarà difficile aiutare in qualsiasi cosa tranne una prova, questa prova in questo modo. – BAR

risposta

0

Sembra che tu abbia un dato di skew. Puoi risolvere questo problema chiamando repartition sul tuo DataFrame prima di scrivere su S3.

0

Questo articolo - The Bleeding Edge: Spark, Parquet and S3 contiene molte informazioni utili su Spark, S3 e Parquet. In particolare, parla di come il driver finisce per scrivere i file _common_metadata_ e può impiegare un po 'di tempo. C'è un modo per spegnerlo.

Sfortunatamente, dicono che continuano a generare i metadati comuni stessi, ma in realtà non parlano di come lo hanno fatto.

Problemi correlati