Pyspark simple re-partition и toPandas() не заканчиваются только на 600,000 + строках

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

эта работа продолжает терпеть неудачу на EMR только на 600 000 строк данных с некоторыми неясными ошибками. Я также увеличил настройки памяти драйвера spark и до сих пор не вижу никакого разрешения.

вот мой код pyspark:

enhDataDf = (
    sqlContext
    .read.json(sys.argv[1])
    )

enhDataDf = (
    enhDataDf
    .repartition('column1', 'column2')
    .toPandas()
    )
enhDataDf = sqlContext.createDataFrame(enhDataDf)
enhDataDf = (
    enhDataDf
    .toJSON()
    .saveAsTextFile(sys.argv[2])
    )

Мои настройки spark следующие:

conf = SparkConf().setAppName('myapp1')
conf.set('spark.yarn.executor.memoryOverhead', 8192)
conf.set('spark.executor.memory', 8192)
conf.set('spark.driver.memory', 8192)
sc = SparkContext(conf=conf)

ошибки, которые я получаю являются:

16/10/01 19:57:56 ERROR executor.CoarseGrainedExecutorBackend: Driver 172.31.58.76:37973 disassociated! Shutting down.
16/10/01 19:57:11 ERROR executor.CoarseGrainedExecutorBackend: Driver 172.31.58.76:42167 disassociated! Shutting down.
16/10/01 19:57:56 ERROR executor.CoarseGrainedExecutorBackend: Driver 172.31.58.76:37973 disassociated! Shutting down.
log4j:ERROR Could not read configuration file from URL [file:/etc/spark/conf/log4j.properties].
log4j:ERROR Ignoring configuration file [file:/etc/spark/conf/log4j.properties].
16/10/01 19:57:11 ERROR ApplicationMaster: RECEIVED SIGNAL 15: SIGTERM
16/10/01 19:57:11 ERROR ApplicationMaster: User application exited with status 143
log4j:ERROR Could not read configuration file from URL [file:/etc/spark/conf/log4j.properties].
log4j:ERROR Ignoring configuration file [file:/etc/spark/conf/log4j.properties].
16/10/01 19:57:56 ERROR ApplicationMaster: RECEIVED SIGNAL 15: SIGTERM
16/10/01 19:57:56 ERROR ApplicationMaster: User application exited with status 143
16/10/01 19:57:11 ERROR executor.CoarseGrainedExecutorBackend: Driver 172.31.58.76:42167 disassociated! Shutting down.
16/10/01 19:57:56 ERROR executor.CoarseGrainedExecutorBackend: Driver 172.31.58.76:37973 disassociated! Shutting down.

код отлично работает примерно на 600 000 строк JSON-даже если есть тонна доступной памяти. Затем он продолжает терпеть неудачу.

любые мысли о том, что происходит и как отлаживать / исправить эту проблему?

6
apache-spark bigdata distributed-computing memory pyspark

2 ответов

Я считаю, что проблема исходит из следующего часть кода:

enhDataDf = (
    enhDataDf
    .repartition('column1', 'column2')
    .toPandas()
)

.toPandas() собирает данные, поэтому, когда количество записей растет, это приведет к ошибке водителя.

согласно вашему комментарию это точный трубопровод, который вы используете. Это означает, что целый этап не только устарел, но и некорректен. Когда данные собираются и далее распараллеливаются, гарантируется, что разбиение создается

.repartition('column1', 'column2')

будет сохранено когда вы re-create Spark DataFrame:

sqlContext.createDataFrame(enhDataDf)

если вы хотите записать данные по столбцу, вы можете сделать это напрямую:

(sqlContext
    .read.json(sys.argv[1])
    .repartition('column1', 'column2')
    .write
    .json(sys.argv[2]))

пропуск промежуточных toPandas и преобразование в RDD.

после вашего комментария:

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

  • переопределение алгоритмов, которые вы используете поверх Spark it, уже недоступны.
  • рассмотрим альтернативную структуру с лучшей совместимостью стека SciPy (например,ДАСК).
3

Это напоминает мне о шахте Spark-контейнер вышел с ненулевым кодом выхода 143, где я работал в PySpark в кластер режим, который указывает на проблему памяти с вашим приложением.

сначала попробуйте определить, какие машины терпят неудачу, драйвер или исполнитель(Ы), и, таким образом, быть в состоянии нацелить ваши шаги лучше - из того, что я читал, это должны быть исполнители.

Я вижу, что вы уже установили memoryOverhead конфигурация, хорошо. Теперь давайте сосредоточимся на memory конфигурация:

...запуск Python с Spark (PySPark), поэтому весь мой код запускается из кучи. По этой причине я должен выделить" не много " памяти (так как это сократит память, которую мне разрешено использовать из общей памяти; т. е. если общая память, которую мне разрешено использовать, составляет 20G, и я запрашиваю 12G, то 8G будет оставлено для моего приложения Python.

поэтому попробуйте уменьшить этот атрибут, да уменьшить его!

следующая цель: #ядер!

уменьшите это тоже, например, если вы используете 8, а затем используйте 4 в исполнителях и / или драйвере:

spark.executor.cores                        4
spark.driver.cores                          4
1