Risolvere i problemi relativi alle prestazioni dell'attività di copia

  • Articolo

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 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.

Monitor copy activity run details

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:

Categoria Suggerimenti per l'ottimizzazione delle prestazioni
Archivio dati specifico Caricamento dei dati in Azure Synapse Analytics: suggerire l'uso dell'istruzione PolyBase o COPY se non viene usata.
  Copia di dati da/a database SQL di Azure: quando DTU è in un utilizzo elevato, suggerire l'aggiornamento al livello superiore.
  Copia di dati da/in Azure Cosmos DB: quando le UR sono in condizioni di utilizzo elevato, suggerire l'aggiornamento a UR di dimensioni maggiori.
Copia dei dati dalla tabella SAP: quando si copia una grande quantità di dati, suggerire di sfruttare l'opzione di partizione di SAP Connector per abilitare il caricamento parallelo e aumentare il numero di partizione massimo.
  Inserimento di dati da Amazon Redshift: suggerisci di usare UNLOAD se non viene usato.
Limitazione dell'archivio dati Se un numero di operazioni di lettura/scrittura viene limitato dall'archivio dati durante la copia, suggerire il controllo e aumentare la frequenza di richiesta consentita per l'archivio dati o ridurre il carico di lavoro simultaneo.
Runtime di integrazione Se si usa un runtime di integrazione self-hosted e l'attività di copia attende molto tempo nella coda fino a quando il runtime di integrazione non dispone della risorsa disponibile per l'esecuzione, suggerire l'aumento o l'aumento del runtime di integrazione.
  Se si usa un runtime di integrazione di Azure che si trova in un'area non ottimale con conseguente rallentamento della lettura/scrittura, suggerire la configurazione per l'uso di un runtime di integrazione in un'altra area.
Tolleranza di errore Se si configura la tolleranza di errore e si ignorano le righe incompatibili si ottengono prestazioni lente, è consigliabile assicurarsi che i dati di origine e sink siano compatibili.
copia di staging Se la copia a fasi è configurata ma non utile per la coppia di sink di origine, suggerire di rimuoverla.
Riprendi Quando l'attività di copia viene ripresa dall'ultimo punto di errore, ma si modifica l'impostazione DIU dopo l'esecuzione originale, si noti che la nuova impostazione DIU non ha effetto.

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.

Fase Descrizione
Coda Tempo trascorso fino all'avvio effettivo dell'attività di copia nel runtime di integrazione.
Script di pre-copia Tempo trascorso tra l'attività di copia avviata nel runtime di integrazione e l'attività di copia completando l'esecuzione dello script di pre-copia nell'archivio dati sink. Applicare quando si configura lo script di pre-copia per i sink di database, ad esempio quando si scrivono dati in database SQL di Azure eseguire la pulizia prima di copiare nuovi dati.
Trasferimenti Tempo trascorso tra la fine del passaggio precedente e il runtime di integrazione che trasferisce tutti i dati dall'origine al sink.
Si notino i passaggi secondari nell'esecuzione del trasferimento in parallelo e alcune operazioni non vengono ora visualizzate, ad esempio il formato di file di analisi/generazione.

- Tempo al primo byte: tempo trascorso tra la fine del passaggio precedente e il momento in cui il runtime di integrazione riceve il primo byte dall'archivio dati di origine. Si applica alle origini non basate su file.
- Elenco origine: quantità di tempo impiegato per enumerare file di origine o partizioni di dati. Quest'ultimo si applica quando si configurano le opzioni di partizione per le origini di database, ad esempio quando si copiano dati da database come Oracle/SAP HANA/Teradata/Netezza/etc.
-Lettura dall'origine: quantità di tempo impiegato per il recupero dei dati dall'archivio dati di origine.
- Scrittura nel sink: quantità di tempo impiegato per la scrittura di dati nell'archivio dati sink. Si noti che alcuni connettori non hanno questa metrica al momento, tra cui Ricerca di intelligenza artificiale di Azure, Azure Esplora dati, Archiviazione tabelle di Azure, Oracle, SQL Server, Common Data Service, Dynamics 365, Dynamics CRM, Salesforce/Salesforce Service Cloud.

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:

    • 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 Analytics, 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:

    • 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:

  • "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 Analytics, 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 di Connessione or e 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:

Contenuto correlato

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