Comments 6
Чтобы избежать возни с кодом, мы развели кучу возни с кодом. Теперь не нужно писать ненавистные даги на питоне, можно просто композировать блаженные даги в ямле.
Как-то сложно: класс-генератор дага, который хаком подсовываем в globals созданный даг (потому что для обнаружения нужен вызов на верхнем уровне, который отрабатывает при python -m dagfile.py), хотя можно использовать менеджер контекста with DAG(**conf) as dag: , и магическим образом все внутренние вызовы сложатся в этот даг. А для доступа к предыдущему шагу вполне "из коробки" подходит reduce. И не надо никакой класс.
Это все работает для однотипных задач с минимумом гибкости. Потому что когда-то возникнет мое любимое - передача параметров по пайплайну: в таком виде только xcom_pull с запоминанием id тасков спасет (не дай бог понадобится добавить группировку в таск группы). Ну и минус Jinja, минус питон объекты в качестве параметров (например, колбэки, кастомные расписания, динамически определяемые параметры запуска). Либо ту же Jinja прикручивать в обработчик YAML и парсить в нативные объекты. И вот мы вернулись к исходной задаче: написали YAML конфиг, написали парсер, это все преобразуется в питон объекты и генерирует даг. А можно было сразу написать питон файлы с тем же самым. Отличие только в from my.super.module import DoStuffOperator.
Наша проблема в том была, что с Python знаком только 1 разработчик. Все остальные не хоят его использовать. А инструмент нужно дать всем, ну или худобы большинству. Чтобы они самостоятельно могли ставить задачи в Airflow без привлечения Python разработчика и без понимания Python. В итоге мы пришли к тому что YAML знаю все так как плотно работают с кубами либо с Ansible. И по этому мы решили сделать такую калымбаху, чтобы Airflow могли пользоваться все, без привлечения Python разраба и без написания кода на Python
>Много кода, не все знают Python, не многие хотят с ним работать.
>Внезапно нас осенило. Ansible! Помните эту штуку? Удобную, понятную практически всем IT-шникам благодаря использованию YAML
После такого перехода пропало всякое желание читать статью дальше. Подачу материала стоило бы скорректировать на мой взгляд.
Поясняю подробно:
Популярность Ansible сама по себе сомнительна, каждый язык хорош для своей задачи.
Кто-то не хочет учить Python - поэтому мы приняли решение сделать поверх Python ещё и Ansible. Теперь если кто-то не хочет учить Ansible, что дальше будете накручивать? Bash-скрипты?
Загоняя в рамки Ansible, вы ограничиваете себя и других в сценариях, когда Ansible будет недостаточно или генератор дагов надо будет дорабатывать, а надо уже сегодня. Выше уже заметили, что задачи не всегда однотипны.
Про много кода на Python смешно читать - Python сам по себе краткий язык. Да, конечно это не SQL, на котором ты пишешь ровно то, что ты хочешь получить, но всё равно.
Анализировать самописные фреймворки - проклятый труд, один уровень абстракции поверх другой, в итоге раскрутка до момента, что конкретно выполняется занимает безумное время.
Можно было просто сказать - мы увидели очень много однотипного кода на Python, и поняли, что это можно упростить с помощью генератора дагов на YAML. Мы осознаем, что могут быть ситуации, когда такого генератора будет недостаточно, и поэтому оставили возможность продолжать писать на Python тем, кто это умеет делать. И всё
Как мы укротили 156 ETL-процессов в Airflow за один день: метод, который изменил работу DevOps