On partitionne pour que le moteur n’ouvre pas les dossiers qui ne concernent pas la requête. Le Hive-style (…/dt=2026-09-13/pays=FR/) transforme un filtre en élagage de chemins : avant même Parquet, le catalog ou le listing ignore des arbres entiers. La colonne juste est donc celle que presque toutes les lectures mettent dans le WHERE, dont la cardinalité reste gérable, et qui sert éventuellement à effacer du vieux (cycle de vie S3, DROP PARTITION).
En pratique, c’est presque toujours une date de grain jour (parfois mois), éventuellement croisée avec une dimension très basse cardinalité : pays, marque, environnement. Ce n’est presque jamais un identifiant client, un event_id, ni une timestamp à la seconde.
1. Lire les filtres réels, pas le modèle conceptuel. Si neuf requêtes sur dix commencent par WHERE dt BETWEEN …, dt est candidate. Si le métier parle de « client » mais que les jobs scannent toujours un jour, le client n’est pas une partition — c’est une clé de clustering, au mieux.
2. Compter les dossiers. Une partition = un préfixe d’objets. Mille jours × 20 pays = 20 000 feuilles, encore tenable. Mille jours × un million d’utilisateurs = un million de dossiers par jour. Le listing S3 et le metastore meurent avant les données.
3. Viser un volume par feuille. Après élagage, chaque partition devrait contenir assez de données pour produire des fichiers de 128 Mo à 1 Go, pas vingt fichiers de 80 ko. Si une partition jour pèse 5 Mo, vous êtes trop fins : passez au mois, ou ne partitionnez pas et clusterisez.
4. Aligner l’expiration. Une rétention de 400 jours se traduit par dt. Une partition categorie n’aide personne à supprimer janvier 2023.
5. Se souvenir que le partitionnement est un contrat d’écriture. Changer de colonne plus tard, c’est réécrire la table. On ne « teste pas » une partition user_id en production.
Que vous distinguez partition (dossiers, élagage de chemins) et clustering / Z-order (ordre dans les fichiers, data skipping). Beaucoup de candidats proposent « on partitionne sur tout ce qu’on filtre ». C’est ainsi qu’on crée un lac de petits fichiers.
La relance : « deux colonnes ou une ? » Deux seulement si les deux sont dans presque tous les filtres et le produit des cardinalités reste bas. dt + pays (200) oui. dt + ville (10 000) souvent non : la ville ira en Z-order.
Autre relance : « et Iceberg / Delta ? » Les tables modernes savent le partitionnement caché (hidden partitioning) : la colonne ts reste un timestamp pour le SQL, le dossier est days(ts). Vous citez ça pour montrer que le Hive-style visible n’est plus le seul outil — le critère de choix (filtre, cardinalité, volume) ne change pas.
Partitionner sur la date d’ingestion alors que les requêtes filtrent la date d’événement. Les dossiers sont jolis, les scans relisent six mois. On partitionne sur la colonne que le consommateur utilise, pas sur celle qui arrange le producteur — sauf si le lac est vraiment une archive FIFO.
Et le cas où la bonne réponse est zéro partition : une table de 80 Go relue en entier, ou déjà bien clusterisée. Un seul arbre plat avec des fichiers d’1 Go bat un labyrinthe de dossiers vides.