Considerazioni sulle prestazioni degli endpoint di analisi SQL

Si applica a:✅ Endpoint di analisi SQL in Microsoft Fabric

L'endpoint di analisi SQL consente di eseguire query sui dati nel lakehouse usando il linguaggio T-SQL e il protocollo TDS. Ogni lakehouse ha un endpoint di analisi SQL. Il numero di endpoint di analisi SQL in un'area di lavoro corrisponde al numero di lakehouse e database con mirroring di cui è stato effettuato il provisioning in tale area di lavoro.

Un processo in background è responsabile dell'analisi del lakehouse per le modifiche e di mantenere aggiornato l'endpoint di analisi SQL per tutte le modifiche di cui è stato eseguito il commit in lakehouse in un'area di lavoro. Il processo di sincronizzazione viene gestito in modo trasparente dalla piattaforma Microsoft Fabric. Quando viene rilevata una modifica in un lakehouse, un processo in background aggiorna i metadati e l'endpoint di analisi SQL riflette le modifiche di cui è stato eseguito il commit nelle tabelle lakehouse. In condizioni operative normali, il ritardo tra un lakehouse e un endpoint di analisi SQL è inferiore a un minuto. L'intervallo di tempo effettivo può variare da pochi secondi a minuti a seconda di un numero di fattori che sono dicussi in questo articolo.

Schema generato automaticamente nell'endpoint di analisi SQL di Lakehouse

L'endpoint di analisi SQL gestisce le tabelle generate automaticamente in modo che gli utenti dell'area di lavoro non possano modificarle. Gli utenti possono arricchire il modello di database aggiungendo schemi, viste, routine e altri oggetti di database SQL personalizzati.

Per ogni tabella Delta in Lakehouse, l'endpoint di analisi SQL genera automaticamente una tabella nello schema appropriato. Per i tipi di dati dello schema generati automaticamente per l'endpoint di analisi SQL, vedere Tipi di dati in Microsoft Fabric.

Le tabelle nell'endpoint di analisi SQL vengono create con un ritardo minore. Dopo aver creato o aggiornato la tabella Delta Lake nel lake, la tabella degli endpoint di analisi SQL che fa riferimento alla tabella Delta Lake verrà creata/aggiornata automaticamente.

Il tempo necessario per aggiornare la tabella è correlato alla modalità di ottimizzazione delle tabelle Delta. Per altre informazioni, vedere Ottimizzazione delle tabelle Delta Lake e V-Order per altre informazioni sugli scenari chiave e una guida approfondita su come gestire in modo efficiente le tabelle Delta per ottenere prestazioni ottimali.

È possibile forzare manualmente un aggiornamento dell'analisi automatica dei metadati nel portale di Fabric. Nella pagina per l'endpoint di analisi SQL selezionare il pulsante Aggiorna nella barra degli strumenti di Explorer per aggiornare lo schema. Passare a Eseguire una query sull'endpoint di analisi SQL e cercare il pulsante di aggiornamento, come illustrato nell'immagine seguente.

Indicazioni

• L'individuazione automatica dei metadati tiene traccia delle modifiche di cui è stato eseguito il commit in lakehouse ed è una singola istanza per ogni area di lavoro Fabric. Se si osserva una maggiore latenza per la sincronizzazione delle modifiche tra lakehouse e endpoint di analisi SQL, potrebbe essere dovuto a un numero elevato di lakehouse in un'area di lavoro. In uno scenario di questo tipo, valutare la possibilità di eseguire la migrazione di ogni lakehouse a un'area di lavoro separata, in quanto consente di ridimensionare l'individuazione automatica dei metadati.
• I file Parquet non sono modificabili per impostazione predefinita. Quando è presente un'operazione di aggiornamento o eliminazione, una tabella Delta aggiungerà nuovi file Parquet con il set di modifiche, aumentando il numero di file nel tempo, a seconda della frequenza di aggiornamenti ed eliminazioni. Se non è pianificata alcuna manutenzione, alla fine questo modello crea un sovraccarico di lettura e questo influisce sul tempo necessario per sincronizzare le modifiche all'endpoint di analisi SQL. Per risolvere questo problema, pianificare le normali operazioni di manutenzione delle tabelle lakehouse.
• In alcuni scenari, è possibile osservare che le modifiche di cui è stato eseguito il commit in un lakehouse non sono visibili nell'endpoint di analisi SQL associato. Ad esempio, potrebbe essere stata creata una nuova tabella in lakehouse, ma non è elencata nell'endpoint di analisi SQL. In alternativa, potrebbe essere stato eseguito il commit di un numero elevato di righe in una tabella in una lakehouse, ma questi dati non sono visibili nell'endpoint di analisi SQL. È consigliabile avviare una sincronizzazione dei metadati su richiesta, attivata dall'opzione Aggiorna della barra multifunzione dell'editor di query SQL. Questa opzione forza la sincronizzazione dei metadati su richiesta, anziché attendere il completamento della sincronizzazione dei metadati in background.
• Non tutte le funzionalità Delta sono comprese dal processo di sincronizzazione automatica. Per altre informazioni sulle funzionalità supportate da ogni motore in Fabric, vedere Interoperabilità delta Lake.
• Se è presente una volumne di tabelle estremamente grande durante l'elaborazione ETL (Extract Transform and Load), potrebbe verificarsi un ritardo previsto fino a quando non vengono elaborate tutte le modifiche.

