attività Copy funzionalità di ottimizzazione delle prestazioni

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi completa per le aziende. Microsoft Fabric copre tutti gli elementi, dallo spostamento dei dati all'analisi scientifica dei dati, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Scopri come avviare gratuitamente una nuova versione di valutazione .

Questo articolo illustra le funzionalità di ottimizzazione delle prestazioni dell'attività di copia che è possibile sfruttare nelle pipeline di Azure Data Factory e Synapse.

Configurazione delle funzionalità delle prestazioni con l'interfaccia utente

Quando si seleziona un attività Copy nell'area di disegno dell'editor della pipeline e si sceglie la scheda Impostazioni nell'area di configurazione dell'attività sotto l'area di disegno, verranno visualizzate le opzioni per configurare tutte le funzionalità delle prestazioni descritte di seguito.

Unità di integrazione dati

Un'unità Integrazione dei dati è una misura che rappresenta la potenza (combinazione di CPU, memoria e allocazione di risorse di rete) di una singola unità all'interno del servizio. Integrazione dei dati'unità si applica solo a Runtime di integrazione di Azure, ma non runtime di integrazione self-hosted.

Le DIU consentite per consentire l'esecuzione di un'attività di copia sono comprese tra 2 e 256. Se non specificato o si sceglie "Auto" nell'interfaccia utente, il servizio applica in modo dinamico l'impostazione DIU ottimale in base alla coppia di sink di origine e al modello di dati. La tabella seguente elenca gli intervalli DIU supportati e il comportamento predefinito in scenari di copia diversi:

Scenario di copia	Intervallo DIU supportato	Numero di unità di integrazione dati predefinite determinato dal servizio
Tra archivi file	- Copiare da o in un singolo file: 2-4 - Copiare da e in più file: 2-256 a seconda del numero e delle dimensioni dei file Ad esempio, se si copiano dati da una cartella con 4 file di grandi dimensioni e si sceglie di mantenere la gerarchia, il numero massimo effettivo di unità di distribuzione è 16; quando si sceglie di unire il file, il numero massimo effettivo DIU è 4.	Tra 4 e 32 a seconda del numero e delle dimensioni dei file
Dall'archivio file all'archivio non file	- Copia da un singolo file: 2-4 - Copiare da più file: 2-256 a seconda del numero e delle dimensioni dei file Ad esempio, se si copiano dati da una cartella con 4 file di grandi dimensioni, il numero massimo effettivo di unità di distribuzione è 16.	- Copiare in database SQL di Azure o Azure Cosmos DB: da 4 a 16 a seconda del livello sink (DTU/UR) e del modello di file di origine - Copiare in Azure Synapse Analytics usando PolyBase o l'istruzione COPY: 2 - Altro scenario: 4
Dall'archivio non file all'archivio file	- Copiare da archivi dati abilitati per l'opzione di partizione (inclusi Database di Azure per PostgreSQL, database SQL di Azure, Istanza gestita di SQL di Azure, Azure Synapse Analytics, Oracle, Netezza, SQL Server e Teradata: 2-256 durante la scrittura in una cartella e 2-4 durante la scrittura in un singolo file. Si noti che la partizione dati di origine può usare fino a 4 UNITÀ di distribuzione. - Altri scenari: 2-4	- Copia da REST o HTTP: 1 - Copiare da Amazon Redshift usando UNLOAD: 2 - Altro scenario: 4
Tra archivi non file	- Copiare da archivi dati abilitati per l'opzione di partizione (inclusi Database di Azure per PostgreSQL, database SQL di Azure, Istanza gestita di SQL di Azure, Azure Synapse Analytics, Oracle, Netezza, SQL Server e Teradata: 2-256 durante la scrittura in una cartella e 2-4 durante la scrittura in un singolo file. Si noti che la partizione dati di origine può usare fino a 4 UNITÀ di distribuzione. - Altri scenari: 2-4	- Copia da REST o HTTP: 1 - Altro scenario: 4

È possibile visualizzare le DIU usate per ogni esecuzione di copia nella visualizzazione di monitoraggio dell'attività di copia o nell'output dell'attività. Per altre informazioni, vedere monitoraggio attività Copy. Per eseguire l'override di questo valore predefinito, specificare un valore per la dataIntegrationUnits proprietà come indicato di seguito. Il numero effettivo di unità di integrazione dati usate dall'operazione di copia in fase di esecuzione è minore o uguale al valore configurato, a seconda del modello di dati.

