Introduction

Ses principaux concurrents

Pourquoi l’utiliser ?

Les différentes architectures

Maintenant que l’on sait de quoi nous parlons, arrêtons nous sur les différentes architectures que l’on peut mettre en place pour installer Airflow.

• Dag : Décrit la façon dont est orchestrée une série de tâches qui forme un flux.
• Dag Run : C’est une instance d’un DAG fonctionnant à un moment donné.
• Operator : Décrit une tâche à exécuter de façon atomique.
  • operator : une action à effectuer (shell, call api, python)
  • transfer : un spécifique pour transférer des données (bq to gcs operator)
  • sensor : déclencheur sur event (fichier sur s3)
• Task : Représente un opérateur paramétrisé
• Task Instance : C’est une instance d’une tâche exécutée à un moment donné avec un paramétrage précis.
• X-Com : Canal d’échange d’informations entre tâches sous forme de Key-Value.

Avantages et inconvénients

L’un des avantages mais aussi des plus gros inconvénients de Airflow est son langage de programmation, Python.
En effet, cela permet de disposer de beaucoup de profils tech sur le marché et d’accroître la productivité. Il est également possible d’introduire des logiques de programmation telles que la création de Dags dynamique en fonction des besoins. Mais cela engendre aussi des problématiques de maintenance du produit de façon générale et entraîne souvent des soucis de dépendances.

L’autre point ambivalent de la solution est sa scalabilité.
Depuis la version 2 du produit, tous les services sont scalables horizontalement, rendant le produit hautement disponible et normalement tolérant aux fautes. Cependant il est difficile de gérer efficacement cette scalabilité sans exploser les coûts au niveau de la consommation des ressources de Compute.

La communauté qui s’active autour du produit est un atout également, ne laissant jamais ses utilisateurs sans réponse aux nombreuses questions qu’ils peuvent se poser au détour de la learning curve assez importante qu’ils doivent acquitter pour être opérationnels sur des projets de production à l’échelle.

Le nombre d’opérateurs disponibles contribue également aux avantages du produit.

En revanche, l’impossibilité de développer directement depuis le frontend de la solution peut devenir assez rédhibitoire en fonction de la cible utilisateur que vous devez adresser, de même que l’absence de gestion d’un quelconque versionning des Dags sans un bon Source Code Manager en back.

Enfin, dès lors que l’on souhaite mutualiser une instance de Airflow sur plusieurs périmètres fonctionnels avec des utilisateurs en provenance de domaines différents, il devient très compliqué de sécuriser les opérations et les accès aux ressources.

Retex de nos interventions Clients Grands Comptes

Deux de nos clients ayant tenté l’aventure du traitement de données à l’échelle mondiale avec Airflow en mode Event Driven se sont frottés à différents problèmes

• Complexité des tâches simples : La création de workflows sans standardisation est une tâche fastidieuse.Cela peut créer beaucoup de bruit et ralentir les projets.
• Problèmes de fiabilité : Airflow s’est avéré peu fiable, les tâches échouant souvent à cause de l’orchestrateur lui-même plutôt que d’erreurs dans le code. Ces problèmes de fiabilité peuvent faire perdre beaucoup de temps, réduisant ainsi la productivité globale.
• Sécurité : La gestion des RBAC ainsi que des utilisateurs n’aide pas à sécuriser la plateforme de façon globale, rendant son utilisation difficilement mutualisable dans un contexte multi pays, multi projets, multi utilisateurs.
• Longs délais de traitement : Dans certains cas, la durée des flux de données orchestrés par Airflow était vingt fois plus longue qu’avec d’autres outils de flux. Airflow nécessite une quantité importante de ressources CPU et de mémoire pour gérer des charges de travail même modérées, ce qui entraîne une augmentation des coûts d’infrastructure et des goulots d’étranglement potentiels au niveau des performances.

En faisant en sorte de standardiser les développements au travers de la mise à disposition de Dags pré-développés ne nécessitant plus que du paramétrage, nous avons pu gommer une partie de ces irritants et en tirer quelques bénéfices :

• Homogénéisation des développements : onboarding plus rapide des nouveaux développeurs
• Respect des règles d’architecture
• Respect des règles de qualité de données
• Recentrage des développeurs sur le fonctionnel
• Amélioration du TimeToMarket
• Facilitation du Run

Cependant, cela ne nous a pas permis de contrebalancer totalement les pain points décrits plus haut, nous obligeant à trouver d’autres solutions.

Vous rencontrez les mêmes problématiques ? La meilleure alternative qui permet de traiter tous les points énoncés se trouve juste ici 👉 kestra.io

Introduction

Fin Avril, Sébastien et la communauté SmartInnovation vous ont proposé d’explorer les dessous des IA génératives (GenAI) dans un premier volet consacré aux images. Le but était d’expliquer, et d’implémenter, des modèles permettant de générer de nouvelles informations observables à partir de représentations latentes.

Définition

Des modèles génératifs

Nous nous sommes ensuite intéressés à la définition et l’implémentation de 3 modèles génératifs :

– les auto encodeurs conventionnels
– les auto encodeurs variationnels
– les réseaux génératifs antagonistes (GAN)

Les auto encodeurs sont un type de réseau de neurones dont le but est de reconstruire une image donnée avec comme contrainte une représentation intermédiaire de plus petite dimensions.

Cependant, les auto encodeurs ne proposent pas une représentation simple de l’espace latent. Il est donc difficile de l’échantillonner pour générer des nouvelles données.

Les auto encodeurs variationnels sont des modèles probabilistes qui fournissent des distributions latentes plus compactes, adaptées à la génération de nouvelles informations.

Finalement, les GAN sont une des plus grandes innovations des 10 dernières années. Deux réseaux de neurones s’affrontent dans un jeu à somme nulle : un générateur G qui joue le rôle de ‘faussaire’ et dont le but est de créer des informations crédibles, et le discriminateur D qui joue le rôle d’expert dont le but est de distinguer les fausses informations des données réelles.