Technical Tutorials

Le paysage de l'orchestration de données évolue. Bien qu'Apache Airflow ait longtemps été la référence de facto pour planifier des pipelines de données complexes, son modèle de DAG centré sur Python peut introduire une charge cognitive et une complexité de versionnage significatives pour les équipes. Kestra, un outil d'orchestration moderne et centré sur le code, change la donne en déplaçant le paradigme de la logique impérative vers des workflows déclaratifs et pilotés par les données. Cet article explore les différences clés et fournit une feuille de route pour migrer les DAG Airflow hérités vers un environnement Kestra.

Comprendre le changement de paradigme

Airflow oblige les utilisateurs à écrire du code Python pour définir les DAG. Bien que puissant, cela signifie que la logique de la façon d'exécuter les tâches est entremêlée avec le contenu des tâches. Les modifications de la logique des tâches nécessitent souvent des déploiements de code, et la nature statique des DAG peut limiter les capacités de branchement dynamique sans contournements complexes.

Kestra, en revanche, utilise YAML pour définir les workflows. Cette séparation des préoccupations permet aux utilisateurs métier et aux ingénieurs de modifier la logique du pipeline sans toucher aux implémentations sous-jacentes des tâches. Dans Kestra, les tâches sont des citoyens de premier ordre qui peuvent être réutilisés dans plusieurs workflows, et le moteur gère nativement la logique d'orchestration. Cette approche "centrée sur le code" ne signifie pas écrire du code bas niveau pour chaque nœud ; cela signifie écrire des configurations claires et maintenables qui correspondent directement à votre flux de données.

Différences techniques clés

Langage de définition : Airflow utilise Python ; Kestra utilise YAML.
Tâches dynamiques : Airflow nécessite des motifs spécifiques (comme DynamicTaskMap) pour l'expansion dynamique ; Kestra gère les tâches dynamiques nativement via des boucles et du rendu.
Gestion de l'état : Kestra dispose d'une gestion de l'état et du traitement des sorties intégrés, réduisant le besoin de bases de données externes ou de buckets S3 pour transmettre des données entre les tâches.
Multi-tenancy : Kestra offre un support natif des espaces de noms et de la multi-tenancy, facilitant la gestion d'environnements isolés pour différentes équipes ou projets.

Migrer un DAG hérité

Considérons un DAG Airflow typique qui extrait des données d'un bucket S3, les transforme à l'aide d'un script Python et les charge dans une base de données PostgreSQL.

# legacy_dag.py
from airflow import DAG
from airflow.providers.amazon.aws.operators.s3 import S3ToRedshiftOperator
from airflow.operators.python import PythonOperator
from datetime import datetime

def transform_data(**kwargs):
    # Logique personnalisée ici
    pass

with DAG(
    's3_to_pg_pipeline',
    start_date=datetime(2023, 1, 1),
    schedule_interval='@daily',
) as dag:
    extract = S3ToRedshiftOperator(
        task_id='extract_s3',
        aws_conn_id='aws_default',
        s3_key='data/file.csv',
        redshift_table='public.staging_data',
    )
    
    transform = PythonOperator(
        task_id='transform_data',
        python_callable=transform_data,
    )
    
    extract >> transform

Voici le workflow YAML Kestra équivalent :

id: s3_to_pg_pipeline
namespace: com.company.team

tasks:
  - id: extract_s3
    type: io.kestra.plugin.aws.s3.DownloadFile
    url: s3://bucket/data/file.csv
    output:
      - /tmp/file.csv

  - id: transform_data
    type: io.kestra.plugin.shell.exec.ShellTask
    input:
      - /tmp/file.csv
    output:
      - /tmp/transformed.csv

  - id: load_pg
    type: io.kestra.plugin.postgres.Insert
    url: "{{ secrets('POSTGRES_URL') }}"
    input: /tmp/transformed.csv

Étapes pratiques de migration

Inventoriez vos DAG : Identifiez les dépendances, les opérateurs personnalisés et les déclencheurs externes.
Associez les tâches aux plugins Kestra : Exploitez l'importante bibliothèque de plugins de Kestra. Si une tâche Python personnalisée existe, enveloppez-la dans un simple shell ou un plugin Java/Kotlin si de hautes performances sont nécessaires.
Refactorisez la logique : Déplacez la logique conditionnelle du code Python vers les tâches conditionnelles de Kestra (if, switch). Cela rend le flux de contrôle visible dans l'interface utilisateur.
Gérez le flux de données : Remplacez les magasins d'état externes (comme Redis ou S3 pour les données intermédiaires) par les mécanismes natifs de sortie/entrée de Kestra.
Testez en parallèle : Exécutez Airflow et Kestra pendant une période pour assurer la cohérence.

Conclusion

La migration d'Airflow vers Kestra n'est pas simplement un changement d'outil ; c'est une opportunité de moderniser votre stratégie d'orchestration. En adoptant un modèle déclaratif basé sur YAML, les équipes peuvent réduire le code de boilerplate, améliorer la visibilité sur la lignée des données et permettre des itérations plus rapides. Bien que la migration initiale nécessite une planification minutieuse, les avantages à long terme en matière de maintenabilité et de scalabilité font de Kestra un choix convaincant pour les organisations souhaitant aller au-delà des limites des DAG Python traditionnels.