Verrà addebitato il numero di UNITÀ di distribuzione usate * durata copia * prezzo unitario/ora DIU.You will be charged # of used DIUS * copy duration * unit price/DIU-hour. Vedere i prezzi correnti qui. Per ogni tipo di sottoscrizione possono essere applicati valute locali e sconti separati.

Esempio:

"activities":[
    {
        "name": "Sample copy activity",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "dataIntegrationUnits": 128
        }
    }
]

Scalabilità del runtime di integrazione self-hosted

Se si vuole ottenere una velocità effettiva più elevata, è possibile aumentare o aumentare le prestazioni del runtime di integrazione self-hosted:

• Se la CPU e la memoria disponibile nel nodo del runtime di integrazione self-hosted non vengono usate completamente, ma l'esecuzione di processi simultanei raggiunge il limite, è necessario aumentare aumentando il numero di processi simultanei che possono essere eseguiti in un nodo. Per istruzioni, vedere qui .
• Se invece la CPU è elevata nel nodo del runtime di integrazione self-hosted o la memoria disponibile è insufficiente, è possibile aggiungere un nuovo nodo per aumentare il carico tra più nodi. Per istruzioni, vedere qui .

Si noti che negli scenari seguenti l'esecuzione di un'attività di copia singola può sfruttare più nodi del runtime di integrazione self-hosted:

• Copiare i dati dagli archivi basati su file, a seconda del numero e delle dimensioni dei file.
• Copiare dati dall'archivio dati abilitato per l'opzione di partizione (inclusi database SQL di Azure, Istanza gestita di SQL di Azure, Azure Synapse Analytics, Oracle, Netezza, SAP HANA, SAP Open Hub, SAP Table, SQL Server e Teradata), a seconda del numero di partizioni di dati.

Copia parallela

È possibile impostare la copia parallela (parallelCopies proprietà nella definizione JSON del attività Copy o Degree of parallelism nell'impostazione nella scheda Impostazioni delle proprietà attività Copy nell'interfaccia utente) nell'attività di copia per indicare il parallelismo che si vuole usare l'attività di copia. È possibile considerare questa proprietà come il numero massimo di thread all'interno dell'attività di copia che leggono dall'origine o scrivono negli archivi dati sink in parallelo.

La copia parallela è ortogonale per Integrazione dei dati unità o nodi del runtime di integrazione self-hosted. Viene conteggiato in tutti i nodi DIU o runtime di integrazione self-hosted.

Per ogni esecuzione dell'attività di copia, per impostazione predefinita il servizio applica dinamicamente l'impostazione di copia parallela ottimale in base alla coppia di sink di origine e al modello di dati.

Suggerimento

Il comportamento predefinito della copia parallela offre in genere la velocità effettiva migliore, determinata automaticamente dal servizio in base alla coppia sink di origine, al modello di dati e al numero di UNITÀ di distribuzione o al numero di CPU/memoria/nodo del runtime di integrazione self-hosted. Fare riferimento a Risolvere i problemi relativi alle prestazioni dell'attività di copia su quando ottimizzare la copia parallela.

La tabella seguente elenca il comportamento di copia parallela:

