Ingénierie data

Publier un package sur PyPI. C’est un de ces trucs qui a l’air intimidant de l’extérieur, mais qui, finalement, s’avère être une question de bon timing et d’un problème assez précis à résoudre.

Un rapport sort des chiffres bizarres. Un analyste te dit « les totaux matchent pas », et tu passes ta journée à remonter la chaîne. Le réflexe auquel je reviens est assez banal : des tests de données dbt, déclarés en YAML à côté des colonnes, et vraiment exécutés en CI. Dire au pipeline ce qu’on attend avant qu’un dashboard nous dise ce qui a dérapé.

Documenter les colonnes d’une base source, c’est le genre de tâche que personne ne veut faire. T’as un système opérationnel avec des centaines de tables, des milliers de colonnes, et une documentation qui va de “inexistante” à “un commentaire de 2017 qui dit TODO: document this.”

Dans mes projets dbt, le YAML rassemble les descriptions, les tests et les responsables de la donnée. J’utilise persist_docs pour faire remonter les descriptions des modèles dans Snowflake, puis des contrôles CI pour éviter que la doc décroche tranquillement du code. La gouvernance vient de ce qu’on construit autour de ces métadonnées. Elle n’arrive pas parce qu’un fichier est en YAML.

J’utilise Terraform pour provisionner mon environnement Snowflake et dbt pour décrire les transformations à l’intérieur. Les databases, les rôles et les warehouses d’un côté ; les modèles, les tests et la documentation de l’autre. Les deux sont du code, relu dans git et déployé par un pipeline.

Il y a un moment, dans la vie d’un data engineer, où tu te retrouves avec un fichier SQL de 300 lignes qui crée des rôles, des grants, des warehouses, et tu te demandes comment t’en es arrivé là. C’est mon histoire.