Testando o Hadoop/Hive no próprio computador, apesar dos apesares

7 min readMar 14, 2022

No mundo de big data temos alguns problemas relacionados ao estudo fora de algum ambiente de cloud (como AWS/Google/Azure/IBM):

Velocidade das mudanças: ainda que a teoria se mantenha relativamente a mesma, o layout das coisas muda bastante em um espaço de meses. Sabe um passo-a-passo que você seguiu ano passado? Hoje já não é mais válido, porque remodelaram tudo. Lembra de uma tela verde com dois botões? Agora é azul, e tem 25 botões.
Tendências: tanto o Hadoop como o Spark são frameworks open-source extremamente usados em empresas [1]. Ou seja: tem empresa que pode usar Spark e tem empresa que pode usar o Hadoop. Ou, ainda, empresa que usa os dois. São formas diferentes de se trabalhar com os dados, mas que compartilham de fundamentos semelhantes. Olhe só a imagem abaixo para comprovar isso [2]: a primeiro momento, o Spark está sendo o mais usado, não é? Porém, olhe a imagem por região: dependendo do país, o Hadoop é o mais utilizado — em outros, o Spark.

Apache Hadoop, Apache Spark — Explore — Google Trends [2]

3. Custo: existem várias empresas que oferecem serviços em Hadoop para… bom, outras empresas [3]. A lista inclui gigantes como Amazon (AWS), Azure, Huawei, IBM, Oracle e Cloudera. O problema é que o foco de uma solução de Big Data não é no estudante que está trabalhando com aquilo em seu próprio computador, mas sim em empresas que irão pagar um valor considerável por um produto. A única empresa que fornece (fornecia) algo assim é (era) a Cloudera, mas a sua solução (o Hortonworks Data Platform Sandbox) não recebe atualizações há um tempo e, ainda, novas integrações precisam ser pagas [4, 5]. Ainda que sob um ponto de vista de aprendizagem ainda seja possível utilizar o Sandbox uma vez que as técnicas e teorias se mantém, isto permanece sendo um desafio.

4. Recursos: na maioria das vezes, trabalhar com big data requer alocar um bom espaço de memória e espaço em seu próprio computador, o que muitos não poderiam dispor em um dado momento.

Uma alternativa

Existe uma alternativa para tal — mais especificamente, há um repositório no Github (big-data-europe/docker-hive) [6] para ajudar nos testes. A arquitetura é semelhante ao que é oferecido por outras soluções, mas requer menos memória do computador.

Como primeiro passo, instale o Docker no seu computador. Caso não tenha instalado, sugiro que siga um tutorial que criei para tal [7].
Assim que o Docker estiver rodando, baixe o repositório contendo as informações para construir a imagem do Docker no nosso computador [6].
Extraia o conteúdo do arquivo zip em uma pasta. No meu caso, eu deixei no C:/docker-hadoop-master:

Naturalmente, você poderá deixar isto em qualquer outra pasta do seu computador. Aqui é só um exemplo, beleza?

Aí, abri o prompt de comando/terminal e naveguei até esta pasta:

Navegando até a pasta onde baixamos (e extraímos) o conteúdo daquele zip.

Depois, rodei o seguinte comando:

docker-compose up -d

O docker-compose executará vários containers que estão definidos dentro desta pasta. Cada um deles possui uma atuação:

Hive Server: é o servidor que possibilita que rodemos queries em SQL usando o Hive;
Presto Coordinator: é o responsável por gerenciar as atividades das queries escritas em SQL quando temos mais de um servidor. Ou seja, é ele que ajuda a distribuir a carga de trabalho entre diferentes servidores que estejam trabalhando com múltiplos usuários e queries ao mesmo tempo caso estejamos usando a engine do Presto para tal. Existem outras engines que também prestam o mesmo tipo de trabalho;
Hive Metastore PostgreSQL e Hive Metastore: são eles que guardam os metadados relacionados à base de dados (por exemplo: lista de colunas que uma tabela possui ou o nome das tabelas).
History Server: é do MapReduce, e ajuda a prover informações das aplicações que foram finalizadas dentro do Hadoop;
NameNode: é um servidor que gerencia os arquivos e os seus acessos para os outros containers.
DataNode: é outro servidor que gerencia os pedidos de leitura e escrita dos arquivos para os outros containers.

