Migrazione dei dati HDFS da on-premise a Google Cloud

Last reviewed 2024-04-17 UTC

Questa guida descrive il processo di spostamento dei dati da Hadoop on-premise Distributed File System (HDFS) su Google Cloud (Google Cloud).

Questa è la seconda di quattro guide che descrivono come passare da Hadoop on-premise:

Pianificare lo spostamento dei dati

Le sezioni seguenti descrivono le best practice per pianificare la migrazione dei dati da HDFS on-premise a Google Cloud. Pianifica per eseguire la migrazione incrementale in modo da lasciare il tempo necessario per eseguire la migrazione di job, dopo lo spostamento di ogni insieme di dati.

Decidere come spostare i dati

Esistono due diversi modelli di migrazione che dovresti prendere in considerazione per il trasferimento Dati HDFS nel cloud: push e pull. Entrambi i modelli utilizzano Hadoop DistCp per copiare i dati dai cluster HDFS on-premise in Cloud Storage, ma adottano approcci diversi.

Il modello push è quello più semplice: il cluster di origine esegue i job distcp sui propri nodi di dati ed esegue il push dei file direttamente in Cloud Storage, come mostrato nel seguente diagramma:

Migrazione dei dati HDFS utilizzando il modello push

Il modello pull è più complesso, ma presenta alcuni vantaggi. Un cluster Dataproc temporaneo esegue i job distcp sui suoi nodi di dati, estrae i file dal cluster di origine e li copia in Cloud Storage, come mostrato nel seguente diagramma:

Migrazione dei dati HDFS utilizzando il modello pull

Il modello push è il più semplice perché il cluster di origine può inviare i dati direttamente a Cloud Storage e non è necessario creare risorse di calcolo aggiuntive per eseguire la copia. Tuttavia, se intendi continuare a utilizzare cluster di origine durante la migrazione per altri normali job di elaborazione dei dati, devono garantire che risorse sufficienti, come CPU, RAM e larghezza di banda di rete, disponibili sul cluster di origine per eseguire anche i job di copia.

Se il cluster di origine è già in esecuzione con la capacità di calcolo massima e non puoi aumentare le risorse sul cluster di origine per eseguire la copia, ti consigliamo di utilizzare il modello pull.

Sebbene più complesso del modello push, il modello pull presenta una serie di vantaggi:

  • L'impatto sulle risorse CPU e RAM del cluster di origine è ridotto al minimo, perché i nodi di origine vengono utilizzati solo per pubblicare blocchi al di fuori del cluster. Puoi anche perfezionare le specifiche delle risorse del cluster pull su Google Cloud per gestire i job di copia e smontare il cluster pull al termine della migrazione.
  • Il traffico sulla rete del cluster di origine viene ridotto, il che consente una maggiore larghezza di banda in uscita e trasferimenti più rapidi.
  • Non è necessario installare il connettore Cloud Storage sul cluster di origine perché il cluster Dataproc temporaneo, che ha già installato il connettore, gestisce il trasferimento dei dati su Cloud Storage.

Per comprendere le implicazioni sull'utilizzo della rete per entrambi i modelli, considera come Hadoop gestisce la replica dei dati in HDFS. Hadoop suddivide ogni file in più blocchi: la dimensione del blocco è in genere compresa tra 128 e 256 megabyte. Hadoop li replica su più nodi di dati e su più rack per evitare di perdere dati in caso di guasto di un nodo di dati o di un rack. Lo standard è archiviare 3 repliche di ogni blocco.

Hadoop utilizza anche la "consapevolezza del rack", che garantisce che 2 copie di ogni blocco si trovino in nodi di dati diversi all'interno dello stesso rack per una latenza inferiore e una terza copia in un rack diverso per una maggiore ridondanza e disponibilità. Questa logica di replica è riassunta nel seguente diagramma:

Replica dei blocchi HDFS con conoscenza del rack

Quando copi un file utilizzando il modello push, ovvero quando l'distcp attività di mappatura viene eseguita su un nodo dati del cluster di origine, tutti i blocchi del file vengono prima raccolti dai vari nodi dati. I blocchi del file vengono quindi spinti fuori nel cluster di origine e in Cloud Storage. Traffico sulla rete possono occupare fino a quasi il doppio delle dimensioni totali del file, come illustrato diagramma seguente:

Utilizzo della rete con il modello push

Quando copi un file utilizzando il modello pull (ovvero quando il compito di mappatura distcp viene eseguito su un nodo di dati del cluster pull in Google Cloud), ogni blocco viene trasmesso sulla rete una sola volta uscendo direttamente dal cluster di origine. Il traffico di rete complessivo è limitato alle dimensioni totali del file, come illustrato nel seguente diagramma:

Utilizzo della rete quando si utilizza il modello pull

