Risolvere i problemi di prestazioni dell'attività Copy

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Questo articolo illustra come risolvere i problemi di prestazioni dell'attività di copia in Azure Data Factory.

Dopo aver eseguito un'attività di copia, è possibile raccogliere i risultati dell'esecuzione e le statistiche sulle prestazioni nella visualizzazione di monitoraggio dell'attività di copia. Di seguito viene riportato un esempio.

Suggerimenti per l'ottimizzazione delle prestazioni

In alcuni scenari, quando si esegue un'attività di copia, nella parte superiore verranno visualizzati i "suggerimenti per l'ottimizzazione delle prestazioni", come illustrato nell'esempio precedente. I suggerimenti indicano il collo di bottiglia identificato dal servizio per questa particolare esecuzione della copia, insieme ai suggerimenti su come aumentare la velocità effettiva della copia. Provare a apportare la modifica consigliata, quindi eseguire di nuovo la copia.

Come riferimento, attualmente i suggerimenti per l'ottimizzazione delle prestazioni forniscono suggerimenti per i casi seguenti:

Informazioni dettagliate sull'esecuzione dell'attività di copia

I dettagli e le durate dell'esecuzione nella parte inferiore della visualizzazione di monitoraggio dell'attività di copia descrivono le fasi principali che l'attività di copia passa attraverso (vedere l'esempio all'inizio di questo articolo), che è particolarmente utile per la risoluzione dei problemi relativi alle prestazioni della copia. Il collo di bottiglia dell'esecuzione della copia è quello con la durata più lunga. Fare riferimento alla tabella seguente nella definizione di ogni fase e informazioni su come risolvere i problemi relativi all'attività di copia in Azure IR e risolvere i problemi relativi all'attività di copia nel runtime di integrazione self-hosted con tali informazioni.

Risolvere i problemi relativi all'attività di copia in Azure IR

Seguire i passaggi di ottimizzazione delle prestazioni per pianificare ed eseguire test delle prestazioni per lo scenario.

Quando le prestazioni dell'attività di copia non soddisfano le aspettative, per risolvere i problemi relativi alle singole attività di copia in esecuzione in Azure Integration Runtime, se vengono visualizzati suggerimenti per l'ottimizzazione delle prestazioni nella visualizzazione di monitoraggio della copia, applicare il suggerimento e riprovare. In caso contrario, comprendere i dettagli dell'esecuzione dell'attività di copia, controllare quale fase ha la durata più lunga e applicare le indicazioni seguenti per migliorare le prestazioni di copia:

• Durata prolungata dello script di pre-copia: significa che il completamento dello script di pre-copia in esecuzione nel database sink richiede molto tempo. Ottimizzare la logica di script di pre-copia specificata per migliorare le prestazioni. Per ulteriori informazioni sul miglioramento dello script, contattare il team del database.

• "Trasferimento - Tempo al primo byte" con durata di lavoro prolungata: significa che la query di origine richiede molto tempo per restituire i dati. Controllare e ottimizzare la query o il server. Per altre informazioni, contattare il team dell'archivio dati.

• "Trasferimento - Origine elenco" ha riscontrato un lungo periodo di lavoro: significa che l'enumerazione dei file di origine o delle partizioni di dati del database di origine è lenta.

  • Quando si copiano dati da un'origine basata su file, se si usa il filtro con caratteri jolly per il percorso della cartella o il nome file (wildcardFolderPath o wildcardFileName) oppure si usa il filtro ora dell'ultima modifica del file (modifiedDatetimeStart omodifiedDatetimeEnd ), si noti che tale filtro genera un elenco di tutti i file nella cartella specificata sul lato client, quindi applicare il filtro. Tale enumerazione di file potrebbe diventare il collo di bottiglia soprattutto quando solo un piccolo set di file soddisfa la regola di filtro.

    • Controllare se è possibile copiare i file in base al percorso o al nome del file partizionato datetime. In questo modo non si comportano carichi di lavoro sul lato origine dell'inserzione.

    • Controllare se è possibile usare il filtro nativo dell'archivio dati, in particolare "prefisso" per Amazon S3/Archiviazione BLOB di Azure/File di Azure e "listAfter/listBefore" per ADLS Gen1. Questi filtri sono il filtro lato server dell'archivio dati e offrono prestazioni molto migliori.

    • Considerare la possibilità di suddividere un singolo set di dati di grandi dimensioni in diversi set di dati più piccoli e consentire l'esecuzione simultanea di tali processi di copia ogni parte dei dati. È possibile eseguire questa operazione con Lookup/GetMetadata + ForEach + Copy. Vedere Copiare file da più contenitori o Eseguire la migrazione dei dati da Amazon S3 ai modelli di soluzione ADLS Gen2 come esempio generale.

  • Controllare se il servizio segnala eventuali errori di limitazione nell'origine o se l'archivio dati è in stato di utilizzo elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

  • Usare Il runtime di integrazione di Azure nella stessa area o vicina all'area dell'archivio dati di origine.

