Ottimizzazione delle origini

Per ogni origine ad eccezione del database SQL di Azure, è consigliabile usare il partizionamento corrente come valore selezionato. Quando si legge da tutti gli altri sistemi di origine, i flussi di dati partiziona automaticamente i dati in modo uniforme in base alle dimensioni dei dati. Viene creata una nuova partizione per circa 128 MB di dati. Man mano che le dimensioni dei dati aumentano, il numero di partizioni aumenta.

Qualsiasi partizionamento personalizzato si verifica dopo che Spark legge i dati e influisce negativamente sulle prestazioni del flusso di dati. Poiché i dati vengono partizionati in modo uniforme durante le operazioni di lettura, non è consigliabile, a meno che non si comprenda prima la forma e la cardinalità dei dati.

Annotazioni

Le velocità di lettura possono essere limitate dalla velocità effettiva del sistema di origine.

Origini del database SQL di Azure

Il database SQL di Azure ha un'opzione di partizionamento univoca denominata partizionamento 'Source'. L'abilitazione del partizionamento di origine può migliorare i tempi di lettura dal database SQL di Azure abilitando le connessioni parallele nel sistema di origine. Specificare il numero di partizioni e come partizionare i dati. Usare una colonna di partizione con cardinalità elevata. È anche possibile immettere una query che corrisponda allo schema di partizionamento della tabella di origine.

Suggerimento

Per il partizionamento della sorgente, l'I/O di SQL Server rappresenta il collo di bottiglia. L'aggiunta di troppe partizioni può saturare il database di origine. In genere quattro o cinque partizioni è ideale quando si usa questa opzione.

Livello di isolamento

Il livello di isolamento della lettura in un sistema di origine SQL di Azure influisce sulle prestazioni. La scelta di "Read uncommitted" offre le prestazioni più veloci e impedisce eventuali blocchi del database. Per altre informazioni sui livelli di isolamento SQL, vedere Informazioni sui livelli di isolamento.

Leggere utilizzando la query

È possibile leggere dal database SQL di Azure usando una tabella o una query SQL. Se si esegue una query SQL, la query deve essere completata prima dell'avvio della trasformazione. Le query SQL possono essere utili per eseguire operazioni di push down che potrebbero essere eseguite più velocemente e ridurre la quantità di dati letti da sql Server, ad esempio ISTRUZIONI SELECT, WHERE e JOIN. Quando si eseguono operazioni push, si perde la possibilità di tenere traccia della derivazione e delle prestazioni delle trasformazioni prima che i dati entrino nel flusso di dati.

Origini di Azure Synapse Analytics

Quando si usa Azure Synapse Analytics, nelle opzioni di origine è presente un'impostazione denominata Abilita gestione temporanea . Ciò consente al servizio di leggere da Synapse usando Staging, migliorando notevolmente le prestazioni di lettura utilizzando la capacità di caricamento in blocco più efficiente, come CETAS e il comando COPY. Per abilitare Staging è necessario specificare un Azure Blob Storage o una posizione di staging di Azure Data Lake Storage gen2 nelle impostazioni dell'attività del flusso di dati.

Origini basate su file

Parquet e testo delimitato

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 si esegue lo stesso flusso di dati su un set di file, raccomandiamo di leggere da una cartella, utilizzando percorsi con caratteri wildcard o leggendo da una lista di file. Una singola esecuzione di attività del flusso di dati può elaborare tutti i file in batch. Altre informazioni su come configurare queste impostazioni sono disponibili nella sezione Trasformazione origine della documentazione del connettore di Azure Blob Storage.

Se possibile, evitare di usare l'attività For-Each per eseguire flussi di dati su un set di file. Ciò fa sì che ogni iterazione del "for-each" avvii il proprio cluster Spark, che spesso non è necessario e può essere costoso.

Set di dati inline e set di dati condivisi

I set di dati ADF e Synapse sono risorse condivise nelle factory e nelle aree di lavoro. Tuttavia, quando si legge un numero elevato di cartelle e file di origine con testo delimitato e origini JSON, è possibile migliorare le prestazioni dell'individuazione dei file del flusso di dati impostando l'opzione "Schema proiettato dall'utente" all'interno della proiezione | Finestra di dialogo Opzioni schema. Questa opzione disattiva l'individuazione automatica dello schema predefinito di Azure Data Factory e migliora notevolmente le prestazioni dell'individuazione dei file. Prima di impostare questa opzione, assicurarsi di importare la proiezione in modo che ADF abbia uno schema esistente per la proiezione. Questa opzione non funziona con la deriva dello schema.

Contenuti correlati

• Panoramica delle prestazioni del flusso di dati
• Ottimizzazione dei sink
• Ottimizzazione delle trasformazioni
• Uso dei flussi di dati nelle pipeline

Vedere altri articoli sul flusso di dati relativi alle prestazioni:

• Attività flusso di dati
• Monitorare le prestazioni del flusso di dati
• Prestazioni del runtime di integrazione