CENTRO UNIVERSITÁRIO ESTADUAL DA ZONA OESTE

Unidade Universitária de Computação

Curso de Bacharelado em Ciência da Computação

ANÁLISE DE GRANDES MASSAS DE DADOS POR MEIO DE

TÉCNICAS DE BIG DATA

GABRIEL MATTOS DINIZ LUCAS

Rio de Janeiro,
Brasil 2018.

1
 GABRIEL MATTOS DINIZ LUCAS

ANÁLISE DE GRANDES MASSAS DE DADOS POR MEIO DE

TÉCNICAS DE BIG DATA

Monografia apresentada à Unidade Universitária de Computação do Centro

Universitário Estadual da Zona Oeste, sob a orientação do Professor José Luiz dos Anjos
Rosa como requisito parcial para obtenção do grau de Bacharel em Ciência da
Computação.

Rio de Janeiro,
Brasil 2018

2
 Lucas, Gabriel

Análise de Grandes Massas de Dados por Meio de Técnicas de Big

Data/ Gabriel Mattos Diniz Lucas. – Rio de Janeiro, 2018.

65f.: il.; 21cm.

Trabalho de Conclusão de Curso (Graduação em Ciência da

Computação) – Universidade Estadual da Zona Oeste, Campus
Campo Grande, Rio de Janeiro, 2018.

Orientador: José Luiz dos Anjos Rosa, DSc

1.Big Data 2.Hive 3.Pig 4.Zeppelin 5.Spark

2
3
AGRADECIMENTOS

Toda honra e glória ao Senhor Deus, Criador dos céus e da terra. Agradeço
profundamente a Ele por ter me dado a capacidade e determinação necessárias para
completar mais uma etapa desta empreitada pelo caminho do conhecimento lógico-
matemático, computacional e tecnológico. Agradeço também à minha família,
especialmente meu pai e minha mãe, por todo amor e suporte a mim conferido ao longo
da minha vida, e por sempre terem me apoiado nas minhas decisões e por acreditarem na
minha capacidade. Gostaria também de agradecer ao meu professor e orientador José Luiz
dos Anjos Rosa, pela eficiência e profissionalismo exercidos ao me ajudar a definir o tema
deste trabalho, na escolha das ferramentas utilizadas e nos direcionamentos técnicos
cruciais para o bom andamento do projeto. Seus materiais de estudo, conselhos
profissionais e conversas amistosas foram muito importantes para mim. Foi uma honra
poder estudar na UEZO. Guardarei boas lembranças do meu tempo na instituição, das
amizades construídas, dos desafios superados e das alegrias alcançadas. Estudei em um
centro universitário jovem, mas com excelentes professores e pessoas engajadas em
tornar este campus cada vez melhor. Fico feliz de ter feito parte da história da instituição
como aluno e, conforme minhas capacidades e minha evolução como profissional,
pretendo retribuir o investimento feito em mim agregando conhecimento as novas
gerações de alunos. Vamos seguir fortes na caminhada e que Deus nos abençoe.

4
RESUMO

Na última década, houve uma inimaginável explosão de dados em diversos setores

da indústria. Por estimativa, mais de 2,5 hexabytes de dados são gerados todos os dias.
Esta incrível quantidade de dados é originária de diferentes fontes como mídias sociais,
dispositivos móveis, câmeras, sensores, servidores públicos e privados e bancos de dados.
O termo Big Data foi criado para descrever este fenômeno e para atender o crescente
anseio de organizações e indivíduos em explorá-lo. Diversos mecanismos, ferramentas e
algoritmos foram criados ao longo dos anos para auxiliar os interessados em se aprofundar
neste novo ramo do gerenciamento de dados. O objetivo deste trabalho é explicar e
demonstrar a transformação de uma grande massa de dados em informação pertinente,
através de técnicas bem definidas e estruturadas atualmente no contexto Big Data. Este
trabalho também realizará um estudo sobre as ferramentas utilizadas, exprimindo sua
significância e funcionalidades em cada etapa do ciclo. Será utilizado como exemplo uma
base de dados estruturados relacionados à receita e orçamento do governo federal e
transferência de verba federal para estados e municípios brasileiros. Esta base foi retirada
do portal de transparência do Governo Federal do Brasil, que fornece dados sobre a
execução orçamentária da União.

5
ABSTRACT

Over the last decade, there has been an inimaginable explosion of data in many
sectors of industry. By estimate, more than 2.5 hexabytes of data are generated every day.
This amazing amount of data is originated from different sources like social media,
mobile devices, cameras, sensors, private and public servers and databases. The
termination Big Data was then created to describe this phenomenon, attending to the
growing aspiration of organizations and individuals in exploring it. Several mechanisms,
tools and algorithms were then created through the years to assist the interested at
deepening themselves in this new branch of data management. The objective of this work
is to explain and demonstrate the transformation of a great deal of data in relevant
information, through well defined and structured techniques currently in the Big Data
context. This work will also perform a study regarding the tools utilized, expressing your
significance and funcionalities in each step of the cycle. It will be used as an example a
semi-structured database related to revenue and budget of the federal government and the
transfer of federal money to Brazilian states and cities. This base was taken from the
Federal Government Transparency Portal, which provides data about the State budget
execution.

6
Sumário
1. INTRODUÇÃO ............................................................................................................ 8
1.1 Relevância ............................................................................................................. 10
1.1.1 Quanto à escolha do uso de técnicas de Big Data: ......................................... 10
1.1.2 Quanto à escolha da base de dados: ............................................................... 11
1.2 Objetivo ................................................................................................................. 12
2. FUNDAMENTAÇÃO TEÓRICA............................................................................... 13
2.1 Hadoop .................................................................................................................. 13
2.2 MapReduce ........................................................................................................... 14
2.3 HDFS .................................................................................................................... 16
2.3.1 NameNode e DataNode ................................................................................. 17
2.4 YARN .................................................................................................................... 18
2.5 Iniciativa Hortonworks.......................................................................................... 19
2.5.1 HDP ................................................................................................................ 20
2.6 Apache Hive .......................................................................................................... 22
2.6.1 Definição ........................................................................................................ 22
2.6.2 Principais Características e Otimização ......................................................... 23
2.7 Apache Pig ............................................................................................................ 25
2.7.1 Definição ........................................................................................................ 25
2.7.2 Principais Caracteríticas e Otimização........................................................... 26
2.8 Comparações Hive x Pig ....................................................................................... 28
2.9 Apache Zeppelin.................................................................................................... 30
2.9.1 Definição ........................................................................................................ 30
2.9.2 Principais Características, otimização com Apache Spark ............................ 31
3. METODOLOGIA ....................................................................................................... 35
3.1 Preparar Ambiente ................................................................................................. 35
3.2 Acessando Ambari View e Terminal Shell in a Box ............................................. 36
3.3 Adquirindo os dados brutos e adicionando-os ao HDFS ...................................... 38
3.4 Criações de tabelas no Hive e junção de arquivos no Pig ..................................... 39
3.5 Estruturação dos dados com expressões regulares ................................................ 41
3.6 Modificações finais para os tipos .......................................................................... 42
3.7 Montagem dos Notebooks Zeppelin ..................................................................... 42
3.7.1 Primeira seção – Repasses por Tipo e Datas .................................................. 43
3.7.2 Segunda seção – Análise do Orçamento ........................................................ 47
4. CONCLUSÃO ............................................................................................................ 51
5. APÊNDICES ............................................................................................................... 53
6. BIBLIOGRAFIA ........................................................................................................ 64

7
 1. INTRODUÇÃO

Conseguimos com facilidade identificar os equipamentos que nos fornecem

diariamente informações. Nossos smartphones, computadores, e diversos sistemas de
tecnologia sendo utilizados por nós diariamente. Menos perceptível porém é a própria
informação. Meio século depois dos computadores entrarem no ambiente central da
sociedade, os dados começaram a se acumular ao ponto de que algo especial começou a
se formar. Não apenas o mundo está inundado com informação como nunca antes, mas
essa informação está crescendo mais rápido. Esta mudança quantitativa força uma
mudança qualitativa. Organizações tecnológicas que entenderam isso rápido no início dos
anos 2000, cunharam o termo “Big Data”. (MAYER-SCHÖNBERGER, 2013).
Inicialmente, a ideia era que o volume de dados cresceu de tal maneira que a
quantidade sendo examinada não mais se encaixava no volume de memória que os
computadores usavam para processamento, então os engenheiros precisavam de uma
mudança das ferramentas que eram usadas para a análise. Esta é a origem de novas
tecnologias de processamento, como o MapReduce da Google e o seu equivalente de
código aberto1, o Hadoop, criado pela Yahoo. Eles trouxeram a oportunidade de analisar
quantidades muito maiores de dados do que antes, e esses dados não precisam estar
inicialmente em linhas ordenadas ou em clássicas bases de dados (MAYER-
SCHÖNBERGER, 2013).
Uma maneira de pensar na situação atual é esta: Big Data se refere a
processamento de dados que podem ser feitos em larga escala e que não podem ser feitos
eficientemente em pequena escala, extrair novas visões ou novas formas de valor, de
maneira que mudam mercados, organizações, relações entre cidadãos e governos, e mais
(MAYER-SCHÖNBERGER, 2013).
Entre pesquisadores e estudiosos, é aceita a identificação do Big Data através dos
três V’s, especificada inicialmente por Doug Laney (2001), ao relatar as dificuldades do
gerenciamento de dados no ambiente de e-commerce:

1
Código aberto é um modelo de desenvolvimento que promove o licenciamento
livre para a esquematização de um produto, onde ele pode ser redistribuído e qualquer um
pode consultar, examinar e modificar este produto.

8
 Volume: Refere-se a imensa quantidade de dados já existentes e gerados a cada
segundo. E-mails, fotos, vídeos, mensagens em redes sociais compartilhadas
incessantemente. No total chegamos a dados na ordem dos zettabytes; Esse aumento
de dados se tornam muito volumosos para serem armazenados e analisados através da
tecnologia tradicional de banco de dados;
 Velocidade: Refere-se à velocidade na qual novos dados são gerados e quão rápidos
eles se espalham. Como um vídeo no YouTube sendo “viral” em minutos, a velocidade
em que cartões de crédito são checados contra atividades fraudulentas ou os
milissegundos que levam sistemas de compra e venda analisarem a mídia de redes
sociais para receberem dados de decisão de compra ou venda de ativos e produtos.
Big Data permite analisar dados enquanto são gerados sem nem mesmo serem
alocados em bases de dados;
 Variedade: Refere-se aos diferentes tipos de dados que podemos usar. No passado,
focamos em dados estruturados que se encaixavam quase que perfeitamente em
tabelas e bases de dados relacionais como com dados financeiros. De fato, a maior
parte dos dados hoje é não estruturado e não pode ser facilmente colocado em bancos
de dados relacionais. Tecnologias de Big Data podem convergir dados de diferentes
estruturas em relações tradicionais.

Com o tempo, tentou-se adicionar mais dois V’s para complementar o seu
conceito inicial:

 Veracidade: Refere-se à confiança no dado. Com tantos formatos de dados,

qualidade e exatidão são menos controláveis, por exemplo hashtags nas redes sociais,
abreviações, siglas, linguagem coloquial. Big Data possui tecnologias analíticas agora
permitem trabalhar com estes tipos de dados (MARR, 2015).
 Valor: Refere-se à identificação de valor nos dados. É importante que os envolvidos
no negócio façam estudos para qualquer tentativa de coletar e analisar dados. É fácil
cair em armadilhas e entrar em iniciativas sem um claro entendimento do valor de
negócio (MARR, 2015).

9
 No entanto, apesar de suas premissas serem válidas no contexto dos dados, não
são avaliadores de magnitude intrínsecos ao Big Data. Nesse sentido, ainda é estipulado
os 3 V’s do Big Data como os identificadores essenciais desse modelo. Validados estes
itens como presentes no contexto de magnitude do seu dado, as técnicas de Big Data se
tornam hoje uma solução atrativa de evolução de trabalhos e análise.

1.1 Relevância

1.1.1. Quanto à escolha do uso de técnicas de Big Data:

Cerca de noventa por cento dos dados hoje foram criados nos últimos dois anos,
e dessa quantidade, oitenta por cento constitui de dados não estruturados ou que estão
disponíveis em variados formatos, o que os torna difíceis de serem analisados. Além
disso, através dos anos de desenvolvimento de sistemas de TI, é percebido que formatos
estruturados como bancos de dados, têm algumas limitações para gerenciar imensas
quantidades de dados, tanto pela necessidade de aumento vertiginoso de poder de
processamento e memória em relação a quantidade de dados quanto pela incapacidade de
um SGBD2 tradicional de gerenciar dados semi e não estruturados.
É observada a dificuldade de se integrar informação distribuída através de
múltiplos sistemas. A maioria dos envolvidos em um negócio não sabe o que deveria ser
analisado e descobrem os requerimentos apenas durante o desenvolvimento de sistemas
de TI. Com o aumento de dados também cresce o acúmulo de dados dentro das
companhias. Dados potencialmente valiosos como os contidos em ERP3 são esquecidos
ou descartados nessas bases. Isso se deve porque geralmente é muito caro justificar a
integração de altos volumes de dados estruturados de diferentes sistemas. Muitos tipos de
informação como dados sobre recursos naturais tem um ciclo de vida útil limitado e são

2
SGBD – Sistema de Gerenciamento de Banco de Dados.
3
ERP – Enterprise Resource Planning. É um sistema de gestão empresarial. Um
conjunto de diversos subsistemas integrados, cada um destinado a uma área da
companhia.

