Spark Streaming с S3 против Kinesis - PullRequest
Новая
       27

Spark Streaming с S3 против Kinesis

0 голосов
/ 25 июня 2018

Я пишу приложение Spark Streaming, в котором входные данные помещаются в корзину S3 небольшими партиями (используя Database Migration Service - DMS).Приложение Spark является единственным потребителем.Я рассматриваю две возможные архитектуры:

  1. Пусть Spark Streaming наблюдает за префиксом S3 и выбирает новые объекты по мере их поступления
  2. Потоковые данные из S3 в поток Kinesis (черезЛямбда-функция запускается, когда DMS создает новые объекты S3) и использует поток в качестве входных данных для приложения Spark.

Хотя второе решение будет работать, первое решение проще.Но есть ли подводные камни?Глядя на это руководство , я обеспокоен двумя конкретными моментами:

Чем больше файлов в каталоге, тем больше времени потребуется для поиска изменений - даже если файлов нетбыли изменены.

Мы будем хранить данные S3 в течение неопределенного времени.Таким образом, число объектов под отслеживаемым префиксом будет увеличиваться очень быстро.

«Полные» файловые системы, такие как HDFS, обычно устанавливают время изменения в своих файлах, как только создается выходной поток,Когда файл открывается, даже до того, как данные полностью записаны, они могут быть включены в DStream - после чего обновления файла в том же окне будут игнорироваться.То есть: изменения могут быть пропущены, а данные пропущены в потоке.

Я не уверен, относится ли это к S3, поскольку, как я понимаю, объекты создаются атомарно и не могут быть впоследствии обновлены, как есть.случай с обычными файлами.

1 Ответ

0 голосов
/ 05 июля 2018

Я разместил это в списке рассылки Spark и получил хороший ответ от Стива Лафрана.

Здесь чуть более оптимизированный источник потоковой передачи для облачных потоков

https://github.com/hortonworks-spark/cloud-integration/blob/master/spark-cloud-integration/src/main/scala/org/apache/spark/streaming/hortonworks/CloudInputDStream.scala

Несмотря на это, стоимость сканирования S3 составляет один запрос LIST на 5000 объектов;Я оставлю вам решать, сколько будет в вашем приложении - и сколько это будет стоить.И, конечно же, чем больше вызовов LIST, чем больше времени занимает, тем больше должно быть ваше окно.

«Полные» файловые системы, такие как HDFS, обычно устанавливают время изменения в своих файлах каккак только будет создан выходной поток.Когда файл открывается, даже до того, как данные полностью записаны, они могут быть включены в DStream - после чего обновления файла в том же окне будут игнорироваться.То есть: изменения могут быть пропущены, а данные пропущены в потоке.

Объекты, записанные в S3, не видны до завершения загрузки в элементарной операции.Вы можете писать на месте и не беспокоиться.

Временная метка для артефактов S3 исходит из PUT tim.При многоэтапной загрузке из многих загрузок в МБ / много ГБ начинается первая запись, инициирующая MPU.Таким образом, если загрузка начинается во временном окне t1 и завершается в окне t2, объект не будет виден до t2, но отметка времени будет иметь значение t1.Имейте это в виду.

Лямбда-обратный вызов, вероятно, имеет лучшую масштабируемость и устойчивость;сам не пробовал.

Так как число объектов в моем сценарии будет намного больше 5000 и будет продолжать расти очень быстро, S3 to Spark кажется нереальным вариантом,Я рассматривал перемещение / переименование обработанных объектов в Spark Streaming, но код приложения Spark Streaming, похоже, получает только DStreams и никакой информации о том, из какого объекта S3 поступают данные.Так что я собираюсь пойти с опцией лямбда и кинезис.

...