Quando utilizzi il modello pull, devi monitorare il numero di distcp mappa e la larghezza di banda utilizzate per evitare di sovraccaricare il cluster di origine con e connessioni parallele.

Decidere dove spostare i dati

Il risultato finale della migrazione di Hadoop può essere una soluzione cloud-native o soluzione ibrida. La differenza tra queste due opzioni è se il sistema manterrà o meno i componenti on-premise. In una soluzione cloud-native, i dati vengono archiviati nel cloud ed eseguiti su di essi i job. In una soluzione ibrida, alcune i dati rimangono on-premise. Potresti eseguire job sui dati on-premise oppure eseguire job nel cloud che funzionano con dati on-premise.

Una soluzione cloud-native è la più semplice da gestire, ma potresti avere requisiti tecnici o aziendali che richiedono di mantenere alcuni dati o l'elaborazione on-premise. Ogni evento soluzione ibrida è fortemente dipendente dai casi, incluso il proprio mix di tecnologie e servizi per soddisfare le esigenze del tuo carico di lavoro.

Spostamento di dati in prodotti diversi da Cloud Storage

Spostare la maggior parte dei tuoi dati in Cloud Storage. Tuttavia, puoi prendere in considerazione lo spostamento dei dati in un Prodotto Google Cloud:

  • Se stai eseguendo la migrazione dei dati da Apache HBase, ti consigliamo di spostarli in Bigtable, che offre funzionalità equivalenti.

  • Se stai eseguendo la migrazione dei dati da Apache Impala, ti consigliamo di spostarli in BigQuery, che offre funzionalità equivalenti.

Potresti avere dati in HBase o Impala che puoi utilizzare senza archiviarli in Bigtable o BigQuery. Se il tuo job non richiede le funzionalità di Bigtable o BigQuery, archivia i dati in Cloud Storage.

Pianificazione delle posizioni dei dati tenendo presenti le autorizzazioni

Google Cloud non utilizza le stesse autorizzazioni granulari per i file che puoi ottenere con HDFS on-premise. L'approccio meno complicato per le autorizzazioni dei file è impostarle a livello di ciascun bucket Cloud Storage. Se hai impostato autorizzazioni diverse per set diversi di dati HDFS, valuta la possibilità di creare bucket diversi in Cloud Storage con ciascuna autorizzazioni diverse. Quindi inserisci i dati HDFS nel bucket che contiene le autorizzazioni appropriate per quei dati.

Se sposti i file in una struttura diversa in Cloud Storage rispetto a HDFS, ricordati di tenere traccia di tutte le modifiche. Quando sposti i job in Dataproc, devi fornire i percorsi corretti per i dati nelle nuove posizioni.

Pianificare un trasferimento incrementale

Pianifica di spostare i dati in blocchi distinti nel tempo. Pianifica un periodo di tempo sufficiente per spostare i job corrispondenti nel cloud tra uno spostamento dei dati e l'altro. Avvia la migrazione spostando i dati di bassa priorità, come i backup e gli archivi.

Suddivisione dei dati

Se prevedi di spostare i dati in modo incrementale, devi suddividerli in più parti. Le seguenti sezioni descrivono le strategie più comuni per la suddivisione dei set di dati.

Suddivisione dei dati per timestamp

Un approccio comune per suddividere i dati per un trasferimento incrementale è archiviare i dati più vecchi nel cloud, mantenendo al contempo i nuovi dati in HDFS nel sistema on-premise. In questo modo puoi testare i job nuovi e migrati su job meno recenti e meno critici e i dati di Google Cloud. Suddividere i dati in questo modo consente di iniziare lo spostamento con quantità di dati.

Considerazioni importanti:

  • Puoi suddividere i dati utilizzando un altro metodo oltre alla suddivisione per tempo? Puoi ottenere un insieme di dati più mirato suddividendoli in base ai job supportati o all'organizzazione che li possiede e suddividendoli ulteriormente in base al tempo.
  • Occorre utilizzare una data e un'ora assolute o una data/ora relativa? A volte ha senso suddividere i dati in un determinato momento, ad esempio archiviando tutti generati prima di un cambiamento importante nel sistema. L'utilizzo di una data/ora assoluta è spesso appropriato se vuoi creare job di backfill per testare il tuo sistema nel cloud e verificare se puoi elaborare i dati precedenti per allinearli ai tuoi standard attuali. In altri casi, potresti voler spostare i dati nel cloud in base a un timestamp relativo alla data corrente. Ad esempio: potresti spostare tutti i dati creati più di un anno fa oppure tutti i dati che non è stato modificato negli ultimi tre mesi.
  • Quale valore di data/ora stai utilizzando per prendere la decisione? I file spesso hanno più valori di data/ora. A volte la data di creazione del file è la importanti. In altri casi potrebbe essere utile usare l'ora dell'ultima modifica oppure un altro timestamp dai metadati del file.
  • Tutti i dati hanno lo stesso formato del timestamp? Esistono molti modi per gestire i timestamp. Se i dati provengono da più di un'origine, è possibile che i timestamp siano archiviati in formati diversi. Assicurati che disponi di timestamp coerenti prima di utilizzarli per suddividere i dati.