• "Trasferimento - lettura dall'origine" ha riscontrato un lungo periodo di lavoro:

  • Adottare le procedure consigliate per il caricamento dei dati specifiche del connettore, se applicabile. Ad esempio, quando si copiano dati da Amazon Redshift, configurare per l'uso di Redshift UNLOAD.

  • Controllare se il servizio segnala eventuali errori di limitazione nell'origine o se l'archivio dati è in uso elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

  • Controllare il modello di origine e sink di copia:

    • Se il modello di copia supporta più di 4 unità di Integrazione dei dati (DIU), fare riferimento a questa sezione sui dettagli, in genere è possibile provare ad aumentare le UNITÀ di distribuzione per ottenere prestazioni migliori.

    • In caso contrario, considerare di suddividere un singolo set di dati di grandi dimensioni in diversi set di dati più piccoli e consentire l'esecuzione simultanea di tali processi di copia ogni parte dei dati. È possibile eseguire questa operazione con Lookup/GetMetadata + ForEach + Copy. Fare riferimento a Copiare file da più contenitori, Eseguire la migrazione dei dati da Amazon S3 ad ADLS Gen2 o Eseguire la copia bulk con modelli di soluzione di tabella dei controlli come esempio generale.

  • Usare Il runtime di integrazione di Azure nella stessa area o vicina all'area dell'archivio dati di origine.

• "Trasferimento - scrittura nel sink" ha riscontrato un lungo periodo di lavoro:

  • Adottare le procedure consigliate per il caricamento dei dati specifiche del connettore, se applicabile. Ad esempio, quando si copiano dati in Azure Synapse Analitica, usare l'istruzione PolyBase o COPY.

  • Controllare se il servizio segnala eventuali errori di limitazione nel sink o se l'archivio dati è in uso elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

  • Controllare il modello di origine e sink di copia:

    • Se il modello di copia supporta più di 4 unità di Integrazione dei dati (DIU), fare riferimento a questa sezione sui dettagli, in genere è possibile provare ad aumentare le UNITÀ di distribuzione per ottenere prestazioni migliori.

    • In caso contrario, ottimizzare gradualmente le copie parallele, si noti che troppi copie parallele potrebbero anche danneggiare le prestazioni.

  • Usare Il runtime di integrazione di Azure nella stessa area o vicina all'area dell'archivio dati sink.

Risolvere i problemi relativi all'attività di copia nel runtime di integrazione self-hosted

Seguire i passaggi di ottimizzazione delle prestazioni per pianificare ed eseguire test delle prestazioni per lo scenario.

Quando le prestazioni di copia non soddisfano le aspettative, per risolvere i problemi relativi alle singole attività di copia in esecuzione in Azure Integration Runtime, se vengono visualizzati suggerimenti per l'ottimizzazione delle prestazioni nella visualizzazione di monitoraggio della copia, applicare il suggerimento e riprovare. In caso contrario, comprendere i dettagli dell'esecuzione dell'attività di copia, controllare quale fase ha la durata più lunga e applicare le indicazioni seguenti per migliorare le prestazioni di copia:

• "Queue" ha riscontrato un lungo periodo di tempo: significa che l'attività di copia attende molto tempo nella coda fino a quando il runtime di integrazione self-hosted non ha una risorsa da eseguire. Controllare la capacità e l'utilizzo del runtime di integrazione e aumentare o aumentare le prestazioni in base al carico di lavoro.

• "Trasferimento - Tempo al primo byte" con durata di lavoro prolungata: significa che la query di origine richiede molto tempo per restituire i dati. Controllare e ottimizzare la query o il server. Per altre informazioni, contattare il team dell'archivio dati.

