Migrazione dei dati HDFS da on-premise a Google Cloud

Last reviewed 2024-04-17 UTC

Questa guida descrive la procedura di spostamento dei dati da Hadoop Distributed File System (HDFS) on-premise a 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 la migrazione in modo incrementale per avere il tempo di eseguire la migrazione di job, esperimenti e test dopo aver spostato ogni insieme di dati.

Decidere come spostare i dati

Esistono due diversi modelli di migrazione da prendere in considerazione 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 in Cloud Storage, ma adottano approcci diversi.

Il modello push è il più semplice: il cluster di origine esegue i job distcp sui propri nodi di dati e invia i file direttamente a 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 il cluster di origine durante la migrazione per altri job di elaborazione dei dati regolari, 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 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 suGoogle Cloud per gestire i job di copia e smantellare 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, poiché il cluster Dataproc temporaneo, che ha già installato il connettore, gestisce il trasferimento dei dati su Cloud Storage.

Per comprendere le implicazioni per l'utilizzo della rete per entrambi i modelli, considera come Hadoop gestisce la replica dei dati in HDFS. Hadoop suddivide ogni file in più blocchi, di solito di dimensioni comprese tra 128 e 256 MB. 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. La configurazione standard prevede la memorizzazione di 3 repliche di ciascun 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 espulsi dal cluster di origine e trasferiti a Cloud Storage. Il traffico sulla rete potrebbe richiedere fino al 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 il distcptask di mappatura 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 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 una 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, alcuni dei tuoi dati rimangono on-premise. Puoi anche eseguire job su questi dati on-premise o nel cloud che funzionano con i 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 soluzione ibrida è altamente dipendente dal caso, inclusa la propria combinazione di tecnologie e servizi per soddisfare le esigenze del tuo carico di lavoro.

Spostare i dati in prodotti diversi da Cloud Storage

Sposta la maggior parte dei dati in Cloud Storage. Tuttavia, in alcuni casi potresti prendere in considerazione la possibilità di spostare i dati in un altro prodottoGoogle 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.

Pianificare le posizioni 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 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. Poi, 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 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 le architetture.

Suddivisione dei dati

Se prevedi di spostare i dati in modo incrementale, devi suddividerli in più parti. Le sezioni seguenti descrivono le strategie più comuni per suddividere i 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 di cui è stata eseguita la migrazione su dati meno critici e meno recenti. Se dividi i dati in questo modo, puoi iniziare lo spostamento con piccole 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.
  • Devi utilizzare una data/ora assoluta o una data/ora relativa? A volte può essere utile 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 verificare se puoi elaborare i dati precedenti per allinearli ai tuoi standard attuali. In altri casi, potresti voler spostare i dati sul 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 data/ora utilizzi per prendere la decisione? I file spesso hanno più valori di data/ora. A volte la data di creazione del file è la più importante. In altri casi, potresti voler utilizzare la data e l'ora dell'ultima modifica o 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 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 che sposti.

Considerazioni importanti:

  • I job che stai spostando nel cloud sono autocontenuti? La suddivisione per job è un'ottima opzione per i job che utilizzano unità di dati autosufficienti, ma può diventare difficile da gestire se i job utilizzano dati distribuiti nel sistema.
  • È probabile che i dati avranno gli stessi utilizzi in futuro? Rifletti attentamente prima di isolare i dati se potresti utilizzarli 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 anziché solo set di job. Ad esempio, puoi eseguire tutte le operazioni di ETL nel cloud e poi eseguire job di analisi e generazione di report on-premise.

Suddivisione dei dati in base alla proprietà

In alcuni casi, puoi suddividere i dati in base alle 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 ti consente di sfruttare la gestione dell'accesso basata sui ruoli diGoogle Cloud. Ad esempio, la migrazione dei dati utilizzati da un determinato ruolo aziendale a un bucket Cloud Storage isolato semplifica la configurazione 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, ma 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 trovare set di dati molto grandi dopo la suddivisione in base alla proprietà. Può essere utile limitare ulteriormente i dati suddividendoli di nuovo per attività o per tempo.

Mantenere sincronizzati i dati in una soluzione ibrida

Uno dei problemi dell'utilizzo di una soluzione ibrida è che a volte un job deve accedere ai dati sia da Google Cloud sia 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 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 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 mantenere più di due copie dei dati. Mantieni una sola copia on-premise e una sola in Google Cloud.

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

Spostare i dati

Le seguenti sezioni illustrano le considerazioni per spostare i dati su Google Cloud.

Configurazione dell'accesso ai dati

Le autorizzazioni dei file funzionano in modo diverso su Cloud Storage rispetto a HDFS. Prima di spostare i dati in Cloud Storage, devi familiarizzare 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 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 norme 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, l'IAM è l'opzione vivamente consigliata. Utilizza le 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 Hadoop DistCp per spostare i dati dall'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 di 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 che hai creato per il job. Il suffisso -m identifica l'istanza principale.

  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 il nomenode e la porta in cui sono memorizzati i dati di origine e 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 dati tra sistemi di archiviazione distinti, come più cluster HDFS o tra HDFS e Cloud Storage, è buona norma 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 maggiori dettagli, consulta la guida sulla convalida dei trasferimenti di dati.

Aumento del tasso di richieste

Cloud Storage gestisce un indice delle chiavi degli oggetti per ogni bucket al fine di fornire un elenco di oggetti coerente. Questo indice viene memorizzato in ordine alfabetico e viene aggiornato 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 aumenta naturalmente le probabilità di contesa.

Cloud Storage rileva queste contese e ridistribuisce automaticamente il carico 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 tasso di richieste, come descritto nella documentazione di Cloud Storage. In caso contrario, la latenza e i tassi di errore potrebbero aumentare temporaneamente.

Miglioramento della velocità di migrazione dei dati

Il modo più semplice per trasferire i dati dai tuoi cluster on-premise a Google Cloud è utilizzare un tunnel VPN tramite internet pubblico. Se un singolo tunnel VPN non fornisce la velocità effettiva necessaria, è possibile creare 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á di connessione sufficienti per soddisfare le esigenze della migrazione. Valuta i seguenti approcci per migliorare il throughput:

  • 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 di 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 scoprire di più, contatta direttamente un fornitore di servizi.

Collaborazione con i partner di Google Cloud

Google Cloud collabora con una serie di partner che possono aiutarti a eseguire la migrazione dei tuoi 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