Чем Apache Beam отличается от Apache Flink, что и когда выбирать, зачем их совмещать для реализации сложных конвейеров обработки больших объемов данных с помощью распределенных stateful-приложений, и как это работает.
Сходства и отличия Apache Beam и Flink
Хотя Apache Beam является унифицированной моделью определения пакетных и потоковых конвейеров параллельной обработки данных, которую можно запустить в любой среде исполнения (Flink, Spark, AirFlow и пр.), используя соответствующий движок (Runner), интересно сравнить эту абстракцию с самим нативным фреймворком. Сегодня рассмотрим, что общего у Apache Beam с Apache Flink, и чем они отличаются.
Прежде всего, и Flink и Beam позиционируются как универсальные фреймворки создания пакетных и потоковых конвейеров распределенной обработки больших объемов данных. Они оба поддерживают оконные операции и концепцию водяных знаков для работы с непоследовательными событиями в потоках. Оконные операции позволяют группировать потоковые данные в фиксированные интервалы времени (окна) для последующей обработки, такой как агрегация или вычисление статистик. Водяные знаки (watermarks) используются для отслеживания прогресса времени в потоковых данных, особенно когда события могут приходить с задержкой или в нерегулярном порядке. Водяные знаки помогают системе определить, когда можно безопасно закрыть окно и выдать результат, учитывая возможные опоздания данных.
Несмотря на мощную поддержку обоих концепций во Flink и Beam, детали их реализации существенно различаются:
- Beam позволяет пользователям создавать индивидуальные методы создания окон, а также обрабатывать данные, которые приходят в потоке не в хронологическом порядке. Это достигается за счёт механизмов обработки и возможности изменения результатов после завершения окна. Это делает его удобным для различных сценариев. Beam способна эффективно обрабатывать события
- Flink тоже допускает пользовательские методы окон, но его методы маркировки более жесткие и не обрабатывает опоздавшие данные так же эффективно. При приходе опоздавших событий Flink может либо игнорировать их, либо обрабатывать с дополнительными накладными расходами, что делает его менее эффективным в сценариях с высокой степенью несогласованности. Но Flink обеспечивает высокую производительность и строгий контроль над водяными знаками, что важно для систем, требующих предсказуемости и эффективности.
Таким образом, Apache Beam лучше подходит для сценариев, где требуется высокая гибкость в обработке событий, особенно когда данные могут приходить с большими задержками. Flink предпочтителен в случаях, где важна высокая производительность и низкая задержка обработки, и когда поток данных более предсказуем.
Flink имеет встроенные механизмы защиты и согласованности данных благодаря механизму контрольных точек и точек сохранения на основе распределенных моментальных снимков. Это повышает его надежность приложений, созданных с помощью этого фреймворка. В Beam целостность данных обеспечивается исполнительным механизмом (Runner), который отвечает за реализацию конвейера в указанной операционной среде.
Если сравнивать производительность Flink и Beam, то первый работает намного быстрее, обеспечивая быстрый отклик на поступающие данные. Это достигается благодаря следующим факторам:
- Beam добавляет дополнительный уровень абстракции поверх выбранного движка исполнения. Хотя это повышает гибкость и переносимость, возникают некоторые накладные расходы, снижая общую производительность по сравнению с непосредственным использованием Flink.
- Нативная оптимизация Flink позволяет более эффективно использовать ресурсы и управлять состоянием обработки данных.
- Зависимость от среды исполнения. Поскольку Beam зависит от выбранного движка, выбранный Runner может не оптимально подходить для решаемой задачи, что снижает производительность. Кроме того, в некоторых сценариях Beam может неэффективен из-за необходимости поддерживать совместимость с различными средами выполнения, тогда как быстрая работа Flink достигается благодаря его специфическим особенностям.
Таким образом, Flink – отличный выбор для разработки распределенных stateful-приложений со сложной логикой обработки больших объемов потоковых данных, где надо хранить и управлять большим количеством состояний, например, для рекомендационных систем. Также Flink подходит для случаев, когда требуется мгновенная обработка данных с минимальными задержками, например, мониторинг в реальном времени с точными временными окнами, обнаружение мошенничества.
В свою очередь, Apache Beam позволяет вести многоплатформенную разработку, когда нужна совместимость конвейеров обработки данных с разными движками выполнения. Унифицированная модель дает возможность писать одно решение для как потоковой, так и пакетной обработки данных. Это полезно в Agile-проектах с микросервисной архитектурой и широким стеком, где возможны изменения в инфраструктуре и требованиях. Кроме того, Beam дает некоторую однородность разработки, предоставляя для разных команд, работающих с различными фреймворками, единый API и набор возможностей. Однако, высокоуровневая модель Beam может упростить разработку, но имеет риск накладных расходов и снижения производительности.
Впрочем, если Beam используется с исполнительным движком Flink, его производительность обычно сопоставима с нативным использованием этого мощного фреймворка. Более того, модель выполнения, а также API Apache Beam, схожи с Flink. Как и Flink, Beam разработан для параллельной распределенной обработки данных. Оба имеют схожие преобразования, поддержку окон, событий/времени обработки, водяных знаков, таймеров, триггеров и многого другого. Однако Beam, не являясь полноценной средой выполнения, фокусируется на предоставлении фреймворка для создания переносимых многоязычных пакетных и потоковых конвейеров обработки, чтобы их можно было запускать на нескольких механизмах выполнения. Одним из них является сам Flink в виде Flink Runner, о котором мы поговорим далее.
Как работает Flink Runner в Beam
Сегодня выделяют два варианта Flink Runner:
- классический, который поддерживает только Java и другие языки на основе JVM, например, Scala, Kotlin и пр.;
- портативный, поддерживающий Python и Go, помимо Java;
Поскольку SDK Python и Go были добавлены позже, архитектуру движков пришлось изменить для поддержки выполнения конвейеров, написанных на языках, отличных от Java. Поэтому, для запуска Python-конвейера Beam на Flink, нужно использовать портативный Runner. Впрочем, оба варианта имеют два пути трансляции, в зависимости от пакетного или потокового режима обработки данных. Пакетные Beam-конвейеры Flink Runner транслирует в операции DataSet, а потоковые – в DataStream API. Соответственно, классический Flink Runner выполняет пакетные или потоковые конвейеры Java, а портативный выполняет Java, а также Python, Go и другие поддерживаемые конвейеры SDK. Пример того, как это может выглядеть на Python я показывала здесь, а в этой статье приведен вариант с использованием YAML API.
Для выполнения Beam-конвейера с помощью Apache Flink Runner можно выбрать режим выполнения кластера (YARN, Kubernetes, Mesos) или режим локального встроенного выполнения, который полезен для тестирования конвейеров.
В любом случае, Flink Runner в Beam транслирует Beam-конвейеры в задания Flink. Такую трансляцию можно параметризовать с помощью опций конвейера, например, чтобы указать имя задания Flink, параллелизм, контрольные точки и отчетов по метрикам. Будучи единственным результатом преобразований, параллельная коллекция PCollection в Beam подобна структуре данных DataSet/DataStream во Flink. Сами конвейеры Beam состоят из преобразований, которые подобны операторам Flink. Они бывают двух видов: примитивные и составные.
Конвейер Beam представлен в виде графа, который состоит из вышеупомянутых составных и примитивных преобразований. Beam предоставляет трансляторы, которые обходят граф в топологическом порядке. Топологический порядок означает начало обхода со всех источников при движении по графу. Flink Runner генерирует вызовы API, как это обычно работает при написании задания Flink.
Flink работает с сериализованными данными, представленными в виде байтов. Это делается с помощью сериализаторов. У Flink есть система типов для создания экземпляра правильного кодировщика для заданного типа, например, StringTypeSerializer для строк. У Apache Beam также есть своя собственная система типов, которая похожа на Flink. Но она использует немного другие интерфейсы. Сериализаторы в Beam называются кодировщиками. Чтобы заставить Beam Coder работать в Flink, два типа сериализаторов должны быть совместимыми. Это делается путем создания специальной информации о типе Flink, которая выглядит так же, как в Flink, но вызывает соответствующий кодировщик Beam. Таким образом, кодировщики Beam помогают выполнять конвейер с помощью Flink. Операторы Flink ожидают соответствующего TypeInformation, например, StringTypeInformation, для которого применяется CoderTypeInformation в Beam. Информация о типе возвращает сериализатор, для которого возвращается CoderTypeSerializer, вызывающий базовый Beam Coder.
Портативный Flink Runner в Beam имеет общий формат конвейера для всех языков программирования: Runner API, а также API Fn – общий runtime-интерфейс для связи между Runner и кодом, написанным на любом языке. Runner API предоставляет универсальное представление конвейера в формате Protobuf, который содержит встроенную схему данных, преобразования, типы и пользовательский код. Кроме того, для работы с Protobuf есть библиотеки в каждом языке программирования. Пример подобного конвейера мы разберем в следующий раз.
В заключение отметим, что Flink Runner объединяет мощность Flink с гибкостью Beam, позволяя выполнять унифицированнную модель конвейера потоковой и пакетной обработки данных в высокоэффективной среде выполнения с минимальными задержками.
Узнайте больше про Apache Flink и Beam на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Потоковая обработка данных с помощью Apache Flink
- Модели и паттерны управления приложениями распределенной обработки данных на Kubernetes
Источники
