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. Il exploite le moteur Fabric Data Warehouse.

Tip

Pour obtenir des conseils complets sur l’optimisation des tables Delta pour l’analyse SQL via une interface, y compris les recommandations de taille de fichier et de groupe de lignes, consultez la maintenance et optimisation des tables pour différents environnements de charge de travail.

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 alors que le point d’accès SQL Analytics est actif et s’arrête après 15 minutes sans activité de requête.

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 pouvez lancer une synchronisation des métadonnées à la demande dans le portail Fabric ou utiliser l’API REST d’actualisation des métadonnées du point de terminaison d’analytique SQL.
  • 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.

V-Order profite principalement à Power BI Direct Lake et, bien qu'il puisse améliorer la compression pour certaines charges de travail, il n'est généralement ni recommandé par défaut pour des performances optimales des endpoints SQL analytics.

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.

Note

Pour obtenir des conseils sur la maintenance générale des tables lakehouse, consultez Exécuter la maintenance des tables à partir de Lakehouse.

Considérations relatives à la taille de partition

La disposition des partitions influence le temps que met le terminau SQL Analytics à découvrir et synchroniser les changements. Un grand nombre de partitions ou de petits fichiers Parquet augmente la surcharge de la balayage des métadonnées. Suivez ces pratiques :

  • Évitez les colonnes de partition à haute cardinalité, qui peuvent créer une partition pour chaque valeur unique. Choisissez une colonne qui produit des partitions proches ou supérieures à 1 Go. Pour plus d’informations, voir partitionnement des tables de Delta Lake.
  • L’ingestion par lots et en streaming peut générer de petits fichiers lorsque les changements sont fréquents ou minimes. Utilisez la maintenance régulière des tables lakehouse pour compacter ces fichiers.

Pour évaluer la taille et le nombre de fichiers de chaque partition, utilisez le script d’exemple pour les détails de la partition.

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

Contenu connexe

  • Last updated on