Учтите, что мы собираемся вычислить среднее число датчиков температуры за данный период времени, и это вычисление будет выполнено параллельно с использованием SPE. Обычно это вычисление выполняется как минимум четырьмя UDF:
map -> keyBy -> window -> aggregate
Если мой оператор keyBy отвечает за получение идентификатора каждого датчика, и у меня есть только 2 датчика, параллелизма 2 достаточно для моего приложения (отказ от ответственности: я не хочу учитывать, насколько велико окно или кортежи, которые должны быть в памяти на данный момент).
Если у меня 1000 датчиков, было бы очень приятно увеличить параллельность. Скажем, до 100 узлов.
Но что, если мой параллелизм установлен на 100, и я обрабатываю кортежи только из 2 датчиков. Буду ли я иметь 98 бездействующих узлов? Знают ли Spark, Flink или Storm, что им не нужно перетасовывать данные на 98 узлов?
Мотивация для моего вопроса - это другой вопрос.
- Какое приложение и сценарий можно реализовать, который показывает, что текущие потоковые процессоры (Storm, Flink, Spark) не знают, как оптимизировать параллелизм внутри, чтобы перетасовать меньше данных по сети?
- Могут ли они предсказать какую-либо характеристику объема или разновидности данных? или ресурсы под капотом?
Спасибо