Migrazione dei dati HDFS da on-premise a Google Cloud

Questa guida descrive il processo di trasferimento dei dati dal file system distribuito HDMI (HDFS) on-premise a Google Cloud (Google Cloud).

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

Pianificare lo spostamento dei dati

Le seguenti sezioni descrivono le best practice per la pianificazione della migrazione di dati da HDFS on-premise a Google Cloud. Pianifica di eseguire la migrazione in modo incrementale in modo da lasciare il tempo di eseguire la migrazione di job, esperimenti e test dopo aver spostato ogni insieme di dati.

Decidi come spostare i dati

Esistono due diversi modelli di migrazione da prendere in considerazione per trasferire i 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 utilizzano approcci diversi.

Il modello push è il modello più semplice: il cluster di origine esegue i job distcp sui nodi dati e invia i file direttamente a Cloud Storage, come mostrato nel diagramma seguente:

Eseguire la 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 nodi di dati, estrae i file dal cluster di origine e li copia in Cloud Storage, come mostrato nel diagramma seguente:

Eseguire la 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 in 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 dati regolari, devi assicurarti che sul 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 alla capacità di calcolo e se non è possibile aumentare le risorse nel cluster di origine per eseguire la copia, è consigliabile utilizzare il modello di pull.

Sebbene sia 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, perché i nodi di origine vengono utilizzati solo per fornire 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 analizzare il cluster di pull al termine della migrazione.
  • Il traffico sulla rete del cluster di origine è ridotto, il che consente una larghezza di banda in uscita superiore e trasferimenti più rapidi.
  • Non è necessario installare il connettore Cloud Storage nel cluster di origine poiché il cluster Dataproc temporaneo, in cui è già installato il connettore, gestisce il trasferimento dei dati in Cloud Storage.

Per comprendere le implicazioni dell'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 è solitamente di 128-256 megabyte. Hadoop replica questi blocchi su più nodi di dati e su più rack per evitare di perdere i dati in caso di errore del nodo dati o di errore del rack. La configurazione standard prevede l'archiviazione di 3 repliche di ciascun blocco.

Hadoop utilizza anche "nock awareness", che assicura che due copie di ciascun blocco siano in nodi di dati diversi all'interno dello stesso rack per una latenza più bassa, e una terza copia in un rack diverso per una maggiore ridondanza e disponibilità. Questa logica di replica è riassunta nel diagramma seguente:

Replica di blocchi HDFS con consapevolezza 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 dati. I blocchi dei file vengono quindi spinti fuori dal cluster di origine e verso Cloud Storage. Il traffico sulla rete può richiedere quasi il doppio delle dimensioni totali del file, come illustrato nel diagramma seguente:

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 generale è limitato alle dimensioni totali del file, come illustrato nel diagramma seguente:

Utilizzo della rete quando si utilizza il modello pull

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

Decidi dove spostare i dati

Il risultato finale della migrazione di Hadoop può essere una soluzione cloud-native o una soluzione ibrida. La differenza è che il sistema conserva tutti i componenti on-premise. In una soluzione cloud-native, tu ospiti i tuoi dati nel cloud ed esegui job in ognuno di essi. In una soluzione ibrida, alcuni dati rimangono on-premise. Puoi anche eseguire job su tali dati on-premise, oppure eseguire nel cloud job che funzionano con dati on-premise.

La soluzione cloud-native è la più facile da mantenere, ma si possono avere requisiti aziendali o tecnici che mantengono alcuni dati o processi on-premise. Ogni soluzione ibrida è altamente dipendente dal caso, incluso il proprio mix di tecnologie e servizi per soddisfare le esigenze del carico di lavoro.

Spostamento di dati in prodotti diversi da Cloud Storage

Trasferisci la maggior parte dei dati a Cloud Storage. Tuttavia, in alcuni casi puoi prendere in considerazione lo spostamento dei dati su un prodotto Google Cloud diverso:

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

  • Se stai eseguendo la migrazione di dati da Apache Impala, valuta la possibilità di spostarli in BigQuery, che fornisce funzionalità equivalenti.

