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