Une table de ventes était consultée au mois. Désormais, les équipes opérationnelles veulent analyser chaque journée. Faut-il réécrire tout l’historique pour changer son organisation physique ?
Le 18 septembre 2026, Snowflake a annoncé la disponibilité générale de l’évolution du partitionnement pour les tables Iceberg dont il gère le catalogue. Les écritures suivantes peuvent adopter une nouvelle règle tandis que les fichiers existants restent en place. C’est une évolution de l’intégration Snowflake : le mécanisme existe déjà dans Apache Iceberg. Annonce officielle du 18 septembre.
Cette souplesse mérite un essai si votre manière de lire les données a changé. Elle ne prouve aucun gain de performance à elle seule. Nous proposons un atelier local exécuté avec PyIceberg, puis une grille pour préparer un test dans votre environnement. Aucun benchmark Snowflake n’a été réalisé pour cet article.
Partitionner une table Iceberg : quelle décision prend-on ?
Un fichier Parquet contient des données. Iceberg ajoute les métadonnées qui décrivent la table, les fichiers à lire et leur organisation. Le moteur peut ainsi préparer une lecture cohérente sans traiter chaque fichier comme un jeu de données indépendant.
Une règle de partitionnement répartit les écritures selon une transformation : par exemple, le mois d’un horodatage. Elle aide le moteur à écarter des groupes de fichiers qui ne peuvent pas répondre au filtre demandé. La requête porte sur la colonne métier ; le lecteur n’a pas à maintenir une seconde condition sur une colonne de partition artificielle.
Avec l’évolution du partitionnement, plusieurs spécifications peuvent coexister. Les fichiers anciens conservent leur organisation ; les nouveaux suivent la spécification courante. Cela sépare deux décisions : changer la règle d’écriture, puis décider éventuellement de réécrire une partie du passé. Documentation Apache Iceberg sur l’évolution.
Cette distinction compte pour une équipe data. Une migration complète mobilise un créneau de calcul, une vérification des résultats et une capacité de reprise. Modifier une règle pour les prochaines écritures permet d’abord d’observer le comportement sur un périmètre réduit. La réorganisation historique devient un chantier distinct, avec son propre bénéfice attendu.
Ce que Snowflake permet, et les limites qui restent
La commande ALTER ICEBERG TABLE permet d’ajouter, retirer ou remplacer un champ de partition. Son périmètre est précis : catalogue Iceberg géré par Snowflake, rôle disposant d’OWNERSHIP, un champ modifié par commande.
Deux contraintes pèsent sur la conception : une colonne utilisée par une spécification actuelle ou historique ne peut pas être supprimée ; le clustering ne peut pas être activé sur une table qui a déjà eu des transformations de partition, même après leur retrait. Syntaxe et limites de la commande.
Pour un catalogue externe, la matrice Snowflake indique que l’évolution doit être effectuée par un moteur externe. La même matrice rappelle que GET_DDL ne restitue pas la clause PARTITION BY. Conservez donc explicitement la configuration de partitionnement dans votre dossier de changement. Métadonnées et matrice de compatibilité.
| Situation |
Première décision |
| Les lectures changent surtout sur les nouvelles données |
Tester une nouvelle règle d’écriture sur une table dédiée |
| Les requêtes lentes portent surtout sur l’historique |
Évaluer séparément une réécriture ciblée des anciens fichiers |
| La table est petite et répond déjà au besoin |
Mesurer avant d’ajouter du partitionnement |
| Plusieurs moteurs lisent ou écrivent la table |
Vérifier chaque lecteur et chaque writer, avec leurs versions réelles |
La disponibilité générale ne remplace pas cette dernière vérification. Un test local valide un mécanisme dans une combinaison de logiciels donnée. Votre catalogue, les autorisations, les traitements et les lecteurs BI forment une autre combinaison à recetter.
Trois situations concrètes à examiner
Les exemples suivants sont fictifs. Ils servent à poser les questions de conception, sans attribuer de résultat à un client.
Un distributeur suit les ventes du jour. Son reporting financier utilise le mois, mais les responsables de magasins interrogent maintenant la journée précédente. Le candidat au test est la table des nouvelles ventes. On conserve aussi une requête de clôture mensuelle dans la recette : accélérer un usage ne doit pas rendre l’autre impraticable.
Un industriel reçoit des événements en retard. Des équipements transmettent aujourd’hui des mesures de la semaine dernière. Le moment d’arrivée ne correspond pas à la date métier. Il faut vérifier la lecture d’une période qui mélange des fichiers écrits avant et après le changement. Notre atelier introduit volontairement ce cas, avec une ligne de septembre ajoutée après le passage au jour.
Une équipe finance analyse plusieurs exercices clos. Ses requêtes lisent principalement des données anciennes. Changer la règle des futures écritures ne traite pas directement cette charge. Elle peut conserver son organisation actuelle et mesurer une réécriture sur une copie limitée. Le bon projet dépend des requêtes réellement lentes, pas du nombre d’options disponibles dans le format.
Avant de choisir une granularité, réunissez les filtres les plus fréquents, les volumes reçus par période et les délais attendus. Ajoutez le responsable de la consommation aval à la discussion. Une modification techniquement correcte peut rester inutile si elle vise un usage marginal.
Atelier : passer du mois au jour sans toucher au fichier initial
L’objectif est de vérifier trois propriétés observables : l’ancien fichier reste identique, les nouvelles écritures utilisent une autre spécification et les deux ensembles se lisent ensemble. Le jeu contient cinq lignes synthétiques. Il ne mesure ni latence, ni débit, ni coût cloud.
L’atelier a été exécuté le 2 octobre 2026 avec Python 3.13.15, PyIceberg 0.12.0, PyArrow 25.0.1 et pyiceberg-core 0.10.1. Le catalogue SQLite et les fichiers sont locaux. La documentation PyIceberg présente ce mode pour l’expérimentation et déconseille son usage en production en raison de sa capacité limitée à monter en charge. Démarrage officiel PyIceberg.
1. Préparer un environnement isolé
Téléchargez le script complet et le fichier des dépendances figées dans un dossier vide. Avec Python 3.13 disponible :
python3.13 -m venv .venv
.venv/bin/python -m pip install -r requirements-lock.txt
.venv/bin/python atelier-iceberg.py
Sous Windows, utilisez l’exécutable Python du dossier .venv/Scripts. Le script crée son propre répertoire temporaire et le nettoie à la fin. Il ne se connecte ni à Snowflake, ni à un stockage d’entreprise. Les téléchargements de dépendances nécessitent Internet ; l’exécution de l’atelier travaille ensuite sur les fichiers locaux.
Le paquet pyiceberg-core est inclus dans les dépendances : il a été nécessaire pour les transformations temporelles lors de cette exécution. Le premier essai sans ce paquet a échoué avant l’écriture ; la version distribuée inclut la dépendance et passe les assertions.
2. Écrire le premier lot au mois
Le script crée une table Iceberg au format v2 avec deux colonnes : un identifiant et event_ts, un horodatage sans fuseau dans cet exemple. Il définit MonthTransform() sur cet horodatage, puis ajoute deux lignes de septembre.
Il relève ensuite les fichiers référencés par la table et calcule leur empreinte SHA-256. Cette empreinte décrit le contenu du fichier. Elle permet de vérifier une propriété plus solide que la simple présence du même chemin après la modification.
Pour transposer l’exercice à des événements réels, fixez d’abord la convention temporelle. « Journée métier française » et journée UTC ne recouvrent pas toujours les mêmes événements. Le choix doit rester cohérent entre ingestion, filtres et restitution BI. Le jeu simplifié n’essaie pas de résoudre cette convention pour vous.
3. Changer la spécification, puis écrire de nouvelles lignes
Le cœur de l’exercice tient dans ce bloc :
with table.update_spec() as update:
update.remove_field("event_month")
update.add_field("event_ts", DayTransform(), "event_day")
Ces opérations appartiennent à la même mise à jour. L’API officielle permet de retirer et d’ajouter des champs de partition avec update_spec. API PyIceberg.
Avant tout nouvel ajout de données, le script vérifie que les chemins et les empreintes du lot initial sont inchangés. Il écrit ensuite trois lignes : deux journées d’octobre et une arrivée tardive du 2 septembre. Cette dernière utilise la nouvelle règle, bien que sa date métier appartienne au mois du premier lot.
4. Lire le résultat et comprendre sa portée
Les résultats de l’exécution donnent :
| Contrôle |
Observation locale |
| Spécification initiale |
ID 0, un fichier, deux lignes |
| Spécification courante |
ID 1, trois fichiers, trois lignes |
| Ancien fichier |
Toujours présent, même empreinte SHA-256 |
| Lecture de la table |
Cinq lignes |
| Filtre sur septembre |
Identifiants 1, 2 et 5 |
Le résultat utile est la coexistence correcte des deux organisations, y compris l’arrivée tardive. Trois petits fichiers ne constituent pas un objectif de production : ils viennent ici des trois valeurs de partition du second lot. Un vrai essai doit examiner les tailles de fichiers et le travail de maintenance.
Vous pouvez modifier les dates du jeu pour tester vos propres cas limites, puis adapter les assertions attendues. Conservez une copie de la sortie avant changement. Si un résultat diffère, identifiez s’il vient des données, de la version du moteur ou de la règle choisie avant de conclure à un défaut du format.
Préparer ensuite un essai dans Snowflake
Sur une table de test existante, gérée par Snowflake et déjà partitionnée au mois sur event_ts, le changement correspondant s’écrit :
ALTER ICEBERG TABLE demo_events
REPLACE PARTITION BY (MONTH(event_ts)) WITH (DAY(event_ts));
Pour examiner les spécifications :
SHOW ICEBERG TABLES LIKE 'DEMO_EVENTS'
->> SELECT "partition_specs", "current_partition_spec_id" FROM $1;
Ces commandes sont fondées sur la référence SQL Snowflake. Elles n’ont pas été exécutées dans un compte Snowflake pour cet article. Le fichier SQL annoté détaille les prérequis ; il ne crée aucun compte ni volume externe.
Préparez la recette avant d’exécuter la modification. Sur des données représentatives mais limitées, comparez une lecture quotidienne récente, une lecture mensuelle historique et une période contenant des arrivées tardives. Vérifiez les identifiants, les agrégats et les doublons, puis la compatibilité des lecteurs aval.
Gardez constants le périmètre des données, le calcul disponible et les conditions de cache lorsque vous comparez les temps. Relevez les octets lus, la durée, le nombre de fichiers et leur taille. Définissez vos seuils d’acceptation à partir du service attendu par le métier. Aucun pourcentage universel ne remplace cette référence.
Quel coût et quel effort prévoir ?
L’atelier local n’utilise aucun service cloud payant. Son coût pratique est le temps de préparation et de lecture du résultat. Un essai sur votre plateforme ajoute les autorisations, le jeu représentatif, les contrôles aval et l’analyse de consommation.
Dans Snowflake, l’absence de réécriture automatique ne signifie pas absence de facture. La documentation distingue calcul et services cloud, stockage selon son gestionnaire et éventuels transferts entre régions ou clouds. Avec un volume externe géré par le client, le fournisseur cloud facture le stockage ; avec le stockage Snowflake, Snowflake le facture. Aucun prix forfaitaire de migration n’est déduit ici. Principes de facturation Iceberg.
Pour un département data français, notez le cloud et la région du calcul comme ceux du stockage. Une localisation européenne des données n’indique pas, à elle seule, le trajet de tous les lecteurs. Faites apparaître ces dépendances dans la fiche d’essai et dans le chiffrage de votre architecture.
La décision à prendre après le test
La grille de recette à télécharger regroupe les contrôles et laisse les mesures vierges. Remplissez-la avec les observations de votre environnement ; la sortie de notre atelier ne vaut pas validation de vos pipelines.
La décision peut être de conserver le partitionnement actuel, d’adopter une nouvelle règle pour les écritures à venir ou de lancer une étude séparée sur l’historique. Documentez le motif, la personne responsable et le traitement de reprise prévu. Les règles de responsabilité des produits data restent nécessaires quel que soit le choix physique.
Commencez par une table dont les lectures ont réellement changé. Si vous devez cadrer ce test avec vos usages BI, vos coûts et vos dépendances, échangeons sur votre plateforme data.