• "Trasferimento - Origine elenco" ha riscontrato un lungo periodo di lavoro: significa che l'enumerazione dei file di origine o delle partizioni di dati del database di origine è lenta.

  • Controllare se il computer del runtime di integrazione self-hosted ha bassa latenza che si connette all'archivio dati di origine. Se l'origine è in Azure, è possibile usare questo strumento per controllare la latenza dal computer del runtime di integrazione self-hosted all'area di Azure, meno è meglio.

  • Quando si copiano dati da un'origine basata su file, se si usa il filtro con caratteri jolly per il percorso della cartella o il nome file (wildcardFolderPath o wildcardFileName) oppure si usa il filtro ora dell'ultima modifica del file (modifiedDatetimeStart omodifiedDatetimeEnd ), si noti che tale filtro genera un elenco di tutti i file nella cartella specificata sul lato client, quindi applicare il filtro. Tale enumerazione di file potrebbe diventare il collo di bottiglia soprattutto quando solo un piccolo set di file soddisfa la regola di filtro.

    • Controllare se è possibile copiare i file in base al percorso o al nome del file partizionato datetime. In questo modo non si comportano carichi di lavoro sul lato origine dell'inserzione.

    • Controllare se è possibile usare il filtro nativo dell'archivio dati, in particolare "prefisso" per Amazon S3/Archiviazione BLOB di Azure/File di Azure e "listAfter/listBefore" per ADLS Gen1. Questi filtri sono il filtro lato server dell'archivio dati e offrono prestazioni molto migliori.

    • Considerare la possibilità di suddividere un singolo set di dati di grandi dimensioni in diversi set di dati più piccoli e consentire l'esecuzione simultanea di tali processi di copia ogni parte dei dati. È possibile eseguire questa operazione con Lookup/GetMetadata + ForEach + Copy. Vedere Copiare file da più contenitori o Eseguire la migrazione dei dati da Amazon S3 ai modelli di soluzione ADLS Gen2 come esempio generale.

  • Controllare se il servizio segnala eventuali errori di limitazione nell'origine o se l'archivio dati è in stato di utilizzo elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

• "Trasferimento - lettura dall'origine" ha riscontrato un lungo periodo di lavoro:

  • Controllare se il computer del runtime di integrazione self-hosted ha bassa latenza che si connette all'archivio dati di origine. Se l'origine è in Azure, è possibile usare questo strumento per controllare la latenza dal computer del runtime di integrazione self-hosted alle aree di Azure, meno è meglio.

  • Controllare se il computer del runtime di integrazione self-hosted ha una larghezza di banda in ingresso sufficiente per leggere e trasferire i dati in modo efficiente. Se l'archivio dati di origine si trova in Azure, è possibile usare questo strumento per controllare la velocità di download.

  • Controllare la tendenza di utilizzo della CPU e della memoria del runtime di integrazione self-hosted in portale di Azure,> ovvero la data factory o l'area di lavoro di Synapse,> pagina di panoramica. Valutare la possibilità di aumentare o ridurre il runtime di integrazione se l'utilizzo della CPU è elevato o la memoria disponibile è insufficiente.

  • Adottare le procedure consigliate per il caricamento dei dati specifiche del connettore, se applicabile. Ad esempio:

    • Quando si copiano dati da Oracle, Netezza, Teradata, SAP HANA, SAP Table e SAP Open Hub, abilitare le opzioni di partizione dei dati per copiare i dati in parallelo.

    • Quando si copiano dati da HDFS, configurare per l'uso di DistCp.

    • Quando si copiano dati da Amazon Redshift, configurare per l'uso di Redshift UNLOAD.

  • Controllare se il servizio segnala eventuali errori di limitazione nell'origine o se l'archivio dati è in uso elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

  • Controllare il modello di origine e sink di copia:

    • Se si copiano dati da archivi dati abilitati per l'opzione di partizione, prendere in considerazione la possibilità di ottimizzare gradualmente le copie parallele, si noti che troppi copie parallele potrebbero anche compromettere le prestazioni.

    • In caso contrario, considerare di suddividere un singolo set di dati di grandi dimensioni in diversi set di dati più piccoli e consentire l'esecuzione simultanea di tali processi di copia ogni parte dei dati. È possibile eseguire questa operazione con Lookup/GetMetadata + ForEach + Copy. Fare riferimento a Copiare file da più contenitori, Eseguire la migrazione dei dati da Amazon S3 ad ADLS Gen2 o Eseguire la copia bulk con modelli di soluzione di tabella dei controlli come esempio generale.