Suddivisione dei dati per job

A volte puoi suddividere i dati esaminando i job che li utilizzano. Questo può particolarmente utile se esegui la migrazione in modo incrementale dei job. Puoi spostare solo i dati utilizzati dai job che sposti.

Considerazioni importanti:

  • I job che stai spostando nel cloud sono autonomi? La suddivisione per job è un'ottima opzione per i job che operano in modo indipendente unità di dati, ma può diventare difficile da gestire se i job lavorano di dati distribuiti nel tuo sistema.
  • È probabile che i dati avranno gli stessi utilizzi in futuro? Rifletti attentamente prima di isolare i dati, se usarli in modi diversi.
  • L'ambito della migrazione del job è appropriato per generare blocchi di dati gestibili?

Puoi anche utilizzare criteri funzionali più ampi per suddividere i dati invece che solo insiemi di job. Ad esempio, potresti eseguire tutti i tuoi ETL: lavora nel cloud ed eseguire job di analisi e reporting on-premise.

Suddivisione dei dati in base alla proprietà

In alcuni casi, puoi suddividere i dati per aree di proprietà. Uno dei vantaggi di questo approccio è che l'organizzazione dei dati è in linea con l'organizzazione della tua attività. Un altro vantaggio è che consente di sfruttare Google Cloud gestione degli accessi basata sui ruoli. Ad esempio: migrazione dei dati utilizzati da un determinato ruolo aziendale in un ambiente Il bucket Cloud Storage semplifica la configurazione delle autorizzazioni.

Considerazioni importanti:

  • I confini tra proprietari sono chiari? In genere è chiaro chi sia il proprietario principale di un determinato elemento di dati, a volte le persone che accedono più di frequente ai dati non sono i proprietari.
  • Esistono altri criteri di suddivisione che puoi combinare con la proprietà? Potresti finiscono con set di dati molto grandi dopo la suddivisione per proprietà. È possibile è utile per restringere ulteriormente le cose suddividendo nuovamente i dati per attività o in base all'orario.

Mantenere sincronizzati i dati in una soluzione ibrida

Una delle sfide dell'utilizzo di una soluzione ibrida è che a volte un job ha bisogno per accedere ai dati sia da Google Cloud che da sistemi on-premise. Se è necessario accedere a un set di dati in entrambi gli ambienti, devi stabilire una posizione di archiviazione principale in un ambiente e mantenere una copia sincronizzata nell'altro.

Le sfide della sincronizzazione dei dati sono simili, indipendentemente dalla sede principale scelta. Devi avere un modo per identificare quando i dati sono stati modificati e un meccanismo per propagare le modifiche alle copie corrispondenti. Se esiste un potenziali cambiamenti contrastanti, dovrai anche sviluppare una strategia risolverle.

Considerazioni importanti:

  • Se possibile, crea sempre copie dei dati di sola lettura. La tua sincronizzazione diviene più complessa con ogni potenziale fonte di nuove modifiche.
  • In una soluzione ibrida, evita di conservare più di due copie dei dati. Mantieni solo una copia on-premise e solo una in Google Cloud.

Puoi utilizzare tecnologie come Apache Airflow per gestire la sincronizzazione dei dati.

Spostamento dei dati

Le seguenti sezioni descrivono le considerazioni per lo spostamento dei dati in in Google Cloud.

Configurazione dell'accesso ai dati

Le autorizzazioni dei file funzionano in modo diverso in Cloud Storage rispetto a come funzionano HDFS. Prima di spostare i dati in Cloud Storage, devi diventare avere familiarità con Identity and Access Management (IAM).

Il modo più semplice per gestire il controllo dell'accesso è ordinare i dati nei bucket Cloud Storage in base ai requisiti di accesso e configurare il criterio di autorizzazione a livello di bucket. Puoi assegnare ruoli che concedono l'accesso a singoli utenti o a gruppi. Concedi l'accesso per gruppi e poi assegna gli utenti ai gruppi in base alle esigenze. Devi prendere decisioni sull'accesso ai dati durante l'importazione e la strutturazione dei dati in Cloud Storage.

Ogni prodotto Google Cloud ha le proprie autorizzazioni e i propri ruoli. Assicurati di comprendere le relazioni tra i controlli di accesso di Cloud Storage e quelli di Dataproc. Valuta i criteri per ciascun prodotto separatamente. Non dare per scontato che i ruoli e le autorizzazioni vengano mappati direttamente tra i prodotti.

