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 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 la migrazione in modo incrementale, in modo da avere il tempo di eseguire la migrazione di job, esperimenti e test dopo lo spostamento di ogni insieme di dati.

Decisione su come spostare i dati

Per trasferire i dati HDFS nel cloud devi prendere in considerazione due diversi modelli di migrazione: 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 suoi 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 dati, estrae i file dal cluster di origine e li copia in Cloud Storage, come illustrato nel seguente diagramma:

Migrazione dei dati HDFS utilizzando il modello pull

Il modello push è il modello più semplice perché il cluster di origine può eseguire il push dei dati direttamente a Cloud Storage e non hai bisogno di 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 sul cluster di origine siano disponibili risorse sufficienti, ad esempio CPU, RAM e larghezza di banda di rete per eseguire anche i job di copia.

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

Sebbene sia 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, poiché i nodi di origine vengono utilizzati solo per gestire blocchi al di fuori del cluster. Puoi anche perfezionare le specifiche delle risorse del cluster di pull su Google Cloud per gestire i job di copia ed eliminare il cluster pull al termine della migrazione.
  • Il traffico sulla rete del cluster di origine viene ridotto, il che consente larghezze di banda in uscita più elevate e trasferimenti più rapidi.
  • Non è necessario installare il connettore Cloud Storage sul cluster di origine poiché il cluster Dataproc temporaneo, in cui il connettore è già installato, gestisce il trasferimento dei dati in Cloud Storage.

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

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

Replica a blocchi HDFS con riconoscimento del rack

Durante la copia di 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. I blocchi del file vengono quindi inviati al cluster di origine e in 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 quando si utilizza il modello push

