Расскажи про суть YARN в Hadoop

А, YARN! Ну это ж классика, ёпта. Представь себе огромный завод, где раньше стоял один-единственный, блядь, конвейер — старый добрый MapReduce. И он только одну деталь штамповал: «раздели-преобразуй-склей». А потом приходит начальник и говорит: «Мужики, так больше нельзя, мы в убытке! Надо, чтобы на этом же заводе можно было и машины собирать, и смартфоны паять, и пирожки печь!». Вот этот начальник — YARN (Yet Another Resource Negotiator). Он не сам работает, он — главный распределитель всего и вся. С его появления в Hadoop 2.0 и началась, можно сказать, нормальная жизнь.

Ключевые рожи на этом заводе:

• ResourceManager (RM) — это, блядь, сам начальник завода, сидит в своей каморке. У него две руки-ноги: Scheduler (это который только бумажки на ресурсы рисует, сам ничего не трогает) и ApplicationsManager (это приемная, куда приносят новые заказы-приложения). Его задача — не вникать, что именно делают в цехах, а следить, чтобы всем хватало железа (CPU, памяти) и никто не подрался.
• NodeManager (NM) — мастер участка на каждом этаже (то есть на каждой машине в кластере). Он получает от начальника наряд на работу (контейнер — это такая коробка с выделенными ресурсами), следит, чтобы рабочие в этой коробке не спали и не жрали все электричество, и стучит об этом наверх.
• ApplicationMaster (AM) — а это, сука, самый главный прораб для КОНКРЕТНОГО заказа. Допустим, привезли чертежи на сборку реактивного самоката (это наше приложение, например, Spark-джоб). Так вот, этот прораб (AM) — он и есть специалист по реактивным самокатам! Он ползает к начальнику (RM), выпрашивает людей и станки (контейнеры), а потом бегает по цехам и орет на мастеров участков (NM), чтобы те по чертежам делали. Гениально же? Раньше прорабом был сам MapReduce, и других самокатов он собрать не мог.

Как весь этот цирк работает, по шагам:

1. Ты, такой весь из себя клиент, приносишь начальнику завода (RM) папку с проектом «Реактивный самокат». Говоришь: «Сделай!».
2. Начальник смотрит в бумаги, хмыкает и говорит одному из мастеров участка (NM): «Вась, выдели в углу каморку и посади туда прораба по самокатам (AM)». Это и есть первый контейнер.
3. Прораб (AM) вылезает из каморки, представляется начальнику: «Я тут, готов работать!». А потом начинает: «Мне для самоката нужно пять токарей, три сварщика и один художник-оформитель!» (это запрос ресурсов у RM).
4. Начальник (RM) через своего плановика (Scheduler) орет по громкой связи: «На втором этаже есть два токаря! На пятом — сварщик! Мастеров пятого этажа (NM), закрепите их за прорабом Ивановым!».
5. Прораб (AM) получает этих работников (контейнеры) и начинает их гонять: «Ты — крути, ты — вари, ты — рисуй цветочки!». И сам же следит, чтобы не накосячили. Если кто-то сдох (упала задача), прораб бежит за новым работником к начальнику.

И в чем, блядь, соль всего этого ёперного театра?

• Завод не простаивает. Раньше, пока конвейер MapReduce штамповал табуретки, линия по сборке гоночных болидов (скажем, Spark) стояла. Теперь же и табуретки, и болиды, и пирожки (Flink, Tez) делаются одновременно на одном и том же железе. Утилизация — овердохуища!
• Масштабируется дохуя. Можно хоть сто этажей достроить (десятки тысяч узлов), начальник (RM) со своими бумажками и прорабами (AM) управится.
• Не привязан к одной технологии. Выкинули старый конвейер MapReduce? Да похуй! Ставим новый для Spark — и прораб (AM) уже другой. Главное, чтобы он умел выпрашивать ресурсы у начальника (RM) по правильному протоколу. Совместимость — её и ели.

Короче, YARN — это не фреймворк для написания программ, а хитрая жопа-менеджер, которая превращает груду серверов в умный, гибкий завод. Без него бы мы до сих пор только табуретки на этом Hadoop'е и штамповали.