Spark: strategia Repartition po przeczytaniu pliku tekstowego

Question

Mam uruchomiła moją klaster ten sposób:

/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 

Pierwszą rzeczą, którą robię jest odczytywany duży plik tekstowy, a liczyć go:

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

Kiedy robiąc to widzę, że tylko jeden z moich węzłów faktycznie czyta plik i wykonuje liczenie (ponieważ widzę tylko jedno zadanie). Czy to jest oczekiwane? Czy powinienem ponownie rozdzielić mój RDD lub kiedy używam funkcji zmniejszania mapy, czy Spark zrobi to za mnie?

Answer 1

Wygląda na to, że używasz spakowanego pliku gzip.

Cytując my answer here:

Myślę, że uderzył w dość typowy problem z spakowane gzipem plików, które nie mogą być ładowane równolegle. Dokładniej, pojedynczy plik gzipowany nie może być ładowany równolegle przez wiele zadań, więc Spark załaduje go z 1 zadaniem, a tym samym da RDD z 1 partycją.

Po załadowaniu trzeba jawnie je ponownie podzielić na partycje RDD, aby można było wykonywać równolegle więcej zadań.

Na przykład:

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

Jeśli chodzi o komentarze na swoje pytanie, powodem ustawienie minPartitions nie pomaga tu dlatego a gzipped file is not splittable, więc Spark będzie zawsze używać 1 zadanie odczytać pliku.

Jeśli ustawisz minPartitions podczas czytania zwykłego pliku tekstowego lub pliku skompresowanego z możliwym do podzielenia formatem kompresji, jak bzip2, zobaczysz, że Spark faktycznie wdroży tę liczbę zadań równolegle (do liczby dostępnych rdzeni w klastrze), aby odczytać plik.