Como usar o Apache Hive no Dataproc

Last reviewed 2022-04-06 UTC

---

Importante: recomendamos o uso do Dataproc Metastore para gerenciar metadados do Hive no Google Cloud do que o legado de fluxo de trabalho descrito no tutorial.

Neste tutorial, mostramos como 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. Essa separação entre 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.

O Hive é um conhecido sistema de armazenamento de dados de código aberto, desenvolvido no Apache Hadoop. O Hive oferece uma linguagem de consulta do tipo SQL, chamada HiveQL, usada para analisar conjuntos de dados grandes e estruturados. O metastore do Hive contém metadados sobre as tabelas do Hive, como o esquema e a localização delas. Quando o MySQL é comumente usado como back-end para o metastore do Hive, o Cloud SQL facilita a configuração, a manutenção, o gerenciamento e a administração dos bancos de dados relacionais no Google Cloud.

Objetivos

• Criar uma instância do MySQL no Cloud SQL para o metastore do Hive.
• Implantar servidores Hive no Dataproc.
• Instalar o Cloud SQL Proxy nas instâncias do cluster do Dataproc.
• Carregar dados do Hive para o Cloud Storage.
• Executar consultas do Hive em vários clusters do Dataproc.

Custos

Neste tutorial, usamos o seguinte componente faturável 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.

Antes de começar

Criar um novo projeto

1. No console do Google Cloud, acesse a página do seletor de projetos.

   Acessar o seletor de projetos

2. Selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

Ativar faturamento

• Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Inicializar o ambiente

1. Inicie uma instância do Cloud Shell:

   Acesse o Cloud Shell

2. No Cloud Shell, defina a zona padrão do Compute Engine como a zona em que os clusters do Dataproc serão criados.

   export PROJECT=$(gcloud info --format='value(config.project)')
   export REGION=REGION
   export ZONE=ZONE
   gcloud config set compute/zone ${ZONE}

   Substitua:

   • REGION: a região em que você quer criar o cluster, como us-central1.
   • ZONE: a zona em que você quer criar o cluster, como us-central1-a.

3. Ative as APIs Admin do Dataproc e do Cloud SQL executando este comando no Cloud Shell:

   gcloud services enable dataproc.googleapis.com sqladmin.googleapis.com

Arquitetura de referência

Para simplificar, neste tutorial, você implanta todos os serviços de computação e armazenamento na mesma região do Google Cloud para minimizar a latência e os custos de transporte da rede. A figura 1 apresenta a arquitetura deste tutorial.

Figura 1. Exemplo de uma arquitetura Hive de região única

Com essa arquitetura, o ciclo de vida de uma consulta do Hive segue estas etapas:

1. O cliente Hive envia uma consulta para um servidor Hive executado em um cluster temporário do Dataproc.
2. O servidor processa a consulta e solicita metadados do serviço metastore.
3. O serviço metastore busca os metadados do Hive do Cloud SQL por meio do Cloud SQL Proxy.
4. O servidor carrega dados do armazenamento do Hive, localizado em um bucket regional no Cloud Storage.
5. O servidor retorna o resultado para o cliente.

Considerações para arquiteturas de várias regiões

Neste tutorial, nosso foco está em uma arquitetura de região única. É possível que uma arquitetura de várias regiões seja considerada se for preciso 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. 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.

Na Figura 2, apresentamos um exemplo de uma arquitetura multirregional.

Figura 2. Exemplo de uma arquitetura Hive multirregional

Como vê, o cenário multirregional é um pouco mais complexo. Para manter a concisão deste tutorial, usamos uma arquitetura de região única.

(Opcional) Como criar o bucket de armazenamento de dados

Se você não tiver um bucket do Cloud Storage para armazenar dados do Hive, crie um bucket de warehouse (é possível executar os seguintes comandos no Cloud Shell) substituindo BUCKET_NAME por um nome de bucket exclusivo:

export WAREHOUSE_BUCKET=BUCKET_NAME
gsutil mb -l ${REGION} gs://${WAREHOUSE_BUCKET}

Como criar a instância do Cloud SQL

Nesta seção, você cria uma nova instância do Cloud SQL que será usada posteriormente para hospedar o metastore do Hive.

No Cloud Shell, crie uma nova instância do Cloud SQL:

gcloud sql instances create hive-metastore \
    --database-version="MYSQL_5_7" \
    --activation-policy=ALWAYS \
    --zone ${ZONE}

Isso pode demorar alguns minutos.

Como criar um cluster do Dataproc

Crie o primeiro cluster do Dataproc, substituindo CLUSTER_NAME por um nome como hive-cluster:

gcloud dataproc clusters create CLUSTER_NAME \
    --scopes sql-admin \
    --region ${REGION} \
    --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
    --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
    --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore" \
    --metadata "enable-cloud-sql-proxy-on-workers=false"

Observações:

• Você fornece o escopo de acesso sql-admin para permitir que as instâncias do cluster acessem a API Admin do Cloud SQL.
• Coloque a ação de inicialização em um script armazenado em um bucket do Cloud Storage e referencie esse bucket com a sinalização --initialization-actions. Para mais informações, consulte Ações de inicialização: considerações e diretrizes importantes.
• Você fornece o URI para o intervalo do armazenamento do Hive na propriedade hive:hive.metastore.warehouse.dir. Isso configura os servidores Hive para ler e gravar no local correto. Essa propriedade precisa conter pelo menos um diretório (por exemplo, gs://my-bucket/my-directory). O Hive não funcionará corretamente se esta propriedade estiver definida como um nome de bucket sem um diretório (por exemplo, gs://my-bucket).
• Especifique enable-cloud-sql-proxy-on-workers=false para garantir que o Cloud SQL Proxy seja executado somente em nós mestres, o que é suficiente para que o serviço metastore Hive funcione e evita cargas desnecessárias no Cloud SQL.

• Você fornece a ação de inicialização do Cloud SQL Proxy que o Dataproc executa automaticamente em todas as instâncias do cluster. Veja o que ocorre com essa ação:

  • Instala o Cloud SQL Proxy.
  • Estabelece uma conexão segura com a instância do Cloud SQL especificada no parâmetro de metadados hive-metastore-instance.
  • Cria o usuário hive e o banco de dados do metastore do Hive.

  Veja o código completo (em inglês)da ação de inicialização do Cloud SQL Proxy no GitHub.

• Para simplificar, neste tutorial usamos apenas uma instância mestre. Para aumentar a resiliência nas cargas de trabalho de produção, considere criar um cluster com três instâncias mestres usando o modo de alta disponibilidade do Dataproc.

• Neste tutorial, usamos uma instância do Cloud SQL com endereço IP público. Se, em vez disso, você usar uma instância com apenas um endereço IP particular, será possível forçar o proxy a usar o endereço IP particular transmitindo o parâmetro --metadata "use-cloud-sql-private-ip=true".

Como criar uma tabela Hive

Nesta seção, você carrega um conjunto de dados de amostra no bucket de armazenamento de dados, cria uma nova tabela Hive e executa algumas consultas do HiveQL nesse conjunto de dados.

1. Copie o conjunto de dados de amostra para o bucket do armazenamento de dados:

   gsutil cp gs://hive-solution/part-00000.parquet \
   gs://${WAREHOUSE_BUCKET}/datasets/transactions/part-00000.parquet

   O conjunto de dados de amostra é compactado no formato Parquet e contém milhares de registros fictícios de transações bancárias, com três colunas: data, valor e tipo de transação.

2. Crie uma tabela Hive externa para o conjunto de dados:

   gcloud dataproc jobs submit hive \
       --cluster CLUSTER_NAME \
       --region ${REGION} \
       --execute "
         CREATE EXTERNAL TABLE transactions
         (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING)
         STORED AS PARQUET
         LOCATION 'gs://${WAREHOUSE_BUCKET}/datasets/transactions';"

Como executar consultas do Hive

É possível usar diferentes ferramentas no Dataproc para executar consultas do Hive. Nesta seção, você aprende como realizar consultas usando as seguintes ferramentas:

• API de jobs do Hive do Dataproc
• Beeline, um conhecido cliente de linha de comando, baseado no SQLLine
• SparkSQL, API do Apache Spark para consultar dados estruturados

Em cada seção, você executa uma consulta de amostra.

Como consultar o Hive com a API Jobs do Dataproc

Execute a seguinte consulta HiveQL simples para verificar se o arquivo parquet está vinculado corretamente à tabela Hive:

gcloud dataproc jobs submit hive \
    --cluster CLUSTER_NAME \
    --region ${REGION} \
    --execute "
      SELECT *
      FROM transactions
      LIMIT 10;"

A saída inclui estes elementos:

+-----------------+--------------------+------------------+
| submissiondate  | transactionamount  | transactiontype  |
+-----------------+--------------------+------------------+
| 2017-12-03      | 1167.39            | debit            |
| 2017-09-23      | 2567.87            | debit            |
| 2017-12-22      | 1074.73            | credit           |
| 2018-01-21      | 5718.58            | debit            |
| 2017-10-21      | 333.26             | debit            |
| 2017-09-12      | 2439.62            | debit            |
| 2017-08-06      | 5885.08            | debit            |
| 2017-12-05      | 7353.92            | authorization    |
| 2017-09-12      | 4710.29            | authorization    |
| 2018-01-05      | 9115.27            | debit            |
+-----------------+--------------------+------------------+

Como fazer uma consulta do Hive com o Beeline

1. Abra uma sessão SSH com a instância mestre do Dataproc (CLUSTER_NAME-m):

   gcloud compute ssh CLUSTER_NAME-m

2. No prompt de comando da instância mestre, abra uma sessão do Beeline:

   beeline -u "jdbc:hive2://localhost:10000"

   Observações:

   • Também é possível fazer referência ao nome da instância mestre como host em vez de localhost:

     beeline -u "jdbc:hive2://CLUSTER_NAME-m:10000"

   • Se estivesse usando o modo de alta disponibilidade com três mestres, você teria que usar o seguinte comando:

     beeline -u "jdbc:hive2://CLUSTER_NAME-m-0:2181,CLUSTER_NAME-m-1:2181,CLUSTER_NAME-m-2:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2"

3. Quando a solicitação do Beeline aparecer, execute a seguinte consulta do HiveQL:

   SELECT TransactionType, AVG(TransactionAmount) AS AverageAmount
   FROM transactions
   WHERE SubmissionDate = '2017-12-22'
   GROUP BY TransactionType;

   A saída inclui estes elementos:

   +------------------+--------------------+
   | transactiontype  |   averageamount    |
   +------------------+--------------------+
   | authorization    | 4890.092525252529  |
   | credit           | 4863.769269565219  |
   | debit            | 4982.781458176331  |
   +------------------+--------------------+

4. Feche a sessão do Beeline:

   !quit

5. Feche a conexão SSH:

   exit

Como fazer uma consulta do Hive com o SparkSQL

1. Abra uma sessão SSH com a instância mestre do Dataproc:

   gcloud compute ssh CLUSTER_NAME-m

2. No prompt de comando da instância mestre, abra uma nova sessão do shell do PySpark:

   pyspark

3. Quando o prompt do shell do PySpark aparecer, digite o seguinte código do Python:

   from pyspark.sql import HiveContext
   hc = HiveContext(sc)
   hc.sql("""
   SELECT SubmissionDate, AVG(TransactionAmount) as AvgDebit
   FROM transactions
   WHERE TransactionType = 'debit'
   GROUP BY SubmissionDate
   HAVING SubmissionDate >= '2017-10-01' AND SubmissionDate < '2017-10-06'
   ORDER BY SubmissionDate
   """).show()

   A saída inclui estes elementos:

   +-----------------+--------------------+
   | submissiondate  |      avgdebit      |
   +-----------------+--------------------+
   | 2017-10-01      | 4963.114920399849  |
   | 2017-10-02      | 5021.493300510582  |
   | 2017-10-03      | 4982.382279569891  |
   | 2017-10-04      | 4873.302702503676  |
   | 2017-10-05      | 4967.696333583777  |
   +-----------------+--------------------+

4. Feche a sessão do PySpark:

   exit()

5. Feche a conexão SSH:

   exit

Como inspecionar o metastore do Hive

Agora você verifica se o metastore do Hive no Cloud SQL contém informações sobre a tabela transactions.

1. No Cloud Shell, inicie uma nova sessão do MySQL na instância do Cloud SQL:

   gcloud sql connect hive-metastore --user=root

   Quando for solicitada a senha do usuário root, não digite nada e pressione a tecla RETURN. Para simplificar este tutorial, você não definiu nenhuma senha para o usuário root. Para conseguir informações sobre como configurar uma senha para proteger ainda mais o banco de dados do metastore, consulte a documentação do Cloud SQL. Na ação de inicialização do Cloud SQL Proxy, também é fornecido um mecanismo para proteger senhas por meio de criptografia. Para ver mais informações, consulte o repositório de códigos (em inglês) da ação.

2. No prompt de comando do MySQL, torne hive_metastore o banco de dados padrão para o restante da sessão:

   USE hive_metastore;

3. Verifique se o local do intervalo do armazenamento de dados está registrado no metastore:

   SELECT DB_LOCATION_URI FROM DBS;

   A saída é assim:

   +-------------------------------------+
   | DB_LOCATION_URI                     |
   +-------------------------------------+
   | gs://[WAREHOUSE_BUCKET]/datasets   |
   +-------------------------------------+

4. Verifique se a tabela está referenciada corretamente no metastore:

   SELECT TBL_NAME, TBL_TYPE FROM TBLS;

   A saída é assim:

   +--------------+----------------+
   | TBL_NAME     | TBL_TYPE       |
   +--------------+----------------+
   | transactions | EXTERNAL_TABLE |
   +--------------+----------------+

5. Verifique se as colunas da tabela também estão referenciadas corretamente:

   SELECT COLUMN_NAME, TYPE_NAME
   FROM COLUMNS_V2 c, TBLS t
   WHERE c.CD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

   A saída é assim:

   +-------------------+-----------+
   | COLUMN_NAME       | TYPE_NAME |
   +-------------------+-----------+
   | submissiondate    | date      |
   | transactionamount | double    |
   | transactiontype   | string    |
   +-------------------+-----------+

6. Verifique se o formato de entrada e o local também estão corretamente referenciados:

   SELECT INPUT_FORMAT, LOCATION
   FROM SDS s, TBLS t
   WHERE s.SD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

   A saída é assim:

   +---------------------------------------------------------------+------------------------------------------------+
   | INPUT_FORMAT                                                  | LOCATION                                       |
   +---------------------------------------------------------------+------------------------------------------------+
   | org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat | gs://[WAREHOUSE_BUCKET]/datasets/transactions |
   +---------------------------------------------------------------+------------------------------------------------+
   

7. Feche a sessão do MySQL:

   exit

Como criar outro cluster do Dataproc

Nesta seção, você criará outro cluster do Dataproc para verificar se é possível que os dados e o metastore do Hive sejam compartilhados entre vários clusters.

1. Crie um novo cluster do Dataproc:

   gcloud dataproc clusters create other-CLUSTER_NAME \
       --scopes cloud-platform \
       --image-version 2.0 \
       --region ${REGION} \
       --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
       --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
       --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore"\
       --metadata "enable-cloud-sql-proxy-on-workers=false"

2. Verifique se o novo cluster pode acessar os dados:

   gcloud dataproc jobs submit hive \
       --cluster other-CLUSTER_NAME \
       --region ${REGION} \
       --execute "
         SELECT TransactionType, COUNT(TransactionType) as Count
         FROM transactions
         WHERE SubmissionDate = '2017-08-22'
         GROUP BY TransactionType;"

   A saída inclui estes elementos:

   +------------------+--------+
   | transactiontype  | count  |
   +------------------+--------+
   | authorization    | 696    |
   | credit           | 1722   |
   | debit            | 2599   |
   +------------------+--------+

Você concluiu o tutorial.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud, siga estas etapas:

• Limpe todos os recursos que você criou para não ser cobrado por eles no futuro. A maneira mais fácil de evitar o faturamento é excluir o projeto criado para o tutorial.
• Como alternativa, exclua os recursos individuais.

Excluir o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Como excluir recursos individuais

Execute os seguintes comandos no Cloud Shell para excluir recursos individuais em vez de excluir todo o projeto:

gcloud dataproc clusters delete CLUSTER_NAME --region ${REGION} --quiet
gcloud dataproc clusters delete other-CLUSTER_NAME --region ${REGION} --quiet
gcloud sql instances delete hive-metastore --quiet
gsutil rm -r gs://${WAREHOUSE_BUCKET}/datasets

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.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.