10
melhor utilizados apenas em um curto período de tempo. Informação é melhor explorada
para o valor do negócio quando é adicionado o contexto ao dado.
Soluções de Big Data se tornaram populares e atrativas porque conseguem
processar imensas quantidades de dados de uma maneira menos dispendiosa, com seus
algoritmos de processamento paralelo. Ele também captura dados em sua forma nativa,
que podem ser estruturados, semiestruturados, não estruturados ou streaming. E sendo
que estes dados podem ser capturados em tempo real, e com um sistema de arquivos
tolerantes a falhas. Mais importante é sua capacidade de transformar dados em
conhecimento acionável ao negócio.
Atualmente os dados já podem ser comparados com óleo, que costumava ser
considerado como o produto mais valioso da Terra no quesito de valor monetário. “Na
sua forma bruta, óleo tem pouco valor. Uma vez processado e refinado, ele ajuda a mover
o mundo. Os dados são o novo óleo” (WINBLAD, 2012).

1.1.2 Quanto à escolha da base de dados:

Em 2016, a economia brasileira viveu mais um ano de recessão. Junto com a

crise política, o cenário teve impactos diretos na queda da arrecadação, no aumento da
previsão de déficit, na crise nas contas dos estados, no aumento dos juros para
financiamento e na queda na confiança dos investidores. “Podemos citar também o déficit
das contas públicas de R$170,5 bilhões, inflação, queda baixa da taxa de juros feita pelo
Banco Central frente a crise, queda estimada do PIB de 3,43% o que gerou queda na
arrecadação federal de cerca de R$ 1,059 trilhão.” (AGÊNCIA BRASIL EBC, 2016)
A crise econômica deteriorou não apenas as contas do governo federal. Com a
arrecadação em queda, os estados tiveram dificuldade em honrar compromissos, o que se
refletiu em atrasos no pagamento de salários a servidores públicos e na prestação de
serviços básicos, como saúde e segurança (AGÊNCIA BRASIL EBC, 2016). Isso levou
a muitos estados a renegociar as dívidas com a união.
Todo este panorama econômico brasileiro, leva a uma reflexão quanto a
eficiência da União e dos estados com os gastos públicos e investimentos. Nesta
iniciativa, faz-se necessário uma melhor compreensão dos dados contidos no portal de

11
transparência do governo federal. Iremos analisar suas finalidades e assim, descobrir
formas de otimização e cortes de gastos.

1.2 Objetivo

Percebendo a importância do Big Data no contexto atual do gerenciamento de

dados, a mudança de paradigmas que o conceito está trazendo ao mundo de TI e o
crescimento e adesão que ele teve nesta década e certamente continuará tendo nos
próximos anos, este trabalho tem os seguintes objetivos:

 Apresentar algumas das atuais técnicas e ferramentas analíticas de Big Data;

 Inserir estas técnicas no desenvolvimento de um conjunto de dados relacionados
com o orçamento anual da União e a transferência de verba federal para Estados
e Municípios do Brasil;
 Analisar e extrair o valor dos dados demonstrando a utilidade do processo.

12
2. FUNDAMENTAÇÃO TEÓRICA

2.1 Hadoop

Na última década, antes do termo “Big Data’ ter sido cunhado, havia poucas opções para
processar grandes bases de dados com tamanho na casa dos Terabytes e além. Algumas bases
comerciais conseguiam, com configurações de hardware bem específicas e caras, serem
escaladas a esse nível, mas especialidade e gastos elevados requeriam que fosse uma opção
apenas para as maiores organizações. Alternativamente, alguns poderiam construir um sistema
customizado destinado a resolução de problemas específicos. E isto também sofria de alguns
dos mesmos problemas (especialidade e gastos) e adicionado o risco inerente de qualquer
sistema de ponta. Por outro lado, se um sistema fosse construído com sucesso, seria uma ótima
solução à necessidade (TURKINGTON, 2015).
Poucas companhias de tamanho médio se preocuparam com este espaço, não apenas
porque as soluções estavam fora de seu alcance, mas eles geralmente não tiveram a percepção
de armazenar a quantidade de volume de dados necessários para estas soluções. Quanto mais a
habilidade de gerar bases de dados mais largas se tornou mais comum, também cresceu a
necessidade de processar estes dados (TURKINGTON, 2015).
Google começou a mudança que eventualmente se transformara no Hadoop quando em
2003 e em 2004, lançaram dois artigos acadêmicos descrevendo o Google File System (GFS) e
o MapReduce. Os dois juntos forneceram uma plataforma para processamento de dados em
larga escala de uma maneira extremamente eficiente. A Google adotou a postura de “construa
você mesmo”, mas ao invés de construir algo destinado a um problema específico ou base de
dados, criaram uma plataforma no qual múltiplas aplicações processadoras pudessem ser
implementadas. Em particular eles utilizaram um extenso número de servidores comuns e
construíram o GFS e o MapReduce de uma forma que entendia que falhas de hardware eram
comuns e era simplesmente algo com que o software tinha que lidar (TURKINGTON, 2015).
O Yahoo percebendo o potencial da nova tecnologia, se tornou um dos mais
proeminentes apoiadores da ideia, tendo desenvolvido o projeto Hadoop encabeçado por Doug
Cutting com a Apache Software Foundation.

13
 2.1.1 Componentes do Hadoop

Segundo Turkington (2015), o projeto Hadoop possui diversos subprojetos

componentes. No seu núcleo, Hadoop provê dois serviços: armazenamento e computação. Um
típico fluxo de trabalho Hadoop consiste em carregar dados dentro do Hadoop Distributed
File System (HDFS) e processar estes dados usando o API do MapReduce ou diversas
ferramentas que se baseiam no MapReduce como um framework de execução.
Tanto o HDFS e MapReduce contém os princípios comuns que seguem:

 Ambos são designados para rodar em clusters de servidores comuns (ou seja, de baixa
à média especificação);
 Ambos escalam sua capacidade adicionando mais servidores (scale-out) em oposição
aos modelos anteriores que usam hardwares mais potentes (scale-up);
 Ambos têm mecanismos para identificar e trabalhar em cima de falhas;
 Ambos provêm a maioria de seus serviços com transparência, permitindo que o usuário
se concentre no problema em mãos;
 Ambos têm uma arquitetura onde um software gerenciador do cluster repousa em
servidores físicos e gerencia aspectos como balanceamento de carregamento de
aplicações e tolerância a falhas, sem depender de um hardware de ponta para entregar
estas capacidades.

Falaremos especificamente sobre os dois componentes a seguir.

2.2 MapReduce

MaPReduce é um modelo de programação desenvolvido para processar dados

estruturados e não-estruturados por amplos clusters compostos por hardwares simples gerando
extensas bases de dados. É capaz de processar muitos terabytes de dados em milhares de nós
computacionais em um cluster, gerenciando falhas, duplicando tarefas, e agregando resultados.
O modelo MapReduce foi concebido no início dos anos 2000 por engenheiros da Google
Research. Consiste de duas funções, uma função Map e uma função Reduce que podem ser

14
executadas em paralelo por múltiplas máquinas. Uma tarefa MapReduce divide uma extensa
quantidade de dados em pedaços independentes e os organiza em uma chave, pares chave-valor
para processamento paralelo (TANNIR, 2014).
A função Map divide a entrada em seções através do InputFormat e cria uma tarefa map
para cada seção na entrada. O JobTracker distribui estas tarefas através dos nós. A saída de cada
tarefa map é particionada em um grupo de pares chave-valor para cada ação reduce.
A função Reduce por sua vez coleta os vários resultados e os combina para responder
o problema inicial que o nó mestre precisa resolver. Cada reduce puxa a partição relevante das
máquinas onde os maps foram executados, e então escreve a sua saída de volta ao HDFS. Então
o reduce é capaz de coletar os dados de todos os maps para as chaves e combiná-los para
resolver o problema.
O modelo de programação do MapReduce é designado para ser independente de
sistemas de armazenamento. MapReduce lê pares chave-valor de sistemas de arquivos
subjacentes através de um leitor. O leitor recupera cada registro do sistema de arquivos e o
envolve em um par chave-valor para os seguintes processamentos. Este design independente de
armazenamento é considerado benéfico para sistemas heterogêneos uma vez que permite que o
MapReduce analise dados armazenados em diferentes sistemas de arquivos (TANNIR, 2014).
Vamos exemplificar o modelo de programação MapReduce com a necessidade de contar
a quantidade ocorrências de cada letra em um arquivo. Transferido para uma tarefa MapReduce,
a tarefa de contador de letras, como mostra a figura 1:

Figura 1 - Exemplo MapReduce – Contador de Letras

Fonte: Tannir (2014)

15
 As tarefas retratadas na Figura 1 podem ser descritas na seguinte ordem:

1. Os dados de entrada são divididos em registros através da função Splitting;

2. Funções Map processam os registros e produzem os pares chave-valor para cada
letra;
3. Todos os pares chave-valor que são saída da função Map são mescladas, agrupadas
por uma chave, e reorganizados pela função Shuffling;
4. Os resultados intermediários são transmitidos para a função Reduce, que produzirá
o resultado final (TANNIR, 2014).

2.3 HDFS

HDFS é um sistema de arquivos diferenciado inspirado no GoogleFileSystem (GFS).

Segundo Turkington, ele possui as seguintes características:

 Armazena arquivos em blocos que são tipicamente de 64MB ou (mais comumente

agora) 128MB, muito mais que os sistemas de arquivos mais comuns de 4 à 32kb;
 É otimizado para uma taxa de transferência acima de latência, é muito eficiente em
transmitir cargas de arquivos extensos, mas pobre em buscar por diversos arquivos
pequenos;
 É otimizado para cargas de trabalho que são geralmente escritos uma vez e lidos diversas
vezes. Ou seja, um arquivo uma vez criado, escrito, e fechado, não precisa ser
modificado. Esta definição simplifica os problemas de coerência dos dados, e permite
alta taxa de transferência de acesso aos dados;
 Ao invés de gerenciar falhas de disco, tendo redundância física em array de disco ou
estratégias similares, HDFS se baseia em replicação. Cada bloco contendo um arquivo
é armazenado em múltiplos nós em um cluster, e um serviço chamado NameNode
constantemente monitora para assegurar que as falhas não serão perdidas em qualquer
bloco abaixo do fator de replicação. Se isso não acontece, então ele agenda a realização
de outra cópia dentro do cluster (TURKINGTON, 2015).

16
 2.3.1 NameNode e DataNode

O HDFS tem uma arquitetura master/slave4. Um cluster HDFS consiste de um único

NameNode, um servidor mestre que gerencia o namespace do sistema de arquivos e regula o
acesso dos clientes aos arquivos. Além disso, há números e DataNodes, geralmente um por nó
no cluster, no qual gerencia o armazenamento anexado aos nós em que eles rodam. O HDFS
expõe o Namespace do sistema de arquivos e permite que os dados de usuários sejam
armazenados em arquivos. Internamente, um arquivo é dividido em um ou mais blocos e estes
blocos são armazenados em um conjunto de DataNodes. O NameNode executa operações de
Namespace no sistema de arquivos como abrindo, fechando e renomeando arquivos e diretórios.
Também determina o mapeamento de blocos de DataNodes. Eles são responsáveis por servir
pedidos de leitura e escrita para os clientes do sistema de arquivos. Os DataNodes também
reproduzem criação de blocos, exclusão, e replicação a partir de uma instrução do Namenode
(BORTHAKUR, 2016). A figura 2 ilustra a definição acima.

Figura 2 - Modelo HDFS

Fonte: Borthakur, 2016

4
Arquitetura voltada a sistemas distribuídos, onde máquinas específicas (master)
particionam a computação do problema e distribuem entre outras máquinas (slaves) que farão
o processamento da solução e então devolverão as respostas para as máquinas master.

17
 A existência de um único NameNode em um cluster simplifica grandemente a
arquitetura do sistema. O NameNode é o árbitro e o repositório de todos os metadados HDFS.
O sistema é designado de tal maneira que o dado de usuário nunca flui através do NameNode.

2.4 YARN

Com a evolução do ecossistema Hadoop, e o surgimento de novas ferramentas

agregando funcionalidades, as diferentes aplicações precisavam de um modelo otimizado de
gerenciamento de recursos para agilizar as execuções em paralelo no cluster. O YARN (Yet
Another Resource Negotiator) tem a função de dividir as funcionalidades do gerenciador de
recursos e o monitoramento de tarefas do Hadoop em diferentes nós. O objetivo é ter um
gerenciador de recurso global (ResourceManager) e um gerenciador por aplicação
(ApplicationMaster). O ResourceManager e o NodeManager formam o framework de
computação dos dados. O ResourceManager é a autoridade que arbitra os recursos entre todas
as aplicações no sistema. O NodeManager é o agente individual da máquina que é responsável
pelos pacotes, monitorando o uso de recursos computacionais do nó e reportando para o
ResourceManager. O ApplicationMaster é, por medida de efeito, uma estrutura de biblioteca
específica e é designada para negociar recursos do ResourceManager e trabalhar com outros
NodeManager para executar e monitorar tarefas. A figura 3 ilustra a definição acima.
Figura 3 – Arquitetura

Fonte: Apache YARN, 2016

18
 2.5 Iniciativa Hortonworks

A Hortonworks foi fundada em 2011 por 24 engenheiros da equipe original Hadoop.

