Questa architettura di riferimento descrive i vantaggi dell'utilizzo di Apache Hive su Dataproc in modo efficiente e flessibile archiviando i dati Hive in Cloud Storage e ospitando il metastore Hive in un database MySQL su Cloud SQL.
Questo documento è destinato ai Cloud Architect e ai data engineer interessati al deployment di Apache Hive su Dataproc e Hive Metastore in Cloud SQL.
Architettura
Il seguente diagramma mostra il ciclo di vita di una query Hive.
Nel diagramma, il ciclo di vita di una query Hive segue questi passaggi:
- Il client Hive invia una query a un server Hive che viene eseguito in un cluster Dataproc temporaneo.
- Il server Hive elabora la query e richiede i metadati al servizio metastore.
- Il servizio Metastore recupera i metadati Hive da Cloud SQL tramite il proxy Cloud SQL.
- Il server Hive carica i dati dal warehouse Hive che si trova in un bucket a livello di regione in Cloud Storage.
- Il server Hive restituisce il risultato al client.
Alternative di progettazione
La seguente sezione presenta una potenziale alternativa di progettazione per questa architettura.
Architettura multiregionale
Prendi in considerazione l'utilizzo di un'architettura multiregionale se devi eseguire server Hive in regioni geografiche diverse. In questo caso, devi creare cluster Dataproc separati dedicati all'hosting del servizio metastore e che risiedono nella stessa regione dell'istanza Cloud SQL.
A volte il servizio metastore può inviare elevati volumi di richieste al database MySQL, quindi è fondamentale mantenere il servizio metastore geograficamente vicino al database MySQL per ridurre al minimo l'impatto sulle prestazioni. In confronto, il server Hive invia in genere molte meno richieste al servizio metastore. Pertanto, è più accettabile che il server Hive e il servizio metastore risiedano in regioni diverse nonostante la maggiore latenza.
Il servizio metastore può essere eseguito solo sui nodi master Dataproc, non sui nodi worker. Dataproc applica un minimo di due nodi worker nei cluster standard e nei cluster ad alta disponibilità.
Per evitare di sprecare risorse su nodi worker inutilizzati, puoi creare invece un cluster a nodo singolo per il servizio metastore. Per ottenere un'alta disponibilità, puoi creare più cluster a nodo singolo.
Il proxy Cloud SQL deve essere installato solo sui cluster di servizio metastore, poiché solo i cluster di servizio metastore devono connettersi direttamente all'istanza Cloud SQL. I server Hive puntano quindi ai cluster di servizi del metastore impostando la proprietà hive.metastore.uris sull'elenco di URI separati da virgole. Ad esempio:
thrift://metastore1:9083,thrift://metastore2:9083
Puoi anche valutare la possibilità di utilizzare un bucket con due o più regioni se i dati Hive devono essere accessibili da server Hive che si trovano in più località. La scelta tra i diversi tipi di località dei bucket dipende dal caso d'uso specifico. Devi trovare un equilibrio tra latenza, disponibilità e costi.
Il seguente diagramma mostra un esempio di architettura per più regioni.
Come puoi notare, lo scenario multiregionale è leggermente più complesso e molto più solido. La guida al deployment per questa architettura di riferimento utilizza uno scenario con una singola regione.
Vantaggi di un'architettura multiregionale
La separazione delle risorse di calcolo e di archiviazione offre alcuni vantaggi:
- Flessibilità e agilità: puoi personalizzare le configurazioni dei cluster per carichi di lavoro Hive specifici e scalare ogni cluster in modo indipendente, a seconda delle esigenze.
- Risparmio sui costi: puoi avviare un cluster temporaneo quando devi eseguire un job Hive e poi eliminarlo al termine del job. Le risorse richieste dai job sono attive solo quando vengono utilizzate, quindi paghi solo per ciò che utilizzi. Puoi anche utilizzare le VM prerilasciabili per l'elaborazione dei dati non critici o per creare cluster di grandi dimensioni a un costo totale inferiore.
- Resilienza: per semplicità, questa architettura di riferimento utilizza una sola istanza master. Per aumentare la resilienza nei carichi di lavoro di produzione, ti consigliamo di creare un cluster con tre istanze master utilizzando la modalità ad alta disponibilità di Dataproc.
Ottimizzazione dei costi
Questa architettura di riferimento e questo deployment utilizzano i seguenti componenti fatturabili di Google Cloud:
- Dataproc
- Cloud Storage
- Cloud SQL
Puoi utilizzare il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.
I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.
Deployment
Per eseguire il deployment di questa architettura, vedi Eseguire il deployment di Apache Hive su Dataproc.
Passaggi successivi
- Prova BigQuery, il data warehouse aziendale serverless, a scalabilità elevata e dai costi contenuti di Google.
- Consulta questa guida sulla migrazione dei carichi di lavoro Hadoop a Google Cloud.
- Controlla questa azione di inizializzazione per ulteriori dettagli su come utilizzare Hive HCatalog su Dataproc.
- Scopri come configurare Cloud SQL per l'alta disponibilità al fine di aumentare l'affidabilità del servizio.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.