Un lac illisible n’est pas un lac plein. C’est un lac dont ouvrir une table honnête (un SELECT borné, un DESCRIBE, un job d’hier) devient long, fragile ou contradictoire. Les deux causes qui reviennent ensemble : trop d’objets et plus qu’une vérité de schéma. Le CPU des scans arrive en troisième.
On diagnostique comme un incident, pas comme un cours.
1. Le temps avant le premier octet. Planification Spark / Trino, LIST du préfixe, lecture du journal ou des manifests. Si cette phase dépasse le scan, vous avez un problème de métadonnées : 200 000 fichiers, un metastore Hive saturé, un _delta_log jamais checkpointé, des manifests Iceberg non réécrits.
2. La distribution des tailles. p50 / p90 / p99 des objets par table. Une p50 à 40 ko avec 80 000 fichiers : petits fichiers. Une p99 à 40 Go avec 12 fichiers : l’autre extrême. Les deux se soignent, pas avec le même outil.
3. Le nombre de feuilles de partition. Un dt × user_id se voit au compte de préfixes, pas au volume. Des milliers de dossiers vides ou quasi vides confirment l’erreur de cardinalité.
4. La divergence de schéma. DESCRIBE du catalog versus un échantillon de footers Parquet (ou versus deux snapshots). Colonnes qui changent de type selon le fichier, structs incompatibles, lectures qui infèrent encore. Symptôme fréquent : « ça marche dans Spark, ça casse dans Athena » — ce n’est pas le moteur, c’est deux lectures du même désordre.
5. Les orphelins et les doubles vérités. Fichiers présents sur S3 absents du snapshot ; préfixes encore lus « à la Hive » à côté d’une table Delta ; deux catalogs. Les humains ont commencé à contourner le protocole : c’est déjà illisible, même si un job passe.
6. Les files d’attente métier. Dashboards qui scannent du JSONL « temporaire » depuis neuf mois ; un stream qui écrit encore dans un dossier raw/ que plus personne ne convertit. L’illisibilité est souvent un processus d’ingestion arrêté à mi-chemin.
Que vous ne commencez pas par « on passe à Iceberg ». On nomme d’abord : quelle table, combien d’objets, quel écart catalog/fichiers, quel mode d’écriture. Ensuite seulement : compaction, réduction de partitions, backfill de schéma, expiration de snapshots, interdiction des lectures par préfixe.
La relance : « comment vous le voyez sans cluster ? » Compter les objets (list paginé, métriques S3, storage inventory), lire la taille du log / le nombre de snapshots, extraire dix footers. Beaucoup d’illisible se diagnostique avant de lancer Spark.
Deuxième relance : « par quoi vous réparez en premier ? » La table la plus lue, pas la plus grosse. Un OPTIMIZE sur une archive morte n’ouvre pas les dashboards. Et on arrête le producteur de petits fichiers le temps de rattraper, sinon on compacte un tapis roulant.
Tout mettre sur « petits fichiers » alors que le vrai mal est cinq schémas dans le même préfixe, ou un lifecycle qui a mangé le log. L’inverse aussi : tout mettre sur le format alors que 90 % du temps est un LIST de partitions folles.
La phrase qui clôt : un lac lisible a peu d’objets par table chaude, un schéma commité, et un seul chemin de lecture — le catalog. Tout le reste est une zone brute, et on l’appelle comme telle.