Comments 9
Дорогой автор, я ни в коей мере не считаю себя экспертом, но генерировать код из базы, на мой взгляд ничем не лучше чем создавать DAG-и по конфигу, который, как минимум легко обрабатывать существующими инструментами разработки.
Объясните в чем смысл, пожалуйста?
А то Вы пишите, что думал-думал и придумал, а зачем весь изврат не пишите. В том-то и прелесть AirFlow и прочих управляшек заданиями, что они управляшки, а логику обработки данных в каждом задании можно кастомизировать… а если логика укладывается в общую канву, отличаясь запросами, то мне кажется и AirFlow может быть не нужен.
Может тут бы людям хватило просто ClickHouse и дашборда типа Tableau.
Суммирую. Мне кажется, Вам не удалось объяснить ценность и достоинства вашего подхода.
Добрый день.
Спасибо за ваш комментарий.
Отвечу сразу на два комментария.
На момент реализации данного решения нас это устраивало и сейчас устраивает, так как основной оркестратор в компании – это Airflow
Да, возможно, и изврат, но об этом также написано, что это решение моего бизнес-кейса. Возможно в дальнейшем он покажет свою несостоятельность и мы его изменим, когда увеличится список компетенций и/или технологий.
У меня не было задачи "продавать" данное решение. Оно не идеальное, но оно отвечает нашему запросу. Оно работает и приносит пользу – для нас это главное.
Возможно в будущем я сделаю часть "два", в которой раскритикую своё предложение и покажу что-то другое. На текущий момент – это описание моего опыта и бизнес-кейса.
Не стоит писать, если нет цели «продать» статью читателю, это просто трата и своего и чужого времени в духе «зафига дофига нафигачили». Ваш императив, приведший Вас к этому решению из статьи не ясен. Любая архитектура делается с учетом pros/cons и требований.
Если я спрошу «почему суп ложкой едят?». Вы мне ответите и кто угодно ответит - это общеизвестное знание, но Ваша архитектура не самоочевидна, а статья не отвечает на вопрос «почему и зачем она такая?».
Обычно, людям сначала интересно «зачем», а потом «как».
Более того, чем больше думаю о решении, тем больше мне кажется, что Вы не смогли именно смысл решения правильно читателю «продать».
Ожидалось почитать что-то новое про DAG, в итоге статья про работу с airflow :(
Лично мне как человеку, кто регулярно отвечает на вопросы произволительности Airflow, в данной статье явно не хватает указания следующих ссылок на документацию:
Optimizing DAG parsing delays during execution, эксперементальный функционал, но шанс что он останется значительно выше, чем у того, что MsSQL останется в качестве DB Backend для Airflow
Потому как если кто-то попробует повторить этот эксперимент, он может легко столкнуться с проблемой, что Airflow начнет заспамливать базу по интервалу сканирования DAGов. Поэтому еще оставлю ссылку на тюнинг планировщика Airflow
Ну и еще от себя добавляю, официальный Docker Compose файл для Airflow существует чисто для того, чтобы пользователь мог запустить и сказать "Вау! Это действительно работает!"
Я конечно не дата-инженер, хотя много работал с данными, но на первый взгляд все же проще засунуть данные в json и положить в какой нибудь аналог mongoDB. А дальше уже можно делать с данными все что угодно. Если я не прав, поясните почему.
Такой дизайн плохо масштабируем. На основании документации:
You should avoid writing the top level code which is not necessary to create Operators and build DAG relations between them. This is because of the design decision for the scheduler of Airflow and the impact the top-level code parsing speed on both performance and scalability of Airflow.
Specifically you should not run any database access, heavy computations and networking operations.
Как альтернатива - хранить код as is в Git и считывать его при выполнении таска
не требуется никакого дополнительного UI
проверенная и 100% рабочая версионность
управление жизненным циклом и весь сопутствующий воркфлоу по внесению изменений
при добавлении нового KPI вместо инсерта в табличку добавляется скрипт и ID метрики в генератор дагов - то, что Вы получаете селектом можно заимпортить как нативный Python-объект/dict из файла настроек метрики
Для управления всем из одной точки с версии 2.3.0 можно использовать dynamic task mapping. В смепленные таски передавать нужные sql-запросы и идентификаторы, а управление поручить запускаемому каждые N минут DAGу. Для определения, какие метрики считать в конкретном запуске, а какие нет, можно использовать поставляемый из коробки croniter.
Таблица-справочник – генератор DAG? А что так можно было?