Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando i flussi di dati scrivono in sink, qualsiasi partizionamento personalizzato avviene immediatamente prima della scrittura. Analogamente all'origine, nella maggior parte dei casi è consigliabile mantenere l'opzione Usa partizionamento corrente come opzione di partizione selezionata. I dati partizionati scrivono molto più velocemente dei dati non partizionati, anche la destinazione non è partizionata. Di seguito sono riportate le singole considerazioni per vari tipi di sink.
Sink del database SQL di Azure
Con il database SQL di Azure, il partizionamento predefinito dovrebbe funzionare nella maggior parte dei casi. È possibile che il sink abbia troppe partizioni perché il database SQL possa gestirle. Se si riscontra questo problema, ridurre il numero di partizioni generate dal sink del database SQL.
Procedura consigliata per l'eliminazione delle righe nel sink basata sulle righe mancanti nella sorgente
Ecco una video procedura dettagliata su come usare i flussi di dati con esistenza, trasformazioni di riga alterate e sink per ottenere questo modello comune.
Impatto della gestione delle righe degli errori sulle prestazioni
Quando si abilita la gestione delle righe di errore ("continua in caso di errore") nella trasformazione sink, il servizio esegue un passaggio aggiuntivo prima di scrivere le righe compatibili nella tabella di destinazione. Questo passaggio aggiuntivo comporta una leggera penalizzazione delle prestazioni, che può aggirarsi intorno al 5%, con un ulteriore piccolo impatto sulle prestazioni se si imposta l'opzione per scrivere anche le righe incompatibili in un file di log.
Disabilitazione degli indici tramite uno script SQL
La disabilitazione degli indici prima di un carico in un database SQL può migliorare notevolmente le prestazioni di scrittura nella tabella. Eseguire il comando seguente prima di scrivere nel sink SQL.
ALTER INDEX ALL ON dbo.[Table Name] DISABLE
Al termine della scrittura, ricompilare gli indici usando il comando seguente:
ALTER INDEX ALL ON dbo.[Table Name] REBUILD
Queste operazioni possono essere eseguite in modo nativo usando script pre e post-SQL all'interno di un database SQL di Azure o un sink Synapse nei flussi di dati di mapping.
Avviso
Quando si disabilitano gli indici, il flusso di dati assume efficacemente il controllo di un database e le query hanno poche probabilità di riuscire. Di conseguenza, molti processi ETL vengono attivati durante la notte per evitare questo conflitto. Per ulteriori informazioni, informarsi sui vincoli relativi alla disabilitazione degli indici SQL.
Aumento delle prestazioni del database
Pianifica un ridimensionamento del database SQL di origine e sink di Azure prima dell'esecuzione della pipeline per aumentare il throughput e ridurre al minimo le limitazioni di Azure una volta raggiunti i limiti DTU. Al termine dell'esecuzione della pipeline, ridimensionare i database alla frequenza di esecuzione normale.
Sink di Azure Synapse Analytics
Quando si scrive in Azure Synapse Analytics, assicurarsi che l'opzione Abilita gestione temporanea sia impostata su true. In questo modo il servizio può scrivere usando il comando SQL COPY, che carica effettivamente i dati in blocco. È necessario fare riferimento a un account di Azure Data Lake Storage gen2 o di Azure Blob Storage per lo staging dei dati quando si utilizza la gestione temporanea.
Oltre a Staging, le stesse procedure consigliate si applicano ad Azure Synapse Analytics come ad Azure SQL Database.
Sink basati su file
Mentre i flussi di dati supportano vari tipi di file, è consigliabile usare il formato Parquet nativo spark per tempi di lettura e scrittura ottimali.
Se i dati vengono distribuiti uniformemente, usare il partizionamento corrente è l'opzione di partizionamento più veloce per la scrittura di file.
Opzioni del nome file
Quando si scrivono file, è possibile scegliere opzioni di denominazione che hanno un effetto sulle prestazioni.
Se si seleziona l'opzione Predefinito , consente una scrittura più veloce. Ogni partizione equivale a un file con il nome predefinito di Spark. Ciò è utile se stai leggendo solo dalla cartella dati.
L'impostazione di un modello di denominazione rinomina ogni file di partizione in un nome più descrittivo. Questa operazione viene eseguita dopo la scrittura ed è leggermente più lenta rispetto alla scelta dell'impostazione predefinita.
Per partizione è possibile assegnare manualmente un nome a ogni singola partizione.
Se una colonna corrisponde alla modalità di output dei dati, è possibile selezionare Nome file come dati di colonna. In questo modo i dati vengono ridistribuiti e possono influire sulle prestazioni se le colonne non vengono distribuite in modo uniforme.
Se una colonna corrisponde alla modalità di generazione dei nomi delle cartelle, selezionare Cartella nome come dati di colonna.
L'output in un singolo file combina tutti i dati in una singola partizione. Ciò comporta tempi di scrittura lunghi, soprattutto per set di dati di grandi dimensioni. Questa opzione è sconsigliata a meno che non esista un motivo aziendale esplicito per usarla.
Sink di Azure Cosmos DB
Quando si scrive in Azure Cosmos DB, la modifica della velocità effettiva e delle dimensioni batch durante l'esecuzione del flusso di dati può migliorare le prestazioni. Queste modifiche diventano effettive solo durante l'esecuzione dell'attività del flusso di dati e torneranno alle impostazioni originali della raccolta dopo la conclusione.
Dimensioni batch: In genere, a partire dalle dimensioni batch predefinite è sufficiente. Per ottimizzare ulteriormente questo valore, calcolare le dimensioni approssimative degli oggetti dei dati e assicurarsi che le dimensioni dell'oggetto * batch siano inferiori a 2 MB. In caso affermativo, è possibile aumentare le dimensioni del batch per ottenere una velocità effettiva migliore.
Velocità effettiva: Impostare qui un'impostazione di velocità effettiva più elevata per consentire ai documenti di scrivere più velocemente in Azure Cosmos DB. Tenere presente i costi di RU più elevati basati su un'impostazione di throughput elevata.
Budget per la velocità effettiva di scrittura: Usare un valore minore delle RU totali al minuto. Se si dispone di un flusso di dati con un numero elevato di partizioni Spark, l'impostazione di un'allocazione del throughput permette un maggiore bilanciamento tra le partizioni.
Contenuti correlati
- Panoramica delle prestazioni del flusso di dati
- Ottimizzazione delle fonti
- Ottimizzazione delle trasformazioni
- Uso dei flussi di dati nelle pipeline
Vedere altri articoli sul flusso di dati relativi alle prestazioni: