Ne traiter que le flux, pas le stock

[ColinMaudry]

Sur proposition de @strainel : afin de réduire le temps de traitement et donc :

• d'éviter les timeout sur CircleCI
• de ne pas dépasser notre capital de crédit CircleCI
• de réduire l'empreinte du traitement

Il s'agit :

1. pour chaque source, d'extraire les données qui n'ont pas encore été publiées et ne traiter que ces données
2. de créer les données du jour en fusion le flux de chaque source
3. de fusionner ces données avec le stock pour dédoublonnement et production des statistiques

Les enjeux :

• chaque source de données a une méthode et un rythme de publication particulier:
  • arborescence de dossiers (https://files.data.gouv.fr/decp/), mais datePublicationDonnees est fiable
  • fichiers quasi-quotidiens mais potentiellement répartis sur plusieurs jeux de données (https://www.data.gouv.fr/fr/organizations/agence-pour-linformatique-financiere-de-letat/)
  • fichiers mensuels (http://focus-marches.ternum-bfc.fr/xml/)
  • sources qui ne sont plus mises à jour (https://data.grandlyon.com/jeux-de-donnees/marche-public-metropole-lyon/info, https://www.data.gouv.fr/fr/datasets/donnees-essentielles-des-marches-publics-publies-sur-marches-publics-info-aws/)
• le dédoublonnement par uid ainsi que la production de statistiques sont effectués sur l'ensemble des données. Une comparaison avec le stock reste donc nécessaire
• il doit rester possible de retraiter l'ensemble des données en cas de problème dans les données source

[ColinMaudry]

Pour les fichiers de la DGFiP, deux données peuvent être utilisées pour extraire les fichiers du jour :

• la valeur de <datePublicationDonnees>, qui est ajoutée par la DGFiP au moment de l'envoi (ex : 2019-04-24+02:00). Elle n'est pas fiable car la même valeur peut apparaître sur plusieurs jours différents

Exemples des marchés transmis le 3 octobre 2020 :

    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-09-22+02:00</datePublicationDonnees>
    <datePublicationDonnees>2019-07-05+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-10-01+02:00</datePublicationDonnees>
    <datePublicationDonnees>2020-09-21+02:00</datePublicationDonnees>

• la valeur du header HTTP Last-Modified (mais le format n'est pas pratique, ex "Wed, 25 Sep 2019 10:29:39 GMT")

[ColinMaudry]

Une des principales difficulté de cet est de, pour une date de traitement donné, d'identifier les dates de publication (par exemple la valeur de Last-Modified pour les données DGFiP) qui indique que le fichier doit être traité.

Si on lance decp-rama les mêmes jours que dgfip-gw, alors on pourrait programmer decp-rama de façon à ce que seuls les fichiers dont la date de publication est égale la date du jour soient traités. Cette approche est cependant fragile, car si le traitement échoue jour J, à J+1 decp-rama ne traitera que les fichiers publiés à la date J+1, pas ceux publiés à la date J.

À noter que l'outil bash date permet de facilement récupérer des dates dans le passé : https://www.cyberciti.biz/tips/linux-unix-get-yesterdays-tomorrows-date.html.

[ColinMaudry]

Une approche hybride pourrait consister à traiter non pas les tout derniers fichiers de chaque source, mais de traiter les 3, 5 ou 7 derniers, puis de ne garder que les nouveaux en utilisant la même technique de soustraction d'array :

nouvellesDonnées - anciennesDonnées = vraimentNouvellesDonnées, où

nouvellesDonnées : données des 7 derniers jours (et non le nouvel ensemble de données consolidées)
anciennesDonnées : ensemble des données consolidées au moment du traitement
vraimentNouvelleDonnées : données restantes une fois les données déjà publiées soustraites des données des 7 derniers jours

Problème : après avoir testé, le temps de traitement ne dépend pas tant de la taille des fichiers comparés mais du nombre de nouvelles données. Ce ne serait donc pas une avancée par rapport à l'approche actuelle.

[ColinMaudry]

Pour les données PES marché, nous avons l'avantage d'avoir le contrôle sur la publication des données. Je propose l'approche suivante :

• à chaque traitement dgfip-gw, on produit un CSV avec la liste des chemins des fichiers présents, avec leur date de publication

path,publicationDate
/20002336400033/2020/05/06/DECP-20002336400033-2020-05-06-01.xml,2020-10-10

• dans decp-rama, on garde en cache CircleCI la liste des fichiers effectivement traités* et à chaque traitement :
  1. on compare la liste des fichiers traités avec la liste produite par dgfip-gw
  2. on traite et publie les fichiers non traités
  3. on met à jour la liste des fichiers traités

* effectivement traité = traité sans erreur et publié sans erreur. La mise en cache se fait donc une fois la publication sur data.gouv.fr effectuée.

@strainel Tu valides ? On en parle au téléphone ?

[ColinMaudry]

Cette approche de "listes de fichiers" peut être appliquée à toutes les sources qui publient les nouvelles données dans des nouveaux fichiers :

• PES marché (DGFiP)
• AIFE
• Dematis/emarches-publics
• Ternum BFC

[ColinMaudry]

• Métropole Lyon : plus de nouvelles données depuis cette source
• marches-publics.info/AWS : plus de nouvelles données depuis cette source
• atexo-maximilien : un fichier qui regroupe toutes les données. Je suis le producteur de ce dataset, je pourrais ajouter un champ pour filter les marchés par date.

[strainel]

Le temps de traitement ayant été diminué, je clos cette demande.