• "Trasferimento - scrittura nel sink" ha riscontrato un lungo periodo di lavoro:

  • Adottare le procedure consigliate per il caricamento dei dati specifiche del connettore, se applicabile. Ad esempio, quando si copiano dati in Azure Synapse Analitica, usare l'istruzione PolyBase o COPY.

  • Controllare se il computer del runtime di integrazione self-hosted ha bassa latenza che si connette all'archivio dati sink. Se il sink si trova in Azure, è possibile usare questo strumento per controllare la latenza dal computer del runtime di integrazione self-hosted all'area di Azure, meno è meglio.

  • Controllare se il computer del runtime di integrazione self-hosted ha una larghezza di banda in uscita sufficiente per trasferire e scrivere i dati in modo efficiente. Se l'archivio dati sink è in Azure, è possibile usare questo strumento per controllare la velocità di caricamento.

  • Controllare se la tendenza di utilizzo della CPU e della memoria del runtime di integrazione self-hosted in portale di Azure,> ovvero la data factory o l'area di lavoro di Synapse,> pagina di panoramica. Valutare la possibilità di aumentare o ridurre il runtime di integrazione se l'utilizzo della CPU è elevato o la memoria disponibile è insufficiente.

  • Controllare se il servizio segnala eventuali errori di limitazione nel sink o se l'archivio dati è in uso elevato. In tal caso, ridurre i carichi di lavoro nell'archivio dati o contattare l'amministratore dell'archivio dati per aumentare il limite di limitazione o la risorsa disponibile.

  • Prendere in considerazione la possibilità di ottimizzare gradualmente le copie parallele, si noti che un numero eccessivo di copie parallele potrebbe anche compromettere le prestazioni.

Prestazioni del connettore e del runtime di integrazione

Questa sezione illustra alcune guide alla risoluzione dei problemi relativi alle prestazioni per un particolare tipo di connettore o runtime di integrazione.

Il tempo di esecuzione dell'attività varia usando Il runtime di integrazione di Azure e il runtime di integrazione di rete virtuale di Azure

Il tempo di esecuzione dell'attività varia quando il set di dati si basa su runtime di integrazione diverso.

• Sintomi: è sufficiente attivare o disattivare l'elenco a discesa Servizio collegato nel set di dati esegue le stesse attività della pipeline, ma ha tempi di esecuzione drasticamente diversi. Quando il set di dati si basa sul runtime di integrazione di Rete virtuale gestito, richiede più tempo in media rispetto all'esecuzione quando si basa sul runtime di integrazione predefinito.

• Causa: controllare i dettagli delle esecuzioni della pipeline, è possibile notare che la pipeline lenta è in esecuzione nel runtime di integrazione di rete virtuale gestita (Rete virtuale) mentre quello normale è in esecuzione in Azure IR. Per impostazione predefinita, il runtime di integrazione di rete virtuale gestita richiede più tempo della coda rispetto al runtime di integrazione di Azure perché non si riserva un nodo di calcolo per ogni istanza del servizio, quindi si verifica un riscaldamento per ogni attività di copia da avviare e si verifica principalmente nell'aggiunta alla rete virtuale anziché al runtime di integrazione di Azure.

Prestazioni ridotte durante il caricamento dei dati in database SQL di Azure

• Sintomi: la copia dei dati in in database SQL di Azure diventa lenta.

• Causa: la causa radice del problema è principalmente attivata dal collo di bottiglia del lato database SQL di Azure. Di seguito sono riportate alcune possibili cause:

  • database SQL di Azure livello non è sufficientemente elevato.

  • database SQL di Azure utilizzo DTU è vicino al 100%. È possibile monitorare le prestazioni e prendere in considerazione l'aggiornamento del livello database SQL di Azure.

  • Gli indici non sono impostati correttamente. Rimuovere tutti gli indici prima del caricamento dei dati e ricrearli al termine del caricamento.

  • WriteBatchSize non è abbastanza grande per adattarsi alle dimensioni delle righe dello schema. Provare ad ingrandire la proprietà per il problema.

  • Anziché l'inserimento bulk, viene usata la stored procedure, che dovrebbe avere prestazioni peggiori.

Timeout o rallentamento delle prestazioni durante l'analisi di file di Excel di grandi dimensioni

• Sintomi:

  • Quando si crea un set di dati di Excel e si importa lo schema dalla connessione/archivio, dai dati di anteprima, dall'elenco o dagli aggiornamenti dei fogli di lavoro, è possibile che si verifichi un errore di timeout se il file excel è di grandi dimensioni.

  • Quando si usa l'attività di copia per copiare dati da un file di Excel di grandi dimensioni (>= 100 MB) in un altro archivio dati, è possibile che si verifichi un rallentamento delle prestazioni o un problema di OOM.

