Управляемый сервис Amazon для Apache Flink теперь поддерживает Apache Flink версии 1.18 | Веб-сервисы Amazon

Apache Flink — это механизм распределенной обработки с открытым исходным кодом, предлагающий мощные программные интерфейсы как для потоковой, так и для пакетной обработки, с первоклассной поддержкой обработки с отслеживанием состояния и семантики времени событий. Apache Flink поддерживает несколько языков программирования: Java, Python, Scala, SQL и несколько API с разным уровнем абстракции, которые можно использовать как взаимозаменяемые в одном приложении.

Управляемый сервис Amazon для Apache Flink, который предлагает полностью управляемый бессерверный интерфейс для запуска приложений Apache Flink, теперь поддерживает Апач Флинк 1.18.1, последняя версия Apache Flink на момент написания.

В этом посте мы обсуждаем некоторые интересные новые функции и возможности Apache Flink, представленные в последних основных выпусках 1.16, 1.17 и 1.18 и теперь поддерживаемые в Managed Service для Apache Flink.

Новые разъемы

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

Открытый поиск

Специальная Открытый поиск соединитель теперь доступен для включения в ваши проекты, позволяя приложению Apache Flink записывать данные непосредственно в OpenSearch, не полагаясь на режим совместимости Elasticsearch. Этот разъем совместим с Сервис Amazon OpenSearch обеспечено и Бессерверная служба OpenSearch.

Этот новый разъем поддерживает API SQL и таблиц, работающий как с Java, так и с Python, а также API потока данных, только для Java. По умолчанию он предоставляет гарантии хотя бы один раз, синхронизируя записи с контрольной точкой Flink. Вы можете добиться семантики «точно один раз», используя детерминированные идентификаторы и метод upsert.

По умолчанию соединитель использует клиентские библиотеки OpenSearch версии 1.x. Вы можете перейти на версию 2.x, выполнив добавление правильных зависимостей.

Amazon DynamoDB

Разработчики Apache Flink теперь могут использовать специальный соединитель для записи данных в Amazon DynamoDB. Этот разъем основан на Apache Flink AsyncSink, разработанный AWS и теперь являющийся неотъемлемой частью проекта Apache Flink, для упрощения реализации эффективных соединителей приемников с использованием неблокирующих запросов на запись и адаптивной пакетной обработки.

Этот разъем также поддерживает оба SQL и таблица API, Java и Python, а также Поток данных API, только для Java. По умолчанию приемник записывает пакетно, чтобы оптимизировать пропускную способность. Примечательной особенностью версии SQL является поддержка предложения PARTITIONED BY. Указав один или несколько ключей, вы можете добиться некоторой дедупликации на стороне клиента, отправляя только последнюю запись для каждого ключа при каждой пакетной записи. Эквивалента можно добиться с помощью API DataStream, указав список ключей раздела для перезаписи внутри каждого пакета.

Этот разъем работает только как сток. Вы не можете использовать его для чтения из DynamoDB. Чтобы выполнить поиск данных в DynamoDB, вам все равно необходимо реализовать поиск с помощью API асинхронного ввода-вывода Flink или реализация пользовательской функции (UDF) для SQL.

MongoDB

Еще один интересный разъем предназначен для MongoDB. В этом случае доступны как источник, так и приемник, как для SQL и таблица API и Поток данных API. Новый соединитель теперь официально является частью проекта Apache Flink и поддерживается сообществом. Этот новый соединитель заменяет старый, предоставляемый непосредственно MongoDB, который поддерживает только старые API-интерфейсы Flink Sink и Source.

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

Среди многих примечательных особенностей этого соединителя стоит упомянуть возможность включения кэширования при использовании источника для поиска. В стандартной комплектации раковина поддерживает гарантию «хотя бы один раз». Когда определен первичный ключ, приемник может поддерживать семантику «точно один раз» посредством идемпотентных обновлений. Соединитель приемника также поддерживает семантику «точно один раз» с идемпотентными преобразованиями, когда определен первичный ключ.

Новое управление версиями соединителя

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

Чтобы включить правильную зависимость, вам необходимо указать версию артефакта в форме: <connector-version>-<flink-version>

Например, новейший коннектор Kafka, также работающий с Amazon Managed Streaming для Apache Kafka (Amazon MSK), на момент написания — версия 3.1.0. Если вы используете Apache Flink 1.18, используемая зависимость будет следующей:

<dependency> 
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kafka</artifactId> 
    <version>3.1.0-1.18</version>
</dependency>

Что касается Амазонка Кинезисновая версия соединителя — 4.2.0. Зависимость для Apache Flink 1.18 будет следующей:

