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 delle quattro guide che descrivono come passare da un ambiente on-premise Hadoop:

Pianificazione dello spostamento dei dati

Le seguenti sezioni 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.

Decisione di 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 DistCp di Hadoop copiare i dati dai cluster HDFS on-premise a Cloud Storage, usano 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. Dataproc temporaneo il cluster esegue i job distcp sui propri nodi di dati, estrae i file dal cluster di origine e e le copia in Cloud Storage, come illustrato nel diagramma seguente:

Migrazione dei dati HDFS tramite il modello pull

Il modello push è quello più semplice perché il cluster di origine può eseguire il push dei dati direttamente in Cloud Storage e non devi creare risorse di calcolo aggiuntive risorse 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 alla capacità di calcolo e se non puoi aumentare le risorse sul cluster di origine per eseguire la copia, dovresti prendere in considerazione l'utilizzo del modello pull.

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

  • L'impatto sulle risorse di CPU e RAM del cluster di origine è ridotto al minimo, i nodi di origine vengono utilizzati solo per gestire i blocchi all'esterno del cluster. Tu puoi anche ottimizzare le specifiche delle risorse del cluster di pull a Google Cloud per gestire i job di copia e rimuovere il cluster di pull al termine della migrazione.
  • Il traffico sulla rete del cluster di origine è ridotto, il che consente un aumento larghezze di banda in uscita e trasferimenti più rapidi.
  • Non è necessario installare Connettore Cloud Storage sul cluster di origine come cluster Dataproc temporaneo, in cui è già installato il connettore gestisce il trasferimento dei dati di archiviazione ideale in 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 replica blocchi su più nodi di dati e su più rack per evitare di perdere dati in caso di guasto del nodo dati o del rack. Lo standard è archiviare 3 repliche di ogni blocco.

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

Replica a blocchi HDFS con rilevamento del rack

Quando copi un file utilizzando il modello push, ovvero quando l'attività di mappatura distcp su un nodo dati del cluster di origine, tutti i blocchi del file vengono raccolti dai vari nodi di dati. I blocchi del file vengono quindi spinti fuori dal cluster di origine e passare a 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 di pull, ovvero quando l'attività di mappatura distcp viene eseguito su un nodo dati del cluster pull in Google Cloud), ogni blocco viaggia sulla rete solo una volta uscendo direttamente dal cluster di origine. La il traffico di rete complessivo è limitato alle dimensioni totali del file, come illustrato in il seguente diagramma:

Utilizzo della rete con 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 è se il sistema conserva o meno dei componenti on-premise. In una soluzione cloud-native, ospiti i dati nel cloud ed eseguire job lì. In una soluzione ibrida, alcune i dati rimangono on-premise. Potresti eseguire job su questi dati on-premise oppure eseguire job nel cloud che funzionano con dati on-premise.

Una soluzione cloud-native è la più facile da mantenere, ma potresti avere o requisiti tecnici che mantengono alcuni dati o 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, valuta la possibilità di spostarli in Bigtable, che fornisce equivalenti le funzionalità di machine learning.

  • Se esegui la migrazione dei dati da Apache Impala, valuta la possibilità di spostarli in BigQuery, che fornisce equivalenti le funzionalità di machine learning.

Potresti avere dati in HBase o Impala che puoi utilizzare senza archiviarli Bigtable o BigQuery. Se il tuo lavoro non richiedono le funzionalità di Bigtable 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 le autorizzazioni dei file è impostarle a livello di ciascun Cloud Storage di sincronizzare la directory di una VM con un bucket. Se hai impostato autorizzazioni diverse per insiemi di dati HDFS diversi, valuta la possibilità di creare in Cloud Storage bucket diversi, autorizzazioni diverse. Quindi inserisci i dati HDFS nel bucket che contiene le autorizzazioni appropriate per quei dati.

Se in Cloud Storage sposti i file in una struttura diversa da quella utilizzata, è in HDFS, ricordati di tenere traccia di tutte le modifiche. Quando sposti in Dataproc dovrai fornire i percorsi giusti nelle sue nuove posizioni.

Pianificazione di un trasferimento incrementale

