Комментарии 15
ТГ чат по NiFi t.me/nifiusers
Вот сколько раз видел упоминания о NiFi — столько раз не покидает ощущение, что это близкий аналог Apache Camel. И при этом нашлось лишь одно относительно вменяемое сравнение, оставляющее больше вопросов, чем дающее ответов.
Про camel было бы интересно послушать.
Сейчас Nifi достаточно прочно занял нишу бесплатного EL данных, даже среди энтерпрайза — сужу по московскому митапу и активности комьюнити. А вот про Camel никогда и ни от кого не слышал.
Может дело в том, что степень вхождения в Nifi много ниже — как правило администраторы/аналитики способны управиться, нет никакого программирования включая написание конфигов (до поры, до времени :).
Сейчас Nifi достаточно прочно занял нишу бесплатного EL данных, даже среди энтерпрайза — сужу по московскому митапу и активности комьюнити. А вот про Camel никогда и ни от кого не слышал.
Может дело в том, что степень вхождения в Nifi много ниже — как правило администраторы/аналитики способны управиться, нет никакого программирования включая написание конфигов (до поры, до времени :).
>А вот про Camel никогда и ни от кого не слышал.
Ну вообще тут было наверное с десяток статей, если мне не изменяет память. Camel — он же достаточно старый продукт, он появился в 2008.
Я раньше работал на проекте, где на нем было сделано порядка сотен интеграций. Так что пользователей (и членов коммьюнити) у него тоже достаточно много.
>администраторы/аналитики способны управиться, нет никакого программирования
Ой не верю я в такое… именно что до поры, до времени. Особенно если это реально большие данные. Да даже и не очень большие — мне как-то приходилось обрабатывать архивы содержащие xml, с данными по бондам. Ну и вот у вас архивчик скажем на 10 гигабайт, а внутри xml на пять десятков… И если делать как написано в примерчиках для начинающих, то либо памяти не напасешься, либо еще что похуже. А потоковая обработка — это уже не так тривиально, и тут именно что нужно программировать.
Ну вообще тут было наверное с десяток статей, если мне не изменяет память. Camel — он же достаточно старый продукт, он появился в 2008.
Я раньше работал на проекте, где на нем было сделано порядка сотен интеграций. Так что пользователей (и членов коммьюнити) у него тоже достаточно много.
>администраторы/аналитики способны управиться, нет никакого программирования
Ой не верю я в такое… именно что до поры, до времени. Особенно если это реально большие данные. Да даже и не очень большие — мне как-то приходилось обрабатывать архивы содержащие xml, с данными по бондам. Ну и вот у вас архивчик скажем на 10 гигабайт, а внутри xml на пять десятков… И если делать как написано в примерчиках для начинающих, то либо памяти не напасешься, либо еще что похуже. А потоковая обработка — это уже не так тривиально, и тут именно что нужно программировать.
habr.com/ru/post/358724
Судя по этой статье порог входа куда выше. Может это компенсируется большей гибкостью.
Ой не верю я в такое… именно что до поры, до времени. Особенно если это реально большие данные.
Если говорить про размер — то это все игрушки :) Но если про количество источников — жить можно.
Про XML — естественно на стандартных процессорах не обработать, но скрипт груви на 2 десятка строк с подключенным sax парсером делает все в лучшем виде. Скрипты на 5 языках встроены в коробку и набор языков тех же администраторов/аналитиков: груви, житон, луа, руби…
Серьёзно?! Мы даже TechOps'ов к Nifi не подпускаем, чтоб не завалить прод., что на нем сделать просто элементарно.
Camel — один из зрелых и распространенных ETL продуктов. Основное преимущество перед другими продуктами огромное количество коннекторов. Наряду с Mule именно большое количество готовых коннекторов и удобство построния процесса делает их лидерами ETL сферы.
Создатели Nifi признают, что Camel вдохновил их.
К сильным сторонам Nifi можно отнести:
- визуальное управление процессом: можно запустить или остановить любой процессор, задать количество потоков, процессов
- возможность увидеть количество сообщение и просмотреть последние
К слабым:
- понятие визуализации у создателей весьма скудное: много ETL продуктов придумывает собственные нотации описания процессов со своими иконками вместо стандартных BPMN, DML и т.д., но показывать всё только однотипными кубиками — верх неуважения пользователя
- невозможность разработки несколькими разработчиками над одним процессом: XML записывается всегда с новыми идентификаторами процессоров, даже, если вы их не меняли — мерж только руками
- скудный набор коннекторов, даже стандартные протоколы не покрыты, например, хотите REST, получите HTTP, а дальше сами, сами. Или коннектор есть, но баги не исправляются годами
- есть очереди, но DLQ создавайте сами
- очень прожерлив: для старта 2 гига, но ничего сделать не получится
По опыту 4 летней работы с ним…
Если есть возможность выбрать другой продукт, то посмотрите в другую сторону.
Складывается впечатление, что продукт отдали в open source, чтоб совсем не выбрасывать. Видно, что его основная идея — визуальное управление и мониторинг конкретных процессоров, но не потока данных в целом. Не обольщайтесь — это узкоспециализированный продукт, но не ETL, не BPM.
Если нет возможности использовать что-то другое, то : - создавайте маленькие процессы: пара-тройка кубиков
- всю логику переносите в процессоры, чтоб их можно было покрыть тестами
- лучше использовать Java процессоры, если не хотите решать проблемы с загрузкой классов и ресурсов в Groovy
- не разрабатывайте одну процесс группу совместно
Я правильно вас понял, что если у кого-то в команде есть скажем 4 года опыта Camel, а у других опыта никакого, то NiFi нам как команде ничего не даст?
Зависит от того, что вы хотите достичь. Но если вы надеетесь, что опыт Camel поможет с Nifi в интеграции, то вряд ли.
Не-не. Я просто смотрю и пытаюсь выбрать. И скорее выберу Camel, потому что пока я не вижу, что бы мне такое даст NiFi, чего я не смогу на Camel запрограммировать, причем достаточно несложно.
Насколько я понимаю, camel позволяет связывать приложения внедряя в них модули фреймворка. Если нет возможности внедриться в приложения, а есть только внешние интерфейсы получения данных (http, файлы) — тут nifi и ему подобные системы подойдут лучше.
В моей практике больше встречалось именно монолитов-источников данных.
В моей практике больше встречалось именно монолитов-источников данных.
Вы не совсем правильно поняли.
>camel позволяет связывать приложения внедряя в них модули фреймворка.
Как вы себе представляете внедрение camel например в СУБД? Нет такого, не очень понимаю, откуда такое впечатление сложилось. Вы можете связать два приложения, встроив camel в оба, и общаться например по AMQP, но это какой-то весьма частный случай.
Ну и приложение camel в любом случае точно так же может получать данные по тем же http или из файлов. И никакого внедрения в другие приложения для этого не нужно.
>camel позволяет связывать приложения внедряя в них модули фреймворка.
Как вы себе представляете внедрение camel например в СУБД? Нет такого, не очень понимаю, откуда такое впечатление сложилось. Вы можете связать два приложения, встроив camel в оба, и общаться например по AMQP, но это какой-то весьма частный случай.
Ну и приложение camel в любом случае точно так же может получать данные по тем же http или из файлов. И никакого внедрения в другие приложения для этого не нужно.
Очень интересно. Жду вторую часть
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Побег от скуки — процессы ETL