Esta empresa, por trabalhar com um ecossistema de aplicações de código aberto, têm uma
comunidade de apoiadores e estudiosos que auxiliam no desenvolvimento do núcleo base de
código Hadoop, criando mais estrutura para o ecossistema de ferramentas da Apache Software
Foundation.
A ideia central da Hortonworks é dividir e interconectar o tratamento do Big Data
através de duas plataformas, a Hortonworks Data Flow (HDF) e Hortonworks Data
Platform (HDP). O HDF cuidará da parte de captar, coletar e analisar em primeira instância a
estrutura dos dados e seu conteúdo que estão presentes na conhecida Internet Of Anything. Já
o HDP tem a função de tratar dos dados já capturados na internet, adicionando em sua base,
acessando-os, modificando-os e tratando de sua visualização final como fonte de nova
informação.
A figura 4 demonstra o processo de aquisição de conhecimento pela visão do
ecossistema Hortonworks. Dados da internet são capturados pelo HDF através de suas
ferramentas, sendo estes dados estruturados ou não. São realocados e armazenados conforme
definição do usuário ou desenvolvedor. Se os dados são interessantes ao estudo, eles são
adicionados à estrutura do HDP, que vai organizar os dados, estruturá-los se necessário e
adicioná-los à base de dados. Essas bases constituem a fonte de informação que trará as visões
desejadas às organizações. O que não for utilizado é armazenado como visão histórica. A
interação entre as duas plataformas caracteriza a inteligência acionável da solução
Hortonworks.

19
 Figura 4 - Solução Hortonworks

Fonte: Hortonworks, 2016

Como podemos perceber pela figura 4, a solução Hortonworks é composta de diversos

níveis de tratamento dos dados, cada um requerendo uma especialidade. Este trabalho não tem
o intuito de utilizar das técnicas da ferramenta HDF para captação de dados. Partiremos da
premissa de que já temos à nossa disposição um conjunto de dados a ser diretamente adicionado
ao sistema de arquivos (HDFS) e que será inspecionada e trabalhada para um intuito específico.
O foco deste trabalho é voltado para análise de dados, que será feita por intermédio do ambiente
HDP e alguns de seus componentes. Veremos com mais detalhes na próxima seção.

2.5.1 HDP

O conceito central de utilizar a plataforma de dados da Hortonworks (HDP) é de

aproveitar os dados apresentados ou encontrados pelo usuário, que foram capturados e estão
armazenados no sistema de arquivos do Hadoop. A Hortonworks definiu como estratégia do
gerenciamento do dado, inserir diversas frentes de tratamento e auxílio com base angular no
HDFS com seu armazenamento escalável e tolerância a falhas e no YARN com seu trabalho de
delegação de recursos para as diferentes aplicações. A figura 5 classifica as frentes de atuação
do HDP da seguinte maneira:

20
  Acesso aos dados: Possui conjunto de mecanismos analíticos encarregados de
processar dados de diferentes formatos e gerar transformações que devolvem
informação agregada a partir da manipulação feita pelo usuário;
 Governança e Integração de dados: Componentes responsáveis por gerenciar o fluxo
de dados de entrada e saída do hadoop. Proporciona uma estrutura de controle e
automatização na integração de dados;
 Segurança: Ferramentas de autenticação de dados, encriptação e decriptação,
administração e monitoramento de dados;
 Operações: Conjunto de ferramentas para monitorar e gerenciar um cluster Hadoop
e agendamento de tarefas dentro do cluster;
 Ferramentas: Componentes de visualização dos dados através do Zeppelin e
integração de ferramentas analíticas em um ambiente gráfico com o Ambari.
(HORTONWORKS, 2016)

Figura 5 - Plataforma HDP

Fonte: Hortonworks, 2016

Podemos perceber através da figura 5, que o universo de trabalho com Big Data possui
diversas ramificações e áreas de atuação, e sabendo disso, um profissional da área pode seguir
em diferentes especializações. Para os propósitos deste trabalho, focaremos nas divisões que
remetem à parte analítica de dados, sendo que faremos uso dos componentes Apache Hive

21
(versão 2.1.0), Apache Pig (versão 0.16.0), e por fim, Apache Spark (versão 2.3.0) sobre a
ferramenta de visualização de dados Apache Zeppelin (0.7.3). Todas estas ferramentas estão
contidas na versão 2.6 do HDP, sendo a build mais estável na data de criação deste trabalho.
As próximas seções do capítulo são destinadas a explicar detalhadamente cada
componente que utilizaremos neste trabalho (citados acima). Entenderemos suas correlações,
funcionalidades, linguagens suportadas, um pouco da arquitetura e do relacionamento com o
cluster (Hadoop/YARN) e relacionamento com as operações MapReduce e HDFS.

2.6 Apache Hive

O Hadoop conseguiu criar solução para o problema de armazenar e recuperar grandes

quantidades de dados através de sua arquitetura escalável e acessível com o uso do HDFS. No
entando, o Hadoop ainda tinha dificuldade de expressar alguns tipos de dados com o uso de
programas MapReduce, porque nem todos os tipos de dados podem ser facilmente trabalhados
apenas com atribuições de pares chave-valor, a menos que tenha uma profunda customização
do job MapReduce através de programação adicional, geralmente em java, processo este muito
dispendioso - quando precisam de uma análise com mais de uma atribuição, como é encontrado
em estruturas tabelares relacionais. O Hive foi criado para suprir essa necessidade.

2.6.1. Definição

Segundo Dayong (Apache Hive Essentials, 2015), Hive é um padrão de consultas SQL
sobre a estrutura Hadoop. Ele fornece acesso à petabytes de dados no HDFS com uma
linguagem similar à SQL fazendo com que o Hadoop seja usado como uma estrutura de data
warehouse. A HQL (Hive Query Language) tem semântica e funções similares ao padrão SQL
em uma base de dados relacional, para que analistas de dados experientes possam facilmente

22
manipulá-los. A linguagem de consulta do Hive pode rodar em diferentes frameworks 5, como
MapReduce, Tez, e Spark para melhor performance.

2.6.2 Principais Características e Otimização

O modelo de dados do Hive oferece uma estrutura de alto nível, similar a tabelas, sobre
o HDFS. E por estar sobre o HDFS, ele também permite escalabilidade massiva e tolerância a
falhas para armazenamento de dados e processamento paralelo em hardware comum .
(DAYONG, 2016).
Esse modelo de dados de estrutura tabelar do Hive facilita consultas do tipo ad-hoc, que são
consultas criadas e modificadas de acordo com a necessidade de análise, e não procedimentos
estáticos e de difícil modificação como as operações em lotes com MapReduce.
Apesar de ter um modelo de dados tabelar, a sua execução ainda segue os padrões
MapReduce. Hive é orientado à execução em lotes (comandos pré-definidos de execução) e
tem alta latência (alto tempo de resposta após execução). Isso permite manter os padrões
necessários para processamento paralelo quando se manipula quantidades massivas de dados
(DAYONG, 2016).
Outro ponto importante a se considerar é a Interoperabilidade do Hive. Isso ignifica que
ele possui diversos frameworks que suportam diferentes tipos e formatos de arquivos. Dentre
os formatos disponíveis, utilizaremos o ORC (Optimized Row Columnar). Ele usa
codificadores para diferentes tipos de dados colunares a fim de melhorar a compressão do
arquivo (compressão de largura variável de valores inteiros). O ORC introduz um leve
indexador que permite pular completos blocos de linhas que não se encaixam com a consulta.
Ele resulta nas funções de estatística básica – MIN, MÁX, SUM e COUNT – sobre as colunas
tornando-as mais ágeis. Por fim, um bloco mais volumoso de 256MB por padrão otimiza largas
leituras sequenciais sobre o HDFS para mais taxa de transferência com menos arquivos para
reduzir a carga no namenode. (PROKOPP, 2014). A partir destas características o ORC é hoje
uma boa opção de formato de arquivo para manipulação no Hive e por isso, ele será utilizado
neste trabalho.

5
Estrutura computacional voltada para desenvolver família de soluções programáticas
semelhantes. No nosso exemplo a linguagem do Hive pode ser usada por diferentes
ferramentas que não só o Hive, para propósitos semelhantes de análise de dados.

23
 Hive também é extensível, proporcionando adição de scripts MapReduce e derivados,
adição de funções e tipos definidos pelo usuário, e de um formato customizado de entrada e
saída de dados que permite utilização de tipos variados e de bases de dados para mais
possibilidades de análise.
Outra característica importante do Hive é a sua boa performance por utilizar uma engine
que possui scripts pré-definidos para reduzir o tempo de execução enquanto oferece alta saída
de dados. Utilizaremos neste trabalho a engine TEZ, uma ferramenta evolutiva ao MapReduce.
A principal função do Tez é generalizar o paradigma MapReduce para uma estrutura mais
poderosa baseada na expressão de computação como um grafo de fluxo de dados. Isso é possível
através do uso de técnicas DAG (Directed Acyclic Graph) contidas na engine, que se traduz
numa API onde o grafo corresponde a uma tarefa, o vértice corresponde aos passos lógicos da
tarefa e as bordas direcionadas representam o movimento de dados ao longo dos vértices até as
folhas. A figura 6 abaixo demonstra bem a diferença entre a execução em MapReduce e a
execução em Tez. Na primeira figura múltiplas tarefas MapReduce são necessárias até chegar
ao resultado final (os reducers do passo anterior alimentando o mapper do próximo passo), e
tendo que armazenar resultados intermediários no HDFS. Na segunda figura, um único map
possui múltiplos estágios reduce (através de uma implementação DAG), sem ter que, portanto,
armazenar dados em disco com HDFS (o processo é feito em memória), trazendo mais
performance (MURTHY, 2014).
Figura 6 - Comparativo MR e Tez

Fonte: Apache Tez, 2016

Mais um aspecto importante do Hive que utilizaremos neste trabalho é a execução

vetorizada de consultas. Ela reduz enormemente o custo de processamento para operações e

24
consulta típicas como filtros, agregações e joins de tabelas. Um sistema padrão de execução de
consultas processa uma linha por vez. Isto resulta em longos códigos e uma quantidade
significante de interpretações de metadados no loop de execução. A execução vetorizada de
consultas otimiza a operação ao processar blocos de 1024 linhas por vez. Em cada bloco, cada
coluna é armazenada como um vetor (um array de tipos primitivos de dados). Operações
simples como cálculos aritméticos e comparações são realizadas rapidamente iterando sobre os
vetores em um loop bem amarrado, com poucas ou nenhuma chamada de função ou
ramificações condicionais dentro do loop (HANSON, 2015).

2.7 Apache Pig

No conceito original de desenvolvimento MapReduce – onde a linguagem Java é
geralmente usada – o programador precisava enfrentar diversos desafios como:

 O desenvolvedor tem que pensar em termos fundamentais de Split, Map e

Reduce, que podem aumentar o tempo de produção de um job ou programa;
 O programador precisa criar códigos customizáveis em Java que também terão
impacto no tempo de produção do trabalho, pois requerem concentração e
atenção a detalhes que, se não percebidos, podem invalidar o código;
 O modelo MapReduce possui um rígido fluxo de dados, ou seja, é difícil entregar
a saída de uma tarefa, a partir da entrada de outra tarefa;
 Conforme a complexidade do código aumenta, fica mais difícil de manter,
otimizar e estender o código.

Pensando nessas dificuldades, a Apache criou Pig, uma ferramenta que pudesse ser
eficiente em ambientes de processamentos de dados paralelos, tendo o encontro perfeito entre
e estilo de programação declarativo do SQL com o estilo procedural do MapReduce.

2.7.1. Definição

Pig é um dos componentes do ecossistema Hadoop. Segundo Gates (2011), Pig é um

mecanismo para executar fluxo de dados em paralelo com Hadoop, Ele inclui a linguagem Pig
Latin para expressar esses fluxos de dados. Pig Latin inclui operadores para muitas das

25
tradicionais operações com dados (join, sort, filter), enquanto tem a possibilidade de que seus
usuários desenvolvam suas próprias funções para leitura, processamento e escrita de dados.
Essa customização do Pig é possível por causa de sua arquitetura de código aberto, que torna
possível a customização do software pela comunidade de usuários.
Pig é sumariamente dividido em dois componentes principais:

 Pig Latin – É uma linguagem de fluxo de dados procedural que contém sintaxe e
comandos que podem ser aplicados para implementar lógicas de manipulação de dados
que são organizadas por regras de negócio (Exemplos são: LOAD, STORE, etc).
 Motor de execução – É um compilador que analisa, valida e produz scripts de operações
através de sequências de programas MapReduce. Ele utiliza, pelo padrão Hadoop, o
HDFS para armazenar e recuperar dados.

2.7.2 Principais Caracteríticas e Otimização

Um dos grandes diferenciais do Pig está na sua forma de operação, que pode ser
explicada e dividida em três estágios:

1. Refere-se a escrita do código Pig Latin, por ser uma linguagem procedural, todo o
código deve ser escrito por inteiro antes de prosseguir para a compilação, e por isso,
recebe o conceito de script. Os dados a serem utilizados devem ser carregados através
da função LOAD, e um agente identificador deve ser aplicado ao conjunto de dados
carregados. Esse identificador é chamado de relação. (APACHE PIG, Pig Latin Basics,
2016) Sequencialmente, são feitas as modificações nos dados através das funções
FILTER, GROUP, JOIN, GENERATE, entre outros. Cada modificação no conjunto de
dados necessita também de relações para serem identificadas. Por fim, os dados
modificados são armazenados no HDFS através da função STORE. Este deve ser o
processo a ser seguido pelo programador ao escrever seu código Pig.
2. O segundo estágio consiste na execução das operações internas do Pig. Nesse estágio,
o compilador se encarrega de separar as linhas do código em etapas e descrever suas
funções sintáticas, checar e otimizar cada parte do código. Se o script passar na

26
 avaliação, Pig planeja a execução do código no ambiente Hadoop, ou seja, o transforma
em tarefas MapReduce, envia e monitora a execução da tarefa.
3. Por fim, temos o terceiro estágio, a execução do plano. Pig pode tanto mostrar o
resultado da operação na tela, através do comando DUMP, ou armazenar efetivamente
no HDFS se o comando STORE for indicado, e assim, a tarefa termina.

