Комментарии 5
Нет проблем совместить обработку бигдаты с возможностями таких фреймворков.
Я понимаю, что есть доклад про использование Spring+Spark (https://www.youtube.com/watch?v=XLSQJQjmFFw ), но это скорее экзотика, чем общепринятая практика.
Но поскольку специалистов по Java на порядок (как минимум) больше, чем на Scala, то Java - отличный кандидат. Может быть, какие-то доли %% производительности по сравнению со Scala и будут потеряны, но зато это с лихвой компенсируется понятностью кода и более низким порогом входа.
На самом деле от разработчика в случае Spark не требуется уметь во все особенности Scala, по факту это лишь DSL для Spark. При этом разработчиков и вообще экспертизы сообщества гораздо больше для пары Scala+Spark, чем для Java+Spark.
Обычно выбор стоит между Scala или Python для Spark. Первый язык предпочитают в случае доминирования в команде DE (Data engineer-ов): на Scala гораздо проще отлаживать код, проще читать сообщения об ошибках; в случае DS (Data science) ориентированной команды выбирают Python из-за популярности этого языка в индустрии анализа данных: большинство библиотек и как следствие проектов используют именно этот язык. Получается, что проще поддерживать проект, который полностью написан на одном языке, чем проект, который использует сразу два языка.
Безусловно, все зависит от контекста. И может быть именно в вашем случае нужен Kotlin / Java / Scala (сразу или по-отдельности, или в произвольных пропорциях).
Центром всех стриминговых являются окно, у Спарта проблемы как раз с этим. Советую начать с Flink , т.к. там у окон можно легко переопределять триггеры, из коробки полно разных типов. 3 уровня абстракции api и для кода и для SQL style. Самое главное что при стриминге по event watermark через тригеры заводятся таймеры на закрытия. А например у Спарк такого нету, чеки идут только на пришедшее новое сообщения. )
Можно по большей части кодить на Spark, а можно «эскуэлить». Вот мы из Spark взяли что-то из Kafka, положили в ClickHouse, и там что-то «повертели» SQL’ем.
В большинстве случаев это ненужно и громоздко, "эскуэлить" можно и в самом Spark, например, см. createTempView, createOrTemplateTempView, да и вообще, весь SparkSQL в целом - если у вас уже есть бэкграунд в DB, вы достаточно легко в нем разберетесь. Например, тяжелые вычисления из БД выносим в Spark (в том числе, например, можно пользоваться union, join, window functions и т.п. "отражениями" возможностей SQL в самом Spark), а в DB возвращаем результаты только в тех случаях, когда возможностей самого Spark, чтобы сделать какие-то очень продвинутые дашборды вам не хватает, а ваша DB поддерживает их.
Какой язык программирования выбрать? Часть 4: Spark