Ao rodar o comando acima, note que os containers foram disponibilizados e inicializados para você (veja as últimas linhas principalmente: há o “Container [nome do container]: Started” que indica isto.

Aqui, um contexto importante: serei simplista na explicação para ser mais acessível na mesma, beleza?

Quando trabalhamos com bancos de dados relacionais “normais” (como o MySQL, PostgreSQL, SQL Server, entre outros) as informações são salvas diretamente no banco de dados. Quer cadastrar um novo usuário? Faça um INSERT. Quer atualizar? UPDATE. Remover? DELETE. Veja que todas estas operações ocorrem dentro do banco de dados, sempre. Você não enxerga arquivos sendo alterados ou algo do tipo.
Quando trabalhamos no Hadoop é um pouco diferente: temos arquivos que são armazenados em um local (imagine um Dropbox/Google Drive onde salvamos vários arquivos contendo os dados que queremos processar): este é o HDFS. Sobre o HDFS temos o Hive, que permite fazer consultas nos arquivos usando a sintaxe do SQL. Já imaginou pegar todos os arquivos do seu computador e fazer buscas de qualquer coisa com o SQL? É algo parecido com isso. Observe a imagem abaixo: veja como o HDFS é a base para os itens que vem acima, como o próprio Hive.

Importante: vale reforçar que estou sendo simplista nesta explicação — naturalmente não é exatamente assim que as coisas funcionam, mas entendo que a analogia mesmo assim se aplica.

Bom, mas e aí? E os próximos passos? Os containers já estão rodando. Vamos rodar o seguinte comando:

docker ps

Veja que todos os containers estão rodando. Preste atenção na coluna PORTS: ela informa qual é a porta de acesso para cada um dos containers. Na imagem abaixo é possível ver que as listagens para o meu caso estão assim:

prestodb: porta 8080
datanode: porta 50075
namenode: porta 50070
metastore (PostgreSQL): porta 5432
metastore: portas 10000, 9083 e 10002
servidor: portas 10000 e 10002

Hora de testar

Agora que tudo inicializou, é hora de testar o Hive. Vou executar o seguinte comando:

docker-compose exec hive-server bash

Este comando irá acessar o servidor do Hive e abrir o terminal de dentro do servidor. Ou seja: estaremos conectados dentro do servidor para fazer quaisquer operações necessárias. Ah, e um lembrete: até aqui, fiz tudo no Windows. Naturalmente, todas estas operações do Docker também são compatíveis com Linux e Mac.

Esta segunda linha indica que o servidor está pronto para inserirmos as nossas queries.

Agora, copiarei o seguinte comando:

/opt/hive/bin/beeline -u jdbc:hive2://localhost:10000

Colarei isto lá no prompt de comando/terminal. Você verá que o Ctrl-V não funciona. Não se preocupe: somente clique com o botão direito no campo e ele colará para você.

Como ficou após colar o comando.

Ao apertar Enter você já poderá inserir suas queries em sintaxe de SQL. Vamos com um exemplo da própria documentação:

CREATE TABLE pokes (foo INT, bar STRING);
LOAD DATA LOCAL INPATH '/opt/hive/examples/files/kv1.txt' OVERWRITE INTO TABLE pokes;

Aqui fazemos duas operações: primeiro, criamos uma tabela com duas colunas. Depois, carregamos um arquivo contendo vários dados. Este LOCAL DATA LOCAL INPATH garante que estaremos inserindo, de uma vez só, todo o conteúdo deste arquivo. Lembre-se da imagem acima do ecossistema do Hadoop: agora, estamos operando no Hive (camada SQL). Por baixo, existe um sistema de arquivos do HDFS que está gerenciando todos os arquivos utilizados por ele.

O que acha de testar uma seleção? Um SELECT * FROM pokes LIMIT 10; só para selecionar os 10 primeiros dados? Olha só:

E aí? Espero que tenha conseguido reproduzir estes mesmos passos por aí. Sei que isto pode parecer muuuuito mais complexo do que somente instalar o PostgreSQL/MariaDB/MySQL/qualquer outra implementação para testar no seu computador a troco de nada: afinal de contas, seria os mesmos SELECT/INSERT/CREATE, não é?

Contudo, lembre-se que este tipo de aplicação possui uma engenharia por trás cujo objetivo é otimizar o trabalho de manipulação de dados em aplicações de big data: logo, estamos falando de múltiplos usuários em paralelo com uma grande quantidade de dados sendo tratada, movida e manipulada ao mesmo tempo. Por isso, no nosso computador não vemos de fato tanta diferença.

Dito isso, também sugiro conhecer também o Spark na devida oportunidade, caso isto seja de seu interesse.

Até logo! 🖐