Версия сайта для слабовидящих
Популярность Apache NiFi в Big Data системах и интернете вещей (Internet of Things, IoT), в т.ч. индустриальном (Industrial Iot, IIoT), обусловлена широкими функциональными возможностями этой платформы по быстрой загрузке и маршрутизации данных любого формата между множеством источников и приемников информации. Также среди ключевых преимуществ NiFi отмечается распределенная архитектура, масштабируемость, наличие GUI, плагинов и интерфейсов для индивидуальной настройки. Однако, как правило, недостатки являются продолжением главных достоинств. Сегодня мы поговорим об основных минусах этого фреймворка, с которыми можно столкнуться при его практическом использовании, и рассмотрим методы решения этих проблем.
5 основных недостатков Apache NiFi
Итак, Apache NiFi свойственны следующие недостатки, которые стоит учитывать при использовании этой платформы маршрутизации данных в качестве production-решения при реализации комплексной Big Data системы или IoT/IIoT-проекта:
- некоторые неудобства эксплуатации, например, способ добавления новых собственных блоков в NiFi несколько перегружен из-за необходимости разработки Java-кода. Аналогичный минус можно отметить в пользовательском GUI, когда в ответ на практически любое действие появляется модальное окно, т.к. все операции происходят на стороне сервера [1].
- неудобный механизм логгирования, когда произошедшую ошибку сложно отловить по факту («задним числом»). Поскольку на практике большую часть тяжеловесных обработок выполняются в ночное время суток, то момент, когда «что-то пошло не так», не будет виден явно. В результате этого данные могут быть собраны или отправлены некорректно. Предупредить такую ситуацию можно с помощью самостоятельно написанного кода, который будет опрашивать NiFi на предмет возникновения ошибок, например, не реже 1 раз в 5-минутный период хранения данных [1].
- чувствительность к отключению узла от кластера – если произошла такая ситуация, когда пользователь вносил какие-либо изменения, то файл со всеми потоками данных, созданных в NiFi (flow.xml) становится недействительным. При этом узел не сможет подключиться обратно к кластеру, пока администратор не скопирует вручную файл flow.xml с подключенного узла [2]. В этой же категории стоит отметить возможность потери данных, хранящихся на узле кластера, в случае его отказа, т.к. NiFi не копирует информацию, как Apache Разумеется, при обнаружении сбоя диспетчер кластера направит новые данные на другой узел, однако, уже существующая очередь сообщений на отказавшем узле может быть потеряна. Проблема решается ручным отправлением данных на работающий узел кластера или отладкой отказавшего узла. Справедливости ради стоит отметить, что очередь данных в каждом узле NiFi обычно мала и не превышает объема информации, накопленного за 1 секунду или даже меньший период времени. Тем не менее, чтобы не потерять данные в очередях при отказе жесткого диска на каком-либо узле, стоит заранее позаботиться о надежности этих элементов. В частности, использовать RAID-массивы, которые обеспечивают избыточность, однако, гарантируют надежность хранения данных за счет возможности восстановления информации [3].
- проблема с сохранением состояния в случае переключения основного узла, что иногда делает обработчики событий неспособными получать данные из систем источников [2].
- неоднозначность гарантированной доставки сообщений, семантика которой зависит от взаимодействующих сторон. Например, при обмене данными между несколькими NiFi-экземплярами через протокол «Site-to-Site» (S2S), из-за 2-х фазовой передачи, предоставляемой на уровне самого фреймворка, будет гарантирована доставка сообщения «как минимум раз» (at least once), при которой возможно дублирование сообщений. В других случаях S2S-соединения, как правило, реализуется строго однократная доставка (exactly once), если отсутствуют разрывы между фазами передачи данных, например, обрыв соединения. Если на практике такая ситуация возникает, возможно дублирование записей, что устраняется с помощью специального обработчика DetectDuplicate, который помещается после порта S2S. На уровне NiFi-обработчика гарантия доставки сообщений зависит от системы, с которой ведется взаимодействие. В частности, для внешних систем, которые поддерживают двухфазную передачу аналогично S2S, например, Apache Kafka, гарантируется доставка «как минимум раз». Иначе, при отсутствии двухфазной передачи, например, как протокол Syslog, реализуется доставка «максимум один раз» (at most once), при которой сообщение может быть потеряно [3].
Вышеотмеченные проблемы решаются достаточно тривиальными способами. Поэтому можно сделать вывод, который успешными практическими кейсами, что все перечисленные недостатки не могут выступать причинами отказа от использования этой технологии в реальных Big Data и IoT/IIoT-проектах. Тем не менее, Apache NiFi не является единственным средством маршрутизации и быстрой загрузки больших данных – на практике для этих задач часто применяются альтернативные решения, например, Flume, Sqoop, StreamSets Data Collector. Чем именно NiFi отличается от этих и других подобных инструментов маршрутизации и передачи больших данных, читайте в нашей следующей статье.
Узнайте больше подробностей по установке, администрированию и эксплуатации NiFi на нашем практическом курсе Кластер Apache NiFi в лицензированном учебном центре обучения и повышения квалификации ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве.
Источники
