спарк перераспределение / исполнитель несоответствия командной строки против Jupyter

Question

Я не был уверен, что озаглавить этот вопрос - рад за предложенное лучшее резюме

Я бьюсь головой, пытаясь понять, почему мертвая простая искровая работа отлично работает с Jupyter, но из командной строки осталось недостаточно исполнителей для прогресса.

Что я пытаюсь сделать: у меня большой объем данных (<1 ТБ), из которого мне нужно извлечь небольшой объем данных (~ 1 ГБ) и сохранить как паркет. </p>

Проблема, с которой я столкнулся: когда мой простой код запускается из командной строки, я получаю столько исполнителей, сколько у меня есть окончательных разделов, что в идеале равно одному, учитывая, что оно маленькое. Тот же самый точный код прекрасно работает в Jupyter, том же кластере, где он выполняет задачи> 10 тысяч по всему моему кластеру. Версия командной строки никогда не прогрессирует. Так как он не производит никаких журналов, кроме сообщения об отсутствии прогресса, я не уверен, где еще копать.

Я пробовал и python3 mycode.py, и spark-submit mycode.py с большим количеством вариантов, но безрезультатно. В моем кластере настроено динамическое распределение.

import findspark
findspark.init('/usr/lib/spark/')
from pyspark.sql import SparkSession

spark = SparkSession.builder.enableHiveSupport().getOrCreate()
data = spark.read.parquet(<datapath>).select(<fields>)
subset = [<list of items>]
spark.sparkContext.broadcast(subset)
data.filter(field.isin.(subset)).coalesce(1).write.parquet("output")

** edit: в исходной версии по ошибке было переделано (1) вместо coalesce.

В этом случае при запуске из командной строки мой процесс получит одного исполнителя.

В моих журналах единственная реальная подсказка, которую я получаю, это

WARN TaskSetManager: Stage 1 contains a task of very large size (330 KB). The maximum recommended task size is 100 KB.

, что имеет смысл, учитывая нехватку выделяемых ресурсов.

Я попытался вручную принудительно установить количество исполнителей, используя настройки времени выполнения spark-submit. В этом случае он начнется с моих начальных настроек, а затем сразу же начнет сбрасывать их, пока не останется только один и ничего не прогрессирует.

Есть идеи? Благодарю.

Answer 1

В итоге я позвонил другу ...

код, который работал нормально в JupyterHub, но не через командную строку, по сути был:

• читать паркет,
• фильтр на небольшом поле,
• COALESCE (1)
• написать паркет

Я предполагал, что объединение (1) и перераспределение (1) должны иметь одинаковые результаты - даже если объединение (N) и перераспределение (N) не дают - учитывая, что все они идут в один раздел.

По словам моего друга, Spark иногда оптимизирует coalesce (1) для одной задачи, как я и видел. Изменив его на repartition (1), все работает нормально.

Я до сих пор понятия не имею, почему он хорошо работает в JupyterHub - проведя> 20 экспериментов - и никогда в командной строке - также> 20 экспериментов.

Но, если вы хотите таким образом перенести свое озеро данных в лужу данных, используйте repartition (1) или repartition (n), где n мало, вместо объединения.