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

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

За последние несколько месяцев мы видели всплеск новых разработок важнейших игроков в данной сфере, таких как Apache Kafka и Apache Spark. На сей раз пришел черед Apache Flink сделать ход, анонсировав не одну, а сразу две новые версии: 1.4, которая вышла 29 ноября, и 1.5, которая появится в начале 2018 г.

Почему такой несколько необычный график выпуска, каковы планы и как все это встраивается в общую картину? Мы обсудили это с членом управляющего комитета проекта Apache Flink и главным технологом dataArtisans Штефаном Эвеном.

Вливаясь в основной поток

Несколько месяцев назад мы уже писали о Flink, но с тех пор много воды утекло, и похоже, Flink, а также dataArtisans (dA) добиваются успеха. dA — это коммерческое предприятие, которое использует многих коммиттеров Flink и предоставляет связанные с Flink сервисы и продукты.

Для начала скажем, что Flink может предъявить несколько весьма крупных примеров использования, таких как Alibaba и Uber. Они не только дают повод похвалиться, но и представляют некоторый интерес с технической точки зрения. Кроме того, в процессе оформления находится удивительное потенциальное партнерство ни с кем иным как с Dell EMC, которое опять же представляет интерес для каждого, кто знаком с этой областью.

В любом случае какое-то время Alibaba была главным пользователем Flink. Отличие в том, что теперь Flink и Alibaba связаны теснее, чем когда-либо. Как и многие другие организации такого же размера, Alibaba использует множество частных технологий. Например, у Alibaba есть собственная реализация шины сообщений и своя среда развертывания.

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

Это знаковый крупный клиент, которым может гордиться любая платформа, и Flink не исключение. Flink сообщает некоторые детали, например, как платформа обеспечила проведение шопинг-фестиваля Single’s Day, который был назван крупнейшим в мире бумом покупок.

Когда речь идет о знаковых клиентах и открытом коде, на ум приходит также имя Uber. Эта компания решила сделать Flink основой своей недавно выпущенной Open Source-платформы для анализа потоков, которая называется AthenaX. Что касается природы этой платформы, то в интерпретации Эвена AthenaX — немногим больше, чем оболочка Flink с некоторыми дополнениями и системой показателей, отражающими потребности Uber.

Но никто кроме Uber не может знать истинных целей выпуска AthenaX. Эвен не рассматривает AthenaX как конкурента Flink, однако трудно привести вескую причину, почему Uber открывает исходный код чего-то, что подходит только Uber. Flink работает над тем, чтобы побудить Uber внести вклад в развитие ядра Flink, так что время покажет, возможен ли такой маловероятный итог.

А есть еще Dell EMC. Не в качестве клиента, заметьте, а как амбициозный конкурент. Немногие слышали до сих пор название Pravega, так что включение этого продукта в список новых функций Flink может удивить. Pravega — Open Source-проект, который утверждает, что «предоставляет новую абстрацию хранения — поток — для непрерывных и не связанных данных».

Как использует его Dell EMC? Хотя официального объявления до сих пор сделано не было, взгляд на команду Pravega не оставляет сомнений в том, откуда это идет. Эвен нашел несколько похвальных слов для Pravega, заявив, что это более чем интересная архитектура и что многое сделано правильно с точки зрения того, как следует сегодня создавать журнал очереди сообщений с учетом уроков, полученных благодаря Kafka.

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

Освоение SQL

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

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

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

Однако Flink — не единственная платформа для обработки потоков, поддерживающая SQL. Недавно Kafka добавила SQL в свой арсенал. Spark тоже включила новый подход под названием структурированная передача потоков. Как и следовало ожидать от конкурирующих решений, существует тест производительности и вокруг этого теста ведутся дискуссии.

Неудивительно, что результаты тестирования, которые опубликовала Spark, показывают, что Spark превосходит как Kafka, так и Flink. Эвен сказал, что тестирование «полностью нарушено, сравниваются яблоки с апельсинами. Это старый тест Yahoo, который производится в основном локально и пересылает по сети очень мало данных. Он отражает различия в фокусе двух проектов».

Он добавил, что «Flink ориентирован на надежное решение самых масштабных задач с хорошей производительностью и контрольными точками. Тест Spark использует 100 ключей, что представляет своего рода шутку, поскольку ни одна компания не применяет 100 показателей. Попробуйте провести его с 500 млн. ключей, и результаты будут весьма отличаться».

Что еще созрело для здорового антагонизма? Ну, стандарты, разумеется. Хотя в данном случае Apache Beam является не совсем стандартом. Он рассматривается как попытка унифицировать передачу потоков между платформами. Но не очень успешная. Apache Beam обязан своим происхождением модели Google DataFlow, однако в данный момент его полностью поддерживают только Google и Flink.

Команда Kafka заявила, что не считает его привлекательным и не испытывает интереса, пока в него не будет добавлена поддержка таблиц. Команда Spark сообщила, что он уже может использоваться, и каждый, кто хочет запускать его на Spark, вполне способен это делать. Но они не собираются выделять ресурсы для поддержки этого. Возможно, играют роль столкновение коммерческих интересов или различия во взглядах, но итог таков: Beam не получил всеобщего признания.

Прежде чем приступить к созданию Flink, сказал Эвен, он и его коллеги познакомились с DataFlow. Многие идеи им понравились и были использованы. Поэтому естественно, что Flink совместим с Beam. Beam критикуют, в частности, за сложность, с чем Эвен согласен. Но он сказал также, что другие модели не обладают такими возможностями, и вероятно сложность необходима для поддержки более совершенных сценариев. Кроме того, Beam работает по спецификации SQL для потоков, что опять же не должно вызывать удивления близостью к взглядам разработчиков Flink.

Освобождаясь от Hadoop

Последнее в списке, но не последнее по значимости. В Flink 1.4 и 1.5 имеется множество не столь ярких, но полезных функций. Однако прежде чем перейти к их описанию, ответим на очевидный вопрос: почему новых версий две? Эвен сказал, что так решено было сделать, потому что одни изменения будут революционными, а другие — нет. Революционные приберегли для версии 1.5, а остальные упаковали в версию 1.4.

Общий интерес вызывает то, что Flink избавляется от Hadoop. В версии 1.4 был полностью переработан механизм зависимостей, что позволило помимо прочего отказаться от зависимостей от HDFS и YARN при работе на AWS. Поскольку изменяются варианты развертывания (главным образом благодаря контейнерам — тому что Docker и Kubernetes завоевывают себе место на YARN и Mesos), Flink старается идти в ногу со временем.

По этой причине в версии 1.5 появятся некоторые революционные изменения, в основном касающиеся способа развертывания Flink на Kubernetes. Эвен признал, что это помешает использовать DevOps. Но по его словам, в средне- и долгосрочной перспективе это к лучшему, поскольку откроет более естественные и эффективные способы решения проблем, которые до настоящего времени решаются с трудом.

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

Развертывание и DevOps — важные темы для Flink. Эвен сказал, основываясь на опыте обслуживания клиентов, что основная часть времени уходит не на разработку логики приложения, а на то, чтобы все работало без сбоев.

Поэтому dA объединила пакет «гарантированно правильных (opinionated)» решений, как она их называет, для используемой в производственных целях Flink с исправлениями, соглашениями об уровне обслуживания и такими сервисами, как ведение журналов и измерение показателей. Это предлагается в качестве корпоративной версии Flink — платформы dA. В стадии бета-тестирования находится dA версии 2, которая станет коммерчески доступна в начале 2018 г.

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

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