Questa guida fornisce una panoramica su come spostare il sistema Apache Hadoop on-premise su Google Cloud. Descrive un processo di migrazione che non solo sposta il tuo lavoro su Hadoop in Google Cloud, ma ti consente anche di adattarlo per sfruttare i vantaggi di un sistema Hadoop ottimizzato per il cloud computing. Inoltre, illustra alcuni concetti fondamentali che devi conoscere per tradurre la configurazione di Hadoop in Google Cloud.
Questa è la prima di diverse guide che descrivono come passare da Hadoop on-premise:
- Questa guida, che fornisce contesto e consigli di pianificazione per la migrazione.
- La migrazione dei dati HDFS da on-premise a Google Cloud fornisce un contesto aggiuntivo per spostare i dati in modo incrementale inGoogle Cloud.
- Migrazione dei dati da HBase a Bigtable
- Eseguire la migrazione dei job Hadoop da on-premise a Dataproc descrive la procedura di esecuzione dei job su Dataproc e su altri Google Cloud prodotti.
Vantaggi della migrazione a Google Cloud
Esistono molti modi in cui l'utilizzo di Google Cloud puoi farti risparmiare tempo, denaro e risorse rispetto all'utilizzo di una soluzione Hadoop on-premise. In molti casi, l'adozione di un approccio basato su cloud può rendere la soluzione complessiva più semplice e facile da gestire.
Supporto integrato per Hadoop
Google Cloud include Dataproc, un ambiente Hadoop e Spark gestito. Puoi utilizzare Dataproc per eseguire la maggior parte dei job esistenti con modifiche minime, quindi non è necessario discostarti da tutti gli strumenti Hadoop che già conosci.
Hardware e configurazione gestiti
Quando esegui Hadoop su Google Cloud, non devi mai preoccuparti dell'hardware fisico. Specifica la configurazione del tuo cluster e Dataproc alloca le risorse per te. Puoi scalare il tuo cluster in qualsiasi momento.
Gestione semplificata delle versioni
Mantenere aggiornati gli strumenti open source e lavorare insieme è una delle parti più complesse della gestione di un cluster Hadoop. Quando utilizzi Dataproc, gran parte di questo lavoro viene gestito per te dal controllo delle versioni di Dataproc.
Configurazione flessibile dei job
Una tipica configurazione Hadoop on-premise utilizza un singolo cluster che serve a molti scopi. Quando passi a Google Cloud, puoi concentrarti sulle singole attività, creando tutti i cluster di cui hai bisogno. Ciò elimina gran parte della complessità legata alla gestione di un singolo cluster con dipendenze crescenti e interazioni di configurazione software.
Pianificare la 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 di business. Di conseguenza, il sistema diventa più complesso nel tempo e può richiedere agli amministratori di scendere a compromessi per far funzionare tutto nel cluster monolitico. Quando sposti il tuo sistema Hadoop su Google Cloud, puoi ridurre la complessità amministrativa. Tuttavia, per ottenere questa semplificazione e un'elaborazione Google Cloud il più efficiente possibile con un costo minimo, devi ripensare alla struttura dei dati e dei job.
Poiché Dataproc esegue Hadoop su Google Cloud, l'utilizzo di un cluster Dataproc persistente per replicare la configurazione on-premise potrebbe sembrare la soluzione più semplice. Tuttavia, questo approccio presenta alcune limitazioni:
- Mantenere i tuoi dati in un cluster HDFS persistente utilizzando Dataproc è più costoso che archiviarli in Cloud Storage, che è ciò che consigliamo, come spiegato di seguito. Mantenere i dati in un cluster HDFS limita anche la capacità di utilizzarli con altri Google Cloud prodotti.
- L'aumento o la sostituzione di alcuni dei tuoi strumenti basati su open source con altri Google Cloud servizi correlati può essere più efficiente o economico per casi d'uso particolari.
- L'utilizzo di un unico cluster Dataproc persistente per i tuoi job è più difficile da gestire rispetto al passaggio a cluster mirati che servono singoli job o aree di job.
Il modo più conveniente e flessibile per eseguire la migrazione del tuo sistema Hadoop a Google Cloud è smettere di pensare in termini di cluster persistenti, multiuso e di grandi dimensioni e pensare invece a cluster piccoli e di breve durata, progettati per eseguire job specifici. Archivia i tuoi dati in Cloud Storage per supportare più cluster di elaborazione temporanei. Questo modello è 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 una migrazione ipotetica da un sistema on-premise a un modello temporaneo su Google Cloud.
L'esempio sposta quattro job in esecuzione su due cluster on-premise in Dataproc. I cluster temporanei utilizzati per eseguire i job in Google Cloud sono definiti per massimizzare l'efficienza per i singoli job. I primi due job utilizzano lo stesso cluster, mentre il terzo e il quarto vengono eseguiti ciascuno su un proprio cluster. Quando esegui la migrazione dei tuoi job, puoi personalizzare e ottimizzare i cluster per singoli job o per gruppi di job in base alle tue esigenze specifiche. Dataproc ti aiuta a definire rapidamente più cluster, a metterli online e a scalarli in base alle tue esigenze.
I dati nell'esempio vengono spostati da due cluster HDFS on-premise ai bucket Cloud Storage. I dati del primo cluster vengono suddivisi tra più bucket e il secondo cluster viene spostato in un singolo bucket. Puoi personalizzare la struttura dei dati in Cloud Storage in base alle esigenze delle tue applicazioni e della tua attività.
La migrazione di esempio acquisisce gli stati iniziale e finale di una migrazione completa a Google Cloud. Ciò implica un solo passaggio, ma otterrai i risultati migliori se non pensi al passaggio a Google Cloud come a una migrazione completa una tantum. Pensa piuttosto al refactoring delle tue soluzioni per utilizzare un nuovo insieme di strumenti in modi che non erano possibili on-premise. Per eseguire questo tipo di refactoring, consigliamo di eseguire la migrazione in modo incrementale.
Sequenza consigliata per la migrazione a Google Cloud
Di seguito sono riportati i passaggi consigliati per eseguire la migrazione dei flussi di lavoro a Google Cloud:
Sposta prima i dati
- Sposta i dati nei bucket Cloud Storage.
- Inizia in piccolo. Utilizza i dati di backup o archiviati per ridurre al minimo l'impatto sul sistema Hadoop esistente.
Esperimento
- Utilizza un sottoinsieme di dati per testare ed eseguire esperimenti. Crea una prova di concetto su piccola scala per ogni job.
- Prova nuovi approcci per lavorare con i tuoi dati.
- Adattarsi ai Google Cloud paradigmi del cloud computing.
Pensa in termini di cluster temporanei specializzati.
- Utilizza i cluster più piccoli possibili: limitali a singoli job o piccoli gruppi di job strettamente correlati.
- Crea i cluster ogni volta che ti servono per un job ed eliminali quando hai finito.
Utilizza gli Google Cloud strumenti, ove opportuno.
Passaggio a un modello temporaneo
Il cambiamento più grande 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 dai cluster persistenti monolitici ai cluster temporanei specializzati. Puoi avviare un cluster quando devi eseguire un job e quindi eliminarlo una volta completata l'operazione. Le risorse richieste dai tuoi job sono attive solo quando vengono utilizzate, quindi paghi solo per ciò che utilizzi. Questo approccio ti consente di personalizzare le configurazioni del cluster per i singoli job. Poiché non stai manutenendo e configurando un cluster persistente, riduci i costi di utilizzo delle risorse e di amministrazione del cluster.
Questa sezione descrive come passare la tua infrastruttura Hadoop esistente a un modello temporaneo.
Separare i dati dal calcolo
L'utilizzo di Cloud Storage come spazio di archiviazione permanente per i flussi di lavoro presenta i seguenti vantaggi:
- È più facile gestire le autorizzazioni di accesso.
- Si tratta di un file system compatibile con Hadoop (HCFS), quindi è facile da utilizzare con i tuoi job esistenti.
- È più veloce di HDFS in molti casi.
- Richiede meno manutenzione rispetto a HDFS.
- È più facile eseguire la migrazione dei dati rispetto a HDFS.
- Ti consente di utilizzare facilmente i tuoi dati con l'intera gamma di Google Cloud prodotti.
- È molto meno costoso che mantenere i dati in HDFS su un cluster Dataproc persistente.
Con i dati archiviati in modo permanente in Cloud Storage, puoi eseguire i job su cluster Hadoop effimeri gestiti da Dataproc.
In alcuni casi, potrebbe essere più opportuno spostare i dati in un'altra Google Cloud tecnologia, come BigQuery o Bigtable. Tuttavia, la maggior parte dei dati generici dovrebbe essere persistente in Cloud Storage. Ulteriori dettagli su queste opzioni di archiviazione alternative sono forniti più avanti in questa guida.
Eseguire job su cluster temporanei
Dataproc semplifica la creazione ed eliminazione dei cluster, in modo da poter passare dall'utilizzo di un cluster monolitico a quello di molti cluster effimeri. Questo approccio presenta diversi vantaggi:
- Puoi evitare i single point of failure e aumentare l'affidabilità della pipeline di dati. Quando un cluster condiviso a lungo termine presenta uno stato di errore, l'intera pipeline di dati può bloccarsi. La riparazione di un cluster stateful a lungo termine può richiedere molto tempo, causando violazioni dell'obiettivo del livello di servizio (SLO). Al contrario, un cluster temporaneo senza stato problematico può essere facilmente eliminato e poi ricreato con i nuovi tentativi del job.
- Puoi ottenere prestazioni dei job più prevedibili ed evitare violazioni degli SLO eliminando le contese delle risorse tra i job.
- Puoi ottimizzare le configurazioni del cluster e i criteri di scalabilità automatica per i singoli job.
- Puoi ottenere le patch di sicurezza, le correzioni di bug e le ottimizzazioni più recenti quando crei un cluster temporaneo per un job.
- Puoi evitare i problemi comuni dei cluster a lungo termine, ad esempio il riempimento dei dischi con log e file temporanei o la mancata scalabilità del cluster a causa di esaurimento delle scorte nella zona.
- Non è necessario gestire i cluster nel tempo perché i cluster temporanei vengono configurati ogni volta che li utilizzi. Non dover gestire i cluster elimina il carico amministrativo della gestione degli strumenti nei vari job.
- Non è necessario gestire un'infrastruttura separata per lo sviluppo, i test e la produzione. Puoi utilizzare le stesse definizioni per creare tutte le versioni diverse di un cluster di cui hai bisogno.
- Puoi risolvere i problemi più rapidamente con il cluster singolo job isolato.
- Paghi le risorse solo quando vengono utilizzate dai tuoi job.
Puoi utilizzare le azioni di inizializzazione di Dataproc per definire la configurazione dei nodi di un cluster. In questo modo è facile gestire le diverse configurazioni del cluster necessarie per supportare da vicino i singoli job e i gruppi di job correlati. Per iniziare, puoi utilizzare le azioni di inizializzazione di esempio fornite. Gli esempi mostrano come creare le tue azioni di inizializzazione.
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 questo processo:
Crea un cluster configurato in modo adeguato.
Esegui il job, inviando l'output a Cloud Storage o a un'altra località persistente.
Elimina il cluster.
Usa l'output del job secondo le tue necessità.
Visualizza i log in Cloud Logging o Cloud Storage.
Questa procedura è illustrata nel seguente diagramma:
Utilizza cluster persistenti di piccole dimensioni solo se assolutamente necessario
Se non riesci a terminare il lavoro senza un cluster persistente, puoi crearne uno. Questa opzione può essere costosa e non è consigliata se esiste un modo per portare a termine il job su cluster temporanei.
Per ridurre al minimo il costo di un cluster persistente:
- Crea il cluster più piccolo possibile.
- Limita il tuo lavoro su quel cluster al minor numero possibile di job.
- Scala il cluster al numero minimo di nodi utilizzabili, aggiungendone di più in modo dinamico per soddisfare la domanda.
Migrazione incrementale
La migrazione incrementale presenta molti vantaggi. Puoi:
- Isola i singoli job nell'infrastruttura Hadoop esistente dalla complessità insita in 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 man mano che si verificano senza ritardare le attività dipendenti.
- Crea una proof of concept per ogni processo complesso senza influire sul tuo ambiente di produzione.
- Sposta i carichi di lavoro nel modello temporaneo consigliato in modo ponderato e deliberato.
La migrazione è specifica per il tuo ambiente Hadoop, pertanto non esiste un piano universale adatto a tutti gli scenari di migrazione. Crea un piano per la migrazione che ti dia la libertà di tradurre ogni componente in un paradigma di cloud computing.
Ecco una sequenza di migrazione incrementale tipica:
Spostare una parte dei dati in Google Cloud.
Fai esperimenti con questi dati:
Replica i job esistenti che utilizzano i dati.
Crea nuovi prototipi che funzionino con i dati.
Ripeti con altri dati.
Inizia con i dati meno critici. Nelle prime fasi, è un buon approccio utilizzare i dati di backup e gli archivi.
Un tipo di job a rischio ridotto che rappresenta un buon test iniziale è il backfilling tramite l'esecuzione dell'elaborazione a raffica sui dati dell'archivio. Puoi configurare job che colmano le lacune nell'elaborazione dei dati esistenti prima dell'implementazione dei job attuali. Iniziare con i job burst può spesso fornire esperienza con il ridimensionamento suGoogle Cloud all'inizio del piano di migrazione. Questo può essere utile quando inizi a eseguire la migrazione di job più critici.
Il seguente diagramma mostra un esempio di una tipica architettura ibrida di backfill.
L'esempio ha due componenti principali. Innanzitutto, i job pianificati in esecuzione sul cluster on-premise inviano i dati a Cloud Storage tramite un gateway internet. In secondo luogo, i job di backfill vengono eseguiti su cluster Dataproc temporanei. Oltre al backfill, puoi utilizzare i cluster effimeri inGoogle Cloud per la sperimentazione e la creazione di proof of concept per il lavoro futuro.
Pianificazione in vista della migrazione completata
Finora, questa guida ha presupposto 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 sia 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:
- Stai sviluppando sistemi cloud-native, quindi i sistemi esistenti che dipendono da questi devono continuare a funzionare on-premise fino al completamento.
- Hai requisiti aziendali che ti impongono di mantenere i dati on-premise.
- Devi condividere i dati con altri sistemi on-premise che non possono interagire con Google Cloud a causa di limitazioni tecniche o aziendali.
Una soluzione ibrida tipica è composta da quattro parti principali:
Un cluster Hadoop on-premise.
Una connessione dal cluster on-premise a Google Cloud.
Archiviazione centralizzata dei dati in Google Cloud.
Componenti cloud-native che lavorano sui dati in Google Cloud.
Un problema che devi affrontare con una soluzione di cloud ibrido è come mantenere sincronizzati i tuoi sistemi. In altre parole, come farai ad assicurarti che le modifiche apportate ai dati in un luogo si riflettano nell'altro? Puoi semplificare la sincronizzazione facendo distinzioni chiare tra il modo in cui i dati vengono utilizzati nei diversi ambienti.
Ad esempio, potresti avere una soluzione ibrida in cui solo i dati archiviati vengono memorizzati in Google Cloud. Puoi configurare job pianificati per spostare i dati dal cluster on-premise al cloud quando raggiungono una scadenza specificata. Google Cloud Poi puoi configurare tutti i job che utilizzano i dati archiviati in Google Cloud in modo da non dover mai sincronizzare le modifiche ai tuoi cluster on-premise.
Un altro modo per suddividere il sistema è spostare tutti i dati e il lavoro per un progetto o un gruppo di lavoro specifico in Google Cloud mantenendo al contempo il resto del lavoro on-premise. In questo modo, puoi concentrarti sui tuoi job anziché creare sistemi di sincronizzazione dei dati complessi.
Potresti avere problemi di sicurezza o logistica che complicano il modo in cui colleghi il tuo cluster on-premise a Google Cloud. Una soluzione è utilizzare un Virtual Private Cloud collegato alla tua rete on-premise utilizzando Cloud VPN.
Il seguente diagramma mostra un esempio di configurazione del cloud ibrido:
La configurazione di esempio utilizza Cloud VPN per connettere un Google Cloud VPC a un cluster on-premise. Il sistema utilizza Dataproc all'interno della VPC per gestire i cluster permanenti che elaborano i dati provenienti dal sistema on-premise. Ciò potrebbe 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 titolo esemplificativo, l'esempio utilizza Cloud Storage, BigQuery e Bigtable per lo spazio di archiviazione, ovvero 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 effimeri che vengono creati in base alle esigenze nel cloud pubblico. Questi cluster possono essere utilizzati per molte attività, tra cui quelle che raccolgono e trasformano nuovi dati. I risultati di questi lavori vengono archiviati negli stessi servizi di archiviazione utilizzati dai cluster in esecuzione nella VPC.
Progettare 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, eviti completamente la complessità della sincronizzazione dei dati, anche se devi comunque fare attenzione a come i diversi job utilizzano gli stessi dati.
Il seguente diagramma mostra un esempio di sistema cloud-native:
Il sistema di esempio ha alcuni cluster permanenti e alcuni effimeri. Entrambi i tipi di cluster condividono strumenti e risorse cloud, tra cui archiviazione e monitoraggio. Dataproc utilizza immagini macchina standardizzate per definire le configurazioni software sulle VM di un cluster. Puoi utilizzare queste immagini predefinite come base per la configurazione della 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 sulla versione 1.2. Puoi creare nuovi cluster con istanze VM personalizzate ogni volta che ne hai bisogno. In questo modo puoi isolare gli ambienti di test e sviluppo dai job e dai dati di produzione critici.
I cluster temporanei nell'esempio eseguono una serie di job. Questo esempio mostra come Apache Airflow in esecuzione su Compute Engine viene utilizzato per pianificare il lavoro con i cluster effimeri.
Lavorare con i Google Cloud servizi
Questa sezione illustra alcune considerazioni aggiuntive per la migrazione di Hadoop a Google Cloud.
Sostituzione degli strumenti open source con Google Cloud servizi
Google Cloud offre molti prodotti che puoi utilizzare con il tuo sistema Hadoop. L'utilizzo di un prodotto Google Cloud può spesso avere dei vantaggi rispetto all'esecuzione del prodotto open source equivalente in Google Cloud. Scopri i Google Cloud prodotti e i servizi per scoprire l'ampiezza dell'offerta della piattaforma.
Utilizzo di regioni e zone
Dovresti comprendere le ripercussioni della geografia e delle regioni prima di configurare i tuoi dati e job. Molti Google Cloud servizi richiedono di specificare regioni o zone in cui allocare le risorse. La latenza delle richieste può aumentare quando le richieste vengono effettuate da una regione diversa da quella in cui sono archiviate le risorse. Inoltre, se le risorse del servizio e i tuoi dati persistenti 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. Questo può avere un grave impatto sul rendimento.
Configurare l'autenticazione e le autorizzazioni
È probabile che il tuo controllo sulle autorizzazioni nei Google Cloud servizi sia meno granulare di quello a cui sei abituato nel tuo ambiente Hadoop on-premise. Assicurati di comprendere come funziona la gestione dell'accesso in Google Cloud prima di iniziare la migrazione.
Identity and Access Management (IAM) gestisce l'accesso alle risorse cloud. Funziona in base ad 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 Google Cloud servizi fornisce un proprio insieme di ruoli per aiutarti a perfezionare le autorizzazioni. Come parte della procedura di pianificazione della migrazione, devi scoprire come IAM interagisce con Cloud Storage e con Dataproc. Scopri i modelli di autorizzazione di ogni Google Cloud servizio aggiuntivo man mano che lo aggiungi al tuo sistema e valuta come definire i ruoli che funzionano in tutti i servizi che utilizzi.
Monitoraggio dei job con Cloud Logging
I tuoi Google Cloud job inviano i log a Cloud Logging, dove sono facilmente accessibili. Puoi ottenere i log nei seguenti modi:
- Con un'interfaccia grafica basata su browser utilizzando Esplora log nella console Google Cloud.
- Da una finestra del terminale locale utilizzando Google Cloud CLI.
- Da script o applicazioni che utilizzano le librerie client di Cloud per l'API Cloud Logging.
- Chiamando l'API REST Cloud Logging.
Gestire i nodi edge con Compute Engine
Puoi utilizzare Compute Engine per accedere a un nodo edge in un cluster Hadoop Dataproc. Come per la maggior parte dei Google Cloud prodotti, hai a disposizione diverse opzioni di gestione: tramite la console basata sul web, dalla riga di comando e tramite le API web.
Utilizzo dei Google Cloud servizi big data
Cloud Storage è il modo principale per archiviare dati non strutturati in Google Cloud, ma non è l'unica opzione di archiviazione. Alcuni dei tuoi 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 ed elevata scalabilità per adattarsi ai tuoi job.
Puoi utilizzare BigQuery per il data warehousing.
Passaggi successivi
Consulta le altre parti della guida alla migrazione su Hadoop:
Consulta la documentazione di Dataproc.
Consulta una panoramica di Google Cloud.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.