Share via


Usare Azure Data Factory per eseguire la migrazione dei dati da un cluster Hadoop locale a Archiviazione di Azure

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 .

Azure Data Factory offre un meccanismo efficiente, affidabile e conveniente per la migrazione dei dati su larga scala da HDFS locale ad Archiviazione BLOB di Azure o Azure Data Lake Archiviazione Gen2.

Data Factory offre due approcci di base per la migrazione dei dati da HDFS locale ad Azure. È possibile selezionare l'approccio in base allo scenario in uso.

  • Modalità DistCp di Data Factory (scelta consigliata): in Data Factory è possibile usare DistCp (copia distribuita) per copiare i file così come sono nell'archivio BLOB di Azure (inclusa la copia a fasi) o In Azure Data Lake Store Gen2. Usare Data Factory integrato con DistCp per sfruttare un cluster potente esistente per ottenere la migliore velocità effettiva di copia. Si ottiene anche il vantaggio della pianificazione flessibile e di un'esperienza di monitoraggio unificata di Data Factory. A seconda della configurazione di Data Factory, l'attività di copia crea automaticamente un comando DistCp, invia i dati al cluster Hadoop e quindi monitora lo stato della copia. È consigliabile usare la modalità DistCp di Data Factory per la migrazione dei dati da un cluster Hadoop locale ad Azure.
  • Modalità di runtime di integrazione nativa di Data Factory: DistCp non è un'opzione in tutti gli scenari. Ad esempio, in un ambiente azure Rete virtuale s, lo strumento DistCp non supporta il peering privato di Azure ExpressRoute con un endpoint di rete virtuale Archiviazione di Azure. In alcuni casi, inoltre, non si vuole usare il cluster Hadoop esistente come motore per la migrazione dei dati in modo da non inserire carichi pesanti nel cluster, che potrebbero influire sulle prestazioni dei processi ETL esistenti. È invece possibile usare la funzionalità nativa del runtime di integrazione di Data Factory come motore che copia i dati da HDFS locale ad Azure.

Questo articolo fornisce le informazioni seguenti su entrambi gli approcci:

  • Prestazione
  • Resilienza della copia
  • Sicurezza di rete
  • Architettura di alto livello della soluzione
  • Procedure consigliate dell'implementazione

Prestazioni

In modalità DistCp di Data Factory la velocità effettiva è identica a quella usata in modo indipendente dallo strumento DistCp. La modalità DistCp di Data Factory ottimizza la capacità del cluster Hadoop esistente. È possibile usare DistCp per la copia tra cluster di grandi dimensioni o all'interno del cluster.

DistCp usa MapReduce per rendere effettiva la distribuzione, la gestione degli errori e il ripristino e la creazione di report. Espande un elenco di file e directory in input per il mapping delle attività. Ogni attività copia una partizione di file specificata nell'elenco di origine. È possibile usare Data Factory integrato con DistCp per creare pipeline per usare completamente la larghezza di banda di rete, le operazioni di I/O al secondo di archiviazione e la larghezza di banda per ottimizzare la velocità effettiva dello spostamento dei dati per l'ambiente.

La modalità di runtime di integrazione nativa di Data Factory consente anche il parallelismo a livelli diversi. È possibile usare il parallelismo per usare completamente la larghezza di banda di rete, le operazioni di I/O al secondo di archiviazione e la larghezza di banda per ottimizzare la velocità effettiva dello spostamento dei dati:

  • Una singola attività di copia può sfruttare le risorse di calcolo scalabili. Con un runtime di integrazione self-hosted, è possibile aumentare manualmente il numero di istanze del computer o aumentare il numero di istanze in più computer (fino a quattro nodi). Una singola attività di copia ne partiziona il set di file in tutti i nodi.
  • Una singola attività di copia legge e scrive nell'archivio dati usando più thread.
  • Il flusso di controllo di Data Factory può avviare più attività di copia in parallelo. Ad esempio, è possibile usare un ciclo For Each.

Per altre informazioni, vedere la guida alle prestazioni dell'attività di copia.

Resilienza

Nella modalità DistCp di Data Factory è possibile usare diversi parametri della riga di comando DistCp (ad esempio, -iignorare gli errori o -update, scrivere i dati quando il file di origine e il file di destinazione differiscono in base alle dimensioni) per livelli di resilienza diversi.

Nella modalità di runtime di integrazione nativa di Data Factory, in una singola esecuzione dell'attività di copia, Data Factory ha un meccanismo di ripetizione dei tentativi predefinito. Può gestire un determinato livello di errori temporanei negli archivi dati o nella rete sottostante.

