Про camel было бы интересно послушать.
Сейчас Nifi достаточно прочно занял нишу бесплатного EL данных, даже среди энтерпрайза — сужу по московскому митапу и активности комьюнити. А вот про Camel никогда и ни от кого не слышал.
Может дело в том, что степень вхождения в Nifi много ниже — как правило администраторы/аналитики способны управиться, нет никакого программирования включая написание конфигов (до поры, до времени :).
Спасибо, хорошая работа. Недавно читал фрикономику, там было про число случайных смертей детей от оружия в доме или утопления в домашних бассейнах — бассейны конечно выиграли.
Так и тут, внезапно города Дагестана оказались одними из самых безопасных по сравнению с суровым Забайкальем.
Очень интересно было бы послушать чем плох мезос с марафоном и чем так хорош кубернетис. Кроме хайпа и вроде бы исключения девопсов из пайплайна выкатки.
Можно даже отдельной статьёй :)
Странные альтернативы.
Ну ладно, разве что гитлаб подходит.
Но как только пайплайн в гитлабе выходит за пределы стандартной сложности начинаются пляски с шаблонами, переменными, ямлом и привет полтыщи строк вместо 50-100 в дженкинсе.
>На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Хороший вопрос про кафку. Вот только после пробы кафки автор доклада вернулся бы на свою схему. На большом потоке чтение из кафки становится проблемой.
И непонятно почему не юдп. Это логи, можно терять какую-то часть. Ценность невелика.
Нашлепка поверх найфая, которую можно отдать пользователям и в которую ты забиваешь как раз свои шаблоны и бестпрактис.
То есть позволяет ее дать малоопытным пользователям или ДС, которые сами смогут строить свои флоу. И при этом будет не так страшно, как на продовом кластере найфая.
В чатике дата инженеров есть Антон из Терадаты, у него хороший опыт с kylo.
Kafka всеми нодами забирается без проблем, там же консамер группы. А hdfs/sftp, если говорить про чтение, с primary-ноды, потом через РПГ все разлетается на другие ноды. Если про запись говорить, то это из коробки работает, считай что пишется в несколько потоков в дестинейшн.
Понятно, я то надеялся какой-то интересный механизм впилили, а все осталось примерно по разному :)
Ради интереса подскажтие, большой выигрыш в скорости по сравнению с скриптованием внутри ExecuteScript скажем на груви?
С документацией полный швах, по апи скриптов раньше было 3 заметки на сайте хортона и все.
Согласен, но создать темплейты в nifi на все случаи жизни и описать бестпрактисы на вики, чтобы «новичок» смог сделать простые загрузки самостоятельно — это куда проще, чем объяснять flume/sqoop, линукс и написание скриптов на bash/python.
И тут мы приходим к Apache Kylo :)
Многое, конечно, зависит от. Я наблюдал как опытный девопс делал первый етл на Nifi и получилось достаточно плохо. Оно работало, но без погружения именно в тонкости nifi — работало плохо и завешивало все серверы кластера.
И все равно внутри обмазано житонами, кафками и всякими секьюрными штуками, чтобы разобраться в которых нужна опсовская практика :)
Если мы говорим про загрузку данных из kafka/hdfs/чего угодно, то все это как правило масштабируется в nifi.
Не понял слова масштабируется в этом контексте. У меня опыт версии 1.2 — но масштабирования там особо нет, или все на примари, или РПГ.
РПГ уже не нужен для балансировки для случая, когда трафик идет с primary node. Это пофиксили в версии 1.8 и теперь балансировка работает на уровне connection, пруф.
А вот это круто. Как раз готовимся к миграции на 1.8. Значимый бонус, если это так.
Статья неплохая. И если бы не знал всех потрохов найфая в работе даже сошло бы :)
Но:
Первое, что нам, как администраторам, не нравилось – это то, что написание конфига Flume для выполнения очередной тривиальной загрузки нельзя было доверить разработчику или аналитику, не погруженному в тонкости работы этого инструмента.
Это все сохраняется и для найфая. Вернее как, бестпрактис и стандартные шаблоны выстраданы квалифицированной командой дев+опс, но никак не первым встречным, который в первый раз увидел найфай. Он просто уронит сервер, а вместе с ним и все остальные таски на нем. Ведь у найфай нет изоляции заданий, все крутится вместе.
Вторым моментом были отказоустойчивость и масштабирование. Для тяжелых загрузок, например, по syslog, нужно было настраивать несколько агентов Flume и ставить перед ними балансировщик. Все это затем нужно было как-то мониторить и восстанавливать в случае сбоя.
Ситуация с балансировщиком остается и в случае найфая. Если у вас эндпойнт внутри кластера, то кто же будет клиентов перенаправлять на него в случае падения/обслуживания ноды?
И масштабирование у найфая весьма специфичное, только через РПГ, которые не работают внутри ПГ.
В-третьих, Flume не позволял загружать данные из различных СУБД и работать с некоторыми другими протоколами «из коробки». Конечно, на просторах сети можно было найти способы заставить работать Flume с Oracle или с SFTP, но поддержка таких «велосипедов» — занятие совсем не из приятных. Для загрузки данных из того же Oracle приходилось брать на вооружение еще один инструмент — Apache Sqoop.
Процессоров куча, а в итоге нет-нет да и предется расчехлять скрипты на груви. И не дай бог влезть в житон, более багованной штуки еще не встречал.
А так приятно видеть, что найфай набирает обороты. Не так активно конечно, как эйрфлоу, но все же. Особенно отрадно видеть сетевых ребят в первом ряду (есть у вас коллеги с ним).
Ну и добро пожаловать в чатик в телеге: @nifiusers
Сейчас Nifi достаточно прочно занял нишу бесплатного EL данных, даже среди энтерпрайза — сужу по московскому митапу и активности комьюнити. А вот про Camel никогда и ни от кого не слышал.
Может дело в том, что степень вхождения в Nifi много ниже — как правило администраторы/аналитики способны управиться, нет никакого программирования включая написание конфигов (до поры, до времени :).
Так и тут, внезапно города Дагестана оказались одними из самых безопасных по сравнению с суровым Забайкальем.
Выдержал примерно месяц дох. Задержки адовые, 3 из 10 запросов не возвращают записи. Если такое включат, пользователи взвоют.
Очень интересно было бы послушать чем плох мезос с марафоном и чем так хорош кубернетис. Кроме хайпа и вроде бы исключения девопсов из пайплайна выкатки.
Можно даже отдельной статьёй :)
Ну ладно, разве что гитлаб подходит.
Но как только пайплайн в гитлабе выходит за пределы стандартной сложности начинаются пляски с шаблонами, переменными, ямлом и привет полтыщи строк вместо 50-100 в дженкинсе.
Отличное обоснование :)
Стоит заметить, что это команда сеньоров. При попадании в нее слабых в профессиональном смысле людей все станет хуже.
Того, кто еще больше должен общаться с людьми со всех сторон? :)
От разработчиков до генеральных директоров )
Странный выбор, учитывая что в последнем запросе кх просто упал. То есть у вас неполный функционал, зато быстро. Джойны, словари обошли стороной.
Посмотрите что происходит с КХ в режиме вставки около 1,5 млн/сек в реплицированные таблицы. Как раз верхняя граница буфера чуть больше 1 млн.
>Что касается эффективности представления данных на диске, то CH хранит данные по-колоночно со сжатием — придумать что-либо эффективнее сложно.
Поколоночно и с сжатием хранят все, для спарка аж 2 формата — паркет и орц так хронят. В кх еще есть сортировка.
И непонятно почему не юдп. Это логи, можно терять какую-то часть. Ценность невелика.
Глаз тоже резануло.
А с другой стороны уметь то умеет, вопрос как умеет. Не зря все обвешаны го-консумерами со всех сторон.
То есть позволяет ее дать малоопытным пользователям или ДС, которые сами смогут строить свои флоу. И при этом будет не так страшно, как на продовом кластере найфая.
В чатике дата инженеров есть Антон из Терадаты, у него хороший опыт с kylo.
Понятно, я то надеялся какой-то интересный механизм впилили, а все осталось примерно по разному :)
С документацией полный швах, по апи скриптов раньше было 3 заметки на сайте хортона и все.
И тут мы приходим к Apache Kylo :)
Многое, конечно, зависит от. Я наблюдал как опытный девопс делал первый етл на Nifi и получилось достаточно плохо. Оно работало, но без погружения именно в тонкости nifi — работало плохо и завешивало все серверы кластера.
И все равно внутри обмазано житонами, кафками и всякими секьюрными штуками, чтобы разобраться в которых нужна опсовская практика :)
Не понял слова масштабируется в этом контексте. У меня опыт версии 1.2 — но масштабирования там особо нет, или все на примари, или РПГ.
А вот это круто. Как раз готовимся к миграции на 1.8. Значимый бонус, если это так.
Но:
Это все сохраняется и для найфая. Вернее как, бестпрактис и стандартные шаблоны выстраданы квалифицированной командой дев+опс, но никак не первым встречным, который в первый раз увидел найфай. Он просто уронит сервер, а вместе с ним и все остальные таски на нем. Ведь у найфай нет изоляции заданий, все крутится вместе.
Ситуация с балансировщиком остается и в случае найфая. Если у вас эндпойнт внутри кластера, то кто же будет клиентов перенаправлять на него в случае падения/обслуживания ноды?
И масштабирование у найфая весьма специфичное, только через РПГ, которые не работают внутри ПГ.
Процессоров куча, а в итоге нет-нет да и предется расчехлять скрипты на груви. И не дай бог влезть в житон, более багованной штуки еще не встречал.
А так приятно видеть, что найфай набирает обороты. Не так активно конечно, как эйрфлоу, но все же. Особенно отрадно видеть сетевых ребят в первом ряду (есть у вас коллеги с ним).
Ну и добро пожаловать в чатик в телеге: @nifiusers