В феврале 2022 года вышел новый релиз Cloudera Flow Management 2.1.3 для совместного использования с Cloudera Manager и CDP Private Cloud Base 7.1.7. Этот выпуск основан на Apache NiFi 1.15, о новинках которого мы ранее рассказывали здесь, здесь и здесь. Сейчас рассмотрим основные преимущества этого решения.
5 главных улучшений в Cloudera Flow Management 2.1.3 с Apache NiFi 1.15
Напомним, Cloudera Flow Management (CFM) — это решение для приема и управления данными без кода, основанное на Apache NiFi. Благодаря интуитивно понятному графическому интерфейсу и процессорам NiFi, CFM предоставляет высокомасштабируемые возможности перемещения, преобразования и управления данными. Помимо Apache NiFi как основного движка, CFM включает его реестр, который позволяет разрабатывать и развертывать потоковые файлы в стиле DevOps. Реестр NiFi также поддерживает управление версиями потока, перенос потоков из одной среды в другую и развертывание потока. Подробнее о том, что такое Cloudera Flow Management, читайте здесь и здесь.
Вышедший в начале ноября прошлого года Apache NiFi 1.15.0 содержит множество улучшений, новых функций, а также исправления ошибок, из которых наиболее важными для пользователей Cloudera Flow Management можно назвать следующие:
- улучшение отклика пользовательского интерфейса NiFi, что особенно важно для работы больших команд на одном кластере, где работают сотни потоков на десятках тысяч процессоров с большим количеством контекстов параметров. При просмотре пользовательского интерфейса и перечислении параметров потока NiFi возвращает больше данных, чем это действительно нужно. Это связано с тем, что все в NiFi основано на API, и все, что пользователь может делать через пользовательский интерфейс, должно быть доступно для автоматизации. Но если API вызывается через пользователя в самом GUI, можно добавить в API флаг необязательности, показывая, что вызов сделан пользовательским интерфейсом NiFi. Так фреймворк может отбросить ненужную информацию, ускорив работу.
- наследование контекстов параметров, что подходит для параметризации потока путем определения набора пар ключ/значение на уровне группы процессов, позволяя легко продвигать поток в нескольких средах или преобразовывать потоки в общие активы для повторного использования в разных командах. В CFM 2.1.3 есть новая функция, которая позволяет определять наследование контекста параметров. Контексты параметров имеют сопоставление один к одному с группами процессов, что усложняет повторное использование параметров в нескольких потоках в случае мультитенантных сред. Эта новая функция упрощает создание параметров «высокого уровня» на уровне корневой группы процессов, которые можно использовать во многих потоках, при этом определяя определенный набор параметров для каждого варианта использования на более низких уровнях группы процессов.
- Улучшение процессора NiFi Stateless, что актуально для транзакционного выполнения потоков, обработки данных в памяти и других операций без сохранения состояния. В CFM 2.1.3 добавлен новый процессор ExecuteStateless, что дает возможность запускать поток с использованием подхода без сохранения состояния непосредственно в пользовательском интерфейсе NiFi. Это решает проблемы обеспечения семантики строго однократной обработки с помощью Kafka (exactly once).
- Валидация компонента в графическом представлении его конфигурации, что экономит время разработчика Data Flow. На практике при настройке процессора может потребоваться много переходов между представлением конфигурации и холстом, когда пользователь NiFi запускает компонент, проверяет его работу и снова возвращается к представлению конфигурации, чтобы настроить его свойства. В CFM 2.1.3 появилась возможность проверить компонент сразу в его конфигурации, позволяющая пользователю подтвердить валидность конфигурации и выполнить код, чтобы действительно проверить ее на реальной системе. Например, при проверке конфигурации процессора ListS3 процессор выведет список содержимого настроенного сегмента и сообщит пользователю, сколько элементов будет фактически отображаться при запуске процессора. Это значительно улучшает взаимодействие с пользователем в сценариях интеграции с внешними системами.
- Улучшение загрузки классов процессоров, связанных с Hadoop (HDFS, Hive и пр.), в многопользовательском режиме. Это означает, что разные наборы учетных данных Kerberos будут использоваться для разных потоков в одном и том же кластере NiFi. Учитывая, как клиент Hadoop использует класс UserGroupInformation, и особенности изоляции загрузки классов в NiFi, фреймворк дублировал ClassLoader для каждого процессора. Это приводило к долгому запуску, например, до одного или двух часов при использовании тысяч процессоров HDFS. Теперь не нужно создавать отдельный ClassLoader, который будет загружать сотни или тысячи классов для каждого экземпляра процессоров. В реальности улучшение сокращает время запуска фреймворка до пары минут.
Узнайте больше про администрирование и эксплуатацию Apache NiFi для эффективной аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
