Pourquoi un catalog est-il nécessaire, au-delà des fichiers ?

La réponse courte

Un dossier d’objets n’est pas une table. Il manque le nom, le schéma officiel, la liste des fichiers du snapshot courant, les partitions, les droits, et souvent l’emplacement qui survit à un changement de chemin. Le catalog (Hive Metastore, AWS Glue, Unity Catalog, Polaris, Nessie) est ce registre. Sans lui, chaque moteur réinvente une vérité : Spark liste un préfixe, Trino un autre, un analyste pointe un sous-dossier de test, et personne ne parle de la même table.

Les tables modernes (Iceberg, Delta) stockent déjà beaucoup de métadonnées à côté des données (_delta_log, metadata/ Iceberg). Le catalog n’en devient pas inutile : il pointe vers la table et en gouverne l’accès. Unity ou Glue ne recopient pas tous les footers ; ils disent « finance.factures = cet URI, ce protocole ». C’est la différence entre ouvrir un Parquet et ouvrir la table de l’équipe finance.

Ce qu’un catalog fait, concrètement

1. Découverte. SHOW TABLES, la recherche dans l’UI, le lineage. Un lac de 4 000 préfixes sans registre est un disque partagé.
2. Contrat d’écriture. Le job d’ingestion ne « pose pas des fichiers » : il commite dans une table connue. Le schéma évolue ici, pas dans un README.
3. Multi-moteurs. Glue + Athena + Spark + Iceberg REST : le même identifiant. C’est tout l’intérêt d’un catalog ouvert. Unity joue le même rôle dans un parc Databricks, avec en plus les grants fins.
4. Sécurité. IAM sur un bucket est trop gros (tout le préfixe) ou trop petit (ingérable). Une permission SELECT sur bronze.events est le niveau où les gens travaillent. Le catalog relie l’identité au nom logique — parfois jusqu’à la colonne.
5. Gouvernance. Tags, classification, rétention annoncée, pas seulement un lifecycle S3 invisible aux analystes.

Ce que l’intervieweur vérifie

Que vous ne dites pas « Glue, c’est pour Athena ». Glue (ou tout metastore) est le plan de contrôle du lac. Athena n’est qu’un consommateur. Inversement, Unity n’est pas « juste un Hive cloud » : c’est catalog + grants + lineage, souvent au-dessus de Delta et d’Iceberg.

La relance : « les métadonnées Iceberg suffisent, non ? » Elles suffisent à un lecteur qui a déjà l’URI de la table. Elles ne suffisent pas à trouver la table, à en contrôler l’accès centralement, ni à empêcher deux équipes de pointer deux metadata.json différents en croyant le même métier.

Deuxième relance : « catalog Hive vs catalog REST ? » Hive Metastore est le plus ancien, et il montre ses limites (locks, trop de partitions). Les catalogs REST (Iceberg) et Unity visent un protocole client léger, moins de chatouilles Thrift. Vous citez le problème, pas le vendor.

Le piège

Deux catalogs pour les mêmes objets, désynchronisés. Spark écrit via Unity, un job historique met à jour Glue « pour Athena », un troisième liste S3. Vous avez trois vérités. Un lac tenu a une source pour le nom des tables. Les ponts (UniForm, sync Glue) sont des produits, pas une excuse pour dupliquer à la main.

L’autre piège : croire que le catalog remplace le lifecycle et le chiffrement. Il nomme ; S3/ADLS détient. Les deux couches doivent raconter la même rétention, sinon l’objet disparaît sous les pieds du metastore — ou l’inverse.