Какую дополнительную выгоду приносит пряжа для существующей карты?

Пряжа отличается по своему инфраструктурному слою от оригинальной карты уменьшения архитектуры следующим образом:

В YARN трекер заданий разделен на два разных демона, называемыхResource Manager а такжеNode Manager (конкретный узел). Диспетчер ресурсов управляет только распределением ресурсов между различными заданиями, за исключением того, что включает в себя планировщик, который просто заботится о планировании заданий, не беспокоясь о каких-либо обновлениях мониторинга или состояния. Различные ресурсы, такие как память, время процессора, пропускная способность сети и т. Д., Помещаются в один модуль, называемыйResource Container, Они разныеAppMasters работает на разных узлах, которые общаются с рядом этих контейнеров ресурсов и соответственно обновляют Node Manager с подробностями мониторинга / состояния.

Я хочу знать, как использование такого подхода повышает производительность с точки зрения уменьшения карты? Кроме того, если есть какая-то определенная информация о мотивации Yarn и ее преимуществах по сравнению с существующей реализацией Map-Reduce, пожалуйста, укажите мне на то же самое.

Ответы на вопрос(5)

я упрощаю всю информацию следующим образом:

MapReduce:                          YARN:

1. It is Platform plus Application  It is a Platform in Hadoop 2.0 and 
in Hadoop 1. 0 and it is only of    doesn't exist in Hadoop 1.0
the applications in Hadoop 2.0

2. It is single use system i.e.,    It is multi purpose system, We can run
We can run MapReduce jobs only.     MapReduce, Spark, Tez, Flink, BSP, MPP,
                                    MPI, Giraph etc... (General Purpose)

3. JobTracker scalability i.e.,     Both Resource Management and
Both Resource Management and        Application Management gets separated & 
Job Management                      managed by RM+NM, Paradigm specific AMs
                                    respectively.

4. Poor Resource Management         Flexible Resource Management i.e., 
system i.e., slots (map/reduce)     containers.

5. It is not highly available       High availability and reliability.

6. Scaled out up to 5000 nodes      Scaled out 10000 plus nodes.

7. Job->tasks                        Application -> DAG of Jobs -> tasks

8. Classical MapReduce = MapReduce  Yarn MapReduce = MapReduce API +      
   API + MapReduce FrameWork        MapReduce FrameWork + YARN System
   + MapReduce System               So MR programs which were written over
                                    Hadoop 1.0 run over Yarn also with out
                                    changing a single line of code i.e.,
                                    backward compatibility.

которые были устранены с помощью Hadoop 2.0 с добавлением Yarn.

Проблема масштабируемости : Job Tracker работает на одной машине, хотя у вас есть тысячи узлов в кластере Hadoop. Обязанности трекера вакансий: управление ресурсами, график работы и задачи и мониторинг. Поскольку все эти процессы выполняются на одном узле, эта модель не масштабируется.Проблема доступности (единая точка отказа): Job Tracker - это единственная точка отказа.Утилизация ресурсов: Из-за предопределенного количества слотов задач Map & Reduce ресурсы не используются должным образом. Когда все узлы Mapper заняты, узлы Reducer простаивают и не могут использоваться для обработки задач Mapper.Тесная интеграция с платформой Map Reduce: Hadoop 1.x может запускать Map только для заданий. Поддержка заданий, кроме Map Reduce, не существует.

Теперь единственное узкое место Job Tracker было удалено сПРЯЖА архитектура в Hadoop 2.x

Основная идеяПРЯЖА заключается в разделении функций управления ресурсами и планирования / мониторинга заданий на отдельные демоны. Идея состоит в том, чтобы иметь глобальныйResourceManager (RM) и за приложениеApplicationMaster (AM), Приложение - это отдельная работа или группа работ.

ResourceManager имеет два основных компонента:планировщик а такжеApplicationsManager.

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

ApplicationsManager отвечает за принятие заявок на работу, согласование первого контейнера для выполнения приложенияApplicationMaster and provides the service for restarting the ApplicationMaster container on failure.

ApplicationMaster для каждого приложения несет ответственность за согласование соответствующих контейнеров ресурсов с Планировщиком, отслеживание их состояния и мониторинг прогресса.

Теперь преимуществаПРЯЖА

Масштабируемость проблемы были решеныНет единой точки отказа, Все компоненты очень доступныУтилизация ресурсов был улучшен при правильном использовании карты и уменьшении количества слотов.Не Карта Сокращает Рабочие может быть представлен

что пряжа ускорит существующую структуру MR. Рассматривая архитектуру, мы видим, что система теперь более модульная, но модульность обычно противоречит более высокой производительности.
Можно утверждать, что YARN не имеет ничего общего с MapReduce. MapReduce только что стал одним из приложений YARN. Вы можете видеть это как переход от некоторой встроенной программы к встроенной ОС с программой внутри нее
В то же время пряжа открывает дверь дляразные Реализации MR с различными структурами. Например, если мы предположим, что наш набор данных меньше, чем кластерная память, мы можем получить гораздо лучшую производительность. думаюhttp://www.spark-project.org/ один из таких примеров
Подводя итог, можно сказать: пряжа не улучшает существующий MR, но позволит другим реализациям MR быть лучше во всех аспектах.

 David Gruzman21 окт. 2012 г., 14:41