Além da forma de operação do Pig, também é importante conhecer seu modelo de dados,
pois ele se difere do modelo SQL tradicional que encontramos no Hive, por exemplo.
Basicamente, Pig suporta quatro tipos básicos:

 Campo – Um simples valor atômico. Suporta os tipos tradicionais como integer, double,
string, etc. Ex: ‘Lucas’;
 Tupla – Uma sequência de campos que podem ser de qualquer tipo de dados
tradicionais. Ex: (‘Lucas’, 25);
 Bag – Coleção de tuplas de estruturas potencialmente variáveis, podem conter
duplicatas. Ex: {(‘Lucas’), (‘Marta’, (25,38))};
 Map – É um array associativo; a chave deve ser um chararray mas o valor pode ser de
qualquer tipo (Tipo indicado para bases semi-estruturadas). Ex:
[nome#Lucas,cel#980567845].

Por padrão, Pig trata campos não declarados como bytearrays, que são uma coleção de
bytes não interpretados. Pig pode inferir o tipo de um campo baseando-se no uso de operadores
que requerem um certo tipo, através de UDF’s (User Defined Functions) com um retorno
tipado conhecido, pelas informações de metadados fornecidos pela função LOAD ou
explicitamente declarados usando a cláusula AS. A conversão de dados do Pig é feita em tempo
de execução apenas. UDF’s são uma característica singular do Pig pois permitem uma
customização do código Pig que se adeque às necessidades do trabalho. Há vários tipos de
customização que podem ser aplicados a funções de avaliação, agregação, interfaces algébricas,
acumuladores e filtros. O maior suporte dessas customizações é na linguagem Java, mas que
pode ser aplicada na plataforma Pig sem problemas.
Conhecendo o seu modo de operação e seu modelo de dados, podemos compreender
como ocorre a construção relacional do código Pig Latin, que é formado por suas declarações.

27
O tutorial na página oficial da Apache Pig (Getting Started, 2016) traz as seguintes
características:

Declarações Pig Latin são os construtores básicos usados para processar

dados usando Pig. Uma declaração Pig Latin é um operador que recebe uma relação
como entrada e produz outra relação como saída. E isto se aplica a todos os operadores
exceto LOAD e STORE que carregam e armazenam dados no HDFS. Declarações Pig
Latin podem incluir expressões6 e esquemas7. Podem gerar múltiplas linhas e devem
encerrar com ponto e vírgula (;). Por padrão, declarações Pig Latin são processadas
utilizando execução multiconsulta.

Com essas execuções, Pig processa por inteiro um script, analisando se tarefas
intermediárias do código podem ser combinadas para reduzir o tempo total de processamento.
Pig, assim como o Hive, também permite um motor de execução alternativo ao
MapReduce, o TEZ. Neste trabalho, ele será um diferencial para otimizar o fluxo dos Jobs e,
consequentemente, reduzir o tempo de execução.

2.8 Comparações Hive x Pig

Uma dúvida comum entre os iniciantes no estudo de Big Data e para novos integrantes
da comunidade Hadoop, ao conhecerem Hive e Pig, é saber em qual circunstâncias usar cada
um deles em seus projetos de análise de dados. Esta dúvida é pertinente ser esclarecida neste
projeto pois, como as duas ferramentas serão usadas, uma comparação é necessária para
especificar em quais momentos cada uma delas é mais útil, e como elas podem se complementar
para tornar o projeto mais eficiente e rápido.
A Tabela 1 demonstra um comparativo entre as duas ferramentas:

6
Expressões são construtores de linguagem usados com operadores de filtro e
agrupamento e funções de avaliação.
7
Esquemas são ferramentas que permitem atribuições de nomes à campos e
declaração de tipos. Agiliza a verificação e execução do código Pig Latin.

28
 Tabela 1 – Comparativo Hive x Pig
Pig Hive
Linguagem procedural de Linguagem declarativa estilo
fluxo de dados SQL
Para programação Para criar relatórios
Usado principalmente por Usado principalmente por
pesquisadores e analistas de dados
programadores
Opera do lado cliente de Opera do lado servidor de um
um cluster cluster.
Não possui uma base de Faz uso da variação de um
dados dedicada a DDL SQL dedicado para
metadados. definir tabelas à priori.
Pig possui alguns aspectos Remete diretamente à SQL,
de SQL mas varia em sendo fácil de aprender para
muitos. experts em bases de dados.

Observando a comparação presente na tabela 1, podemos concluir que as características

aplicadas a Hive nos proporcionam uma ferramenta analítica de dados, que se assemelha a um
Data Warehouse, ou seja, Hive é mais eficiente na estruturação tabelar dos dados que serão
recebidos inicialmente do HDFS. Ele será mais útil na primeira etapa do trabalho, onde os dados
históricos precisam de um pré-processamento para serem organizados.
Pig por sua vez, tem suas características mais fortes relacionados à ETL8, onde um
comparativo de performance entre Hive e Pig feito pela IBM 9 mostrou que Pig é superior ao
realizar a maioria das operações de manipulação de dados como: operações aritméticas (em
média 46% mais rápido), filtragem de dados (em média 49% mais rápido ao filtrar 10% da base
de dados, em média 18% mais rápido ao filtrar 90% da base de dados), junção de tabelas e bases

8
ETL – Extract, Transform, Load. Processo de extração de dados de um determinado
local, manipulação desses dados, e carregamento em plataforma especificada.
9
Ver Pig vs Hive: Benchmarking High Level Query Languages nas referências
bibliográficas.

29
de dados (em média 36% mais rápido). Pig mostrou-se inferior apenas no agrupamento de
dados, sendo 104% mais lento que Hive (JAKOBUS, 2013).

2.9 Apache Zeppelin

Com todas as capacidades de manipulação de dados que Hive e Pig possuem, eles não
contêm uma estrutura robusta para uma visualização final dos dados. Pensando nisso, é
interessante adicionar uma ferramenta que proporcione uma exploração de dados mais
simplificada e interessante tanto para o cientista de dados, quanto aos usuários finais que
desconhecem as composições técnicas das bases de dados. Zeppelin é esta ferramenta.

2.9.1 Definição

Zeppelin foi concebido como um notebook baseado em web. Notebook é um modelo de

visualização de dados em estrutura de páginas ou relatórios. Por ser web, Zeppelin opera em
modo cliente-servidor e precisa ser executado em um browser (APACHE ZEPPELIN, 2016).
Apache Zeppelin é relevante nas seguintes atividades da ciência de dados:

 Data Ingestion: Processo de obtenção e importação de dados para uso imediato ou

armazenamento em uma base de dados;
 Data Discovery: Processo de descoberta de conhecimento através da observação de
padrões nos dados;
 Data Analytics: Processo de utilização de conhecimento adquirido, este referenciado
pelo termo “insight”, para auxiliar na tomada de decisão de negócios, trabalho ou
pesquisa;
 Data Visualization & Collaboration: Processo de representação visual dos dados, com
objetivo de comunicar um insight da forma mais eficiente e clara possível (APACHE
ZEPPELIN, 2016).

30
 O grande propósito do Zeppelin é fornecer uma ferramenta interativa de visualização de
dados, sendo interativo porque propicia um modelo volátil na estrutura de visualização que
melhor atenda às necessidades finais do usuário, que possa aglomerar diversas iterações de
dados em um único arquivo e que possa modificar seu arcabouço em tempo real e a cada nova
consulta. Isto permite que engenheiros e analistas de dados possam ser mais produtivos ao
desenvolver, organizar, executar e compartilhar códigos, visualizar resultados, e trabalhar com
os fluxos de trabalho sem se preocupar com linhas de comando ou detalhes do cluster (APACHE
ZEPPELIN, 2016).

2.9.2 Principais Características, otimização com Apache Spark

Apache Zeppelin basicamente trabalha à base de seus interpretadores, que são módulos
que permitem entender a entrada feita pelos usuários de uma linguagem de processamento de
dados. Atualmente, Zeppelin possui suporte a interpretadores de diversas linguagens famosas
no mundo Big Data como SQL, R, Python, Scala, entre outros. Para adicionar uma linguagem
é preciso referenciá-la no contexto de interpretadores ao iniciar a escrita do código, como
mostra a figura 7 abaixo:

Figura 7 – Zeppelin Notebook

Fonte: Apache Zeppelin (2016)

31
 Na figura 7 temos a representação do Notebook Zeppelin com três visualizações
diferentes de dados. Todas foram criadas com consultas do interpretador SQL permitida através
da declaração %sql. Da esquerda para a direita, a primeira visualização mostra os dados em
estrutura de tabela, a segunda em gráfico de setores, a terceira em gráfico de linhas. Estas
visualizações são possíveis através de seus parágrafos que são constituídos de uma seção
destinada à escrita do código fonte, e uma seção que mostra o resultado da execução do código.
É importante para fins de otimização que se escolha, entre os interpretadores disponíveis
no catálogo do Zeppelin, o que proporciona o processo de visualização mais simples e eficiente.
Apache Spark é um sistema distribuído de processamento de dados baseado em JVM criado
especificamente para trabalhar com Big Data. A melhor justificativa de escolha do Spark para
esta etapa de visualização com Zeppelin, vem do conhecimento de que Spark roda programas
cem vezes mais rápido que MapReduce quando alocados em memória e dez vezes mais rápido
quando alocados em disco. Isto é possível devido a sua habilidade de realizar o processamento
na memória principal dos nós ativos e previne processamento de fluxo de dados desnecessário
em disco. Outra vantagem que o Spark oferece é a habilidade de encadear as tarefas mesmo na
fase de programação da aplicação, sem escrever – ou minimizando em último caso - rotinas em
disco (THOTTUVAIKKATUMANA, 2016).
Outra característica que demonstra a eficiência do Spark é a implementação do motor
de processamento de dados DAG (Directed Acyclic Graph), o mesmo conceito implementado
por TEZ no contexto Hive, visto no capítulo 2.6.2. Isso significa que para cada execução Spark,
uma tarefa DAG é criada pelo motor da aplicação. O conceito de processamento de dados in-
memory aliado ao processamento DAG leva o Spark ao nível mais avançado de eficiência e
velocidade.
O modelo do Spark constitui no seu núcleo a característica mais importante de abstração
de dados, o RDD (Resilient Distributed Dataset). Ele se encarrega de realizar o particionamento
e a distribuição da base de dados entre os nós do cluster de forma que não existam nós ativos
ociosos, além de replicar os dados contidos em nós que falharem, para os nós ativos
(THOTTUVAIKKATUMANA, 2016).
As qualidades do Spark como ferramenta de Big Data vêm também de seu suporte ao
paradigma de programação funcional, o qual o RDD do Spark se apropria.
Thottuvaikkatumana em seu livro “Apache Spark 2 For Beginners” (2016) explica o conceito:

A mutação de objetos em tempo de execução, e a inabilidade de se ter

resultados consistentes de um programa ou função por conta dos efeitos colaterais que
a lógica de programação cria, torna aplicações muito complexas. Se as funções em

32
 linguagens de programação começarem a se comportar exatamente como funções
matemáticas de forma que a saída da função dependa somente da entrada, isso dá
muita previsibilidade as aplicações. O paradigma de programação computacional que
dá ênfase ao processo de construir tais aplicações e outros elementos baseados nisso,
e usando estas funções da mesma forma que qualquer outro tipo de dados esteja sendo
usado, é popularmente conhecido como paradigma de programação funcional.

Além disso, o autor nos apresenta a linguagem Scala, e sua importância na construção
do Spark. Ela consegue conciliar fortes capacidades de programação funcional sem perder
qualquer propriedade orientada a objetos. Spark é construído predominantemente em Scala, por
isso ele recebe muitos de seus bons conceitos aplicados ao seu RDD, por exemplo, utilizar
funções como parâmetros para transformações dos dados. Nesse sentido, o Spark RDD se
comporta como uma coleção de objetos, ou seja, métodos de transformação de dados são
compartilhados entre Scala e o Spark RDD para realizar as mesmas ações. Essa propriedade
fundamental resulta nos seguintes aspectos:

 Spark RDD é imutável: Uma vez que um RDD é criado, ele não pode ser modificado.
Se um nó que estiver processando uma parte do RDD morrer, o programa pode recriar
as partes e redirecionar o processamento para outro nó até a completude do
processamento do dado (THOTTUVAIKKATUMANA, 2016);
 Spark RDD é distribuído: Na execução de um programa, quando os nós ativos
disponíveis ao recebem suas respectivas tarefas, cada nó terá um contexto único de
execução, ou seja, cada tarefa é distribuída e executada em uma instância diferente de
JVM. Essa dinâmica do RDD ser dividido em porções menores, e ser distribuído entre
os nós ativos, e por fim, mesclar os resultados de volta, é oculta ao usuário, provendo o
ambiente necessário de resiliência na abstração de dados
(THOTTUVAIKKATUMANA, 2016);
 Spark RDD vive em memória: Spark faz o máximo para manter seus RDD’s em
memória. Em raras exceções, se Spark estiver operando além da capacidade de
memória, ou o tamanho da base crescer além do ponto suportado, ele opera em disco
(THOTTUVAIKKATUMANA, 2016);
 Spark RDD é fortemente tipado: Um RDD pode ser criado usando qualquer tipo
suportado de dado. Os tipos de dados podem tanto ser modelos Java/Scala pré
determinados, ou classes criadas pelo próprio usuário. Esta característica traz imunidade

33
 a erros runtime10. Se o programa falhar, ele falhará somente em tempo de compilação
(THOTTUVAIKKATUMANA, 2016).

De posse dessas informações é esperado que Zeppelin fornecerá as ferramentas

necessárias para uma visualização de dados eficiente. Através de um interpretador Spark que
fornece toda a estrutura RDD para processamento de dados paralelizados e otimizada pelo
modelo de programação funcional para trazer robustez e agilidade.

10
Erros Runtime são exceções que ocorrem durante a execução da aplicação. Nesses
casos a aplicação não consegue continuar operando e se encerra.

34
 3. METODOLOGIA

Este capítulo é reservado para o desenvolvimento do projeto. Aplicaremos o

conhecimento técnico do capítulo anterior para alcançar os objetivos definidos. Todas as
figuras abaixo são resultado de screenshots tirados ao longo do processo.

3.1 Preparar Ambiente

A primeira etapa do trabalho consiste na preparação do ambiente HDP, que contém

todas as ferramentas que serão utilizadas para transformação dos dados. Em condições
ideais, nosso ambiente seria montado em um cluster físico de alta capacidade
computacional. Isso seria muito custoso, uma vez que não dispomos deste cluster no
decorrer deste trabalho. Para contornar esta deficiência e facilitar a utilização da ferramenta,
a Hortonworks disponibiliza seu sandbox HDP em um ambiente Linux, distribuição
CentOS, para ser montado em uma máquina virtual, ou seja, nosso cluster será montado
virtualmente e não fisicamente. Ele está disponível para download no site
https://br.hortonworks.com/downloads/. Faremos o download do arquivo ova na versão 2.6
que possui cerca de 10GB. Faremos a virtualização pelo VM Virtualbox da Oracle
(download - https://www.virtualbox.org/), portanto, baixaremos o HDP específico desta
virtualização.
Seguidamente, é importante constatar que memória RAM rege os trabalhos de
processamento de dados. Isso será ainda mais forte quando chegarmos nas atividades com
Spark. Portanto, quanto mais memória disponível, melhor. A Hortonworks pede requisitos
mínimos para funcionamento do HDP de 8GB de memória RAM reservados a máquina
virtual. NO entanto, recomenda-se 16GB para melhor performance. Quanto menos seu
sistema operacional físico ocupar de memória, mais poderá ser usado pela máquina virtual.
Pensando nisso, utilizaremos na máquina física o sistema operacional Linux, distribuição
Ubuntu. É uma boa opção por âmbito de performance, usabilidade, e de aplicação. Demanda
cerca de 3GB para uma utilização agradável e sem gargalos.
Com o download do HDP e instalação do Virtualbox concluídos, devemos abrir o
gerenciador do VM e importar o arquivo no formato ova através do caminho: Arquivo >
Importar Appliance. Ao realizar a importação, é crucial definir de forma correta, através do

35
 menu de configuração, a quantidade de memória base e CPU destinada à máquina virtual.
Neste trabalho, temos a limitação de 12GB de memória RAM, portanto destinamos 9GB
para a máquina virtual e 3GB para o sistema operacional. Com um processador de quatro
núcleos, podemos destinar três núcleos para máquina virtual e deixar um núcleo para a
máquina local.
Após estes preparativos, o HDP está pronto para iniciar. A máquina virtual carregará
o sistema CentOS, que por usa vez carregará o HDP e seus componentes. A primeira
inicialização pode durar vários minutos, de acordo com a quantidade de memória alocada.
Findado este processo, resulta a seguinte tela demonstrada pela figura 7 abaixo. Nela
contém descrito a versão do HDP (2.6.4), o endereço ip do sandbox HDP ligado ao host da
máquina virtual, representado por 127.0.0.1 junto com :8888 que representa a porta para a
página de boas-vindas.

Figura 8 – Tela Inicial HDP

3.2 Acessando Ambari View e Terminal Shell in a Box

Iremos agora inicializar duas aplicações importantes no auxílio do desenvolvimento dos

trabalhos: O Ambari view será a ferramenta de integração dos componentes HDP. Ele será útil
para monitorar o funcionamento do cluster e acessar todas as suas ferramentas. Seu acesso
ocorre pelo endereço ip do host e pela porta :8080 (padrão - 127.0.0.1:8080).

36
 O Terminal SHH (secure shell) Shell in a box é uma ferramenta que permite a
comunicação segura entre o sistema da máquina virtual e o sandbox HDP. Acessado pelo ip do
host e porta :4200 (padrão – 127.0.0.1:4200). Será requerido o login root e senha hadoop para
primeiro acesso. Após login, configuraremos a senha de acesso ao Ambari pelo comando:
ambari-admin-password-reset. É importante manter o terminal SSH operante, pois
realizaremos através dele outros comandos posteriormente.
Na tela de login Ambari, são pedidos usuário e senha. Usaremos o login admin porque
ele nos dá permissões totais de controle do cluster e configuração dos serviços disponíveis. A
senha é a mesma criada anteriormente pelo terminal SSH.
Somos então direcionados para a dashboard que contém as funções centrais do Ambari
enumerados na figura 8:

1. Acessar individualmente a situação de cada serviço que compõe a plataforma HDP,

como o HDFS, YARN, Spark, Hive, etc. Com permissões de admin, podemos ativar e
desativar serviços livremente;
2. Métricas de avaliação do cluster com as informações do uso total de espaço do HDFS,
utilização da memória YARN, atividade dos NameNode e DataNodes, entre outros;
3. Nos permite a configuração do relacionamento de cada serviço com o cluster, ou seja,
alocação de memória, utilização do TEZ no Hive, atualizar ferramentas, e manipular as
configurações dos componentes deste trabalho.
Figura 9 - Ambari UI

37
 3.3 Adquirindo os dados brutos e adicionando-os ao HDFS

Nosso objetivo é demonstrar o processo de descoberta de conhecimento por meio de

técnicas de big data. Utilizaremos dados do governo federal referentes às receitas públicas,
despesas públicas e recursos transferidos para estados e municípios (disponível em
http://www.portaltransparencia.gov.br/). Utilizaremos a base histórica de 2013 até 2017 para os
dados dos recursos transferidos para Estados e Municípios, e a base de 2014 até 2017 para as
receitas e despesas públicas do Governo Federal. Isso significa utilizar toda a base disponível
no portal relacionada aos tipos citados, exceto os dados de 2018, pois na data deste trabalho
ainda não ocorreu o fim do ciclo orçamentário anual.
Os dados estão distribuídos somente por ano, no caso do orçamento e das receitas, de
2014 a 2017 e divididos por ano e mês no caso dos arquivos de transferência de 2013 a 2017.
Temos então sessenta arquivos dos dados de transferência, quatro arquivos dos dados de
orçamento e quatro arquivos dos dados de receita. Temos no total a utilização de 68 arquivos.
O download foi feito de forma manual, diretamente do portal de transparência. O conjunto total
de dados possui cerca de 8,4GB.
Vislumbrando os futuros procedimentos de manipulação dos dados, é importante
compreender que Hive trabalha, por padrão, com arquivos codificados em UTF-8. Utilizar
arquivos com outra codificação resulta que caracteres latinos com acentos apareçam distorcidos
nas consultas. Portanto, criaremos um script bash Linux para modificar os arquivos adquiridos
do portal (formato original ISO-8859-1) para UTF-8. O código utilizado se encontra no
apêndice 1- Código arquivo Bash para Conversão de arquivos.
O próximo passo é criar uma conexão SFTP (SSH File Transfer Protocol) entre máquina
física e máquina virtual para transferir todos os arquivos necessários. O código utilizado para
esse processo se encontra no apêndice 2- Comando Linux de Conexão SFTP e Transferência
de arquivos para VM. Os arquivos podem então ser movidos manualmente para a pasta criada
e estarão disponibilizadas no ambiente HDP. Finalmente, os arquivos podem ser movidos para
o HDFS, onde poderão ser de fato utilizados pelas ferramentas de manipulação de dados.
Usaremos o shell in a box para realizar este processo. Com o login já executado na etapa
anterior, realizamos um comando de cópia de arquivos para o HDFS. Comandos presentes no
apêndice 3 – Comando HDFS cópia de arquivos.

38
 3.4 Criações de tabelas no Hive e junção de arquivos no Pig

Com os arquivos já presentes no HDFS, podemos começar a criar as tabelas que

receberão os dados. Acessaremos o Hive View 2.0 pela seção três do Ambari, e após uma
verificação de estabilidade do serviço, somos direcionados para utilização do Hive demonstrado
pela figura 10 com as seguintes funcionalidades principais:

1. Abas que contém as funções principais do Hive, permitindo criar códigos HiveQL,
verificar histórico de consultas, modificar, criar e excluir estrutura de tabelas, criar
UDF’s Hive, e configurações gerais;
2. Seleção de base de dados;
3. Local para codificação;
4. Tabelas da base de dados selecionada.

Figura 10 – Hive View 2.0

Criaremos então as tabelas em coluna única tipo string para cada seção: orçamento,
receita e transferências. A partir deste ponto do projeto, como os dados de todas as seções
seguem um modelo estrutural similar, escolhemos apresentar o processo tão somente dos dados

39
de transferências. Nos casos onde o processo se individualizar, eles serão descritos. É a partir
deste ponto também que declararemos o formato de arquivo ORC na criação de todas as tabelas
Hive, com o intuito de usufruir de suas capacidades. Para especificar este formato, basta
adicionar o comando “stored as orc” ao final do código HiveQL. A estrutura está no apêndice
4- Estrutura tabela inicial Hive. Essas tabelas atuarão como intermediárias ao receber os
dados agrupados de todos os anos e meses para cada tipo e transferi-las para outras tabelas e
realizar novas modificações. Consecutivamente, o agrupamento de dados e sua transferência
para a tabela Hive criada serão feitos por um script Pig.
Da mesma forma que o Hive, acessamos a interface Pig pelo Ambari na aba Pig View,
e então teremos a figura 10 abaixo:

1. Lista de scripts, UDF e histórico de execuções;

2. Acessar script atual ou histórico ordenado;
3. Funções de auxílio para o código;
4. Adicionar argumentos necessários para execução do script;
5. Botão de execução do script ou verificador do código.

Figura 11 - Pig View

2 5

3
1

Criaremos um script salvando o caminho para o HDFS e atribuindo um nome. O

objetivo deste script é carregar os diversos arquivos, unificando-os em um único contexto para

40
transferi-los aos Hive. A relação receberá o caminho HDFS da pasta e carregará todos os
arquivos nela contidos para o PigStorage. Com o comando store, será armazenada a relação na
tabela indicada no formato ‘database.tabela’, sendo essencial adicionar o argumento “–
useHCatalog” para demonstrar o uso da função de armazenamento HCatStorer. Script contido
no apêndice 5 – Script Pig agregar arquivos HDFS. Seguindo este processo, os dados estarão
presentes nas tabelas Hive especificadas.

3.5. Estruturação dos dados com expressões regulares

É importante perceber que ao realizar a primeira consulta, apesar dos dados estarem
organizados linearmente, estão concentrados em uma única coluna, necessitando de uma
avaliação de seus metadados e definição de uma estrutura de separação dos mesmos. Os
metadados de cada tipo estão no apêndice 6 – Metadados tabelas. O Hive possui ferramentas
com este fim de separação porém, com o objetivo de manter a durabilidade e consistência dos
dados, manteremos as tabelas originais inalteradas e usaremos expressões regulares para
modificar a estrutura dos dados e enviá-las a novas tabelas. As primeiras consultas mostram
uma separação delimitada por um caractere específico, por ponto e vírgula (;).
Desenvolveremos então um insert em uma nova tabela Hive a partir de um select dos dados
originais com a separação por colunas com funções regexp_extract(). Nesta função, o código
‘\073’ representa o ponto e vírgula. Separados os dados, teremos várias colunas onde os
registros estarão entre aspas, para isso criaremos uma expressão regular para selecionar apenas
os dados e descartar as aspas. Outra pequena alteração que deve ser feita refere-se as colunas
que contém valores monetários. Esses números denotam os valores decimais com vírgula, sendo
que os padrões do hive precisam que os valores decimais sejam representados por ponto. Isso
permitirá também a mudança dos tipos de string para double, com objetivo de fazer operações
matemáticas analíticas com esses números. Faremos também, na tabela de transferências, uma
separação da coluna ‘ano_mes’ em duas colunas separadas, uma para o ano, outra para o mês.
Isso facilitará as análises futuras de períodos temporais. Criação de tabela e códigos insert são
encontrados no apêndice 7 – Expressões Regulares para organização dos dados.

41
 3.6 Modificações finais para os tipos

Antes de entregarmos os dados para as visualizações, faremos alguns ajustes finais para
tornar a próxima etapa mais prática e rápida. Inicialmente, criaremos um pig Script para filtrar
os registros, selecionando todas as tuplas e descartando os headers. Os headers são registros
contidos em cada arquivo baixado do portal de transparência, com objetivo de identificar os
dados. Com as definições das colunas, esses headers são desnecessários. Dentro deste script, é
utilizado uma UDF Pig escrita em Java, com o objetivo de transformar os números na coluna
dos meses, em suas representações escritas por extenso. Esta UDF é adicionada ao código
através do comando “REGISTER” onde deve-se especificar caminho hdfs do código e o
comando “DEFINE” onde podemos realizar uma nova atribuição ao nome da função. Os
comandos “foreach” representam uma iteração – linha por linha – do código para gerar, através
do comando “generate” os itens escolhidos. Códigos presentes no apêndice 8- Header Script
e UDF mês (transferências).
O próximo passo resume-se em lançar mão de scripts Pig para criar tabelas específicas
dos somatórios do orçamento, receita e transferências, agrupados por ano e trimestres. Com a
limitação de memória, isto é essencial para que mais à frente não precisemos aglutinar muitas
operações em uma única consulta, que resultaria em um tempo excessivo de processamento ou
uma exceção por falta de memória. É nesta parte que os códigos terão a maior quantidade de
agrupamentos e somas, pois são as operações onde Pig se mostrou mais eficiente – na análise
de benchmarking - em relação ao Hive. Os códigos estão presentes no apêndice 9 –
Consolidados monetários anuais.

3.7 Montagem dos Notebooks Zeppelin

É aqui que os dados organizados nas etapas anteriores tomarão corpo, em um formato
visual sofisticado para as análises essenciais e suas descobertas e conclusões decorrentes. O
Zeppelin possui uma página específica, sendo acessado através do ip do host, na porta :9995
(no nosso caso 127.0.0.1:9995). A figura 11 abaixo representa a primeira visão do Zeppelin.
Para criar um notebook, basta acessar sua respectiva aba e selecionar o item ‘create new note’
e atribuir nome e o interpretador padrão.

42
 Figura 12 – Página Inicial Zeppelin

Ao criar o primeiro relatório, é necessário definir o interpretador que será utilizado para
criar os parágrafos no Zeppelin. Como já realizamos todos as transformações dos dados com
Hive e Pig, resta ao Zeppelin apenas, aplicar as consultas que resultarão nas visualizações finais.
Para isso, utilizaremos o interpretador %spark2.sql que nos proporciona a estrutura do spark
para execução rápida e persistência dos dados em memória, aliada a praticidade das consultas
SQL e alguns elementos de Scala para criação de formulários dinâmicos.
Sequencialmente, estruturaremos o modelo dos relatórios. Organizaremos os notebooks
em duas seções que representam as análises dos dados e serão os resultados finais deste
trabalho. É importante lembrar que ao decorrer das seções tentaremos interpretar os dados no
objetivo de identificar os motivos que levaram à crise financeira iniciada em 2014, medidas de
recuperação e possíveis dados estranhos que apareçam. Essa é uma abordagem importante visto
que estamos trabalhando com dados do portal de transparência do Governo Federal, que visa
mostrar com exatidão seu planejamento e execução monetária.

3.7.1 Primeira seção – Repasses por Tipo e Datas

Esta seção será responsável por gerar os relatórios contendo uma análise dos dados
relacionados aos repasses. A figura 13 abaixo representa os dois primeiros resultados. Temos
um gráfico em barras especificando anualmente os repasses distribuídos pelos Estados. Os

43
maiores repasses são destinados aos Estados de São Paulo, Minas Gerais, Bahia e Rio de
Janeiro, respectivamente. Isso faz sentido, uma vez que são os Estados mais populosos do
Brasil. Ao analisar a distribuição por regiões, com o ano de 2017 como referência, o Sudeste
possui 28,3% dos repasses, Sul com 12%, Norte com 16,7%, Nordeste possui a maior
porcentagem com 36.5% e Centro-Oeste com 6.5%. Há também no gráfico, o mais alto valor
repassado para um grupo vazio, e um outro grupo para distribuição de múltiplos Estados. O
grupo vazio representa os valores repassados diretamente aos municípios compostos
majoritariamente dos fundos municipais e com o maior valor direcionado a Organização Pan-
Americana de Saúde (OPAS), responsável pela organização do programa Mais Médicos. Os
dois juntos representam mais de quatro bilhões do orçamento dos Estados. Os repasses para
múltiplos Estados são referentes na maior parte ao Teto MAC (Medicina de alta complexidade)
e o PAB (Piso de Atenção Básica) repassado pelo Governo Federal via SUS para administração
dos Estados e municípios, ou seja, todos compõem gastos de saúde.
No segundo gráfico, temos a distribuição anual dos repasses pelo tipo de transferências,
sendo as ‘Constitucionais e Royalties’, que são as despesas obrigatórias determinadas pela
constituição, presentes no pacto federativo da União com os Estados e municípios e os
benefícios derivados de royalties. E também as transferências ‘Legais, Voluntárias e
Específicas’ que são os repasses previstos em leis específicas ou a títulos de cooperação, auxílio
e assistência financeira aos entes federados. Disto isto, verificando o gráfico, percebemos uma
estabilização dos valores entre os anos de 2014 e 2015 e uma alta em 2016 porém, temos em
2013 um valor ínfimo de 45 milhões de reais de repasses ‘Legais, Voluntários e Específicos’
em comparação aos outros anos. Este é um valor único direcionado a compensação financeira
dos Estados pelos Royalties do tratado de Itaipu. A ausência dos demais valores desta categoria
é um ponto de atenção e provavelmente representa dados faltosos de 2013.

44
 Figura 13 – Repasses por Tipo

No próximo parágrafo temos a distribuição anual dos repasses por “Tipo de

Favorecimento”. Podemos verificar um salto no valor disponibilizado para Entidades
Empresariais, que estava na faixa de quatrocentos e quinhentos milhões de reais nos anos de
2014 e 2015 indo para mais de seis bilhões de reais em 2016. Quase metade deste valor foi em
favor do Banco do Brasil em três bilhões de reais destinado a segurança pública durante os
jogos olímpicos e paraolímpicos do ‘Rio2016’. Em relação a entidades sem fins lucrativos, os
valores disponibilizados foram reduzidos ao longo dos anos, com os principais afetados sendo
o SENAI e SENAC, e a Fundação Butantan. Temos também um repasse em 2014 de noventa e
seis milhões de reais para um tipo “sem informação”. Apesar de serem valores pequenos no
contexto dos repasses, a não clareza desses dados impacta na transparência pois alguns destes
repasses estão ligados a diversas funções como saúde, esporte, ciência e tecnologia.
Através da figura 14, temos uma visão consolidada dos tipos de entidade favorecida
pelo repasses. Os maiores valores são referentes a reserva da administração pública estadual e
municipal, e para a disponibilização do Fundo Público. O principal ponto de atenção neste caso
é que mais de 60% da função dos gastos são relacionados a encargos especiais. Esses gastos se
refletem nos parágrafos subsequentes, onde no relatório de programas representam operações
especiais de transferências constitucionais e decorrentes de legislação específica. Ou seja, são
os repasses para gasto determinado pelos governadores dos estados e dos municípios
assinalados como o Fundo de Participação dos Estados (FPE) e dos Municípios (FPM), o Fundo
da Educação Básica (FUNDEB).

45
 Figura 14 – Tipo Favorecimento

Nas próximas views temos os repasses dispostos por períodos do ano. Na figura 15
abaixo a primeira visualização em linha mostra um vertiginoso aumento do repasse de 2013
para 2014, decorrente da provável não publicidade integral dos gastos do tipo ‘Legais,
Voluntários e Específicas’. Os gastos gerais aumentaram de 2014 até 2016 com uma leve queda
em 2017. Especificamente, olhando a distribuição trimestral dos repasses, o aumento
substancial no quarto trimestre de 2016 em relação ao mesmo período do ano anterior é o
responsável pelo aumento visto no quadro anual. Da mesma forma, na figura 16, encontramos
na visualização de repasses por mês que esse aumento ocorre especificamente em uma pequena
parte no mês de novembro de 2016, mas vertiginosamente em dezembro do mesmo ano. Sendo
que os grandes responsáveis por esse aumento são, mais uma vez, os encargos especiais pagos
pelos Estados. Os códigos que geraram as imagens desta seção estarão disponíveis no apêndice
10 – Zeppelin - Repasses por Tipo e Datas.

46
 Figura 15 – Repasses por ano e trimestres

Figura 16 – Repasses por mês

3.7.2 Segunda seção – Análise do Orçamento

Partindo para as análises que contém as receitas e orçamentos, temos o próximo

parágrafo na figura 17 que mostra a relação entre as transferências e o orçamento federal. O
resultado nos mostra que os repasses para Estados e municípios representam um valor muito
pequeno do orçamento da União, e são levemente reduzidos a cada ano em seu valor percentual,
14,05% em 2014, 13,72% em 2015, 13,61% em 2016 e 13,57% em 2017.

47
 Figura 17 – Relação Orçamento/Transferências

O próximo relatório contém o orçamento da união em suas diversas fases de avaliação.

O orçamento inicial, estimativa criada na LOA (Lei Orçamentária Anual) como preparação ao
exercício fiscal, o orçamento atualizado, que é o valor definitivo da previsão de gastos para o
ano fiscal correspondente. Por último, o orçamento realizado, referente ao valor devidamente
disponibilizado em crédito na projeção final do orçamento. Dito isto, temos na figura 18 abaixo
um orçamento atualizado – o orçamento final – quase 10% acima do valor estipulado
inicialmente em 2013. Os dois parâmetros foram se aproximando pelos próximos anos até o
último ponto em 2017, onde eles se equalizaram. Além disso, observando o orçamento
realizado, percebemos em 2017 o valor de execução com apenas 71,46% do final orçado, sendo
o menor valor da série histórica, e com discrepâncias similares nos anos anteriores.
Decompondo os valores orçamentários para encontrar a origem destes gastos, iniciamos a
análise a partir dos principais gastos da União: encargos especiais, previdência social, saúde e
educação, respectivamente. Na figura 19, temos um comparativo entre orçamento final e
realizado e podemos perceber que educação e saúde tem orçamento minúsculo comparado aos
gastos de encargos e previdência.

48
 Figura 18 – Orçamento anual

Figura 19 – Maiores gastos da União

Averiguando os maiores gastos denotados acima, temos na figura 20 o orçamento mais

relevante aos encargos, que são a amortização e o refinanciamento da dívida, os juros e encargos
da dívida pública. Isso contempla os valores corrigidos do refinanciamento da dívida mobiliária
e o principal da dívida mobiliária resgatada, valores decorrentes de pagamento e
refinanciamento dos títulos emitidos pelo Tesouro Nacional e pelo Banco Central para captação
de dinheiro com investidores para suas operações. Mesmo com a execução menor do que o
planejado final, esses são de longe os maiores gastos do Governo Federal. Em relação a
previdência social, temos as despesas correntes, ligadas a aposentadorias, benefícios e pensões
de servidores públicos e do INSS. O mais importante dos dados da previdência é que, diferentes
dos valores referentes aos encargos, eles têm uma margem constante de crescimento dos gastos
em sua série histórica. Também podemos observar que os gastos de previdência possuem os

49
valores de execução mais próximos do orçamento final estipulado, evidenciando a baixa
possibilidade de cortes, que ocorre em certa medida nas amortizações e refinanciamentos da
dívida. Realizando uma análise sobre esse crescimento dos gastos previdenciários, percebemos
um aumento de 9% de 2014 para 2015, 12,7% de 2015 para 2016 e 9,8% de 2016 para 2017.
Com uma média de crescimento da previdência de 10% ao ano, os custos de previdência social
alcançariam o orçamento atual em 2031.

Figura 20 – Principais gastos Encargos e Previdência

Por fim, averiguamos a relação entre a receita e o orçamento. Temos em todos os anos
um planejamento orçamentário acima da receita, tendo o seu menor percentual de 103.7% em
2016 e seu maior percentual de 130.97% em 2017. Porém, quanto a execução, ela se torna
menor que a receita, tendo o menor valor de 82.25% em 2015 e o maior valor de 94.02% em
2014. Os códigos que geraram as imagens desta seção estão no apêndice 11 – Zeppelin –
Análises do Orçamento.

50
 4 – CONCLUSÃO

Verificando todos os dados que permeiam a execução e distribuição do orçamento, é

perceptível como os gastos obrigatórios com encargos especiais, rolagem de dívida, pagamento
de juros e previdência, tanto no âmbito federal como o estadual e municipal, consomem grande
parte do orçamento, deixando pouca margem para os investimentos em saúde, educação,
segurança, entre outros, sendo setores tão caros para a população brasileira.
A partir deste trabalho, presenciamos um processo viável e eficiente de descoberta de
conhecimento a partir de técnicas atuais de Big Data. As ferramentas que permeiam o mundo
da Ciência dos Dados são abrangentes e permitem diversas abordagens, perspectivas e
especialidades de trabalho que se complementam no objetivo de buscar novas perspectivas para
empresas, organizações e indivíduos. A própria Hortonworks, que forneceu o framework HDP
utilizado neste trabalho, está constantemente atualizando sua solução com novas atualizações e
versões, onde eles corrigem bugs, melhoram a performance geral, e adicionam novas
ferramentas da Apache para enriquecer o framework. As pessoas interessadas em seguir por
esse caminho encontrarão também uma comunidade ativa pronta para tirar dúvidas em seu
fórum (https://community.hortonworks.com/index.html).
Sobre as possibilidades de trabalhos futuros relacionados a Big Data. Da mesma forma
que este focou na manipulação de dados que de alguma forma já estão estruturados, grande
parte do que é Big Data também se traduz em como receber dados de diferentes formatos
multimídia e como organizá-los. Para tanto, temos possibilidades de novos trabalhos nesse
quesito utilizando a plataforma HDF da própria Hortonworks. Podemos também explorar
diversas áreas da computação utilizando outras ferramentas do HDP. Como visto nas
especificações do framework na seção teórica, podemos explorar sobre segurança dos dados
utilizando o Ranger e o Atlas. Gerenciamento da infraestrutura de ambientes distribuídos com
Zookeeper e Oozie. Integração e fluxo de dados no ambiente distribuído utilizando o Falcon,
Flume e Kafka. Ou seja, há diversas formas de complementar e acrescer este trabalho.
No contexto temático, da mesma forma que utilizamos este processo para análise de
dados orçamentários do Executivo, outras análises podem ser feitas buscando informações
orçamentárias dos Poderes Judiciário e Legislativo. Portais de transparência específicos dos
Estados e Municípios ou ainda, uma análise completa com integração dos gastos de todos os
setores públicos do Brasil.

51
 A fronteira de possibilidades com os dados depende da criatividade, colaboração e
experiência dos profissionais envolvidos, estrutura adequada para o desenvolvimento dos
trabalhos de uma organizção e a vontade de buscar novas perspectivas nos dados. A área de Big
Data é um ramo da computação relativamente novo e em constante evolução. É um campo de
variedades de conhecimento que permite a criação de processos disruptivos que impactarão
profundamente a formação da sociedade do futuro.

52
 5 – APÊNDICES

Os relatórios Zeppelin de onde se originaram as figuras das seções 3.7.1 e 3.7.2 serão
exportados e armazenados em um CD para acesso e manipulação dos interessados, que deverão
atender aos devidos processos de instalação do framework HDP 2.6 para poder utilizá-los. O
código utilizado para criação da UDF Pig também estará disponível no CD.
Abaixo estão os códigos principais utilizados ao decorrer do trabalho. A numeração é
referência direta da ordem de utilização dos códigos no corpo do projeto.

1 - Código arquivo Bash para Conversão de arquivos

Comentários sobre cada comando estão apontados com #.

#!/bin/bash
#Script para modificar encoding de arquivos
#De ANSI
FROM_ENCODING="ISO-8859-1"
#Para UTF8
TO_ENCODING="UTF-8"
#Método de conversão
CONVERT=" iconv -f $FROM_ENCODING -t $TO_ENCODING"
#Loop de conversão para todos arquivos da pasta atual
for file in *.csv;
do $CONVERT "$file" -o "${file%.csv}_v2.csv";
done
#Permissões de usuário
for file in *;
do sudo chown gabriel "$file";
done
exit 0

2 - Comandos Linux de Conexão SFTP e Transferência de arquivos para VM

#iniciar serviços ssh no linux

sudo service ssh start
#conexão segura com a máquina virtual
ssh root@127.0.0.1 -p 2222
#instalar protocolo SFTP
sudo apt install sshfs
#criar diretório a ser compartilhado
mkdir ~/sshfs
#compartilhar diretório criado

53
sshfs -o port=2222 root@127.0.0.1:/root ~/sshfs

3 - Comando HDFS cópia de arquivos

CÓDIGO UTILIZADO:
hdfs dfs -copyFromLocal /root/transf_verba_fed /user/admin

EXPLICATIVO:
hdfs dfs –copyFromLocal [caminho_arquivo_pasta_origem]
[caminho_arquivo_pasta_destino]

4- Estrutura tabela inicial Hive

CÓDIGO UTILIZADO:
create table if not exists transf (dados string) stored as orc;

EXPLICATIVO:
create table if not exists [nome_tabela] (nome_coluna string) stored as orc;

5 – Script Pig agregar arquivos HDFS

CÓDIGO UTILIZADO:
a = load '/user/admin/hive/verba/transf_novo' using PigStorage() as (dados:chararray);
store a into 'transferencias.transf' using org.apache.hive.hcatalog.pig.HCatStorer();

-useHCatalog

EXPLICATIVO:
[relação] = load [/caminho_HDFS] using PigStorage() as ([alias]:[tipo]);
store [relação] into ‘[database].[tabela]’ using ork.apache.hive.hcatalog.pig.HCatStorer();

[argumento_Hcatalog]

6 – Metadados tabelas utilizadas

TRANSFERÊNCIAS:

Informações das transferências de recursos federais, constitucionais, legais ou voluntárias, para

estados, municípios, Distrito Federal, instituições privadas com e sem fins lucrativos e ao
exterior, realizados pelos órgãos e entidades da Administração Pública Federal, que executam
as despesas pelo Sistema Integrado de Administração Financeira do Governo Federal (Siafi).
Essas informações estão dispostas pelos seguintes dados:

Ano/Mês, Tipo de Transferência, Tipo do Favorecido, Unidade da Federação, Código

Município SIAFI, Nome do Município, Código Função, Nome Função, Código Subfunção,

54
Nome Subfunção, Código do Programa, Nome do Programa, Código da Ação, Nome da Ação,
Linguagem Cidadã, Código do Favorecido, Nome do Favorecido, Valor do Repasse

RECEITA:

Informações sobre as estimativas de arrecadação e os valores de fato arrecadados pelo Governo

Federal. Inclui os valores obtidos pelas diversas origens, tais como tributos, vendas de títulos e
bens, prestação de serviços, aluguéis e outras que compõem o orçamento da receita. Essas
informações estão dispostas pelos seguintes dados:

Código órgão Superior, Órgão Superior, Código do Órgão, Órgão, Código da Unidade Gestora,
Unidade Gestora, Categoria Econômica, Origem da Receita, Espécie Receita, Detalhes, Valor
Previsto, Valor Lançado, Valor Realizado, Percentual Realizado, Data de Lançamento, Ano

ORÇAMENTO:

Informações sobre o planejamento do governo quanto às expectativas de obtenção de receita e

limites de gastos com suas despesas. Essas informações estão dispostas pelos seguintes dados:

Exercício, Código Órgão Superior, Órgão Superior, Código Órgão Subordinado, Órgão
Subordinado, Código Unidade Orçamentária, Unidade Orçamentária, Código Função, Função,
Código Subfunção, Nome Subfunção, Código Programa Orçamentário, Nome Programa
Orçamentário, Código Ação, Ação, Código Categoria Econômica, Nome Categoria Econômica,
Código Grupo Despesa, Grupo Despesa, Código Elemento Despesa, Elemento Despesa,
Orçamento Inicial, Orçamento Atualizado, Orçamento Realizado.

7 – Expressões Regulares para organização dos dados

TABELA HIVE QUE RECEBERÁ OS DADOS DE TRANSFERÊNCIA:

create table if not exists transf_separado(ano_mes string, tipo_transf string, tipo_favorecido

string, uf string, cod_municipio_siafi string, nome_municipio string, cod_funcao string,
nome_funcao string, cod_subfuncao string, nome_subfuncao string, cod_programa string,
nome_programa string, cod_acao string, nome_acao string, linguagem_cidada string,
cod_favorecido string, nome_favorecido string, valor_repasse string) stored as orc;

SEPARAR COLUNAS:

insert overwrite table transf_separado select

regexp_extract(dados, '^(([^\073]*)){1}',1) ano_mes,
regexp_extract(dados, '^(([^\073]*)\073?){2}',2) tipo_transf,
regexp_extract(dados, '^(([^\073]*)\073?){3}',2) tipo_favorecido,
regexp_extract(dados, '^(([^\073]*)\073?){4}',2) uf,
regexp_extract(dados, '^(([^\073]*)\073?){5}',2) cod_municipio_siafi,
regexp_extract(dados, '^(([^\073]*)\073?){6}',2) nome_municipio,

55
 regexp_extract(dados, '^(([^\073]*)\073?){7}',2) cod_funcao,
regexp_extract(dados, '^(([^\073]*)\073?){8}',2) nome_funcao,
regexp_extract(dados, '^(([^\073]*)\073?){9}',2) cod_subfuncao,
regexp_extract(dados, '^(([^\073]*)\073?){10}',2) nome_subfuncao,
regexp_extract(dados, '^(([^\073]*)\073?){11}',2) cod_programa,
regexp_extract(dados, '^(([^\073]*)\073?){12}',2) nome_programa,
regexp_extract(dados, '^(([^\073]*)\073?){13}',2) cod_acao,
regexp_extract(dados, '^(([^\073]*)\073?){14}',2) nome_acao,
regexp_extract(dados, '^(([^\073]*)\073?){15}',2) linguagem_cidada,
regexp_extract(dados, '^(([^\073]*)\073?){16}',2) cod_favorecido,
regexp_extract(dados, '^(([^\073]*)\073?){17}',2) nome_favorecido,
regexp_extract(dados, '^(([^\073]*)\073?){18}',2) valor_repasse
from transf;

RETIRAR ASPAS:

insert overwrite table transf_sem_aspas

select
regexp_extract(ano_mes, '^(?:"([^"]*)"?)',1) ano_mes,
regexp_extract(tipo_transf, '^(?:"([^"]*)"?)',1) tipo_transf,
regexp_extract(tipo_favorecido, '^(?:"([^"]*)"?)',1) tipo_favorecido,
regexp_extract(uf, '^(?:"([^"]*)"?)',1) uf,
regexp_extract(cod_municipio_siafi, '^(?:"([^"]*)"?)',1) cod_municipio_siafi,
regexp_extract(nome_municipio, '^(?:"([^"]*)"?)',1) nome_municipio,
regexp_extract(cod_funcao, '^(?:"([^"]*)"?)',1) cod_funcao,
regexp_extract(nome_funcao, '^(?:"([^"]*)"?)',1) nome_funcao,
regexp_extract(cod_subfuncao, '^(?:"([^"]*)"?)',1) cod_subfuncao,
regexp_extract(nome_subfuncao, '^(?:"([^"]*)"?)',1) nome_subfuncao,
regexp_extract(cod_programa, '^(?:"([^"]*)"?)',1) cod_programa,
regexp_extract(nome_programa, '^(?:"([^"]*)"?)',1) nome_programa,
regexp_extract(cod_acao, '^(?:"([^"]*)"?)',1) cod_acao,
regexp_extract(nome_acao, '^(?:"([^"]*)"?)',1) nome_acao,
regexp_extract(linguagem_cidada, '^(?:"([^"]*)"?)',1) linguagem_cidada,
regexp_extract(cod_favorecido, '^(?:"([^"]*)"?)',1) cod_favorecido,
regexp_extract(nome_favorecido, '^(?:"([^"]*)"?)',1) nome_favorecido,
regexp_extract(valor_repasse, '^(?:"([^"]*)"?)',1) valor_repasse
from transf_separado;

TROCAR VÍRGULA POR PONTO:

insert overwrite table transf_sem_aspas

select
ano_mes, tipo_transf, tipo_favorecido, uf, cod_municipio_siafi, nome_municipio,
cod_funcao, nome_funcao, cod_subfuncao, nome_subfuncao, cod_programa,
nome_programa, cod_acao, nome_acao, linguagem_cidada, cod_favorecido,
nome_favorecido,
regexp_replace(valor_repasse, '\,', '\.') valor_repasse
from transf_sem_aspas;

56
SEPARAR ANO E MÊS EM TABELAS DISTINTAS:

insert overwrite table transf_final

select tipo_transf, tipo_favorecido, uf, cod_municipio_siafi, nome_municipio, cod_funcao,
nome_funcao, cod_subfuncao, nome_subfuncao, cod_programa, nome_programa, cod_acao,
nome_acao, linguagem_cidada,cod_favorecido,nome_favorecido,valor_repasse,
regexp_extract(ano_mes, '([0-9]{2})$' ,1) mes,
regexp_extract(ano_mes, '^([0-9]{4})' ,1) ano
from transf_sem_aspas;

8- Header Script com UDF mês (transferências)

HEADER SCRIPT:

REGISTER hdfs:///user/admin/.pigJars/pigUDF.jar
DEFINE pigUDF org.apache.pig.udf.pigUDF();
a = load 'transferencias.transf
using org.apache.hive.hcatalog.pig.HCatLoader() as (ano_mes:chararray,
tipo_transf:chararray, tipo_favorecido:chararray, uf:chararray, cod_municipio_siafi:chararray,
nome_municipio:chararray, cod_funcao:chararray, nome_funcao:chararray,
cod_subfuncao:chararray, nome_subfuncao:chararray, cod_programa:chararray,
nome_programa:chararray, cod_acao:chararray, nome_acao:chararray,
linguagem_cidada:chararray, cod_favorecido:chararray, nome_favorecido:chararray,
valor_repasse:float, ano:chararray, mes:chararray);
b = foreach a generate $1..$18,
pigUDF($19) as mes:chararray;
c = filter b by ($2!='UF');
store c into 'transferencias.final' using org.apache.hive.hcatalog.pig.HCatStorer();

CÓDIGO DA UDF pigUDF():

DEPENDÊNCIAS MAVEN:

<dependency>
<groupId>org.apache.pig</groupId>
<artifactId>pig</artifactId>
<version>0.15.0</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-core</artifactId>
<version>0.20.2</version>
</dependency>

57
CÓDIGO JAVA:

package com;
import java.io.IOException;
import org.apache.pig.EvalFunc;
import org.apache.pig.data.Tuple;

public class Month extends EvalFunc<String>{

@Override
public String exec(Tuple a) throws IOException {
if(a == null || a.size() == 0){
return null;}
String i = (String)a.get(0);
String output;
if(i == "01" ){
output = "janeiro";
return output.toUpperCase();}
else if (i == "02"){
output = "fevereiro";
return output.toUpperCase();}
else if (i == "03"){
output = "março";
return output.toUpperCase(); }
else if (i == "04"){
output = "abril";
return output.toUpperCase();}
else if (i == "05"){
output = "maio";
return output.toUpperCase();}
else if (i == "06"){
output = "junho";
return output.toUpperCase();}
else if (i == "07"){
output = "julho";
return output.toUpperCase();}
else if (i == "08"){
output = "agosto";
return output.toUpperCase();}
else if (i == "09"){
output = "setembro";
return output.toUpperCase();}
else if (i == "10"){
output = "outubro";
return output.toUpperCase();}
else if (i == "11"){
output = "novembro";
return output.toUpperCase();}

58
 else if (i == "12"){
output = "dezembro";
return output.toUpperCase();}
else
return "";
}
}

9 – Consolidados monetários anuais

Todos os códigos são armazenados em uma tabela hive no formato da saída da última relação
apresentada no script.

SCRIPT CONSOLIDADO DE TRANSFERÊNCIAS:

a = load 'transferencias.final'
using org.apache.hive.hcatalog.pig.HCatLoader()
as (tipo_transf:chararray, tipo_favorecido:chararray, uf:chararray,
cod_municipio_siafi:chararray, nome_municipio:chararray, cod_funcao:chararray,
nome_funcao:chararray, cod_subfuncao:chararray, nome_subfuncao:chararray,
cod_programa:chararray, nome_programa:chararray, cod_acao:chararray,
nome_acao:chararray, linguagem_cidada:chararray, cod_favorecido:chararray,
nome_favorecido:chararray, valor_repasse:double, ano:chararray, mes:chararray);
b = foreach a generate $17 as ano, $16 as valor_repasse;
c = group b by ano;
d = foreach c generate $0 as ano, SUM(b.valor_repasse) as repasse;
store d into 'transferencias.consolidado_transferencia_ano' using
org.apache.hive.hcatalog.pig.HCatStorer();

SCRIPT CONSOLIDADO DE ORÇAMENTO:

a = load 'transferencias.orcamento_final'
using org.apache.hive.hcatalog.pig.HCatLoader()
as (exercicio:chararray, cod_orgao_superior:chararray, orgao_superior:chararray,
cod_orgao_subordinado:chararray,
orgao_subordinado:chararray, cod_unidade_orcamentaria:chararray,
unidade_orcamentaria:chararray, cod_funcao:chararray, funcao:chararray,
cod_subfuncao:chararray, subfuncao:chararraycod_programa_orcamentario:chararray,
programa_orcamentario:chararray, cod_acao:chararray, acao:chararray,
cod_categoria_economica:chararray, categoria_economica:chararray,
cod_grupo_despesa:chararray, grupo_despesa:chararray, cod_elemento_despesa:chararray,
elemento_despesa:chararray, orcamento_inicial:double,
orcamento_atualizado:double, orcamento_realizado:double);
b = foreach a generate $0 as ano, $21 as valor_inicial, $22 as valor_atualizado, $23 as
valor_realizado;
c = group b by ano;
d = foreach c generate $0 as ano, SUM(b.valor_inicial) as orcamento_inicial,

59
SUM(b.valor_atualizado) as orcamento_atualizado,
SUM(b.valor_realizado) as orcamento_realizado;
store d into 'transferencias.consolidado_orcamento_ano' using
org.apache.hive.hcatalog.pig.HCatStorer();

SCRIPT CONSOLIDADO DA RECEITA:

a = load 'transferencias.receita_final'
using org.apache.hive.hcatalog.pig.HCatLoader()
as (cod_orgao_superior:chararray, orgao_superior:chararray,
cod_orgao:chararray, orgao:chararray, cod_unidade_gestora:chararray,
unidade_gestora:chararray, categoria_economica:chararray, origem_receita:chararray,
especie_receita:chararray, detalhes:chararray, valor_previsto:double, valor_lancado:double,
valor_realizado:double, percentual_realizado:float,
data_lancamento:chararray, ano:chararray);
b = foreach a generate $15 as ano, $12 as valor_realizado;
c = group b by ano;
d = foreach c generate $0 as ano, SUM(b.valor_realizado) as receita;
store d into 'transferencias.consolidado_receita_ano' using
org.apache.hive.hcatalog.pig.HcatStorer();

SCRIPT TRANSFERÊNCIA TRIMESTRAL:

a = load 'transferencias.transf_final'
using org.apache.hive.hcatalog.pig.HCatLoader()
as (tipo_transf:chararray, tipo_favorecido:chararray, uf:chararray,
cod_municipio_siafi:chararray, nome_municipio:chararray, cod_funcao:chararray,
nome_funcao:chararray,
cod_subfuncao:chararray, nome_subfuncao:chararray, cod_programa:chararray,
nome_programa:chararray,
cod_acao:chararray, nome_acao:chararray, linguagem_cidada:chararray,
cod_favorecido:chararray,
nome_favorecido:chararray, valor_repasse:double, ano:chararray, mes:chararray);
b = foreach a generate $17 as ano, $16 as valor_repasse, $18 as mes;
b1 = filter b by (mes == 'JANEIRO' or mes == 'FEVEREIRO' or mes == 'MARÇO');
b2 = filter b by (mes == 'ABRIL' or mes == 'MAIO' or mes == 'JUNHO');
b3 = filter b by (mes == 'JULHO' or mes == 'AGOSTO' or mes == 'SETEMBRO');
b4 = filter b by (mes == 'OUTUBRO' or mes == 'NOVEMBRO' or mes == 'DEZEMBRO');
c1 = group b1 by ano;
c2 = group b2 by ano;
c3 = group b3 by ano;
c4 = group b4 by ano;
d1 = foreach c1 generate $0 as ano, SUM(b1.$1) as repasse;
d2 = foreach c2 generate $0 as ano, SUM(b2.$1) as repasse;
d3 = foreach c3 generate $0 as ano, SUM(b3.$1) as repasse;
d4 = foreach c4 generate $0 as ano, SUM(b4.$1) as repasse;
final1 = join d1 by ano, d2 by ano, d3 by ano, d4 by ano;

60
final2 = foreach final1 generate $0 as ano, $1 as primeiro, $3 as segundo, $5 as terceiro, $7 as
quarto;
store final2 into 'transferencias.trimestre' using org.apache.hive.hcatalog.pig.HCatStorer();

10 – Zeppelin - Repasses por Tipo e Datas

INTERPRETADOR - %spark2.sql

REPASSE POR ESTADOS

select ano, uf, sum(valor_repasse) as repasse from transferencias.transf_final group by ano, uf
order by repasse

REPASSE POR TIPO DE TRANSFERÊNCIA

select ano, tipo_transf, sum(valor_repasse) as soma from transferencias.transf_final group by
ano, tipo_transf order by soma

REPASSE POR TIPO DE FAVORECIMENTO

select ano, tipo_favorecido, sum(valor_repasse) as repasse from transferencias.transf_final
where tipo_transf = "${Tipo Transferência= ,Legais, Voluntárias e Específicas|Constitucionais
e Royalties}" group by ano, tipo_favorecido order by repasse desc

REPASSE POR FUNÇÃO

select ano, nome_funcao, sum(valor_repasse) as repasse from transferencias.transf_final
where tipo_favorecido = "${Tipo Favorecido=Fundo Público,Fundo Público|Administração
Pública Municipal|Administração Pública Estadual ou do Distrito Federal}" group by ano,
nome_funcao order by repasse desc

REPASSE POR PROGRAMA

select ano, nome_programa, sum(valor_repasse) as repasse from transferencias.transf_final
where nome_funcao = "${Função=ENCARGOS ESPECIAIS,ENCARGOS
ESPECIAIS|SAUDE|EDUCACAO}" group by ano, nome_programa having
repasse>"${Repasse=1000000000}" order by repasse desc

POR AÇÃO

61
select ano, nome_acao, sum(valor_repasse) as repasse from transferencias.transf_final group
by nome_acao, ano having repasse>10000000000

VALOR ANUAL TRANSFERENCIAS

select ano, sum(valor_repasse) as valor from transferencias.transf_final group by ano order by
ano

VALOR TRIMESTRAL TRANSFERENCIAS

select * from transferencias.trimestre

VALOR MENSAL TRANSFERENCIAS

select a.ano, a.mes, b.ordem, sum(a.valor_repasse) from transferencias.transf_final a inner
join transferencias.ordem b on (a.mes = b.mes) group by a.ano, a.mes, b.ordem order by
b.ordem

11 – Zeppelin – Análises do Orçamento

INTERPRETADOR - %spark2.sql

PERCENTAGEM DO ORÇAMENTO PARA TRANSFERENCIAS

select transf.ano, format_number(transf.repasse,2) as transferencias_estados,
format_number(orc.orcamento_realizado,2) as orcamento,
format_number((transf.repasse*100)/(orc.orcamento_realizado),2) as
percentagem_orcamento_estadua
from transferencias.consolidado_transferencia_ano transf
left join transferencias.orcamento_ano_percentagem orc
on (transf.ano=orc.ano) where transf.ano != 2013

DESTINO DO ORÇAMENTO
select transf.ano, transf.repasse as transferencias_estados, orc.orcamento_realizado as
orcamento_total,

62
(orc.orcamento_realizado - transf.repasse) as orcamento_federal from
transferencias.consolidado_transferencia_ano transf
left join transferencias.orcamento_ano_percentagem orc
on (transf.ano=orc.ano) where transf.ano = "${Ano=2014,2014|2015|2016|2017}"

ORÇAMENTO ANUAL DAS DESPESAS

select ano, format_number(orcamento_inicial,2) as Orcamento_inicial,
format_number(orcamento_atualizado,2) as Orcamento_atualizado,
format_number(percentagem_init_att,2) as Percentagem_atualizado,
format_number(orcamento_realizado,2) as Orcamento_executado,
format_number(percentagem_att_realizado,2) as Percentagem_realizado from
transferencias.orcamento_ano_percentagem

FUNÇÃO DO ORÇAMENTO
select exercicio, funcao, sum(orcamento_realizado) from transferencias.orcamento_final
where exercicio = "${Ano=2014,2014|2015|2016|2017}" group by exercicio, funcao order by
sum(orcamento_realizado) desc

ORÇAMENTO – GRUPO DE DESPESAS

select exercicio, grupo_despesa, sum(orcamento_atualizado) as atualizado,
sum(orcamento_realizado) as realizado from transferencias.orcamento_final where funcao =
"${Função=ENCARGOS ESPECIAIS,ENCARGOS ESPECIAIS|PREVIDENCIA
SOCIAL|SAUDE|EDUCACAO}" group by exercicio, grupo_despesa having
sum(orcamento_realizado)>"${Valor Repasse=9000000000}"