<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kinesis</artifactId> 
    <version>4.2.0-1.18</version>
</dependency>

В следующих разделах мы обсудим новые мощные функции, которые теперь доступны в Apache Flink 1.18 и поддерживаются в Amazon Managed Service для Apache Flink.

SQL

В Apache Flink SQL пользователи могут предоставлять подсказки для объединения запросов, которые можно использовать, чтобы предложить оптимизатору повлиять на план запроса. В частности, в потоковых приложениях поисковые соединения используются для пополнения таблицы, представляющей потоковые данные, данными, запрашиваемыми из внешней системы, обычно из базы данных. Начиная с версии 1.16, в соединения поиска было внесено несколько улучшений, позволяющих настроить поведение соединения и повысить производительность:

Кэш поиска — это мощная функция, позволяющая кэшировать в памяти наиболее часто используемые записи, снижая нагрузку на базу данных. Раньше кэш поиска был специфичен для некоторых соединителей. Начиная с Apache Flink 1.16, эта опция стала доступна для всех соединителей, внутренне поддерживающих поиск (ФЛИП-221). На момент написания этой статьи JDBC, Hiveи HBase соединители поддерживают кэш поиска. Кэш поиска имеет три доступных режима: FULL, для небольшого набора данных, который может полностью храниться в памяти, PARTIALдля большого набора данных кэширование только самых последних записей или NONE, чтобы полностью отключить кеш. Для PARTIAL кэша, вы также можете настроить количество строк для буферизации и время жизни.
Асинхронный поиск это еще одна функция, которая может значительно улучшить производительность. Асинхронный поиск обеспечивает в Apache Flink SQL функциональность, аналогичную Асинхронный ввод-вывод доступен в API DataStream. Это позволяет Apache Flink отправлять новые запросы к базе данных, не блокируя поток обработки до тех пор, пока не будут получены ответы на предыдущие запросы. Как и в случае с асинхронным вводом-выводом, вы можете настроить асинхронный поиск, чтобы обеспечить упорядочение или разрешить неупорядоченные результаты, а также настроить емкость буфера и время ожидания.
Вы также можете настроить стратегия повтора поиска в сочетании с PARTIAL or NONE кэш поиска, чтобы настроить поведение в случае неудачного поиска во внешней базе данных.

Всем этим поведением можно управлять с помощью LOOKUP подсказка, как в следующем примере, где мы показываем соединение поиска с использованием асинхронного поиска:

SELECT 
    /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ 
    O.order_id, O.total, C.address
FROM Orders AS O 
JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C 
  ON O.customer_id = O.customer_id

ПиФлинк

В этом разделе мы обсуждаем новые улучшения и поддержку в PyFlink.

Поддержка Python 3.10

В последних версиях Apache Flink представлено несколько улучшений для пользователей PyFlink. Прежде всего, теперь поддерживается Python 3.10, а поддержка Python 3.6 полностью удалена (ФЛИНК-29421). Управляемая служба для Apache Flink в настоящее время использует среду выполнения Python 3.10 для запуска приложений PyFlink.

Приближаемся к равенству функций

С точки зрения API программирования PyFlink с каждой версией становится все ближе к Java. API DataStream теперь поддерживает такие функции, как побочные выходные данные и состояние широковещания, а пробелы в API управления окнами закрыты. PyFlink также теперь поддерживает новые соединители, такие как Потоки данных Amazon Kinesis непосредственно из API DataStream.

Улучшения режима потоков

PyFlink очень эффективен. Накладные расходы на запуск операторов Flink API в PyFlink минимальны по сравнению с Java или Scala, поскольку среда выполнения фактически запускает реализацию оператора непосредственно в JVM, независимо от языка вашего приложения. Но когда у вас есть пользовательская функция, все немного по-другому. Строка кода Python, такая же простая, как lambda x: x + 1или такая же сложная функция, как функция Pandas, должна выполняться в среде выполнения Python.

По умолчанию Apache Flink запускает среду выполнения Python в каждом диспетчере задач, вне JVM. Каждая запись сериализуется, передается в среду выполнения Python посредством межпроцессного взаимодействия, десериализуется и обрабатывается в среде выполнения Python. Затем результат сериализуется и возвращается в JVM, где он десериализуется. Это ПиФлинк Режим ПРОЦЕСС. Он очень стабилен, но требует дополнительных затрат, а в некоторых случаях может стать узким местом в производительности.

