Esta arquitetura de referência descreve os benefícios de usar o Apache Hive no Dataproc de maneira eficiente e flexível, armazenando dados do Hive no Cloud Storage e hospedando o metastore do Hive em um banco de dados MySQL no Cloud SQL.
Este documento é destinado a arquitetos de nuvem e engenheiros de dados interessados em implantar o Apache Hive no Dataproc e o metastore Hive no Cloud SQL.
Arquitetura
O diagrama a seguir mostra o ciclo de vida de uma consulta do Hive.
No diagrama, o ciclo de vida de uma consulta do Hive segue estas etapas:
- O cliente Hive envia uma consulta para um servidor Hive executado em um cluster temporário do Dataproc.
- O servidor Hive processa a consulta e solicita metadados do serviço metastore.
- O serviço metastore busca os metadados do Hive do Cloud SQL por meio do Cloud SQL Proxy.
- O servidor Hive carrega dados do armazenamento do Hive, localizado em um bucket regional no Cloud Storage.
- O servidor retorna o resultado para o cliente.
Alternativas de design
A seção a seguir apresenta uma possível alternativa de design para essa arquitetura.
Arquitetura multirregional
Considere usar uma arquitetura multirregional se precisar executar servidores Hive em diferentes regiões geográficas. Nesse caso, crie clusters separados do Dataproc dedicados a hospedar o serviço de metastore e que residam na mesma região da instância do Cloud SQL.
Às vezes, grandes volumes de solicitações podem ser enviados pelo serviço metastore ao banco de dados MySQL. Portanto, é essencial manter o serviço de metastore geograficamente próximo ao banco de dados MySQL para proteger o desempenho e minimizar o impacto. Em comparação, o servidor Hive geralmente envia muito menos solicitações para o serviço metastore. Portanto, pode ser mais aceitável que o servidor Hive e o serviço metastore residam em regiões diferentes, mesmo que a latência aumente.
O serviço metastore pode ser executado apenas em nós mestres do Dataproc, não em nós de trabalho. O Dataproc impõe no mínimo dois nós de trabalho em clusters padrão e em clusters de alta disponibilidade.
Para evitar o desperdício de recursos em nós de trabalho não utilizados, crie um cluster de nó único para o serviço metastore. Para conseguir alta disponibilidade, crie vários clusters de nó único.
O proxy do Cloud SQL precisa ser instalado somente nos clusters de serviço do metastore, porque somente os clusters de serviço do metastore precisam se conectar diretamente à instância do Cloud SQL. Em seguida, os servidores do Hive apontam para os clusters de serviço do metastore definindo a propriedade hive.metastore.uris como a lista de URIs separados por vírgula. Por exemplo:
thrift://metastore1:9083,thrift://metastore2:9083
Também é possível considerar o uso de um bucket birregional ou multirregional se os dados do Hive precisarem ser acessados nos servidores Hive, localizados em vários locais. A escolha entre diferentes tipos de locais de buckets depende do seu caso de uso. Você precisa equilibrar os custos de latência e disponibilidade.
O diagrama a seguir mostra um exemplo de arquitetura multirregional.
Como você pode ver, o cenário multirregional é um pouco mais complexo e muito mais robusto. O guia de implantação para esta arquitetura de referência usa um cenário de região única.
Vantagens de uma arquitetura multirregional
A separação de recursos de computação e armazenamento oferece algumas vantagens:
- Flexibilidade e agilidade: é possível personalizar configurações de cluster para cargas de trabalho específicas do Hive e escalonar cada cluster de maneira independente para mais ou para menos, conforme necessário.
- Economia de custos: é possível criar um cluster efêmero quando for preciso executar um job do Hive e excluí-lo quando o job for concluído. Os recursos que seu job exige ficam ativos somente quando estão sendo usados, então você paga apenas pelo que usa. Também é possível usar VMs preemptivas para processamento de dados não críticos ou criar clusters muito grandes com um custo total menor.
- Resiliência: para simplificar, esta arquitetura de referência usa apenas uma instância mestre. Para aumentar a resiliência nas cargas de trabalho de produção, pense na criação de um cluster com três instâncias mestres usando o modo de alta disponibilidade do Dataproc.
Otimização de custos
Esta arquitetura de referência e implantação usa os seguintes componentes faturáveis do Google Cloud:
- Dataproc
- Cloud Storage
- Cloud SQL
Use a calculadora de preços para gerar uma estimativa de custo com base no uso previsto.
Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.
Implantação
Para implantar essa arquitetura, consulte Implantar o Apache Hive no Dataproc.
A seguir
- Teste o BigQuery, o armazenamento de dados corporativo de custo reduzido do Google, altamente escalonável e sem servidor.
- Confira este guia sobre como migrar cargas de trabalho do Hadoop para o Google Cloud.
- Confira esta ação de inicialização para mais detalhes sobre como usar o HCatalog do Hive no Dataproc.
- Aprenda a configurar o Cloud SQL para alta disponibilidade e aumentar a confiabilidade do serviço.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.