Как стать автором
Обновить

Комментарии 25

r3former Когда разбирался с NiFi так и не понял, можно ли там делать что-то типа «проектов»/«разных рабочих областей». Когда в рабочей области становится много различных DataFlow еще и не связанных между собой, навигация между ними неудобна.
Как вы с этим боретесь? Или я что то не доглядел?
Все делается на уровне process groups. Разные проекты выделяются в отдельные PGs, внутри которых подпроекты и задачи в свою очередь разделяются на другие PGs. Разделение прав делается также на уровне PGs.
Так это из-за этого у вас так чудовищно тормозит ЛК? Вчера не подгружались ни счета на оплату, ни проведенные платежи, ни информация о тарифе.
Что это за дерьмо, ребята?
На загрузку этой формы уходит МИНУТА!

image

Вам не стыдно выкатывать такой продукт? Что это — халтура или профнепригодность?
Я бы на вашем месте постеснялся на хабру лезть.
Каждый раз у меня не то что припекает, а выжигает, когда приходится сталкиваться с вашими системами.
Мне кажется, Вы не ту статью выбрали для Вашего комментария. NiFi используется в Ростелеком для загрузок данных в Hadoop, а сам Hadoop никоим образом не связан с работой интернет/IPTV/мобильной связи и веб-ресурсов Ростелеком. Hadoop для построения рекомендательных моделей, машинного обучения и всякой разной аналитики. По работе ЛК рекомендую Вам обратиться в техподдержку компании.

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

НЛО прилетело и опубликовало эту надпись здесь

Причем снежинка, как и вся статика грузятся быстро. А вот нужная инфа либо минуту, либо вообще не.

Статья неплохая. И если бы не знал всех потрохов найфая в работе даже сошло бы :)
Но:
Первое, что нам, как администраторам, не нравилось – это то, что написание конфига Flume для выполнения очередной тривиальной загрузки нельзя было доверить разработчику или аналитику, не погруженному в тонкости работы этого инструмента.

Это все сохраняется и для найфая. Вернее как, бестпрактис и стандартные шаблоны выстраданы квалифицированной командой дев+опс, но никак не первым встречным, который в первый раз увидел найфай. Он просто уронит сервер, а вместе с ним и все остальные таски на нем. Ведь у найфай нет изоляции заданий, все крутится вместе.
Вторым моментом были отказоустойчивость и масштабирование. Для тяжелых загрузок, например, по syslog, нужно было настраивать несколько агентов Flume и ставить перед ними балансировщик. Все это затем нужно было как-то мониторить и восстанавливать в случае сбоя.

Ситуация с балансировщиком остается и в случае найфая. Если у вас эндпойнт внутри кластера, то кто же будет клиентов перенаправлять на него в случае падения/обслуживания ноды?
И масштабирование у найфая весьма специфичное, только через РПГ, которые не работают внутри ПГ.
В-третьих, Flume не позволял загружать данные из различных СУБД и работать с некоторыми другими протоколами «из коробки». Конечно, на просторах сети можно было найти способы заставить работать Flume с Oracle или с SFTP, но поддержка таких «велосипедов» — занятие совсем не из приятных. Для загрузки данных из того же Oracle приходилось брать на вооружение еще один инструмент — Apache Sqoop.

Процессоров куча, а в итоге нет-нет да и предется расчехлять скрипты на груви. И не дай бог влезть в житон, более багованной штуки еще не встречал.

А так приятно видеть, что найфай набирает обороты. Не так активно конечно, как эйрфлоу, но все же. Особенно отрадно видеть сетевых ребят в первом ряду (есть у вас коллеги с ним).

Ну и добро пожаловать в чатик в телеге: @nifiusers
Спасибо за комментарий! Приятно, что нашлись те, с кем можно поделиться опытом. Приглашение в тг-канал принял, уже там)

Немного поспорю с Вами:
Это все сохраняется и для найфая. Вернее как, бестпрактис и стандартные шаблоны выстраданы квалифицированной командой дев+опс, но никак не первым встречным, который в первый раз увидел найфай. Он просто уронит сервер, а вместе с ним и все остальные таски на нем. Ведь у найфай нет изоляции заданий, все крутится вместе

Согласен, но создать темплейты в nifi на все случаи жизни и описать бестпрактисы на вики, чтобы «новичок» смог сделать простые загрузки самостоятельно — это куда проще, чем объяснять flume/sqoop, линукс и написание скриптов на bash/python. Так то и про промышленные ETL-системы можно сказать, что бестпрактисы сложных задач выстраданы и человек «с улицы» все поломает.

Ситуация с балансировщиком остается и в случае найфая. Если у вас эндпойнт внутри кластера, то кто же будет клиентов перенаправлять на него в случае падения/обслуживания ноды?
И масштабирование у найфая весьма специфичное, только через РПГ, которые не работают внутри ПГ.

1. Если процессор предоставляет именно эндпоинт, то балансировщик нужен как и в случае flume. Если мы говорим про загрузку данных из kafka/hdfs/чего угодно, то все это как правило масштабируется в nifi.
2. РПГ уже не нужен для балансировки для случая, когда трафик идет с primary node. Это пофиксили в версии 1.8 и теперь балансировка работает на уровне connection, пруф. Про то, что РПГ не работают внутри ПГ — не очень понял. У меня в ПГ работает РПГ сейчас, что не так я делаю?
Согласен, но создать темплейты в nifi на все случаи жизни и описать бестпрактисы на вики, чтобы «новичок» смог сделать простые загрузки самостоятельно — это куда проще, чем объяснять flume/sqoop, линукс и написание скриптов на bash/python.

