Où vit le schéma : dans le fichier, dans le catalog, ou les deux ?

La réponse courte

Les deux, et ils ne racontent pas la même histoire.

Le fichier (pied Parquet, en-tête Avro, footer ORC) porte le schéma physique : noms, types, nullabilité tels qu’ils ont été écrits dans cet objet. Un moteur qui ouvre le fichier sans catalog peut le lire. C’est ce qui rend Parquet portable : DuckDB, pandas ou Athena n’ont pas besoin de Hive pour comprendre un objet isolé.

Le catalog (Hive Metastore, Glue, Unity, Polaris, Nessie) porte le schéma logique de la table : la liste officielle des colonnes, les partitions, l’emplacement, les propriétés (format, codec, rétention). C’est le contrat que les jobs d’écriture doivent respecter, et que les moteurs SQL voient via DESCRIBE. Sans catalog, vous avez un tas d’objets ; avec un catalog, vous avez une table.

Le décalage entre les deux est le quotidien d’un lac mal tenu. Un fichier écrit il y a six mois n’a pas la colonne canal ; le catalog l’a depuis la migration de mars. Un lecteur « schema-on-read » fusionne comme il peut — souvent en string ou en null. Un lecteur « schema-on-write » (Delta, Iceberg) refuse l’incompatibilité à l’écriture, ce qui est le comportement sain.

Ce que l’intervieweur vérifie

Que vous savez qui gagne en cas de conflit. Trois réponses possibles, à ne pas mélanger :

1. Parquet nu + chemin. Le schéma du fichier gagne. Deux dossiers « de la même table » peuvent diverger. C’est le mode schema-on-read historique, et la raison pour laquelle les lacs Hive devenaient illisibles.
2. Table Delta / Iceberg. Le journal (ou les metadata files) est la source de vérité : la version N a un schéma précis, et chaque fichier ajouté à cette version a été validé contre lui. Le catalog pointe souvent vers l’emplacement de la table, pas vers chaque colonne — le détail vit dans les métadonnées de table.
3. Vues et couches sémantiques. Un outil BI peut encore exposer d’autres noms. Ce n’est pas le schéma de stockage ; c’est une projection. Si vous les confondez, vous « corrigez » un catalog alors que le fichier est juste.

La question de suivi fréquente : « alors on peut se passer de catalog ? » Pour un datamart d’un seul moteur, un moment, oui. Dès que deux moteurs ou deux équipes lisent la même table, le catalog n’est plus du confort : c’est ce qui évite que Spark écrive event_ts en timestamp et que Trino le lise en string parce qu’il a ouvert un autre fichier.

Le piège à nommer

Croire que le pied de fichier suffit. Il suffit pour lire un objet. Il ne suffit pas pour gouverner une table : évolution contrôlée, partitions, permissions, time travel, et « quels fichiers font partie de la version courante ». L’inverse est aussi faux : un catalog qui déclare amount DOUBLE alors que les Parquet ont un DECIMAL mal inféré produit des erreurs ou des arrondis que personne ne relie au schéma.

La phrase qui montre l’expérience : le fichier dit la vérité locale, le catalog dit la vérité d’équipe. Un lac tenu est celui où les deux sont alignés à chaque commit, pas celui où l’un des deux « devrait suffire ».