RELATÓRIO DE ATIVIDADES DISCIPLINA: ARQUITETURAS PARALELAS. Hadoop e QEF: Uma abordagem distribuída para aplicações de Astronomia

Transcrição

1 UNIVERSIDADE FEDERAL FLUMINENSE INSTITUTO DE COMPUTAÇÃO (IC) RELATÓRIO DE ATIVIDADES DISCIPLINA: ARQUITETURAS PARALELAS Hadoop e QEF: Uma abordagem distribuída para aplicações de Astronomia Henrique Klôh Matheus Bandini Prof. Vinod Rebello Julho

2 Sumário 1 Introdução 3 2 Objetivos Técnicos 4 3 Antecedentes Justificativa 5 4 Metodologia Meta 1: Levantamento de informações sobre as aplicações SkyMap e SkyMapAdd Meta 2: Particionamento do banco de dados Meta 3: Pesquisa sobre o modelo MapReduce e sobre o framework Hadoop Meta 4: Adequação das aplicações SkyMap e SkyMapAdd ao framework Hadoop Meta 5: Incorporação do QEF (Query Evaluation Framework) à arquitetura proposta com o framework Hadoop Meta 6: Execução de testes e análise comparativa entre a arquitetura proposta e a arquitetura atual Realização de Testes e Análise da Arquitetura 11 6 Conclusões e Trabalhos Futuros 12 2

3 1 Introdução O relatório de atividades a seguir apresenta os esforços realizados, com o objetivo de oferecer uma solução mais eficiente para o problema de acesso e utilização de conjuntos massivos de dados por aplicações científicas, através do uso de paralelismo, tanto para o acesso aos dados, como para o processamento dos mesmos. Estes esforços julgam se necessários devido à crescente complexidade das aplicações científicas e pelo consequente volume de dados gerados a partir destas aplicações. Os recentes desenvolvimentos tecnológicos, bem como o aumento da complexidade dos problemas, têm gerado um grande volume de informações, resultados de aplicações com os mais variados propósitos, e que podem servir como fluxo de informações para outras aplicações. Estes fluxos, denominados Data Workflows, permitem a colaboração entre campos distintos, nos âmbitos científicos, comerciais e industriais. Como resultado desta colaboração, é comum que sejam gerados grandes volumes de dados, caracterizando as chamadas Aplicações BigData, que têm os objetivos de armazenar e permitir o acesso e a análise dos dados, possibilitando uma tomada de decisão baseada nos resultados obtidos por este conjunto de ações. No que tange a manipulação de grandes volumes de dados, é necessário que haja uma estratégia bem definida de acesso e processamento, tornando esta manipulação mais eficiente. Uma destas estratégias é aplicar o paralelismo nas aplicações que realizam o acesso e o processamento dos dados, uma vez que este paralelismo possibilita a obtenção do mesmo resultado alcançado pela execução em série, mas em uma parcela de tempo reduzida. O ganho alcançado com o paralelismo depende de diversos fatores, dentre os quais merecem destaque: o tipo da aplicação a onde o paralelismo será aplicado; o algoritmo de paralelismo adotado e; a quantidade e a qualidade dos recursos disponíveis para se aplicar o paralelismo. Dentro do contexto de aplicações Big Data, encontra se o Ogando Science Portal 1, uma aplicação do Laboratório LIneA (Laboratório Interinstitucional de e Astronomia). Este laboratório está vinculado ao projeto DES Brazil (Dark Energy Survey) dedicado ao estudo da natureza da energia escura. O Portal Ogando é responsável pelo processamento e pela análise de informações de corpos celestes, assim como pela geração de imagens que permitem a visualização simulada destes corpos em um plano cartesiano. O grande volume de dados gerado por este portal demanda estratégias paralelas de armazenamento, acesso e processamento dos dados, com o objetivo de proporcionar um resultado válido em tempo hábil para a tomada de decisões. Como principal estratégia de paralelismo para a realização deste tra

