02 · Alten · banque
Une table dont les données existaient mais restaient introuvables
Les fichiers étaient bien présents sur HDFS, aucune requête ne les remontait. Diagnostic méthodique jusqu'à la cause réelle.
- Pistes écartées une à une : metastore, partitions, dédoublonnage, lecture récursive
- Cause identifiée : sous-répertoires générés par le moteur d'exécution d'une recipe
- Résolu par un changement de moteur, sans réécrire le traitement
Une table mutualisée, utilisée par plusieurs projets en aval, est devenue illisible. Les fichiers étaient bien présents sur HDFS : on pouvait les voir, les compter, vérifier leur taille. Mais aucune requête SQL ne remontait la moindre ligne.
Le diagnostic
Ce type de symptôme a beaucoup de causes possibles, et elles se ressemblent toutes vues de loin. J'ai procédé en écartant les hypothèses une par une.
- Metastore Hive
- désynchronisation entre les partitions présentes sur HDFS et celles déclarées. Piste sérieuse, écartée après vérification.
- Partitions
- partitions manquantes ou mal déclarées côté dataset. Non concluant.
- Dédoublonnage
- traitement de déduplication supprimant tout. Écarté.
- Lecture récursive
- option de parcours des sous-dossiers. C'est en creusant ce point que la cause est apparue.
La cause réelle
La recipe d'empilement qui alimentait la table s'exécutait avec le moteur Hive. Ce moteur, quand il réalise une union, écrit ses résultats dans des sous-répertoires plutôt que directement dans le répertoire cible.
Les fichiers étaient donc bien écrits, mais un niveau plus bas que là où les lecteurs allaient les chercher. D'où la situation absurde : des données visibles sur le système de fichiers, et une table vide en SQL.
C'est un comportement documenté mais peu connu, et surtout parfaitement silencieux. Aucune erreur n'est levée, ni à l'écriture, ni à la lecture.
La correction
Changer le moteur d'exécution de la recipe. Pas de réécriture du traitement, pas de migration de données : le problème n'était pas dans la logique métier mais dans la façon dont le moteur matérialisait le résultat.
Quand des données existent sur le disque mais restent invisibles en requête, la question n'est pas « où sont les données » mais « où le moteur les a-t-il vraiment écrites ».
Ce que j'en retiens
J'ai passé du temps sur la piste du metastore, qui était la plus probable a priori et que tout le monde suggère en premier. C'était le bon réflexe, mais j'aurais gagné du temps en vérifiant plus tôt la structure réelle des répertoires plutôt que la cohérence des métadonnées.
Les noms de projets, de tables et de systèmes internes ont été retirés. Les détails techniques sont réels.