Questa guida fornisce una panoramica su come spostare Apache Hadoop on-premise in 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. Inoltre, introduce alcuni concetti fondamentali che devi comprendere per tradurre la configurazione di Hadoop su 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.
- Migrazione dei dati HDFS dall'infrastruttura on-premise a Google Cloud fornisce un contesto aggiuntivo per lo spostamento incrementale dei dati in Google Cloud.
- Migrazione dei dati da HBase a Bigtable
- Migrazione di job Hadoop da on-premise a Dataproc descrive il processo di esecuzione dei job su Dataproc e altri Google Cloud.
Vantaggi della migrazione a Google Cloud
L'uso di Google Cloud può farti risparmiare tempo in molti modi, denaro e sforzi rispetto all'uso 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 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 del lavoro viene gestito automaticamente Controllo delle versioni di Dataproc.
Configurazione flessibile dei job
Una tipica configurazione Hadoop on-premise utilizza un unico cluster che gestisce molti scopi. Quando passi a Google Cloud, puoi concentrarti sulle singole attività, creando tutti i cluster di cui hai bisogno. Ciò elimina gran parte delle la complessità di gestire un unico cluster con dipendenze crescenti e interazioni con la configurazione software.
Pianificazione della migrazione
La migrazione da una soluzione Hadoop on-premise a Google Cloud richiede un cambiamento 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 l'elaborazione più efficiente in Google Cloud con il costo minimo, Occorre ripensare il modo di strutturare i dati e i lavori.
Poiché Dataproc esegue Hadoop su Google Cloud, utilizzando un cluster Dataproc permanente per replicare la tua 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 prodotti Google Cloud.
- L'aumento 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 particolari.
- L'utilizzo di un singolo cluster Dataproc permanente per i tuoi job più difficile da gestire rispetto al passaggio a cluster mirati che gestiscono singole offerte di lavoro o settori di lavoro.
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 in un modello temporaneo su Google Cloud.
L'esempio sposta quattro job eseguiti su due cluster on-premise 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 job ciascuno vengono eseguiti sul proprio cluster. Quando esegui la migrazione dei tuoi job, puoi personalizzare ottimizzare i cluster per singoli job o per gruppi di job in base alle esigenze il tuo lavoro specifico. Dataproc consente di definire rapidamente di archiviazione, portarli online e scalarli in base alle tue esigenze.
I dati dell'esempio vengono spostati da due cluster HDFS on-premise di archiviazione dei bucket Cloud Storage. I dati del primo cluster vengono suddivisi in 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 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
Ecco i passaggi consigliati per eseguire la migrazione dei tuoi flussi di lavoro su Google Cloud:
Sposta prima i dati
- Spostare i dati nei bucket Cloud Storage.
- Inizia con pochi utenti. Utilizza i dati di backup o archiviati per ridurre al minimo l'impatto sul sistema Hadoop esistente.
Esperimento
- Utilizza un sottoinsieme di dati per eseguire test ed esperimenti. Crea una prova di concetto su piccola scala per ogni job.
- Prova nuovi approcci all'utilizzo dei dati.
- Adattarsi ai paradigmi di Google Cloud e del cloud computing.
Pensa in termini di cluster temporanei e specializzati.
- Utilizza i cluster più piccoli possibili: limitali a singoli job o piccoli gruppi di job strettamente correlati.
- Crea cluster ogni volta che ne hai bisogno per un job ed eliminali al termine dell'operazione.
Utilizza gli strumenti Google Cloud 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. Tu avvia un cluster quando devi eseguire un job e poi lo elimina quando vengono completate. 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. Perché non sei la manutenzione e la configurazione di un cluster permanente, riduci i costi l'uso delle risorse e l'amministrazione del cluster.
Questa sezione descrive come spostare l'infrastruttura Hadoop esistente un modello temporaneo.
Separa 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 job esistenti.
- In molti casi è più veloce di HDFS.
- 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 Google Cloud.
- È molto meno costoso che conservare i dati in HDFS su un un cluster Dataproc permanente.
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 tecnologia Google Cloud, come BigQuery o Bigtable. Tuttavia, la maggior parte dei dati per uso generico dovrebbe rimanere di archiviazione ideale in Cloud Storage. Puoi trovare ulteriori dettagli su queste opzioni di archiviazione alternative 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 avere prestazioni dei job più prevedibili ed evitare le violazioni degli SLO delle risorse tra i job.
- Puoi ottimizzare le configurazioni dei cluster e i criteri di scalabilità automatica i singoli lavori.
- Puoi ricevere le patch di sicurezza, le correzioni di bug e le ottimizzazioni più recenti quando crei un cluster temporaneo per un job.
- Puoi evitare problemi comuni con i cluster a lunga esecuzione, ad esempio i dischi che ricevono Il cluster non è riempito di log e file temporanei oppure non riesce a fare lo scale up. a causa di esaurimento scorte nella zona.
- Non è necessario gestire i cluster nel tempo perché le istanze 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 mantenere un'infrastruttura separata per lo sviluppo, test e 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 per le risorse solo quando i tuoi job le utilizzano.
Puoi utilizzare le azioni di inizializzazione di Dataproc per definire la configurazione dei nodi di un cluster. In questo modo è facile mantenere le diverse configurazioni del cluster che devi supportare singoli lavori e gruppi di lavori 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 permanenti di piccole dimensioni solo quando assolutamente necessario
Se non riesci a svolgere il tuo lavoro senza un cluster permanente, puoi creare uno. Questa opzione può essere costosa e non è consigliata se esiste un modo per il tuo lavoro sui 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 la complessità intrinseca in un ambiente maturo.
- Esaminare ogni job in modo isolato per valutarne le esigenze e determinare il percorso migliore per la migrazione.
- Gestisci i problemi imprevisti nel momento in cui si presentano senza ritardare le attività dipendenti.
- Crea una proof of concept per ogni processo complesso senza influire sul tuo ambiente di produzione.
- Sposta i tuoi 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. Prepara un piano per la migrazione che offre la libertà di tradurre ogni pezzo in un paradigma di cloud computing.
Ecco una tipica sequenza di migrazione incrementale:
Spostare una parte dei tuoi 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 l'operazione aggiungendo altri dati.
Inizia con i dati meno critici possibili. 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 lavori che colmano le lacune per i dati esistenti prima dell'applicazione dei job attuali. Iniziare con i job burst può spesso fornire esperienza con il ridimensionamento su Google Cloud all'inizio del piano di migrazione. Questo può aiutarti quando iniziare 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 un cluster on-premise esegue il push dei dati a Cloud Storage tramite una connessione gateway VPN ad alta disponibilità. Secondo, i job di backfill vengono eseguiti su Dataproc temporaneo cluster. Oltre al backfill, puoi utilizzare i cluster temporanei in Google Cloud per la sperimentazione e la creazione di proof of concept per le attività future.
Pianificare tenendo presente la 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 in esecuzione completamente su Google Cloud è più facile da gestire rispetto a uno che gestisce sia nel cloud e 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 per sviluppare sistemi cloud-native, quindi le applicazioni che dipendono da essi devono continuare a essere eseguiti on-premise completato.
- Hai requisiti aziendali per mantenere i tuoi dati on-premise.
- Devi condividere i dati con altri sistemi che vengono eseguiti on-premise sistemi non possono interagire con Google Cloud a causa di problemi tecnici restrizioni aziendali.
Una tipica soluzione ibrida ha 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 vi assicuri che le modifiche apportate ai dati si riflette 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 vengono archiviati in Google Cloud. Puoi configurare job pianificati per spostare i dati dal cluster on-premise a Google Cloud quando raggiungono una scadenza specificata. Puoi quindi configurare tutti i job che funzionano in Google Cloud, così non dovrai mai sincronizzare le modifiche nei 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 su 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 logistici che complicano il modo in cui comunichi del tuo cluster on-premise a Google Cloud. Una soluzione è utilizzare Virtual Private Cloud connesso alla rete on-premise Cloud VPN.
Il seguente diagramma mostra un esempio di configurazione del cloud ibrido:
La configurazione di esempio utilizza Cloud VPN per connettere un VPC Google Cloud a per un cluster on-premise. Il sistema utilizza Dataproc all'interno del VPC per gestire i cluster permanenti che elaborano i dati provenienti da reti on-premise di un sistema operativo completo. Ciò potrebbe comportare la sincronizzazione dei dati tra i sistemi. Quelli anche i cluster Dataproc permanenti trasferiscono i dati provenienti on-premise ai servizi di archiviazione appropriati in Google Cloud. A scopo illustrativo, l'esempio utilizza Cloud Storage, BigQuery e Bigtable per l'archiviazione: sono 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 vengono create secondo necessità 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 diversi tipi di cluster condividono strumenti e risorse cloud, tra cui archiviazione e il monitoraggio. Dataproc utilizza immagini macchina standardizzate per definire le configurazioni software sulle VM di un cluster. Puoi utilizzare questi 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 unico 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 test e sviluppo da dati di produzione e job critici.
I cluster temporanei nell'esempio eseguono una serie di job. Questo esempio mostra Apache Airflow in esecuzione su Compute Engine utilizzato per pianificare le operazioni con di cluster temporanei.
Utilizzo dei servizi Google Cloud
Questa sezione illustra alcune considerazioni aggiuntive per la migrazione di Hadoop a in 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 spesso offre vantaggi rispetto che esegue il prodotto open source equivalente in Google Cloud. Scopri di più sui prodotti e i servizi Google Cloud per scoprire tutto ciò che la piattaforma ha da offrire.
Utilizzo di regioni e zone
Sii consapevole delle ripercussioni area geografica e regioni prima di configurare dati e job. Molti servizi Google Cloud 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 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. Questo può avere un grave impatto sul rendimento.
Configurare l'autenticazione e le autorizzazioni
È probabile che il tuo controllo sulle autorizzazioni nei servizi Google Cloud sia meno granulare rispetto a quanto abitualmente nel tuo servizio Hadoop on-premise. completamente gestito di Google Cloud. Prima di iniziare la migrazione, assicurati di comprendere come funziona la gestione dell'accesso in Google Cloud.
Identity and Access Management (IAM) e gestire 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 servizi Google Cloud offre un proprio insieme di ruoli per aiutarti a perfezionare le autorizzazioni. Come parte del processo di pianificazione della migrazione, dovresti scoprire come IAM interagisce con Cloud Storage e con Dataproc. Scopri i modelli di autorizzazione di ogni servizio Google Cloud aggiuntivo mentre lo aggiungi al tuo sistema e valuta come definire i ruoli che funzionano tra i servizi che utilizzi.
Monitoraggio dei job con Cloud Logging
I tuoi job Google Cloud inviano i relativi log a Cloud Logging, dove i log 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 il metodo API REST Cloud Logging.
Gestione dei nodi perimetrali con Compute Engine
Puoi utilizzare Compute Engine per accedere a un nodo perimetrale in una di un cluster Dataproc Hadoop. Come per la maggior parte dei servizi Google Cloud, prodotti, hai a disposizione più opzioni di gestione: tramite l'interfaccia dalla riga di comando e tramite le 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 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 e elevata scalabilità per adattarsi alle per i tuoi lavori.
Per il data warehousing, puoi utilizzare BigQuery.
Passaggi successivi
Consulta le altre parti della guida alla migrazione di 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.