Грузим терабайты бочками или SparkStreaming vs Spring+YARN+Java

[knekrasov]

Скажите, а исходный вариант SparkStreaming у вас также крутился на YARN? Или это был Spark Standalone?

[pustota_2009]

SS запускался в кластерном режиме.

[knekrasov]

Само собой, что не в локальном :-) но какой resource manager вы использовали?
В конечном варианте со спрингом очевидно заявлен YARN. Но был ли он у вас изначально в версии со Spark'ом?

[pustota_2009]

Да, все на YARN

[facha]

Для Spark Streaming backpressure использовать пробовали?

[pustota_2009]

Да, это не помогало. Backpressure уменьшает кол-во сообщений в батче, однако проблема была в том, что когда начинались тормоза он и маленький батч обрабатывал неприлично долго. Собственно выглядело так, что от размера батча время обработки мало зависела в этот момент.

[sshikov]

>Для того чтобы убедиться, что проблема не в функции сохранения данных, можно воспользоваться оберткой Dataset — вроде как он хорошо оптимизирован.

Ну, наверное чтобы убедиться, так сделать можно, но откуда вообще данные, что Dataset в этом месте хорошо оптимизирован? В моем понимании, операции типа сохранения в файл должны быть примерно одинаковы, а оптимизации слегка в другом месте (в каталисте).

И да, самая интересная тема не раскрыта. А именно, где и сколько контейнеров запускается, и почему это оказывается лучше спарка? Если у вас производительность проседала из-за нагрузки на кластер, понятно что можно запустить контейнеры на малонагруженных узлах, но как выбрать такие узлы, даст ли это что-нибудь реально, и не перестанут ли они быть низконагруженными через секунду-другую — вопросы интересные. Ждем'с следующий пост.