Comments 6
Есть ли какая-то особенная причина, по которой вы используете старый Spark Streaming вместо нового Spark Structured Streaming? Особенно с учетом того что здесь у вас нет верхней границы на версию спарка.
На диаграмме компонентов стрелка от producer идёт прямо в спарк из кафка и это неправильно- producer пишет в кафку а забирать должен consumer. Это конечно если рассматривать с позиции очереди сообщений.
Как у новичка, незнакомого со spark и потоковой обработкой данных, у меня вопросы по поводу архитектуры.
1. Почему не использовать Kafka streaming, где, по-моему, точно также можно создать обработку сообщений и направлять их в базу данных? Тогда мы отказываемся от целого компонтента, что упрощает систему.
2. Допустим, возникли сложности с Kafka streaming. Следующее, что приходт на ум — почему бы не использовать обычный клиент (java, .net, php...), который, скорее всего, замечательно впшется в текущй стек разработки и уже существующие вопросы тестирования, мониторинга, развёртываня и компетенций разработчиков не должны вызвать трудностей. Если говорить о сheckpoints описанных в статье как
Кажется за этими словами, стоит много важной и основной информации, которая, к сожалению, так и осталась за кадром.
Думаю, что те, кто знаком со стеком, описанным в статье, собственно в ней и не нуждается, тогда я просто развожу руками и предвижу, что статья, если и находит читателей, то говорит только о том, что с Kafka, Spark и AWS можно обрабатывать потоки данных…
1. Почему не использовать Kafka streaming, где, по-моему, точно также можно создать обработку сообщений и направлять их в базу данных? Тогда мы отказываемся от целого компонтента, что упрощает систему.
2. Допустим, возникли сложности с Kafka streaming. Следующее, что приходт на ум — почему бы не использовать обычный клиент (java, .net, php...), который, скорее всего, замечательно впшется в текущй стек разработки и уже существующие вопросы тестирования, мониторинга, развёртываня и компетенций разработчиков не должны вызвать трудностей. Если говорить о сheckpoints описанных в статье как
основной механизм в SparkStreaming, который должен быть настроен для обеспечения отказоустойчивости, то по-моему управление чтением из Kafka с использованием транзакций решает эту проблему.
С ростом объемов данных из различных источников, сложно переоценить практическую ценность Spark Streaming для создания потоковых приложений и приложений, действующих в масштабе реального времени.
Кажется за этими словами, стоит много важной и основной информации, которая, к сожалению, так и осталась за кадром.
Думаю, что те, кто знаком со стеком, описанным в статье, собственно в ней и не нуждается, тогда я просто развожу руками и предвижу, что статья, если и находит читателей, то говорит только о том, что с Kafka, Spark и AWS можно обрабатывать потоки данных…
Sign up to leave a comment.
Apache Kafka и потоковая обработка данных с помощью Spark Streaming