Ваш вопрос немного гипотетичен, так как маловероятно, что у вас будет кластер Hadoop с HDFS, существующий только с одним узлом данных и двумя рабочими узлами, один из которых является рабочим и узлом данных.То есть, вся идея Spark (и MR) с HDFS состоит в том, чтобы перенести обработку данных.Рабочие узлы на самом деле являются узлами данных в стандартной настройке Hadoop.Это первоначальное намерение.
Некоторые варианты ответа на ваш вопрос:
При условии, как описано выше, каждый рабочий узел будет обрабатывать один раздел и последующие преобразования вновые сгенерированные RDD до завершения.Конечно, вы можете перераспределить данные, и то, что происходит, зависит от количества разделов и количества исполнителей на рабочий узел.
В двух словах: если у вас изначально N блоков / разделов и меньше, чем N, выделенных исполнителей - E - в кластере Hadoop с HDFS, то вы получите некоторую передачу блоков (нетасование, о котором говорится в другом месте) назначенным рабочим, от рабочих, где исполнителю Spark не назначен исполнитель, в противном случае блок назначается для обработки этому узлу данных / рабочего, очевидно.Каждый блок / раздел обрабатывается некоторым образом, перемешивается, и следующий набор разделов или разделов читается и обрабатывается, в зависимости от скорости обработки ваших преобразований.
Вслучай AWS S3 и эквивалентного облачного хранилища Mircosoft и gooogle, который оставляет в стороне принцип локальности данных, как в приведенном выше случае - т.е. вычислительная мощность отделена от хранилища, с предположением, что сеть не является узким местом - что было в точности классической Hadoopпричина довести обработку до данных, тогда она работает аналогично вышеупомянутому, то есть передача данных S3 рабочим.
Все это предполагает, что было вызвано действие.
Я оставляю в стороне принципы Rack Awareness и т. Д., Поскольку все становится довольно сложным, но Менеджеры ресурсов понимают эти вещи и принимают соответствующие решения.