Auto Partitioning dans le Copy job de Fabric Data Factory : déplacez des tables géantes en minutes, sans configurer de partition

Résumé en une ligne : le Copy job de Fabric Data Factory partitionne désormais les grandes tables automatiquement — il choisit la colonne, calcule les frontières et lance des lectures en parallèle, le tout à partir d'un seul toggle dans Advanced settings.

Le goulot que tout le monde a déjà connu

Si vous avez déjà monté une ingestion depuis une grande base relationnelle vers le lakehouse, vous connaissez la scène : le chargement initial d'une table de transactions de centaines de millions de lignes bloque la fenêtre de traitement pendant des heures. La raison est simple — par défaut, une copie lit la source sur un seul thread. Une lecture séquentielle de 500 millions de lignes est lente par nature, quelle que soit la robustesse de la destination.

La solution traditionnelle était de partitionner à la main : choisir une colonne à bonne distribution (un id ou une date), calculer des plages de valeurs qui découpent la table en morceaux équilibrés et configurer combien de lectures parallèles lancer. Ça marche, mais il y a trois problèmes. D'abord, c'est du travail, et il faut le refaire pour chaque table. Ensuite, c'est facile de se tromper — une colonne à distribution biaisée produit des partitions déséquilibrées, et alors un thread porte 80 % des données pendant que les autres restent inactifs. Enfin, quand le volume change, la configuration qui était bonne redevient un goulot.

Ce qui a changé : Auto Partitioning (Preview)

L'Auto Partitioning dans le Copy job de Fabric Data Factory confie ce travail à la plateforme elle-même. Au lieu que vous définissiez la stratégie de partitionnement, le moteur le fait tout seul :

1. Analyse le schéma et les caractéristiques de la donnée à la source.
2. Sélectionne la colonne de partitionnement adéquate.
3. Calcule des frontières (boundaries) équilibrées entre les partitions.
4. Exécute plusieurs lectures concurrentes — sans aucune intervention de votre part.

Partitionner, c'est découper un grand ensemble en morceaux plus petits qui peuvent être lus et écrits en même temps. C'est cette concurrence qui change le palier de débit : la différence entre une lecture single-thread et une lecture parallèle partitionnée est, littéralement, la différence entre des heures et des minutes.

Stratégie adaptative : elle passe à l'échelle avec la donnée

Le point le plus élégant, c'est que la stratégie s'adapte à la taille de la table. Les tables plus grandes reçoivent plus de partitions ; les petites tables tournent sans la surcharge du partitionnement. Que ce soit une table de lookup de 100 lignes ou un journal de transactions de 500 millions, le Copy job applique la bonne stratégie automatiquement. Vous n'avez pas à décider à partir de quelle taille partitionner « en vaut la peine » — le moteur décide.

Comment l'activer (c'est un toggle)

En pratique, la configuration est minimale. Dans votre Copy job, sous Advanced settings, vous activez le toggle Auto-partitioning. C'est tout.

Sur le plan conceptuel, la définition du job ressemble à ceci :

// Copy job → Advanced settings
{
  "source": "AzureSqlDatabase",
  "table": "dbo.transactions",   // ~500M lignes
  "copyMode": "incremental",
  "watermark": "modified_at",
  "autoPartition": true          // ← toute l'astuce
}
// Le moteur choisit la colonne et les frontières,
// et lance N lectures en parallèle. Sans tuning.

Remarquez que l'Auto Partitioning est compatible avec le chargement incrémental par watermark — c'est-à-dire qu'il fonctionne aussi bien sur la copie initiale complète que sur les chargements incrémentaux suivants. Vous combinez l'avantage du partitionnement parallèle avec la logique incrémentale que vous utilisez déjà pour ne pas retraiter toute la table chaque jour.

Où ça marche

Pour le moment (Preview), l'Auto Partitioning est pris en charge pour les scénarios de chargement par watermark (full initial + incrémental) sur les principaux connecteurs relationnels :

• Azure SQL Database
• SQL Server / Azure SQL Managed Instance
• Amazon RDS for SQL Server
• Azure Synapse Analytics
• Oracle
• SAP HANA
• Fabric Data Warehouse
• Tables du Fabric Lakehouse

Étant en Preview, il vaut la peine de valider dans un environnement de développement avant de passer en production, et de suivre les limites de chaque connecteur dans la documentation officielle.

Ce que ça change au quotidien

Trois gains concrets pour l'ingénieur des données :

1. Moins de tuning manuel. Vous cessez de choisir une colonne de partition, de calculer des plages et d'ajuster le degré de parallélisme. Ce travail — répétitif et sujet à l'erreur — disparaît.

2. Des fenêtres de chargement plus courtes. Des tables qui bloquaient la nuit tiennent désormais en minutes. Cela libère de la place pour plus de dépendances dans le pipeline ou pour des SLA plus agressifs.

3. Une configuration qui ne vieillit pas. Comme la stratégie est adaptative, elle suit la croissance de la table sans exiger de révision. Le job que vous configurez aujourd'hui continue de faire la bonne chose quand le volume double.

Après presque deux décennies à construire des pipelines de données, j'ai appris à me méfier des fonctionnalités qui promettent de la « magie ». Mais le partitionnement adaptatif automatique n'est pas de la magie — c'est la plateforme qui assume enfin un travail lourd qui n'aurait jamais dû être manuel. Le temps que vous économisez sur le tuning est du temps qui revient à la modélisation, à la qualité et à la gouvernance, là où l'ingénierie des données livre vraiment de la valeur.

Prochaines étapes

Si vous utilisez le Copy job pour amener des données de bases relationnelles vers Fabric, le test est bon marché : activez le toggle sur une grande table de développement et comparez le temps d'exécution avec et sans Auto Partitioning. Le gain tend à être le plus marqué précisément sur les tables qui font le plus mal aujourd'hui.