Я согласен, что пряжа дает гораздо больше гибкости и приводит к лучшему использованию. В то же время я не ожидаю, что пряжа улучшит производительность одной работы в большинстве случаев.
 Abhishek Jain21 окт. 2012 г., 13:41
Я согласен с тем, что у Yarn есть дополнительное преимущество использования других парадигм или другой версии Map Reduce в том же кластере, но было бы неправильно говорить, что это не приносит никаких преимуществ в производительности. Пряжа увеличивает использование ресурсов кластера таким образом, что нет предопределенной карты или сокращает количество временных интервалов, и каждое задание может свободно запрашивать столько ресурсов, сколько ему необходимо, и эти ресурсы также включают время процессора и память. Если ресурсы будут более интенсивно использоваться, это, естественно, повысит производительность каждой отдельной работы.
 Abhishek Jain22 окт. 2012 г., 16:30
Я согласен с последним пунктом. Поправь меня, если я ошибаюсь. У треккеров есть предварительно сконфигурированная карта / сокращение слотов. Представьте себе ситуацию, когда у меня есть несколько независимых заданий сокращения карт, т. Е. У map-redund job1 есть мапперы 1,2,3,4 и Redurs 1,2; map-Reduction Job2 есть мапперы 4,5,6,7 и Redurs 3,4. Теперь представьте, что эти 2 задания не используют выходные данные друг друга и не связаны друг с другом, за исключением того, что они работают в одном кластере hadoop. В этом случае моим картостроителям / редукторам, возможно, придется подождать, пока слоты освободятся и станут доступными, и, таким образом, добавится задержка, которой можно избежать в случае пряжи.
 David Gruzman22 окт. 2012 г., 08:16
Я вижу это следующим образом: сокращение слотов занимает только оперативную память, в то время как ЦП, диск, сеть по-прежнему используются мапперами, поэтому выигрыш не так уж велик. Hadoop обычно связан с CPU / IO, но не с системой RAM. Запустив редукторы на этапе отображения, вы не сможете отправлять данные из готовых картографов на редукторы, что увеличивает задержку. Так что в некоторых случаях «поздние редукторы» уменьшат латентность, в некоторых - увеличат. Я также вижу, что во многих случаях тасование и редукторы фактически являются узким местом работы.
 Abhishek Jain21 окт. 2012 г., 20:04
Я до сих пор не могу понять это полностью. Можете ли вы пролить немного света на это. Я смотрю на это со следующей точки зрения - я пытаюсь запустить много картографических устройств в кластере, а слоты сокращения работают без дела (говоря о старой парадигме сокращения карт). В этом случае преобразователи не могут использовать эти идеальные ресурсы и работать, вместо этого им нужно ждать, когда некоторые ресурсы будут освобождены другими заданиями сопоставления. Следовательно, в этом случае присутствует задержка, которая уходит в случае пряжи.

http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/.

Насколько я понимаю, YARN должен быть более общим. Вы можете создавать свои собственные приложения YARN, которые напрямую согласовывают ресурсы с менеджером ресурсов (1), а MapReduce - лишь один из нескольких уже существующих менеджеров приложений (2).

Решение Вопроса

1, 2, 3) о пряжи Они говорят о преимуществах использования YARN.

YARN является более общим, чем MR, и должно быть возможно запустить другие вычислительные модели, такие какБСП кроме MR. До YARN требовался отдельный кластер для MR, BSP и других. Теперь они могут сосуществовать в одном кластере, что приводит к более широкому использованию кластера.Вот некоторые приложения перенесены на YARN.

С точки зрения MapReduce в устаревшей MR есть отдельные слоты для задач Map и Reduce, но в YARN они не являются фиксированным назначением контейнера. Этот же контейнер можно использовать для задачи «Карта», «Сокращение», «Hama BSP» или для чего-то еще. Это приводит к лучшему использованию.

Кроме того, это позволяет запускать разные версии Hadoop в одном и том же кластере, что невозможно с устаревшей MR, что делает это простым с точки зрения обслуживания.

Вот Вот некоторые из дополнительных ссылок для YARN. Также,Hadoop: полное руководство, 3-е издание имеет целый раздел, посвященный YARN.

К вашему сведению, это было немногоспорный разработать YARN вместо использования некоторых фреймворков, которые делали нечто подобное и успешно работали целую вечность с устранением ошибок.

 hanif s04 мар. 2016 г., 13:41
#Praveen Sripati статья недоступна
 Abhishek Jain21 окт. 2012 г., 09:11
Спасибо! Это действительно полезно, особенно 2-я статья.

Ваш ответ на вопрос