Scenario di copia	Comportamento di copia parallela
Tra archivi file	parallelCopies determina il parallelismo a livello di file. La suddivisione in blocchi all'interno di ogni file avviene automaticamente e in modo trasparente. È progettato per usare le dimensioni del blocco più adatte per un determinato tipo di archivio dati per caricare i dati in parallelo. Il numero effettivo di attività di copia parallela usata in fase di esecuzione non è maggiore del numero di file disponibili. Se il comportamento di copia è mergeFile nel sink di file, l'attività di copia non può sfruttare il parallelismo a livello di file.
Dall'archivio file all'archivio non file	- Quando si copiano dati in database SQL di Azure o Azure Cosmos DB, la copia parallela predefinita dipende anche dal livello sink (numero di DTU/UR). - Quando si copiano dati in tabella di Azure, la copia parallela predefinita è 4.
Dall'archivio non file all'archivio file	- Quando si copiano dati da un archivio dati abilitato per l'opzione di partizione (inclusi database SQL di Azure, Istanza gestita di SQL di Azure, Azure Synapse Analytics, Oracle, Amazon RDS for Oracle, Netezza, SAP HANA, SAP Open Hub, SAP Table, SQL Server, Amazon RDS per SQL Server e Teradata), la copia parallela predefinita è 4. Il numero effettivo di attività di copia parallela usata in fase di esecuzione non è maggiore del numero di partizioni di dati disponibili. Quando si usa il runtime di integrazione self-hosted e si copia in BLOB di Azure/ADLS Gen2, si noti che la copia parallela massima effettiva è 4 o 5 per nodo del runtime di integrazione. - Per altri scenari, la copia parallela non ha effetto. Anche se viene specificato il parallelismo, non viene applicato.
Tra archivi non file	- Quando si copiano dati in database SQL di Azure o Azure Cosmos DB, la copia parallela predefinita dipende anche dal livello sink (numero di DTU/UR). - Quando si copiano dati da un archivio dati abilitato per l'opzione di partizione (inclusi database SQL di Azure, Istanza gestita di SQL di Azure, Azure Synapse Analytics, Oracle, Amazon RDS for Oracle, Netezza, SAP HANA, SAP Open Hub, SAP Table, SQL Server, Amazon RDS per SQL Server e Teradata), la copia parallela predefinita è 4. - Quando si copiano dati in tabella di Azure, la copia parallela predefinita è 4.

Per controllare il carico nei computer che ospitano gli archivi dati o ottimizzare le prestazioni di copia, è possibile eseguire l'override del valore predefinito e specificare un valore per la parallelCopies proprietà. Il valore deve essere un numero intero maggiore o uguale a 1. In fase di esecuzione, per ottenere prestazioni ottimali, l'attività di copia usa un valore minore o uguale al valore impostato.

Quando si specifica un valore per la parallelCopies proprietà, prendere in considerazione l'aumento del carico negli archivi dati di origine e sink. Prendere in considerazione anche l'aumento del carico al runtime di integrazione self-hosted se l'attività di copia è abilitata da essa. Questo aumento del carico si verifica soprattutto quando si hanno più attività o esecuzioni simultanee delle stesse attività eseguite sullo stesso archivio dati. Se si nota che l'archivio dati o il runtime di integrazione self-hosted è sovraccarico con il carico, ridurre il valore per alleviare il parallelCopies carico.

Esempio:

"activities":[
    {
        "name": "Sample copy activity",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "BlobSource",
            },
            "sink": {
                "type": "AzureDataLakeStoreSink"
            },
            "parallelCopies": 32
        }
    }
]

copia di staging

Quando si copiano dati da un archivio dati di origine a un archivio dati sink, è possibile scegliere di usare l'archiviazione BLOB di Azure o Azure Data Lake Archiviazione Gen2 come archivio di staging provvisorio. La funzionalità di staging è particolarmente utile nei casi seguenti:

• Si vogliono inserire dati da vari archivi dati in Azure Synapse Analytics tramite PolyBase, copiare dati da/a Snowflake o inserire dati da Amazon Redshift/HDFS con prestazioni elevate. Per altre informazioni, vedere:
  • Usare PolyBase per caricare i dati in Azure Synapse Analytics.
  • Connettore Snowflake
  • Connettore Amazon Redshift
  • Connettore HDFS
• Non si vogliono aprire porte diverse dalla porta 80 e dalla porta 443 nel firewall a causa dei criteri IT aziendali. Ad esempio, quando si copiano dati da un archivio dati locale a un database SQL di Azure o azure Synapse Analytics, è necessario attivare la comunicazione TCP in uscita sulla porta 1433 sia per Windows Firewall che per il firewall aziendale. In questo scenario, la copia a fasi può sfruttare il runtime di integrazione self-hosted per copiare prima i dati in un archivio di staging tramite HTTP o HTTPS sulla porta 443, quindi caricare i dati dalla gestione temporanea in database SQL o Azure Synapse Analytics. In questo flusso non è necessario abilitare la porta 1433.
• A volte occorre tempo per eseguire uno spostamento dati ibrido, ovvero la copia da un archivio dati locale a un archivio dati cloud, su una connessione di rete lenta. Per migliorare le prestazioni, è possibile usare la copia a fasi per comprimere i dati in locale in modo che sia necessario meno tempo per spostare i dati nell'archivio dati di staging nel cloud. È quindi possibile decomprimere i dati nell'archivio di staging prima di caricare nell'archivio dati di destinazione.

Come funziona la copia di staging

