В чем заключается основное различие между Flink и Storm?


137

Flink сравнивают со Spark , что, на мой взгляд, является неправильным сравнением, поскольку сравнивает оконную систему обработки событий с микропакетами; Точно так же мне не имеет смысла сравнивать Флинка с Самзой. В обоих случаях он сравнивает стратегию обработки событий в реальном времени и пакетную, даже если в меньшем «масштабе» в случае Samza. Но я хотел бы знать, как Flink сравнивается со Storm, который концептуально гораздо больше похож на него.

Я нашел это (слайд № 4), документирующее основное отличие как «регулируемое время ожидания» для Flink. Другой намек, похоже, на статью Slicon Angle, в которой говорится, что Flink лучше интегрируется в мир Spark или HadoopMR, но никакие реальные детали не упоминаются и не упоминаются. Наконец, сам Фабиан Хуеске отмечает в своем интервью, что «по сравнению с Apache Storm, функциональность потокового анализа Flink предлагает высокоуровневый API и использует более легкую стратегию отказоустойчивости для обеспечения точно однократных гарантий обработки».

Все это немного скудно для меня, и я не совсем понимаю суть. Может кто-нибудь объяснить, что проблема (и?) С потоковой обработкой в ​​Storm (есть?) Точно решена с помощью Flink? На что ссылается Hueske в вопросах API и их «более легкой стратегии отказоустойчивости»?


2
Обратите внимание, что Apache Spark (фокус связанного вопроса) - это не то же самое, что Apache Storm (этот вопрос здесь) - так что нет, это ни в коем случае не дубликат.
фн

Ответы:


213

Отказ от ответственности : я являюсь коммиттером Apache Flink и членом PMC и знаком только с высокоуровневым дизайном Storm, а не с его внутренними компонентами.

Apache Flink - это платформа для унифицированной потоковой и пакетной обработки. Среда выполнения Flink изначально поддерживает оба домена благодаря конвейерной передаче данных между параллельными задачами, которая включает конвейерные тасования. Записи немедленно отправляются от создания задач к получению задач (после сбора в буфере для передачи по сети). Пакетные задания могут быть дополнительно выполнены с использованием блокирования передачи данных.

Apache Spark - это фреймворк, который также поддерживает пакетную и потоковую обработку. Пакетный API Flink выглядит довольно схожим и обращается к тем же сценариям использования, что и Spark, но отличается по внутренним параметрам. Для потоковой передачи обе системы следуют совершенно разным подходам (мини-пакеты против потоковой передачи), что делает их пригодными для различных видов приложений. Я бы сказал, что сравнение Spark и Flink является действительным и полезным, однако Spark не является наиболее похожим механизмом потоковой обработки для Flink.

