pyspark spark 2.4 на EMR 5.27 - остановка обработки кластера после вывода списка файлов - PullRequest
Новая
       34

pyspark spark 2.4 на EMR 5.27 - остановка обработки кластера после вывода списка файлов

2 голосов
/ 15 октября 2019

Учитывая приложение, преобразующее csv в паркет (из и в S3) с небольшим преобразованием: 

for table in tables:
    df_table = spark.read.format('csv') \
            .option("header", "true") \
            .option("escape", "\"") \
            .load(path)

    df_one_seven_thirty_days = df_table \
            .filter(
                (df_table['date'] == fn.to_date(fn.lit(one_day))) \
                    | (df_table['date'] == fn.to_date(fn.lit(seven_days))) \
                    | (df_table['date'] == fn.to_date(fn.lit(thirty_days)))
            )

    for i in df_one_seven_thirty_days.schema.names:
        df_one_seven_thirty_days = df_one_seven_thirty_days.withColumnRenamed(i, colrename(i).lower())
    df_one_seven_thirty_days.createOrReplaceTempView(table)

   df_sql = spark.sql("SELECT * FROM "+table)
   df_sql.write \
        .mode("overwrite").format('parquet') \
        .partitionBy("customer_id", "date") \
        .option("path", path) \
        .saveAsTable(adwords_table)

Я столкнулся с трудностью с искровым ЭМИ.

На локальном с искрой представить, это без проблем работает (140 МБ данных) и довольно быстро. Но в EMR это другая история.

первый «adwords_table» будет конвертирован без проблем, но второй остается бездействующим.

Я прошел пользовательский интерфейс заданий зажигания, предоставленный EMR, иЯ заметил, что после выполнения этой задачи:

Список листовых файлов и каталогов для 187 путей:

Spark убивает всех исполнителей: enter image description here

и через 20 минут больше ничего не происходит. Все задания находятся в состоянии «Выполнено» и новые не запускаются. Я жду запуска saveAsTable.

Моя локальная машина имеет 8 ядер 15 ГБ, а кластер состоит из 10 узлов. R3.4xlarge: 32 vCore, 122 ГиБ памяти, 320 SSD ГБ, хранилище EBS. Хранение: 200GiB

В конфигурации используется maximizeResourceAllocation true, и я только изменил --num-executors / --executor-cores на 5

Кто-нибудь знает, почему кластер входит в "холостые "и не заканчивает задачу? (это в конечном итоге завершится сбоем без ошибок через 3 часа)

РЕДАКТИРОВАТЬ: Я добился небольшого прогресса, удалив все соединения каталога клея + понизив значение hadoop для использования: hadoop-aws: 2.7.3

Теперь saveAsTable работает нормально, но как только он завершается, я вижу, что исполнители удаляются, а кластер не работает, шаг не заканчивается.

Таким образом, моя проблема остается той же.

Ответы [ 2 ]

0 голосов
/ 18 октября 2019

У меня тоже такая же проблема, связана ли эта проблема с новой версией EMR 5.27? Для меня также работа застряла на одного исполнителя на очень долгое время. Он завершает все 99% исполнителя, и это происходит при чтении файлов.

0 голосов
/ 17 октября 2019

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

Удивительно, но на пользовательском интерфейсе это не отображается, и создается впечатление простоя.

написание занимает несколько часов, независимо от того, что я делаю (перераспределение (1), больший кластер и т. д.).

Основная проблема здесь - saveAsTable, я понятия не имею, что происходит, так долго илисделать запись такой медленной.

Таким образом, я пошел для write.parquet ("hdfs: /// tmp_loc") локально в кластере и затем обработал, чтобы использовать aws s3-dist-cp из hdfs в s3папка.

Производительность превосходна, я перешел от saveAsTable (от 3 до 5 часов на запись 17k строк / 120 МБ) к 3 мин.

Поскольку данные / схема могут измениться в какой-то моментЯ просто выполняю сохранение клея из SQL-запроса.

...