Eseguire la migrazione di cluster Apache Hadoop locali ad Azure HDInsight - Procedure consigliate per la migrazione dei dati
Questo articolo offre indicazioni per la migrazione dei dati ad Azure HDInsight. L'articolo fa parte di una serie di documenti che descrivono le procedure consigliate per facilitare la migrazione di sistemi Apache Hadoop locali ad Azure HDInsight.
Eseguire la migrazione di dati locali ad Azure
Esistono due opzioni principali per eseguire la migrazione dei dati da un sistema locale all'ambiente Azure:
Trasferimento dei dati sulla rete con TLS
Tramite Internet: è possibile trasferire i dati nell'archiviazione di Azure tramite una normale connessione Internet usando uno dei diversi strumenti, ad esempio: Archiviazione di Azure Explorer, AzCopy, Azure PowerShell e l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Spostamento di dati da e verso Archiviazione di Azure.
ExpressRoute: ExpressRoute è un servizio di Azure che consente di creare connessioni private tra i data center Microsoft e l'infrastruttura in locale o in una struttura di condivisione. Le connessioni ExpressRoute non passano su Internet pubblico e offrono maggiore sicurezza, affidabilità e velocità con latenze inferiori rispetto alle connessioni tipiche su Internet. Per altre informazioni, vedere Creare e modificare un circuito ExpressRoute.
Trasferimento dei dati online Data Box: Data Box Edge e Data Box Gateway sono prodotti per il trasferimento dei dati online che fungono da gateway di archiviazione di rete per gestire i dati tra il sito e Azure. Data Box Edge, un dispositivo di rete locale, trasferisce i dati verso e da Azure e usa risorse di calcolo perimetrali abilitate per intelligenza artificiale per elaborare i dati. Data Box Gateway è un'appliance virtuale con funzionalità di gateway di archiviazione. Per altre informazioni, vedere Documentazione di Azure Data Box - Trasferimento online.
Spedizione dei dati offline
Trasferimento dei dati offline di Data Box: i dispositivi Data Box, Data Box Disk e Data Box Heavy consentono di trasferire grandi quantità di dati in Azure quando la rete non è un'opzione. Questi dispositivi per il trasferimento dei dati offline vengono spediti tra l'organizzazione e il data center di Azure. Usano la crittografia AES per la protezione dei dati in transito e vengono sottoposti a un processo completo di bonifica dopo il caricamento per l'eliminazione dei dati. Per altre informazioni sui dispositivi di trasferimento offline di Data Box, vedere la documentazione di Azure Data Box - Trasferimento offline. Per altre informazioni sulla migrazione dei cluster Hadoop, vedere Usare Azure Data Box per eseguire la migrazione da un archivio HDFS locale a Archiviazione di Azure.
La tabella seguente indica una durata di trasferimento dei dati approssimativa, basata sul volume dei dati e sulla larghezza di banda della rete. Usare un'appliance Data Box se si prevede che la migrazione dei dati richieda più di tre settimane.
| Qtà di dati | Larghezza di banda della rete di 45 Mbps (T3) |
Larghezza di banda della rete di 100 Mbps |
Larghezza di banda della rete di 1 Gbps |
Larghezza di banda della rete di 10 Gbps |
|---|---|---|---|---|
| 1 TB | 2 giorni | 1 giorno | 2 ore | 14 minuti |
| 10 TB | 22 giorni | 10 giorni | 1 giorno | 2 ore |
| 35 TB | 76 giorni | 34 giorni | 3 giorni | 8 ore |
| 80 TB | 173 giorni | 78 giorni | 8 giorni | 19 ore |
| 100 TB | 216 giorni | 97 giorni | 10 giorni | 1 giorno |
| 200 TB | 1 anno | 194 giorni | 19 giorni | 2 giorni |
| 500 TB | 3 anni | 1 anno | 49 giorni | 5 giorni |
| 1 PB | 6 anni | 3 anni | 97 giorni | 10 giorni |
| 2 PB | 12 anni | 5 anni | 194 giorni | 19 giorni |
Gli strumenti nativi di Azure, ad esempio Apache Hadoop, DistCp, Azure Data Factory e AzureCp, possono essere usati per trasferire i dati in rete. Per lo stesso scopo può essere usato anche lo strumento di terze parti WANDisco. Per i trasferimenti continui di dati da un sistema locale ai sistemi di archiviazione di Azure è possibile usare Apache Kafka Mirrormaker e Apache Sqoop.
Considerazioni sulle prestazioni con Apache Hadoop DistCp
DistCp è un progetto Apache che usa un processo di mapping di MapReduce per trasferire i dati, gestire gli errori ed eseguire il ripristino. Assegna un elenco di file di origine a ogni attività di mapping. L'attività di mapping copia quindi tutti i file ricevuti in assegnazione nella destinazione. Esistono diverse tecniche per migliorare le prestazioni di DistCp.
Aumentare il numero di mapper
DistCp prova a creare attività di mapping in modo che ognuna possa copiare all'incirca lo stesso numero di byte. Per impostazione predefinita, i processi di DistCp usano 20 mapper. L'uso di più mapper per Distcp (con il parametro m alla riga di comando) aumenta il parallelismo durante il processo di trasferimento dei dati e consente di ridurre la durata del trasferimento. Tuttavia, esistono due aspetti da considerare quando si aumenta il numero di mapper:
La granularità minima di DistCp è rappresentata da un singolo file. Se si specifica un numero di mapper maggiore del numero di file di origine, non è utile e si sprecano le risorse del cluster disponibili.
Prendere in considerazione la memoria YARN disponibile nel cluster per determinare il numero di mapper. Ogni attività di mapping viene avviata come contenitore YARN. Supponendo che non siano in esecuzione altri carichi di lavoro pesanti nel cluster, il numero di mapper può essere determinato dalla formula seguente: m = (numero di nodi di lavoro * memorie YARN per ogni nodo di lavoro) / dimensioni del contenitore YARN. Tuttavia, se la memoria è usata da altre applicazioni, scegliere di usare solo una parte della memoria YARN per i processi di DistCp.
Usare più processi di DistCp
Quando la dimensione del set di dati da spostare supera 1 TB, usare più processi di DistCp. Usando più processi l'impatto degli errori risulta limitato. Se un processo non riesce, è sufficiente riavviare tale processo anziché tutti i processi.
Considerare la possibilità di dividere i file
Se è presente un numero ridotto di file di grandi dimensioni, è possibile dividere i file in blocchi da 256 MB per ottenere una maggiore concorrenza potenziale con più mapper.
Usare il parametro strategy della riga di comando
È consigliabile usare il parametro strategy = dynamic nella riga di comando. Il valore predefinito del parametro strategy è uniform size, nel qual caso ogni mapping copia all'incirca lo stesso numero di byte. Se questo parametro viene impostato su dynamic, il file listato viene diviso in diversi blocchi. Il numero di blocchi è un multiplo del numero di mapping. A ogni attività di mapping viene assegnato uno dei blocchi. Al termine dell'elaborazione di tutti i percorsi di un blocco, il blocco corrente viene eliminato e viene acquisito un nuovo blocco. Il processo continua fino a quando non sono disponibili altri blocchi. Questo approccio dinamico consente alle attività di mapping più veloci di utilizzare un numero maggiore di percorsi rispetto alle attività più lente, determinando una velocizzazione complessiva del processo di DistCp.
Aumentare il numero di thread
Verificare se aumentando il valore del parametro -numListstatusThreads migliorano le prestazioni. Questo parametro controlla il numero di thread da usare per la creazione dell'elenco di file e 40 è il valore massimo.
Usare l'algoritmo committer dell'output
Verificare se passando il parametro -Dmapreduce.fileoutputcommitter.algorithm.version=2 migliorano le prestazioni di DistCp. Questo algoritmo committer dell'output presenta ottimizzazioni per la scrittura di file di output nella destinazione. Il comando seguente è un esempio che illustra l'utilizzo di parametri diversi:
hadoop distcp -Dmapreduce.fileoutputcommitter.algorithm.version=2 -numListstatusThreads 30 -m 100 -strategy dynamic hdfs://nn1:8020/foo/bar wasb://<container_name>@<storage_account_name>.blob.core.windows.net/foo/
Migrazione di metadati
Apache Hive
È possibile eseguire la migrazione del metastore Hive usando gli script o la replica di database.
Migrazione del metastore Hive con gli script
- Generare gli DDL Hive dal metastore Hive locale. Questo passaggio può essere eseguito tramite uno script Bash wrapper.
- Modificare l'istruzione DDL generata per sostituire l'URL Hadoop Distributed File System con gli URL WASB/ADLS/ABFS.
- Eseguire l'istruzione DDL aggiornata sul metastore dal cluster HDInsight.
- Assicurarsi che la versione del metastore Hive sia compatibile per il passaggio da sistemi locali a cloud.
Migrazione del metastore Hive con la replica di database
Configurare la replica tra il database del metastore Hive locale e il database del metastore HDInsight.
Usare Hive MetaTool per sostituire l'URL HDFS con gli URL WASB/ADLS/ABFS, ad esempio:
./hive --service metatool -updateLocation hdfs://nn1:8020/ wasb://<container_name>@<storage_account_name>.blob.core.windows.net/
Apache Ranger
- Esportare i criteri locali di Ranger nei file xml.
- Trasformare percorsi basati su HDFS specifici dell'ambiente locale in WASB/ADLS usando uno strumento come XSLT.
- Importare i criteri in Ranger che viene eseguito in HDInsight.
Passaggi successivi
Leggere l'articolo successivo di questa serie:
- Security and DevOps best practices for on-premises to Azure HDInsight Hadoop migration (Procedure consigliate relative alla sicurezza e a DevOps per la migrazione da un sistema locale ad Azure HDInsight Hadoop)