PERCENTAGEM DO ORÇAMENTO PÚBLICO COMPARADO A RECEITA

select a.ano, format_number(a.receita,2) as receita,
format_number(b.orcamento_atualizado,2) as orcamento_atualizado,
format_number(((b.orcamento_atualizado*100)/a.receita),2) as percentual_orc_final,
format_number(b.orcamento_realizado,2) as orcamento_executado,
format_number(((b.orcamento_realizado*100)/a.receita),2) as percentual_orc_executado
from transferencias.consolidado_receita_ano a
inner join transferencias.consolidado_orcamento_ano b
on (a.ano=b.ano)

63
6 - BIBLIOGRAFIA

MAYER-SCHÖNBERGER, V; CUKIER, K. Big Data: A Revolution That Will Transform

How We Live, Work, and Think, Editora: Eamon Dolan/Houghton Mifflin Harcourt, 2013

LANEY, D. 3D Data Management: Controlling Data Volume, Velocity, and Variety,

Gartner Group, 2001. Disponível em: https://blogs.gartner.com/doug-
laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-Velocity-and-
Variety.pdf
.
MARR., B. 2015. Why Only one of the 5 Vs of Big Data matters, IBM Blog. Disponível em:
http://www.ibmbigdatahub.com/blog/why-only-one-5-vs-big-data-really-matters

