Комментарии 13
Маша, статья супер. Еще бы картинки кликабельные, чтобы можно было потоки рассмотреть.
Спасибо за статью!
Подскажите, я правильно понял, что именно визуализация самого алгоритма подкупила использование?
Или именно встроенность существующих функционала как отправка и крон?
Мы можем в любой момент остановить любой поток, внести правку и запустить заново.
То есть, мы по факту выпустили релиз кода, но при этом нигде это не отразилось? И возможно никто никогда не узнает, что поток изменили? И не узнает, что изменили? И почему? И даже jira на это изменение не заведет никто, и уж тем более — эта задачка в jira в коде не отразится (потому что в Git изменение тоже не положили)? Я правильно понимаю, что вы работаете с кодом без его версионирования?
Архитектура на ладони.
Да-да. Пока влезает в один экран — кажется что так оно и есть. Потом — в один лист А0 в напечатанном виде. Потом это впечатление вообще пропадает. Проходили, причем много раз. UML, BPM — им просто нет числа, таким языкам и нотациям. Вам кажется, что вы видите свои процессы в виде картинки — а потом выясняется, что для реального понимания, как они работают, нужно посмотреть какое-то свойство у квадратика или стрелочки. И вот на этом все «понимание» архитектуры обычно и заканчивается.
То есть, мы по факту выпустили релиз кода, но при этом нигде это не отразилось?
Не совсем. Как я и говорила в статье, NiFi не про разработку, а про архитектуру. В последней часто происходят изменения. Меняются ip, версии сервисов, которые мы дергаем и т.д. Такие правки обычное дело, но менять из-за них каждый раз код, согласитесь, напрягает. Лучше вынести в NiFi.
Вам кажется, что вы видите свои процессы в виде картинки — а потом выясняется, что для реального понимания, как они работают, нужно посмотреть какое-то свойство у квадратика или стрелочки.
Для этого существует документирование. Внятные названия процессоров и каменты маст хев. Также разбивка на группы процессов поможет не потеряться.
>Не совсем. Как я и говорила в статье, NiFi не про разработку, а про архитектуру.
Не, ну смотрите — вы можете это назвать как угодно, но если там есть IP или url коннекта — это код. Или как это нынче модно — инфраструктура as code. Как ни называй, но если вы это меняете вот так вот без версионирования — это может рано или поздно выстрелить. Потому что вчера кто-то там поменял, и ушел в отпуск, забыв документировать. А если бы оно проходило через git, как это следует делать — то там были бы и версии, и ссылка на jira (а с чего собственно вы меняете ip на проме сервисе, по какому такому поводу — где задача-то?), и все остальное. А дальше pull request, согласование, в общем — полноценный процесс взрослой зрелой разработки.
Скажем, в нашей большой распределенной команде за такое изменение конфигов прома могут дать по шапке — и будут правы.
Что в общем не отменяет возможности того, что в вашем проекте в силу его специфики, размеров, размеров команды и ее квалификации такое вполне может работать. До поры до времени…
Не, ну смотрите — вы можете это назвать как угодно, но если там есть IP или url коннекта — это код. Или как это нынче модно — инфраструктура as code. Как ни называй, но если вы это меняете вот так вот без версионирования — это может рано или поздно выстрелить. Потому что вчера кто-то там поменял, и ушел в отпуск, забыв документировать. А если бы оно проходило через git, как это следует делать — то там были бы и версии, и ссылка на jira (а с чего собственно вы меняете ip на проме сервисе, по какому такому поводу — где задача-то?), и все остальное. А дальше pull request, согласование, в общем — полноценный процесс взрослой зрелой разработки.
Скажем, в нашей большой распределенной команде за такое изменение конфигов прома могут дать по шапке — и будут правы.
Что в общем не отменяет возможности того, что в вашем проекте в силу его специфики, размеров, размеров команды и ее квалификации такое вполне может работать. До поры до времени…
Маша, подскажите а как вы выбирали эту тулзу?
Пробовали рассмотреть Talend? Тоже неплохая тулза для etl и визуализирует процесс .
Мы выбирали с упором на мощность и удобства работы с биг дата. У нас NiFi используют и девопсы и админы и я со своей аналитикой )
А что в вашем понимании есть bigdata? Дело в том, что у нас NiFi тоже есть, для определенных задач, и я бы сказал, что по сравнению скажем со Spark он не масштабируется никак. Ну т.е. вы можете конечно наращивать размеры кластера, но когда рядом стоит хадуп кластер из 100 узлов, и Spark масштабируется динамически от 1 ядра до всех 100 узлов, а рядом NiFi — и его размер фиксирован, и вот так просто не растет, если сегодня вдруг лишний терабайт прибежал — то это грустно.
И на хадуп его никто не разворачивает, потому что у него же планировщик задач свой, и как он будет жить с ярн — непонятно. Насколько я знаю, на ярне он работать не умеет.
И на хадуп его никто не разворачивает, потому что у него же планировщик задач свой, и как он будет жить с ярн — непонятно. Насколько я знаю, на ярне он работать не умеет.
Talend дорогой немного получается — NiFi открытый и бесплатный. Отлично разворачивается где угодно.
Я пользую нифи уже 3 года — отличный инструмент, единственное, что трансформацию данных я бы на нем не делал, а использовал бы для этого другие мощности.
Я пользую нифи уже 3 года — отличный инструмент, единственное, что трансформацию данных я бы на нем не делал, а использовал бы для этого другие мощности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация аналитики Jira средствами Apache NiFi