Опубликованная впервые в 2016 году 1-ая версия Apache NiFi дополняется новыми минорными релизами, последним из которых стал 1.23.2, исправляющий ошибки предыдущих выпусков. Однако, в обозримом будущем ожидается мажорный релиз 2.0 со множеством новых возможностей. Разбираемся с его наиболее перспективными предложениями.
ТОП-10 целей Apache NiFi 2.0
Чтобы повысить безопасность, снизить сложность и внедрить новые функции, NiFi 2.0 сфокусирован на сокращении технического долга. Согласно принципам семантического управления версиями, мажорный выпуск предоставляет возможность внесения критических изменений, которые исключают обратную совместимость с предыдущими версиями. 15 декабря 2022 года комитет по управлению проектом Apache NiFi проголосовал за принятие следующих основных целей нового мажорного релиза:
- внедрить поддержку Java 11 вместо Java 8. В частности, для Jetty 10 требуется и OpenSAML 4 требуется Java 11. Поддержка Java 8 в Kafka 3 прекращена в сентябре 2021 года, а в Spring 6 – в ноябре 2022 г.
- удалить устаревшие компоненты и свойства компонентов, включая процессоры и службы контроллеров, помеченные как неподдерживаемые или замененные лучшими альтернативами. Удаление устаревших свойств компонента позволит сохранить существующие процессоры, устраняя при этом дублирующиеся параметры конфигурации. Например, свойства PGP в EncryptContent и связанные с ними возможности теперь реализованы в EncryptContentPGP и DecryptContentPGP, о чем мы писали здесь. Свойства Keytab непосредственно в процессорах, поддерживающих Kerberos, а KeytabCredentialService заменены на KerberosUserService.
- удалить компоненты, интегрирующиеся с необслуживаемыми сервисами и/или их устаревшими версиями без технической поддержки;
- удалить ненужные классы и методы, например, PersistentProvenanceRepository, Стандартный RecordWriter NiFiLegacyCipherProvider и связанные с ним методы шифрования supportExpressionLanguage() без аргументов, пользовательские классы InputStream и OutputStream.
- заменить представление внутренней конфигурации потока в файле flow.xml.gz на flow.json.gz. В NiFi 1.16.0 представлен flow.json.gz для хранения конфигурации потока с использованием классов модели версионных компонентов. Более простой JSON-формат снижает затраты на сохранение конфигурации и синхронизацию нескольких представлений и уже используется в NiFi, NiFi Stateless и NiFi Registry.
- удалить дублирующиеся функции и элементы, например, шаблоны XML, замененные JSON-представлениями и реестр переменных, замененный контекстом параметров;
- обновить внутренние ссылки на API Java — перенос внутреннего использования классов util.Date в java.time обеспечит большую точность анализа и форматирования. Это предполагает рефакторинг использования классов DateTimeFormatter и java.time в компонентах, ориентированных на записи.
- Реорганизация стандартных компонентов для уменьшения размера и объема процессоров и пакетов NAR Standard Services. Компоненты со специализированными зависимостями будут перемещены из стандартных процессоров (SFTP, HTTP, JSON, Netty) в отдельные пакеты.
- Внедрение инструментов миграции для обновления потоков, включая автоматическую миграцию для переназначения свойств и функций, преобразования шаблонов XML в определения потока JSON.
Важные возможности и ключевые изменения
В Apache NiFi 2.0 ожидается поддержка Python, что очень порадует многих дата-инженеров и разработчиков. Впрочем, использовать Python в этом ETL-фреймворке можно уже сейчас, о чем мы рассказываем в здесь. Также будет добавлена возможность запуска группы процессов с использованием NiFi Stateless – компонента, который обеспечивает механизм потока данных с меньшим масштабом и набором функций. Он не включает пользовательский интерфейс для создания или мониторинга потоков данных, а просто запускает потоки данных, созданные с помощью приложения NiFi. NiFi Stateless может хранить все данные в памяти или использовать дисковый репозиторий для содержимого FlowFile, чтобы избежать необходимости использования очень больших куч Java. Однако, данные не будут восстановлены после перезапуска, что и обусловливает название компонента – без сохранения состояния. Использование NiFi Stateless на уровне группы процессов позволит реализовать транзакционные сценарии потокового конвейера обработки данных, когда поток следует рассматривать как единую транзакцию. Это пригодится в случае захвата измененных данных (CDC, Change Data Capture). Подробнее о принципах работы Stateless-движка читайте в нашей новой статье.
Также ожидается улучшение движка обработки правил (Rules Engine), который дает рекомендации проектировщику потока данных по настройке компонентов, опираясь на лучшие практики современной дата-инженерии.
Как уже было отмечено, вместо XML-представлений будут использоваться JSON-структуры. Шаблоны XML хранятся в памяти NiFi, а также в постоянном определении потока (файлы flow.xml.gz и flow.json.gz), и это вызвало множество проблем у пользователей с десятками или сотнями массивных шаблонов с тысячами компонентов. Удаление всего этого повысит стабильность NiFi и улучшит использование памяти. При переходе на новую версию придется экспортировать шаблоны в виде определений JSON или создать версию шаблонов в экземпляре реестра NiFi. Лучше использовать реестр NiFi вместе с самим фреймворком, чтобы контролировать версии и определения потока данных для совместного и повторного использования. Для этого, если шаблон представляет собой группу процессов, можно перетащить его на холст, а затем через контекстное меню экспортировать его как определение потока (файл JSON) или запустить контроль версий в реестре NiFi. Если шаблон не является группой процессов, а представляет собой непосредственно поток с компонентами, нужно перетащить группу процессов, затем перейти в эту группу процессов и перетащить туда шаблон. Далее можно вернуться к родительской группе процессов, содержащей шаблон, и экспортировать ее как определение потока или запустить для нее контроль версий.
Переменные и реестр переменных исчезнут, поскольку они имеют множество ограничений, таких как необходимость поддержки языка выражений в свойстве для ссылки на переменную и невозможность хранения конфиденциальных значений. Вместо этого будут использоваться контексты параметров, которые поддерживают концепцию провайдеров. Например, провайдер контекста параметров для получения значений параметров из внешних хранилищ, таких как HashiCorp, хранилища облачных провайдеров и пр.
Стратегия планирования на основе событий была экспериментальной опцией, доступной на некоторых процессорах. Поскольку она не принесла каких-либо существенных улучшений производительности, в версии NiFi 2.0 ее не будет. Вместо этой стратегии следует использовать стратегию планирования на основе таймера. Для более простого отслеживания удаленных и устаревших компонентов в NiFi есть специальный файл журнала nifi-deprecation.log, который содержит их перечисления.
Наконец, для обновления зависимостей в пользовательских компонентах, в набор CLI-инструментов NiFi 2.0 будет добавлена команда рекурсивного изменения текущих версии всех экземпляров компонента на более новые.
Что из этих планов реализовано в мажорном релизе 2.0, вышедшем в ноябре 2023 года, читайте в нашей новой статье.
Узнайте больше про администрирование и использование Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
