Spark: дисковый ввод-вывод при объяснении границ этапа - PullRequest
Новая
       33

Spark: дисковый ввод-вывод при объяснении границ этапа

1 голос
/ 04 ноября 2019

Я не могу найти информацию о временном сохранении данных Spark на диске в официальных документах, только в некоторых статьях по оптимизации Spark, таких как this :

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

Всегда ли стойкость к диску на каждой границе этапа применяется для обоих: HashJoin иSortMergeJoin? Почему Spark (движок в памяти) сохраняет эту стойкость для файлов tmp перед перемешиванием? Это сделано для восстановления на уровне задач или для чего-то еще?

PS Вопрос в основном относится к Spark SQL API, в то время как меня также интересует потоковая и структурированная потоковая передача

UPD: найденоупоминание и более подробную информацию о том, почему это происходит в «Потоковая обработка с книгой Apache Spark» . Найдите разделы «Восстановление после сбоя задачи» и «Восстановление после сбоя» на странице, на которую есть ссылки. Насколько я понял, Почему = восстановление, Когда = всегда, так как это механика Spark Core и Shuffle Service, которая отвечает за передачу данных. Более того, все API Spark (SQL, Streaming и Structured Streaming) основаны на одинаковых гарантиях отработки отказа (Spark Core / RDD). Так что я полагаю, что это обычное поведение для Spark

Ответы [ 2 ]

3 голосов
/ 11 ноября 2019

Spark не является и никогда не был «движком в памяти». Если вы проверите внутреннее устройство, то совершенно ясно, что оно не оптимизировано для обработки в памяти и не настроено для аппаратного обеспечения, ориентированного на память.

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

Такая реализация может использоваться для восстановления или во избежание повторного вычисления (см., Например, Что означает «Пропущенный этап» в веб-интерфейсе Apache Spark? ), но это больше, чем первоначальная цель.

0 голосов
/ 13 ноября 2019

Это хороший вопрос, потому что мы слышим о памяти Spark vs. Hadoop, поэтому немного сбивает с толку. Документы ужасные, но я проверил несколько вещей и проверил наблюдения, оглядываясь по сторонам, чтобы найти самый превосходный источник: http://hydronitrogen.com/apache-spark-shuffles-explained-in-depth.html

Предполагая, что было вызвано Действие - чтобы избежать очевидного комментария, если этоне указано, если мы не говорим о ResultStage и широковещательном соединении, то речь идет о ShuffleMapStage. Сначала мы рассмотрим RDD.

Затем, заимствуя из URL:

  • DAG-зависимость, включающая случайное перемешивание, означает создание отдельной стадии.
  • За операциями карты следуют операции уменьшения и карты и т. Д.

ТЕКУЩИЙ ЭТАП

  • ВсеОперации карты (слитые) выполняются внутри стадии.
  • Требование следующей стадии, операция уменьшения - например, reduByKey, означает, что выходные данные хешируются или сортируются по ключу (K) вконец операций Map текущей стадии.
  • Эти сгруппированные данные записываются на диск на рабочем месте, где находится Executor, или в хранилище, привязанное к этой версии Cloud. (Я бы подумал, что в памяти это возможно, если данных мало, но это архитектурный подход Spark, как указано в документации.)
  • ShuffleManager уведомляется о том, что хэшированные, сопоставленные данные доступны для потребленияследующий этап. ShuffleManager отслеживает все ключи / местоположения после выполнения всей работы на стороне карты.

СЛЕДУЮЩИЙ ЭТАП

  • Следующая стадия, будучи сокращением, затем получает данные из этих мест, консультируясь с Shuffle Manager и используя Block Manager.
  • Исполнитель может быть повторно использован или быть новым на другом Работнике, или другой Исполнитель на том же Работнике.

Итак, я понимаю, что архитектурно, Стадии означаютзапись на диск, даже если достаточно памяти. Учитывая ограниченные ресурсы Worker, имеет смысл, что запись на диск происходит для этого типа операции. Более важным моментом, конечно же, является реализация «Сокращение карты». Я суммировал отличные посты, это ваш канонический источник.

Конечно, отказоустойчивости способствует эта настойчивость, меньше работы по перерасчету.

Подобные аспекты применимы к DF.

...