Migrazione dell'infrastruttura Hadoop on-premise a Google Cloud

Questa guida fornisce una panoramica su come spostare il tuo sistema Apache Hadoop on-premise su Google Cloud. Descrive un processo di migrazione che non solo sposta il tuo lavoro Hadoop su Google Cloud, ma ti consente anche di adattarlo per sfruttare i vantaggi di un sistema Hadoop ottimizzato per il cloud computing. Introduce anche alcuni concetti fondamentali da comprendere per tradurre la configurazione di Hadoop in Google Cloud.

Questa è la prima di una serie di guide che descrivono come passare da Hadoop on-premise:

I vantaggi della migrazione a Google Cloud

L'utilizzo di Google Cloud può farti risparmiare tempo, denaro e impegno in molti modi rispetto a una soluzione Hadoop on-premise. In molti casi, l'adozione di un approccio basato sul cloud può rendere la soluzione complessiva più semplice e facile da gestire.

Supporto integrato per Hadoop

Google Cloud include Dataproc, ovvero un ambiente gestito Hadoop e Spark. Puoi utilizzare Dataproc per eseguire la maggior parte dei job esistenti con modifiche minime, in modo da non dover abbandonare tutti gli strumenti Hadoop che già conosci.

Hardware gestito e configurazione

Quando esegui Hadoop su Google Cloud, non devi preoccuparti dell'hardware fisico. Tu specifichi la configurazione del tuo cluster e Dataproc alloca le risorse per te. Puoi scalare il cluster in qualsiasi momento.

Gestione semplificata delle versioni

Mantenere aggiornati gli strumenti open source e la collaborazione è una delle parti più complesse della gestione di un cluster Hadoop. Quando utilizzi Dataproc, gran parte del lavoro viene gestita per te dal controllo delle versioni di Dataproc.

Configurazione flessibile dei job

Una tipica configurazione Hadoop on-premise utilizza un singolo cluster che serve molti scopi. Quando passi a Google Cloud, puoi concentrarti sulle attività individuali, creando tutti i cluster di cui hai bisogno. In questo modo si elimina gran parte delle complessità associate alla gestione di un singolo cluster con dipendenze e interazioni di configurazione software crescenti.

Pianificazione della migrazione

La migrazione da una soluzione Hadoop on-premise a Google Cloud richiede un cambio di approccio. Un tipico sistema Hadoop on-premise è costituito da un cluster monolitico che supporta molti carichi di lavoro, spesso in più aree aziendali. Di conseguenza, il sistema nel tempo diventa più complesso e può richiedere agli amministratori di scendere a compromessi per far funzionare tutto nel cluster monolitico. Spostando il tuo sistema Hadoop su Google Cloud, puoi ridurre la complessità amministrativa. Tuttavia, per ottenere questa semplificazione e ottenere l'elaborazione più efficiente in Google Cloud con il costo minimo, devi ripensare a come strutturare i dati e i job.

Poiché Dataproc esegue Hadoop su Google Cloud, l'utilizzo di un cluster Dataproc permanente per replicare la configurazione on-premise potrebbe sembrare la soluzione più semplice. Tuttavia, questo approccio presenta alcune limitazioni:

  • Conservare i dati in un cluster HDFS permanente utilizzando Dataproc è più costoso rispetto all'archiviazione dei dati in Cloud Storage, cosa che consigliamo, come spiegato di seguito. Conservare i dati in un cluster HDFS limita anche la possibilità di utilizzare i dati con altri prodotti Google Cloud.
  • Il potenziamento o la sostituzione di alcuni dei tuoi strumenti basati su open source con altri servizi Google Cloud correlati può essere più efficiente o economico per casi d'uso specifici.
  • Utilizzare un unico cluster Dataproc permanente per i job è più difficile da gestire rispetto al passaggio a cluster mirati che si occupano di singoli job o aree di lavoro.

