Quel problème les formats de table comme Iceberg et Delta Lake résolvent-ils que du Parquet brut sur du stockage objet ne résout pas ?

Des fichiers Parquet bruts dans un bucket ne vous donnent aucune transaction : un lecteur peut voir un répertoire à moitié écrit, et un job en échec laisse des données partielles. Les formats de table ajoutent une couche de métadonnées avec des commits atomiques et une isolation par snapshot, si bien que les écritures apparaissent d'un seul coup. Ils apportent aussi l'évolution de schéma, les mises à jour et suppressions au niveau ligne, le voyage dans le temps vers des snapshots antérieurs, et l'élagage de fichiers par statistiques plutôt que par listage de répertoires.

Avec du Parquet brut, la table n'est en réalité qu'une convention de répertoires, donc il n'y a pas d'atomicité. Si un job meurt à mi-parcours, les lecteurs voient des données partielles, et il n'y a aucun moyen de mettre à jour ou de supprimer une ligne sans réécrire des partitions entières à la main. Les formats de table corrigent cela avec une couche de métadonnées. Un commit bascule atomiquement un pointeur vers un nouveau snapshot, si bien que les lecteurs voient soit l'ancien état, soit le nouveau, jamais un mélange, et vous obtenez le voyage dans le temps presque gratuitement parce que les anciens snapshots existent toujours. Ce dernier point nous a sauvés une fois, quand une mauvaise transformation avait écrasé un mart : nous avons récupéré en interrogeant le snapshot précédent plutôt qu'en restaurant depuis les sauvegardes. L'autre chose que j'aime chez Iceberg en particulier, c'est le partitionnement caché, où la table suit elle-même la transformation de partition, si bien qu'un analyste qui filtre sur un horodatage bénéficie de l'élagage sans connaître la disposition. Le coût, c'est la maintenance : il faut une compaction planifiée des petits fichiers et une expiration des snapshots, sinon les métadonnées grossissent sans limite.