Spark Структурированная потоковая передача - ограничения?(Производительность источника, неподдерживаемые операции, интерфейс Spark)

Question

Я начал исследовать Spark Structured Streaming, чтобы написать несколько приложений, которые до этого использовали DStreams .

Я пытаюсь понять ограничения структурированного потокового вещания, поскольку я начал его использовать, но хотел бы знать, какие есть недостатки.

Q1.Для каждого приемника в приложении структурированной потоковой передачи оно будет независимо читать из источника (например, Kafka).Это означает, что если вы читаете из одной темы A и пишете в 3 места (например, ES, Kafka, S3), это фактически установит 3 исходных соединения, независимых друг от друга .

Будет ли это снижение производительности?Поскольку для этого потребуется 3 независимых управляемых соединения вместо одного (подход DStream)

Q2.Я знаю, что объединение 2 потоковых наборов данных не поддерживается .Как я могу выполнить расчеты на 2 потока?

Если у меня есть данные из темы A и другие данные из темы B, можно ли как-то провести расчеты по обоим из них?

Q3.В пользовательском интерфейсе Spark Streaming есть вкладка Streaming для метрик и для просмотра пропускной способности приложения.В структурированном потоке это больше не доступно.

Почему это?Является ли намерение получить все показатели программно и передать их в отдельную службу мониторинга?

Answer 1

Для каждого приемника в приложении структурированной потоковой передачи оно будет независимо считывать данные из источника (например, Kafka).Это означает, что если вы читаете из одной темы А и пишете в 3 места (например, ES, Kafka, S3), это фактически установит 3 соединения с источником независимо друг от друга.

Из коробки, да,Каждый Раковина описывает свой поток выполнения.Но вы можете обойти это, не используя встроенные приемники и создавая свой собственный, который управляет записью.

Будет ли это снижение производительности?Поскольку для этого потребуется 3 независимых управляемых соединения вместо одного (подход DStream)

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

Q2.Я знаю, что объединение двух потоковых данных не поддерживается.Как я могу выполнить расчеты на 2 потока?

Начиная с версии Spark 2.3 это поддерживается OOTB.

Q3.В пользовательском интерфейсе Spark Streaming есть вкладка Streaming для метрик и для просмотра пропускной способности приложения.В структурированном потоке это больше не доступно.Почему это?Намерено ли получить все показатели программно и передать их в отдельную службу мониторинга?

Вы правы.Причудливый интерфейс, который у вас был в структурированном потоке, еще не существует в SparkЯ задал Майкл Армбурст этот вопрос, и его ответ был «приоритеты», у них просто не было времени заняться созданием чего-то столь же фантастического, как у Spark Streaming, потому что они хотели втиснуть больше функций.OSS в том, что вы всегда можете внести недостающую часть самостоятельно, если вам это нужно.

В общем, структурированное потоковое вещание - это будущее Spark.В DStreams больше не вкладывается работа.Для систем с высокой пропускной способностью я могу сказать, что присоединение к структурированной потоковой передаче имеет существенное преимущество.Я переключился после того, как был выпущен 2.1, и это определенно повышение производительности, особенно в областях потоковых конвейеров с отслеживанием состояния.

Answer 2

TL; DR; Структурированная потоковая передача разработана с учетом различных целей, и, хотя мы склонны называть DStream «устаревшими», замены не существует.Сравнивать их несколько бессмысленно, поскольку по мере их развития они все больше расходятся с исходной моделью Spark.

DStreams можно использовать для реализации многих функций структурированной потоковой передачи (просто отметьте Apache Beam), но это далеко не тривиально.

В то же время различия повторяют то, что мы знаем из обсуждения RDD vs. DataFrame - вы получаете очень выразительный, оптимизированный и лаконичный APIценой универсальности и свободы (не все проблемы могут быть сформулированы в SQL-подобном API).

Кроме того, он все еще довольно новый и в основном экспериментальный, поэтому некоторые функции могут быть не реализованы пока что .

1. Будет ли это снижение производительности?Поскольку для этого потребуется 3 независимых соединения, управляемых вместо одного (подход DStream)

   В обычных условиях это улучшит производительность и, за исключением устаревших источников на основе приемника, не отличается от Kafka DStreams.

2. Я знаю, что объединение 2 потоковых наборов данных не поддерживается

   Существует широкий диапазон поддерживаемых потоковых соединений.См. Матрица поддержки для объединений в потоковых запросах .

3. n Структурированная потоковая передача больше не доступна.

   Spark UIпредоставляет широкий набор данных через пользовательский интерфейс.Отметьте только Мониторинг приложений структурированной потоковой передачи с использованием веб-интерфейса от Jacek Laskowski