Funzionalità di ottimizzazione delle prestazioni dell'attività Copy

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Questo articolo illustra le funzionalità di ottimizzazione delle prestazioni dell'attività Copy 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à di integrazione dei dati è un'unità di misura che rappresenta la potenza, ossia la combinazione tra CPU, memoria e allocazione di risorse di rete, di una singola unità nel servizio. L'unità di integrazione dati si applica solo ad Azure Integration Runtime ma non al runtime di integrazione self-hosted.

Le DIU consentite per abilitare l'esecuzione di un'attività di copia sono tra 4 e 256. Se non specificato o se si sceglie "Auto" nell'interfaccia utente, il servizio applica in modo dinamico l'impostazione di 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:

È 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 dell'attività Copy. Per ignorare l'impostazione predefinita, è possibile specificare un valore per la proprietà dataIntegrationUnits procedendo come segue. 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.

L'addebito sarà pari a numero di unità di distribuzione usate * durata copia * prezzo unitario/DIU-ora. 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 le prestazioni del runtime di integrazione self-hosted:

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

Si noti che negli scenari seguenti l'esecuzione di un'attività Copy 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, Tabella SAP, SQL Server e Teradata), a seconda del numero di partizioni di dati.

Copia parallela

È possibile impostare la copia parallela (proprietà parallelCopies nella definizione JSON dell'attività Copy o impostazione Degree of parallelism nella scheda Impostazioni delle proprietà dell'attività Copy nell'interfaccia utente) per indicare al parallelismo che si vuole usare l'attività di copia. Questa proprietà può essere considerata come il numero massimo di thread all'interno dell'attività Copy che possono leggere dall'origine o scrivere negli archivi dati sink in parallelo.

La copia parallela è ortogonale per unità di integrazione dati 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à Copy, 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.

La tabella seguente elenca il comportamento di copia parallela:

Per controllare il carico sui computer che ospitano gli archivi dati o per ottimizzare le prestazioni di copia, è possibile ignorare il valore predefinito e specificare un valore per la proprietà parallelCopies. Il valore deve essere un numero intero maggiore o uguale a 1. Per garantire prestazioni ottimali in fase di esecuzione, l'attività Copy usa un valore minore o uguale al valore configurato.

Quando si specifica un valore per la proprietà parallelCopies, 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à Copy lo usa. Questo aumento del carico avviene soprattutto quando ci sono più attività o esecuzioni simultanee delle stesse attività che vengono eseguite con lo stesso archivio dati. Se si nota che l'archivio dati o il runtime di integrazione self-hosted è sovraccarico, ridurre il valore parallelCopies per alleviarlo.

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 un archivio BLOB di Azure o Azure Data Lake Storage Gen2 come archivio di gestione temporanea. 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 dati in Azure Synapse Analytics.
  • Connettore Snowflake
  • Connettore Amazon Redshift
  • Connettore HDFS
• Non si vuole 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 le comunicazioni TCP in uscita sulla porta 1433 per Windows Firewall e 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 gestione temporanea tramite HTTP o HTTPS sulla porta 443, quindi caricare i dati dalla gestione temporanea nel database SQL o in 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 di gestione temporanea 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 caricarli nell'archivio dati di destinazione.

Come funziona la copia di staging

Quando si attiva la funzionalità di staging, i dati vengono prima copiati dall'archivio dati di origine nell'archivio di gestione temporanea (con il proprio archivio BLOB di Azure o Data Lake Storage Gen2). Successivamente, vengono copiati dalla gestione temporanea nell'archivio dati sink. L'attività Copy gestisce automaticamente il flusso a due fasi e pulisce anche i dati temporanei dall'archiviazione di gestione temporanea dopo il completamento dello spostamento dei dati.

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

Quando si attiva lo spostamento dei dati usando un archivio di staging, è possibile specificare se i dati devono essere compressi prima dello spostamento dall'archivio dati di origine all'archivio di gestione temporanea e poi decompressi prima dello spostamento dall'archivio dati provvisorio o di staging all'archivio dati sink.

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

Impostazione

Configurare l'impostazione enableStaging nell'attività Copy per specificare se i dati devono essere inseriti in un archivio di gestione temporanea prima del caricamento in un archivio dati di destinazione. Se si imposta enableStaging su TRUE, specificare le proprietà aggiuntive elencate nella tabella seguente.

Di seguito è riportata una definizione di esempio di attività Copy 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

I costi addebitati si basano su due passaggi: durata della copia e tipo di copia.

• Quando si usa la funzionalità di staging durante una copia nel cloud, ovvero la copia di dati da un archivio dati cloud a un altro archivio dati cloud con l'ottimizzazione del runtime di integrazione di Azure, il costo addebitato sarà [somma della durata della copia per i passaggi 1 e 2] x [prezzo unitario della copia nel cloud].
• Quando si usa la funzionalità di staging durante una copia ibrida, ovvero la copia di dati da un archivio dati locale a un archivio dati cloud e solo uno beneficia dell'ottimizzazione del runtime di integrazione di Azure, il costo addebitato sarà [durata della copia ibrida] x [prezzo unitario della copia ibrida] + [durata della copia nel cloud] x [prezzo unitario della copia nel 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 di prestazioni dell'attività Copy
• 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 un archivio dati Amazon S3 ad Archiviazione di Azure