Considérations sur les performances des interfaces analytiques SQL

Le point de terminaison d’analytique SQL vous permet d’interroger des données dans lakehouse à l’aide du langage T-SQL et du protocole TDS.

Chaque Lakehouse dispose d'un point d'accès à l'analyse SQL. Le nombre de points d'extrémité SQL analytics dans un espace de travail correspond au nombre de lakehouses et de bases de données miroir provisionnées dans cet espace de travail.

Un processus en arrière-plan est chargé d’analyser le lakehouse à la recherche de modifications et de maintenir à jour le point de terminaison SQL Analytics avec toutes les modifications validées dans les lakehouses d’un espace de travail. La plateforme Fabric gère de manière transparente le processus de synchronisation. Lorsqu’une modification est détectée dans un lakehouse, un processus en arrière-plan met à jour les métadonnées et le point de terminaison SQL analytique reflète les modifications validées dans les tables lakehouse. Dans des conditions de fonctionnement normales, le décalage entre un lakehouse et un point de terminaison SQL analytique est inférieur à une minute. La durée réelle peut varier de quelques secondes à minutes en fonction de nombreux facteurs abordés par cet article. Le processus en arrière-plan s’exécute uniquement lorsque le point de terminaison d’analyse SQL est actif et qu’il s’arrête après 15 minutes d’inactivité.

Conseils

• La découverte automatique des métadonnées suit les modifications validées dans lakehouses et est une instance unique par espace de travail Fabric. Si vous constatez une latence accrue dans la synchronisation des modifications entre les lakehouses et le point de terminaison SQL analytique, cela peut être dû à un grand nombre de lakehouses au sein d’un même espace de travail. Dans ce scénario, envisagez de migrer chaque lakehouse vers un espace de travail distinct, car cette approche permet à la découverte automatique des métadonnées de passer à l’échelle.
• Les fichiers Parquet sont immuables par conception. Lorsqu’il existe une opération de mise à jour ou de suppression, une table Delta ajoute de nouveaux fichiers Parquet avec l’ensemble de modifications, ce qui augmente le nombre de fichiers au fil du temps, en fonction de la fréquence des mises à jour et des suppressions. Si vous ne planifiez pas de maintenance, ce modèle crée finalement une surcharge de lecture et cette condition affecte le temps nécessaire à la synchronisation des modifications apportées au point de terminaison d’analyse SQL. Pour résoudre ce problème, planifiez des opérations régulières de maintenance des tables lakehouse.
• Dans certains scénarios, vous pouvez observer que les modifications validées dans un lakehouse ne sont pas visibles dans le point de terminaison d'analyses SQL associé. Par exemple, vous pouvez créer une table dans lakehouse, mais elle n’est pas encore répertoriée dans le point de terminaison d’analyse SQL. Il se peut également que vous écriviez un grand nombre de lignes dans une table d’un lakehouse, sans que ces données soient encore visibles dans le point de terminaison SQL analytique. Vous avez la possibilité de démarrer la synchronisation des métadonnées à la demande.
• Le processus de synchronisation automatique ne prend pas en charge toutes les fonctionnalités Delta. Pour plus d’informations sur les fonctionnalités prises en charge par chaque moteur dans Fabric, consultez l’interopérabilité du format de tableau Delta Lake.
• S’il existe un volume extrêmement important de modifications de table pendant le traitement ETL (Extract Transform and Load), un délai attendu se produit jusqu’à ce que toutes les modifications soient traitées.

Optimisation des tables lakehouse pour interroger le point de terminaison d’analyse SQL

Lorsque le point de terminaison SQL pour l’analytique lit les tables stockées dans un lakehouse, les performances des requêtes dépendent fortement de l’organisation physique des fichiers Parquet sous-jacents. Le moteur paralléllise les scans au niveau du fichier Parquet. Trop de petits fichiers augmentent la surcharge des fichiers et des métadonnées, tandis que trop peu de fichiers volumineux peuvent limiter le parallélisme de balayage.

Pour les tables écrites par Spark, utilisez les paramètres par défaut dans Fabric Spark runtime 2.0 ou ultérieur. Ces temps d’exécution permettent par défaut une taille adaptative de fichier cible pour sélectionner la taille de fichier cible la plus optimale par table, allant de 128 Mo pour les tables plus petites jusqu’à 1 Go pour les plus grandes tables. Évitez de définir des cibles statiques ou une limite arbitraire de nombre de lignes au-dessus des configurations par défaut. Une limite de lignes ne prend pas en compte la largeur des lignes et peut créer de petits fichiers pour des tableaux étroits.

Si vous utilisez Fabric Spark runtime 1.3, activez la taille adaptative du fichier cible et les cibles de compactage au niveau du fichier, qui sont disponibles en tant que fonctionnalités d'adhésion volontaire.

Vous n’avez pas besoin de V-Order pour améliorer les performances du point de terminaison SQL Analytics, car Spark écrit des fichiers Parquet compressés avec Snappy afin de réduire les E/S en lecture comme en écriture.