4 balho, foi adotado o modelo MapReduce, por ser um modelo considerado adequado para aplicações que realizam processamento intensivo em grandes volumes de dados. O modelo MapReduce tem como principais características a preocupação com a localidade dos dados e a tolerância a falhas [4], estes aspectos são considerados importantes ao modelar um projeto de arquitetura paralela que visa o alto desempenho. 2 Objetivos Técnicos O objetivo geral deste trabalho é fazer com que o armazenamento e a manipulação dos dados pelo Portal Ogando seja realizado de forma paralela, além de aproximar os nós de processamento dos dispositivos de armazenamento, visando otimizar o uso de recursos computacionais e reduzir significativamente o tempo necessário para se executar as etapas que compõem o fluxo de informações do Portal. Estas etapas são: a obtenção dos dados para o processamento distribuído; a distribuição dos dados para o processamento paralelo e; a consolidação das informações na forma de uma imagem que representa o resultado final do processo. A figura 1 representa as etapas do ciclo e o atual estado da arte, detalhado na seção 3. Para alcançar o objetivo geral especificado anteriormente, os seguintes objetivos técnicos foram definidos: 1. Propor uma nova arquitetura baseada no modelo MapReduce através do framework Hadoop; 2. Reduzir a complexidade da arquitetura, eliminando módulos centralizadores da arquitetura proposta, ou encapsulando os módulos relevantes para o funcionamento dentro do framework Hadoop; 3. Implementar a arquitetura paralelizada com o modelo MapReduce, via framework Hadoop; e 4. Realizar a análise comparativa entre a arquitetura estável (Portal Ogando) e a arquitetura proposta (Hadoop). Como desdobramentos destes objetivos, pode se citar: O aumento do desempenho da aplicação de análise de corpos celestes, no que se refere ao tempo de execução, comparando se à versão atualmente estável; a redução da concorrência de acesso ao servidor de banco de dados, através da fragmentação dos dados da aplicação e; o aumento da coesão do sistema através da eliminação de módulos de gerenciamento e manipulação de arquivos, necessários para o funcionamento da arquitetura atual e desnecessários para o modelo proposto. 4

5 3 Antecedentes Justificativa O presente trabalho aborda uma proposta de arquitetura paralela de acesso e manipulação dos dados hospedados em servidores de banco de dados distintos, com o objetivo de obter ganhos em tempo de execução referentes não apenas ao processamento, mas também referentes ao acesso dos dados. Este trabalho foi motivado pela necessidade de otimizar os processos executados pelo Portal Ogando, responsável por manipular e processar grandes massas de dados referentes a aplicações científicas da área de Astronomia. Atualmente, o Portal Ogando utiliza o paralelismo no processamento dos dados. No entanto, o acesso aos dados é feito através de um único servidor de dados centralizado (figura 1). Desta forma, mesmo ocorrendo o paralelismo no processamento dos dados, o tempo total de execução do processo é prejudicado devido ao acesso concorrente ao servidor de banco de dados centralizado. Figura 1: Arquitetura estável do Portal Ogando Uma outra questão que não se mostrou ideal, do ponto de vista do desempenho apresentado pela arquitetura atual, é o fato de que os dados são buscados pelo componente DataRetriever e preparados para o processamento paralelo pelo componente DataOrganizer, para só então inicializar a execução paralela. As aplicações SkyMap e SkyMapAdd, por sua vez, realizam o paralelismo e a consolidação dos dados, respectivamente. Como um primeiro esforço para oferecer uma solução capaz de resolver essa demanda de forma mais eficiente, está sendo apresentado pela proposta do Projeto LSST (Large Synoptic Survey Telescope) 2 que encontra se em desenvolvimento. Esta proposta, por sua vez, aborda o uso de um banco de dados distribuídos, para o armazenamento, e um módulo denominado Qserv [5], para o acesso às informações astronômicas. A figura 2 representa 2 5

6 a arquitetura em questão. Figura 2: Arquitetura proposta pelo LSST Embora a arquitetura proposta pelo LSST baseie se no uso de dados fragmentados e distribuídos em diversos servidores, foi observado que esta arquitetura também pode ser aprimorada. Isto se deve ao fato de que os dados são recuperados e consolidados pelo módulo Qserv e enviados para o módulo DataOrganizer que, por sua vez, prepara os dados para o paralelismo executado pela aplicação SkyMap. Assim como na arquitetura atual, o módulo SkyMapAdd é responsável pela consolidação dos dados e pela geração de uma imagem que representa o fim do processo. O possível aprimoramento da arquitetura LSST, objeto de motivação para este trabalho, está na possibilidade de remover os módulos Qserv e DataOrganizer, aplicando a fragmentação dos dados diretamente nos recursos responsáveis pela execução da aplicação SkyMap. Paralelo a isto, foi considerada a utilização do gerenciador de workflows científicos QEF (Query Evaluation Framework) [3], com o intuito de uniformizar e otimizar o acesso aos servidores de banco de dados. A figura 3 apresenta o modelo de arquitetura proposto, implementado e apresentado neste trabalho. Figura 3: Arquitetura proposta (QEF + Hadoop) 6

