Когда мы начинали разработку, dag-factory только зарождалась. Но даже если сравнивать сейчас, то она не совсем нам подходит. Мы не только генерируем DAG-и по YAML-ам, но и генерируем сами YAML-ы, чтобы пользователю не пришлось писать их руками. При этом генерация и валидация работают в обе стороны. У нас высокие требования к валидации значений из YAML и пришлось бы существенно переписывать библиотеку. Еще одно отличие — объектная модель: у нас основная единица обработки — таск-группа, а не таска. Специфика нашего ETL предполагает большое количество задач, разбитых по таск-группам, а отдельные задачи практически не используются.
Если правильно понял вопрос про параллелизацию, речь о параллельном выполнении какой-то конкретной задачи, например spark-джоба? Логика выполнения задач находится «ниже» фреймворка dag_generator и реализована в конкретном джобе. Задача фреймворка — сгенерировать код DAG-а, а реализация вызываемого джоба уже написана заранее (в виде отдельного Python-пакета). Поэтому параллельность на уровне задач описывается в YAML, а распараллеливание конкретной задачи — в реализации каждого отдельного джоба (dbt, Spark, SQL и т.д.).
Какие еще реализации рассматривали. Дольше всего думали над тем, какими должны быть DAG-и: полностью динамическими, полудинамическими (как описано в статье) или статичными. Также смотрели на Dagster. В целом он подходил, но в штате уже были сотрудники с опытом внедрения и сопровождения Airflow.
Спасибо за подробный материал. Также, было бы интересно почитать о том, как парадигма DataMesh уживается в VK Data Platform. Например, есть ли в там упомянутые в статье компоненты и в каком виде.
Приветствую, хороший вопрос, отвечаю:
Когда мы начинали разработку, dag-factory только зарождалась. Но даже если сравнивать сейчас, то она не совсем нам подходит. Мы не только генерируем DAG-и по YAML-ам, но и генерируем сами YAML-ы, чтобы пользователю не пришлось писать их руками. При этом генерация и валидация работают в обе стороны. У нас высокие требования к валидации значений из YAML и пришлось бы существенно переписывать библиотеку. Еще одно отличие — объектная модель: у нас основная единица обработки — таск-группа, а не таска. Специфика нашего ETL предполагает большое количество задач, разбитых по таск-группам, а отдельные задачи практически не используются.
Если правильно понял вопрос про параллелизацию, речь о параллельном выполнении какой-то конкретной задачи, например spark-джоба? Логика выполнения задач находится «ниже» фреймворка dag_generator и реализована в конкретном джобе. Задача фреймворка — сгенерировать код DAG-а, а реализация вызываемого джоба уже написана заранее (в виде отдельного Python-пакета). Поэтому параллельность на уровне задач описывается в YAML, а распараллеливание конкретной задачи — в реализации каждого отдельного джоба (dbt, Spark, SQL и т.д.).
Какие еще реализации рассматривали. Дольше всего думали над тем, какими должны быть DAG-и: полностью динамическими, полудинамическими (как описано в статье) или статичными. Также смотрели на Dagster. В целом он подходил, но в штате уже были сотрудники с опытом внедрения и сопровождения Airflow.
Спасибо за подробный материал. Также, было бы интересно почитать о том, как парадигма DataMesh уживается в VK Data Platform. Например, есть ли в там упомянутые в статье компоненты и в каком виде.