Dbt

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.

Tu connais cette sensation : un rapport qui sort des chiffres bizarres, un analyste qui te dit “les totaux matchent pas”, et tu passes ta journée à remonter la chaîne pour trouver où les données ont dérapé. Souvent, le problème aurait pu être détecté automatiquement si quelqu’un avait mis un test quelque part.

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.”

La documentation, c’est le truc que personne ne veut faire. Surtout en data. T’as des centaines de colonnes dans des dizaines de tables, et quelqu’un te demande “c’est quoi le champ status dans la table orders ?” Et la réponse honnête, c’est souvent “euh… un enum je pense qui veut probablement dire X.”

Snowflake est fondamentalement SQL-first. C’est sa force : tout se pilote en SQL, des grants à la création d’objets en passant par les transformations. L’infrastructure, on a vu comment la dompter avec Terraform dans l’article précédent. Mais les transformations de données, elles, tombent dans un angle mort. Des scripts SQL éparpillés, pas de tests, pas de versioning sérieux, un seul collègue qui sait dans quel ordre tout lancer.