Spark SQL медленное выполнение с ресурсом простоя - PullRequest
2 голосов
/ 24 марта 2019

У меня есть Spark SQL, который раньше выполнялся <10 минут, теперь работает через 3 часа после миграции кластера, и мне нужно углубиться в то, что он на самом деле делает.Я новичок в спарке, и, пожалуйста, не возражайте, если я задам что-то не связанное. </p>

Увеличено spark.executor.memory, но не повезло.

Env: Azure HDInsight Spark 2.4 в хранилище Azure

SQL: чтение и объединение некоторых данных и, наконец, запись результата в метасторское хранилище Hive.

Скрипт spark.sql заканчивается следующим кодом: .write.mode("overwrite").saveAsTable("default.mikemiketable")

Поведение приложения: внутрипервые 15 минут он загружает и выполняет большинство задач (199/200);оставил только 1 процесс-исполнитель живым и непрерывным, чтобы перемешивать данные чтения / записи.Поскольку сейчас остается только 1 исполнитель, нам нужно подождать 3 часа, пока приложение не закончится.enter image description here

Оставлен в живых только 1 исполнитель enter image description here

Не уверен, что делает исполнитель: enter image description here

Время от времени мы можем сказать, что чтение в случайном порядке увеличивается: enter image description here

Поэтому я увеличил память spark.executor.memory до 20g, но ничего не изменилось,От Ambari и YARN я могу сказать, что у кластера осталось много ресурсов.enter image description here

Освобождение почти всех исполнителей enter image description here

Любые указания приветствуются.

1 Ответ

0 голосов
/ 25 марта 2019

Я хотел бы начать с некоторых наблюдений для вашего случая:

  1. Из списка задач вы можете видеть, что оба Shuffle Spill (Disk) и Shuffle Spill (Memory) имеют очень высокие значения.Максимальный размер блока для каждого раздела во время обмена данными не должен превышать 2 ГБ , поэтому следует помнить, что размер перемешанных данных должен быть как можно ниже.Как правило, вы должны помнить, что размер каждого раздела должен быть ~ 200-500 МБ.Например, если общий объем данных составляет 100 ГБ, вам нужно как минимум 250-500 разделов, чтобы сохранить размер раздела в указанных пределах.
  2. Сосуществование двух предыдущих также означает, что памяти исполнителя недостаточно иSpark был вынужден пролить данные на диск.
  3. Длительность задач слишком велика. обычное задание должно длиться от 50 до 200 мс.
  4. Слишком много убитых исполнителей - еще один признак того, что вы сталкиваетесь с проблемами OOM.
  5. Местность это RACK_LOCAL, который считается одним из самых низких значений, которые вы можете достичь в кластере.Вкратце, это означает, что задача выполняется не на том узле, где хранятся данные.

В качестве решения я бы попробовал следующие несколько вещей:

  • Увеличитьколичество разделов с помощью repartition() или через настройки Spark с spark.sql.shuffle.partitions до числа, соответствующего вышеуказанным требованиям, например 1000 или более.
  • Измените способ хранения данных и введите разделенные данные, например день / месяц/ год с использованием partitionBy
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...