Спарк Пряжа Архитектура

Question

У меня был вопрос по этому изображению в учебнике я был следующим. Таким образом, на основе этого изображения в архитектуре, основанной на основе нитей, выполнение искрового приложения выглядит примерно так:

Сначала у вас есть драйвер, который работает на клиентском узле или в узле данных. В этом драйвере (похожем на драйвер в java?) Состоит из вашего кода (написанного на java, python, scala и т. Д.), Который вы отправляете в контекст Spark. Тогда этот искровой контекст представляет собой соединение с HDFS и отправляет ваш запрос менеджеру ресурсов в экосистеме Hadoop. Затем менеджер ресурсов связывается с узлом Name, чтобы выяснить, какие узлы данных в кластере содержат информацию, которую запрашивал клиентский узел. Исходный контекст также помещает исполнителя на рабочий узел, который будет выполнять задачи. Затем менеджер узла запустит исполнитель, который будет запускать задачи, предоставленные ему контекстом Spark, и вернет обратно данные, запрошенные клиентом из HDFS, драйверу.

Правильно ли это было сделано?

Также будет ли драйвер посылать три исполнителя на каждый узел данных для извлечения данных из HDFS, поскольку данные в HDFS реплицируются 3 раза на различные узлы данных?

Answer 1

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

Давайте посмотрим, смогу ли я сделать это более понятным для вас.

Предположим, что у вас есть пример подсчета слов в Scala.

object WordCount { 
    def main(args: Array[String]) { 
     val inputFile = args(0) 
     val outputFile = args(1) 
     val conf = new SparkConf().setAppName("wordCount") 

     val sc = new SparkContext(conf) 

     val input = sc.textFile(inputFile) 

     val words = input.flatMap(line => line.split(" ")) 

     val counts = words.map(word => (word, 1)).reduceByKey{case (x, y) => x + y} 

     counts.saveAsTextFile(outputFile) 
    } 
} 

В каждой свече работе Вы состоите шаг инициализации, где вы создаете объект SparkContext, обеспечивающий некоторую конфигурацию подобно APPNAME и мастеров, то вы читаете файл_ввод, вы обрабатываете его, и вы сохраните результат вашей обработки на диск. Весь этот код работает в драйвере, за исключением анонимных функций, которые делают фактическую обработку (функции переданы .flatMap, .map и reduceByKey) и функции ввода-вывода textFile и saveAsTextFile, которые работают удаленно в кластере.

Здесь DRIVER - это имя, которое предоставляется той части программы, которая выполняется локально на том же узле, где вы отправляете свой код с spark-submit (на вашем снимке называется Клиентский узел). Вы можете отправить свой код с любого компьютера (либо ClientNode, WorderNode, либо даже MasterNode), если у вас есть источник искры и доступ к сети для вашего кластера YARN. Для простоты я предполагаю, что клиентский узел является вашим ноутбуком, а кластер пряжи сделан из удаленных компьютеров.

Для простоты я буду игнорировать это изображение Zookeeper, поскольку он используется для обеспечения высокой доступности HDFS и не участвует в запуске искрового приложения. Я должен упомянуть, что Yarn Resource Manager и HDFS Namenode являются ролями в Yarn и HDFS (фактически это процессы, запущенные внутри JVM), и они могут жить на одном и том же ведущем узле или на отдельных машинах. Даже менеджеры Nain Node и узлы данных являются только ролями, но обычно они живут на одной машине, чтобы обеспечить локальность данных (обработка данных, близких к тем, где хранятся данные).

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

Когда ResourceManager найдет доступный рабочий узел, он свяжется с NodeManager на этом узле и попросит его создать контейнер для пряжи (JVM), где запускается исполнитель искры. В других режимах кластера (Mesos или Standalone) у вас не будет контейнера для пряжи, но концепция исполнителя искры одинакова. Исключительный исполнитель работает как JVM и может запускать несколько задач.

Драйвер, выполняющийся на клиентском узле, и задачи, выполняемые на искровых исполнителей, продолжают общаться, чтобы выполнить вашу работу. Если драйвер работает на вашем ноутбуке и сбой вашего ноутбука, вы потеряете соединение с задачами, и ваша работа завершится неудачно. Поэтому, когда искра работает в кластере нити, вы можете указать, хотите ли вы запускать драйвер на своем ноутбуке «-deploy-mode = client» или на кластере пряжи в качестве другого контейнера пряжи »--deploy-mode = cluster ». Для получения дополнительной информации смотрите spark-submit