Архитектура Пряжи Искры

enter image description here

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

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

- Это выше верное толкование?

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

6
apache-spark hadoop hdfs scala

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)
    }
}

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

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

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

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

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

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

3