Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В предыдущей статье я рассказывал о Kafka и её аналогах, а сегодня хочу рассмотреть NiFi.
Вы узнаете:
Что такое NiFi и как мы используем этот инструмент;
Аналоги NiFi: их преимущества и недостатки.
NiFi: что это такое и как мы используем этот инструмент?
Давайте двигаться дальше, в сторону ETL инструмента. Начиная разработку продукта UseBus, мы познакомились с шинами Enterprise Service Bus, которые были построены на Apache Camel. Собственно, в этом случае мы и столкнулись с ним в полной мере и ощутили очень многие неприятности. Во-первых, это очень старое решение, что хорошо и плохо одновременно. Хорошо, потому что оно устоявшееся, а плохо, потому что, как правило, более старые решения гораздо менее удобны. Когда инструменты эволюционируют, то они двигаются в сторону удобства для пользователей.
NiFi — это ETL инструмент. Дословно расшифровывается как «Extract, Transform, Load» и переводится на русский язык как «вытащить, преобразовать, загрузить». Обычно такие инструменты используются для сбора данных из разных источников и загрузки в какое-то единое место, например, в Data Lake или просто какую-то очень большую базу данных. Место загрузки зависит от архитектуры. Главное — понять предназначение этих инструментов.
Аналоги NiFi
Apache Camel
Мы честно пытались настраивать pipeline, пытались обсуждать это с людьми с рынка, имеющими опыт с Apache Camel. Их не так много, и все согласны с одной простой вещью: Apache Camel чрезвычайно мощный инструмент, но порог вхождения настолько высокий, что приходится всё это штудировать и очень много изучать. С точки зрения удобства использования быстро докручивать pipleline очень часто не получается, приходится тратить значительные объёмы времени. А ещё приходится докручивать разного рода логику, дописывать на Java. На наш взгляд, из коробки было недостаточно модулей и инструментов. Ну и, как я уже говорил, порог вхождения не самый простой. Инструмент, на мой взгляд, не самый удобный. Я ожидал, что из-за того, что он до сих пор поддерживается, его сделают гораздо более удобным. К сожалению, с точки зрения удобства не сильно всё изменилось. Есть подозрение, что он постепенно вошёл в период стагнации.
Apache Airflow
Есть Apache Airflow, один из пром. стандартов, очень популярный на сегодня. У него достаточно приятный GUI, порог вхождения гораздо ниже, чем у Apache Camel и из коробки он достаточно хорошо масштабируется. Для нас в нём был только один критический минус: какие-то pipeline и модули в большинстве своём надо дописывать на Python. Нет полноценного GUI, на котором ты бы просто сел и собрал самое простое решение, тебе всё равно придётся кодить. Для кого-то это плюс, для кого-то минус. Масштабируется Airflow также довольно хорошо.
AWS Step Functions
Также хочу упомянуть полу-пром. стандарт — AWS Step Functions. Он оказался очень популярен, но не в России. Особенности нашего законодательства не позволяют хранить свои данные и сервера где-то в AWS. Насколько мне известно, AWS Cloud признан одним из самых дорогих решений среди облаков открытого доступа. Например, считается, что на том же Azure Cloud можно выстроить решение подешевле. Но AWS уже давно пром. стандарт среди облаков, он имеет большое количество готовых решений, и поэтому до сих пор на нём работает очень много разработчиков, много команд и продуктов. Многие знают и любят AWS Step Functions. Вроде и минусов-то у него немного, но он просто дорогой.
Luigi
Не могу не поделиться моментом, который меня крайне сильно удивил – проанализировав многие отзывы и топики мы увидели, что очень многие любят Luigi. Как я понял, это не совсем самостоятельный инструмент, а именно расширение, плагин для стандартного Python-фреймворка, веб-фреймворка, на основе которого можно поднять ETL функциональность. У него есть GUI для мониторинга, но большую часть логики нужно писать на Python.
Особенность Luigi во многом схожа с RabbitMQ: он запускается, из коробки имеет очень много возможностей, очень удобен, но очень плохо масштабируется. Когда я читал чат разработчиков Luigi, они прямым текстом говорят: «Luigi был создан не для этого, он был создан для быстрого старта, для запуска какого-то пайпа, но не для масштабирования. Это не его цель, не его задача». Он популярен, потому что простой, на нём можно выстроить и создать какое-то решение, но для серьёзного энтерпрайза, тем более высоконагруженного, он совсем не подойдёт.
Почему мы выбрали NiFi?
С удивлением для нас, мы обнаружили, что очень многие компании (в том числе, в России), запускают пайплайны на Apache NiFi. Можно смело говорить, что сейчас фактически два пром. стандарта, которые повсеместно используются — это Apache Airflow и Apache NiFi. Просто Apache NiFi гораздо более молодой инструмент и поэтому долгое время на него смотрели с опаской — готов он для серьёзного энтерпрайза или не готов? Но, учитывая то, насколько серьёзные компании запускают его сейчас, похоже, все признали, что он готов.
NiFI очень удобный ETL инструмент, плюс у него огромное количество адаптеров и решений из коробки. Многие вещи можно на нём не писать. Понятно, что для каких-то нетривиальных, кастомных решений придётся что-то дописывать, и модули можно дописывать на Java (что мы, в принципе, и делаем в рамках разработки проекта UseBus). Но за счёт того, что у него большое количество готовых решений, вам придётся это делать гораздо реже, чем в любых других инструментах. Для быстрого старта вы его просто запустили, собрали из готовых модулей какое-то решение и оно работает. Согласитесь – это удобно.
С точки зрения масштабирования NiFi из коробки умеет очень хорошо масштабироваться, работать кластерами, а также имеет модуль для приёма входящих сообщений. Тот же самый Rest API на нём построить достаточно легко: вы берёте какой-то порт, указываете ему какие URL-ы каким методом соединить и всё, он работает. Оказалось (что для нас было открытием), что многие ETL инструменты не умеют принимать входящие сообщения. К слову, некоторые создатели ETL прямо пишут, что это не их задача. На их взгляд, ETL сам должен собирать данные, ему не должны их присылать.
GUI очень удобный, что было для нас решающим аргументом при выборе. Он неплохо держит нагрузку по сравнению с очень многими инструментами и отлично масштабируется с точки зрения энтерпрайз-решений. В принципе, вы можете настроить всё только через GUI. Да, там есть возможность выгрузки конфигурации и её загрузки, если вы, например, отладили это на деве и хотите выдать на прод. Но если что-то пошло не так, вам это делать не обязательно, вы в реальном времени можете отключить или докрутить какой-то поток и не будет никакой остановки приложений. Это очень удобно.
Почему он нам понравился? Как оказалось, Enterprise Service Bus шины очень часто используются в первую очередь для сбора серьёзного объёма данных из разных систем и поэтому очень часто идут в комплекте с каким-то ETL инструментом, который ещё надо «подружить» между ESB и ETL. А тут из коробки, если у тебя это составная часть системы, вы уже всё «подружили» и она работает, а вы быстро можете накрутить ETL к разным системам, pipeline, забрать оттуда данные, через шину отправить и положить куда надо. Собственно, поэтому мы и остановились на NiFi.
В GUI, когда вы настроите минимальный pipeline, достаточно быстро можно разобраться. Когда вы донастраиваете какие-то более сложные вещи, всё равно приходится погружаться в документацию.
Я могу смело сказать, что по сравнению с Apache Camel уровень вхождения гораздо ниже, на порядок, в десятки раз. Наверное, единственный минус, который я могу вспомнить это то, что когда вы пишете серьёзные кастомные решения, порог вхождения все ещё присутствует. У Apache Airflow с этим попроще, там уровень вхождения ниже. Но ниже он за счёт того, что многих готовых решений там просто нет. И вам легче докручивать, потому что вы взяли и сами написали своё решение.
Вот тут и возникает особенность, trade-off.
Вы хотите большое количество готовых решений, но придётся с ними разбираться;
Или у вас не будет этих готовых решений, но вам придётся дописывать их собственными силами.
Смотря на эти trade-off и думайте, хотите ли вы двигаться в сторону Airflow или в сторону NiFi с точки зрения того, кто будет просто поддерживать NiFi и докручивать его. Более продвинутый разработчик может уже создать и настроить pipeline. Если что-то пошло не так, то условно администратор и даже бизнес-пользователь может просто включить какой-то поток или добиться хитрой фильтрации прямо в продакшене.
С Apache Airflow так не получится. С ним, если что-то пошло не так в продакшене, вы зовёте третью линию поддержки и разработчиков. Без них вы не обойдётесь и это достаточно серьёзный минус Airflow. С NiFi можно обойтись, можно что-то придумать. Если у вас круглосуточная поддержка, разработчики хотя бы будут спать по ночам :)
Заключение
Ранее мы рассмотрели Kafka с её преимуществами и недостатками, а сегодня NiFi и аналоги инструментов. Перед тем, как выбрать необходимую технологию, внимательно знакомьтесь с плюсами и минусами, а также подумайте: точно ли инструмент подойдёт вам и вашей команде и закроет ваши потребности?
Спасибо за то, что уделили время прочтению статьи. Делитесь своим мнением в комментариях: что использовали и что больше нравится?