Возвращаясь к первоначальному вопросу, Apache Storm - это процессор потоков данных без пакетных возможностей. На самом деле конвейерный движок Flink выглядит немного похожим на Storm, т. Е. Интерфейсы параллельных задач Flink похожи на болты Storm. Общее у Storm и Flink то, что они нацелены на обработку потоков с малой задержкой путем конвейерной передачи данных. Однако Flink предлагает более высокоуровневый API по сравнению со Storm. Вместо реализации функциональности болтов с одним или несколькими считывателями и сборщиками, API-интерфейс Flink DataStream предоставляет такие функции, как Map, GroupBy, Window и Join. Многие из этих функций должны быть реализованы вручную при использовании Storm. Еще одно отличие - обработка семантики. Storm гарантирует обработку как минимум один раз, а Flink - только один раз. Реализации, которые дают эти гарантии обработки, немного отличаются. В то время как Storm использует подтверждения на уровне записей, Flink использует вариант алгоритма Ченди-Лампорта. Короче говоря, источники данных периодически вводят маркеры в поток данных. Всякий раз, когда оператор получает такой маркер, он проверяет свое внутреннее состояние. Когда маркер был получен всеми приемниками данных, маркер (и все записи, которые были обработаны ранее) фиксируются. В случае сбоя все операторы источников сбрасываются в свое состояние, когда они увидели последний зафиксированный маркер, и обработка продолжается. Этот подход с использованием маркеров и контрольных точек является более легким, чем подтверждения уровня записи Storm. это источники данных периодически вводят маркеры в поток данных. Всякий раз, когда оператор получает такой маркер, он проверяет свое внутреннее состояние. Когда маркер был получен всеми приемниками данных, маркер (и все записи, которые были обработаны ранее) фиксируются. В случае сбоя все операторы источников сбрасываются в свое состояние, когда они увидели последний зафиксированный маркер, и обработка продолжается. Этот подход с использованием маркеров и контрольных точек является более легким, чем подтверждения уровня записи Storm. это источники данных периодически вводят маркеры в поток данных. Всякий раз, когда оператор получает такой маркер, он проверяет свое внутреннее состояние. Когда маркер был получен всеми приемниками данных, маркер (и все записи, которые были обработаны ранее) фиксируются. В случае сбоя все операторы источников сбрасываются в свое состояние, когда они увидели последний зафиксированный маркер, и обработка продолжается. Этот подход с использованием маркеров и контрольных точек является более легким, чем подтверждения уровня записи Storm. это все операторы источников возвращаются в свое состояние, когда они увидели последний зафиксированный маркер и обработка продолжается. Этот подход с использованием маркеров и контрольных точек является более легким, чем подтверждения уровня записи Storm. это все операторы источников возвращаются в свое состояние, когда они увидели последний зафиксированный маркер и обработка продолжается. Этот подход с использованием маркеров и контрольных точек является более легким, чем подтверждения уровня записи Storm. этонабор слайдов и соответствующий доклад обсуждают подход потоковой обработки Flink, включая отказоустойчивость, контрольные точки и обработку состояний.

Storm также предлагает высокоуровневый API высокого уровня под названием Trident. Тем не менее, Trident основан на мини-пакетах и, следовательно, больше похож на Spark, чем Flink.

Регулируемая задержка Flink относится к тому, как Flink отправляет записи из одной задачи в другую. Я уже говорил, что Flink использует конвейерную передачу данных и пересылает записи сразу после их создания. Для эффективности эти записи собираются в буфере, который отправляется по сети после того, как он заполнится или будет достигнут определенный порог времени. Этот порог контролирует задержку записей, поскольку он определяет максимальное время, в течение которого запись будет оставаться в буфере без отправки в следующую задачу. Однако его нельзя использовать для предоставления жестких гарантий относительно времени, которое требуется для записи на вход и выход из программы, поскольку это также зависит от времени обработки в задачах и количества сетевых передач между прочим.


2
Спасибо Вам большое! Может быть, одна открытая точка, если я еще раз побеспокою вас: в чем проблема «регулируемой задержки»? Кажется, что это может быть довольно актуально, учитывая, что разные домены приложений будут иметь разные требования в этом отношении. Можете ли вы объяснить, что это означает, по крайней мере, с точки зрения Флинк?
ФНЛ

6
Конечно, я расширил свой ответ и обсудил регулируемую задержку. Дайте мне знать, если у вас есть дополнительные вопросы.
Фабиан Хуеске

Позволяет ли Flink вносить «горячие» изменения в рабочий процесс DAG, как это можно реализовать, например, с помощью Erlang? IE. Можно ли изменить DAG во время выполнения?
Томас Браун

1
Горячая замена кода невозможна. Однако вы можете сохранить состояние приложения в качестве точки сохранения. Точка сохранения может быть использована для запуска измененного приложения. Это можно сделать, пока оригинальное приложение еще работает, так что вывод может быть перевернут в какой-то момент. Обратите внимание, что приложения не могут быть произвольно изменены при выходе из существующей точки сохранения.
Фабиан Хуеске

1
Интересным и огромным преимуществом Flink является возможность запуска Apache Beam с еще более высоким уровнем API. Это один из самых богатых и законченных раннеров для Beam.
Петр Гвязда

47

Добавляем к ответу Фабиана Гуэске:

