Considérations sur les performances des points de terminaison analytique SQL

S’applique à :✅ point de terminaison d’analytique SQL dans Microsoft Fabric

Le point de terminaison d’analytique SQL vous permet d’interroger des données dans le 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 lakehouse et de bases de données miroir provisionnés dans cet espace de travail.

Un processus en arrière-plan est chargé d’analyser lakehouse pour les modifications et de maintenir sql analytique point de terminaison à jour pour toutes les modifications validées dans les lakehouses dans un espace de travail. Le processus de synchronisation est géré de manière transparente par la plateforme Microsoft Fabric. 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 dans cet article. Le processus en arrière-plan s’exécute uniquement lorsque le point de terminaison d’analytique SQL est actif et qu’il est arrêté après 15 minutes d’inactivité.

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

Le point de terminaison d’analyse SQL gère les tables générées automatiquement afin que les utilisateurs de l’espace de travail ne puissent pas les modifier. Les utilisateurs peuvent enrichir le modèle de base de données en ajoutant leurs propres schémas SQL, vues, procédures et autres objets de base de données.

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é. Pour connaître les types de données de schéma générés automatiquement pour le point de terminaison d’analyse SQL, consultez Types de données dans Microsoft Fabric.

Les tables du point de terminaison d’analytique SQL sont créées avec un léger retard. Une fois que vous avez créé ou mis à jour la table Delta Lake dans le lac, la table de point de terminaison d’analyse SQL qui référence la table Delta Lake est créée/actualisée automatiquement.

Le temps nécessaire à l’actualisation de la table dépend du degré d’optimisation des tables Delta. Pour plus d’informations, consultez Optimisation des tables Delta Lake et V-Order pour en savoir plus sur les scénarios clés, ainsi qu’un guide approfondi sur la manière de maintenir efficacement les tables Delta pour des performances maximales.

Vous pouvez forcer manuellement l’actualisation de l’analyse automatique des métadonnées dans le portail Fabric. Sur la page du point de terminaison d’analytique SQL, sélectionnez le bouton Actualiser dans la barre d’outils de l’explorateur pour actualiser le schéma. Accédez à Interroger votre point de terminaison d’analytique SQL et recherchez le bouton d’actualisation, comme illustré dans l’image suivante.

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.

Assistance

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 observez une latence accrue pour la synchronisation des modifications entre lakehouses et le point de terminaison d’analyse SQL, cela peut être dû à un grand nombre de lakehouses dans un espace de travail. Dans ce scénario, envisagez de migrer chaque lakehouse vers un espace de travail distinct, car cela permet de mettre à l’échelle la découverte automatique des métadonnées.
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, augmentant le nombre de fichiers au fil du temps, en fonction de la fréquence des mises à jour et des suppressions. S’il n’existe aucune maintenance planifiée, ce modèle crée une surcharge de lecture et cela affecte le temps nécessaire à la synchronisation des modifications apportées au point de terminaison SQL analytique. Pour résoudre ce problème, planifiez des opérations régulières de maintenance de table 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 avez peut-être créé une table dans lakehouse, mais elle n’est pas encore répertoriée dans le point de terminaison d’analytique SQL. Vous avez peut-être validé un grand nombre de lignes dans une table d’un lakehouse, mais ces données ne sont pas encore visibles dans le terminal d'analytique SQL. Nous vous recommandons de lancer une synchronisation des métadonnées à la demande, déclenchée à partir de l’option du ruban Actualiser l’éditeur de requête SQL ou de l’API REST actualiser les métadonnées de point de terminaison SQL. Cette option force une synchronisation des métadonnées à la demande, plutôt que d’attendre la fin de la synchronisation des métadonnées en arrière-plan.
Toutes les fonctionnalités Delta ne sont pas comprises par le processus de synchronisation automatique. 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 tables lors du traitement d'Extraction, Transformation et Chargement (ETL), un retard prévisible peut se produire jusqu’à ce que l’ensemble des modifications soit traité.

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

Lorsque le point de terminaison d’analyse SQL lit les tables stockées dans un lakehouse, les performances des requêtes sont fortement influencées par la disposition physique des fichiers Parquet sous-jacents.

Un grand nombre de petits fichiers Parquet crée une surcharge et affecte négativement les performances des requêtes. Pour garantir des performances prévisibles et efficaces, nous vous recommandons de maintenir le stockage des tables de sorte que chaque fichier Parquet contienne deux millions de lignes. Ce nombre de lignes fournit un niveau équilibré de parallélisme sans fragmenter le jeu de données en tranches excessivement petites.

En plus des instructions relatives au nombre de lignes, la taille du fichier est tout aussi importante. Le point de terminaison d’analyse SQL fonctionne le mieux lorsque les fichiers Parquet sont suffisamment volumineux pour réduire la surcharge de gestion des fichiers, mais pas au point de limiter l’efficacité des analyses parallèles. Pour la plupart des charges de travail, conserver des fichiers Parquet individuels d'environ 400 Mo offre le meilleur équilibre. Pour atteindre cet équilibre, procédez comme suit :

Défini maxRecordsPerFile sur 2 000 000 avant que les modifications de données ne se produisent.
Effectuez vos modifications de données (ingestion de données, mises à jour, suppressions).
Défini maxFileSize sur 400 Mo.
Exécutez OPTIMIZE. Pour plus d’informations sur l’utilisation OPTIMIZE, reportez-vous aux opérations de maintenance de table.

Le script suivant fournit un modèle pour ces étapes et doit être exécuté sur un lakehouse :

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Pour conserver des tailles de fichiers saines, les utilisateurs doivent exécuter régulièrement des opérations d’optimisation Delta telles que OPTIMIZE, en particulier pour les tables qui reçoivent des écritures incrémentielles fréquentes, des mises à jour et des suppressions. Ces opérations de maintenance compactent les petits fichiers en fichiers de taille appropriée, ce qui permet de s’assurer que le point de terminaison d’analytique SQL peut traiter efficacement les requêtes.

Note

Pour obtenir des conseils sur la maintenance générale des tables lakehouse, reportez-vous à Exécuter une maintenance de table ad hoc sur une table Delta à l’aide de Lakehouse.

Considérations relatives à la taille de partition

Le choix de la colonne de partition pour une table delta dans un lakehouse affecte également le temps nécessaire à la synchronisation des modifications apportées au point de terminaison SQL analytique. 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. Notre recommandation est d’utiliser une colonne qui entraînerait une partition d’au moins (ou proche) de 1 Go. Nous vous recommandons de suivre les meilleures pratiques pour la maintenance des tables delta ; optimisation. Pour obtenir un script Python pour évaluer les partitions, consultez l’exemple de 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 pouvez avoir un grand nombre de fichiers 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, elle 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 de traitement par lots et de diffusion en continu peuvent également entraîner des petits fichiers en fonction de la fréquence et de la taille des modifications écrites 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, nous vous recommandons d’implémenter une maintenance régulière des tables lakehouse.

Exemple de script pour les détails de la partition

Utilisez le bloc-notes suivant pour imprimer une taille détaillée de rapport et les détails des partitions sous-jacentes à une table delta.

Tout d’abord, vous devez fournir le chemin ABSFF de 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.
Le script génère toutes les partitions de la table delta.
Le script itère au sein de chaque partition pour calculer la taille totale et le nombre de fichiers.
Le script génère les détails des partitions, des fichiers par partition et la taille par partition en Go.

Le script complet peut être copié à 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']}")

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-01-27