gip-inclusion / data-inclusion

data·inclusion aggrège les données de l'insertion sociale et professionnelle
https://api.data.inclusion.beta.gouv.fr/api/v0/docs
MIT License
6 stars 1 forks source link

Proposition pour decoupler les sources des traitements finaux #264

Closed hlecuyer closed 2 weeks ago

vmttn commented 1 month ago

@vperron les data tests n'ayant lieu qu'après l'exec des models, si il y a une erreur sur l'étape intermediate de dora par exemple, les données invalides contenues dans la table intermediate alimenteront quand même les models en aval. D'où l'idée du nouveau layer qui fait buffer...

autre solution qui ne nécessite pas de modifier la structure des models (et donc plus proche de ce que tu imaginais @hlecuyer en passant via une transaction) : changer de schéma temporairement ?

dans dbt_project.yml :

...

models:
  data_inclusion:

    ...

    intermediate:
      +schema: "{{ 'intermediate_tmp' if var('tmp', false) else 'intermediate' }}"
      +materialized: table

...
  1. build une 1ère fois dans un schéma "temporaire" via une tâche airflow dédiée avec :

dbt build -s models/intermediate/sources/france_travail/ --vars 'tmp: true'

  1. build une seconde fois dans le bon schéma via une autre tâche airflow dépendant de la 1ère

dbt build -s models/intermediate/sources/france_travail/

Si erreur, les données ne se propageront pas

vperron commented 1 month ago

Je suis d'accord @vmttn pour les modèles intermediate, on avait "pas de solution". Mais mon point était de dire que si on blinde les data tests de staging pour bien valider les données amont qui viennent des sources et peuvent casser hors de notre contrôle, a priori on se protège déjà assez bien et les intermediate vont jouer leur rôle de buffer de données J-1 (si on met en place le ALL_DONE)

Ta suggestion est cool cependant car elle permettra de protéger AUSSI le layer intermediate et ne prend pas bcp de code !

hlecuyer commented 3 weeks ago

Je vais tester la solution de @vmttn.