Почему DevOps-подходы не так просто внедрить в инженерию данных, что не так с реестром Apache NiFi и зачем расширять набор инструментов Toolkit собственным Java-приложением для автоматизированной миграции потоковых конвейеров в разные среды развертывания.
Что не так с реестром Apache NiFi с точки зрения DevOps-инженера
Изначально Apache NiFi был создан как NoCode-инструмент построения потоковых конвейеров обработки данных, который позволяет без разработки кода в веб-GUI проектировать рабочие процессы, используя готовые обработчики (процессоры). Однако, как и большинство LowCode/NoCode инструментов, производственное использование NiFi в реальных проектах не обходится без кодирования. В частности, дата-инженеру может потребоваться написать скрипт для скриптовых процессоров или вообще реализовать собственный обработчик, что мы рассматривали здесь и здесь.
Впрочем, внедрить DevOps-подходы в инженерию данных не так-то просто, о чем мы упоминали в прошлой статье. В частности, из-за отсутствия встроенных функциональных возможностей для отмены изменений был создан реестр NiFi — внешняя система управления версиями, позволяющая откатывать спроектированные конвейеры до последней рабочей версии. Реестр NiFi дает возможность управлять версиями каждой группы процессов, выполняя коммиты непосредственно на холсте веб-GUI. На первый взгляд может показаться, что это похоже на Git для NiFi, но в реестре отсутствуют функции современных систем управления версиями. Это обусловлено следующими причинами:
- хранить потоковый конвейер сложнее, чем хранить код. Компоненты потока часто ссылаются на друг на друга, причем эти ссылки могут быть как внутренними, так и внешними, т.е. вне групп процессов с версиями.
- Компоненты потокового конвейера содержат внутренние метаданные, которые нельзя переместить в репозиторий.
- Совместное проектирование потокового конвейера реализуется сложнее, чем слияние веток кода в Git-подобных системах. Проще всего создать несколько версий потока, в каждой из которых соавтор вносит свои изменения, чтобы впоследствии объединить эти частные результаты в один общий.
Впрочем, системы контроля версий нужны не только для совместной разработки. Они также упрощают миграции между средами, например, при переводе из среды разработки в среду тестирования и производства. Автоматизированная миграция экономит время и менее подвержена ошибкам. В NiFi реализовать такой CI/CD-подход можно двумя способами:
- один реестр для всех сред, что проще, но вызывает много проблем с безопасностью, включая беспрепятственную возможность изменения производственной системы в любой момент времени;
- уникальный реестр для каждой среды (DEV/TEST/PROD), что более управляемо и безопасно.
Однако, чтобы реализовать второй вариант, необходимо сохранить и импортировать все ранее разработанные конвейеры. Причем желательно сделать это автоматически. Хотя NiFi, и NiFI Registry предоставляют REST API для всех операций, которые можно выполнять через веб-интерфейс, это довольно низкоуровневый API, который не очень удобно использовать для автоматизированного выполнения действий. В частности, нужно обработать подключение к компонентам, сопоставление всех сущностей с объектами и еще ряд рутинных операций.
Чтобы решить эту проблему, в Apache NiFi есть Toolkit — набор CLI-утилит, которые используют REST API этого фреймворка. NiFi Toolkit загружается отдельно от самого NiFi и содержит следующие утилиты для настройки и поддержки фреймворка в автономных и кластерных средах:
- CLI — инструмент командной строки, который позволяет администратору кластера взаимодействовать с экземплярами NiFi и его реестра для автоматизации таких задач, как развертывание версий потоковых конвейеров, управление группами процессов и узлами кластера.
- Encrypt Config — инструмент, который шифрует конфиденциальные ключи в файле properties, чтобы упростить настройку защищенного экземпляра NiFi;
- File Manager — диспетчер файлов, который позволяет администратору создавать резервные копии, устанавливать или восстанавливать установку NiFi из резервной копии;
- Flow Analyzer создает отчет, позволяющий понять максимальный объем данных, который может храниться при обратном давлении для данного потока;
- Node Manager позволяет администратору выполнять проверки состояния узлов, а также подключать, отключать или удалять узлы из кластера NiFi;
- Notify — средство отправки уведомлений в пользовательский интерфейс NiFi;
- S2S позволяет администратору отправлять данные в потоки NiFi или из них через сайт-сайт;
- TLS Toolkit создает необходимые хранилища ключей, хранилище доверенных сертификатов и соответствующие файлы конфигурации, чтобы упростить настройку защищенного экземпляра NiFi;
- ZooKeeper Migrator нужен для перемещения информации ZooKeeper из одного кластера в другой и переносить владение узлом этого сервиса синхронизации метаданных;
Все эти утилиты выполняются с помощью скриптов, которые находятся в bin-каталоге установки NiFi Toolkit. Тем не менее, несмотря на довольно широкий набор инструментов Toolkit, они не позволяют автоматически выполнить миграцию из одного реестра NiFi в другой. Придется писать код, чтобы управлять этим. Как это сделать, рассмотрим далее.
Реализация CI/CD
Итак, чтобы внедрить подход непрерывной интеграции и поставки к потоковым конвейерам Apache NiFi, придется выполнить собственную реализацию этих DevOps-идей из-за отсутствия таких возможностей в самом фреймворке. В коде реестра NiFi есть POJO-объекты для всех сущностей, используемых REST API, и некоторые вспомогательные методы, которые упрощают взаимодействие с компонентами потокового конвейера. Напомним, POJO (Plain Old Java Objec) – это простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели. Будучи написанным на Java, NiFi использует все концепции этого языка программирования.
При создании сценариев развертывания можно расширить NiFi Toolkit и создать собственное Java-приложение, использующее существующие POJO и методы. Однако, несмотря доступность всех POJO, некоторые методы использовать довольно сложно. Например, получить статус всех процессоров внутри группы процессов. Таким образом, при создании автоматического развертывания для потоков приходится решать множество проблем, вызванных отсутствием функций в NiFi Toolkit. В частности, необходимо реализовать следующие операции и компоненты:
- Идентификация объектов— реестр NiFi обеспечивает собственную идентификацию объектов, поэтому он не зависит от UUID NiFi или имен процессоров. Тем не менее, генерация идентификатора вызывает некоторые проблемы во время миграции.
- Зависимости групп процессов. Если какая-то версия группы процессов использует другую версию группы процессов, она содержит ссылку на нее. Это создает связь между группами процессов в реестре NiFi. Поэтому при импорте компонентов в потоковый конвейер необходимо делать это в правильном порядке, чтобы ни одна группа процессов не импортировалась до ее зависимостей.
- Сопоставление UUID— при импорте группы процессов создается новый идентификатор. Это создает проблему, когда одна группа процессов зависит от другой, поскольку при импорте зависимости она получает новый UUID. Поэтому группе, которая ее использует, необходимо обновить ссылку.
- URL-адрес реестра в ссылках. Путь к зависимости в реестре NiFi содержит URL-адрес реестра в качестве одного из свойств. При переходе в другую среду необходимо обновить значение до URL-адреса реестра, который будет использоваться.
- Видимость реестра. Эта проблема может возникнуть во время тестирования, например, в Docker, когда URL-адрес, видимый для пользователя, отличается от того, под которым NiFi видит свой реестр NiFi.
- Scopes— реестр NiFi хранит все о потоковом конвейере обработки данных, но он должен находиться в группе процессов с версиями. Это может быть проблемой для переменных и служб контроллеров, которые часто имеют глобальную область действия.
- Миграция службы контроллера. Реестр NiFi не хранит службы контроллера из внешней группы процессов. Необходимо создать дополнительный механизм, предназначенный для их импорта и экспорта.
- Сопоставление служб контроллера. Если процессор ссылается на службу контроллера за пределами своей группы процессов, реестр NiFi сохранит ссылку, но не сохранит службу контроллера. В результате после импорта процессор будет иметь неверную ссылку. Следует создать механизм для сопоставления этих ссылок после импорта потокового конвейера.
- Зависимости службы контроллера. Некоторые службы контроллера используются не только процессорами, но и другими службами контроллера. Во время миграции все компоненты получают новые UUID, поэтому необходимо обновить все ссылки.
- Управление состоянием потока. Компоненты в NiFi имеют состояние, которое зависит от состояния процессоров и количества потоковых файлов в очереди.Чтобы разрешить модификацию, нужно остановить процессор или очистить очередь. Проще и быстрее всего это сделать в веб-GUI.
- Плавная остановка. Чтобы избежать конфликтов при развертывании новой версии, следует убедиться, что в очередях потоков нет потоковых файлов.Для этого недостаточно просто изменить статус всех компонентов, которые необходимо остановить. Необходимо реализовать механизм, который ожидает обработки всех потоковых файлов, а затем останавливает все, в зависимости от структуры потока.
Таким образом, хотя NiFi Registry — отличный инструмент для разработки, который сочетается с набором инструментов Toolkit и помогает при миграции между средами, дата-инженеру придется вручную выполнить много дополнительной работы, чтобы сделать фактический процесс переноса потокового конвейера автоматизированным и надежным.
Освойте все возможности Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
