Автомасштабирование EMR- это обязательно? Должен ли я просто использовать EC2? Должен ли я просто использовать Qubole?
Чтобы сократить время на подготовку, мы решили сохранить выделенный кластер EMR с 5 экземплярами (ожидается, что потребуется около 5). В случае, если нам нужно больше, мы думаем, что нам нужно будет реализовать некоторый вид автомасштабирования.
Я совсем не знаком с EMR- поддерживает ли он автоматическое масштабирование? Я нашел это в документации: http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-manage-resize.html
Это правильное место для поиска автомасштабирования или я неправильно понимаю, что они имеют в виду под "изменением размера". Я читал, что одним из преимуществ EMR является "обработка по требованию", и я думаю, что он распределяет нагрузку между экземплярами ec2 без указания количества экземпляров, поэтому у меня создается впечатление, что он сам выполняет масштабирование экземпляров ec2 Это означает, что нам не нужно автоматически масштабировать себя. Я неправильно понимаю, что означает "обработка по требованию"?
Если предоставленная мной ссылка на изменение размера подходит для того, что я пытаюсь сделать, есть ли у кого-нибудь опыт определения того, когда изменять размер? В документе описывается только то, как, но не, например, как сигнализировать о том, когда нужно изменить размер. Я использовал их обычный сервис автоматического масштабирования, и он позволяет вам изменять размер в зависимости от определенных условий, но я не вижу этого здесь.
Я до сих пор не уверен, является ли автоматическое масштабирование EMR плохой идеей - слишком ли это важно (поскольку есть целые компании, такие как Qubole, которые предоставляют это) или, может быть, не очень полезно, поскольку EMR уже использует любую необходимую ему вычислительную мощность? Я не очень много знаю о том, что на самом деле обеспечивает EMR, поэтому, может быть, поэтому я запутался.
2 ответа
На странице, на которую вы ссылались, были показаны способы ручного или программного увеличения узлов в вашем кластере. Я не мог найти что-нибудь еще об автомасштабировании для EMR.
Если мы не пропустим некоторые факты, вам все равно придется придумать свой собственный алгоритм и процесс масштабирования. Если вы принимаете во внимание такие факторы, как отставание в работе, единицы времени, за которые вы платите, использование менее дорогих "точечных" экземпляров, несколько кластеров и т. Д., Это, вероятно, не тривиальное упражнение.
В дополнение к увеличению размера вашего кластера, есть также сокращение. EMR допускает это (вручную или программно) для узлов задач, но они утверждают, что не для основных узлов. Вам придется завершить работу основного узла с помощью функций AWS и рискнуть потерять данные. Если ваши рабочие нагрузки увеличиваются и уменьшаются со временем, сокращение основного узла будет полезно для снижения затрат.
Qubole автоматически позаботится обо всех этих вещах из коробки. Вы запускаете свои задания из пользовательского интерфейса или API, и он запускает, масштабирует или изменяет размеры кластера. Когда вы закончите, он уменьшает или завершает кластер. Это также позволяет вам иметь минимальное количество постоянно работающих узлов одновременно. Я также слышал, что время запуска для узлов Qubole значительно быстрее, чем EMR.
Надеюсь, это поможет вам.
В настоящее время AWS (по состоянию на конец 2016 года) не поддерживает автоматическое масштабирование из коробки как часть EMR. Однако API EMR предоставляет все необходимые компоненты для 1) сбора данных мониторинга и 2) программного масштабирования кластера вверх и вниз.
По сути, есть два основных варианта реализации автоматического масштабирования для кластеров EMR:
- Цикл автоматического масштабирования: процесс, который выполняется на сервере и постоянно отслеживает текущую загрузку кластера. Метрики производительности (память, процессор, ввод-вывод и т. Д.) Можно регулярно собирать и сохранять в базе данных. Правила автомасштабирования сравниваются с показателями производительности, а узлы задач кластера увеличиваются или уменьшаются при необходимости.
- Автоматическое масштабирование на основе событий: Используя метрики CloudWatch (например, метрики для EMR или метрики для EC2), вы можете программно определять триггеры, которые запускаются при определенных условиях (например, добавлять узлы, если среднее использование CPU всеми узлами превышает 80%).
Оба варианта имеют свои плюсы и минусы. Преимущество варианта 2 заключается в том, что это подход без сервера (не требует запуска собственного сервера). Недостатком является то, что метрики CloudWatch собираются партиями (обычно с пятиминутными интервалами), и, следовательно, данные могут быть немного задержаны или менее точны. Кроме того, подход, основанный на событиях, может не обеспечивать необходимые инструменты для проверки текущего и исторического состояния масштабирования вашего кластера. Вариант 1, с другой стороны, требует сервера, но, следовательно, имеет больший контроль для настройки логики ваших правил масштабирования. Кроме того, это позволяет вести поиск записей истории решений по масштабированию.
Вы можете взглянуть на Themis, платформу для автоматического масштабирования EMR, разработанную в Atlassian. Themis реализует цикл автоматического масштабирования, как описано в варианте 1 выше. Текущие функции включают в себя как активное, так и реактивное автоматическое масштабирование, он поставляется с веб-интерфейсом, и инструмент очень прост в настройке.