Utilizzo di Apache Hive su Dataproc

Last reviewed 2023-05-08 UTC

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 è rivolto ad architetti cloud e data engineer interessati al deployment di Apache Hive su Dataproc e Hive Metastore in Cloud SQL.

Il seguente diagramma mostra il ciclo di vita di una query Hive.

Diagramma di un'architettura a regione singola.

Nel diagramma, il ciclo di vita di una query Hive segue questi passaggi:

  1. Il client Hive invia una query a un server Hive in esecuzione in un cluster Dataproc temporaneo.
  2. Il server Hive elabora la query e richiede i metadati dal servizio metastore.
  3. Il servizio Metastore recupera i metadati Hive da Cloud SQL tramite il proxy Cloud SQL.
  4. Il server Hive carica i dati dal magazzino Hive situato in un bucket regionale in Cloud Storage.
  5. Il server Hive restituisce il risultato al client.

Alternative di design

La sezione seguente presenta una potenziale alternativa di progettazione per questa architettura.

Architettura multiregionale

Valuta la possibilità di utilizzare un'architettura multiregionale se devi eseguire server Hive in diverse regioni geografiche. In questo caso, devi creare cluster Dataproc separati dedicati all'hosting del servizio Metastore e che si trovino nella stessa regione dell'istanza Cloud SQL.

A volte il servizio metastore può inviare volumi elevati di richieste al database MySQL, pertanto è fondamentale mantenere il servizio metastore geograficamente vicino al database MySQL per ridurre al minimo l'impatto sulle prestazioni. In confronto, il server Hive in genere invia molte meno richieste al servizio metastore. Pertanto, può essere più accettabile che il server Hive e il servizio metastore si trovino in regioni diverse nonostante l'aumento della latenza.

Il servizio metastore può essere eseguito solo sui nodi master di 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 un cluster a un solo nodo per il servizio metastore. Per ottenere un'alta disponibilità, puoi creare più cluster a un solo nodo.

Il proxy Cloud SQL deve essere installato solo sui cluster dei servizi Metastore, perché solo questi devono connettersi direttamente all'istanza Cloud SQL. I server Hive rimandano quindi ai cluster di servizi del metastore impostando la hive.metastore.uris proprietà sull'elenco separato da virgole di URI. Ad esempio:

thrift://metastore1:9083,thrift://metastore2:9083

Puoi anche valutare la possibilità di utilizzare un bucket a due regioni o multiregione se è necessario accedere ai dati Hive da server Hive situati in più località. La scelta tra i diversi tipi di località del bucket dipende dal caso d'uso. Devi trovare un equilibrio tra latenza, disponibilità e costi.

Il seguente diagramma mostra un esempio di architettura multiregionale.

Diagramma di un'architettura Hive multiregionale.

Come puoi vedere, lo scenario multiregionale è leggermente più complesso e molto più solido. La guida all'implementazione di questa architettura di riferimento utilizza uno scenario a una sola regione.

Vantaggi di un'architettura multiregionale

La separazione delle risorse di calcolo e archiviazione offre alcuni vantaggi:

  • Flessibilità e agilità: puoi personalizzare le configurazioni dei cluster per carichi di lavoro Hive specifici e scalare ogni cluster indipendentemente verso l'alto e verso il basso in base alle esigenze.
  • Risparmio sui costi: puoi avviare un cluster temporaneo quando devi eseguire un job Hive ed eliminarlo al termine del job. Le risorse richieste dai tuoi job sono attive solo quando vengono utilizzate, quindi paghi solo per ciò che utilizzi. Puoi anche utilizzare le VM prerilasciabili per l'elaborazione di 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 principale. Per aumentare la resilienza nei carichi di lavoro di produzione, ti consigliamo di creare un cluster con tre istanze master utilizzando la modalità di 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 Google Cloud utenti potrebbero avere diritto a una prova gratuita.

Deployment

Per eseguire il deployment di questa architettura, consulta Eseguire il deployment di Apache Hive su Dataproc.

Passaggi successivi