7 O modelo de arquitetura proposto por este trabalho aborda ainda o uso do framework Hadoop, com o objetivo de verificar o efeito do uso do modelo MapReduce nas aplicações SkyMap e SkyMapAdd, tornando possível a análise comparativa do desempenho da arquitetura proposta com a arquitetura atual. 4 Metodologia Para alcançar os objetivos descritos na seção 2 na página 4, as seguintes metas foram definidas: 1. Meta 1: Levantamento de informações sobre as aplicações SkyMap e SkyMapAdd. 2. Meta 2: Particionamento do banco de dados. 3. Meta 3: Pesquisa sobre o modelo MapReduce e sobre o framework Hadoop. 4. Meta 4: Adequação das aplicações SkyMap e SkyMapAdd ao framework Hadoop. 5. Meta 5: Incorporação do QEF (Query Evaluation Framework) à arquitetura proposta com o framework Hadoop. 6. Meta 6: Execução de testes e análise comparativa entre a arquitetura proposta e a arquitetura atual. A seguir apresenta-se a metodologia a ser seguida para a consecução de cada uma das metas propostas. 4.1 Meta 1: Levantamento de informações sobre as aplicações SkyMap e SkyMapAdd Para que fosse possível alcançar os requisitos necessários para implementar a arquitetura proposta, foi necessária a análise de funcionamento do Portal Ogando, bem como a verificação de dependências dos módulos identificados como indispensáveis para a correta implementação da arquitetura, de forma a proporcionar um resultado de qualidade em um tempo reduzido. Os principais esforços nesta meta foram exercidos sobre as aplicações SkyMap e SkyMapAdd. Durante a análise destas aplicações, foi observado que, em ambos os casos, eram utilizados arquivos e bibliotecas gerados a 7

8 partir do Portal Ogando. Como o objetivo era tornar estas aplicações independentes, de forma a executar isoladamente, foram removidas todas as dependências relativas ao Portal Ogando. Sendo assim, foram mantidas apenas as aplicações SkyMap e SkyMapAdd e os arquivos PKL 3, elos de ligação entre as duas aplicações. Figura 4: Componentes do Portal Ogando A figura 4 demonstra os componentes individuais do Portal Ogando. Os componentes representados pelos arquivos XML (extensible Markup Language) e os arquivos FITS, que possuem dados astronômicos brutos, foram removidos da arquitetura proposta. 4.2 Meta 2: Particionamento do banco de dados Ao analisar a arquitetura atual utilizada pelo Portal Ogando, foi observado que, embora o processamento dos dados seja feito de forma paralela, o acesso é centralizado em um único servidor. Este fato, além de causar a concorrência de acesso ao servidor de banco de dados, faz com o desempenho da arquitetura fique prejudicado devido ao tempo necessário para acessar os dados. Com o objetivo de otimizar os processos de acesso aos dados, esta meta teve como propósito dividir a base de dados de teste, utilizada pelo Portal Ogando para avaliação de desempenho e medição do tempo de execução, foi particionada de acordo com o número de recursos computacionais disponíveis (noventa e quatro nós de armazenamento). A estratégia de particionamento foi elaborada de forma a balancear a carga de dados em todos os nós de processamento. Esta estratégia permite ainda que os novos data releases anuais possam ser particionados de 3 Arquivos que contém informações vetoriais não ordenadas que, no contexto de aplicações de Astronomia, representam o posicionamento de corpos celestes em um determinado conjunto de coordenadas de um plano cartesiano. 8

9 forma semelhante e substituídos. Isto se torna possível pelo fato de que, em um primeiro momento, não são consideradas as informações de coordenadas espaciais, mas apenas a divisão pela quantidade de registros. O estudo da relevância de realizar o particionamento dos dados baseado em regiões, considerando se as informações de coordenadas, será realizado como trabalho futuro. 4.3 Meta 3: Pesquisa sobre o modelo MapReduce e sobre o framework Hadoop O MapReduce é um paradigma de programação sobre o qual o Google desenvolveu um algoritmo de processamento paralelo de arquivos com o objetivo de agilizar seus processos de busca [2]. Funciona de forma a utilizar duas funções: a função Map, responsável por distribuir e executar o processamento paralelo e; a função Reduce, responsável por receber o retorno da função Map e realizar uma agregação, consolidando as informações e gerando um resultado final. O framework Hadoop é uma implementação do algoritmo MapReduce desenvolvido em Java pela Apache Foundation, voltada para soluções de alto desempenho baseadas em cluster com o propósito de processar grandes volumes de dados aplicando o paralelismo. Os processos de MapReduce do Hadoop trabalham com pares chave/valor, onde, para cada situação envolvendo uma determinada chave, um valor é associado a ela [1]. Figura 5: Estrutura do framework Hadoop [1] A figura 5 apresenta o fluxograma dos processos internos do Hadoop. As entradas de dados são enviadas para a função Map, responsável pelo particionamento dos dados e pelo processamento distribuído. Uma vez realizado 9

