Migrazione dei dati HDFS da on-premise a Google Cloud

Last reviewed 2024-04-17 UTC

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

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

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 una migrazione incrementale in modo da lasciare il tempo necessario per eseguire la migrazione dei job, degli esperimenti e dei test dopo aver spostato ogni corpo di dati.

Decisione di spostare i dati

Esistono due diversi modelli di migrazione da considerare per il trasferimento dei dati HDFS nel cloud: push e pull. Entrambi i modelli utilizzano Hadoop DistCp per copiare i dati dai cluster HDFS on-premise a Cloud Storage, ma utilizzano approcci diversi.

Il modello push è il modello 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 propri nodi di dati, estrae i file dal cluster di origine e li copia in Cloud Storage, come illustrato nel seguente diagramma:

Migrazione dei dati HDFS tramite il modello pull

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

Se il cluster di origine è già in esecuzione al limite della 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 presenta una serie di vantaggi:

  • L'impatto sulle risorse di CPU e RAM del cluster di origine è ridotto al minimo, perché i nodi di origine vengono utilizzati solo per gestire i blocchi al di fuori del cluster. Puoi anche ottimizzare le specifiche delle risorse del cluster di pull su 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 larghezze di banda in uscita maggiori e trasferimenti più veloci.
  • Non è necessario installare il connettore Cloud Storage sul cluster di origine poiché il cluster Dataproc temporaneo, in cui è già installato il connettore, gestisce il trasferimento dei dati a Cloud Storage.

Per comprendere le implicazioni per l'utilizzo della rete per entrambi i modelli, considera il modo in cui Hadoop gestisce la replica dei dati in HDFS. Hadoop suddivide ogni file in più blocchi: la dimensione dei blocchi è di solito compresa tra 128 e 256 MB. Hadoop replica questi blocchi su più nodi di dati e su più rack per evitare di perdere dati in caso di errore dei nodi dati o del rack. La configurazione standard prevede l'archiviazione di 3 repliche di ogni blocco.

Hadoop utilizza inoltre la "consapevolezza del rack", che garantisce che 2 copie di ogni blocco siano in nodi di dati diversi all'interno dello stesso rack per una minore latenza e una terza copia in un rack diverso per maggiore ridondanza e disponibilità. Questa 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 viene eseguita su un nodo dati del cluster di origine, tutti i blocchi del file vengono prima raccolti dai vari nodi di dati. Il push dei blocchi del file viene eseguito dal cluster di origine a Cloud Storage. Il traffico sulla rete potrebbe richiedere fino a quasi il doppio delle dimensioni totali del file, come illustrato nel seguente diagramma:

Utilizzo della rete con il modello push

