В рамках обучения дата-инженеров сегодня заглянем под капот системы Cloudera Flow Management, которая является частью платформы Cloudera DataFlow и основана на Apache NiFi. Вас ждет разбор основных концепций жизненного цикла потоковой разработки и их реализация в Apache NiFi с практическими примерами и рекомендациями по применению.
Что такое Cloudera Flow Management и причем здесь Apache NiFi: основы разработки Data Flow
В основе Cloudera Flow Management (CFM) лежит Apache NiFi – GUI-фреймворк для маршрутизации потоков данных, который реализует идеи DevOps для потоковых конвейеров, обеспечивая дата-инженеру удобство разработки и поддержку остальных этапов жизненного цикла Data Flow. Ключевыми концепциями жизненного цикла потоковой разработки в Apache NiFi являются следующие [1]:
- Процессор (Processor) — компонент для интеграции с реляционными СУБД и другими хранилищами данных, включая Apache Kafka, HBase и общедоступные облачные сервисы (AWS S3 и Azure DataLakeStorage). CFM есть около 400 готовых процессоров, которые заказчики могут настраивать в своих потоках данных. О том, как создать свой процессор NiFi, мы писали здесь.
- Группа процессов (Process Group) – объединение нескольких процессоров в одну группу, чтобы организовать поток более понятным образом.
- Шаблон потока данных (Flow Template), который можно экспортировать как XML-файл потока, чтобы импортировать в другой кластер и создать на его основе экземпляр потока.
- Контроль версий (Version Control) — сам шаблон потока не имеет контроля версий, но это поддерживается с помощью Cloudera NiFi Registry, который поддерживает версионирование DataFlow, обеспечивая извлечение и обновление версий потока данных в связанных кластерах NiFi.
Развертывание потока данных в Apache NiFi может выполняться вручную, когда разработчик Data Flow самостоятельно загружает и выгружает шаблоны, копируя их из локальной среды разработки в кластер. Этот режим подвержен ошибкам человеческого фактора и не рекомендуется, в отличие от автоматического развертывания. NiFi и NiFi Registry предоставляют CLI и RESTful API для развертывания определенной версии потока из реестра в разных средах. NiFi Registry — это репозиторий управления версиями потока, из которого потоки следует продвигать в среду более высокого уровня. Именно автоматический режим решает корпоративные проблемы соблюдения должного уровня SLA и безопасности данных.
В частности, на практике часто требуется риски критически важных рабочих нагрузок, например, с помощью мультиарендных ACL-списков, экспертной оценки и управления релизами. Как это обеспечивается в Cloudera Flow Management и Apache NiFi, рассмотрим далее.
Эксплуатация Apache NIFI
Код курса
NIFI3
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
ТОП-10 практик разработки и развертывания потоков данных
В NiFi устойчивость потока данных зависит от режима их сбора. Например, pull-потоки активно собирают данные из исходных систем или хранилищ. Обычно потоки в режиме pull можно мгновенно остановить, поскольку данные буферизуются в исходных системах, и обработка возобновится после перезапуска потока. Потоки в режиме push пассивно принимают данные, которые отправляют другие системы. Обновление запущенного потока в режиме push более сложно, т.к. необходимо отслеживать сбои и сообщать о них. Но push-потоки разработаны так, чтобы минимизировать время простоя.
Рекомендуется разделить поток данных на минимум на две группы процессов:
- группа процессов подачи, где процессоры нужны только для прослушивания или подключения к исходной системе, а также к выходному порту. Эта группа процессов редко меняется после первоначального развертывания, а поток действует как внутренний буфер или очередь для хранения сообщений.
- группа процессов обработки, где выполняется вся бизнес-логика, которая может часто обновляться, не влияя на системы-источники.
Для раздельного развертывания под-потоков группы процессов подачи и обработки контролируются отдельно с помощью реестра. Если у работающего потока есть сообщения в очереди, NiFi не позволит обновить его до новой версии, чтобы избежать потери данных, вызванной несовместимыми изменениями в логике. Для этого Cloudera Professional Service реализует простое решение создания сценариев: Python-скрипт deploy_dest_changes.py, который проверяет статус потока каждые 10 секунд. Как только все очереди будут очищены, он начнет обновление группы процессов с новой версией.
Говоря про разработку и развертывание потоков данных в Apache NiFi следует отметить мультиарендность, которая позволяет нескольким бизнес-пользователям и процессам совместно использовать общий набор ресурсов, например, Cloudera Data Platform через политику, а не физическое разделение, без нарушения требований безопасности и раскрытия сторон.
Мультиарендность также важна для команд разработчиков, создающих разные приложения, которые необходимо объединить для выполнения в единой среде. Поэтому Cloudera Data Platform поддерживает многопользовательскую работу с данными и рабочими нагрузками, позволяя едином в кластере назначать пользователям роли с правами на общие ресурсы данных и рабочие нагрузки: пакетную или потоковую передачу, интерактивные пользовательские запросы.
Для этого используются политики Apache Ranger, предназначенные для управления разрешениями на авторизацию. Плагин Ranger можно включить для NiFi и NiFi Registry, чтобы настроить политики Ranger для ресурсов NiFi и сегментов реестра. Например, назначить каждой команде собственные группы процессов NiFi и единую корзину в реестре для среды разработки (dev). А в среде для тестирования разработанных потоков каждой команде можно назначено разрешение на чтение только своих групп процессов.
Для сервисов, совместно используемых несколькими потоками или разными процессорами в одном потоке в Apache NiFi есть сервисы контроллера. В частности, сервисы контроллера корневой области для ресурсов всего кластера, подключающиеся к внешним системам, таким как пул соединений с базой данных или службы ограниченного контроллера. А сервисы для отдельны процессоров или их групп используются для готовых служб при работе с внешними ресурсами, такими как учетные данные AWS. Они обернуты в систему управления версиями группы процессов, тогда как службы контроллера корневой области находятся вне контроля реестра NiFi. Знать, какие службы контроллера в этой группе процессов изменены, в NiFi Registry помогает API отслеживания версий. Эта опция позволяет избежать обновления всех служб контроллера, которые могут повлиять на большинство несвязанных потоков.
Чтобы сделать поток данных универсальным для разных сред, он должен иметь настраиваемые параметры, которые следует извлекать из потока и управлять ими в одном месте. При этом в реестре переменных нельзя параметризовать конфиденциальные свойства, например, пароли пользователей. Эту проблему решает контекст параметра NiFi для каждого потока. Когда версия потока создается в целевой среде, контекст параметра, на который указывает ссылка, создается автоматически, а также копируются его нечувствительные параметры. Для чувствительных параметров следует вручную обновить пустое значение, поскольку эти значения не отображаются в реестре. Подробнее о подобных проблемах утечки конфиденциальных данных мы писали в этой статье.
Если существующее значение параметра обновляется, оно не будет автоматически перезаписано в целевой среде. Поэтому следует добавить новый параметр с новым номером версии, соответствующем версии группы процессов и со ссылками на новый параметр. Таким образом, применение новой версии контекста параметра не влияет на поток в реальном времени. А когда новая версия потока также будет развернута в целевой среде Apache NiFi, устаревшие и неиспользуемые параметры могут быть удалены.
В заключение отметим, что разные потоки данных обрабатывают разную бизнес-логику. Поэтому использовать один и тот же набор скриптов для развертывания всех потоков проблематично, а большое количество таких сценариев доставки нежелательно из-за высоких накладных расходов на их обслуживание. Поэтому рекомендуется иметь соглашение об единых шаблонах именования процессоров и их групп. Например, добавлять суффикс IN к названиям группы процессов подачи, и OUT – к группе процессов обработки.
Эксплуатация Apache NIFI
Код курса
NIFI3
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Узнайте, как применять эти и другие лучшие практики администрирования и использования Apache NiFi в задачах современной дата-инженерии на специализированных курсах для разработчиков, ИТ-архитекторов, инженеров данных, администраторов, Data Scientist’ов и аналитиков Big Data в нашем лицензированном учебном центре обучения и повышения квалификации в Москве:
