Optimisation des performances d’Azure Integration Runtime
Les flux de données s’exécutent sur des clusters Spark qui sont lancés au moment de l’exécution. La configuration du cluster utilisé est définie dans le runtime d’intégration (IR) de l’activité. Trois aspects en lien avec les performances sont à prendre en considération lors de la définition de votre runtime d’intégration : type de cluster, taille de cluster et durée de vie.
Pour plus d’informations sur la création d’un Runtime d’intégration, consultez Runtime d’intégration.
Le moyen le plus simple de bien démarrer avec les runtimes d’intégration de flux de données consiste à choisir de petite, moyenne ou grande dans le sélecteur de taille de calcul. Consultez les mappages aux configurations de cluster pour ces tailles ci-dessous.
Taille du cluster
Les flux de données répartissent le traitement des données sur différents cœurs d’un cluster Spark pour effectuer des opérations en parallèle. Un cluster Spark avec davantage de cœurs augmente le nombre de cœurs dans l’environnement Compute. Des cœurs en plus grand nombre augmentent la puissance de traitement du flux de données. L’augmentation de la taille du cluster est souvent un moyen simple de réduire le temps de traitement.
La taille de cluster par défaut est de quatre cœurs de pilote et quatre cœurs de worker (petit). Lorsque vous traitez davantage de données, des clusters plus grands sont recommandés. Vous trouverez ci-dessous les options de dimensionnement possibles :
| Cœurs de worker | Cœurs de pilote | Nombre total de cœurs | Notes |
|---|---|---|---|
| 4 | 4 | 8 | Small |
| 8 | 8 | 16 | Moyenne |
| 16 | 16 | 32 | Grande |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
Les flux de données sont tarifés sur la base de vCores/heure, mode de calcul intégrant la taille du cluster et le facteur de temps d’exécution. Lorsque vous augmentez l’échelle, le coût par minute de votre cluster augmente, mais le temps global d’exécution diminue.
Conseil
Il existe un plafond à la manière dont la taille d’un cluster affecte les performances d’un flux de données. Selon la taille de vos données, il existe un point au-delà duquel l’augmentation de la taille d’un cluster n’améliore plus les performances. Par exemple, si vous avez plus de cœurs que de partitions de données, l’ajout de cœurs n’est pas utile. Une bonne pratique consiste à commencer petit et à augmenter l’échelle pour répondre à vos besoins en matière de performances.
Partition aléatoire personnalisée
Le flux de données divise les données en partitions et les transforme à l’aide de différents processus. Si la taille des données d’une partition est supérieure à ce que le processus peut contenir en mémoire, le processus échoue avec des erreurs OOM (mémoire insuffisante). Si le flux de données contient d’énormes quantités de données présentant des jointures/agrégations, vous pouvez essayer de modifier les partitions aléatoires de manière incrémentielle. Vous pouvez les définir de 50 à 2 000 pour éviter les erreurs OOM. Les propriétés personnalisées de calcul dans le runtime de flux de données permettent de contrôler vos besoins en calcul. Le nom de la propriété est Partitions aléatoires et son type est entier. Cette personnalisation ne doit être utilisée que dans les scénarios connus, car elle peut sinon entraîner des échecs inutiles de flux de données.
Lors de l’augmentation des partitions aléatoires, assurez-vous que les données sont bien réparties. Un nombre approximatif consiste à avoir environ 1,5 Go de données par partition. Si les données sont asymétriques, l’augmentation des « Partitions aléatoires » ne sera pas utile. Par exemple, si vous avez 500 Go de données, avoir une valeur comprise entre 400 et 500 devrait fonctionner. La limite par défaut pour les partitions aléatoires est de 200, ce qui fonctionne bien pour environ 300 Go de données.
- Dans le portail ADF, sous Gérer, sélectionnez un temps d'exécution d’intégration personnalisé et passez en mode d’édition.
- Sous l’onglet de temps d’exécution du flux de données, accédez à la section Propriétés de calcul personnalisées.
- Sélectionnez Partitions aléatoires sous Nom de propriété et saisissez la valeur de votre choix, par exemple, 250, 500, etc.
Vous pouvez faire de même en modifiant le fichier JSON du runtime, en ajoutant un tableau avec le nom et la valeur après une propriété existante telle que la propriété de nettoyage.
Durée de vie
Par défaut, chaque activité de flux de données a pour effet de démarrer un nouveau cluster Spark en fonction de la configuration d’Azure IR. Le démarrage des clusters froids prend quelques minutes et le traitement des données ne peut pas commencer tant que le processus de démarrage n’est pas terminé. Si vos pipelines contiennent plusieurs flux de données séquentiels, vous pouvez activer une valeur de durée de vie (TTL). La spécification d’une valeur de durée de vie a pour effet que le cluster reste actif pendant un certain temps après la fin de son exécution. Si une nouvelle tâche commence à utiliser le runtime d’intégration (IR) pendant TTL, elle va réutiliser le cluster existant et le temps de démarrage sera fortement réduit. Une fois le deuxième travail terminé, le cluster reste actif pendant la durée de vie.
Toutefois, si la plupart de vos flux de données s’exécutent en parallèle, il n’est pas recommandé d’activer la TTL de l’IR que vous utilisez pour ces activités. Une seule tâche peut être exécutée sur un seul cluster à la fois. Si un cluster est disponible, mais que deux flux de données démarrent, un seul utilise par le cluster actif. Le deuxième travail démarre son propre cluster isolé.
Notes
La durée de vie n’est pas disponible lors de l’utilisation du runtime d’intégration de résolution automatique (par défaut).
Contenu connexe
Consultez d’autres articles sur les flux de données consacrés aux performances :