Хотя коммерческой поддержке Apache Flink еще предстоит набрать критическую массу, этот движок обещает заполнить пробел, оставленный другими потоковыми движками с открытым исходным кодом — добавить в ваше потоковое приложение повтор и откат.

Мы уже давно предсказывали, что потоковые движки ожидает светлое будущее. Почти пять лет назад мы заявили, что «тот же взрывообразный рост данных, который обусловил актуальность больших данных, порождает и спрос на превращение данных в основу для немедленных действий». А в начале текущего года мы декларировали, что «Интернет вещей (IoT) представляет ту область применения, которая выдвинет на передний план передачу потоков в реальном времени».

И точные прогнозы на этом не заканчиваются. Месяц назад мы присмотрелись к DataTorrent, компании, осуществляющей проект Apache Apex, который представляет собой применение визуальной IDE, чтобы сделать передачу потоков более доступной для разработчиков приложений.

Чтобы выслушать все стороны, давайте взглянем на Apache Flink. У нас состоялся интересный диалог с Костасом Тзума, генеральным директором компании data Artisans, разрабатывающей проект Flink, который представляет собой платформу для создания приложений на ее базе и управления ими.

Flink, в отличие от потоковых движков с открытым исходным кодом вроде Apex, Storm или Heron, осуществляет не только передачу потоков. Он больше напоминает Apache Spark наоборот. В обоих случаях один и тот же движок осуществляет передачу как в реальном времени, так и пакетами, избавляя от необходимости в архитектуре Lambda. У обоих имеются API-интерфейсы для запроса данных из таблиц и API-интерфейсы или библиотеки для обработки в реальном времени и пакетной обработки, а также имеются графы и машинное обучение.

Так чем же Flink отличается от Spark? Flink представляет собой вычислительный движок, созданный для передачи потоков и расширенный для передачи пакетов, тогда как Spark был создан для передачи пакетов и собственной версии — микропакетов (эта ситуация, в конце концов, изменится). В определенной мере эта метафора может быть применена к Storm (с его API-интерфейсом Trident), но у него отсутствуют библиотеки и поддержка таких важнейших функций, как строго однократная обработка событий (она, например, гарантирует, что событие будет обработано только однажды), а также имеются ограничения в отношении масштабирования.

После таких сопоставлений есть соблазн заявить применительно к обработке больших данных, что поезд Spark отправился в путь. Хотя сторонники Flink утверждают, что это один из пяти главных проектов Apache Big Data, у сообщества разработчиков Spark имеются сторонники, деятельность которых направлена на то, чтобы этот проект был признан номером 1. Кроме того, Spark получил поддержку коммерческих производителей. Он поддерживается практически всеми дистрибутивами Hadoop и основными облачными провайдерами. Растет и список имеющихся в Spark инструментов анализа и подготовки данных.

Так к чему эти разговоры? Если Spark имеет то преимущество, что первым вышел на рынок, то разработчики Flink сознательно не пытаются сделать его всем для всех. Они не нацеливаются на интерактивную аналитику или создание сложных моделей машинного обучения. И хотя Flink построен на базе потокового движка, анализ потоков не обязательно является для него главным.

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

При этом Flink нацеливается на функционал, который обычно резервируется за СУБД — поддержку приложений с запоминанием состояний. Приложения, размещаемые на Flink в качестве микросервисов, будут управлять состоянием. Для работающих в реальном времени приложений отказ от характерных для СУБД операций ввода-вывода сокращает задержки и накладные расходы. Идея не столь уж нова. В n-уровневых приложениях состояниями часто управляло написанное на Java ПО промежуточного слоя. А если еще больше углубиться в историю, то мониторы транзакций (предшественники серверов приложений) абстрагировали такую возможность от СУБД.

Тем не менее в эпоху, когда стали применяться быстрые СУБД, использующие хранение в оперативной памяти и на флэш-массивах, остается ряд известных областей обработки в реальном времени, в которых по-прежнему может иметь значение вынесение сохранения состояний за пределы СУБД. Примерами могут служить управление сетями IoT, отражение актуального состояния сделок, заключаемых посредством электронной коммерции, выдача рекомендаций в реальном времени, резервирование билетов и управление подключенными к Интернету автомобилями. Это не означает, что Flink заменит СУБД, поскольку данные (или выжимка из них) могут, в конечном итоге, сохраняться. Различие в том, что ключевая операция обработки некоторых транзакций реального времени (но не тех, которые требуют полной поддержки ACID) производится прежде, чем данные попадут в СУБД.

Хотя коммерческая поддержка Flink остается делом будущего, наличие более чем 12 тыс. сторонников по всему миру свидетельствует о начале формирования массовой опоры. Компании MapR и data Artisans составили превосходное подробное введение в Apache Flink, которое можно загрузить бесплатно. И даже если мы думали, будто Spark решил проблему сочетания обработки в реальном времени с пакетной обработкой, проект Apache Beam, реализованный в сервисе Google Cloud Dataflow, заставляет возобновить дискуссию, предоставляя среду для работы с находящимися в движении данными, в которой можно менять движки обработки данных в реальном времени по своему выбору.