Comments 15
Слушайте, ну это так плохо, что просто "плохо". Ну ладно общая оверэнженернутость подхода в данном случае, пример учебный, спишем на это. Но блин, вы запускаете 4 своих потока асинхронно, и надеетесь, что они всегда дадут 4 flow-file'а. А если нет? Если трафик обновления в таблицах разный? Пуф! Вы пролюбили данные.
А если кто-то остановил процессоры после первого инсерта? Пуф, вы пролюбили данные - следующий флоуфайл запустит truncate.
А если трафик изменений в таблицах действительно высокий? Пуф! Вы пролюбили данные - цепочка обработки не ждет прохождения каждого отдельного flow-file'а от начала и до конца.
Если БЫ вы использовали запуск по крону - этих проблем бы не было, но чистить временные данные "in general" все равно лучше после того, как завершили запись, а не до.
Если вы уверены, что на каждый запуск у вас будут данные по всем четырем потокам - зачем вам тут скрипты? Используйте merge с min files = max files = 4 и expiration на очереди.
Если у вас четыре идентичных потока обработки - не надо их контрол-цэ контрол-вэ - извлекли данные из таблиц - запускайте их в общий поток с параметризацией - под нагрузкой окупится.
Ну и опять же - обработка ошибок, алертинг... не-еет, "такая цифровая трансформация нам не нужен"(Цы).
Но блин, вы запускаете 4 своих потока асинхронно, и надеетесь, что они всегда дадут 4 flow-file'а. А если нет? Если трафик обновления в таблицах разный? Пуф! Вы пролюбили данные.
А если кто-то остановил процессоры после первого инсерта? Пуф, вы пролюбили данные - следующий флоуфайл запустит truncate.
А если трафик изменений в таблицах действительно высокий? Пуф! Вы пролюбили данные - цепочка обработки не ждет прохождения каждого отдельного flow-file'а от начала и до конца.
Если БЫ вы использовали запуск по крону - этих проблем бы не было, но чистить временные данные "in general" все равно лучше после того, как завершили запись, а не до.
Проблема с количеством Flow Files очевидна. Конечно, мы потеряем данные, если их будет меньше четырех штук. Но в данном случае мы принимаем, что источник всегда будет отдавать новые записи.
В данной статье не говориться, что запуск потоков руками - это то, как нужно работать с данными процессорами. Стоило об этом написать, но в текущей статье подразумевается то, что процессоры будут запускаться одновременно с определенной периодичностью, которую мы можем самостоятельно настроить. Это обезопасит нас от повторных запусков и от преждевременного затирания данных.
Если вы уверены, что на каждый запуск у вас будут данные по всем четырем потокам - зачем вам тут скрипты? Используйте merge с min files = max files = 4 и expiration на очереди.
Использование скриптов объясняется желанием показать, что такая функциональность присутствует, а также показать на простом примере, как эти скрипты могут выглядеть.
Если у вас четыре идентичных потока обработки - не надо их контрол-цэ контрол-вэ - извлекли данные из таблиц - запускайте их в общий поток с параметризацией - под нагрузкой окупится.
По поводу общего потока согласны. Так как в данном случае мы получаем имя таблицы, которую захватываем + имеется возможность добавить атрибут, который более точно определял бы источник, мы могли бы реализовать процесс Truncate'а и записи через один процессор. Но нужно проверить, действительно ли это более оптимальное решение.
Ну и опять же - обработка ошибок, алертинг... не-еет
Тема данной статьи не связана с обработкой ошибок, настройкой алертинга и т. д. Эти вещи, безусловно, необходимы, но в текущей статье не требуют разработки и упоминания.
Всё настолько плохо, что даже ещё хуже.
Взял таблицу с почти миллионом записей, вытащил из неё данные за год(80к), дважды(покупатель, продавец) поженил на таблицу с контрагентами, в которой 150к строк, дважды поженил на таблицу с договорами(10к строк), всё это select into в таблицу, которую перед этим грохнул... Результат без дополнительных оптимизаций - 2 сек.
Заворачиваем в хранимку и ставим задание Агенту SQL сервера. Вуаля.
Вопрос - зачем вообще вытаскивать данные с сервера, если их надо туда же положить?
Сравнивать Airflow с NiFi??? Это же инструменты совсем разных классов! Красное с круглыми...
cron vs awk: исследуем инструменты для парсинга логов
А почему нет-то? И то, и другое - решения класса ETL - то, что подход для решения задач выбран ОЧЕНЬ разный, и, как следствие, "локальные оптимумы" в массиве решаемых проблем разложены сильно по разному - но они определенно пересекаются.
Есть классы задач, которые одинаково эффективно решаются обоими инструментами (Злые языки говорят, что без них - даже быстрее) - и в эту сторону было бы интересно посравнивать. С моей т.з. тут проблема именно в самом сравнении.
Вот как раз нет. Airflow - это оркестратор в первую очередь. A NiFi - да, ETL - инструмент. Из-за непонимании этого различия у автора по тексту и встречается дичь вида
... Airflow в отличие от NiFi нет механизма инкрементальной загрузки «из коробки»..
Ну а так, в телегу можно запрячь и корову, а шурупы закручивать ножницами. И при этом даже результат приемлемый может получиться. Но статья "Корова или лошадь - кого лучше запрячь в телегу?" наверное все же не для "Сельского Весника", а для "Крокодила".
Ну, в FAQ у них все еще осталось "Airflow was developed as a solution for ETL needs."
Вот сравнивать NiFi и прости оссспыдя, Camunda'у - таки да, было бы странно (Хотя ETL проект на последней я видел, бррр!) - а тут не вижу прям криминала.
"solution for ETL needs " <> "ETL-tool". А так cron - тоже можно использовать "for ETL needs" :)))
Разница между хорошим специалистом и просто специалистом именно в понимании сути и нюансов. Никого не хочу обидеть, но прямое сравнение Airflow и NiFi допустимо для вчерашнего вупускника курса "войти в ИТ", но не в блоге уважаемой компании
Ну, определенного рода казуистика уже :). Крон можно использовать "for ETL needs" - но он определенно не developed as solution for :)
Если что, в документации NiFi аббревиатура "ETL" вообще не упоминается:
"What is Apache NiFi?
Put simply, NiFi was built to automate the flow of data between systems."
Предлагаю зафиксировать common ground:
NiFi и Airflow ДОХРЕНА разные инструменты и выбирать между ними _без учета специфики задач_ - ну прям очень такоЭ.
Вне зависимости от корректности сравнения per se - сама статья - ну, этакоЭ
Если смотреть глубже - да, инструменты заточены под решение разных задач. Но в данном случае рассматривается конкретная задача, которая может быть решена обоими способами. Суть задачи максимально упрощена. Необходимо было показать - что могут предложить эти инструменты.
Уже в дальнейшем, исходя из бизнес-задач, которые могут возникать, мы можем здраво оценить, что будет предпочтительнее выбрать.
Airflow vs NiFi: исследуем оркестратор для формирования витрин данных