Considerazioni sulle dimensioni delle partizioni

La scelta della colonna di partizione per una tabella delta in un lakehouse influisce anche sul tempo necessario per sincronizzare le modifiche all'endpoint di analisi SQL. Il numero e le dimensioni delle partizioni della colonna di partizione sono importanti per le prestazioni:

• Una colonna con cardinalità elevata (per lo più o interamente costituita da valori univoci) comporta un numero elevato di partizioni. Un numero elevato di partizioni influisce negativamente sulle prestazioni dell'analisi di individuazione dei metadati per individuare le modifiche. Se la cardinalità di una colonna è elevata, scegliere un'altra colonna per il partizionamento.
• Anche le dimensioni di ogni partizione possono influire sulle prestazioni. È consigliabile usare una colonna che genera una partizione di almeno (o vicino a) 1 GB. È consigliabile seguire le procedure consigliate per la manutenzione delle tabelle differenziali; ottimizzazione. Per uno script Python per valutare le partizioni, vedere Script di esempio per i dettagli della partizione.

Un volume elevato di file Parquet di piccole dimensioni aumenta il tempo necessario per sincronizzare le modifiche tra una lakehouse e l'endpoint di analisi SQL associato. È possibile che si verifichi un numero elevato di file Parquet in una tabella delta per uno o più motivi:

• Se si sceglie una partizione per una tabella delta con un numero elevato di valori univoci, viene partizionata da ogni valore univoco e potrebbe essere sovra partizionata. Scegliere una colonna di partizione che non ha una cardinalità elevata e comporta dimensioni di partizione singole di almeno 1 GB.
• La velocità di inserimento dei dati in batch e di streaming può comportare anche file di piccole dimensioni a seconda della frequenza e delle dimensioni delle modifiche scritte in un lakehouse. Ad esempio, potrebbe esserci un piccolo volume di modifiche che arrivano al lakehouse e questo potrebbe comportare piccoli file parquet. Per risolvere questo problema, è consigliabile implementare la manutenzione regolare della tabella lakehouse.

Script di esempio per i dettagli della partizione

Usare il notebook seguente per stampare un report che illustra in dettaglio le dimensioni e i dettagli delle partizioni alla base di una tabella differenziale.

1. Prima di tutto, è necessario specificare il percorso ABSFF per la tabella delta nella variabile delta_table_path.
   • È possibile ottenere il percorso ABFSS di una tabella delta da Esplora del portale di Fabric. Fare clic con il pulsante destro del mouse sul nome della tabella, quindi scegliere COPY PATH dall'elenco di opzioni.
2. Lo script restituisce tutte le partizioni per la tabella delta.
3. Lo script scorre ogni partizione per calcolare le dimensioni totali e il numero di file.
4. Lo script restituisce i dettagli delle partizioni, dei file per partizioni e delle dimensioni per partizione in GB.

Lo script completo può essere copiato dal blocco di codice seguente:

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

Contenuto correlato

• Meglio insieme: Lakehouse e Warehouse
• Linee guida sulle prestazioni di Data Warehouse Synapse in Microsoft Fabric
• Limitazioni dell'endpoint di analisi SQL