Мониторинг Apache Airflow. Оценка «прожорливости» тасок

[Sirakan]

Очень интересная статья, спасибо!
Отдельный респект за проведенное расследование с форком :)

[david_khoperiya]

Спасибо!

[seasadm]

Kubernetes executor. 1 таск = 1 под. Мониторинг тривиален.

[david_khoperiya]

Обсолютно согласен, это очень простой и приятный вариант, но здесь раскрывается связка Airflow + Celery Executor, которая также является достаточно популярным решением, как минимум наравне с Kubernetes Executor.

[seasadm]

Да. Я понял что речь про celery executor. Как более лёгкий вариант, - попробовать APM на него натравить.

[kmarutya]

Познавательно, но для масштабируемости использовать лучше Kube, KubePodOperator с deferrable=True.

Тогда нагрузка на workers минимальна и можно масштабировать на порядок лучше.

[david_khoperiya]

Да, с точки зрения масштабируемости и мониторинга ресурсов работать с k8s реально удобнее, однако это не ключик к успеху, многое зависит от того, кто пишет DAG'и в вашем Airflow и какой у них уровень технических знаний.

[kmarutya]

Разница в нагрузке на worker.

Даже если код написан плохо, падает под созданный оператором, но worker pod только нужен запустить процесс. Fire and forget. Trigerrer process will do the rest.

[pustoshilov_d]

Спасибо, заберу в свой проект!

Правда у нас самые ресурсные таски идут через Slurm (с кастомным оператором), там надо будет ещё покопаться в мониторинге

[david_khoperiya]

Спасибо за приятный комментарий!