Il modo più economico e flessibile per eseguire la migrazione del tuo sistema Hadoop su Google Cloud è abbandonare la visione in termini di cluster permanenti grandi, multiuso e permanenti e pensare piuttosto a cluster piccoli e a breve durata progettati per eseguire job specifici. Puoi archiviare i dati in Cloud Storage per supportare più cluster di elaborazione temporanea. Questo modello viene spesso chiamato modello temporaneo, perché i cluster utilizzati per l'elaborazione dei job vengono allocati secondo necessità e rilasciati al termine dei job.

Il seguente diagramma mostra un'ipotetica migrazione da un sistema on-premise a un modello temporaneo su Google Cloud.

Diagramma che illustra come riorganizzare i cluster on-premise durante la migrazione a Google Cloud.

L'esempio sposta in Dataproc quattro job in esecuzione su due cluster on-premise. I cluster temporanei utilizzati per eseguire i job in Google Cloud sono definiti in modo da massimizzare l'efficienza dei singoli job. I primi due job utilizzano lo stesso cluster, mentre il terzo e il quarto job vengono eseguiti ciascuno sul proprio cluster. Quando esegui la migrazione dei tuoi job, puoi personalizzare e ottimizzare i cluster per i singoli job o per i gruppi di job in base alle tue esigenze specifiche. Dataproc consente di definire rapidamente più cluster, portarli online e scalarli in base alle tue esigenze.

I dati nell'esempio vengono spostati da due cluster HDFS on-premise ai bucket Cloud Storage. I dati nel primo cluster sono divisi tra più bucket, mentre il secondo viene spostato in un unico bucket. Puoi personalizzare la struttura dei dati in Cloud Storage in base alle esigenze delle tue applicazioni e della tua azienda.

L'esempio di migrazione acquisisce gli stati iniziale e finale di una migrazione completa a Google Cloud. Questo implica un solo passaggio, ma otterrai i risultati migliori se non pensi di passare a Google Cloud come una migrazione completa una tantum. Immagina invece come un refactoring delle soluzioni per usare nuovi strumenti in modi impensabili on-premise. Per far funzionare questo refactoring, consigliamo di eseguire la migrazione in modo incrementale.

Ecco i passaggi consigliati per la migrazione dei flussi di lavoro a Google Cloud:

  1. Sposta prima i dati

    • Sposta i dati nei bucket Cloud Storage.
    • Inizia con pochi utenti. Utilizza dati di backup o archiviati per ridurre al minimo l'impatto sul sistema Hadoop esistente.
  2. Sperimenta

    • Utilizza un sottoinsieme di dati per eseguire test ed esperimenti. Crea un proof of concept su scala ridotta per ogni job.
    • Prova nuovi approcci per lavorare con i tuoi dati.
    • Adeguati ai paradigmi di Google Cloud e di cloud computing.
  3. Pensa in termini di cluster temporanei specializzati.

    • Utilizza i cluster più piccoli possibili, limitandoli a singoli job o a piccoli gruppi di job strettamente correlati.
    • Crea i cluster ogni volta che ne hai bisogno per un job ed eliminali quando hai finito.
  4. Usa gli strumenti di Google Cloud dove appropriato.

Passaggio a un modello temporaneo

Il cambiamento più importante nel tuo approccio tra l'esecuzione di un flusso di lavoro Hadoop on-premise e l'esecuzione dello stesso flusso di lavoro su Google Cloud è il passaggio da cluster monolitici e permanenti a cluster temporanei specializzati. Puoi avviare un cluster quando devi eseguire un job, quindi eliminarlo al termine del job. Le risorse richieste dai job sono attive solo quando vengono utilizzate, quindi paghi solo per quello che utilizzi. Questo approccio consente di personalizzare le configurazioni dei cluster per i singoli job. Poiché non si gestisce e si configura un cluster permanente, si riducono i costi di utilizzo delle risorse e di amministrazione del cluster.

Questa sezione descrive come spostare l'infrastruttura Hadoop esistente a un modello temporaneo.

Separa i dati dal calcolo