Les paramètres d’écriture par défaut ne remplacent pas la maintenance de table. Utilisez les pratiques suivantes pour préserver une disposition saine au fur et à mesure que les tables changent :

• Activez la compaction automatique pour les charges de travail où la latence d’écriture synchrone périodique ajoutée est acceptable. La compaction automatique est une fonctionnalité de Spark qui ne s’exécute que lorsqu’il y a trop de petits fichiers dans une table.
• Planifiez des tâches OPTIMIZE périodiques pour les charges de travail pour lesquelles la latence périodique supplémentaire due à la compaction automatique ne permet pas de respecter les SLA de mise à jour des données.
• Exécutez VACUUM en fonction de vos exigences de rétention et de voyage dans le temps afin de supprimer les fichiers que le journal Delta ne référence plus. VACUUM Réduit le stockage conservé mais n’améliore pas la disposition active des fichiers.
• Évitez le partitionnement à haute cardinalité et les configurations d’écriture personnalisées qui créent de nombreux petits fichiers.

Si vous n’utilisez pas l’auto-compaction, pour identifier les tables nécessitant de la maintenance, utilisez un pipeline de données et la sys.sp_get_table_health_metrics procédure stockée T-SQL avant d’exécuter OPTIMIZE. Pour suivre un didacticiel, consultez Optimiser les tables Lakehouse en fonction des contrôles d’état.

Considérations relatives à la taille de partition

Le choix de la colonne de partition pour une table Delta dans un lakehouse influe également sur le temps nécessaire à la synchronisation des modifications avec le point de terminaison d’analytique SQL. Le nombre et la taille des partitions de la colonne de partition sont importantes pour les performances :

• Une colonne avec une cardinalité élevée (principalement ou entièrement composée de valeurs uniques) entraîne un grand nombre de partitions. Un grand nombre de partitions a un impact négatif sur les performances de l’analyse de découverte de métadonnées pour les modifications. Si la cardinalité d’une colonne est élevée, choisissez une autre colonne pour le partitionnement.
• La taille de chaque partition peut également affecter les performances. Utilisez une colonne qui génère une partition d’au moins (ou proche) de 1 Go. Suivez les meilleures pratiques pour la maintenance et le partitionnementdes tables Delta. Pour obtenir un script Python pour évaluer les partitions, consultez Sample script pour plus d’informations sur la partition.

Un grand volume de fichiers Parquet de petite taille augmente le temps nécessaire à la synchronisation des modifications entre un lakehouse et son point de terminaison SQL analytique associé. Vous pourriez vous retrouver avec un grand nombre de fichiers de parquet dans une table Delta pour une ou plusieurs raisons :

• Si vous choisissez une partition pour une table Delta avec un nombre élevé de valeurs uniques, la table est partitionnée par chaque valeur unique et peut être sur-partitionnée. Choisissez une colonne de partition qui n’a pas de cardinalité élevée et entraîne des partitions individuelles au moins 1 Go chacune.
• Les taux d’ingestion de données par lots et en continu peuvent également créer de petits fichiers, en fonction de la fréquence et de la taille des modifications en cours d’écriture dans un lakehouse. Par exemple, il peut y avoir un petit volume de modifications qui arrivent à la lakehouse, ce qui entraîne de petits fichiers parquet. Pour résoudre ce problème, implémentez la maintenance régulière des tables lakehouse.

Exemple de script pour les détails de la partition

Utilisez le carnet suivant pour imprimer un rapport détaillant la taille et les détails des partitions qui sous-tendent une table Delta.

1. Tout d’abord, fournissez le chemin ABFSS pour votre table Delta dans la variable delta_table_path.
   • Vous pouvez obtenir le chemin ABFSS d’une table delta à partir de l’Explorateur du portail Fabric. Cliquez avec le bouton droit sur le nom de la table, puis sélectionnez COPY PATH dans la liste des options.
2. Le script produit toutes les partitions de la table Delta.
3. Le script itère au sein de chaque partition pour calculer la taille totale et le nombre de fichiers.
4. Le script génère les détails des partitions, des fichiers par partition et la taille par partition en Go.

Vous pouvez copier le script complet à partir du bloc de code suivant :

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Schéma généré automatiquement dans le point de terminaison d’analytique SQL du Lakehouse

Pour chaque table Delta de votre Lakehouse, le point de terminaison d’analytique SQL génère automatiquement une table dans le schéma approprié. Le moteur de point de terminaison d’analytique SQL est basé sur le moteur Fabric Data Warehouse.

Pour plus d’informations, consultez synchronisation des métadonnées de point de terminaison SQL Analytics. Vous pouvez également forcer par programmation une actualisation de l’analyse automatique des métadonnées à l’aide de l’API REST Actualiser les métadonnées de point de terminaison SQL.

Contenu connexe

• Maintenance et optimisation des tableaux multi-charges de travail
• Optimisation de la table de Delta Lake et ordre V
• Compactage de table
• Ajuster la taille du fichier
• Cas d’utilisation du point de terminaison d’analytique SQL Lakehouse