Запуская наш новый курс по Эксплуатация Apache NIFI, сегодня рассмотрим 3 популярных вопроса про этот Big Data фреймворк с комментариями компании Cloudera. Читайте далее, может ли NiFi заменить пакетные ETL-оркестраторы, как использовать REST API для управления потоками данных в этом фреймворке, а также где настраивать политики управления доступом в многопользовательской кластерной среде.
Kafka и NiFi: конкуренты или комплементы?
NiFi предназначен для централизованного размещения, обычно в центре обработки данных или в облаке, чтобы перемещать данные или собирать их из внешних источников, таких как СУБД, хранилища объектов и пр. Таким образом, NiFi играет роль шлюза (маршрутизатора) для перемещения данных между гетерогенными средами или в гибридной облачной архитектуре. При том, что Apache NiFi работает в потоковой парадигме, иногда он может использоваться для пакетной обработки как ELT-оркестратор. В этом случае NiFi будет захватывать различные наборы данных и выполнять для каждого из них необходимые преобразования: проверка схемы, преобразование формата, очистка данных и т.д. После этого NiFi может отправить наборы данных в хранилище на базе Apache Hive и затем инициировать к нему запросы.
Вообще в Apache NiFi потоковые файлы (FlowFile) – это способ описания событий, объектов и данных. Для каждого потокового файла в Apache NiFi можно выполнить практически любое преобразование. Но использовать этот фреймворк для чисто пакетных операций, таких как join-соединения на основе общего столбца или оконных агрегатов, не совсем целесообразно и требует дополнительных решений, подобно вышеописанному кейсу с Apache Hive.
В разговоре про потоковую обработку Big Data, чаще всего речь идет об Apache Kafka, которая изначальна создана для этих сценариев использования. Но, в отличие от NiFi, Kafka работает с файлами не слишком большого размера. Можно сказать, что Kafka похожа на почтовый ящик, который хранит данные топиках, ожидая, пока приложение опубликует или потребит их. NiFi же аналогичен почтальону, который доставляет данные в почтовый ящик или в другое место назначения с помощью различных протоколов (MQTT, Kafka Protocol, HTTP, Syslog, JDBC, TCP/UDP и пр.) и наглядного веб-GUI. А благодаря расширяемой структуре NiFi, пользователь может расширять возможности фреймворка, настраивая собственные потоки перемещения данных [1].
Таким образом, Apache NiFi и Kafka дополняют друг друга, позволяя дата-инженеру строить эффективные потоковые конвейеры. Подробнее о кейсах совместного использования этих Big Data фреймворков мы рассказывали здесь.
Код курса
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Масштабный сбор данных в реальном времени с REST API
В Apache NiFi имеется REST API, который обеспечивает программный доступ к управлению экземпляром фреймворка в режиме реального времени, позволяя запускать и останавливать процессоры, отслеживать очереди, запрашивать сведения о происхождении данных и выполнять прочие операции с помощью конечных точек. Каждая конечная точка включает описание, определения ожидаемых входных и выходных данных, коды потенциальных ответов и авторизации, необходимые для вызова сервиса. Используя 4 классических метода REST API (PUT, POST, GET, DELETE), можно создавать соединения, аутентифицировать пользователя, управлять кластером и очередями, посылать и получать данные, а также выполнять множество других операций этого потокового фреймворка [2].
Таким образом, REST API в NiFi позволяет собирать данные из внешних источников и отправлять их в нужные пункты назначения. Из всех протоколов передачи данных, поддерживаемых REST-подходом, на практике чаще всего используется HTTP и его защищенная модификация HTTPS.
Например, если требуется принять данные, можно использовать процессор ListenHTTP, который будет прослушивать заданный порт для HTTP-запроса. А с помощью процессоров HandleHTTPRequest и HandleHTTPResponse можно получить HTTP-запрос от внешнего клиента, чтобы преобразовать данные в запросе и отправить клиенту ответ. Аналогично, NiFi получит доступ к внешним системам, таким как FTP-сервер, через HTTP-запросы в REST API. Все эти уникальные запросы очень хорошо масштабируются горизонтально, а балансировщик нагрузки обеспечит ее равномерное распределение между узлами в кластере NiFi [1].
Безопасность в NiFi: управление пользовательским доступом к потокам данных
NiFi предоставляет очень детализированную мультиарендную модель с политиками безопасности, которые можно настроить для многопользовательской среды. В частности, определить несколько групп процессов с разными наборами политик для разных вариантов использования. При этом нужно учесть следующие аспекты [1]:
- организовать разделение доступа к группам процессов для разных команд, например, с помощью Apache Ranger или внутренних политик фреймворка, о которых мы поговорим далее.
- в кластере NiFi все ресурсы используются всеми существующими потоками без изоляции ресурсов. Поэтому фреймворк не может выделить, к примеру, 60% ресурсов для кейса А и 40% для кейса B. Для особенно важных и критичных для бизнеса сценариев рекомендуется выделить отдельный кластер NiFi, чтобы гарантировать соблюдение SLA. Фреймворк предоставляет функции мониторинга для обеспечения правильного использования ресурсов в кластере и предупреждения в случае недостаточного размера кластера. В 2021 году Cloudera планирует выпустить новое решение, позволяющее клиентам запускать потоки в выделенных кластерах NiFi, работающих на k8s с автоматическим масштабированием. Эта опция гарантирует, что каждый сценарий потребляет только необходимое количество ресурсов, не влияя на другие варианты использования.
Как мы уже отметили выше, фреймворк позволяет управлять возможностью пользователей и групп просматривать или изменять ресурсы с помощью политик доступа, которые могут быть определены следующим образом [3]:
- просмотр – только пользователи или группы, добавленные к этой политике, могут видеть детали этого ресурса;
- изменение – только пользователи или группы, добавленные к этой политике, могут изменять конфигурацию этого ресурса.
Администратор NiFi может создавать и применять политики доступа на глобальном и на компонентном уровне, применяя политики доступа ко всем типам компонентов, кроме подключений. Полномочия на подключение определяются отдельными политиками доступа к исходным и конечным компонентам подключения, а также политикой доступа группы процессов, содержащей эти компоненты.
Чтобы получить доступ к списку очереди или удалению очереди для подключения, пользователю требуется разрешение на просмотр и изменение в политике компонента. Причем все узлы кластера должны быть добавлены к этим политикам, т.к. пользовательский запрос может быть реплицирован через любой узел.
В зависимости от возможностей, настроенных в файлах UserGroupProvider и AccessPolicyProvider, пользователи, группы и политики будут настраиваться в пользовательском интерфейсе. Если расширения не настраиваются, пользователи, группы и политики будут доступны только для чтения в пользовательском интерфейсе. Если настроенный авторизатор не использует UserGroupProvider и AccessPolicyProvider, существующие пользователи и политики могут не отображаться в пользовательском интерфейсе [3].
Код курса
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Читайте в нашей следующей статье про особенности развертывания Apache NiFi на Kebernetes в облаках AWS. А лучшие практики конфигурирования Linux под особенности этого фреймворка и тонкости использования его готовых процессоров рассматриваются здесь.
Узнайте больше про администрирование и применение Apache NiFi для решения задач дата-инженерии на специализированных курсах для разработчиков, ИТ-архитекторов, дата-инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в нашем лицензированном учебном центре обучения и повышения квалификации в Москве:
- https://blog.cloudera.com/top-5-questions-about-apache-nifi/bigdataschool.ru/contacts/registration
- https://nifi.apache.org/docs/nifi-docs/rest-api/index.html
- https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html
