Spark: la strategia Repartition dopo la lettura di file di testo

Question

ho lanciato il mio gruppo in questo modo:

/usr/lib/spark/bin/spark-submit --class MyClass --master yarn-cluster--num-executors 3 --driver-memory 10g --executor-memory 10g --executor-cores 4 /path/to/jar.jar 

La prima cosa che faccio è leggere un file di testo grande, e ritengo che:

val file = sc.textFile("/path/to/file.txt.gz") 
println(file.count()) 

Quando facendo ciò, vedo che solo uno dei miei nodi sta effettivamente leggendo il file ed eseguendo il conteggio (perché vedo solo un'attività). È previsto? Dovrei ripartizionare il mio RDD in seguito, o quando uso le funzioni di riduzione della mappa, Spark lo farà per me?

Answer 1

Sembra che tu stia lavorando con un file gzip.

Citando my answer here:

Credo che hai raggiunto un problema abbastanza tipico con i file compressi con gzip, nel senso che non possono essere caricati in parallelo. Più precisamente, , un singolo file gzip non può essere caricato in parallelo da più attività, quindi Spark lo caricherà con 1 attività e quindi fornirà un RDD con 1 partizione.

È necessario ripartizionare esplicitamente l'RDD dopo averlo caricato in modo che più attività possano essere eseguite parallelamente.

Ad esempio:

val file = sc.textFile("/path/to/file.txt.gz").repartition(sc.defaultParallelism * 3) 
println(file.count()) 

Per quanto riguarda i commenti sul tuo domanda, l'impostazione minPartitions non aiuta qui motivo è perché a gzipped file is not splittable, quindi Spark utilizzerà sempre 1 compito di leggere il file.

Se si imposta minPartitions durante la lettura di un normale file di testo o un file compresso con un formato di compressione splittabile come bzip2, si vedrà che Spark distribuirà effettivamente quel numero di attività in parallelo (fino al numero di core disponibili nel tuo cluster) per leggere il file.