Pianifica lo spostamento dei dati in blocchi discreti nel tempo. Pianifica molto tempo per spostare i job corrispondenti nel cloud tra un trasferimento dei dati e l'altro. Avvia migrazione spostando dati a bassa priorità, come backup e 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 alla suddivisione dei dati per uno spostamento incrementale consiste nell'archiviare i dati nel cloud, conservando i nuovi dati in HDFS di un sistema operativo completo. 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:

  • Oltre a suddividere i dati, puoi utilizzare un altro metodo volta? Puoi ottenere un set di dati più mirato suddividendo i dati in base ai job che sostiene o all'organizzazione che ne è proprietaria, per poi suddividerlo ulteriormente in base all'ora.
  • 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'uso di un valore assoluto la data e l'ora sono spesso indicate se vuoi creare job di backfill testare il sistema nel cloud per vedere se è possibile elaborare i vecchi dati per secondo gli 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 hanno spesso 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 di timestamp? Esistono molti modi per gestire i timestamp. Se i dati provengono da più di un'origine, è possibile che i timestamp siano archiviati in diversi formati. 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 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 abbiano gli stessi utilizzi in futuro? Rifletti attentamente prima di isolare i dati, se usarli in modi diversi.
  • L'ambito della migrazione del job è adeguato in modo da generare blocchi gestibili di dati?

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à. Un vantaggio adottare questo approccio è che la tua organizzazione dei dati sia allineata 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? Di solito è chiaro quale sia il principale proprietario di un determinato elemento di dati è, a volte, le persone che accedono più spesso i dati non sono 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.

Mantieni i dati sincronizzati 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 al set di dati deve essere accessibile in entrambi gli ambienti, devi definire un posizione di archiviazione in un ambiente e di mantenere una copia sincronizzata l'altra.

Le sfide della sincronizzazione dei dati sono simili, indipendentemente dall'impostazione località che scegli. Ti serve un modo per capire quando i dati sono cambiati e meccanismo di propagazione delle modifiche alle copie corrispondenti. Se esiste un potenziali cambiamenti contrastanti, dovrai anche sviluppare una strategia risolverle.

Considerazioni importanti:

  • Se possibile, fai 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. Conserva solo una copia on-premise e una sola in Google Cloud.

Puoi usare tecnologie come Apache Airflow per gestire i tuoi dati la sincronizzazione dei dati.

Spostamento dei dati

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

Configurare l'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 ai bucket Cloud Storage in base ai requisiti di accesso e di autorizzazione a livello di bucket. Puoi assegnare ruoli che concedono l'accesso a singoli utenti o gruppi. Concedere l'accesso per gruppi; e assegnare gli utenti ai gruppi in base alle esigenze. Devi prendere decisioni sull'accesso ai dati quando importi e struttura i dati in Cloud Storage.

Ogni prodotto Google Cloud ha autorizzazioni e ruoli propri. Assicurati che comprendi le relazioni tra i controlli di accesso di Cloud Storage e quelli per Dataproc. Valuta le norme per ogni prodotto separatamente. Non dare per scontato che i ruoli e le autorizzazioni siano mappati direttamente tra prodotti di big data e machine learning.

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 gli ACL solo se autorizzazioni sono particolarmente complesse.

Utilizzo di 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 creato per il job. Il suffisso -m identifica l'istanza master.

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

I comandi DistCp effettivi necessari per spostare i dati sono simili 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 i 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 Sicurezza (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 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 ulteriori dettagli, Consulta la guida Convalidare i 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. Aggiunta ed eliminazione di oggetti le cui chiavi si trovano tutte in un intervallo ridotto dell'indice aumenta naturalmente le possibilità 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 prevediamo che otterrete un tasso maggiore di 1000 richieste di scrittura al secondo, dovresti aumentare la tasso di richieste gradualmente, come descritto 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 Google Cloud prevede di utilizzare un tunnel VPN su nella rete internet pubblica. 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 la rete POP (POP) perimetrali. Questa opzione riduce 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. Dettagli del servizio variano in base al partner. La maggior parte offre uno SLA per la disponibilità di rete delle prestazioni. Per ulteriori informazioni, contatta direttamente un fornitore di servizi.

Collaborare con i partner Google Cloud

Google Cloud collabora con una serie di partner che possono aiutarti in eseguire la migrazione dei dati. Consulta le partner che lavorano con Cloud Storage per ulteriori informazioni sui servizi disponibili che ti aiutano con i tuoi dati migrazione. I servizi e i termini disponibili variano a seconda del fornitore, quindi collabora con il fornitore direttamente per ottenere i dettagli.

Passaggi successivi