L'utilizzo di Cloud Storage come archiviazione permanente per i flussi di lavoro offre i seguenti vantaggi:

  • È più facile gestire le autorizzazioni di accesso.
  • È un file system compatibile con Hadoop (HCFS), quindi è facile da utilizzare con i job esistenti.
  • In molti casi è più veloce dell'HDFS.
  • Richiede meno manutenzione rispetto a HDFS.
  • La migrazione dei dati è più semplice rispetto all'HDFS.
  • Consente di utilizzare facilmente i dati con l'intera gamma di prodotti Google Cloud.
  • È notevolmente meno costoso rispetto a conservare i dati in HDFS su un cluster Dataproc permanente.

Archiviando i dati in modo permanente in Cloud Storage, puoi eseguire i tuoi job su cluster Hadoop temporanei gestiti da Dataproc.

In alcuni casi, potrebbe essere più opportuno spostare i dati in un'altra tecnologia Google Cloud, come BigQuery o Bigtable. Tuttavia, la maggior parte dei dati generici dovrebbe essere conservata in Cloud Storage. Ulteriori dettagli su queste opzioni di archiviazione alternative sono forniti più avanti nella guida.

Esecuzione di job su cluster temporanei

Dataproc semplifica la creazione e l'eliminazione dei cluster, in modo da poter passare dall'utilizzo di un cluster monolitico all'utilizzo di molti cluster temporanei. Questo approccio presenta diversi vantaggi:

  • Puoi evitare single point of failure e aumentare l'affidabilità della pipeline di dati. Quando un cluster condiviso a lunga esecuzione viene eseguito in stato di errore, l'intera pipeline di dati può essere bloccata. La riparazione di un cluster stateful a lunga esecuzione può richiedere molto tempo, causando violazioni degli obiettivi del livello di servizio (SLO). Al contrario, un cluster temporaneo stateless problematico può essere facilmente eliminato e poi ricreato con nuovi tentativi dei job.
  • Puoi avere prestazioni dei job più prevedibili ed evitare violazioni degli SLO eliminando i conflitti delle risorse tra i job.
  • Puoi ottimizzare le configurazioni dei cluster e i criteri di scalabilità automatica per i singoli job.
  • Quando crei un cluster temporaneo per un job, puoi ricevere le patch di sicurezza, le correzioni di bug e le ottimizzazioni più recenti.
  • Puoi evitare problemi comuni con i cluster a lunga esecuzione, come i dischi che si riempiono di log e file temporanei o che lo scale up del cluster non riesce a causa di problemi di disponibilità nella zona.
  • Non è necessario gestire i cluster nel tempo perché i cluster temporanei vengono configurati ogni volta che li utilizzi. Il fatto di non dover gestire i cluster elimina il carico amministrativo della gestione degli strumenti per più job.
  • Non è necessario mantenere un'infrastruttura separata per sviluppo, test e produzione. Con le stesse definizioni, puoi creare tutte le versioni diverse di un cluster.
  • Puoi risolvere i problemi più rapidamente con il cluster isolato a job singolo.
  • Paghi per le risorse solo quando i tuoi job le utilizzano.

Puoi utilizzare le azioni di inizializzazione di Dataproc per definire la configurazione dei nodi in un cluster. Ciò semplifica la manutenzione delle diverse configurazioni dei cluster necessarie per supportare strettamente i singoli job e i relativi gruppi di job. Per iniziare, puoi utilizzare le azioni di inizializzazione di esempio fornite. Gli esempi mostrano come eseguire azioni di inizializzazione personalizzate.

Riduci al minimo la durata dei cluster temporanei

Lo scopo dei cluster temporanei è utilizzarli solo per la durata dei job. Quando è il momento di eseguire un job, segui questa procedura:

  1. Creare un cluster configurato correttamente.

  2. Esegui il job, inviando l'output a Cloud Storage o a un'altra posizione permanente.

  3. Elimina il cluster.

  4. Utilizza l'output del job come preferisci.

  5. Visualizza i log in Cloud Logging o Cloud Storage.

