Cloudera Flow Management, основанная на Apache NiFi и являющаяся частью платформы Cloudera DataFlow, используется некоторыми из крупнейших организаций в мире для обеспечения простого в использовании, мощного и надежного способа распределения и высокоскоростной обработки данных в современной экосистеме больших данных. Клиенты все чаще используют CFM для ускорения обработки потоковых данных на предприятии от концепции до реализации. Интерфейс разработки потоков Cloudera отличается от типичных стилей структурированного кодирования, что часто создает проблему применения лучших практик непрерывного совершенствования/непрерывной доставки (CI/CD) в стиле DevOps для доставки потоков. В этом блоге мы рассмотрим сквозной жизненный цикл процесса потока данных, который способствует непрерывной доставке с минимальным временем простоя. Мы надеемся, что вы почувствуете вдохновение, чтобы внедрить некоторые из этих идей в свои собственные процессы Cloudera Flow Management CD. Ниже представлена архитектура подобного решения:  В этом процессе можно выделить следующие шаги. Разработчики проектируют DataFlow и тестируют его в общем многопользовательском DEV кластере. Команда может работать только в своих собственных группах процессов, контролируемых политиками Apache Ranger для NiFi. Если какие-либо группы потребуют изменить или добавить службу корневого контроллера, администратор поможет с этим изменением и скопирует его в выделенную группу процессов root_controller_services.  Для контроля версий разработчики вручную добавляют или обновляют протестированные потоки в DEV раздел NiFi Registry. При заданных политиках в Apache Ranger для NiFi Registry одна команда может наблюдать только за назначенным ей сегментом. Администратор обновляет версию группы процессов root_controller_services в сегменте администратора реестра.  Чтобы разработчики не переносили потоки, которые все еще проходят тестирование, в среду более высокого уровня, они должны создать файл запроса на изменение (source change) для коллегиальной проверки исходника после тестирования потоков. Этот файл находится в проекте git изменений исходника. Разработчики создают новую ветку этого проекта git, а затем обновляют файл source_change_request.json, чтобы он содержал измененные потоки и версии. Если какие-то службы корневого контроллера были обновлены, администратор обновит версию группы процессов root_controller_services в файле source_change_request.json. Как только все они будут готовы, владелец изменения должен дать запрос git pull, чтобы выполнить Peer Review. Пример source_change_request.json  Члены команды рецензируют код, проверяя статус потока и тестируя в DEV NiFi.  Если команда подтверждает, что изменение готово к продвижению, они могут объединить этот запрос с главной ветвью проекта изменения исходника.  Cloudera предлагает создать задание Jenkins для запуска скрипта python Promo_source_changes.py, отслеживая главную ветвь проекта изменения исходника. Этот скрипт использует NiFi / NiFi Registry API для экспорта версии потока из DEV NiFi Registry, а затем импортирует ее в UAT NiFi Registry. Пример кода: Пример promote_source_changes.py   В реестре UAT NiFi скрипт generate_dest_change_request.sh зарегистрирован как перехватчик событий реестра. Конфигурация NiFi Registry Event Hook   Пример события CREATE_FLOW_VERSION     Это эквивалентно следующему: Любое обновление версии отдельного потока запускает сценарий для создания новой ветви проекта git запроса на изменение цели и создания файла dest_change_request.json путем сравнения новой и основной версии.  Пример dest_change_request.json   Для рассмотрения запроса release менеджером в git создается запрос на перенос. Поскольку каждое изменение версии группы процессов запускает одно событие реестра NiFi, если диспетчер версий содержит несколько групп процессов и несколько служб корневого контроллера, то для одного запроса на изменение исходника он будет получать несколько запросов на изменение цели. Диспетчеру версий необходимо объединить связанные запросы на изменение и просмотреть изменения. Если перечислены какие-либо чувствительные параметры, он должен подтвердить, требуются ли в целевом NiFi новые значения чувствительных параметров. После внесения этих изменений конфиденциальных параметров запрос на перенос может быть одобрен и объединен с master ветвью в git. Пример комбинированного dest_change_request.json   Наконец, объединенная главная ветвь запускает скрипт python deploy_dest_changes.py для автоматического развертывания новой версии потока в среде UAT - без простоев или с минимальным временем простоя. Соединение подпотоков совершенно нового потока Развертывание новой версии активного подпотока  Благодаря превосходному NiPyApi (https://github.com/Chaffelson/nipyapi), веденному Дэниелом Чаффельсоном, скрипты Python для Cloudera Flow Management оказаались намного проще, чем ожидалось.