Побег от скуки — процессы ETL

[UnnamedUA]

ТГ чат по NiFi t.me/nifiusers

[sshikov]

Вот сколько раз видел упоминания о NiFi — столько раз не покидает ощущение, что это близкий аналог Apache Camel. И при этом нашлось лишь одно относительно вменяемое сравнение, оставляющее больше вопросов, чем дающее ответов.

[barloc]

Про camel было бы интересно послушать.
Сейчас Nifi достаточно прочно занял нишу бесплатного EL данных, даже среди энтерпрайза — сужу по московскому митапу и активности комьюнити. А вот про Camel никогда и ни от кого не слышал.
Может дело в том, что степень вхождения в Nifi много ниже — как правило администраторы/аналитики способны управиться, нет никакого программирования включая написание конфигов (до поры, до времени :).

[sshikov]

>А вот про Camel никогда и ни от кого не слышал.
Ну вообще тут было наверное с десяток статей, если мне не изменяет память. Camel — он же достаточно старый продукт, он появился в 2008.

Я раньше работал на проекте, где на нем было сделано порядка сотен интеграций. Так что пользователей (и членов коммьюнити) у него тоже достаточно много.

>администраторы/аналитики способны управиться, нет никакого программирования
Ой не верю я в такое… именно что до поры, до времени. Особенно если это реально большие данные. Да даже и не очень большие — мне как-то приходилось обрабатывать архивы содержащие xml, с данными по бондам. Ну и вот у вас архивчик скажем на 10 гигабайт, а внутри xml на пять десятков… И если делать как написано в примерчиках для начинающих, то либо памяти не напасешься, либо еще что похуже. А потоковая обработка — это уже не так тривиально, и тут именно что нужно программировать.

[barloc]

habr.com/ru/post/358724

Судя по этой статье порог входа куда выше. Может это компенсируется большей гибкостью.

Ой не верю я в такое… именно что до поры, до времени. Особенно если это реально большие данные.

Если говорить про размер — то это все игрушки :) Но если про количество источников — жить можно.
Про XML — естественно на стандартных процессорах не обработать, но скрипт груви на 2 десятка строк с подключенным sax парсером делает все в лучшем виде. Скрипты на 5 языках встроены в коробку и набор языков тех же администраторов/аналитиков: груви, житон, луа, руби…

[sshikov]

Мне сложно судить про порог — когда я впервые узнал про Camel, у меня уже было 30 лет опыта разработки. Но я думаю — он не сложный, уже по опыту пары коллег. Месяца примерно вполне хватает, чтобы вникнуть, не больше.

[vdshat]

Серьёзно?! Мы даже TechOps'ов к Nifi не подпускаем, чтоб не завалить прод., что на нем сделать просто элементарно.

[barloc]

Архитектурный надзор и большое sla — в таком виде вполне работает.

[vdshat]

Camel — один из зрелых и распространенных ETL продуктов. Основное преимущество перед другими продуктами огромное количество коннекторов. Наряду с Mule именно большое количество готовых коннекторов и удобство построния процесса делает их лидерами ETL сферы.
Создатели Nifi признают, что Camel вдохновил их.
К сильным сторонам Nifi можно отнести:

• визуальное управление процессом: можно запустить или остановить любой процессор, задать количество потоков, процессов
• возможность увидеть количество сообщение и просмотреть последние

К слабым:

• понятие визуализации у создателей весьма скудное: много ETL продуктов придумывает собственные нотации описания процессов со своими иконками вместо стандартных BPMN, DML и т.д., но показывать всё только однотипными кубиками — верх неуважения пользователя
• невозможность разработки несколькими разработчиками над одним процессом: XML записывается всегда с новыми идентификаторами процессоров, даже, если вы их не меняли — мерж только руками
• скудный набор коннекторов, даже стандартные протоколы не покрыты, например, хотите REST, получите HTTP, а дальше сами, сами. Или коннектор есть, но баги не исправляются годами
• есть очереди, но DLQ создавайте сами
• очень прожерлив: для старта 2 гига, но ничего сделать не получится
  По опыту 4 летней работы с ним…
  Если есть возможность выбрать другой продукт, то посмотрите в другую сторону.
  Складывается впечатление, что продукт отдали в open source, чтоб совсем не выбрасывать. Видно, что его основная идея — визуальное управление и мониторинг конкретных процессоров, но не потока данных в целом. Не обольщайтесь — это узкоспециализированный продукт, но не ETL, не BPM.
  Если нет возможности использовать что-то другое, то :
• создавайте маленькие процессы: пара-тройка кубиков
• всю логику переносите в процессоры, чтоб их можно было покрыть тестами
• лучше использовать Java процессоры, если не хотите решать проблемы с загрузкой классов и ресурсов в Groovy
• не разрабатывайте одну процесс группу совместно

[sshikov]

Я правильно вас понял, что если у кого-то в команде есть скажем 4 года опыта Camel, а у других опыта никакого, то NiFi нам как команде ничего не даст?

[vdshat]

Зависит от того, что вы хотите достичь. Но если вы надеетесь, что опыт Camel поможет с Nifi в интеграции, то вряд ли.

[sshikov]

Не-не. Я просто смотрю и пытаюсь выбрать. И скорее выберу Camel, потому что пока я не вижу, что бы мне такое даст NiFi, чего я не смогу на Camel запрограммировать, причем достаточно несложно.

[alian]

Насколько я понимаю, camel позволяет связывать приложения внедряя в них модули фреймворка. Если нет возможности внедриться в приложения, а есть только внешние интерфейсы получения данных (http, файлы) — тут nifi и ему подобные системы подойдут лучше.
В моей практике больше встречалось именно монолитов-источников данных.

[sshikov]

Вы не совсем правильно поняли.

>camel позволяет связывать приложения внедряя в них модули фреймворка.
Как вы себе представляете внедрение camel например в СУБД? Нет такого, не очень понимаю, откуда такое впечатление сложилось. Вы можете связать два приложения, встроив camel в оба, и общаться например по AMQP, но это какой-то весьма частный случай.

Ну и приложение camel в любом случае точно так же может получать данные по тем же http или из файлов. И никакого внедрения в другие приложения для этого не нужно.

[Ninil]

Очень интересно. Жду вторую часть