Questa procedura è illustrata nel seguente diagramma:

Diagramma di un flusso di job temporaneo nel cloud.

Utilizza cluster permanenti di piccole dimensioni solo quando assolutamente necessario

Se non riesci a svolgere il tuo lavoro senza un cluster permanente, puoi crearne uno. Questa opzione potrebbe essere costosa e non è consigliata se esiste un modo per eseguire il job su cluster temporanei.

Puoi ridurre al minimo il costo di un cluster permanente:

  • Creazione del cluster più piccolo possibile.
  • Limitare il tuo lavoro al cluster al minor numero possibile di job.
  • Scalabilità del cluster fino al numero minimo di nodi utilizzabili, aggiungendone di più in modo dinamico per soddisfare la domanda.

Migrazione incrementale

La migrazione in modo incrementale presenta molti vantaggi. Puoi:

  • Isola i singoli job nella tua infrastruttura Hadoop esistente dalla complessità intrinseca di un ambiente maturo.
  • Esamina ogni job in modo isolato per valutarne le esigenze e determinare il percorso migliore per la migrazione.
  • Gestisci i problemi imprevisti non appena si presentano senza ritardare le attività dipendenti.
  • Crea una proof of concept per ogni processo complesso senza influire sull'ambiente di produzione.
  • Sposta i carichi di lavoro al modello temporaneo consigliato in modo ponderato e deliberato.

La migrazione è univoca per il tuo ambiente Hadoop, perciò non esiste un piano universale adatto a tutti gli scenari di migrazione. Fai un piano per la migrazione che ti duca la libertà di tradurre ogni pezzo in un paradigma di cloud computing.

Ecco una tipica sequenza di migrazione incrementale:

  1. Sposta alcune parti dei tuoi dati in Google Cloud.

  2. Fai delle prove con questi dati:

    1. Replica i job esistenti che utilizzano i dati.

    2. Crea nuovi prototipi compatibili con i dati.

  3. Ripeti la procedura con altri dati.

Inizia con i dati meno critici possibile. Nelle fasi iniziali è un buon approccio per usare i dati e gli archivi di backup.

Un tipo di job a basso rischio che offre un buon test iniziale è il backfill mediante l'esecuzione dell'elaborazione di burst sui dati di archiviazione. Puoi configurare job che colmano le lacune nell'elaborazione dei dati esistenti prima dell'applicazione dei job attuali. L'avvio dei job di burst può spesso fornire esperienza con la scalabilità su Google Cloud all'inizio del tuo piano di migrazione. In questo modo puoi iniziare la migrazione di altri job critici.

Il seguente diagramma mostra un esempio di una tipica architettura ibrida di backfill.

Diagramma di una tipica architettura per il backfill nel cloud.

L'esempio ha due componenti principali. Innanzitutto, i job pianificati eseguiti sul cluster on-premise eseguono il push dei dati in Cloud Storage tramite un gateway internet. In secondo luogo, i job di backfill vengono eseguiti su cluster Dataproc temporanei. Oltre al backfill, puoi utilizzare cluster temporanei in Google Cloud per la sperimentazione e la creazione di proof of concept per il lavoro futuro.

Pianificare tenendo presente la migrazione completata

Finora, questa guida ha ipotizzato che il tuo obiettivo sia spostare l'intero sistema Hadoop da on-premise a Google Cloud. Un sistema Hadoop eseguito interamente su Google Cloud è più facile da gestire di uno che opera sia nel cloud che on-premise. Tuttavia, spesso è necessario un approccio ibrido per soddisfare le esigenze aziendali o tecnologiche.

Progettazione di una soluzione ibrida

Ecco alcuni motivi per cui potresti aver bisogno di una soluzione ibrida:

  • Poiché sei in fase di sviluppo di sistemi cloud-native, i sistemi esistenti che dipendono da questi devono continuare a essere eseguiti on-premise fino al termine dell'operazione.
  • Hai i requisiti aziendali per mantenere i dati on-premise.
  • Devi condividere i dati con altri sistemi eseguiti on-premise, che non possono interagire con Google Cloud a causa di restrizioni tecniche o aziendali.