• Causa:

  • Per operazioni come l'importazione dello schema, l'anteprima dei dati e l'elenco dei fogli di lavoro nel set di dati excel, il timeout è 100 s e statico. Per un file di Excel di grandi dimensioni, queste operazioni potrebbero non terminare entro il valore di timeout.

  • L'attività di copia legge l'intero file di Excel in memoria, quindi individua il foglio di lavoro e le celle specificati per leggere i dati. Questo comportamento è dovuto all'SDK sottostante usato dal servizio.

• Risoluzione:

  • Per l'importazione dello schema, è possibile generare un file di esempio più piccolo, ovvero un subset di file originale, e scegliere "Importa schema dal file di esempio" anziché "Importa schema da connessione/archivio".

  • Per elencare il foglio di lavoro, nell'elenco a discesa del foglio di lavoro è possibile fare clic su "Modifica" e immettere invece il nome o l'indice del foglio.

  • Per copiare file excel di grandi dimensioni (>100 MB) in un altro archivio, è possibile usare Flusso di dati origine excel che lo streaming sportivo legge e prestazioni migliori.

Problema OOM di lettura di file JSON/Excel/XML di grandi dimensioni

• Sintomi: quando si leggono file JSON/Excel/XML di grandi dimensioni, si verifica il problema di memoria insufficiente durante l'esecuzione dell'attività.

• Causa:

  • Per file XML di grandi dimensioni: il problema OOM di lettura di file XML di grandi dimensioni è progettato. La causa è che l'intero file XML deve essere letto in memoria perché è un singolo oggetto, quindi viene dedotto lo schema e i dati vengono recuperati.
  • Per file di Excel di grandi dimensioni: il problema OOM di lettura di file di Excel di grandi dimensioni è da progettare. La causa è che l'SDK (POI/NPOI) usato deve leggere l'intero file di Excel in memoria, quindi dedurre lo schema e ottenere i dati.
  • Per file JSON di grandi dimensioni: il problema OOM di lettura di file JSON di grandi dimensioni è progettato quando il file JSON è un singolo oggetto.

• Raccomandazione: applicare una delle opzioni seguenti per risolvere il problema.

  • Opzione-1: registrare un runtime di integrazione self-hosted online con potenti computer (CPU/memoria elevata) per leggere i dati dal file di grandi dimensioni tramite l'attività di copia.
  • Opzione-2: usare una memoria ottimizzata e un cluster di grandi dimensioni (ad esempio, 48 core) per leggere i dati dal file di grandi dimensioni tramite l'attività del flusso di dati di mapping.
  • Opzione-3: suddividere il file di grandi dimensioni in quelli di piccole dimensioni, quindi usare l'attività di copia o mapping del flusso di dati per leggere la cartella.
  • Opzione-4: se si è bloccati o si verifica il problema OOM durante la copia della cartella XML/Excel/JSON, usare l'attività foreach + copia/mapping del flusso di dati nella pipeline per gestire ogni file o sottocartella.
  • Opzione-5: Altri:
    • Per XML, usare l'attività Notebook con un cluster ottimizzato per la memoria per leggere i dati dai file se ogni file ha lo stesso schema. Attualmente Spark include implementazioni diverse per gestire xml.
    • Per JSON, usare moduli di documento diversi(ad esempio, documento singolo, documento per riga e matrice di documenti) nelle impostazioni JSON nell'origine del flusso di dati per mapping. Se il contenuto del file JSON è Document per riga, consuma molto poco memoria.

Altri riferimenti

Di seguito sono riportati alcuni riferimenti sul monitoraggio e l'ottimizzazione delle prestazioni per alcuni degli archivi dati supportati:

• Archiviazione BLOB di Azure: obiettivi di scalabilità e prestazioni per l'archiviazione BLOB e elenco di controllo per prestazioni e scalabilità per l'archiviazione BLOB.
• Archiviazione tabelle di Azure: obiettivi di scalabilità e prestazioni per l'archiviazione tabelle e l'elenco di controllo delle prestazioni e della scalabilità per l'archiviazione tabelle.
• database SQL di Azure: è possibile monitorare le prestazioni e controllare la percentuale DTU (Database Transaction Unit).
• Azure Synapse Analitica: la sua funzionalità viene misurata in unità data warehouse (DWU). Vedere Gestire la potenza di calcolo in Azure Synapse Analitica (panoramica).
• Azure Cosmos DB: livelli di prestazioni in Azure Cosmos DB.
• SQL Server: monitorare e ottimizzare le prestazioni.
• File server locale: Ottimizzazione delle prestazioni per i file server.

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
• attività Copy funzionalità di ottimizzazione delle prestazioni
• 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