Медленный этап Spark с небольшим количеством операций ввода-вывода

Если у вас есть медленный этап с не большим количеством операций ввода-вывода, это может быть вызвано следующими причинами:

• Чтение большого количества небольших файлов
• Написание большого количества небольших файлов
• Медленные UDF
• Декартовское присоединение
• Взрыв соединения

Почти все эти проблемы можно определить с помощью DAG SQL.

Открытие DAG SQL

Чтобы открыть daG SQL, прокрутите вниз до верхней части страницы задания и щелкните связанный SQL-запрос:

Теперь вы увидите DAG. Если нет, прокрутите немного и увидите следующее:

Прежде чем двигаться дальше, ознакомьтесь с DAG и где тратится время. Некоторые узлы в DAG содержат полезные сведения о времени, а другие — нет. Например, этот блок занял 2,1 минуты и даже предоставляет идентификатор этапа:

Этот узел требует, чтобы открыть его, чтобы увидеть, что потребовалось 1,4 минуты:

Эти времена являются совокупными, поэтому это общее время, затраченное на все задачи, а не время часов. Но это все еще очень полезно, так как они коррелируются с временем и стоимостью часов.

Полезно ознакомиться с тем, где в DAG время тратится.

Чтение большого количества небольших файлов

Если вы видите, что один из операторов сканирования занимает много времени, откройте его и найдите количество файлов, прочитанных:

Если вы читаете десятки тысяч файлов или более, может возникнуть небольшая проблема с файлом. Файлы должны быть не менее 8 МБ. Проблема с небольшими файлами чаще всего вызвана секционированием на слишком большом количестве столбцов или столбцом высокой карта inality.

Если вам повезло, вам может потребоваться просто запустить OPTIMIZE. Независимо от того, необходимо пересмотреть макет файла.

Написание большого количества небольших файлов

Если вы видите, что запись занимает много времени, откройте ее и найдите количество файлов и количество записанных данных:

Если вы пишете десятки тысяч файлов или более, может возникнуть небольшая проблема с файлом. Файлы должны быть не менее 8 МБ. Проблема с небольшими файлами чаще всего вызвана секционированием на слишком большом количестве столбцов или столбцом высокой карта inality. Вам нужно пересмотреть макет файла или включить оптимизированные записи.

Медленные определяемые пользователем функции

Если вы знаете, что у вас есть определяемые пользователем функции или вы увидите что-то подобное в DAG, вы можете страдать от медленных определяемых пользователем пользователей:

Если вы считаете, что страдаете от этой проблемы, попробуйте закомментировать UDF, чтобы узнать, как это влияет на скорость конвейера. Если UDF действительно где тратится время, лучше всего переписать UDF с помощью собственных функций. Если это невозможно, рассмотрите количество задач на этапе выполнения UDF. Если это меньше числа ядер в кластере, repartition() перед использованием UDF кадр данных выполните указанные ниже действия.

  (df
    .repartition(num_cores)
    .withColumn('new_col', udf(...))
  )

Определяемые пользователем функции также могут страдать от проблем с памятью. Учитывайте, что каждой задаче может потребоваться загрузить все данные в свою секцию в память. Если эти данные слишком большие, вещи могут быть очень медленными или нестабильными. Повторная часть также может устранить эту проблему, сделав каждую задачу меньшей.

Декартовское присоединение

Если в DAG отображается декартовое соединение или вложенное соединение цикла, вы должны знать, что эти соединения очень дороги. Убедитесь, что это то, что вы намеревались, и посмотрите, есть ли другой способ.

Взрыв соединения или взрыва

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

Дополнительные сведения о взрывах см. в руководстве по оптимизации Databricks.