Quando si attiva la funzionalità di gestione temporanea, prima di tutto i dati sono copiati dall'archivio dati di origine all'archiviazione di staging (bring your own Azure Blob o Azure Data Lake Archiviazione Gen2). Successivamente, i dati verranno copiati dalla gestione temporanea all'archivio dati sink. L'attività di copia gestisce automaticamente il flusso a due fasi e pulisce anche i dati temporanei dall'archiviazione di staging dopo il completamento dello spostamento dei dati.

È necessario concedere l'autorizzazione di eliminazione ad Azure Data Factory nell'archiviazione di staging, in modo che i dati temporanei possano essere puliti dopo l'esecuzione dell'attività di copia.

Quando si attiva lo spostamento dei dati usando un archivio di staging, è possibile specificare se si desidera comprimere i dati prima di spostare i dati dall'archivio dati di origine all'archivio di staging e quindi decompressi prima di spostare i dati da un archivio dati provvisorio o di staging all'archivio dati sink.

Attualmente, non è possibile copiare dati tra due archivi dati connessi tramite IR self-hosted diversi, né con né senza copia di staging. Per questo scenario, è possibile configurare due attività di copia concatenati in modo esplicito per la copia dall'origine alla gestione temporanea e quindi dalla gestione temporanea al sink.

Configurazione

Configurare l'impostazione enableStaging nell'attività di copia per specificare se si vuole che i dati vengano inseriti nello spazio di archiviazione prima di caricarli in un archivio dati di destinazione. Quando si imposta enableStaging su TRUE, specificare le proprietà aggiuntive elencate nella tabella seguente.

Proprietà	Descrizione	Default value	Richiesto
enableStaging	Specificare se si vuole copiare i dati tramite un archivio di staging provvisorio.	False	No
linkedServiceName	Specificare il nome di un'archiviazione BLOB di Azure o di un servizio collegato azure Data Lake Archiviazione Gen2, che fa riferimento all'istanza di Archiviazione usata come archivio di staging provvisorio.	N/D	Sì, quando enableStaging è impostato su TRUE
path	Specificare il percorso che si desidera contenere i dati di gestione temporanea. Se non si specifica un percorso, il servizio crea un contenitore per archiviare i dati temporanei.	N/D	No
enableCompression	Specifica se i dati devono essere compressi prima che vengano copiati nella destinazione. Questa impostazione ridurre il volume dei dati da trasferire.	False	No

Nota

Se si usa la copia di staging con compressione abilitata, l'entità servizio o l'autenticazione MSI per il servizio collegato BLOB di staging non è supportato.

Ecco una definizione di esempio di un'attività di copia con le proprietà descritte nella tabella precedente:

"activities":[
    {
        "name": "CopyActivityWithStaging",
        "type": "Copy",
        "inputs": [...],
        "outputs": [...],
        "typeProperties": {
            "source": {
                "type": "OracleSource",
            },
            "sink": {
                "type": "SqlDWSink"
            },
            "enableStaging": true,
            "stagingSettings": {
                "linkedServiceName": {
                    "referenceName": "MyStagingStorage",
                    "type": "LinkedServiceReference"
                },
                "path": "stagingcontainer/path"
            }
        }
    }
]

Impatto della copia di staging sulla fatturazione

L'addebito è basato su due passaggi: durata della copia e tipo di copia.

• Quando si usa la gestione temporanea durante una copia cloud, che copia i dati da un archivio dati cloud a un altro archivio dati cloud, entrambe le fasi abilitate dal runtime di integrazione di Azure vengono addebitati i costi [somma della durata della copia per il passaggio 1 e il passaggio 2] x [prezzo unitario copia cloud].
• Quando si usa lo staging durante una copia ibrida, che copia i dati da un archivio dati locale a un archivio dati cloud, una fase abilitata da un runtime di integrazione self-hosted, viene addebitato un costo per [durata unità copia ibrida] x [prezzo unità copia ibrida] + [durata copia cloud] x [prezzo unitario copia cloud].

Contenuto correlato

Vedere gli altri articoli relativi all'attività di copia:

• Panoramica dell'attività di copia
• Guida a prestazioni e scalabilità dell'attività di copia
• Risolvere i problemi relativi alle prestazioni dell'attività di copia
• Usare Azure Data Factory per eseguire la migrazione dei dati dal data lake o dal data warehouse ad Azure
• Eseguire la migrazione dei dati da Amazon S3 a Archiviazione di Azure