In HBase o Impala potresti avere dati che puoi utilizzare senza archiviarli in BigQuery 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 più complicato alle autorizzazioni dei file è impostarle a livello di ciascun bucket Cloud Storage. Se hai impostato autorizzazioni diverse per set di dati HDFS diversi, valuta la creazione di bucket diversi in Cloud Storage, ognuno dei quali ha autorizzazioni diverse. Quindi inserisci i dati HDFS nel bucket con le autorizzazioni appropriate per tali dati.

Se sposti in Cloud Storage i file in una struttura diversa da quella dell'HDFS, ricordati di tenere traccia di tutte le modifiche. Quando sposti i job in Dataproc, devi fornire i percorsi corretti ai dati nelle nuove posizioni.

Pianificare uno spostamento incrementale

Pianifica di spostare i dati in blocchi discreti nel tempo. Pianifica un sacco di tempo per spostare i job corrispondenti sul cloud tra un trasferimento di dati e l'altro. Avvia la migrazione spostando i dati a bassa priorità, come backup e archivi.

Suddividere i 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 al timestamp

Un approccio comune alla suddivisione dei dati per uno spostamento incrementale consiste nell'archiviazione dei dati meno recenti nel cloud, pur mantenendo 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. Suddividere i dati in questo modo ti consente di iniziare lo spostamento con piccole quantità di dati.

Considerazioni importanti:

  • È possibile suddividere i dati utilizzando un altro metodo oltre alla suddivisione per tempo? Per ottenere un set di dati più mirato, suddividi i dati in base alle mansioni supportate o all'organizzazione proprietaria e suddivideli ulteriormente per tempo.
  • Devi utilizzare una data/ora assoluta o una data/ora relativa? A volte ha senso suddividere i dati in un momento specifico, ad esempio archiviare tutti i dati generati prima di un'importante modifica nel sistema. L'utilizzo di una data/ora assoluta è spesso appropriata se vuoi creare job di backfill per testare il tuo sistema nel cloud per vedere se puoi elaborare i dati precedenti al fine di 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 utilizzi per prendere la decisione? I file hanno spesso più valori per data/ora. A volte la data di creazione del file è la più importante. Altre volte potresti voler usare l'ora dell'ultima modifica o un altro timestamp dai metadati del file.
  • Tutti i dati hanno lo stesso formato di timestamp? Esistono diversi modi per gestire i timestamp. Se i dati provengono da più origini, è possibile che i timestamp siano memorizzati 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. Questo 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 state spostando nel cloud sono autonomi? La suddivisione per job è un'ottima opzione per i job che lavorano su unità di dati indipendenti, ma può diventare difficile da gestire se i job funzionano con dati distribuiti nel tuo sistema.
  • È probabile che i dati abbiano gli stessi utilizzi in futuro? Rifletti attentamente prima di isolare i dati per utilizzarli in modi diversi.
  • La migrazione del job ha un ambito appropriato per generare blocchi di dati gestibili?

Puoi anche utilizzare criteri funzionali più ampi per suddividere i dati invece di soli insiemi di job. Ad esempio, puoi eseguire tutto il tuo lavoro ETL nel cloud e poi eseguire job di analisi e reporting on-premise.

Suddivisione dei dati per proprietà

In alcuni casi, puoi suddividere i dati in base alle aree di proprietà. Uno dei vantaggi di questo approccio è che la tua organizzazione dei dati è in linea con quella della tua attività. Un altro vantaggio è che ti 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 a un bucket Cloud Storage isolato semplifica la configurazione delle autorizzazioni.

Considerazioni importanti:

  • I confini tra i proprietari sono chiari? Di solito è chiaro chi è il proprietario principale di un determinato elemento dati, può capitare che le persone che più spesso accedono ai dati non siano i proprietari.
  • Esistono altri criteri di suddivisione che puoi combinare con la proprietà? Dopo la suddivisione in base alla proprietà, potresti ottenere set di dati di grandi dimensioni. Può essere utile limitare ulteriormente gli elementi suddividendo i dati per attività o per tempo.

Mantenere sincronizzati i dati in una soluzione ibrida