Flink улучшает Storm дополнительно также следующими способами:

  • Противодавление: потоковая среда выполнения Flink хорошо себя ведет, когда разные операторы работают на разных скоростях, потому что последующие операторы противодействуют восходящим операторам очень хорошо, хотя сетевой уровень управляет буферными пулами.

  • Пользовательское состояние: Flink позволяет программам поддерживать пользовательское состояние в ваших операторах. Это состояние может фактически участвовать в контрольной точке на предмет отказоустойчивости, предоставляя точно однократные гарантии для пользовательского состояния, определенного пользователем. Посмотрите этот пример пользовательского конечного автомата внутри оператора, который последовательно проверяется вместе с потоком данных.

  • Потоковая передача Windows: потоковая обработка окон и агрегация окон являются важным строительным блоком для анализа потоков данных. Flink поставляется с довольно мощной системой управления окнами, которая поддерживает многие типы окон.


2
Что касается вашего первого замечания, Storm хорошо себя ведет под противодавлением по состоянию на 1.0 (выпущен в апреле 2016 г.)
Колин Николс

Противодействие шторму можно уменьшить с помощью свойства spout_max_pending. Он устанавливает пороговое значение для максимальных кортежей, которые могут присутствовать в носике, ожидающих подтверждения. Носик больше не будет потреблять кортежи, пока не произойдет подтверждение.
Аман

3

Основано на моем опыте Шторма и Флинка. Я чувствую, что эти инструменты могут решить одну и ту же проблему с разными подходами. Каждая черта Флинка упоминается @Stephan Ивно может соответствовать Буре с внутренним API (т.е. spolts и болтами ) и Trident API в настоящее время. Кто-то утверждает, что Trident является мини-пакетным стилем, хотя я думаю, что большинство сложных приложений, связанных с состоянием или агрегацией, могут зависеть только от пакетной обработки со стилем окна. Поэтому я просто перечисляю некоторые основные отличия, не говоря, что лучше.

  • Разработка стиля . ориентированный на вычисления (например, цепочечный оператор) в Flink против потока данных (например, addSpolt()/addBolt()) в Storm.
  • API высокого уровня . Функции (например, «Карта», «Окно», «Объединить на уровне потоковой передачи») в Flink vs. Native Window и Trident в Storm.
  • Гарантированная обработка сообщений (GMP. Т. Е. Точно-один раз ) . Контрольная точка с двухфазным соединителем фиксации (например, KafkaConsumer) в Flink vs. Tuple-tree с внешним конечным автоматом или Trident в Storm.
  • Отказоустойчивость . Маркер-контрольная точка во Flink против рекордного уровня ACK в Storm.
  • Внутренняя архитектура . Простая абстракция и относительный параллелизм (например, слот для каждого потока, рассматриваемого с ядрами ЦП) в Flink против многоуровневых абстракций (например, слот для каждой JVM в качестве рабочего в супервизоре и у каждого супервизора может быть много рабочих) в Storm.

3

Отказ от ответственности: я сотрудник Cloudera, крупный сторонник Storm и (скоро) Flink.

функциональная

Много хороших технических моментов уже было представлено. Очень краткое резюме основных моментов:

  • И Flink, и Storm могут выполнять обработку для каждого события
  • Storm не поддерживает время события из коробки
  • Storm не поднял поддержку SQL из экспериментальной стадии

Нефункциональные

  • Многие клиенты находят Storm (слишком) сложным в использовании
  • Принятие Storm замедлилось, и сообщество Flink теперь, кажется, более активно, чем Storm
  • Флинк все еще должен наверстать упущенное (например, документированные примеры), но в целом он догнал почти во всех областях, о которых вы могли подумать

Вывод

Cloudera недавно объявила об устаревании Storm (в HDP). И одновременно Flink был объявлен своим преемником.

Так что, если у вас есть случаи использования шторма, они, конечно, будут продолжать работать. Но для новых случаев использования я хотел бы взглянуть на Flink или другие потоковые движки.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.