Apache NiFi 1.19: что нового?

Apache NiFi администрирование дата-инженерия новый релиз примеры курсы обучение, Apache NiFi курсы примеры обучение, курсы дата-инженеров, обучение инженеров данных, обучение большим данным, Школа Больших Данных Учебный Центр Коммерсант

Недавно мы писали про Apache NiFi 1.18. А 28 ноября опубликован новый выпуск — 1.19.0 и спустя немного времени первый баг-фикс к нему. Разбираемся с новинками свежего релиза самого популярного потокового ETL-маршрутизатора: новые процессоры, исправления ошибок и улучшения, о которых следует знать дата-инженеру и администратору кластера.

Главные новости Apache NiFi 1.19

В Apache NiFi 1.19.0 исправлено около 100 ошибок и внесено несколько десятков улучшений, а также новые фичи, ключевыми из которых можно назвать следующие:

  • обновление рекомендуемой версии Java до 11.0.16 или выше. Хотя Java 8 продолжает работать для всех версий NiFi 1.x, в релизе 2.x, поддержки Java 8 больше не будет;
  • реализован новый процессор для передачи данных в Apache Iceberg под названием PutIceberg;
  • представлен новый процессор PutSnowflake для помещения данных в Snowflake с помощью Snowpipe Ingest;
  • добавлен новый процессор UpdateDatabaseTable, который полезен в случаях, когда схема данных развивается, а резервные таблицы пишутся так, что требуются изменения DDL-запросов, чтобы приспособиться к ним, чтобы потоковые данные продолжали поступать и обрабатываться;
  • добавлены новые компоненты для обработки JSON-структур (процессор ValidateJSON, преобразователь с использованием с использованием JSLT), а также создан новый метод языка выражений isJson, чтобы определить, является ли атрибут JSON;
  • добавлена поддержка наборов шифров TLS в реестре NiFi и служба контроллера закрытых ключей;
  • процессор Consume Kafka Record теперь позволяет записывать ключ каждого сообщения, что пригодится для получения потоков данных из Apache Kafka;
  • Docker-образы теперь используют Java 11 и поддерживают платформы ARM64 в дополнение к AMD64 (aarch64/x86_64), включая компьютеры Apple Silicon Mac с процессорами M1/M2;
  • обновлены многочисленные зависимости для проблем с уязвимостями безопасности, таких как Apache Commons Text, производительность, функциональность и стабильность API, как в случае с Apache Iceberg 1.0;
  • исправлены многочисленные исправления ошибок, связанные с MergeContent, Stateless NiFi, ListenSyslog и многими другими компонентами;
  • в пользовательский интерфейс добавлена возможность фильтрации сводных таблиц. Это позволяет дата-инженеру в сводной таблице использовать раскрывающийся список фильтров для фильтрации процессоров по состоянию, чтобы, например, посмотреть только запущенные компоненты и флажок фильтрации для отображения только процессоров, настроенных для работы на основном узле.

Рассмотрим более подробно новые процессоры. В частности, процессор ValidateJSON гарантирует, что содержимое не будет изменено, а только маршрутизировано. Напомним, ранее существовавший процессор ValidateRecord перезаписывает содержимое. Однако, спецификация схемы JSON предоставляет несколько удобных функций, которые не поддерживают схемы AVRO, например, значения сопоставления с образцом. Поскольку NiFi имеет процессор ValidateXml для валидации входящих XML-файлов по схеме данных, целесообразно иметь аналогичный компонент для валидации JSON-сообщений, что и было реализовано в выпуске 1.19.0 с помощью процессора ValidateJSON. Также добавлен автономный процессор, который читает JSON, убеждается, что это допустимое сообщение, а затем перенаправляет потоковый файл на успешное или неудачное отношение по результатам проверки.

Реализован процессор PutSnowflake, ориентированный на запись, для передачи данных в Snowflake, используя подход Snowpipe вместо JDBC. А процессор PutIceberg позволяет принимать данные в таблицы Apache Iceberg.

Также полезна новая функция повышения информационной безопасности: служба контроллера, обеспечивающая абстрактный доступ к закрытым ключам. Она реализована для поддержки процессоров и служб, которым требуются криптографические закрытые ключи. Служба поддерживает возврат экземпляров java.security.PrivateKey и способна считывать зашифрованные или незашифрованные закрытые ключи, закодированные с использованием формата PEM и структурированные с использованием PKCS 8. Формат PEM представляет материал ключа, закодированный с использованием Base64, поэтому служба может настраиваться с использованием либо пути к файлу, либо конфиденциального свойства, где ключ может быть указан как значение свойства. Поскольку java.security.PrivateKey является частью стандартного JDK, этот сервисный интерфейс подходит для включения в nifi-standard-services-api-nar, что также позволяет использовать пользовательские реализации из других источников.

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

Чтобы исправить это, в процессоры ConsumeKafkaRecord было добавлено новое свойство стратегия вывода (Output Strategy), которое по умолчанию принимает значение записи (Write Value Only) для обеспечения обратной совместимости. Если задана стратегия Use Wrapper, то записи должны быть заключены в элемент-оболочку, содержащий 4 ключа: ключ сообщения Kafka, его значение, поле типа Map со строками в качестве ключей и значений и метаданные (топик, раздел, смещение, отметка времени и контрольная сумма). При задании стратегии вывода Use Wrapper следует указать формат ключа, т.е. его допустимые значения (строка, массив байтов, запись) и считывать записи ключа (Key Record Reader). Если Key Format = «Record», должно быть разрешено указать Record Reader для ключа.

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

  • заголовки для добавления в качестве атрибутов (регулярные выражения);
  • кодирование ключевых атрибутов.

Больше подробностей по администрированию и эксплуатации Apache NiFi  для построения эффективных ETL-конвейеров потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.19.0
  2. https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352345
  3. https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12352626

Поиск по сайту