И тут мы приходим к Apache Kylo :)
Многое, конечно, зависит от. Я наблюдал как опытный девопс делал первый етл на Nifi и получилось достаточно плохо. Оно работало, но без погружения именно в тонкости nifi — работало плохо и завешивало все серверы кластера.
И все равно внутри обмазано житонами, кафками и всякими секьюрными штуками, чтобы разобраться в которых нужна опсовская практика :)
Если мы говорим про загрузку данных из kafka/hdfs/чего угодно, то все это как правило масштабируется в nifi.

Не понял слова масштабируется в этом контексте. У меня опыт версии 1.2 — но масштабирования там особо нет, или все на примари, или РПГ.
РПГ уже не нужен для балансировки для случая, когда трафик идет с primary node. Это пофиксили в версии 1.8 и теперь балансировка работает на уровне connection, пруф.

А вот это круто. Как раз готовимся к миграции на 1.8. Значимый бонус, если это так.
Не понял слова масштабируется в этом контексте. У меня опыт версии 1.2 — но масштабирования там особо нет, или все на примари, или РПГ.

Kafka всеми нодами забирается без проблем, там же консамер группы. А hdfs/sftp, если говорить про чтение, с primary-ноды, потом через РПГ все разлетается на другие ноды. Если про запись говорить, то это из коробки работает, считай что пишется в несколько потоков в дестинейшн.
Kafka всеми нодами забирается без проблем, там же консамер группы. А hdfs/sftp, если говорить про чтение, с primary-ноды, потом через РПГ все разлетается на другие ноды. Если про запись говорить, то это из коробки работает, считай что пишется в несколько потоков в дестинейшн.

Понятно, я то надеялся какой-то интересный механизм впилили, а все осталось примерно по разному :)
За Kylo отдельное спасибо. Интересный проект и совсем молодой в этой индустрии. Я так понял, что он работает поверх NiFi и включает его в себя.
Нашлепка поверх найфая, которую можно отдать пользователям и в которую ты забиваешь как раз свои шаблоны и бестпрактис.
То есть позволяет ее дать малоопытным пользователям или ДС, которые сами смогут строить свои флоу. И при этом будет не так страшно, как на продовом кластере найфая.
В чатике дата инженеров есть Антон из Терадаты, у него хороший опыт с kylo.
«чатик дата инженеров» — это где, в телеграмме?

Спасибо за развернутый комментарий, теперь я напуган вот этой фразой:

" Ведь у найфай нет изоляции заданий, все крутится вместе. "

И ни слова о том, что процессоры для NiFi можно самим написать. Правда документалки по этому делу маловато. Т.е. она как бы есть, но когда начинаешь реально делать, то оказывается, что многие моменты просто не описаны. Например, нужен ли AtomicReference для объектов и как правильно его сделать, чтобы все копии процесса по кластерам использовали только один объект, а не создавали его заново и т.п.
В статье об этом есть информация:
Работа с конкретной СУБД реализуется за счет добавление соответствующего JDBC-драйвера. Есть API для написания своего модуля в качестве дополнительного приемника или преобразователя данных. Примеры можно найти здесь и здесь.

Предположу, что место для этого абзаца получилось не самым лучшим, и Вы не заметили. Подробно эту тему я не раскрывал, так как это все же краткий обзор. Информации местами действительно не хватает, но многие вещи описаны на портале Hortonworks и в mailing lists.
Я видел эти «здесь и здесь». Для очень простого процессора это пойдёт, для сложного прихдится копаться в документации, но она, как я уже упомянул, оставляет желать лучшего по некоторым специфическим вопросам.

PS. У меня процессоры для HL7 и FHIR — конвертация из одного формата в другой, валидация, динамические аттрибуты и прочее подобное.
Ради интереса подскажтие, большой выигрыш в скорости по сравнению с скриптованием внутри ExecuteScript скажем на груви?
С документацией полный швах, по апи скриптов раньше было 3 заметки на сайте хортона и все.
>мне совсем не хотелось поддерживать зоопарк решений
Хм. Не вижу в sqoop ничего сложного. Если у вас много баз данных — то это вполне себе несложное решение (со своими ограничениями, разумеется).
Речь не про сложность sqoop, а про совокупность решений. NiFi заменяет flume + sqoop + скрипты. Ведь куда приятнее работать с однородной инфраструктурой, а не когда у Вас на каждый чих отдельное решение.
Да это понятно, но это все все равно до определенного момента. Нам уж как информатику хвалили, как универсальное решение, но постепенно народ нахлебался, и понял, что как только ты выходишь за пределы, которые авторы предусмотрели — так практически сразу и ку-ку. В этом смысле более узкоспециализированные инструменты были и будут лучше, и собрать решение из них можно более подходящее для себя (хотя возможно и большими усилиями).

P.S. Ни в коем случае не имел в виду агитировать за Sqoop. Он сам не без недостатков.
Вы не первый, от кого слышу такой отзыв про informatica) С NiFi у нас хронология несколько иная. Сначала долго тестировали и игрались, а уже потом начали переносить все продакшн-флоу на него. И ожидания от NiFi совершенно не те были, что от informatica. Для нас NiFi — это больше EL, чем ETL. Поэтому пока довольны.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий