Комментарии 10
Для обработки ошибок есть Retry-процессор с настройкой penalty duration, а так же с настройкой retries_exceeded, после чего надо отправлять flowfile в порт error для анализа ошибки
Не надо failure возвращать обратно в процессор
А вообще не увидел зачем для таких задач NiFi нужен, почему просто через Airflow PostgresOperator это не сделать
Спасибо за комментарий и особенно про Retry-процессор.
На стороне заказчика не было своих DE, а аналитики и поддержка не были готовы работать с кодом DAGs и настройками соединений Airflow для новых источников.
На практике Nifi стал намного дружелюбнее для пользователей. Подробнее описал под заголовком "Особенности Apache NiFi"
1) Согласен
2) Согласен
3) Согласен
4) Локализация проблемы - да, а вот насчет простоты решения.. Придёт какой-нибудь ответ по API {"error": "400"} или просто сетевая ошибка - тут пользователю надо всё-таки разбираться в инструменте и уметь читать Java-еггоги хотя бы минимально
5) Защита? У Вас в примере все процессоры стопнуты, а если они (кроме первого) будут включены? Пока не понимаю до конца этого утверждения
6) Тоже не понимаю - вот выгрузились данные и куда-то сохранились (или произошёл UPDATE), NiFi это же ETL-инструмент, а не мониторинг, Вы предлагаете в Data Provenance смотреть что ли?)
И ещё заметил что в в примерах нет процессора GenerateFlowFile - это специально так и задумано?
Про локализацию проблем.
Пример кейса: Упала база приемник или снизилась производительность. Поддержка видит событие в системе мониторинга и может самостоятельно посмотреть на каком участке пайплайна копится очередь. Какой процессор выдает ошибки . Сколько данных перегрузилось за последние 5 минут и т.д. Мы предоставили поддержке алгоритмы диагностики которые позволяют передать проблему конкретной команде (ЦОД\БД источник\БД получатель)В Nifi есть множество ограничений для пользователя которые спасают от случайных ошибок
Например:
- Нельзя удалить очередь пока в ней есть FlowFiles
- Нельзя удалить коннектор если он где-то используется
- Нельзя удалить процессор если он связан с другим процессором и т.д.Допустим задача выгрузить данные из новой таблицы источника PG. Можно поправить запрос и разово запустить процессор. Тут же посмотреть в очереди получившийся CSV\JSON и т.д. Для аналитиков такая возможность оказалась очень полезной. Они смогли самостоятельно корректировать запросы и отслеживать преобразования данных поэтапно. Это оказалось намного прозрачнее и быстрее чем вычитывать логи задач Airflow
не очень понял как Вы собираетесь использовать GenerateFlowFile и что хотите генерировать при перегрузе данных из одного источника в другой :)
В песочнице развернуты две БД. БД источник и БД получатель. Первый процессор в пайплайнах обращается к БД источнику и перегружает данные дальше до БД получатель
Собственно предлагаю каждому заинтересованному попробовать познакомится с Nifi самостоятельно. Можете обкатать свои идеи в песочнице. Попробовать улучшить мои примеры и т.д.
Буду рад если кто-нибудь поделится своими шаблонами новых пайплайнов
GenerateFlowFile создает flowfile который уже бегает по вашим процессорам и собирает данные \ выполняет загрузку данных, пока что для меня загадка как Вы без него работаете, ну да ладно, может у нас подходы к работе в NiFi разные
4) Если есть процессорная группа под мониторинг - тогда нет вопросов
5) По идее пользователь не должен трогать работающий NiFi-поток, если он загружает данные на прод и при этом вносит изменения в real-time режиме то это как-то странно
6) Тут про мониторинг был пункт, но я понял про что Вы говорите, посмотреть данные действительно удобно, тут бесспорно :)
Не обязательно использовать flowfile как "триггер" для работы с другими процессорами. Первый процессор выполняет SQL запрос по расписанию и генерирует flowfile в котором так же можно хранить как данные так и атрибуты.
Могу только порекомендовать развернуть у себя песочницу и посмотреть самостоятельно. Возможно это натолкнет Вас на какие-то новые идеи :)
Кроме самого Nifi в тестовом стенде есть базы данных PG, файловая шара и прикручен Airflow. Все должно работать "из коробки". Если вдруг обнаружите проблемы с тестовым стендом, то постараюсь оперативно исправить их
А, в целом, как ощущения от суперсета после Qlik? А то отзывы крайне противоречивые. И почему чистый суперсет, а не отечественный BI на суперсете? Их даже несколько..
Apache NiFi как доступный ETL инструмент: кейс применения + тестовый стенд Docker