partitionBy занимает слишком много времени при сохранении набора данных на S3 с использованием Pyspark - PullRequest
0 голосов
/ 07 июня 2019

Я пытаюсь сохранить набор данных, используя partitionBy на S3, используя pyspark.Я делю на столбец даты.Работа Spark занимает больше часа, чтобы выполнить ее.Если я запускаю код без partitionBy, это займет 3-4 минуты.Может ли кто-нибудь помочь мне в настройке parititonby?

1 Ответ

0 голосов
/ 09 июня 2019

Хорошо, так что искра ужасна при выполнении ввода-вывода. Особенно в отношении с3. В настоящее время, когда вы пишете в спарк, он будет использовать весь исполнитель для записи данных ПОСЛЕДОВАТЕЛЬНО. То, что назад и вперед между s3 и искрой, приводит к тому, что он довольно медленный. Таким образом, вы можете сделать несколько вещей, чтобы помочь смягчить / обойти эти проблемы.

  • Используйте другую стратегию разбиения, если возможно, с целью минимизации записанных файлов.
  • Если перед записью используется случайное перемешивание, вы можете изменить настройки в соответствии с размером перемешивания по умолчанию: spark.sql.shuffle.partitions 200 // 200 is the default you'll probably want to reduce this и / или перераспределить данные перед записью.
  • Вы можете обойти искры io и написать свой собственный hdfs писатель или напрямую использовать s3 api. Используя что-то вроде foreachpartition, затем функцию для записи в s3. Таким образом, вещи будут писать параллельно, а не последовательно.
  • Наконец, вы можете захотеть использовать repartition и partitionBy вместе при записи ( DataFrame partitionBy в один файл Parquet (на раздел) ). Это приведет к одному файлу на раздел при смешивании с maxRecordsPerFile (ниже), это поможет уменьшить размер файла.

В качестве примечания: вы можете использовать опцию spark.sql.files.maxRecordsPerFile 1000000, чтобы помочь контролировать размеры файлов, чтобы они не вышли из-под контроля.

Короче, вам следует избегать создания слишком большого количества файлов, особенно маленьких. Также обратите внимание: вы увидите большой скачок производительности, когда начнете читать эти 2000 * n файлов.

Мы используем все вышеперечисленные стратегии в разных ситуациях. Но в целом мы просто пытаемся использовать разумную стратегию разбиения + перераспределение перед записью. Еще одно замечание: если происходит случайное перемешивание, ваше разбиение уничтожается и возникает автоматическое разбиение. Отсюда и необходимость постоянного перераспределения.

Надеюсь, эти предложения помогут. SparkIO очень разочаровывает, но не забывайте сводить файлы к минимуму для чтения / записи, и вы должны увидеть отличную производительность.

...