10 o processamento, os algoritmos split/sort organizam os resultados do Map e os enviam para a função Reduce, responsável por agregar estes resultados, finalizando o processo. É possível ainda utilizar a função Reduce de forma hierárquica, onde o resultado de uma função Reduce serve de entrada para outra. Esta estratégia pode ser utilizada com o objetivo de paralelizar o processamento da função Reduce, de acordo com a quantidade de dados existente. 4.4 Meta 4: Adequação das aplicações SkyMap e SkyMapAdd ao framework Hadoop Esta meta descreve as adequações realizadas nas aplicações SkyMap e SkyMapAdd para que fosse possível utilizá las em conjunto com o Hadoop. Com o objetivo de evitar problemas de incompatibilidade entre as aplicações, foi necessário remover as bibliotecas referentes ao Portal Ogando das aplicações SkyMap e SkyMapAdd, deixando apenas as necessárias para a execução das aplicações. Após a remoção das dependências, foi definido que a aplicação SkyMap, responsável pelo processamento dos dados obtidos a partir do banco de dados, seria executado pela classe Mapper. O resultado de sua execução é a geração de uma determinada quantidade de arquivos PKL, quantidade esta definida pelo número de vezes em que a classe Mapper é instanciada. No caso da arquitetura proposta, foi estabelecido que cada nó de processamento executaria apenas uma instância da classe Mapper. Uma vez que os arquivos PKL são gerados pelos nós de processamento, a classe Reducer executa a aplicação SkyMapAdd, responsável por consolidar as informações obtidas em todos os arquivos PKL e gerar uma imagem que representa o resultado final do processo. 4.5 Meta 5: Incorporação do QEF (Query Evaluation Framework) à arquitetura proposta com o framework Hadoop O QEF (Query Evaluation Framework) é um gerenciador de workflows científicos que introduz uma abordagem para a geração configurável e flexível de middlewares para a integração de dados heterogêneos e distribuídos. O QEF considera que cada tipo de aplicação necessita de um subconjunto de funcionalidades de um SGBD (Sistema Gerenciador de Banco de Dados) [3]. Sendo assim, esta meta foi definida com o objetivo de analisar a influência do QEF como gerenciador de workflows científicos dentro da arquitetura proposta, com o propósito de melhor gerenciar o fluxo de consultas aos 10

11 servidores distribuídos de banco de dados e os resultados destas consultas e permitir uma mudança flexível de contexto, caso seja necessária a integração com aplicações com propósitos diferentes. A incorporação do QEF à arquitetura proposta foi realizada através do seu encapsulamento à função map da classe Mapper, implementada com o auxílio do framework Hadoop. Desta forma, a cada instância chamada da classe Mapper, o QEF é executado e se torna responsável pela gerência dos fluxos de dados em cada um dos nós de armazenamento e processamento. Para avaliar o desempenho da arquitetura com a incorporação de um gerenciador de workflows, foram realizados testes onde o QEF exerce a função de controle dos fluxos de dados, além de testes com as rotinas de persistência executadas diretamente pela classe Mapper do Hadoop. Os resultados e análises destes testes encontram se detalhados na seção Meta 6: Execução de testes e análise comparativa entre a arquitetura proposta e a arquitetura atual Para a execução desta meta, foram previstos e executados testes com o objetivo de comparar o tempo de execução da arquitetura proposta neste trabalho e a arquitetura atualmente em uso pelo Portal Ogando. A análise comparativa das arquiteturas em questão possibilitou, além da definição de qual arquitetura deve ser considerada mais adequada para esta situação, como também as razões pelas quais as arquiteturas apresentaram desempenhos tão díspares, ao considerar o tempo de execução como métrica de avaliação. 5 Realização de Testes e Análise da Arquitetura Com o propósito de validar a arquitetura proposta, foi preparado um ambiente de processamento de alto desempenho com as seguintes características: Hardware: Cluster SGI com 95 nós de processamento, sendo 1 nó mestre (duas placas, cada placa com dois processadores Intel Xeon X5650, 2.67GHz, 6 núcleos reais por processador, com possibilidade de Hyper-threading, 24GB memória, 1,5TB de disco rígido) e 94 nós escravos (duas placas, cada placa com dois processadores Intel Xeon X5650, 2.67GHz, 6 núcleos reais por processador, com possibilidade de Hyper-threading, 24GB memória, 500GB de disco rígido); Software: 11

