Не обязательно использовать flowfile как "триггер" для работы с другими процессорами. Первый процессор выполняет SQL запрос по расписанию и генерирует flowfile в котором так же можно хранить как данные так и атрибуты.
Могу только порекомендовать развернуть у себя песочницу и посмотреть самостоятельно. Возможно это натолкнет Вас на какие-то новые идеи :) Кроме самого Nifi в тестовом стенде есть базы данных PG, файловая шара и прикручен Airflow. Все должно работать "из коробки". Если вдруг обнаружите проблемы с тестовым стендом, то постараюсь оперативно исправить их
Про локализацию проблем. Пример кейса: Упала база приемник или снизилась производительность. Поддержка видит событие в системе мониторинга и может самостоятельно посмотреть на каком участке пайплайна копится очередь. Какой процессор выдает ошибки . Сколько данных перегрузилось за последние 5 минут и т.д. Мы предоставили поддержке алгоритмы диагностики которые позволяют передать проблему конкретной команде (ЦОД\БД источник\БД получатель)
В Nifi есть множество ограничений для пользователя которые спасают от случайных ошибок Например: - Нельзя удалить очередь пока в ней есть FlowFiles - Нельзя удалить коннектор если он где-то используется - Нельзя удалить процессор если он связан с другим процессором и т.д.
Допустим задача выгрузить данные из новой таблицы источника PG. Можно поправить запрос и разово запустить процессор. Тут же посмотреть в очереди получившийся CSV\JSON и т.д. Для аналитиков такая возможность оказалась очень полезной. Они смогли самостоятельно корректировать запросы и отслеживать преобразования данных поэтапно. Это оказалось намного прозрачнее и быстрее чем вычитывать логи задач Airflow
не очень понял как Вы собираетесь использовать GenerateFlowFile и что хотите генерировать при перегрузе данных из одного источника в другой :) В песочнице развернуты две БД. БД источник и БД получатель. Первый процессор в пайплайнах обращается к БД источнику и перегружает данные дальше до БД получатель
Собственно предлагаю каждому заинтересованному попробовать познакомится с Nifi самостоятельно. Можете обкатать свои идеи в песочнице. Попробовать улучшить мои примеры и т.д. Буду рад если кто-нибудь поделится своими шаблонами новых пайплайнов
На стороне заказчика не было своих DE, а аналитики и поддержка не были готовы работать с кодом DAGs и настройками соединений Airflow для новых источников.
На практике Nifi стал намного дружелюбнее для пользователей. Подробнее описал под заголовком "Особенности Apache NiFi"
К сожалению сам суперсет мне потрогать не пришлось :)
На сколько понял BI Аналитики заказчика перешли без особых проблем
Что там было глубже, например с производительность, к сожалению не знаю
Не обязательно использовать flowfile как "триггер" для работы с другими процессорами. Первый процессор выполняет SQL запрос по расписанию и генерирует flowfile в котором так же можно хранить как данные так и атрибуты.
Могу только порекомендовать развернуть у себя песочницу и посмотреть самостоятельно. Возможно это натолкнет Вас на какие-то новые идеи :)
Кроме самого Nifi в тестовом стенде есть базы данных PG, файловая шара и прикручен Airflow. Все должно работать "из коробки". Если вдруг обнаружите проблемы с тестовым стендом, то постараюсь оперативно исправить их
Про локализацию проблем.
Пример кейса: Упала база приемник или снизилась производительность. Поддержка видит событие в системе мониторинга и может самостоятельно посмотреть на каком участке пайплайна копится очередь. Какой процессор выдает ошибки . Сколько данных перегрузилось за последние 5 минут и т.д. Мы предоставили поддержке алгоритмы диагностики которые позволяют передать проблему конкретной команде (ЦОД\БД источник\БД получатель)
В Nifi есть множество ограничений для пользователя которые спасают от случайных ошибок
Например:
- Нельзя удалить очередь пока в ней есть FlowFiles
- Нельзя удалить коннектор если он где-то используется
- Нельзя удалить процессор если он связан с другим процессором и т.д.
Допустим задача выгрузить данные из новой таблицы источника PG. Можно поправить запрос и разово запустить процессор. Тут же посмотреть в очереди получившийся CSV\JSON и т.д. Для аналитиков такая возможность оказалась очень полезной. Они смогли самостоятельно корректировать запросы и отслеживать преобразования данных поэтапно. Это оказалось намного прозрачнее и быстрее чем вычитывать логи задач Airflow
не очень понял как Вы собираетесь использовать GenerateFlowFile и что хотите генерировать при перегрузе данных из одного источника в другой :)
В песочнице развернуты две БД. БД источник и БД получатель. Первый процессор в пайплайнах обращается к БД источнику и перегружает данные дальше до БД получатель
Собственно предлагаю каждому заинтересованному попробовать познакомится с Nifi самостоятельно. Можете обкатать свои идеи в песочнице. Попробовать улучшить мои примеры и т.д.
Буду рад если кто-нибудь поделится своими шаблонами новых пайплайнов
Спасибо за комментарий и особенно про Retry-процессор.
На стороне заказчика не было своих DE, а аналитики и поддержка не были готовы работать с кодом DAGs и настройками соединений Airflow для новых источников.
На практике Nifi стал намного дружелюбнее для пользователей. Подробнее описал под заголовком "Особенности Apache NiFi"