WINBLAD, A. Venture Investing & Hiring In Silicon Valley, CNBC Interview: 2012
Disponível em: http://video.cnbc.com/gallery/?video=3000074076

AGÊNCIA BRASIL EBC; 2016. Ajuste fiscal, crise nos estados e inflação; veja fatos da
economia em 2016. Disponível em: http://agenciabrasil.ebc.com.br/economia/noticia/2016-
12/ajuste-fiscal-crise-nos-estados-infla%C3%A7%C3%A3o-veja-o-que-marcou-a-economia-
em-2016

TANNIR, K. Optimizing Hadoop for MapReduce: 1. ed. Birmingham B3 2PB, Editora:

Packt Publishing, 2014. 11 p.

TURKINGTON, G.; MODERNA, G., Learning Hadoop 2. 1. ed. Birmingham B3 2PB,

Editora: Packt Publishing, 2015. 9 p.

BORTHAKUR, D. HDFS Architecture Guide. Apache Software Foundation, 2013.

Disponível em: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

APACHE HADOOP, Apache Hadoop YARN, 2016. Disponível em:

https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html

DAYONG, D., Apache Hive Essentials. 1. ed. Birmingham B3 2PB, Editora: Packt
Publishing, 2015. 54-56 p.

PROKOPP, C. ORC: An Intelligent Big Data file format for Hadoop and Hive. 2014.
Disponível em: http://www.semantikoz.com/blog/orc-intelligent-big-data-file-format-hadoop-
hive/

