Что является/является основным отличием между Flink и Storm?

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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