Quando si esegue la copia binaria da HDFS locale all'archiviazione BLOB e da HDFS locale a Data Lake Store Gen2, Data Factory esegue automaticamente il checkpoint in larga misura. Se un'esecuzione dell'attività di copia ha esito negativo o si verifica il timeout, in un nuovo tentativo successivo (assicurarsi che il numero di tentativi sia > 1), la copia riprende dall'ultimo punto di errore anziché iniziare all'inizio.

Sicurezza di rete

Per impostazione predefinita, Data Factory trasferisce i dati da HDFS locale ad archiviazione BLOB o Azure Data Lake Archiviazione Gen2 usando una connessione crittografata tramite protocollo HTTPS. Il protocollo HTTPS offre la crittografia dei dati in transito e impedisce l'intercettazione e gli attacchi man-in-the-middle.

In alternativa, se non si vuole trasferire i dati tramite Internet pubblico, per una maggiore sicurezza, è possibile trasferire i dati tramite un collegamento di peering privato tramite ExpressRoute.

Architettura della soluzione

Questa immagine illustra la migrazione dei dati tramite Internet pubblico:

Diagram that shows the solution architecture for migrating data over a public network

  • In questa architettura, i dati vengono trasferiti in modo sicuro usando HTTPS su Internet pubblico.
  • È consigliabile usare la modalità DistCp di Data Factory in un ambiente di rete pubblico. È possibile sfruttare un potente cluster esistente per ottenere la migliore velocità effettiva di copia. Si ottiene anche il vantaggio della pianificazione flessibile e dell'esperienza di monitoraggio unificata di Data Factory.
  • Per questa architettura, è necessario installare il runtime di integrazione self-hosted di Data Factory in un computer Windows dietro un firewall aziendale per inviare il comando DistCp al cluster Hadoop e per monitorare lo stato della copia. Poiché il computer non è il motore che sposta i dati (solo a scopo di controllo), la capacità del computer non influisce sulla velocità effettiva dello spostamento dei dati.
  • I parametri esistenti del comando DistCp sono supportati.

Questa immagine illustra la migrazione dei dati tramite un collegamento privato:

Diagram that shows the solution architecture for migrating data over a private network

  • In questa architettura i dati vengono migrati tramite un collegamento di peering privato tramite Azure ExpressRoute. I dati non attraversano mai la rete Internet pubblica.
  • Lo strumento DistCp non supporta il peering privato di ExpressRoute con un endpoint di rete virtuale Archiviazione di Azure. È consigliabile usare la funzionalità nativa di Data Factory tramite il runtime di integrazione per eseguire la migrazione dei dati.
  • Per questa architettura, è necessario installare il runtime di integrazione self-hosted di Data Factory in una macchina virtuale Windows nella rete virtuale di Azure. È possibile aumentare manualmente le prestazioni della macchina virtuale o aumentare il numero di istanze in più macchine virtuali per usare completamente le operazioni di I/O al secondo di rete e archiviazione o la larghezza di banda.
  • La configurazione consigliata per iniziare con per ogni macchina virtuale di Azure (con il runtime di integrazione self-hosted di Data Factory installato) è Standard_D32s_v3 con 32 vCPU e 128 GB di memoria. È possibile monitorare l'utilizzo della CPU e della memoria della macchina virtuale durante la migrazione dei dati per verificare se è necessario aumentare le prestazioni della macchina virtuale per ottenere prestazioni migliori o ridurre le prestazioni della macchina virtuale per ridurre i costi.
  • È anche possibile aumentare il numero di istanze associando fino a quattro nodi vm a un singolo runtime di integrazione self-hosted. Un singolo processo di copia in esecuzione in un runtime di integrazione self-hosted partiziona automaticamente il set di file e usa tutti i nodi della macchina virtuale per copiare i file in parallelo. Per la disponibilità elevata, è consigliabile iniziare con due nodi della macchina virtuale per evitare uno scenario a singolo punto di errore durante la migrazione dei dati.
  • Quando si usa questa architettura, sono disponibili la migrazione iniziale dei dati snapshot e la migrazione dei dati differenziali.

Procedure consigliate dell'implementazione

È consigliabile seguire queste procedure consigliate quando si implementa la migrazione dei dati.