Acquisisci familiarità con la seguente documentazione per prepararti a prendere decisioni relative alle policy per il tuo sistema Hadoop basato su cloud:

Se devi assegnare autorizzazioni più granulari a singoli file, Cloud Storage supporta elenchi di controllo dell'accesso (ACL). Tuttavia, IAM è l'opzione fortemente preferita. Utilizza le ACL solo se le autorizzazioni sono particolarmente complesse.

Utilizzare DistCp per copiare i dati in Cloud Storage

Poiché Cloud Storage è un file system compatibile con Hadoop, puoi utilizzare DistCp di Hadoop per spostare i dati da HDFS on-premise a Cloud Storage. Puoi per spostare dati in vari modi usando DistCp. Ti consigliamo di procedere in questo modo:

  1. Stabilisci un collegamento privato tra la tua rete on-premise e quella di Google sulla rete tramite Cloud Interconnect o Cloud VPN.

  2. Crea un cluster Dataproc da utilizzare per il trasferimento dei dati.

  3. Utilizza Google Cloud CLI per connetterti al master del cluster in esecuzione in un'istanza Compute Engine. Ad esempio:

    gcloud compute ssh [CLUSTER_NAME]-m

    dove CLUSTER_NAME è il nome del cluster Dataproc che hai creato per il job. Il suffisso -m identifica l'istanza master.

  4. Nell'istanza principale del cluster, esegui i comandi DistCp per spostare i dati.

I comandi DistCp effettivi necessari per spostare i dati sono simili ai seguenti:

hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/

In questo esempio nn1 e 8020 sono i namenode e la porta in cui l'origine dati sono e bucket è il nome del bucket Cloud Storage che stai copiando il file.

Il traffico di Cloud Storage è criptato per impostazione predefinita con Transport Layer Security (TLS).

Convalida dei trasferimenti di dati

Quando copi o sposti dati tra sistemi di archiviazione distinti, come in più cluster HDFS o tra HDFS e Cloud Storage, è una buona idea eseguire un qualche tipo di convalida per garantire l'integrità dei dati. Questo tipo di convalida è essenziale per assicurarsi che i dati non siano stati alterati durante il trasferimento. Per maggiori dettagli, consulta la guida sulla convalida dei trasferimenti di dati.

Aumentare la tasso di richieste

Cloud Storage gestisce un indice di chiavi oggetto per ogni bucket in ordine per fornire un elenco coerente degli oggetti. Questo indice è archiviati in ordine lessicografico e vengono aggiornati ogni volta che gli oggetti vengono scritti o eliminati da un bucket. L'aggiunta ed eliminazione di oggetti le cui chiavi esistono tutte in un piccolo intervallo dell'indice aumentano naturalmente le probabilità di contesa.

Cloud Storage rileva tale contesa e ridistribuisce automaticamente sull'intervallo dell'indice interessato su più server. Se stai scrivendo oggetti con un nuovo prefisso e prevedi di raggiungere una frequenza superiore a 1000 richieste di scrittura al secondo, devi aumentare gradualmente la frequenza delle richieste, come descritto nella documentazione di Cloud Storage. Se non lo fai, la latenza e i tassi di errore potrebbero essere temporaneamente più alti.

Miglioramento della velocità di migrazione dei dati

Il modo più semplice per trasferire i dati dai cluster on-premise a Google Cloud è utilizzare un tunnel VPN tramite internet pubblico. Se un singolo tunnel VPN non fornisce la necessaria velocità effettiva, più tunnel VPN e Google Cloud distribuirà automaticamente il traffico attraverso i tunnel per fornire larghezza di banda aggiuntiva.

A volte anche più tunnel VPN non forniscono larghezza di banda sufficiente o la stabilità della connessione per soddisfare le esigenze della tua migrazione. Considera le i seguenti approcci per migliorare la velocità effettiva:

  • Utilizza il peering diretto tra la tua rete e i punti di presenza (PoP) perimetrali di Google. Questa opzione consente di ridurre il numero di hop tra la tua rete e Google Cloud.

  • Utilizza un Provider di servizi Cloud Interconnect per stabilire una connessione diretta alla rete Google. I dettagli del servizio varieranno in base al partner. La maggior parte offre un SLA per la disponibilità e le prestazioni della rete. Per ulteriori informazioni, contatta direttamente un fornitore di servizi.

Collaborazione con i partner Google Cloud

Google Cloud collabora con una serie di partner che possono aiutarti in eseguire la migrazione dei dati. Consulta i partner che collaborano con Cloud Storage per saperne di più sui servizi disponibili per aiutarti con la migrazione dei dati. I servizi e i termini disponibili variano in base al fornitore, quindi contattalo direttamente per avere maggiori dettagli.

Passaggi successivi