Una tipica soluzione ibrida è costituita da quattro parti principali:

  1. Un cluster Hadoop on-premise.

  2. Una connessione dal cluster on-premise a Google Cloud.

  3. Archiviazione dei dati centralizzata in Google Cloud.

  4. Componenti cloud-native che lavorano sui dati in Google Cloud.

Un problema da risolvere con una soluzione cloud ibrido è mantenere sincronizzati i sistemi. In altre parole, come puoi assicurarti che le modifiche apportate ai dati in una posizione si riflettano nell'altra? Puoi semplificare la sincronizzazione facendo distinzioni chiare tra le modalità di utilizzo dei dati nei diversi ambienti.

Ad esempio, potresti avere una soluzione ibrida in cui solo i dati archiviati vengono archiviati in Google Cloud. Puoi configurare job pianificati per spostare i dati dal cluster on-premise a Google Cloud quando i dati raggiungono un'età specificata. Quindi puoi configurare tutti i job che funzionano sui dati archiviati in Google Cloud, in modo da non dover mai sincronizzare le modifiche ai cluster on-premise.

Un altro modo per suddividere il sistema è spostare tutti i dati e lavorare in Google Cloud per un progetto o un gruppo di lavoro specifico, mantenendo l'altra attività on-premise. Concentrati sui tuoi job invece di creare complessi sistemi di sincronizzazione dei dati.

Potresti avere problemi di sicurezza o logistici che complicano il modo in cui connetti il cluster on-premise a Google Cloud. Una soluzione prevede l'utilizzo di un Virtual Private Cloud connesso alla tua rete on-premise tramite Cloud VPN.

Il seguente diagramma mostra un esempio di configurazione di un cloud ibrido:

Diagramma di una tipica architettura Hadoop con cloud ibrido.

La configurazione di esempio utilizza Cloud VPN per connettere un VPC di Google Cloud a un cluster on-premise. Il sistema usa Dataproc all'interno del VPC per gestire cluster permanenti che elaborano i dati provenienti dal sistema on-premise. Ciò può comportare la sincronizzazione dei dati tra i sistemi. Questi cluster Dataproc permanenti trasferiscono anche i dati provenienti dal sistema on-premise ai servizi di archiviazione appropriati in Google Cloud. A scopo illustrativo, l'esempio utilizza Cloud Storage, BigQuery e Bigtable per l'archiviazione, queste sono le destinazioni più comuni per i dati elaborati dai carichi di lavoro Hadoop in Google Cloud.

L'altra metà della soluzione di esempio mostra più cluster temporanei creati in base alle esigenze nel cloud pubblico. Questi cluster possono essere usati per molte attività, incluse quelle che raccolgono e trasformano nuovi dati. I risultati di questi job vengono archiviati negli stessi servizi di archiviazione utilizzati dai cluster in esecuzione nel VPC.

Progettazione di una soluzione cloud-native

Al contrario, una soluzione cloud-native è semplice. Poiché esegui tutti i tuoi job su Google Cloud utilizzando i dati archiviati in Cloud Storage, eviterai del tutto la complessità della sincronizzazione dei dati, anche se devi comunque fare attenzione al modo in cui i diversi job utilizzano gli stessi dati.

Il seguente diagramma mostra un esempio di sistema cloud-native:

Diagramma di una tipica architettura Hadoop cloud-native.

Il sistema di esempio ha alcuni cluster permanenti e altri temporanei. Entrambi i tipi di cluster condividono strumenti e risorse cloud, inclusi archiviazione e monitoraggio. Dataproc utilizza le immagini delle macchine standardizzate per definire le configurazioni software sulle VM in un cluster. Puoi utilizzare queste immagini predefinite come base per la configurazione VM di cui hai bisogno. L'esempio mostra la maggior parte dei cluster permanenti in esecuzione sulla versione 1.1, con un cluster in esecuzione nella versione 1.2. Puoi creare nuovi cluster con istanze VM personalizzate ogni volta che ne hai bisogno. Ciò consente di isolare gli ambienti di test e sviluppo dai job e dai dati critici.