Gestione dell'autenticazione e delle credenziali

  • Per eseguire l'autenticazione in HDFS, è possibile usare Windows (Kerberos) o Anonimo.
  • Per la connessione all'archiviazione BLOB di Azure sono supportati più tipi di autenticazione. È consigliabile usare le identità gestite per le risorse di Azure. Basato su un'identità di Data Factory gestita automaticamente in Microsoft Entra ID, le identità gestite consentono di configurare le pipeline senza fornire le credenziali nella definizione del servizio collegato. In alternativa, è possibile eseguire l'autenticazione nell'archiviazione BLOB usando un'entità servizio, una firma di accesso condiviso o una chiave dell'account di archiviazione.
  • Sono supportati anche più tipi di autenticazione per la connessione a Data Lake Archiviazione Gen2. È consigliabile usare le identità gestite per le risorse di Azure, ma è anche possibile usare un'entità servizio o una chiave dell'account di archiviazione.
  • Quando non si usano identità gestite per le risorse di Azure, è consigliabile archiviare le credenziali in Azure Key Vault per semplificare la gestione centralizzata e la rotazione delle chiavi senza modificare i servizi collegati di Data Factory. Si tratta anche di una procedura consigliata per CI/CD.

Migrazione iniziale dei dati dello snapshot

In modalità DistCp di Data Factory è possibile creare un'attività di copia per inviare il comando DistCp e usare parametri diversi per controllare il comportamento iniziale della migrazione dei dati.

In modalità di runtime di integrazione nativa di Data Factory è consigliabile eseguire la partizione dei dati, soprattutto quando si esegue la migrazione di più di 10 TB di dati. Per partizionare i dati, usare i nomi delle cartelle in HDFS. Ogni processo di copia di Data Factory può quindi copiare una partizione di cartella alla volta. È possibile eseguire più processi di copia di Data Factory contemporaneamente per una migliore velocità effettiva.

Se uno dei processi di copia ha esito negativo a causa di problemi temporanei di rete o archivio dati, è possibile eseguire di nuovo il processo di copia non riuscito per ricaricare tale partizione specifica da HDFS. Altri processi di copia che caricano altre partizioni non sono interessati.

Migrazione dei dati Delta

In modalità DistCp di Data Factory è possibile usare il parametro -updatedella riga di comando DistCp , scrivere i dati quando il file di origine e il file di destinazione differiscono in base alle dimensioni, per la migrazione dei dati differenziali.

In modalità di integrazione nativa di Data Factory, il modo più efficiente per identificare i file nuovi o modificati da HDFS consiste nell'usare una convenzione di denominazione partizionata in tempo. Quando i dati in HDFS sono stati partizionati in tempo con informazioni sulla sezione temporale nel nome del file o della cartella (ad esempio, /aa/mm/dd/file.csv), la pipeline può identificare facilmente quali file e cartelle copiare in modo incrementale.

In alternativa, se i dati in HDFS non sono partizionati in tempo, Data Factory può identificare file nuovi o modificati usando il valore LastModifiedDate . Data Factory analizza tutti i file da HDFS e copia solo i file nuovi e aggiornati con un timestamp dell'ultima modifica maggiore di un valore impostato.

Se si dispone di un numero elevato di file in HDFS, l'analisi iniziale dei file potrebbe richiedere molto tempo, indipendentemente dal numero di file che corrispondono alla condizione di filtro. In questo scenario è consigliabile partizionare prima i dati usando la stessa partizione usata per la migrazione dello snapshot iniziale. Quindi, l'analisi dei file può verificarsi in parallelo.

Stimare il prezzo

Si consideri la pipeline seguente per la migrazione dei dati da HDFS ad Archiviazione BLOB di Azure:

Diagram that shows the pricing pipeline

Si supponga di presupporre le informazioni seguenti:

  • Il volume totale dei dati è 1 PB.
  • È possibile eseguire la migrazione dei dati usando la modalità di runtime di integrazione nativa di Data Factory.
  • 1 PB è suddiviso in 1.000 partizioni e ogni copia sposta una partizione.
  • Ogni attività di copia è configurata con un runtime di integrazione self-hosted associato a quattro computer e che ottiene una velocità effettiva di 500 MBps.
  • La concorrenza ForEach è impostata su 4 e la velocità effettiva aggregata è di 2 GBps.
  • In totale, sono necessarie 146 ore per completare la migrazione.

Ecco il prezzo stimato in base ai nostri presupposti:

Table that shows pricing calculations

Nota

Si tratta di un esempio di prezzo ipotetico. I prezzi effettivi variano in base alla velocità effettiva dell'ambiente. Il prezzo per una macchina virtuale Windows di Azure (con runtime di integrazione self-hosted installato) non è incluso.

Altri riferimenti