Блог компании Сбербанк
Высокая производительность
Java
Big Data
Hadoop
Комментарии 7
0
Скажите, а исходный вариант SparkStreaming у вас также крутился на YARN? Или это был Spark Standalone?
0
Само собой, что не в локальном :-) но какой resource manager вы использовали?
В конечном варианте со спрингом очевидно заявлен YARN. Но был ли он у вас изначально в версии со Spark'ом?
0
Да, это не помогало. Backpressure уменьшает кол-во сообщений в батче, однако проблема была в том, что когда начинались тормоза он и маленький батч обрабатывал неприлично долго. Собственно выглядело так, что от размера батча время обработки мало зависела в этот момент.
0
>Для того чтобы убедиться, что проблема не в функции сохранения данных, можно воспользоваться оберткой Dataset — вроде как он хорошо оптимизирован.

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

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