Avaliação do uso de Hadoop e MapReduce para
aumento de eficiência no gerenciamento de
dados biológicos
São José dos Campos
2019
Avaliação do uso de Hadoop e MapReduce para aumento
de eficiência no gerenciamento de dados biológicos
Trabalho de conclusão de curso de
gradua-ção apresentado ao Instituto de Ciência e
Tecnologia da Universidade Federal de São
Paulo como requisito parcial para a obtenção
do título de Bacharel(a) em Engenharia de
Computação.
Universidade Federal de São Paulo - UNIFESP
Instituto de Ciência e Tecnologia
Orientador: Prof
a. Dra. Daniela Leal Musa
São José dos Campos
2019
Na qualidade de titular dos direitos autorais, em consonância com a Lei de direitos autorais nº 9610/98, autorizo a publicação livre e gratuita desse trabalho no Repositório Institucional da UNIFESP ou em outro meio eletrônico da instituição, sem qualquer ressarcimento dos direitos autorais para leitura, impressão e/ou download em meio eletrônico para fins de divulgação intelectual, desde que citada a fonte.
Ficha catalográfica gerada automaticamente com dados fornecidos pelo(a) autor(a)
Wassef, Yasmin
Avaliação do uso de Hadoop e MapReduce para aumento de eficiência no gerenciamento de dados biológicos/ Yasmin Wassef
Orientação: Daniela Leal Musa-São José dos Campos, 2019. 89 p.
Evaluation of Hadoop and MapReduce in increasing efficiency in biological databases
Trabalho de Conclusão de Curso-Engenharia da Computação-Universidade Federal de São Paulo-Instituto de Ciência e Tecnologia, 2019.
1. Hadoop. 2. MapReduce. 3. Bancos de dados. 4. Bioinformática. I. Leal Musa, Daniela
WASSEF, Y. Avaliação do uso de Hadoop e MapReduce para aumento de
eficiência no gerenciamento de dados biológicos. 2019. 89 f. Trabalho de Conclusão
de Curso (Bacharelado em Engenharia de Computação) - Instituto de Ciência e Tecnologia,
Universidade Federal de São Paulo, São José dos Campos, 2019.
Folha Linha Onde se lê Leia-se
Avaliação do uso de Hadoop e MapReduce para aumento
de eficiência no gerenciamento de dados biológicos
Trabalho de conclusão de curso de
gradua-ção apresentado ao Instituto de Ciência e
Tecnologia da Universidade Federal de São
Paulo como requisito parcial para a obtenção
do título de Bacharel(a) em Engenharia de
Computação.
Trabalho aprovado. São José dos Campos, 04 de dezembro de 2019:
Prof
a. Dra. Daniela Leal Musa
Orientador
Prof. Dr. Álvaro Luiz Fazenda
Convidado 1
Prof. Dr. Reginaldo Massanobu
Kuroshu
Convidado 2
São José dos Campos
2019
Gostaria de agradecer a todos os mestres que contribuíram com a minha formação
acadêmica e profissional durante a minha vida, das várias áreas e instituições em que atuei
desde que comecei minha graduação.
Aos meus colegas de faculdade e amigos, companheiros nos momentos de dificuldade
e na troca de conhecimento e experiências, sem os quais não teria sido possível completar
essa jornada.
E agradecimentos excepcionais aos meus amigos Bela e Magno, que tanto me
auxiliaram com os momentos de alegria, descontração e também de estudo, sempre me
amparando quando necessário. Um último e mais especial agradecimento ao meu querido
amigo Welerson, que com sua insistência, ajuda e motivação, foi essencial para que essa
pesquisa fosse concluída.
Os avanços tecnológicos da era digital vem contribuindo para o crescimento exponencial do
volume de dados gerado pelo estilo de vida moderno, tornando relevante o estudo de Big
Data e seus métodos e técnicas. A Bioinformática segue o mesmo comportamento, visto
que as grandes revoluções tecnológicas na área vem facilitando a geração de diversos dados
genômicos e biológicos, se tornando uma ramificação da área de Big Data. A manutenção
e gerenciamento desse grande volume de dados muitas vezes extrapola a capacidade
de processamento das tecnologias tradicionais, fazendo com que se torne necessário o
estudo de novas tecnologias para processamento de dados, utilizando por exemplo sistemas
distribuídos. Tendo em vista essas questões, o estudo framework Apache Hadoop para
melhoria de performance de consultas a bases de dados biológicos em relação a bancos de
dados relacionais, através da realização de consultas em dados de anotações de polimorfismo
de nucleotídeo único em um sistema distribuído simulado. Para o volume e tipo de dados
utilizado, verificou-se que o overhead operacional e dificuldade de gerenciamento do sistema
distribuído acarretaram uma lentidão significativa de tempo de execução em relação a essas
mesmas operações sendo realizadas num banco relacional tradicional (PostgreSQL). Porém,
aumentando-se a escala do problema, foi possível avaliar que para o volume adequado de
dados a aplicação de Hadoop se torna mais vantajosa do que bancos relacionais, mas é
preciso avaliar as condições da aplicação em questão para escolher a tecnologia que possa
trazer mais benefícios.
The technological advances of the digital age have contributed to the exponential growth
of available data generated by the modern lifestyle, turning Big Data’s methods and
techniques a relevant research area. Bioinformatics follows the same behavior since the
technological revolutions which facilitated the generation of genomic and biological data,
creating a new branch in the study of Big Data related especifically to its applications
in biological datasets. Maintaining and managing these large datasets often exceeds
the processing power of current technologies, making it necessary to research new data
processing techniques, such as distributed systems. In regard to the aforementioned topics,
the present study evaluated the use of the Apache Hadoop framework in improving the
performance of queries to biological datasets in comparison to relational databases, by
performing queries on single nucleotide polymorphism annotation data in a simulated
distributed system. With the volume and type of data used, the operational overhead and
management difficulty of the distributed system led to a significantly slower execution
time compared to the same queries being performed in a traditional relational database
(PostgreSQL). However, when increasing the size of the problem, it was possible to
conclude that for the appropriate volume of data Hadoop can have better performance
than relational databases, but the scenario of the specific application must be evaluated
to choose the most suitable technology for the given problem.
Figura 1 – Funcionamento do algoritmo de MapReduce.
. . . .
32
Figura 2 – Arquitetura básica do Hive.
. . . .
33
Figura 3 – Esquema de banco relacional.
. . . .
41
Figura 4 – Gráfico relacionando tempos de consulta.
. . . .
49
Figura 5 – Gráfico de aproveitamento de tempo de consulta.
. . . .
49
Figura 6 – Gráfico relacionando tempos de consulta para ambas as massas de dados.
53
Figura 7 – Gráfico de aproveitamento para ambas as massas de dados.
. . . .
53
Tabela 1 – Dados de entrada para as tabelas no Hive.
. . . .
42
Tabela 2 – Comparação entre consultas Hive e PostgreSQL.
. . . .
45
Tabela 3 – Tempo total vs. tempo efetivo de execução das consultas.
. . . .
48
Tabela 4 – Número total de jobs vs. número efetivo de jobs.
. . . .
48
Tabela 5 – Duplicação da massa de dados para as tabelas no Hive.
. . . .
52
API
Application programming interface
AST
Árvore de sintaxe abstrata
BLAST
Basic Local Alignment Search Tool
CLI
Command-line interface - Interface de linha de comando
CSV
Comma-separated values
DAG
Directed acyclic graph - Grafo acíclico direcionado
GSEA
Gene Set Enrichment Analysis
HDFS
Hadoop Distributed File System
NGS
Next-generation sequencing
NoSQL
Not only SQL
SGBDR
Sistema de gerenciamento de bancos de dados relacionais
SNP
Single-nucleotide polymorphism - Polimorfismo de nucleotídeo único
SQL
Structured Query Language
SSD
Solid-state Drive
UI
User Interface - Interface de Usuário
Sumário
1
INTRODUÇÃO
. . . 23
2
OBJETIVOS
. . . 25
2.1
Objetivo Geral
. . . 25
2.2
Objetivos Específicos
. . . 25
3
MOTIVAÇÃO
. . . 27
4
FUNDAMENTAÇÃO TEÓRICA
. . . 29
4.1
Big Data
. . . 29
4.2
Técnicas e tecnologias de Big Data
. . . 29
4.2.1
Lei de Ahmdal
. . . .
30
4.2.2
Hadoop
. . . .
31
4.2.3
MapReduce
. . . .
31
4.2.4
Apache Hive
. . . .
33
4.3
Hadoop e MapReduce em Bioinformática
. . . 34
4.4
Bancos de dados biológicos e seus recursos
. . . 35
4.4.1
Desafios relacionados
. . . .
36
5
METODOLOGIA
. . . 39
5.1
Tipo de pesquisa
. . . 39
5.2
Materiais
. . . 39
5.3
Métodos
. . . 40
6
RESULTADOS
. . . 45
6.1
Overhead operacional
. . . 45
6.2
Tipo e volume de dados
. . . 50
6.3
Simulação do sistema distribuído
. . . 51
6.4
Aumento da massa de dados
. . . 51
7
CONCLUSÃO
. . . 55
7.1
Trabalhos futuros
. . . 56
APÊNDICES
61
APÊNDICE A – SCRIPT DE CRIAÇÃO DE TABELAS NO HIVE
. 63
APÊNDICE B – LOG DA CONSULTA 1
. . . 65
APÊNDICE C – LOG DA CONSULTA 2
. . . 69
APÊNDICE D – LOG DA CONSULTA 3
. . . 71
APÊNDICE E – LOG DA CONSULTA 4
. . . 75
APÊNDICE F – LOG DA CONSULTA 5
. . . 77
APÊNDICE G – LOG DA CONSULTA 6
. . . 81
APÊNDICE H – LOG DA CONSULTA 7
. . . 85
1 Introdução
Com o advento da tecnologia na era digital, a quantidade de dados produzida
pelos recentes aparatos tecnológicos vem crescendo exponencialmente, o que faz necessário
com que sejam desenvolvidos métodos e técnicas que sejam capazes de analisar e extrair
informações relevantes desse grande conjunto de dados.
O termo Big Data foi cunhado para se referir a esses grandes conjuntos de dados
cuja dimensão extrapola a capacidade de processamento de tecnologias tradicionais (
PA-TEL; BIRLA; NAIR
,
2012
). Diversos softwares e métodos de processamento vem sendo
desenvolvidos especialmente para lidar com os desafios apresentados por essa área, entre
eles computação em grid, sistemas de arquivos distribuídos, bases de dados distribuídas,
sistemas de armazenamento escaláveis, processamento paralelo, entre outros (
PATEL;
BIRLA; NAIR
,
2012
).
A Bioinformática não diverge desse comportamento; o uso de computação de alto
desempenho no estudo de biologia molecular, genética e proteômica nas últimas décadas
vem permitindo revoluções na área, com criação de grandes bases de dados biológicos para
estudo (
CHEN; HUANG; WU
,
2017
). Essas bases de dados, em sua maioria, se utilizam de
bancos de dados relacionais para estruturação e armazenamento, porém devido ao volume
e complexidade dos dados biológicos percebe-se que bancos de dados relacionais são pouco
eficientes nesse contexto (
SCHULZ et al.
,
2016
).
Bancos de dados relacionais oferecem aumento de eficiência de armazenamento
em relação a arquivos simples, porém operações de inserção e busca podem ser custosas
para grandes volumes de dados, como é o caso de dados biológicos (
SCHULZ et al.
,
2016
).
Outros métodos de gerenciamento de dados tem sido usados para esse fim, como é o caso
de sistemas NoSQL (Not Only SQL) em especial bancos de dados orientados a documentos,
que podem melhorar a eficiência de operações de busca e inserção de dados biológicos
(
SCHULZ et al.
,
2016
); mas, levando em consideração que a análise desses dados pode
ser uma ramificação de estudos de Big Data, é possível que a utilização de metodologias
e softwares dessa área melhorem a eficiência de inserção e consulta em bancos de dados
biológicos.
A utilização de tecnologias como Hadoop e MapReduce, comumente aplicadas
ao processamento paralelo de grandes volumes de dados, podem ser utilizadas para
melhorar a eficiência do gerenciamento de dados biológicos. Essas tecnologias já vêm
sido aplicadas com sucesso na análise de dados de sequenciamento de genomas, como no
software Cloudburst desenvolvido por Michael C. Schatz (
CBCB
,
2019
), e em outras áreas
da Bioinformática como na comparação de sequências biológicas primárias com BLAST
24 Capítulo 1. Introdução
(Basic Local Alignment Search Tool) e GSEA (Gene Set Enrichment Analysis) (
TAYLOR
,
2010
).
A utilização de Hadoop e MapReduce em bancos de dados NoSQL para outras
aplicações científicas relacionadas a Big Data também apresentou melhora de tempo
de consulta e inserção (
ALSHAMMARI; BAJWA; LEE
,
2015
), o que leva a crer que
sua aplicação para bancos de dados biológicos também poderá acarretar melhorias de
performance.
2 Objetivos
2.1
Objetivo Geral
O objetivo geral desse projeto é avaliar se técnicas de processamento paralelo como
Hadoop e MapReduce podem ser aplicadas a bancos de dados biológicos para melhoria de
desempenho de operações de consulta, em comparação com o uso de apenas bancos de
dados relacionais.
2.2
Objetivos Específicos
Os objetivos específicos do projeto são:
• Estudar a literatura a respeito de técnicas já existentes para o gerenciamento de
dados biológicos, em especial dados de anotações de polimorfismo de nucleotídeo
único (SNPs);
• Estudar o framework Hadoop Apache, o sistema de arquivos Hadoop Distributed
File System (HDFS) e MapReduce;
• Analisar o uso da ferramenta Hive QL - para gerenciamento de consultas com
Hadoop;
• Criar scripts de importação dos dados no sistema distribuído criado com Hadoop;
• Implementar e executar consultas nos dados;
• Comparar os resultados obtidos com os tempos de execução no banco de dados
relacional.
3 Motivação
A quantidade de dados produzidas pelo conjunto da sociedade como um todo vem
crescendo exponencialmente nas últimas décadas, o que traz à tona a necessidade da
criação de métodos e tecnologias para lidar com esse grande volume de dados, tanto na
análise quanto no armazenamento eficiente.
Big Data está quase que onipresente no cotidiano do cidadão moderno, abrangendo
áreas como redes de sensores de satélites e dados geo-espaciais, dados de comportamento
e tendências de redes sociais, astronomia, ciências atmosféricas, telecomunicações, entre
outros (
PATEL; BIRLA; NAIR
,
2012
). Por isso, é imprescindível estudar técnicas de
armazenamento de dados que permitam o contínuo avanço dessas tecnologias sem impor
gargalos de desempenho.
Em Biologia Genética, o avanço das tecnologias de sequenciamento de genomas tem
tornado os custos relacionados a esse sequenciamento cada vez menores, fazendo com que
o volume destes dados cresça rapidamente (
SCHULZ et al.
,
2016
). Assim, surge o desafio
de gerenciar tais informações de maneira eficiente, tanto em relação a espaço em disco
quanto a velocidade de escrita e acesso, que é cada vez maior. Tal dificuldade acarreta
em graves impeditivos para o avanço do conhecimento em Bioinformática, pois ao mesmo
tempo que há uma grande quantidade de dados sendo gerados, eles não são processados
na mesma velocidade.
Pesquisas nessa área necessitam de comparações genéticas entre diferentes espécies;
de forma a entender o funcionamento, ancestralidade e função de diversos alelos comum
a diferentes organismos (
CHEN; HUANG; WU
,
2017
). Os resultados obtidos ajudam a
compreender melhor o funcionamento do genoma humano, o que por sua vez tem infindáveis
aplicações na busca de tratamento de diversas doenças genéticas e aplicações na medicina
em geral.
Estudos baseados em comparações de alelos e alinhamento de sequências em
diferentes genomas, por sua vez, somente podem ser realizados se as bases de dados que
armazenam esses dados forem estruturadas de forma eficiente, permitindo a consulta
e comparação de dados sem grandes empecilhos. Dessa forma, vê-se a necessidade do
estudo de técnicas de otimização para o armazenamento desses dados, como proposto
nesse projeto.
4 Fundamentação Teórica
Este capítulo apresenta uma revisão dos conceitos teóricos fundamentais para o
desenvolvimento dessa pesquisa.
4.1
Big Data
O termo “Big Data” é utilizado para se referir a grandes conjuntos de dados
cujo tamanho extrapola a habilidade de softwares comuns de analisá-los e gerenciá-los
dentro de um período de tempo tolerável (
PATEL; BIRLA; NAIR
,
2012
). Os tamanhos
dos conjuntos de dados em questão podem variar desde alguns terabytes a dezenas de
petabytes, e por conta de seu volume apresentam desafios para coleta, armazenamento,
busca, compartilhamento e visualização (
PATEL; BIRLA; NAIR
,
2012
).
Conjuntos de dados vêm crescendo rapidamente, principalmente pela contribuição
de diversos dispositivos IoT (Internet of Things) que estão constantemente coletando
informações, como celulares, câmeras, microfones, redes de sensores sem fio, entre outros
(
GIGAOM
,
2019
). A capacidade mundial de armazenamento de informação per-capita tem
dobrado a cada 40 anos desde os anos 80 (
HILBERT; LÓPEZ
,
2011
), e prevê-se que o
volume global de dados irá crescer exponencialmente de 4.4 zettabytes a 44 zettabytes entre
2013 e 2020 (
REINSEL; GANTZ; RYDNING
,
2017
), podendo chegar a 163 zettabytes em
2025.
Para processar e analisar esse grande volume de dados, algumas tecnologias
rela-cionadas a variedades específicas de conjuntos de dados vêm sendo desenvolvidas, como
business intelligence, computação em nuvem e bases de dados distribuídos. Técnicas de
análise mais abrangentes também estão em ascensão, como teste A/B, aprendizado de
máquina e processamento de linguagem natural (
MANYIKA
,
2011
).
4.2
Técnicas e tecnologias de Big Data
Big Data requer tecnologias excepcionais para eficientemente processar grandes
quantidades de dados dentro de um limite de tempo tolerável. Algumas tecnologias que vêm
sendo aplicadas a essa área incluem computação em grid, sistemas de arquivos distribuídos,
bases de dados distribuídas, sistemas de armazenamento escaláveis e processamento
paralelo (
PATEL; BIRLA; NAIR
,
2012
). Essas técnicas e tecnologias são desenvolvidas
com conhecimentos de diversas áreas de estudo, como estatística, ciência da computação,
matemática aplicada e economia, e por isso precisam ser flexíveis e multidisciplinares, visto
30 Capítulo 4. Fundamentação Teórica
que a abrangência de aplicações também é vasta (
PATEL; BIRLA; NAIR
,
2012
).
4.2.1
Lei de Ahmdal
Em arquitetura de computadores, a lei de Ahmdal é uma fórmula que prevê o
speedup teórico do tempo de execução de uma tarefa fixa quando os recursos do sistema
são melhorados, comumente utilizada em computação paralela para prever o speedup
com o aumento do número de processadores. Ela pode ser formulada como: (
MCCOOL;
REINDERS; ROBISON
,
2012
)
S
latência(s) =
1
(1 − p) +
psOnde:
• S
latência(s) é o speedup teórico de execução da tarefa completa;
• s é o speedup da porção da tarefa que se beneficia de melhoria de recursos;
• p é a proporção da tarefa que se beneficia da melhoria de recursos.
Com isso, tem-se:
S
latência(s) ≤ 1/(1 − p)
lim
s→∞S
latência(s) = 1/(1 − p)
(4.1)
O que mostra que o speedup teórico da tarefa como um todo aumenta com melhoria
de recursos do sistema, porém está sempre limitado pela parte do problema que não se
beneficia dessa melhoria (porção serial do problema) (
MCCOOL; REINDERS; ROBISON
,
2012
). Como exemplo, pode-se utilizar um programa que processa arquivos de um disco,
em que uma parte do programa lê o diretório e cria uma lista de arquivos na memória,
e outra passa cada arquivo para threads individuais que farão o processamento. A parte
sequencial, de leitura do diretório, configura o limite do speedup máximo, pois não se
beneficiaria do aumento de recursos. O speedup apenas se aplica à porção paralelizável
do programa, que seria o processamento paralelo dos arquivos por threads. Dessa forma,
quanto maior a porção paralelizável de um problema, mais ele pode se beneficiar da
utilização de processamento paralelo distribuído.
Em Big Data, o volume de dados e o tipo de processamento realizado sobre eles
é tão massivo que acaba por ser comparativamente muito maior do que a porção de
operações sequenciais do problema, logo são problemas que se beneficiam diretamente
do processamento distribuído e da melhoria de recursos do sistema. Dessa forma, a lei
de Ahmdal se torna uma ferramenta interessante para avaliar a possível melhoria de
performance que se pode obter com computação distribuída.
4.2.2
Hadoop
Apache Hadoop é uma coletânea de softwares que utilizam redes de computadores
para fazer processamento paralelo de quantidades massivas de dados. Através do modelo
de programação MapReduce, ele fornece um framework robusta para processamento e
armazenamento distribuído de Big Data (
HADOOP
,
2019
). A estratégia de design dos
módulos que compõem o Hadoop se baseia no princípio fundamental de que hardware está
propenso a falhas recorrentes, cabendo ao software lidar com essas ocorrências; por isso o
framework é tolerante a falhas e robusto (
HADOOP
,
2019
).
O framework Hadoop é composto dos seguintes módulos (
HADOOP
,
2019
):
• Hadoop Common: contém bibliotecas e ferramentas adicionais necessários aos outro
módulos;
• Hadoop Distributed File System (HDFS): sistema de arquivos distribuído responsável
por gerenciar os dados armazenados;
• Hadoop YARN : responsável por gerenciar os recursos computacionais do cluster e
usá-los para gerenciar as aplicações de usuário;
• Hadoop MapReduce: implementação do modelo de programação MapReduce para
processamento de dados em larga escala.
Para fazer o gerenciamento de arquivos e transferência de dados entre os nós de
um cluster de computadores, o framework utiliza o sistema de gerenciamento de arquivos
proprietário HDFS, e MapReduce para fazer o processamento. Para isso, o Hadoop divide
os arquivos em grandes blocos de dados que são distribuídos através dos nós, juntamente
com pacotes de código que realizarão o processamento em paralelo. Essa abordagem tira
proveito do princípio da localidade dos dados (
IBM
,
2019
), onde os nós manipulam os
dados aos quais têm acesso direto, tornando o processamento mais rápido e eficiente do
que seria em uma arquitetura convencional de supercomputador (
MALAK
,
2014
).
4.2.3
MapReduce
MapReduce é um framework introduzido pelo Google em 2004 para suporte de
computação distribuída de grandes conjuntos de dados em clusters de computadores. Esse
modelo é baseado na utilização de duas funções básicas de processamento: map, que analisa
duplas chave-valor de dados para gerar conjuntos chave-valor intermediários, e reduce,
32 Capítulo 4. Fundamentação Teórica
que mergeia todos os valores intermediários associados com a mesma chave intermediária
(
PATEL; BIRLA; NAIR
,
2012
), como ilustrado na
Figura 1
. Mais detalhadamente, o
funcionamento de cada uma das etapas é:
• Map: O nó mestre recebe a entrada, a particiona em subconjuntos e distribui para nós
subjugados que irão fazer o processamento (workers), que podem repetir o processo,
criando uma estrutura de árvore de múltiplos níveis. O nó worker então processa o
subconjunto e retorna o resultado ao mestre (
PATEL; BIRLA; NAIR
,
2012
).
• Reduce: O nó mestre então coleta todos os resultados de cada subconjunto e os
combina de forma a gerar uma saída única para cada agrupamento de dados. Múltiplas
instâncias de reduce são então aplicadas paralelamente a cada conjunto de dados,
produzindo uma coleção de resultados para cada domínio (
PATEL; BIRLA; NAIR
,
2012
).
Figura 1 – Funcionamento do algoritmo de MapReduce.
Fonte: Elaboração própria
Apesar desse processo, à primeira vista, parecer mais ineficiente que algoritmos
sequencias tradicionais, MapReduce pode ser aplicado a conjuntos de dados muito maiores
do que um commodity server poderia lidar. Além disso, esse paralelismo pode ajudar na
recuperação parcial de falha de algum dos servidores, assumindo que o dado de entrada
ainda esteja disponível (
GIGAOM
,
2019
).
4.2.4
Apache Hive
Apache Hive é um software de data warehouse para busca e análise de dados por
meio de uma linguagem de consulta própria semelhante a SQL (HiveQL), construído
sobre Apache Hadoop (
VENNER
,
2009
). Como a abstração entre a linguagem SQL
e sua implementação baixo-nível da Java API é intermediada pelo próprio Hive, ele
acaba por cumprir o papel de mediador entre diversas aplicações baseadas em SQL
e Hadoop, permitindo que essas aplicações possam fazer processamento sobre dados
distribuídos (
RUTHERGLEN; WAMPLER; CAPRIOLO
,
2012
). A arquitetura básica de
seus componentes se encontra na
Figura 2
.
Figura 2 – Arquitetura básica do Hive.
Fonte: (
KARANTH
,
2014
)
Os principais componentes da arquitetura Hive são:
• Metastore: Armazena metadados para cada uma das tabelas, como esquema e local.
Ele também inclui os metadados da partição, que ajudam o driver a rastrear o
progresso de vários conjuntos de dados distribuídos pelo cluster. Os dados são
arma-zenados em um formato SGBDR tradicional. Como esses metadados são essenciais
para que o driver gerencie os dados, um servidor de backup os replica regularmente
para que possam ser recuperados em caso de perda (
HADOOP
,
2019
).
• Driver : Atua como um controlador que recebe as consultas do HiveQL, iniciando a
execução da instrução, criando sessões e monitorando o ciclo de vida e o progresso
da consulta. Ele armazena os metadados necessários gerados durante a execução
34 Capítulo 4. Fundamentação Teórica
de uma instrução HiveQL, e também atua como um ponto de coleta de dados ou
resultados de consultas obtidos após operações de Reduce (
HADOOP
,
2019
).
• Compiler : Compila a consulta de HiveQL, convertendo-a num plano de execução.
Esse plano contém as tarefas e as etapas necessárias para a execução do Hadoop
MapReduce para obter a saída conforme traduzida pela consulta. O compilador
converte a consulta em uma árvore de sintaxe abstrata (AST), e após verificar a
compatibilidade e erros de compilação, ele converte o AST em um grafo acíclico
direcionado (DAG). O DAG divide os operadores em estágios e tarefas do MapReduce
com base na consulta e nos dados de entrada (
HADOOP
,
2019
).
• Optimizer : Responsável por otimizar o plano de execução. Faz operações de agregação,
como a transformação de um pipeline de joins em um único join, e de divisão, como
transformação dos dados de entrada antes de uma operação de Reduce (
HADOOP
,
2019
).
• Executor : Executa as tarefas de acordo com a ordem de dependência, interagindo
com o job tracker do Hadoop (
DOKEROGLU et al.
,
2014
).
• CLI, UI e Thrift Server : Interface de linha de comando (CLI) que provê uma interface
para que o usuário interaja com o Hive, fazendo consultas, instruções e monitorando
status de processos. O Thrift Server permite que clientes externos interajam com o
Hive através de uma rede (
HADOOP
,
2019
).
4.3
Hadoop e MapReduce em Bioinformática
Dados os desafios apresentados anteriormente com relação ao desenvolvimento da
área de Bioinformática, estudos vêm surgindo na literatura sobre possíveis aplicações de
Hadoop e MapReduce nessa área. As aplicações para sequenciamento de próxima geração
(next-gen sequencing – NGS) incluem o software Cloudburst (
CBCB
,
2019
), que mapeia
dados de sequências curtas de nucleotídeos a um genoma de referência para descoberta e
genotipificação de SNPs (polimorfismo de nucleotídeo único). Ainda se tratando de NGS,
alguns algoritmos como Crossbow (
MATSUNAGA; TSUGAWA; FORTES
,
2008
) se utilizam
de Hadoop para análises de re-sequenciamento de genomas inteiros e genotipificação de
SNPs (
TAYLOR
,
2010
).
Além de aplicações em NGS, Hadoop vêm sendo aplicado em outras áreas da
Bioinformática, como na implementação dos algoritmos BLAST (Basic Local Alignment
Search Tool) e GSEA (Gene Set Enrichment Analysis), para alinhamento de sequência
e significância estatística de expressão de genes, respectivamente. CloudBLAST (
MAT-SUNAGA; TSUGAWA; FORTES
,
2008
), uma versão paralelizada do algoritmo NCBI
BLAST2 utilizando Hadoop, desenvolvido na Universidade da Flórida, apresentou bons
resultados para aplicações aos quais se aplica o paradigma MapReduce, em comparação
com outras tecnologias BLAST de processamento paralelo, como mpiBLAST (
TAYLOR
,
2010
).
No Laboratório de Ciências Ambientais Moleculares do Departamento de Energia
dos Estados Unidos, há um projeto para o desenvolvimento de um sistema na escala de
petabytes que possa armazenar dados, metadados e resultados de processamento de dados
de diversas fontes, e cujo projeto piloto se baseia na integração de dados proteômicos
e transcriptômicos gerados a partir de computação de alto rendimento. Essa base de
dados está sendo estruturada em um cluster de 25 nós utilizando Hadoop e HBase como
framework para gerenciamento (
TAYLOR
,
2010
).
Até o momento, os resultados obtidos utilizando-se de ferramentas de
processa-mento paralelo, Hadoop e MapReduce apresentaram bons resultados com aplicações em
Bioinformática. Todos os trabalhos citados acima apresentam resultados positivos e
apon-tam como a utilização dessa framework aumentou a rapidez e eficiência de processamento
se comparado com tecnologias tradicionais.
4.4
Bancos de dados biológicos e seus recursos
Bioinformática é a aplicação de tecnologia da informação para armazenar, organizar
e analisar dados biológicos, que podem estar disponíveis na forma de sequências e estruturas
de proteínas e ácido nucleicos. Sequências e estruturas são apenas alguns dos exemplos dos
tipos de dados necessários ao estudo de biologia moderna, que além destes pode incluir vias
metabólicas, interações moleculares, mutações e polimorfismo em sequências e estruturas
moleculares, mapas genéticos, dados fisiológicos, perfis de expressão genética, entre outros
(
NARGUND
,
2019
). Um banco de dados biológico é uma coleção desses dados estruturados
para que possam ser facilmente acessíveis, gerenciados e atualizados. Eles possuem a função
básicas de fazer com que dados biológicos estejam disponíveis para cientistas em formatos
prontos para serem processados via computador (
NARGUND
,
2019
).
Bancos de dados biológicos podem ser genericamente divididos entre bancos de
dados de sequência (ácidos nucleicos e proteínas) ou de estrutura (apenas proteínas),
bem como em primários, secundários e compostos. Um banco de dados primário contém
informações a respeito da sequência ou estrutura apenas, enquanto um banco de dados
secundário contém informações derivadas da base de dados primária, como sequências
conservadas, sequências assinatura e resíduos de sítio ativo das famílias de proteínas. Já
bancos de dados compostos possuem uma amálgama de dados de diferentes bancos de
dados primários (
NARGUND
,
2019
). Alguns exemplos de bancos de dados biológicos são:
36 Capítulo 4. Fundamentação Teórica
1991
), EMBL (European Molecular Biology Laboratory) (
EMBL
,
2019
), DDBJ (DNA
Databank of Japan) (
DDBJ
,
2019
);
• Repositórios primários de sequências de proteínas: PIR-PSD (Protein Information
Resource – Protein Sequence Database) (
PIR
,
2019
) e Swiss-Prot (
SIB
,
2015
);
• Bases de dados secundárias de sequências de nucleotídeos: FlyBase (
FLYBASE
,
1999
), focado no genoma da mosca de fruta D. Melanogaster, e CMR (Comprehensive
Microbial Resource), que contém genomas microbiais, anotações de sequência e outras
informações a respeito dos organismos estudados (
PETERSON et al.
,
2001
).
• Base de dados estruturais primárias: PDB (Protein Databank) (
PDB
,
2019
) e CSD
(Cambridge Structural Database) (
GROOM et al.
,
2016
).
Todas essas bases de dados são de livre acesso ao público pela internet, e os dados
podem ser baixados em diversos formatos, desde formatos de texto a sequências. Os links
de acesso aos repositórios de dados encontram-se nas referências.
4.4.1
Desafios relacionados
Embora um grande número de bancos de dados e recursos biológicos vêm sido
desenvolvidos nos últimos anos, ainda há grandes desafios relacionados à integração de
dados, criação de hipóteses baseadas em dados e facilitação de descobertas científicas nessa
área (
CHEN; HUANG; WU
,
2017
). Alguns desafios atuais impostos à essa área são:
• Armazenamento e gerenciamento de dados: além de melhorias no hardware para
aumentar a eficiência de processamento, sistemas de armazenamento paralelo vêm
sido estudados para serem aplicados na área, como Lustre (
LLC
,
2019
) e Apache
Hadoop (
HADOOP
,
2019
). Bancos de dados relacionais têm dificuldades em lidar com
grandes volumes de dados pois não são horizontalmente escaláveis e se tornam muito
complexos quando tratando de dados heterogêneos, e por isso bancos NoSQL são
uma alternativa. Alguns tipos sistemas de gerenciamento de bancos de dados NoSQL
populares são baseados em grafos, pares chave-valor, bancos de dados estruturados
em colunas ou orientado a documentos (
CHEN; HUANG; WU
,
2017
).
• Análise de dados: não basta apenas se ter uma coletânea massiva de dados, é
necessário analisar esses dados de forma a produzir conhecimento. Nesse quesito,
computação em nuvem vêm surgindo como uma alternativa econômica para análise
de dados em larga escala. Além disso, novos e eficientes algoritmos de aprendizado
de máquina e mineração de dados também são essenciais para o processo de produzir
conhecimento a partir de dados (
CHEN; HUANG; WU
,
2017
). Um exemplo de
tecnologia para rápida e eficiente computação em nuvem é o Apache Stark (
SPARK
,
2018
).
• Integração de dados: para lidar com a heterogeneidade, diversidade e complexidade
de dados de forma a encontrar uma melhor forma de integrá-los pode-se utilizar de
ontologias e tecnologias da Web Semântica. O rápido desenvolvimento e aplicação de
ontologias permitiu que pesquisadores pudessem anotar e integrar dados biológicos
e biomédicos utilizando-se de padrões ontológicos, e automatizar a descoberta e
composição de webservices e workflows de Bioinformática (
CHEN; HUANG; WU
,
2017
). Tecnologias de Linked Data provém um método para publicação de dados
estruturados na internet e os tornam interconectados. Alguns projetos bem-sucedidos
de Linked Data no campo da Bioinformática são Bio2RDF (
BELLEAU et al.
,
2008
)
e a plataforma EBI RDF (
JUPP et al.
,
2014
).
Tendo em vista que os recentes avanços na área de Bioinformática tendem a
enriquecer ainda mais os conjuntos de dados existentes, soluções para os desafios
apre-sentados principalmente na área de armazenamento, gerenciamento e análise de dados se
tornam cada vez mais importantes para o progresso dessa área da ciência como um todo.
Tecnologias que tornem o armazenamento de dados cada vez mais eficiente se tornam
imprescindíveis como agentes facilitadores da pesquisa científica no contexto atual de Big
5 Metodologia
O capítulo a seguir descreve o tipo de pesquisa conduzida, bem como a forma de
implementação, tecnologias utilizadas e todos os demais recursos e métodos necessários à
realização do estudo.
5.1
Tipo de pesquisa
A hipótese de pesquisa estudada é se a utilização de Hadoop melhora os tempos
de execução de consultas em bancos de dados biológicos com grandes volumes de dados
quando comparado a um banco de dados relacional. A pesquisa conduzida é exploratória e
quantitativa, visto que é um processo investigativo e de aprendizado numa área de estudo
nova e que visa mensurar a performance da aplicação de forma quantitativa, comparando-a
com dados previamente existentes.
As etapas de desenvolvimento da pesquisa foram:
1. Estudo do framework Apache Hadoop, do sistema de arquivos HDFS e de MapReduce;
2. Análise do uso da ferramenta Hive QL para gerenciamento das consultas;
3. Análise e escolha do método de simulação do sistema distribuído;
4. Criação das máquinas virtuais e configuração do ambiente distribuído com Hadoop
e Hive;
5. Criação de tabelas e inserção de dados no Hive;
6. Execução das consultas;
7. Comparação com resultados previamente obtidos em bancos de dados relacionais.
5.2
Materiais
Os dados biológicos utilizados para a realização das consultas foram dados de
variações genéticas e anotações biológicas da população de arroz Oryza sativa, colhidos
das bases de dados públicas EnsemblPlants, Rice Diversity e Rice Genome Annotation
Project. Esses dados foram escolhidos por serem abundantes e completos, e por permitirem
a comparação entre diferentes populações (no trabalho em questão serão apenas analisados
os dados de uma população).
40 Capítulo 5. Metodologia
Os dados originais de referência em formato FASTA foram obtidos através da
plataforma Ensembl Genomes
1, enquanto os dados utilizados como fonte de anotações
biológicas encontram-se disponíveis no Rice Genome Annotation Project
2. Já os dados
referentes à variações genéticas estão disponíveis na plataforma Rice Diversity
3.
5.3
Métodos
Para testar a hipótese, foram utilizados os softwares Hadoop e Hive sobre um
cluster composto por 3 máquinas virtuais Linux executando concomitantemente na mesma
máquina hospedeira, simulando um sistema distribuído. O hardware utilizado para
simu-lação foi um notebook Dell modelo Inspiron 15-557, com processador Intel R Core TM
i7-6500U CPU @ 2.50GHz 2.60Ghz (2 núcleos físicos e 4 núcleos lógicos), 16GB de RAM
@ 1600 MHz e sistema operacional Windows 10 Home versão 1803.
As máquinas virtuais foram criadas e executadas utilizando-se o software open
source Oracle VM VirtualBox
4. A configuração utilizada nas máquinas virtuais foi:
• 4096 MB de memória;
• 20 GB de disco;
• Sistema operacional LUbuntu 18.04 LTS bionic;
• Hadoop versão 2.7.7;
• Apache Hive versão 2.3.6;
• MySQL Server versão 14.14 - distribuição 5.7.27.
Com essas configurações, foram criadas tabelas no Hive a partir de um esquema
relacional previamente implementado, ilustrado na
Figura 3
. Os dados biológicos a serem
utilizados foram colhidos a partir de arquivos VCF do genoma da população escolhida,
que devem ser comparados com um arquivo de referência para verificação de alterações
genéticas em determinada posição do cromossomo. O cruzamento dessas informações é
feito a partir de 8 consultas que foram realizadas no ambiente distribuído do Hadoop, cujo
tempo foi medido e comparado com o obtido num banco de dados relacional.
1 ftp://ftp.ensemblgenomes.org/pub/plants/release-43/fasta/oryza sativa/dna/ 2 http://rice.plantbiology.msu.edu/annotation pseudocurrent.shtml 3 http://www.ricediversity.org/data/index.cfm 4 https://www.virtualbox.org/wiki/VirtualBox
Figura 3 – Esquema de banco relacional.
Fonte: (
MATOS
,
2019
)
O modelo de dados relacional foi criado e implementado em PostgreSQL por
(
MATOS
,
2019
) em seu projeto de Iniciação Científica para avaliação de bancos de
dados NoSQL no gerenciamento de dados biológicos. Nesse modelo, as tabelas variation,
individual e population são uilizadas para armazenar os dados de variações genéticas,
indivíduos e população, respectivamente. As tabelas chromosome e reference são utilizadas
para armazenar as informações de anotações biológicas, e, por fim, a tabela chromosome
variation annotation é utilizada para relacionar as variações com seus cromossomos e com
as anotações biológicas referentes a região do genoma em questão (
MATOS
,
2019
).
As tabelas foram criadas no Hive de forma a receber como entrada dados em
formato CSV (separado por vírgula) em que cada linha corresponde a um novo registro
(opções ROW FORMAT DELIMITED FIELDS TERMINATED BY ’,’). Para que fosse possível
42 Capítulo 5. Metodologia
carregar os registros na tabela diretamente a partir de um arquivo CSV, foi preciso fazer
com que as tabelas fossem armazenadas em arquivo texto (opção STORED AS TEXTFILE). A
relação entre o volume de dados inserido (quantidade de registros e tamanho dos arquivos)
e as tabelas criadas encontra-se ilustrada na
Tabela 1
, e o script de criação das tabelas e
inserção dos dados está disponível no
Apêndice A
.
Tabela 1 – Dados de entrada para as tabelas no Hive.
Tabela
N
ode registros
Tamanho do arquivo
biologic annotation
66 154
4.3 MB
chromosome
12
2 KB
chromosome variation annotation
777 702
15.8 MB
individual
1 567
55 KB
population
1
1 KB
reference
1
1 KB
variation
700 000
31.1 MB
Fonte: Elaboração Própria
As consultas realizadas, formuladas em conjunto com um especialista na área,
cru-zam diversas informações entre população, variações genéticas, indivíduos e cromossomos,
visando abranger o escopo do que seriam análises comuns realizadas em dados genéticos.
Dessa forma, as medições feitas podem melhor se aproximar da realidade da aplicação real
de buscas em bancos de dados genéticos. As consultas utilizadas foram as seguintes:
1. SNPs de um experimento: população (grupo) e referência.
1 I N S E R T O V E R W R I T E D I R E C T O R Y ’ / q u e r y ’ 2 ROW F O R M A T D E L I M I T E D 3 F I E L D S T E R M I N A T E D BY ’ , ’ 4 S T O R E D AS T E X T F I L E 5 S E L E C T D I S T I N C T v . v a r i a t i o n _ i d e n t i f i c a t i o n 6 F R O M v a r i a t i o n v , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva 7 W H E R E v . id = cva . v a r i a t i o n _ i d AND v . p o p u l a t i o n _ i d = ’ r i c e 1 ’ 8 AND cva . c h r o m o s o m e _ i d IN (S E L E C T c . id F R O M c h r o m o s o m e c W H E R E c . r e f e r e n c e _ i d = ’ O r y z a _ s a t i v a . IRGSP - 1 . 0 . d n a _ r m . a l l _ c h r o m o s o m e s ’) ;
2. SNPs de um cromossomo: referência e cromossomos.
1 I N S E R T O V E R W R I T E D I R E C T O R Y ’ / q u e r y ’ 2 ROW F O R M A T D E L I M I T E D 3 F I E L D S T E R M I N A T E D BY ’ , ’ 4 S T O R E D AS T E X T F I L E 5 S E L E C T D I S T I N C T v . v a r i a t i o n _ i d e n t i f i c a t i o n 6 F R O M v a r i a t i o n v , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , c h r o m o s o m e c
7 W H E R E ( v . id = cva . v a r i a t i o n _ i d AND cva . c h r o m o s o m e _ i d = c . id AND c . id = 3) ;
3. Quais as variações relacionadas à uma anotação X?
• Anotação;
• Cromossomos;
• Posição;
• População;
• Indivíduos.
1 I N S E R T O V E R W R I T E D I R E C T O R Y ’ / q u e r y ’ 2 ROW F O R M A T D E L I M I T E D 3 F I E L D S T E R M I N A T E D BY ’ , ’ 4 S T O R E D AS T E X T F I L E 5 S E L E C T D I S T I N C T v . v a r i a t i o n _ i d e n t i f i c a t i o n 6 F R O M v a r i a t i o n v , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , b i o l o g i c _ a n n o t a t i o n ba 7 W H E R E ba . a n n o t a t i o n L I K E ’ % e x p r e s s e d p r o t e i n % ’ AND v . id = cva . v a r i a t i o n _ i d AND cva . b i o l o g i c _ a n n o t a t i o n _ i d = ba . id ;4. Quantas anotações estão relacionadas com uma variação X.
1 S E L E C T D I S T I N C T ba . a n n o t a t i o n
2 F R O M b i o l o g i c _ a n n o t a t i o n ba , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , v a r i a t i o n v
3 W H E R E ba . id = cva . b i o l o g i c _ a n n o t a t i o n _ i d AND cva . v a r i a t i o n _ i d = v . id AND v . v a r i a t i o n _ i d e n t i f i c a t i o n = ’ SNP - 1 . 1 0 0 0 6 2 1 1 . ’;
5. Qual a quantidade de SNPs no cromossomo X na população Y em cada referência?
1 S E L E C T r . id as r e f e r e n c e , c . id as c h r o m o s o m e , C O U N T(D I S T I N C T v . id )
as q u a n t i d a d e
2 F R O M v a r i a t i o n v , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , c h r o m o s o m e c , r e f e r e n c e r
3 W H E R E v . p o p u l a t i o n _ i d = ’ r i c e 1 ’ AND v . id = cva . v a r i a t i o n _ i d AND
cva . c h r o m o s o m e _ i d = c . id
6. Quantas anotações estão relacionadas a um indivíduo X.
1 I N S E R T O V E R W R I T E D I R E C T O R Y ’ / q u e r y ’ 2 ROW F O R M A T D E L I M I T E D 3 F I E L D S T E R M I N A T E D BY ’ , ’ 4 S T O R E D AS T E X T F I L E 5 S E L E C T D I S T I N C T( ba . a n n o t a t i o n ) 6 F R O M b i o l o g i c _ a n n o t a t i o n ba , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , v a r i a t i o n v , p o p u l a t i o n p , i n d i v i d u a l i 7 W H E R E i . i n d i v i d u a l _ i d e n t i f i c a t i o n = ’ I R G C 1 2 1 8 6 4 @ 0 a 1 2 f 8 f 9 .0 ’ AND i . p o p u l a t i o n _ i d = p . id
8 AND p . id = v . p o p u l a t i o n _ i d AND cva . v a r i a t i o n _ i d = v . id AND ba . id = cva . b i o l o g i c _ a n n o t a t i o n _ i d ;
44 Capítulo 5. Metodologia
7. Quais as anotações relacionadas a um cromossomo X.
1 I N S E R T O V E R W R I T E D I R E C T O R Y ’ / q u e r y ’ 2 ROW F O R M A T D E L I M I T E D 3 F I E L D S T E R M I N A T E D BY ’ , ’ 4 S T O R E D AS T E X T F I L E 5 S E L E C T D I S T I N C T( ba . a n n o t a t i o n ) 6 F R O M c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , b i o l o g i c _ a n n o t a t i o n ba
7 W H E R E cva . c h r o m o s o m e _ i d = 3 AND cva . b i o l o g i c _ a n n o t a t i o n _ i d = ba . id ;
8. Considerando as posições X, Y e Z no cromossomo W quais são suas anotações
biológicas e em quais populações esse SNP existe?
1 S E L E C T v . pos as p o s i t i o n, ba . a n n o t a t i o n as a n n o t a t i o n , p . id as p o p u l a t i o n 2 F R O M b i o l o g i c _ a n n o t a t i o n ba , c h r o m o s o m e _ v a r i a t i o n _ a n n o t a t i o n cva , v a r i a t i o n v , p o p u l a t i o n p 3 W H E R E v . pos in (’ 9 5 8 1 7 9 ’, ’ 1 0 0 0 6 0 4 2 ’, ’ 1 0 0 0 7 2 3 6 ’) AND v . p o p u l a t i o n _ i d = p . id
4 AND cva . v a r i a t i o n _ i d = v . id AND cva . b i o l o g i c _ a n n o t a t i o n _ i d = ba . id
5 G R O U P BY v . pos , ba . a n n o t a t i o n , p . id ;
Uma vez que o ambiente distribuído foi criado e os dados inseridos em tabelas no
Hive, as consultas acima foram executadas através da interface CLI própria do Hive, e os
valores e métricas apresentados durante a execução foram colhidos e salvos em arquivos
de texto para posterior análise.
6 Resultados
Em um ambiente de processamento distribuído, a maior preocupação de performance
é com relação ao tempo de execução, visto que assume-se que há abundância de recursos
de hardware suficiente para se montar um cluster de máquinas. Dessa forma, o indicador
de performance utilizado para comparar os desempenhos em ambas as plataformas foi
apenas o tempo de execução. A
Tabela 2
relaciona os tempos de execução das consultas no
banco de dados relacional PostgreSQL (
MATOS
,
2019
) com os tempos obtidos no Hive.
Tabela 2 – Comparação entre consultas Hive e PostgreSQL.
Consulta
Tempo - PostgreSQL
Tempo - Hive
N
ode registros retornados
Consulta 1
1 s 848 ms
55 s 828 ms
700 000
Consulta 2
359 ms
36 s 904 ms
67 500
Consulta 3
397 ms
47 s 123 ms
62 318
Consulta 4
145 ms
29 s 719 ms
1
Consulta 5
1 s 487 ms
55 s 153 ms
12
Consulta 6
1 s 450 ms
52 s 168 ms
7 326
Consulta 7
124 ms
21 s 588 ms
1 616
Consulta 8
160 ms
53 s 002 ms
3
Fonte: Elaboração Própria
Percebe-se que o tempo de execução das consultas no ambiente distribuído aumentou
consideravelmente em relação ao banco relacional, ao contrário do esperado. Para investigar
as causas desse aumento inesperado do tempo de execução, foram analisados os logs das
consultas na CLI do Hive, e foi feita uma análise e comparação de outras aplicações que
utilizaram essa mesma estratégia para melhorar performance com sistemas distribuídos.
6.1
Overhead operacional
Analisando os logs, foi possível observar que parte considerável do tempo de cada
consulta é gasto com o setup do ambiente, carregamento dos dados, distribuição das tarefas
entre os jobs de MapReduce, entre outras tarefas operacionais custosas relativas ao
geren-ciamento do ambiente distribuído (overhead, que corresponde à parte serial de execução).
O trecho de código paralelizável, correspondente ao processamento distribuído dos dados
pelos nós do cluster, é apenas uma pequena parcela do tempo total de processamento.
Os trechos de log a seguir, separados por consulta, demonstram o aproveitamento das
operações realizadas e do tempo de execução. Os logs completos de cada uma das consultas
encontram-se listados do
Apêndice B
ao
Apêndice I
.
46 Capítulo 6. Resultados
Query ID = hduser_20191117144638_2390a4ef-dacb-4be0-8888-aa27990932a9
Total jobs = 7
[...]
MapReduce Jobs Launched:
Stage-Stage-5:
HDFS Read: 198762736 HDFS Write: 239255320 SUCCESS
Stage-Stage-9:
HDFS Read: 131280525 HDFS Write: 119627660 SUCCESS
Stage-Stage-6:
HDFS Read: 131280525 HDFS Write: 119627660 SUCCESS
Stage-Stage-3:
HDFS Read: 262561050 HDFS Write: 250362844 SUCCESS
Dos 7 jobs lançados, apenas 4 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 8.93 segundos são gastos na execução desses jobs.
Consulta 2
Query ID = hduser_20191117144936_06f561b4-ab77-4815-abf6-7c36b9a300b6
Total jobs = 3
[...]
MapReduce Jobs Launched:
Stage-Stage-7:
HDFS Read: 163179682 HDFS Write: 130735184 SUCCESS
Stage-Stage-3:
HDFS Read: 326359364 HDFS Write: 262531749 SUCCESS
Dos 3 jobs lançados, apenas 2 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 7.08 segundos são gastos na execução desses jobs.
Consulta 3
Query ID = hduser_20191117151121_ff73b76a-ef3b-4015-a5c9-a422103615a8
Total jobs = 3
[...]
MapReduce Jobs Launched:
Stage-Stage-7:
HDFS Read: 294456259 HDFS Write: 132857946 SUCCESS
Stage-Stage-3:
HDFS Read: 588912518 HDFS Write: 266703632 SUCCES
Dos 3 jobs lançados, apenas 2 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 12.805 segundos são gastos na execução desses jobs.
Consulta 4
Query ID = hduser_20191117151750_7032e5c0-01b9-433e-b994-5e89975a2d35
Total jobs = 5
[...]
MapReduce Jobs Launched:
Stage-Stage-2:
HDFS Read: 1293887177 HDFS Write: 404500278 SUCCESS
Stage-Stage-3:
HDFS Read: 883857556 HDFS Write: 269666852 SUCCESS
Dos 5 jobs lançados, apenas 3 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 3.271 segundos são gastos na execução desses jobs.
Consulta 5
Query ID = hduser_20191117152332_74c5ebaa-43fb-4574-8776-ccf89ae7db0c
Total jobs = 3
[...]
MapReduce Jobs Launched:
Stage-Stage-10:
HDFS Read: 573205355 HDFS Write: 134833426 SUCCESS
Stage-Stage-4:
HDFS Read: 1146410710 HDFS Write: 269666852 SUCCESS
Dos 3 jobs lançados, apenas 2 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 9.807 segundos são gastos na execução desses jobs.
Consulta 6
Query ID = hduser_20191117152930_334ae800-8e9d-41a9-9e6d-09c269b44560
Total jobs = 5
[...]
MapReduce Jobs Launched:
Stage-Stage-13:
HDFS Read: 688778717 HDFS Write: 134833426 SUCCESS
Stage-Stage-2:
HDFS Read: 2130134465 HDFS Write: 404500278 SUCCESS
Stage-Stage-4:
HDFS Read: 1441355748 HDFS Write: 270043349 SUCCESS
Dos 5 jobs lançados, apenas 3 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 5.99 segundos são gastos na execução desses jobs.
Consulta 7
Query ID = hduser_20191117154021_439be360-5377-4580-a7c0-1cb1672988c1
Total jobs = 1
[...]
MapReduce Jobs Launched:
Stage-Stage-2:
HDFS Read: 1672502472 HDFS Write: 271247893 SUCCESS
Apenas um job foi lançado e fez todo o processamento. Do tempo total da consulta,
apenas 3.816 segundos são gastos na parte do código que opera sobre os dados.
48 Capítulo 6. Resultados
Query ID = hduser_20191117154510_2cb9a92a-2775-48a3-8dc0-791754857dc5
Total jobs = 5
[...]
MapReduce Jobs Launched:
Stage-Stage-12:
HDFS Read: 886115178 HDFS Write: 135744055 SUCCESS
Stage-Stage-2:
HDFS Read: 2722143848 HDFS Write: 407232165 SUCCESS
Stage-Stage-4:
HDFS Read: 1836028670 HDFS Write: 271488110 SUCCESS
Dos 5 jobs lançados, apenas 3 realmente lidam com os dados da consulta. Do tempo
total da consulta, apenas 6.917 segundos são gastos na execução desses jobs.
A
Tabela 3
sumariza os dados de tempo de execução analisados nos trechos de
logs acima, comparando o tempo de execução da consulta completa (tempo total) com
o tempo efetivamente gasto com operações sobre os dados da consulta (tempo efetivo).
A
Figura 4
apresenta esses dados um um gráfico de forma a facilitar a visualização, e a
Figura 5
mostra o aproveitamento percentual de tempo para cada consulta (calculado
como a razão entre o tempo efetivo e o tempo total gasto). A
Tabela 4
relaciona o número
total de jobs por consulta com o número de jobs utilizado para operar sobre os dados.
Tabela 3 – Tempo total vs. tempo efetivo de execução das consultas.
Consulta
Tempo total
Tempo efetivo
Consulta 1
55.828 s
8.93 s
Consulta 2
36.904 s
7.08 s
Consulta 3
47.123 s
12.805 s
Consulta 4
29.719 s
3.271 s
Consulta 5
55.153 s
9.807 s
Consulta 6
52.168 s
5.99 s
Consulta 7
21.588 s
3.816 s
Consulta 8
53.002 s
6.917 s
Fonte: Elaboração Própria
Tabela 4 – Número total de jobs vs. número efetivo de jobs.
Consulta
N
ototal de jobs
N
ode jobs efetivos
Consulta 1
7
4
Consulta 2
3
2
Consulta 3
3
2
Consulta 4
5
3
Consulta 5
3
2
Consulta 6
5
3
Consulta 7
1
1
Consulta 8
5
3
Figura 4 – Gráfico relacionando tempos de consulta.
Fonte: Elaboração própria.
Figura 5 – Gráfico de aproveitamento de tempo de consulta.
50 Capítulo 6. Resultados