APACHE TEZ, Welcome to Apache Tez. Apache Software Foundation, 2016.

Disponível em: https://tez.apache.org/

MURTHY, A.; SAHA, B. INFOQ - What is Apache Tez?, 2014

Disponível em: https://www.infoq.com/articles/apache-tez-saha-murthy

64
HANSON, E. 2015. Vectorized Query Execution. Disponível em:
https://cwiki.apache.org/confluence/display/Hive/Vectorized+Query+Execution

GATES, A. Programming Pig, Editora: O’Rilley Media, California, 2011. 10 p.

APACHE PIG, Pig Latin Basics. Apache Software Foundation, 2016

Disponível em: http://pig.apache.org/docs/r0.17.0/basic.html

APACHE PIG, Getting Started. Apache Software Foundation, 2016

Disponível em: http://pig.apache.org/docs/r0.17.0/start.html#pl-statements

JAKOBUS, B.; MCBRIEN, P., Pig vs Hive: Benchmarking High Level Query Languages,
Imperial College London, 2013. Disponível em:
https://www.ibm.com/developerworks/library/ba-pigvhive/pighivebenchmarking.pdf

HORTONWORKS, Apache Zeppelin, 2017.

Disponível em: https://zeppelin.apache.org/

HEER, J., Interactive Visualization of Big Data O’Reilly Strata, 2013

Disponível em: http://radar.oreilly.com/2013/12/interactive-visualization-of-big-data.html

APACHE ZEPPELIN, Interpreters in Apache Zeppelin, 2016

Disponível em: https://zeppelin.apache.org/docs/latest/manual/interpreters.html

THOTTUVAIKKATUMANA, R., Apache Spark 2 For Beginners, Birmingham B3 2PB,

Editora: Packt Publishing, 2016. 12-14 p.; 31-32 p.

65