Начиная с версии 1.15, Apache Flink также поддерживает РЕЗЬБОВЫЙ режим для PyFlink. В этом режиме определяемые пользователем функции Python выполняются внутри самой JVM, устраняя накладные расходы на сериализацию/десериализацию и межпроцессное взаимодействие. Режим РЕЗЬБА имеет некоторые ограничения; например, режим THREAD нельзя использовать для Pandas или UDAF (определяемых пользователем агрегатных функций, состоящих из множества входных записей и одной выходной записи), но он может существенно повысить производительность приложения PyFlink.

В версии 1.16 поддержка режима THREAD была существенно расширена, включая API Python DataStream.

Режим THREAD поддерживается Managed Service для Apache Flink и может быть включен непосредственно из вашего приложения PyFlink.

Поддержка Apple Silicon

Если вы используете компьютеры на базе Apple Silicon для разработки приложений PyFlink, разрабатываемых для PyFlink 1.15, вы, вероятно, столкнулись с некоторыми известными проблемами зависимостей Python в Apple Silicon. Эти проблемы наконец-то решены(ФЛИНК-25188). Эти ограничения не повлияли на приложения PyFlink, работающие в управляемой службе для Apache Flink. До версии 1.16, если вы хотели разработать приложение PyFlink на машине с использованием чипсета M1, M2 или M3, вам приходилось использовать некоторые обходные, поскольку невозможно было установить PyFlink 1.15 или более раннюю версию непосредственно на машину.

Улучшения несогласованных контрольных точек

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

В версиях 1.16 и 1.17 было внесено несколько изменений для улучшения стабильности и производительности.

Обработка неравномерности данных

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

Однако использование водяных знаков сопряжено с трудностями. Если приложение имеет несколько источников (например, оно получает события из нескольких разделов темы Kafka), водяные знаки генерируются независимо для каждого раздела. Внутри каждый оператор всегда ожидает одного и того же водяного знака на всех входных разделах, практически выравнивая его по самому медленному разделу. Недостаток заключается в том, что если один из разделов не получает данные, водяные знаки не сохраняются, что увеличивает сквозную задержку. По этой причине дополнительный тайм-аут простоя был представлен во многих потоковых источниках. По истечении настроенного времени ожидания при создании водяных знаков игнорируются все разделы, не получающие никаких записей, и водяные знаки могут продолжать работать.

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

Чтобы решить проблему более быстрых источников, начиная с Apache Flink 1.17, вы можете включить выравнивание водяных знаков для разделения исходного кода (ФЛИНК-28853). Этот механизм, отключенный по умолчанию, гарантирует, что ни один из разделов не будет отображать водяные знаки слишком быстро по сравнению с другими разделами. Вы можете связать вместе несколько источников, например несколько входных тем, назначив один и тот же идентификатор группы выравнивания и настроив продолжительность максимального отклонения от текущего водяного знака. Если один конкретный раздел получает события слишком быстро, оператор источника приостанавливает обработку этого раздела до тех пор, пока отклонение не уменьшится ниже настроенного порога.

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

В следующем фрагменте кода показано, как можно настроить выравнивание водяных знаков для разделения исходного кода в источнике Kafka, испускающем водяные знаки ограниченного нарушения порядка:

KafkaSource<Event> kafkaSource = ...
DataStream<Event> stream = env.fromSource(
    kafkaSource,
    WatermarkStrategy.<Event>forBoundedOutOfOrderness( Duration.ofSeconds(20))
        .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)),
    "Kafka source"));

Эта функция доступна только с ФЛИП-217 совместимые источники, поддерживающие выравнивание водяных знаков при разделении источников. На момент написания статьи из основных коннекторов источников потоковой передачи только источник Kafka поддерживает эту функцию.

Прямая поддержка формата Protobuf.

API-интерфейсы SQL и Table теперь напрямую поддерживают Формат протобуфа. Чтобы использовать этот формат, вам необходимо сгенерировать классы Java Protobuf из файла .proto файлы определения схемы и включите их в качестве зависимостей в свое приложение.

Формат Protobuf работает только с API-интерфейсами SQL и Table и только для чтения или записи данных, сериализованных Protobuf, из источника или в приемник. В настоящее время Flink напрямую не поддерживает Protobuf для прямой сериализации состояния и не поддерживает эволюцию схемы, как это происходит для Avro, например. Вам еще нужно зарегистрировать пользовательский сериализатор с некоторыми накладными расходами для вашего приложения.

Сохранение открытого исходного кода Apache Flink

Apache Flink внутренне использует Akka для отправки данных между подзадачами. В 2022 году Lightbend, компания, стоящая за Akka, объявила об изменении лицензии для будущих версий Akka — от Apache 2.0 до более строгой лицензии, и что Akka 2.6, версия, используемая Apache Flink, не будет получать никаких дальнейших обновлений или исправлений безопасности.

