Enregistrement des dataframes entre les tâches en table dans une DB spécifique (vs xcom)

[kolok]

Description succincte du problème résolu

⚠️ Tâche très embroyonnaire, pas du tout prète pour ne review, même partielle

Arrêter de passer par la table XCOM pour transférer les dataframe entre les tâches:

• les xcom ne s'occupe que des métadonnées
• les dataframes sont enregistrés en base de données :
  • création d'une base de données spécifiques pour ne pas interférer avec les données de django lors de calculs en DB
  • les tables sont nommées en utilisant les ID de dag, run et tache
  • les tables sont nettoyée régulièrement

A discuter :

• Utilisation du même serveur de base de données que la base de données Django
• Nommage de table
• politique de nettoyage

Tache à suivre :

• Transférer les calculs sur la base de données quand c'est possible

Type de changement :

• Bug fix
• Nouvelle fonctionnalité
• Mise à jour de données / DAG
• Les changements nécessitent une mise à jour de documentation
• Refactoring de code (explication à retrouver dans la description)

Auto-review

Les trucs à faire avant de demander une review :

• J'ai bien relu mon code
• La CI passe bien
• En cas d'ajout de variable d'environnement, j'ai bien mis à jour le .env.template
• J'ai ajouté des tests qui couvrent le nouveau code

Comment tester

En local / staging :

• …

[maxcorbeau]

Contexte: problème soulevé lors de mon audit d'arrivé via Etat de fonctionnement des DAGs au 2024-11-04

• https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/xcoms.html

Et en comparant la taille DB avant/après avec la requête suivante:

SELECT
	DATE(timestamp) AS date,
	COUNT(*) AS nombre_entrees,
	ROUND(SUM(pg_column_size(value) / 1024.0 / 1024.0)) AS taille_mb
FROM xcom
GROUP BY 1
ORDER BY 1 DESC

On voit la taille de la table xcom qui explose (178MB de plus le 2024-11-04 avec seulement 18 DAGs lancées):