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

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

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

Отказ от ответственности : я являюсь коммиттером 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 использует конвейерную передачу данных и пересылает записи сразу после их создания. Для эффективности эти записи собираются в буфере, который отправляется по сети после того, как он заполнится или будет достигнут определенный порог времени. Этот порог контролирует задержку записей, поскольку он определяет максимальное время, в течение которого запись будет оставаться в буфере без отправки в следующую задачу. Однако его нельзя использовать для предоставления жестких гарантий относительно времени, которое требуется для записи на вход и выход из программы, поскольку это также зависит от времени обработки в задачах и количества сетевых передач между прочим.

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

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

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

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

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

Основано на моем опыте Шторма и Флинка. Я чувствую, что эти инструменты могут решить одну и ту же проблему с разными подходами. Каждая черта Флинка упоминается @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.

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

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

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

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

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

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

Вывод

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

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