Partager via


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 à quelques minutes en fonction d’un certain nombre de facteurs qui sont abordés dans cet article.

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 lake, la table du point de terminaison d’analytique SQL qui fait référence à la table Delta Lake sera 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.

Capture d’écran du portail Fabric montrant le bouton Actualiser le schéma du point de terminaison d’analytique 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 entre lakehouses et sql analytique point de terminaison, 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 SQL analytique associé. Par exemple, vous avez peut-être créé une table dans lakehouse, mais elle n’est pas répertoriée dans le point de terminaison SQL analytique. Vous avez peut-être validé un grand nombre de lignes dans une table dans un lakehouse, mais ces données ne sont pas visibles dans sql analytique point de terminaison. Nous vous recommandons de lancer une synchronisation des métadonnées à la demande, déclenchée à partir de l’option Actualiser le ruban de l’éditeur de requête 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 Interopérabilité Delta Lake.
  • Un volume extrêmement important de modifications de tables au cours du processus d’extraction, de transformation et de chargement (ETL) peut entraîner un retard jusqu’à ce que toutes les modifications aient été traitées.

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 une taille de partition individuelle d’au moins 1 Go.
  • 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 dans la lakehouse et cela entraînerait 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.

  1. 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.
  2. Le script génère 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.

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']}")