Как кластеры делят ядра и гигабайты: управление ресурсами при обработке больших данных?⚙️
📌На самом первом Hadoop всем процессом командовал один-единственный «дирижёр» — JobTracker. Он принимал каждую задачу MapReduce, держал у себя в памяти всё-всё о каждой джобе, сам решал, на каком сервере что запустить, и следил, чтобы все работали. Пока данных было десятки гигабайт — было норм. Но когда логов и кликов накопились терабайты, JobTracker стал узким горлышком: память забивалась, отчёты об ошибках копились, а падение одной машины могло поставить на паузу весь кластер — ведь дирижёр был один.
🔄Чтобы разблокировать рост, в Hadoop 2.x придумали YARN (Yet Another Resource Negotiator). Логика была простая: вынесли две задачи — управление вычислительным процессом и управление ресурсами — в разные контуры:
Контур ресурсов
В центре — ResourceManager. Он воспринимает кластер как пул CPU-ядер и гигабайт памяти, ведёт их учёт, применяет выбранную политику планировщика (FIFO, Fair, Capacity) и решает, на каком узле открыть очередной контейнер.
Контур приложений
Для каждого приложения стартует свой ApplicationMaster. Это «директор программы»: оценивает объём работы, запрашивает у ResourceManager контейнеры нужного размера, раздаёт задачи исполнителям(MapReduce, Spark и др.) и отслеживает сбои.
Узловой слой
На каждом сервере работает NodeManager. Он получает команды от ResourceManager, создаёт и завершает контейнеры, следит за фактическим потреблением ресурсов и регулярно отчитывается о здоровье узла.
Контейнер
Контейнер — минимальная единица выполнения: изолированная среда с заданным лимитом CPU и памяти, в которой крутится конкретная задача (Spark-executor, MapReduce-task и т. д.). Это гарантирует, что приложение не выйдет за выделенные ему рамки и не помешает соседям.
✅Благодаря такому разделению «ресурсы — отдельно, логика — отдельно» исчезло узкое горлышко единственного JobTracker’а. Кластер получил гибкую схему: ResourceManager управляет ресурсами в целом, а десятки ApplicationMaster’ов параллельно руководят своими задачами, не мешая друг другу и не конкурируя за центральный диспетчер.
Пользоваться и следить за ресурсами с помощью YARN очень удобно - у него есть UI -интерфейс, где можно отслеживать статусы своих задачек, смотреть логи, искать ошибки.
❓Частые вопросы на собесах:
⏺Как YARN распределяет ресурсы?
⏺Общие принципы работы YARN?
⏺Что такое ApplicationMaster и какие типы вы знаете?
#Hadoop #YARN #DataEngineering #MapReduce #Spark
📌На самом первом Hadoop всем процессом командовал один-единственный «дирижёр» — JobTracker. Он принимал каждую задачу MapReduce, держал у себя в памяти всё-всё о каждой джобе, сам решал, на каком сервере что запустить, и следил, чтобы все работали. Пока данных было десятки гигабайт — было норм. Но когда логов и кликов накопились терабайты, JobTracker стал узким горлышком: память забивалась, отчёты об ошибках копились, а падение одной машины могло поставить на паузу весь кластер — ведь дирижёр был один.
🔄Чтобы разблокировать рост, в Hadoop 2.x придумали YARN (Yet Another Resource Negotiator). Логика была простая: вынесли две задачи — управление вычислительным процессом и управление ресурсами — в разные контуры:
Контур ресурсов
В центре — ResourceManager. Он воспринимает кластер как пул CPU-ядер и гигабайт памяти, ведёт их учёт, применяет выбранную политику планировщика (FIFO, Fair, Capacity) и решает, на каком узле открыть очередной контейнер.
Контур приложений
Для каждого приложения стартует свой ApplicationMaster. Это «директор программы»: оценивает объём работы, запрашивает у ResourceManager контейнеры нужного размера, раздаёт задачи исполнителям(MapReduce, Spark и др.) и отслеживает сбои.
Узловой слой
На каждом сервере работает NodeManager. Он получает команды от ResourceManager, создаёт и завершает контейнеры, следит за фактическим потреблением ресурсов и регулярно отчитывается о здоровье узла.
Контейнер
Контейнер — минимальная единица выполнения: изолированная среда с заданным лимитом CPU и памяти, в которой крутится конкретная задача (Spark-executor, MapReduce-task и т. д.). Это гарантирует, что приложение не выйдет за выделенные ему рамки и не помешает соседям.
✅Благодаря такому разделению «ресурсы — отдельно, логика — отдельно» исчезло узкое горлышко единственного JobTracker’а. Кластер получил гибкую схему: ResourceManager управляет ресурсами в целом, а десятки ApplicationMaster’ов параллельно руководят своими задачами, не мешая друг другу и не конкурируя за центральный диспетчер.
Пользоваться и следить за ресурсами с помощью YARN очень удобно - у него есть UI -интерфейс, где можно отслеживать статусы своих задачек, смотреть логи, искать ошибки.
❓Частые вопросы на собесах:
⏺Как YARN распределяет ресурсы?
⏺Общие принципы работы YARN?
⏺Что такое ApplicationMaster и какие типы вы знаете?
#Hadoop #YARN #DataEngineering #MapReduce #Spark