Виправлено

Якщо українська компанія готова нам надати безоплатну підписку, то ми розглянемо цей варіант. Зараз ми користуємось Transifex-проєктом японської команди безкоштовно.

Як я вже писав

Необхідно зауважити, що більшість текстів є машинним перекладом, тому потребує перегляду і редагування.

Зараз статистика така: 98.54% translated, 0.8% reviewed.

Якщо ви вважаєте, що деякі переклад невірний, то можете долучитись і зробити переклад краще. Можна почати зі зміни терміну на Вікі
uk.wikipedia.org/wiki/Потік_(інформатика

Я трохи описав це в розділі «Пріорітети». Для того, щоб мова з’явилась в проді (перелік мов в меню) треба мати якісний переклад пріорітетних сторінок.
В нас вже є машинний переклад і ми працюємо над рев’ю, тому зовсім скоро українська теж буде там

Трохи критики Airflow і порівняння з Prefect та Dagster
towardsdatascience.com/...​-inside-look-6074781c9b77

Такое рAгульное решение встречал только

Ну його писали для внутрішніх потреб Airbnb, а він став популярним через те, що закривав певну нішу. Мені це стало звичним, і нічого особливого в цій реалізації не бачу, але на початку роботи було, м’яко кажучи, незрозуміло :)

И писать логику на Jinja

логіка ж на SQL пишеться, точніше моделюється. А Jinja там додає гнучкості.
Хоча колись в чатах бачив, що хтось зробив щось на кшталт
WHERE col IN ({% for i in range(55) %} {{i}}, {% endfor %})

В цілому на нашому проекті так само але х2.5 (prod, stg, і іноді dev).
На проді не ризикуємо, тому відразу обираємо Celery/Kubernetes executor. А от на деві часто LocalExecutor

Так ADF чудовий інструмент, якщо вся дата платформа зосереджена в Azure.
Але є компанії з multi-cloud, або мігрують з GCP на AWS (чи навпаки).
Одне з переваг Airflow перед іншими оркестраторами — це наявність великої кількості інтеграцій

Згоден. Я це мав на увазі, коли писав

Для мене таким недоліком є складний процес розробки.

Але разом з тим я не думаю, що описаний вами випадок буде легше імплементувати в Dagster/Prefect

Дуже доречне зауваження. Дякую

В нас, наприклад, на одному інстансі більше 100 DAG-ів і без CeleryExecutor, нажаль, не обійтися

Абсолютно згоден, що

dbt != dbt cloud

Проте в моему розумінні оркестрація не стільки запуск за певним розкладом, скільки запуск задач у відносній послідовності, типу «А перед Б, а В після Б».
Якщо я не помиляюсь, то у теж Luigi немає production-ready планувальника, але він вважається оркестратором

В dbt теж можна будувати пайплани трансформації даних, через моделювання. А у клауд версії можна виконувати ’dbt run’ за розкладом.
Якщо в організації, наприклад, лише одне сховище даних і всі трансформації відбуваються в ній, то використання Airflow може бути недоцільним