Комментарии 14
Было бы неплохо интро сделать про иерархию объектов в пайплайне. Типа, процессор, процессорная группа ...
Было бы не плохо допинать разрабов NiFi (Cloudera, которая предлагает NiFi как бесплатную замануху для своих cloud-based фигни) на создание групп процессов, которые можно вызывать из других процессов. Тогда одно и то же можно будет вызывать из разных мест и не тянуть все эти линии. Сейчас я это делаю с InvokeHTTP, это всё равно как гланды через *опу автогеном.
Посмотрите в сторону NIFI Statless и Execute Statless ну и NIFI про Конвейер, а не про Процедуры, это немного ломает.
Ну, вообще - я использую kafka'у в качестве в том числе и внутреннего транспорта. Работает. Был опыт с использованием RemoteProcessGroup "к самому себе" - и это тоже работает, но в кластерных инсталляциях мне показалось проблемно.
Пожалуйста, не используйте NiFi в качестве ETL и перестаньте позиционировать в качестве такого инструмента. В этой ипостаси он неэффективен. Да, он может своими процессорами извлекать данные и ижектировать и даже траснформировать немного. Но создан он для роутинга данных. Для реально нагруженных ETL пайпланов он вреден и бесполезен.
Обоснуйте.
Вполне удобный ETL инструмент, с возможностью собственного расширения. Довольно широкий спектр задач, которые можно решить без единой строчки кода. Есть своя ниша.
Хотелось бы больше деталей.
Как по мне, замечательный инструмент для Extract Transform Load. Есть вопросы к механизму стейта (IO дисков узкое место для NIFI) Но это решаемая тема.
А для роутинга данных кажется слегка перебор.
Попытаюсь ответить вам двоим: @KlimenkoIv и @Shadilan:
В ETL задачах очень часто необходимо использовать джойны. В Nifi это делается сложно и неудобно, потому что изначально не предназначался для этого. При этом, поскольку NiFi умеет в параллельную обработку, то нужно иметь в виду, что параллельные джойны также должны быть конфигурируемы: изменять алгоритм partitionning (по ключу или хэшу, броадкаст на все ноды, распределение по модулю, и т.д.), например, чтобы избежать бесполезных перемещений (шаффлинга) части данных с ноды на ноду.
На мой взгляд Nifi удобный инструмент, если нужно приземлять в реальном времени данные из очередей, перед этим трансформировать их, скажем из json в parquet, оповестить некий сервис о пришедших данных. Возможно, даже будет удобен для микробатчей. Максимум - для заполнения Staging Area. Дальше, когда нужно запускать тяжелые батчи, вроде создания DWH или DataMart, использовать NiFi будет уже тяжеловато.
По поводу no-code ETL: такие действительно существуют, при этом вполне умеют в полноценную параллельную обработку. Например, монструозный динозавр IBM DataStage. Из бесплатных - Talend (не знаю, научились ли они в параллельную обработку, раньше не могли, но наверняка код Spark на нем можно сгенерировать).i.
Ну и обработка в flow-файлах, как вы правильно отметили, не прибавляет скорости обработки. Кроме того, насколько я помню, они даже без сжатия хранятся.
Попытаюсь вам оппонировать.
В ETL задачах очень часто необходимо использовать джойны.
В своей практике не встречал, где нужен JOIN. Если требуется на лету соединять несколько источников/потоков данных, это действительно не про NIFI. Например, Flink с этим прекрасно справится. В этом случае я всегда задаю один вопрос - вы точно уверены в выборе инструмента? Все остальные задачи решаемы за счет обогащения.
На мой взгляд Nifi удобный инструмент, если нужно приземляьть в реальном времени данные из очередей, перед этим трансформировать их, скажем из json в parquet, оповестить некий сервис о пришедших данных. Возможно, даже будет удобен для микробатчей. Максимум - для заполнения Staging Area
Вы сами говорите об области применения, где достаточно много трансформаций, параллельных процессов.
Дальше, когда нужно запускать тяжелые батчи, вроде создания DWH или DataMart, использовать NiFi будет уже тяжеловато.
Для этих целей существует другой ряд инструментария. Когда данные в Stage попали, область ответсвенности NIFI закончилась. Данные доставили. Вся последующая магия через внутренние преобразования в БД, которые окрестрируются, например, Airflow.
Ну и обработка в flow-файлах, как вы правильно отметили, не прибавляет скорости обработки. Кроме того, насколько я помню, они даже без сжатия хранятся.
Укажите кодек Avro в настройке Writer. Данные будут сжаты. Из коробки поддерживается deflate, bzip2, snappy, xz, zstandard. Т.о. контент будет занимать меньше места. Однако это влияет на обработку, т.к. для изменения записи идет их распаковка и упаковка.
Тут скорее надо говорить, что у nifi как и у любого другого инструмента есть границы применимости и классы решаемых задач в которых он эффективен. Сотни мб\сек в datalake лить - можно, но дороговато как по железу так и с т.з. "когнитивной нагрузки" на эксплуатантов.
А вот например забрать данные по персоналу с SAP HCM по шине, сконвертить из тамошнего XML, положить в три микросервиса внарезку и дообогатить данными из AD через keycloak - можно _руками джуна_. Собственно, смысл статьи в том, чтобы смотреть на результат "народного творчества" инженеров внедрения - не "разработчиков" ни в одном месте - можно было без внутренней дрожи.
Решение аналогичного рода задач "в рассыпуху" на том же airflow требует существенно большей квалификации.
В целом, можно получить полезную выжимку, как оформить свои процессорные группы, что бы потом другие не ломали себе мозг))
Интересно узнать, как поступаете с выходами с ошибками у процессоров. Когда много процессоров, то и много выходов failure, и схема с ними хуже читается.
В настоящий момент - формируем сообщение по схеме и публикуем в отдельный топик кафки через controlrate, чтобы флудинга не было. Более-менее универсальная обработка потока ошибок (Запись в лог, создание платформенных event'ов, нотификация пользователей при необходимости - вот это все) в отдельной группе процессоров. Понятно, что с ошибками, для которых нужна обработка (Откат цепочки операций, "восстановимые" ошибки и пр) этот фокус не прокатит - но в целом схемы упрощаются. Плюс - обработчик ошибок выходит переиспользуемый между проектами.
Что такое «хорошо» и что такое «плохо» в NiFi. Часть 1