Séparer les données sources des snapshots d’exécution dans une architecture de collecte

✨ Résumé de GPT-5.5

Retour sur le passage à PostgreSQL de données de référence qui ne cessaient de bouger entre JSON, CSV et DuckDB, en séparant éléments probants d’origine, observations, données de référence, snapshots d’exécution et artefacts de livraison.

Les données de référence ne cessaient de bouger entre JSON, CSV et DuckDB

Pendant plusieurs jours de mise en place du flux de collecte, de revue, d’exécution et de livraison des données, toutes sortes de problèmes ont continué à surgir. Comme je n’ai jamais vraiment appris ni utilisé les bases de données sérieusement, je changeais souvent de méthode de stockage, et chaque changement ne se limitait jamais à un simple remplacement.

Au début, je collectais les données en JSON et en CSV, puis j’avais ajouté DuckDB pour pouvoir les consulter. Mais les sorties des workers se sont mélangées à une structure où le coordinateur reconstruisait sans cesse la base de données, et je perdais constamment la distinction entre données sources et données de référence.

J’ai aussi préparé un plan pour construire la base de données avec MySQL. Mais le problème n’était pas MySQL en lui-même. Le problème venait d’une structure où plusieurs workers ou scripts mettaient directement à jour les données de référence. Avec cette approche, les mises à jour simultanées, les conflits, la responsabilité et les retours en arrière risquaient de se répéter.

J’ai ensuite examiné d’autres approches, mais le problème de fond restait le même. Lorsque les frontières entre données collectées, données de référence, données d’exécution et artefacts de livraison sont floues, le même problème finit par revenir.

La responsabilité des mutations comptait plus que le produit de base de données

Le passage à PostgreSQL ne résolvait pas le problème à lui seul. Avant de choisir une base de données, il fallait décider qui avait le droit de modifier les données de référence.

Les workers laissent les éléments probants d’origine et leurs observations sous une forme append-only. Ils ne modifient pas directement les données de référence. Le coordinateur examine ces éléments et ces observations, puis met à jour les données et les valeurs de référence. Centraliser à un seul endroit la responsabilité de modifier ces données permettait aussi de retrouver ce qu’il fallait annuler lorsqu’un conflit survenait.

J’ai réparti les rôles dans PostgreSQL

Aujourd’hui, en passant à une base PostgreSQL, j’ai donc aussi réorganisé tout le flux mis en place pendant plusieurs jours. Au lieu de tout traiter comme un seul bloc de base de données, j’ai séparé les rôles.

• Éléments probants d’origine
  • Stocker les éléments probants et les valeurs d’origine collectés depuis des sources publiques
  • Conserver les valeurs traitées et les états dans un historique séparé au lieu d’écraser la source
  • Les fichiers JSON et CSV peuvent servir de miroirs de ces éléments, mais ne sont pas les données de référence
• Observations
  • Les workers soumettent uniquement les observations de leur canal de collecte dans un registre append-only
  • La découverte et l’enrichissement sont séparés en deux rôles différents
  • Les workers ne modifient pas directement les données de référence
• Données de référence
  • Le coordinateur examine les éléments probants et les observations
  • Seules les valeurs validées sont intégrées aux données de référence selon la structure définie
  • Les vues servent de surfaces de calcul, de revue et d’export
• Snapshots d’exécution
  • Une vue de collecte ne sert pas directement de base à l’exécution réelle
  • Les cibles qui passent les contrôles de déduplication et de qualité sont figées dans un snapshot à un instant donné
  • Les résultats d’exécution, les exclusions et les états de suivi sont gérés séparément des données de référence
• Artefacts de livraison
  • Les fichiers livrés au format CSV, Google Sheets, Excel ou pour vox.ai sont générés depuis les données de référence ou les snapshots d’exécution
  • Ce sont des artefacts destinés à l’affichage ou à la livraison
  • Ils ne sont pas ensuite modifiés comme s’ils étaient les données de référence

Le flux devenait traçable des éléments probants jusqu’à l’exécution et à la livraison

J’ai ainsi terminé un flux où il devenait possible de suivre l’endroit où s’accumulent les éléments probants collectés, ce que les workers laissent, quelles valeurs deviennent des valeurs de référence, quel snapshot sert à l’exécution réelle et ce qui devient un artefact de livraison.

Bien sûr, cette structure reste encore très imparfaite et il y aura beaucoup de choses à retoucher. Je vais continuer à tester, recueillir des retours et corriger, et toutes sortes de grands bouleversements finiront sûrement par se produire. C’est comme cela que le flux, la structure du harness et mon intuition continueront tous à évoluer.

Je partage cela au cas où la mise en place de mon flux pourrait aider quelqu’un.