Una delle sfide dell'utilizzo di una soluzione ibrida è che a volte un job deve accedere ai dati sia di Google Cloud che dei sistemi on-premise. Se devi accedere a un set di dati in entrambi gli ambienti, devi stabilire una località di archiviazione principale in un ambiente e conservare una copia sincronizzata nell'altro.

Le sfide relative alla sincronizzazione dei dati sono simili, indipendentemente dalla località principale che scegli. Hai bisogno di un modo per identificare quando i dati sono stati modificati e un meccanismo per propagare le modifiche alle copie corrispondenti. Se esiste un potenziale di modifica in conflitto, devi anche sviluppare una strategia per risolverli.

Considerazioni importanti:

  • Se possibile, crea 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 solo una in Google Cloud.

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

Spostamento dei dati

Le seguenti sezioni illustrano le considerazioni necessarie per spostare i tuoi dati in Google Cloud.

Configurazione dell'accesso ai dati

Le autorizzazioni dei file funzionano in modo diverso su Cloud Storage rispetto all'HDFS. Prima di spostare i tuoi dati in Cloud Storage, devi conoscere 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 consentono l'accesso a singoli utenti o a gruppi. Concedi l'accesso in base ai gruppi e assegna gli utenti ai gruppi in base alle esigenze. Devi prendere decisioni relative all'accesso ai dati durante l'importazione e la strutturazione dei dati in Cloud Storage.

Ogni prodotto Google Cloud ha le proprie autorizzazioni e ruoli. Assicurati di comprendere le relazioni tra i controlli dell'accesso di Cloud Storage e quelli di Dataproc. Valuta le norme relative a ciascun prodotto separatamente. Non supporre che i ruoli e le autorizzazioni vengano mappati direttamente tra i prodotti.

Acquisisci familiarità con la seguente documentazione per preparare le decisioni dei 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 più consigliata. Utilizza 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 Hadoop DistCp per spostare i dati dalla tua HDFS on-premise a Cloud Storage. Puoi spostare i dati in diversi modi utilizzando DistCp. Consigliamo di farlo in questo 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 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 creato per il job. Il suffisso -m identifica l'istanza master.

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

Gli effettivi comandi DistCp 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 nome e la porta in cui sono archiviati i dati di origine, mentre bucket è il nome del bucket Cloud Storage in cui copi 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, è consigliabile eseguire un tipo di convalida per garantire l'integrità dei dati. Questa convalida è essenziale per garantire che i dati non siano stati modificati durante il trasferimento. Per ulteriori dettagli, consulta la guida sulla convalida dei trasferimenti di dati.

Incrementare la percentuale di richieste

Cloud Storage mantiene un indice delle chiavi degli oggetti per ciascun bucket al fine di fornire un elenco di oggetti coerente. Questo indice è archiviato in ordinelessicografico 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 esistono tutte in un piccolo intervallo dell'indice aumentano naturalmente le possibilità di contenziosi.

Cloud Storage rileva questa contesa e ridistribuisce automaticamente il carico sull'intervallo di indice interessato tra più server. Se scrivi oggetti con un nuovo prefisso e prevedi di ottenere una frequenza superiore a 1000 richieste di scrittura al secondo, dovresti incrementarla gradualmente, come descritto nella documentazione di Cloud Storage. Se non lo fai, la latenza e i tassi di errore potrebbero risultare temporaneamente più elevati.

Migliorare la velocità di migrazione dei dati

Il modo più semplice per trasferire dati dai tuoi cluster on-premise a Google Cloud è utilizzare un tunnel VPN sulla Internet pubblica. Se un singolo tunnel VPN non fornisce la velocità effettiva necessaria, potrebbero essere 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 una larghezza di banda o una stabilità di connessione sufficienti 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) di Google. Questa opzione riduce il numero di hop tra la rete e Google Cloud.

  • Usa 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 (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 serie di partner che possono aiutarti a eseguire la migrazione dei tuoi dati. Consulta i partner che lavorano con Cloud Storage per ulteriori informazioni sui servizi disponibili per aiutarti con la migrazione dei dati. I servizi e i termini disponibili variano a seconda del fornitore, quindi contattali direttamente per avere informazioni dettagliate.

Passaggi successivi