I cluster temporanei nell'esempio eseguono vari job. Questo esempio mostra Apache Airflow in esecuzione su Compute Engine che viene utilizzato per pianificare il lavoro con cluster temporanei.

Lavorare con i servizi Google Cloud

Questa sezione illustra alcune considerazioni aggiuntive per la migrazione di Hadoop a Google Cloud.

Sostituire gli strumenti open source con i servizi Google Cloud

Google Cloud offre molti prodotti che puoi utilizzare con il tuo sistema Hadoop. L'utilizzo di un prodotto Google Cloud può spesso avere vantaggi rispetto all'esecuzione del prodotto open source equivalente in Google Cloud. Scopri i prodotti e i servizi Google Cloud per conoscere la portata di ciò che la piattaforma offre.

Utilizzo di regioni e zone

Prima di configurare dati e job, dovresti comprendere le ripercussioni dell'area geografica e delle regioni. Molti servizi Google Cloud richiedono di specificare le regioni o le zone in cui allocare le risorse. La latenza delle richieste può aumentare quando queste vengono effettuate da una regione diversa da quella in cui sono archiviate le risorse. Inoltre, se le risorse del servizio e i tuoi dati permanenti si trovano in regioni diverse, alcune chiamate ai servizi Google Cloud potrebbero copiare tutti i dati richiesti da una zona all'altra prima dell'elaborazione. Ciò può avere un grave impatto sulle prestazioni.

Configurazione dell'autenticazione e delle autorizzazioni

È probabile che il controllo sulle autorizzazioni nei servizi Google Cloud sia meno granulare rispetto a quello a cui sei abituato nel tuo ambiente Hadoop on-premise. Assicurati di comprendere come funziona la gestione degli accessi in Google Cloud prima di iniziare la migrazione.

Identity and Access Management (IAM) gestisce l'accesso alle risorse cloud. Funziona sulla base di account e ruoli. Gli account identificano un utente o una richiesta (autenticazione) e i ruoli concessi a un account determinano il livello di accesso (autorizzazione). La maggior parte dei servizi Google Cloud fornisce un insieme di ruoli per aiutarti a perfezionare le autorizzazioni. Nell'ambito del processo di pianificazione della migrazione, dovresti scoprire in che modo IAM interagisce con Cloud Storage e Dataproc. Scopri i modelli di autorizzazioni di ogni servizio Google Cloud aggiuntivo quando lo aggiungi al tuo sistema e considera come definire i ruoli utilizzabili nei servizi che utilizzi.

Monitoraggio dei job con Cloud Logging

I job Google Cloud inviano i propri log a Cloud Logging, dove sono facilmente accessibili. Puoi recuperare i log nei seguenti modi:

Gestione dei nodi perimetrali con Compute Engine

Puoi utilizzare Compute Engine per accedere a un nodo perimetrale in un cluster Hadoop di Dataproc. Come per la maggior parte dei prodotti Google Cloud, hai a disposizione più opzioni per la gestione: dalla console basata sul web, dalla riga di comando e dalle API web.

Utilizzo dei servizi per big data di Google Cloud

Cloud Storage è il modo principale per archiviare dati non strutturati in Google Cloud, ma non è l'unica opzione di archiviazione. Alcuni dati potrebbero essere più adatti all'archiviazione in prodotti progettati esplicitamente per i big data.

Puoi utilizzare Bigtable per archiviare grandi quantità di dati sparsi. Bigtable è un'API conforme a HBase che offre bassa latenza e alta scalabilità per adattarsi ai tuoi job.

Per il data warehousing, puoi utilizzare BigQuery.

Passaggi successivi