Maintenance d’un lakehouse
Résumé
Les fichiers d’un lakehouse sont immuables : chaque modification crée de nouveaux fichiers et de nouveaux snapshots. Sans entretien, les requêtes ralentissent, le stockage gonfle, et les données « supprimées » restent lisibles. Quatre tâches (compaction, expiration des snapshots, nettoyage des orphelins, réécriture des manifests) sont à planifier, plus une vigilance sur le catalogue, la compatibilité entre moteurs et le droit à l’effacement.
Prérequis
Data lake vs lakehouse (snapshot, manifest, merge-on-read).
Les tâches de maintenance
| Tâche | Problème traité | Fréquence indicative |
|---|---|---|
| Compaction | Petits fichiers, delete files accumulés | Horaire à quotidienne selon le débit d’écriture |
| Expiration des snapshots | Stockage et métadonnées qui gonflent | Quotidienne ou hebdomadaire |
| Suppression des fichiers orphelins | Restes d’écritures échouées | Hebdomadaire |
| Réécriture des manifests | Planification de requête lente | Selon la croissance |
Les fréquences sont indicatives et dépendent des volumes. Pour Iceberg, la documentation classe l’expiration des snapshots, la suppression des anciens fichiers de métadonnées et celle des fichiers orphelins comme maintenance recommandée, et la compaction des fichiers de données et la réécriture des manifests comme maintenance optionnelle.1
Exemple chiffré : un commit par minute donne 1 440 fichiers de 2 Mo par jour (environ 2,8 Go). Après compaction vers des fichiers d’environ 512 Mo, il reste environ 6 fichiers. Une requête qui ouvrait 1 440 fichiers n’en ouvre plus que 6, soit 240 fois moins.
Trois risques à budgétiser
- Le catalogue concentre le risque. C’est le point de coordination des commits et des permissions. S’il tombe, plus d’écritures. Un accès direct au stockage contourne ses règles de sécurité.
- La compatibilité entre moteurs. Un moteur qui écrit une fonction récente (type de suppression, version du format) qu’un autre ne comprend pas peut rendre la lecture impossible ou fausse. Prévoir une matrice de compatibilité et des tests croisés.
- Le droit à l’effacement. Un
DELETEne supprime pas physiquement la donnée tant que les anciens snapshots et fichiers existent.
Séquence d'effacement
- Supprimer les lignes.
- Compacter les fichiers concernés.
- Expirer les snapshots antérieurs.
- Nettoyer les orphelins.
La rétention doit être dimensionnée selon les délais d’effacement légaux. La même tension existe avec un Data Vault insert-only : voir Inmon, Kimball et Data Vault.
Le time travel n’est pas une sauvegarde : si le stockage ou le catalogue est perdu, tout part avec.
Pièges courants
Trois pièges à fort impact
| Piège | Symptôme | Parade |
|---|---|---|
| Aucune maintenance planifiée | Requêtes qui ralentissent chaque mois | Compaction et expiration planifiées, avec alertes |
| Rétention des snapshots qui ignore l’effacement | Données supprimées mais encore présentes | Aligner la rétention sur les délais légaux |
| Plusieurs écrivains sur la même table via des catalogues différents | Métadonnées écrasées, lecteurs sur une version périmée | Un seul catalogue par table |
Autres pièges
| Piège | Symptôme | Parade |
|---|---|---|
| Partitionnement trop fin (par identifiant client) | Millions de petits fichiers | Partition grossière (jour, mois), tri à l’intérieur des fichiers |
| Accès direct au stockage | Règles de sécurité contournées | Verrouiller le stockage, tout faire passer par le catalogue |
Pipeline non idempotent (INSERT simple) | Doublons après un rejeu | MERGE sur la clé métier : Iceberg n’impose pas d’unicité |
| Fonctions récentes non supportées par tous les moteurs | Lecture impossible ou résultat faux | Matrice de compatibilité, tests croisés |
| Lac sans gouvernance | Personne ne sait ce qui est fiable | Catalogue, propriétaires, contrats de données |
Notes liées
- Data lake vs lakehouse : les concepts.
- Change Data Capture (CDC) : une source typique de mises à jour fréquentes.
- Idempotence et backfill : rejeu sûr, unicité et
MERGE. - Parquet, le format de fichier colonnaire : pourquoi les petits fichiers coûtent.
- Choisir entre lake, lakehouse et warehouse : décider si le lakehouse vaut ce coût.
- Lakehouse auto-hébergé sur Scaleway : une mise en œuvre où cette maintenance est à la charge de l’équipe.
- dbt et le lakehouse : dbt ne fait pas cette maintenance.
- Glossaire data engineering : idempotence, snapshot, compaction.
- MOC Data Engineering : carte du vault.
Notes de bas de page
-
Apache Iceberg, Maintenance, documentation officielle, consultée le 24 octobre 2026. Les procédures Spark correspondantes (
expire_snapshots,remove_orphan_files,rewrite_data_files,rewrite_manifests) sont décrites dans Spark procedures. ↩