Что такое «задача» в штормовых параллельности

Question

Я пытаюсь научиться твиттер шторма, следуя большую статью «Understanding the parallelism of a Storm topology»

Однако я немного перепутали понятие «задача». Является ли задача запущенным экземпляром компонента (носик или болт)? Исполнитель, имеющий несколько задач на самом деле, говорит, что один и тот же компонент выполняется несколько раз исполнителем, правильно ли я?

Кроме того, в общем смысле параллельности, Storm будет порождать специальную нить (исполнитель) для носика или болта, но то, что вклад в параллельность с помощью исполнителя (нити), имеющего нескольких задач? Я думаю, что есть несколько задач в потоке, так как поток выполняется последовательно, только сделайте поток своего рода «кэшированным» ресурсом, который избегает нереста нового потока для запуска следующей задачи. Я прав?

я могу очистить эти путаницы сам после того, больше времени, чтобы исследовать, но вы знаете, мы оба любим StackOverflow ;-)

Спасибо заранее.

Answer 1

Отказ от ответственности: Я написал the article, на который вы ссылаетесь в своем вопросе выше.

Однако я немного смущен концепцией «задачи». Является ли задача запущенным экземпляром компонента (носик или болт)? Исполнитель, имеющий несколько задач на самом деле, говорит, что один и тот же компонент выполняется несколько раз исполнителем, правильно ли я?

Да, и да.

Кроме того, в общем смысле параллелизма, Storm будет порождать выделенный поток (исполнитель) для носика или болта, но что способствует параллелизму исполнителя (потока), имеющего несколько задач?

Выполнение нескольких задач для каждого исполнителя не увеличивает уровень параллелизма - у исполнителя всегда есть один поток, который он использует для всех своих задач, а это означает, что задачи выполняются последовательно на исполнителе.

Как я уже писал в статье, пожалуйста, обратите внимание, что:

• Количество ИСПОЛНИТЕЛЬ потоков может быть изменен после запуска топологии (см storm rebalance команду).
• Число задач топологии статично.

И по определению существует инвариант #executors <= #tasks.

Таким образом, одна из причин того, что задача 2+ для каждого исполнительного потока - предоставить вам гибкость для расширения/расширения топологии с помощью команды storm rebalance в будущем без использования топологии в автономном режиме. Например, представьте, что вы начинаете с кластера Storm из 15 машин, но уже знаете, что на следующей неделе будут добавлены еще 10 ящиков. Здесь вы можете выбрать запуск топологии на ожидаемом уровне параллелизма из 25 машин уже на 15 исходных ящиках (что, конечно, медленнее, чем 25 ящиков). После того, как будут добавлены дополнительные 10 ящиков, вы сможете затем использовать топологию, чтобы в полной мере использовать все 25 ящиков без простоя.

Другая причина для запуска 2+ заданий для каждого исполнителя - для (в основном функциональных) тестирования. Например, если ваш компьютер-разработчик или сервер CI достаточно мощный, чтобы запустить, скажем, 2 исполнителя вместе со всеми остальными файлами, запущенными на компьютере, вы все равно можете запустить 30 заданий (здесь: 15 на каждого исполнителя), чтобы узнать, может ли код, например, ваша пользовательская группировка Storm работает должным образом.

На практике мы обычно запускаем 1 задачу на каждого исполнителя.

PS: Обратите внимание, что Буря на самом деле порождает a few more threads behind the scenes. Например, каждый исполнитель имеет свой собственный «поток отправки», который отвечает за обработку исходящих кортежей. Также существуют «потоки» на уровне «системного уровня», например. acking кортежи, которые работают рядом с вашими нитями. IIRC The Storm UI подсчитывает эти потоки acking в дополнение к вашим «нитям».