Quando copi un file utilizzando il modello pull (ovvero, quando l'attività mappa distcp viene eseguita su un nodo dati del cluster 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 quando si utilizza il modello pull

Quando utilizzi il modello pull, devi monitorare il numero di attività di mappatura di 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 Hadoop può essere una soluzione cloud-native o ibrida. La differenza tra questi è se il sistema manterrà i componenti on-premise. Una soluzione cloud-native ospita i dati nel cloud e lì esegue job. In una soluzione ibrida, alcuni dati rimangono on-premise. Potresti eseguire job anche su questi dati on-premise, oppure eseguire job nel cloud che funzionano con dati on-premise.

Una soluzione cloud-native è la più facile da gestire, ma potresti avere requisiti aziendali o tecnici che mantengono parte dei dati o dell'elaborazione on-premise. Ogni soluzione ibrida è altamente dipendente dal caso, compreso il proprio mix di tecnologie e servizi, per soddisfare le esigenze del carico di lavoro.

Spostamento di dati in prodotti diversi da Cloud Storage

Sposta la maggior parte dei tuoi dati in Cloud Storage. Tuttavia, in alcuni casi potresti considerare di spostare i dati in un altro prodotto Google Cloud:

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

  • Se esegui la migrazione dei dati da Apache Impala, valuta la possibilità di spostarli in BigQuery, per fornire 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.

Pianificare le località dei dati tenendo conto delle 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 ogni bucket Cloud Storage. Se hai impostato autorizzazioni diverse per set di dati HDFS differenti, valuta la possibilità di creare in Cloud Storage bucket diversi con autorizzazioni diverse. Poi inserisci i dati HDFS nel bucket che dispone delle autorizzazioni corrette.

Se sposti i file in una struttura in Cloud Storage diversa da quella in HDFS, ricordati di tenere traccia di tutte le modifiche. Quando sposti i job in Dataproc, dovrai indicare i percorsi corretti dei dati nelle nuove posizioni.

Pianificare uno spostamento incrementale

Pianifica di spostare i dati in blocchi discreti nel tempo. Pianifica molto tempo per spostare i job corrispondenti nel cloud tra un trasferimento di dati e l'altro. Avvia la migrazione spostando i 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 in base a timestamp

Un approccio comune alla suddivisione dei dati per uno spostamento incrementale è archiviare i dati meno recenti nel cloud, mantenendo i nuovi dati in HDFS nel sistema on-premise. Ciò consente di testare job nuovi e di cui è stata eseguita la migrazione su dati meno critici e meno recenti. Suddividere i dati in questo modo ti consente di iniziare lo spostamento con piccole quantità di dati.

Considerazioni importanti:

  • Oltre alla suddivisione in base al tempo, puoi 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 proprietaria e successivamente suddividendoli ulteriormente in base al tempo.
  • Vuoi usare una data e un'ora assolute o relative? 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 appropriato se vuoi creare job di backfill per testare il tuo sistema nel cloud e vedere se puoi elaborare i vecchi dati per renderli conformi 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 hanno spesso più valori di data e ora. A volte la data di creazione del file è la più importante. Altre volte potresti voler utilizzare l'ora dell'ultima modifica o un altro timestamp dai metadati del file.
  • I dati hanno tutti 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 diversi formati. Assicurati di avere timestamp coerenti prima di utilizzarli per suddividere i dati.

Suddivisione dei dati per job

A volte puoi suddividere i dati cercando i job che li utilizzano. Ciò può essere particolarmente utile se esegui la migrazione in modo incrementale dei job. 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 può risultare difficile 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 puoi utilizzarli in modi diversi.
  • L'ambito della migrazione del job è corretto in modo da generare blocchi di dati gestibili?

Puoi anche utilizzare criteri funzionali più ampi per suddividere i dati anziché solo insiemi di job. Ad esempio, puoi eseguire tutto il lavoro ETL nel cloud e quindi 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 l'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 particolare ruolo aziendale a un bucket Cloud Storage isolato semplifica l'impostazione delle autorizzazioni.

Considerazioni importanti:

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

Mantenere sincronizzati i dati in una soluzione ibrida

Una delle sfide dell'uso di una soluzione ibrida è che a volte un job deve 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 località di archiviazione principale in un ambiente e mantenerne una copia sincronizzata nell'altro.

Le sfide legate alla sincronizzazione dei dati sono simili, indipendentemente dalla località principale scelta. Hai bisogno di un modo per capire quando i dati sono stati modificati e di un meccanismo per propagare le modifiche alle copie corrispondenti. Se esiste la possibilità di modifiche in conflitto, devi anche sviluppare una strategia per risolverle.

Considerazioni importanti:

  • Se possibile, crea sempre copie dei dati di sola lettura. La 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 meglio la sincronizzazione dei dati.

Spostamento dei dati

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

Configurazione dell'accesso ai dati

Le autorizzazioni per i file funzionano in modo diverso in Cloud Storage rispetto a HDFS. Prima di spostare i tuoi 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 in base ai gruppi, quindi assegna gli utenti ai gruppi in base alle esigenze. Devi prendere decisioni relative all'accesso ai dati durante l'importazione e la struttura 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 separatamente i criteri per ogni prodotto. 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 ai criteri per il tuo sistema Hadoop basato su cloud:

Se devi assegnare autorizzazioni più granulari ai singoli file, Cloud Storage supporta gli elenchi di controllo dell'accesso (ACL). Tuttavia, IAM è l'opzione fortemente preferita. Utilizza gli ACL solo se le tue 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 Hadoop DistCp per spostare i dati da HDFS on-premise a Cloud Storage. Puoi spostare i dati in diversi modi utilizzando DistCp. Ti consigliamo di procedere nel seguente 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 dei 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 creato per il job. Il suffisso -m identifica l'istanza principale.

  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 nodo 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 viene criptato per impostazione predefinita con Transport Layer Security (TLS).

Convalida dei trasferimenti di dati

Quando copi o sposti dati tra sistemi di archiviazione distinti, ad esempio più cluster HDFS o tra HDFS e Cloud Storage, è consigliabile eseguire un tipo di convalida per garantire l'integrità dei dati. Questa convalida è essenziale per assicurarti che i dati non siano stati modificati durante il trasferimento. Per ulteriori dettagli, consulta la guida relativa alla convalida dei trasferimenti di dati.

Aumentare il tasso di richieste

Cloud Storage mantiene un indice di chiavi degli oggetti per ciascun bucket al fine di fornire un elenco coerente degli oggetti. Questo indice viene 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 sono tutte presenti in un piccolo intervallo dell'indice aumentano naturalmente le possibilità di contesa.

Cloud Storage rileva questa contesa e ridistribuisce automaticamente il carico sull'intervallo di indice interessato su più server. Se scrivi gli oggetti con un nuovo prefisso e prevedi di raggiungere una frequenza superiore a 1000 richieste di scrittura al secondo, devi aumentare gradualmente la tasso di richieste, come descritto nella documentazione di Cloud Storage. In caso contrario, la latenza e i tassi di errore potrebbero essere temporaneamente più elevati.

Migliorare la 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 distribuisca 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 sufficiente per soddisfare le esigenze della migrazione. Valuta 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 dei partner. La maggior parte offre uno SLA (accordo sul livello del servizio) 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 varietà di partner che possono aiutarti nella migrazione dei dati. Consulta 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 ottenere informazioni dettagliate.

Passaggi successivi