Хотя Akka исторически была очень стабильной и не требовала частых обновлений, это изменение лицензии представляло риск для проекта Apache Flink. Решением сообщества Apache Flink было заменить Akka форком версии 2.6 под названием Апач Пекко (ФЛИНК-32468). Эта вилка сохранит лицензию Apache 2.0 и будет получать все необходимые обновления от сообщества. Тем временем сообщество Apache Flink рассмотрит вопрос о том, следует ли полностью удалить зависимость от Akka или Pekko.

Сжатие состояния

Apache Flink предлагает дополнительное сжатие (по умолчанию: выключено) для всех контрольных точек и точек сохранения. Apache Flink обнаружил ошибку в Flink 1.18.1, где состояние оператора не могло быть должным образом восстановлено при включенном сжатии снимков. Это может привести либо к потере данных, либо к невозможности восстановления с контрольной точки. Чтобы решить эту проблему, Managed Service for Apache Flink выполнил резервный порт фиксировать это будет включено в будущие версии Apache Flink.

Обновления версий на месте с помощью Managed Service для Apache Flink

Если вы в настоящее время запускаете приложение в управляемой службе для Apache Flink с использованием Apache Flink 1.15 или более ранней версии, теперь вы можете обновить его на месте до версии 1.18 без потери состояния, используя команду Интерфейс командной строки AWS (интерфейс командной строки AWS), AWS CloudFormation or Комплект для разработки облачных сервисов AWS (AWS CDK) или любой инструмент, использующий AWS API.

Ассоциация ОбновитьПриложение Действие API теперь поддерживает обновление версии среды выполнения Apache Flink существующего приложения Managed Service для Apache Flink. Вы можете использовать UpdateApplication непосредственно в работающем приложении.

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

Также мы рекомендуем протестировать обновленное приложение, прежде чем приступать к обновлению. Мы рекомендуем тестировать локально и в непроизводственной среде, используя целевую версию среды выполнения Apache Flink, чтобы убедиться в отсутствии регрессий.

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

Когда вы будете готовы, вы можете использовать ОбновитьПриложение действие API или приложение-обновление Команда AWS CLI для обновления версии приложения во время выполнения и указания ей нового артефакта приложения, JAR-файла или zip-файла с обновленными зависимостями.

Более подробную информацию о процессе и API см. Обновление версии на месте для Apache Flink. Документация включает пошаговые инструкции и видео, которые помогут вам пройти процесс обновления.

Выводы

В этом посте мы рассмотрели некоторые новые функции Apache Flink, поддерживаемые в управляемом сервисе Amazon для Apache Flink. Этот список не является исчерпывающим. Apache Flink также представил некоторые очень многообещающие функции, такие как TTL на уровне оператора для SQL и API таблиц [ФЛИП-292] и Путешествие во времени [ФЛИП-308], но они еще не поддерживаются API и пока не доступны пользователям. По этой причине мы решили не освещать их в этом посте.

Благодаря поддержке Apache Flink 1.18 управляемая служба для Apache Flink теперь поддерживает последнюю выпущенную версию Apache Flink. Мы увидели некоторые интересные новые функции и новые соединители, доступные в Apache Flink 1.18, а также то, как управляемая служба для Apache Flink помогает обновить существующее приложение на месте.

Более подробную информацию о последних выпусках можно найти в блоге Apache Flink и примечаниях к выпуску:

Если вы новичок в Apache Flink, мы рекомендуем наш руководство по выбору правильного API и языка и следуя руководство по началу работы чтобы начать использовать управляемую службу для Apache Flink.

Об авторах

Лоренцо Никора работает старшим архитектором решений потоковой передачи в AWS, помогая клиентам в регионе EMEA. Он занимается созданием облачных систем с интенсивным использованием данных более 25 лет, работая в финансовой отрасли как в качестве консультантов, так и в компаниях, производящих продукты FinTech. Он широко использовал технологии с открытым исходным кодом и участвовал в нескольких проектах, включая Apache Flink.

Франсиско Морилло — архитектор потоковых решений в AWS. Франциско работает с клиентами AWS, помогая им разрабатывать архитектуры аналитики в реальном времени с использованием сервисов AWS, поддерживая Amazon MSK и Amazon Managed Service для Apache Flink.

SEO-контент и PR-распределение. Получите усиление сегодня.
PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
Источник: https://aws.amazon.com/blogs/big-data/amazon-managed-service-for-apache-flink-now-supports-apache-flink-version-1-18/

Генеративный анализ данных

Amazon Managed Service для Apache Flink теперь поддерживает Apache Flink версии 1.18 | Веб-сервисы Amazon