12 Framework Hadoop; Sistema Gerenciador de Banco de Dados PostgreSQL. O ambiente utilizado atualmente pelo projeto DES-Brazil necessita de aproximadamente 50 minutos para a execução do workflow de aplicações SkyMap e SkyMapAdd. De posse destas informações, foram realizados vinte testes de execução com a arquitetura proposta, sendo dez com o uso do QEF como gerenciador de workflow e dez sem o uso do QEF. Os resultados dos testes, em tempo médio de execução, foram os seguintes: Testes sem o QEF: Tempo médio de execução aproximadamente igual a 2 minutos e 40 segundos; Testes com o QEF: Tempo médio de execução aproximadamente igual a 2 minutos e 10 segundos; Com os resultados dos testes realizados, foi possível observar que, em ambos os casos, o tempo de execução da arquitetura proposta foi, aproximadamente, 95% menor do que o tempo de execução da arquitetura utilizada atualmente pelo Portal Ogando. Esta diferença de desempenho ocorre principalmente pela forma como o acesso aos dados está sendo feito em cada uma das arquiteturas e pela remoção dos módulos DataRetriever e DataOrganizer. Em relação à diferença de 30 segundos constatada entre os testes sem e com o uso do QEF, pode se concluir que o uso de um gerenciador de workflow sobre um grande volume de dados oferece um resultado mais satisfatório devido aos métodos de acesso e controle de fluxo utilizados. 6 Conclusões e Trabalhos Futuros Este trabalho apresentou uma proposta de arquitetura paralela para aplicações BigData, no que tange o armazenamento e o processamento de dados. Como estudo de caso para validar a arquitetura, foi utilizada uma situação problema, onde há a necessidade de otimizar a arquitetura atual, a fim de reduzir o tempo de execução dos processos do Portal Ogando da área de Astronomia. Com a elaboração da arquitetura e com os testes executados, foi possível concluir que a arquitetura proposta neste trabalho apresentou resultados satisfatórios, quando comparados à arquitetura atualmente em uso. Estes resultados se deram em função da fragmentação do banco de dados de teste do portal em um ambiente distribuído, acessado por uma aplicação que 12

13 engloba o uso conjunto do Hadoop, como implementação do algoritmo MapReduce, e do QEF com o papel de gerenciar os fluxo de informações entre a aplicação e o banco de dados. A realização deste trabalho possibilitou um estudo profundo sobre o funcionamento do framework Hadoop. Foi possível identificar uma série de configurações possíveis, e que ele admite recursos que não foram utilizados neste trabalho. No entanto, houve dificuldades em definir configurações inicialmente consideradas simples, dentre as quais a quantidade de funções MapReduce executadas por nó de processamento. Como propostas de trabalhos futuros, merecem destaque: a otimização da arquitetura proposta, de forma a tornar a implementação mais flexível, utilizando recursos relevantes disponibilizados pelo framework Hadoop; a implementação de uma estratégia mais eficiente para a fragmentação de grandes volumes de dados; a elaboração e a implementação de um modelo de tolerância a falhas do banco de dados distribuído; a adaptação da arquitetura proposta para ambientes de nuvens computacionais e; o desenvolvimento de um portal para aplicações BigData. Referências [1] Shrinivas B. Joshi. Apache hadoop performance-tuning methodologies and best practices. In Proceedings of the third joint WOSP/SIPEW international conference on Performance Engineering, ICPE 12, pages , New York, NY, USA, ACM. Citado na página 9. [2] Andrew W. McNabb, Christopher K. Monson, and Kevin D. Seppi. Parallel pso using mapreduce. In IN PROC. OF THE CONGRESS ON EVOLUTIONARY COMPUTATION, Citado na página 9. [3] Fabio Porto, Othman Tajmouati, Vinicius F. V. Da Silva, Bruno Schulze, and Fausto V. M. Ayres. Qef - supporting complex query applications. In CCGRID 07: Proceedings of the Seventh IEEE International Symposium on Cluster Computing and the Grid, pages , Washington, DC, USA, IEEE Computer Society. Citado nas páginas 6 and 10. [4] Energy Department U.S. The magellan report on cloud computing for science Citado na página 4. [5] Daniel L. Wang, Serge M. Monkewitz, Kian-Tat Lim, and Jacek Becla. Qserv: a distributed shared-nothing database for the lsst catalog. In State of the Practice Reports, SC 11, pages 12:1 12:11, New York, NY, USA, ACM. Citado na página 5. 13