Оптимизация / использование ресурсов в EMR для длительной работы и нескольких небольших работ - PullRequest
1 голос
/ 18 марта 2020

Мой вариант использования:

  • У нас долгая работа Spark. Здесь после называется LRJ . Эта работа выполняется один раз в неделю.
  • У нас есть несколько небольших запущенных заданий, которые могут появиться в любое время. Эти задания имеют более высокий приоритет, чем долгосрочное задание.

Чтобы решить эту проблему, мы создали очереди YARN, как показано ниже:

Созданы очереди YARN для управления ресурсами. Сконфигурированная очередь Q1 для долго выполняющихся заданий и очередь Q2 для небольших работ.

Config:
     Q1 : capacity = 50% and it can go upto 100%
          capacity on CORE nodes = 50% and maximum 100%   
     Q2 : capacity = 50% and it can go upto 100%
          capacity on CORE nodes = 50% and maximum 100% 

Проблема, с которой мы сталкиваемся:

Когда LRJ выполняется, он получает все ресурсы. Несколько небольших запущенных заданий ждут, когда LRJ получит все ресурсы. Как только кластер масштабируется и новые ресурсы становятся доступными, небольшие запущенные задания получают ресурсы. Однако, поскольку кластеру требуется время для масштабирования, это создает значительную задержку при распределении ресурсов для этих заданий.

Обновление 1: Мы пытались использовать maximum-capacity config согласно YARN docs , но он не работает, как я писал в моем другом вопросе здесь

1 Ответ

1 голос
/ 19 марта 2020

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

Задания в очереди Q1 будут вытеснены, когда происходит следующая последовательность событий:

  1. Очередь Q1 использует больше указанной емкости (Пример: задание LRJ использует больше ресурсов, чем указано в очереди).
  2. Внезапно задания на Q2 очередь запланирована (пример: неожиданно запускаются несколько небольших запущенных заданий).

Чтобы понять приоритет, прочитайте this и this

Ниже приведен пример конфигурации, которую мы используем в нашем скрипте AWS CloudFormation для запуска кластера EMR:

Конфигурация Capacity-Scheduler:

        yarn.scheduler.capacity.resource-calculator: org.apache.hadoop.yarn.util.resource.DominantResourceCalculator
        yarn.scheduler.capacity.root.queues: Q1,Q2
        yarn.scheduler.capacity.root.Q2.capacity: 60
        yarn.scheduler.capacity.root.Q1.capacity: 40
        yarn.scheduler.capacity.root.Q2.accessible-node-labels: "*"
        yarn.scheduler.capacity.root.Q1.accessible-node-labels: "*"
        yarn.scheduler.capacity.root.accessible-node-labels.CORE.capacity: 100
        yarn.scheduler.capacity.root.Q2.accessible-node-labels.CORE.capacity: 60
        yarn.scheduler.capacity.root.Q1.accessible-node-labels.CORE.capacity: 40
        yarn.scheduler.capacity.root.Q1.accessible-node-labels.CORE.maximum-capacity: 60
        yarn.scheduler.capacity.root.Q2.disable_preemption: true
        yarn.scheduler.capacity.root.Q1.disable_preemption: false

конфигурация yarn-site:

        yarn.resourcemanager.scheduler.class: org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
        yarn.resourcemanager.scheduler.monitor.enable: true
        yarn.resourcemanager.scheduler.monitor.policies: org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy
        yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval: 2000
        yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill: 3000
        yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round: 0.5
        yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity: 0.1
        yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor: 1

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

...