Quando copi un file utilizzando il modello pull (ovvero quando l'attività di mappa distcp viene eseguita su un nodo dati del cluster di pull in Google Cloud), ogni blocco viaggia 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 con il modello pull

Quando utilizzi il modello pull, devi monitorare il numero di attività di mappatura distcp e la larghezza di banda utilizzata per evitare di sovraccaricare il cluster di origine con troppe connessioni parallele.

Decidere dove spostare i dati

Il risultato finale della migrazione di Hadoop può essere una soluzione cloud-native o ibrida. La differenza sta nel fatto che il sistema conserverà i componenti on-premise. Con una soluzione cloud-native, i dati vengono ospitati nel cloud ed eseguirvi job. In una soluzione ibrida, alcuni dei tuoi dati rimangono on-premise. Potresti anche eseguire job su quei dati on-premise o nel cloud job che funzionano con dati on-premise.

Una soluzione cloud-native è la più facile da mantenere, ma potresti avere requisiti aziendali o tecnici che mantengono alcuni dati o elaborazioni on-premise. Ogni soluzione ibrida dipende fortemente 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, in alcuni casi potresti prendere in considerazione lo spostamento dei dati in un altro prodotto Google Cloud:

  • Se esegui la migrazione dei dati da Apache HBase, valuta la possibilità di spostarli in Bigtable, che fornisce funzionalità equivalenti.

  • Se esegui la migrazione dei dati da Apache Impala, valuta la possibilità di spostarli in BigQuery, che fornisce 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 per i file le stesse autorizzazioni granulari che puoi ottenere con HDFS on-premise. L'approccio meno complicato alle autorizzazioni dei file è impostarle al livello di ciascun bucket Cloud Storage. Se hai impostato autorizzazioni diverse per insiemi di dati HDFS diversi, valuta la possibilità di creare bucket diversi in Cloud Storage con autorizzazioni diverse. Quindi, inserisci i dati HDFS nel bucket che dispone delle autorizzazioni appropriate per questi dati.

Se sposti i file in una struttura diversa in Cloud Storage da quella in HDFS, ricordati di tenere traccia di tutte le modifiche. Quando sposterai i tuoi job in Dataproc, dovrai fornire i percorsi giusti per i tuoi dati nelle 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 i trasferimenti di dati. Avvia la migrazione spostando i dati a bassa priorità, ad esempio 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 meno recenti nel cloud, conservando al contempo i nuovi dati in HDFS nel sistema on-premise. In questo modo puoi testare i job nuovi e migrati su dati meno recenti e meno critici. La suddivisione dei dati in questo modo consente di iniziare il trasferimento con quantità ridotte di dati.

Considerazioni importanti:

  • Oltre alla suddivisione in base al tempo, è possibile suddividere i dati utilizzando un altro metodo? Puoi ottenere un set di dati più mirato suddividendo i dati in base ai job supportati o all'organizzazione che ne è proprietario e quindi 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 archiviare tutti i dati generati prima di una modifica importante nel sistema. L'utilizzo di una data/ora assoluta è spesso la scelta appropriata se vuoi creare job di backfill per testare il tuo sistema nel cloud e verificare se puoi elaborare i vecchi dati per portarli agli standard attuali. In altri casi, potresti voler spostare i dati nel cloud in base a un timestamp relativo alla data corrente. Ad esempio, puoi spostare tutti i dati creati più di un anno fa o tutti i dati che non sono stati modificati negli ultimi tre mesi.
  • Quale valore di data/ora stai utilizzando per prendere la decisione? I file spesso hanno più valori di data e ora. A volte la data di creazione del file è la più importante. In altri casi potrebbe essere utile usare l'ora dell'ultima modifica o un altro timestamp dei 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ù origini, è possibile che i timestamp siano archiviati in formati diversi. Assicurati di avere 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. Ciò può essere particolarmente utile se esegui la migrazione dei job in modo incrementale. Puoi spostare solo i dati utilizzati dai job spostati.

Considerazioni importanti:

  • I job che stai spostando nel cloud sono autonomi? La suddivisione per job è un'ottima opzione per i job che lavorano su unità di dati autonome, ma che possono diventare difficili da gestire se i job funzionano con dati distribuiti nel sistema.
  • È probabile che i dati abbiano gli stessi utilizzi in futuro? Rifletti attentamente prima di isolare i dati, se potresti utilizzarli in modi diversi.
  • L'ambito della migrazione dei 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 tutto il tuo lavoro ETL nel cloud e poi 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 di questo approccio è che la tua organizzazione dei dati è in linea con l'organizzazione della tua azienda. Un altro vantaggio è che consente di sfruttare la gestione degli accessi basata sui ruoli di Google Cloud. Ad esempio, la migrazione dei dati utilizzati da un determinato ruolo aziendale in un bucket Cloud Storage isolato semplifica la configurazione delle autorizzazioni.

Considerazioni importanti:

  • I confini tra proprietari sono chiari? Di solito è chiaro chi sia il proprietario principale di un determinato elemento di dati; a volte le persone che più spesso accedono ai dati non sono i proprietari.
  • Esistono altri criteri di suddivisione che puoi combinare con la proprietà? Dopo la suddivisione per proprietà, potresti avere set di dati molto grandi. Può essere utile restringere ulteriormente i dati suddividendo i dati nuovamente per attività o per data.

Mantieni i dati sincronizzati in una soluzione ibrida

Una delle sfide dell'utilizzo di una soluzione ibrida è che a volte un job deve accedere ai dati sia da Google Cloud che dai 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 località principale scelta. Devi trovare un modo per identificare quando i dati sono stati modificati e un meccanismo per propagare le modifiche alle copie corrispondenti. Se esiste il potenziale di cambiamenti in conflitto, devi anche sviluppare una strategia per risolverli.

Considerazioni importanti:

  • Se possibile, fai sempre copie dei dati di sola lettura. La tua strategia di sincronizzazione diventa più complessa con ogni potenziale fonte di nuove modifiche.
  • In una soluzione ibrida, evita di conservare più di due copie dei dati. Conserva una sola copia on-premise e una sola 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 Google Cloud.

Configurare l'accesso ai dati

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

Il modo più semplice per gestire controllo dell'accesso#39;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 gruppi. Concedi l'accesso per gruppi, quindi assegnando 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 di comprendere le relazioni tra i controlli di accesso di Cloud Storage e quelli per Dataproc. Valuta le norme separatamente per ogni prodotto. Non dare per scontato che i ruoli e le autorizzazioni siano mappati direttamente tra i prodotti.

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

Se devi assegnare autorizzazioni più granulari a singoli file, Cloud Storage supporta gli elenchi di controllo dell'accesso (ACL). Tuttavia, IAM è l'opzione fortemente preferita. Usa gli ACL solo se le 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. È possibile spostare i dati in diversi modi utilizzando DistCp. Ti consigliamo di procedere in questo modo:

  1. Stabilisci un collegamento privato tra la tua rete on-premise e la rete Google utilizzando Cloud Interconnect o Cloud VPN.

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

  3. Utilizza Google Cloud CLI per connetterti all'istanza master del cluster. 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 master 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 il namenode e la porta in cui sono archiviati i dati di origine, mentre bucket è il nome del bucket Cloud Storage in cui 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 i dati tra sistemi di archiviazione distinti, come più cluster HDFS oppure tra HDFS e Cloud Storage, ti consigliamo di eseguire un qualche tipo di convalida per garantire l'integrità dei dati. Questa convalida è essenziale per assicurarsi che i dati non siano stati alterati durante il trasferimento. Per ulteriori dettagli, consulta la guida Convalida dei trasferimenti di dati.

Aumentare la tasso di richieste

Cloud Storage gestisce un indice delle chiavi dell'oggetto per ogni bucket al fine di fornire un elenco coerente degli oggetti. Questo indice è archiviato in ordine lessicografico e viene aggiornato ogni volta che gli oggetti vengono scritti o eliminati da un bucket. L'aggiunta e l'eliminazione di oggetti le cui chiavi si trovano tutte in un piccolo intervallo dell'indice aumenta naturalmente le possibilità di contesa.

Cloud Storage rileva tale contesa e ridistribuisce automaticamente il carico sull'intervallo di indice interessato su più server. Se scrivi oggetti utilizzando un nuovo prefisso e prevedi che arriverai a una velocità superiore alle 1000 richieste di scrittura al secondo, dovresti aumentare gradualmente la tasso di 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 sulla rete internet pubblica. Se un singolo tunnel VPN non fornisce la velocità effettiva necessaria, è possibile che vengano creati più tunnel VPN e Google Cloud distribuirà automaticamente il traffico tra i tunnel per fornire larghezza di banda aggiuntiva.

A volte anche più tunnel VPN non forniscono larghezza di banda o stabilità della connessione sufficienti per soddisfare le esigenze della migrazione. Considera 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 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. I dettagli del servizio variano a seconda del partner. La maggior parte offre uno SLA per disponibilità e prestazioni della rete. Per ulteriori informazioni, contatta direttamente un fornitore di servizi.

Collaborare con i partner Google Cloud

Google Cloud collabora con diversi partner che possono aiutarti a eseguire la migrazione dei dati. Scopri i partner che collaborano con Cloud Storage per ulteriori informazioni sui servizi disponibili per aiutarti nella migrazione dei dati. I servizi e i termini disponibili variano a seconda del fornitore, quindi collabora direttamente con il fornitore per avere informazioni dettagliate.

Passaggi successivi