Partager via

Optimisation des sources

  • Article

Pour chaque source à l’exception d’Azure SQL Database, il est recommandé de conserver l’option Utiliser le partitionnement actuel sélectionnée. Lors de la lecture à partir de tous les autres systèmes sources, le flux de données partitionne automatiquement les données uniformément en fonction de la taille des données. Une nouvelle partition est créée pour chaque volume d’environ 128 Mo de données. Le nombre de partitions augmente à mesure que la taille des données augmente.

Tout partitionnement personnalisé se produit après que Spark a lu les données, et affecte négativement les performances de votre flux de données. Comme les données sont partitionnées uniformément à la lecture, ceci n’est pas recommandé, sauf si vous comprenez d’abord la forme et la cardinalité de vos données.

Remarque

Les vitesses de lecture peuvent être limitées par le débit de votre système source.

Sources d’Azure SQL Database

Azure SQL Database offre une option de partitionnement unique appelée partitionnement de la source. L’activation du partitionnement de la source peut améliorer vos temps de lecture à partir d’Azure SQL Database en activant des connexions parallèles sur le système source. Spécifiez le nombre de partitions et la manière de partitionner vos données. Utilisez une colonne de partition avec une cardinalité élevée. Vous pouvez également entrer une requête correspondant au schéma de partitionnement de votre table source.

Conseil

Pour le partitionnement de la source, les E/S de SQL Server constituent le goulot d’étranglement. L’ajout d’un trop grand nombre de partitions peut saturer votre base de données source. Généralement, quatre ou cinq partitions sont idéales lors de l’utilisation de cette option.

Source partitioning

Niveau d’isolation

Le niveau d’isolement de la lecture sur un système source SQL Azure affecte les performances. L’option « Lecture non validée » permet d’obtenir des performances optimales et d’éviter tout verrouillage de la base de données. Pour en savoir plus sur les niveaux d’isolation SQL, consultez Présentation des niveaux d’isolation.

Lire à l’aide d’une requête

Vous pouvez lire à partir d’Azure SQL Database à l’aide d’une table ou d’une requête SQL. Si vous exécutez une requête SQL, celle-ci doit se terminer avant que la transformation puisse démarrer. Des requêtes SQL peuvent être utiles pour effectuer plus tôt des opérations susceptibles de s’exécuter plus rapidement et réduire la quantité de données lues à partir d’un serveur SQL Server, comme des instructions SELECT, WHERE et JOIN. En effectuant des opérations plus tôt, vous perdez la possibilité de suivre le lignage et les performances des transformations avant que les données entrent dans le flux de données.

Sources d’Azure Synapse Analytics

Quand vous utilisez Azure Synapse Analytics, un paramètre appelé Activer le mode de préproduction existe dans les options de source. Cela permet au service de lire à partir de Synapse à l’aide de Staging, ce qui améliore considérablement les performances de lecture à l’aide de la capacité de chargement en masse la plus performante telle que la commande CETAS et COPY. L’activation de Staging nécessite que vous spécifiiez un Stockage Blob Azure ou un emplacement de préproduction Azure Data Lake Storage Gen2 dans les paramètres d’activité du flux de données.

Enable staging

Sources basées sur des fichiers

Parquet et texte délimité

Si les flux de données prennent en charge différents types de fichiers, le format Parquet natif de Spark est recommandé pour optimiser les temps de lecture et d’écriture.

Si vous exécutez le même flux de données sur un ensemble de fichiers, nous vous recommandons de lire à partir d’un dossier en utilisant des chemins d’accès génériques ou en lisant à partir d’une liste de fichiers. Une exécution d’activité de flux de données unique peut traiter tous vos fichiers par lots. Vous trouverez plus d’informations sur la configuration de ces paramètres dans la section Transformation de la source de la page de documentation Connecteur Stockage Blob Azure.

Autant que possible, évitez d’utiliser l’activité For-Each pour exécuter des flux de données sur un ensemble de fichiers. Cela a pour effet que chaque itération de l’activité For-Each lance son propre cluster Spark, ce qui n’est souvent pas nécessaire et peut s’avérer onéreux.

Jeux de données inline et jeux de données partagés

Les jeux de données ADF et Synapse sont des ressources partagées dans vos fabriques et espaces de travail. Cependant, quand vous lisez un grand nombre de dossiers et de fichiers sources avec du texte délimité et des sources JSON, vous pouvez améliorer les performances de la découverte de fichiers de flux de données en définissant l’option « Schéma projeté par l’utilisateur » dans la Boîte de dialogue Projection | Options de schéma. Cette option désactive la découverte automatique de schémas par défaut d’ADF et améliore considérablement les performances de la découverte de fichiers. Avant de définir cette option, veillez à importer la projection afin qu’ADF dispose d’un schéma existant pour la projection. Cette option ne fonctionne pas avec la dérive de schéma.

Contenu connexe

Consultez d’autres articles sur les flux de données consacrés aux performances :