EDUARDO PETRINI SILVA CASTRO UMA PROPOSTA DE IMPLEMENTAÇÃO DO ALGORITMO APRIORI DISTRIBUÍDO UTILIZANDO O ARCABOUÇO HADOOP MAPREDUCE

Transcrição

1 EDUARDO PETRINI SILVA CASTRO UMA PROPOSTA DE IMPLEMENTAÇÃO DO ALGORITMO APRIORI DISTRIBUÍDO UTILIZANDO O ARCABOUÇO HADOOP MAPREDUCE LAVRAS MG 2014

2 EDUARDO PETRINI SILVA CASTRO UMA PROPOSTA DE IMPLEMENTAÇÃO DO ALGORITMO APRIORI DISTRIBUÍDO UTILIZANDO O ARCABOUÇO HADOOP MAPREDUCE Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Sistemas de Informação para obtenção do título de Bacharel em Sistemas da Informação. Orientador Prof. DSc. Denilson Alves Pereira LAVRAS MG 2014

3 EDUARDO PETRINI SILVA CASTRO UMA PROPOSTA DE IMPLEMENTAÇÃO DO ALGORITMO APRIORI DISTRIBUÍDO UTILIZANDO O ARCABOUÇO HADOOP MAPREDUCE Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Sistemas de Informação para obtenção do título de Bacharel em Sistemas da Informação. APROVADA em 10 de Fevereiro de Prof. DSc. Ahmed Ali Abdalla Esmin UFLA Prof. DSc. Leonardo Andrade Ribeiro UFLA Prof. DSc. Denilson Alves Pereira (Orientador) LAVRAS MG 2014

4

5 Dedico este trabalho a toda a minha família por me darem todas as condições necessárias e, principalmente, apoio incondicional em todos os momentos para que eu realizasse este sonho de me formar em Sistemas de Informação. Dedico, também, ao minha namorada Ana Paula Martins Inácio por toda a força e incentivo repassados para que, em meio de toda adversidade, fizesse com que eu não desistisse e persistisse na realização desse sonho. Peço a Deus que os ilumine e retribua toda dedicação e afetividade que tiveram por mim.

6 AGRADECIMENTOS À Universidade federal de Lavras (UFLA), ao Departamento de Ciência da Computação e ao Departamento de Administração e Economia, pela oportunidade concedida para a realização da graduação. Aos professores do Departamento de Ciência da Computação e do Departamento de Administração e Economia pelos ensinamentos transmitidos e harmoniosa convivência. Ao Prof. Dr. Denilson Alves Pereira pela orientação e pelo auxílio neste projeto como também pela confiança depositada em mim em trabalhos realizados nestes anos de faculdade, que foram de grande relevância para a realização deste trabalho e para meu crescimento pessoal e profissional. A todos os colegas do LI- CESA e amigos do curso, em especial Ana Paula Martins Inácio pela ajuda e pela convivência, que foram de grande importância e significância em meu dia-a-dia na Universidade.

7 RESUMO Com o constante aumento no volume de dados gerados diariamente, surgem problemas de eficiência em muitos algoritmos que trabalham com grandes quantidades de dados. Uma parte desses algoritmos é utilizada em mineração de dados para encontrar padrões ocultos em diversos conjuntos de dados. Dentre eles, existe o algoritmo Apriori, que consiste em uma implementação bem conhecida de regras de associação visando encontrar relações entre itens em uma dada base de transações. É eficiente para pequenos conjuntos de dados, porém seu desempenho diminui a medida que o tamanho da entrada aumenta. Existem várias propostas para melhorar o desempenho de algoritmos, dentre elas estão a paralelização e distribuição do processamento. Este trabalho propõe uma técnica de implementação distribuída que busca aumentar a velocidade de processamento da etapa de geração de conjuntos de itens (itemsets) do algoritmo Apriori perante a um grande volume de dados. Para isso foi utilizado o arcabouço Hadoop MapReduce, um sistema de computação distribuída que permite armazenamento e processamento de dados em diversas máquinas organizadas em um cluster. O algoritmo proposto implementa o conceito de arquivo invertido transformando a base de dados de transações em uma estrutura de dados semelhante a uma tabela hash, onde a chave são os itens e o valor representa o conjunto de transações em que o item ocorreu. O algoritmo é divido em 3 fases fundamentais e dependentes entre si. Cada fase gera um conjunto de dados de saída que é utilizado como entrada para a fase seguinte. Foram realizados experimentos utilizando bases sintéticas e uma base real. Palavras-Chave: Hadoop; MapReduce; Paralelização; Distribuição; Mineração de Dados, Apriori.

8 ABSTRACT With the constant increase in the volume of data generated daily, arise efficiency problems in many algorithms that work with large mounts of data. Some these algorithms are used in mining data to find hidden patterns in different data sets. Among them, there is Apriori algorithm, which consists of a successful implementation known association rules aimed at finding relationships between items in a given transaction database. It is efficient for small data sets, but performance decreases as the input size increases. There are several proposals to enhance the performance of algorithms, among which are parallelization and distribution processing. This paper proposes a technique a distributed implementation that seeks to increase the processing speed of generating sets of items (itemsets) step Apriori Algorithm owed to a large volume of data. To this was Hadoop MapReduce framework used for a computing system allowing distributed storage and data processing in various machines arranged in a cluster. The proposed algorithm implements the concept of inverted file, transforming the database transactions in a structure similar to a hash table data, which the key are items and the value is the set of transactions in which the item occurred. The algorithm is divided into 3 fundamental and interdependent stages. Each step generates a data set output that is used as input to the next stage. Experiments using synthetic bases and a real basis were performed. Keywords: Hadoop; MapReduce; Paralelização; Distribuição; Mineração de Dados, Apriori.

9 SUMÁRIO 1 Introdução Contextualização Objetivos Objetivo Geral Objetivos Específicos Justificativa Organização deste Documento Referencial Teórico MapReduce WordCount Hadoop Arquitetura Hadoop daemons Mineração de dados Mineração de Regras de Associação Algoritmo Apriori Algoritmo Apriori Utilizando o MapReduce Metodologia Classificação do Trabalho Desenvolvimento do Trabalho Algoritmo Apriori MapReduce Descrição do Algoritmo Primeira Fase Segunda Fase Terceira Fase

10 4.2 Configurações para o MapReduce Experimentos e Resultados Ambiente de Experimentos Bases de Dados Estratégia de Execução e Balanceamento de Carga Experimento com as Bases de Dados Conclusão 61 A Instalação e Configuração do Hadoop 68 A.1 Antes da Instalação A.2 Hadoop A.2.1 hadoop-env.sh A.2.2 core-site.xml A.2.3 hdfs-site.xml A.2.4 mapred-site.xml A.2.5 yarn-site.xml A.3 Inicialização do Hadoop

11 LISTA DE FIGURAS 2.1 Etapas do MapReduce (GRONINGEN, 2009) Arquitetura do Hadoop 1.x.x (APACHE, 2011) Arquitetura do Hadoop 2.x.x (APACHE, 2014) Arquitetura do JobTracker Arquitetura YARN (APACHE, 2013) Geração de itemsets Fluxo de execução do processamento das entidades (CRYANS et al., 2010) Fluxo de execução do Apriori MapReduce (LI et al., 2012) Estrutura do Arquivo Invertido Fluxo MapReduce da Primeira Fase Fluxo MapReduce da Segunda Fase Fluxo MapReduce da Terceira Fase Tempo de Execução por Suporte Mínimo Speedup para as bases de dados sintéticas Tempo de execução por suporte mínimo: base real Speedup para a base de dados real

12 LISTA DE TABELAS 2.1 Conjunto de dados de transações Computador Mestre Computadores Escravos Base de Dados Sintéticas

13 11 1 INTRODUÇÃO 1.1 Contextualização Nos últimos anos, a quantidade de dados e informações geradas por empresas e pessoas aumentou a níveis extraordinários. Proporcionalmente também aumentou o custo computacional para o processamento desses dados. Muitos algoritmos que funcionavam bem há uma ou duas décadas atrás, hoje podem não ser tão eficientes perante a quantidade de dados muito maior para qual foram projetados. Grande parte dos algoritmos afetados são da área de mineração de dados, utilizados por diversas organizações para extração de informações. Mineração de dados é a área da computação que busca obter informações implícitas em um determinado conjunto de dados. Os algoritmos de mineração buscam encontrar padrões em dados, e alguns necessitam ler o conjunto de dados mais de uma vez. O problema é que se o volume de dados for muito grande, a execução desses algoritmos tende a ser demorada (WITTEN et al., 2011). O algoritmo Apriori é uma implementação bem conhecida de regras de associação (AGRAWAL; SRIKANT, 1994). O objetivo é gerar regras de acordo com os padrões de relacionamentos entre itens de uma determinada base de dados de transações. Para isso é necessário efetuar diversas combinações desses itens, o que pode resultar em centenas ou milhares de regras dependendo do tamanho da entrada. Para que o algoritmo gere somente um conjunto de regras interessantes para o usuário, é necessário definir um valor para o suporte e a confiança mínima. O suporte se refere à quantidade de ocorrência de um item ou uma combinação de itens na base de dados. Já a confiança é a proporção de um ou mais itens implicarem na ocorrência de outros itens. Muito se tem feito para melhorar o desempenho de algoritmos que trabalham com grandes volumes de dados, utilizando diversas técnicas, inclusive paralelização e distribuição. O método de paralelização permite a execução de vários

14 12 processos ao mesmo tempo em processadores que compartilham a mesma memória. O método de distribuição permite que processos sejam executados em diversos computadores diferentes, com memória independente, interligados por uma rede. A paralelização também pode ser distribuída onde cada processo executado em uma máquina diferente com memória não compartilhada. Com esses métodos é possível obter um ganho de desempenho, permitindo que algoritmos processem grandes volumes de dados em menos tempo. Uma das técnicas utilizadas para o processo de distribuição de processamento é o MapReduce (DEAN; GHEMAWAT, 2004), um paradigma de programação para processar e gerar grandes quantidades de dados de forma distribuída. É fundamentado na ideia de mapear e reduzir, processando dados no formato chave / valor. É uma implementação de um paradigma de programação muito útil para processamento de dados e pode ser usada em diversas áreas (GUNARATHNE et al., 2010). Uma implementação bem conhecida do MapReduce é o Hadoop que foi desenvolvido pela Apache Yahoo. É capaz de gerenciar o armazenamento e o processamento de grandes quantidades de dados de forma distribuída e com eficiência. Possui um sistema de arquivos distribuídos denominado HDFS (HDFS, 2010), inspirado no Google File System (GHEMAWAT et al., 2003). Muitas empresas usam o Hadoop como plataforma base para gerenciar grandes quantidades de dados como o Facebook (BORTHAKUR et al., 2011) e Twitter (LIN; KOLCZ, 2012). 1.2 Objetivos Objetivo Geral Este trabalho tem por objetivo propor uma implementação do módulo de geração dos itemsets do algoritmo de regras de associação, denominado Apriori, utilizando um sistema de programação distribuída.

15 Objetivos Específicos Para desenvolver a aplicação é necessário atingir os objetivos específicos listados: Preparar o ambiente de desenvolvimento executando o sistema Hadoop em um cluster. Pesquisar e compreender o funcionamento do algoritmo Apriori. Mapear o algoritmo Apriori para o paradigma de programação MapReduce. Realizar experimentos com diversas bases de dados. 1.3 Justificativa O campo de computação distribuída cada vez mais abre portas para o desenvolvimento de algoritmos que processe grandes volumes de dados. Com o surgimento do framework Hadoop/MapReduce, muitos pesquisadores implementaram suas propostas de mapeamento de diversos algoritmos para o arcabouço MapReduce. Para o algoritmo de mineração de dados Apriori, existem trabalhos recentes que também propõem o seu mapeamento para o modelo MapReduce, como (CRYANS et al., 2010), (LIN et al., 2012), (YANG et al., 2010) e (LI et al., 2012). Porém, cada um com suas características e limitações. Alguns possuem propósitos específicos, como (CRYANS et al., 2010) que foi projetado para receber o conjunto de dados de entrada, obtidos da Web, a partir de um sistema de armazenamento denominado HBase (APACHE, 2014). Em (LIN et al., 2012) são propostas três versões de algoritmos Apriori mapeados para o paradigma MapReduce, utilizando um processo iterativo, porém ambos necessitam varrer a base de dados de transações original, a cada iteração, para a gerar os conjuntos de itens frequentes. A estratégia de ler a base de transações diversas vezes também é utilizada em (LI et al., 2012) e (YANG et al., 2010), o que torna-se um gargalo quando essa base contém milhares de transações.

16 14 Muito ainda pode ser feito em relação ao desenvolvimento do algoritmo Apriori utilizando o MapReduce, de modo a, reduzir a quantidade de leituras da base de transações originais, que seja mais eficiente e adequada a diversos tipos de bases de dados. Neste sentido, nossa proposta utiliza uma estratégia para efetuar a leitura da base de transações somente uma vez, transformando-a em um arquivo invertido que é utilizado para a geração dos itemsets. 1.4 Organização deste Documento O restante deste documento está organizado a seguinte forma: na Seção 2 é apresentado o referencial teórico. A metodologia é apresentada na Seção 3. Na Seção 4 é apresentado e descrito o algoritmo utilizado neste trabalho. Os resultados são apresentados na Seção 5 seguido pela conclusão na Seção 6. No final há o Apêndice A detalhando o processo de instalação e configuração do framework Hadoop.

17 15 2 REFERENCIAL TEÓRICO 2.1 MapReduce O MapReduce é uma uma técnica de programação distribuída proposta pelo Google para processar dados em grande escala, paralelamente, em um ambiente de computação distribuída (DEAN; GHEMAWAT, 2004). Ele opera exclusivamente com entradas e saídas no formato <chave/valor>. Nesta seção, daremos uma visão geral do funcionamento do MapReduce implementando o algoritmo de teste chamado WordCount (WORDCOUNT, 2011) WordCount O algoritmo WordCount, proposto para fins de teste, é a demonstração do funcionamento básico do MapReduce, e tem como objetivo contar a ocorrência de cada palavra em um arquivo de texto qualquer. O primeiro passo para a execução do código é pegar um arquivo de texto qualquer e armazená-lo no HDFS. Vamos supor que o arquivo de texto tenha o seguinte conteúdo: 1 Deer Beer River 2 Car Car River 3 Deer Car Bear Inicialmente a entrada <chave/valor> do algoritmo é o número da linha e o conteúdo da linha em questão. Essa é a entrada para a primeira função do MapReduce, a função Map. Nesta função o objetivo é processar a linha do arquivo para extrair todas as palavras do texto e, para cada palavra, adicionar um contador com o valor 1. Esse par de dados <palavra/contador(1)> é gerado para cada palavra do texto. Ou seja, após a execução da função Map a saída terá a seguinte forma: 1 Deer 1

18 16 2 Bear 1 3 River 1 4 Car 1 5 Car 1 6 River 1 7 Deer 1 8 Car 1 9 Bear 1 Observe que para cada palavra encontrada no texto, o algoritmo gerou uma chave (a palavra) e um valor (1). Terminado a função Map, uma passo intermediário é executado para efetuar o agrupamendo de ordenação lexicograficamente das chaves emitidas na função Map: 1 Bear 1 2 Bear 1 3 Car 1 4 Car 1 5 Car 1 6 Deer 1 7 Deer 1 8 River 1 9 River 1 A função Reduce é, então, chamada com o objetivo de contar quantas vezes uma determinada chave apareceu. Ou seja, para cada ocorrência da chave, incremente o seu valor por 1. A saída será todas as ocorrências de palavras distintas encontrada no texto e a quantidade de vez que ela apareceu: 1 Bear 2 2 Car 3 3 Deer 2 4 River 2

19 17 A Figura 2.1 ilustra o esquema de funcionamento do MapReduce e todas suas etapas para o exemplo em questão. Figura 2.1: Etapas do MapReduce (GRONINGEN, 2009) Observa-se que há 4 etapas para produzir o resultado final. O arquivo texto armazenado no HDFS é primeiramente divido em blocos e espalhado pelos computadores do cluster. Em seguida a função Map efetua o processamento dos dados de acordo com a implementação feita pelo usuário. Na etapa de Shuffling ocorre o agrupamento dos dados na forma de <chave/valor> de acordo com a chave. Assim a função Reduce processa esses dados e incrementa o contador de cada chave para gerar o resultado final. O MapReduce tem sido usado pelo Google e por diversas outras empresas para muitos diferentes propósitos. Existem diversas razões para a ascensão do MapReduce, dentre elas, destacamos a facilidade de uso, os programadores não precisam ter experiência com sistemas paralelos e distribuídos, já que toda a questão de detalhes da paralelização são invisíveis ao usuário. Uma grande variedade de problemas podem ser facilmente expressados no MapReduce. Por exemplo, o Google utiliza o MapReduce para tratar os dados gerados pelo serviço de busca na Web. Há também implementações para soluções de problemas ou otimização nas áreas de mineração de dados, aprendizagem de máquina, tratamento de texto

20 18 como busca, indexação e tokenização, cloud computing, dentre outras (DEAN; GHE- MAWAT, 2004). 2.2 Hadoop O Hadoop (APACHE, 2011) é uma implementação de código aberto do framework Google MapReduce (DEAN; GHEMAWAT, 2004) que possibilita desenvolver aplicações para serem executadas de forma distribuída. O Hadoop usa o Hadoop Distribuited File System (HDFS) (HDFS, 2010), uma implementação do Google File System (GHEMAWAT et al., 2003), para compartilhar dados em um cluster de computadores. O HDFS é um sistema para armazenamento de dados distribuído e primário usado pelas aplicações do Hadoop. É adequado para armazenamento e processamento distribuído usando computadores comuns, chamados de commodity hardware. As principais características que diferem o HDFS dos demais sistemas de aquivos distribuídos é sua tolerância à falhas, escalabilidade e simplicidade para expandir a capacidade de armazenamento. Recentemente o framework Hadoop passou por uma grande atualização que modificou o funcionamento de alguns dos seus componentes, principalmente os voltados para o gerenciamento de aplicações (APACHE, 2013). Essa nova geração do Hadoop introduz uma nova arquitetura para o gerenciamento de aplicações denominada YARN (Yet Another Resource Negotiator) que foi projetada para solucionar os problemas de escalabilidade presentes na versão anterior do Hadoop/- MapReduce. Foi introduzido na versão 0.23 do Hadoop e já está presente a partir das versões 2.x.x do framework (APACHE, 2013). Nas próximas seções será feito uma descrição de sua arquitetura procurando comparar a diferença entre as versões antiga (Hadoop 1.x.x ou inferior) e a nova (Hadoop 2.x.x).

21 Arquitetura A arquitetura do Hadoop é baseada no paradigma mestre/escravo. Na versão antiga do Hadoop um cluster HDFS poderia possuir somente um NameNode (serviço mestre) e vários DataNodes (escravos) (LAM, 2010). Na nova versão, é possível ter mais de uma NameNode por cluster por meio do novo recurso denominado HDFS Federation (HORTONWORKS, 2014; APACHE, 2014), que fornece melhoria na escalabilidade e opção de isolamento de dados. O NameNode é um serviço mestre que gerencia o sistema de arquivos e o acesso aos dados pelos clientes. No Hadoop 1.x.x, por existir somente um Name- Node por cluster, uma falha no mestre deixaria todo o sistema inoperante até que o NameNode inicie novamente (BORTHAKUR et al., 2011). Já na nova versão, se o cluster possuir mais de um NameNode, o funcionamento dos DataNodes não é prejudicado caso algum nó mestre falhe. Cada máquina de um cluster possui um DataNode que gerencia o armazenamento em cada nó que está rodando. Os arquivos armazenados no HDFS pelos usuários são divididos em um ou mais blocos de 64Mb (padrão) ou um tamanho definido pelo usuário, e são armazenados nos DataNodes. Os DataNodes também executam a criação, exclusão e replicação de blocos no sistema de arquivos. Figura 2.2: Arquitetura do Hadoop 1.x.x (APACHE, 2011)

22 20 A Figura 2.2, ilustra a arquitetura do Hadoop 1.x.x. Apresenta um NameNode e cinco DataNodes com dados armazenados divididos em blocos. Esses blocos são replicados (3 vezes por padrão ou um valor especificado pelo usuário) através dos DataNodes. Essa replicação permite a recuperação de dados caso algum nó falhe. Isso torna o Hadoop um sistema tolerante a falhas. Figura 2.3: Arquitetura do Hadoop 2.x.x (APACHE, 2014) A arquitetura do Hadoop 2.x.x é ilustrado na Figura 2.3. Nota-se que é possível ter vários NameNodes por cluster, cada um responsável por um conjunto de dados, garantindo o isolamento. O Block Pool é uma camada abstrata para facilitar o gerenciamento dos blocos de cada NameNode sem a necessidade de coordenação com os outros NameNodes. Caso algum NameNode venha a falhar, somente os dados o qual gerencia ficará inacessível até que volte a executar. O HDFS também suporta gerenciamento de arquivos para que o usuário possa criar, renomear e excluir arquivos e diretórios do sistema. Para isso, o NameNode fornece uma interface de linha de comando chamada FS Shell (HADOOP, 2009). Nela, o usuário interage com os dados no HDFS criando e removendo arquivos ou diretórios, além de ver conteúdo de arquivos de texto. Também fornece alguns comandos para administrar o cluster, por exemplo, listar e obter informações dos DataNodes ativos no momento.

23 Hadoop daemons Os Hadoop daemons são os serviços que executam quando o Hadoop é iniciado. O NameNode é o daemon principal que controla o HDFS e dirige todos os DataNodes. Há ainda outros daemons fundamentais para sua execução. Como dito anteriormente, o DataNode está presente em cada máquina escrava do cluster Hadoop para executar o trabalho pesado do sistema de arquivo - leitura e escrita no HDFS. Quando é requisitada a leitura de um arquivo no HDFS, o NameNode irá informar quais DataNodes contém cada bloco do arquivo. Os DataNodes irão processar os blocos correspondentes ao arquivo em questão. Um processo semelhante é o de escrita. Quando um arquivo é armazenado no HDFS, ele é divido em blocos que serão replicados através dos DataNodes. Cada DataNode sabe quais blocos de quais arquivos ele está armazenando. Isso permite uma taxa alta de leitura/escrita de dados. Outro daemon importante é o Secondary NameNode (SNN) (LAM, 2010). Trata-se de um daemon assistente para monitoramento do estado do cluster HDFS. A função do SNN é criar pontos de restauração para recuperação de configuração, caso o NameNode venha a falhar. Existem ainda dois outros daemons fundamentais para desenvolvimento de aplicações para processamento de dados no HDFS. Na versão 1.x.x do Hadoop esses daemons eram conhecidos como JobTracker e TaskTracker (LAM, 2010). O JobTracker era a ligação entre uma aplicação MapReduce e o Hadoop. Uma vez executado um código em cima do cluster, o JobTracker determina um plano de execução. Define quais arquivos irá processar, quais nós atribuir para diferentes tarefas, além de monitorar todas as tarefas em execução. Se uma tarefa falhar, o daemon automaticamente realoca a tarefa para outra máquina. O TaskTracker é o daemon escravo do JobTracker que gerencia tarefas individuais em cada nó escravo. Cada TaskTracker executa as tarefas que o JobTracker atribuir. Apesar de existir somente um TaskTracker para cada nó do cluster,

24 22 o daemon pode gerar múltiplas JVMs (Java Virtual Machines) para manipular as tarefas do MapReduce em paralelo. O TaskTracker também tinha a responsabilidade de se comunicar constantemente com o JobTracker. Se a comunicação entre o JobTracker e um TaskTracker específico falhasse, o JobTracker assumiria que esse TaskTracker não está funcionando e logo realocaria a tarefa correspondente a outro nó do cluster. A Figura 2.4 apresenta um esboço do funcionamento do JobTracker e os TaskTracker em um cluster. Figura 2.4: Arquitetura do JobTracker Com a nova arquitetura YARN os antigos JobTracker e TaskTracker foram substituídos por novos serviços que descentralizam as responsabilidades e permite um gerenciamento mais eficiente do cluster. Os demais serviços, Name- Node, DataNode e SecondaryNameNode, foram mantidos e melhorados. O novo gerenciador de recursos, ResoucerManager, é o principal daemon que executada na máquina mestre e sua principal função é atribuir os recursos necessários para todas as aplicações a serem executadas no sistema. Trabalha junto com outros dois serviços que são executados em cada máquina escrava do cluster: NodeManager e ApplicationMaster. O NodeManager recebe as instruções do ResoucerManager e monitora o uso dos recursos (cpu, memória, disco e rede) de sua respectiva máquina escrava. O ApplicationMaster é responsável por negociar os recursos com o ResoucerManager, gerenciar cada instância de uma aplicação executando

25 23 no YARN e trabalha com o NodeManager para alocar e monitorar o conjunto de recursos necessários para a aplicação. Figura 2.5: Arquitetura YARN (APACHE, 2013) O ResoucerManager possui dois componentes principais: um escalonador e um gerenciador de aplicação. O escalonador é responsável por alocar os recursos para todas as aplicações em execução. Os recursos são organizados abstratamente em contêineres de acordo com os requerimentos da aplicação. O gerenciador de aplicação, por sua vez, é responsável por aceitar os jobs submetidos, negociar o contêiner de recursos com o ApplicationMaster e fornecer um serviço que reiniciar o ApplicationMaster em caso de falhas. A Figura 2.5 ilustra a arquitetura YARN. Analisando a Figura 2.5 é possível perceber a importância do Resoucer- Manager para o cluster como um todo. O NodeManager, responsável por monitorar os recursos, reporta o status de cada contêiner de seus respectivos nós. Uma vez que uma aplicação é submetida pelo cliente, inicia-se o processo de negociação de recursos entre o ApplicationMaster e o ResoucerManager para disponibilizar um contêiner necessário para atender os requisitos da aplicação. Enquanto uma aplicação é executada, o NodeManager envia relatórios com status dos recursos utilizados. O ApplicationMaster gerencia a instância da aplicação que está sendo

26 24 executada e, quando finaliza, ele reporta ao ResoucerManager o fim da aplicação e termina. O YARN não é apenas uma atualização melhorada do Hadoop, mas também uma plataforma genérica que fornece um ambiente para outros tipos de paradigmas além do MapReduce, tais como, processamento de grafos, processamento iterativo, machine learning e diversas computações complexas que podem ser executadas em um cluster. 2.3 Mineração de dados Devido ao constante aumento do volume de dados, a necessidade de analisá-los de forma efetiva e rápida se tornou fundamental. Mineração de dados surgiu da necessidade de busca por conhecimento omitido e padrões em diversos conjuntos de dados de forma automatizada para auxiliar na tomada de decisão (WITTEN et al., 2011). Com a tecnologia cada vez mais presente na sociedade torna-se fácil armazenar dados sobre hábitos de compra, hábitos financeiros, entre outros que podem conter algum conhecimento oculto ou algum padrão útil para definir estratégias de empresas. Existem diversas técnicas em mineração de dados, dentre as principais estão regra de associação, classificação e clusterização. Regra de associação é um método usado para encontrar relações entre itens de uma mesma base de dados. Utiliza os conceitos de suporte e confiança para poder gerar regras que sejam interessantes ao usuário. Já para a classificação a estratégia é gerar um modelo baseando-se em dados de treinamento (dados que já possuem a classe conhecida). Esse modelo pode ser em forma de regras (if then), árvore de decisão, fórmulas matemáticas ou redes neurais e será usado para predizer a classe dos dados que serão classificados (HAN; KAMBER, 2011).

27 25 Ao contrário de classificação e regras de associação que predizem atributos, em clusterização o objetivo é agrupar os conjuntos de dados com características semelhantes. Os dados são divididos em grupos baseando-se na similaridade de seus atributos. Assim, cada cluster gerado pode ser visto como uma classe possibilitando a geração de regras. 2.4 Mineração de Regras de Associação Essa técnica gera regras do tipo if then, ou seja, se ocorreu isso, então ocorreu aquilo, por exemplo: em uma base de dados de supermercado descobriu-se que diversos clientes que compraram pão também compraram manteiga. A regra, então, ficaria da seguinte forma: se cliente compra pão, então compra manteiga. Em regras de associação um atributo (comprou pão) pode predizer um ou mais atributos (comprou manteiga e comprou leite, por exemplo). Regras de associação também introduz os conceitos de suporte e confiança para que as regas sejam geradas de acordo com as necessidades do usuário. Para uma base de dados muito grande, a quantidade de regras geradas pode chegar a números exorbitantes. Para limitar a quantidade de regras utiliza-se também o conceito de suporte mínimo e confiança mínima. Suporte é a quantidade de ocorrências de um item ou uma combinação de itens presentes na base de dados de transações. O suporte mínimo é a quantidade mínima, definida pelo usuário, de ocorrência dos itens. Na Tabela 2.1, que representa um banco de dados de transações (onde a primeira coluna é o identificar das transações (TID) e a segunda coluna são os itens), se o suporte mínimo for definido como 2, somente os itens que ocorreram duas ou mais vezes (itens 1, 2, 3 e 5) serão processados pelo algoritmo, os demais serão excluídos. A confiança é a proporção de um ou mais itens implicarem na ocorrência de outros itens. Por exemplo, o item 3 ocorreu três vezes na base de dados de transações assim como o item 5. Porém a proporção de vezes que a ocorrência do

28 26 Tabela 2.1: Conjunto de dados de transações TID Itens item 3 implicou na ocorrência do item 5 é de 66.7%. A confiança mínima, por sua vez, é a proporção mínima, definida pelo usuário, necessária para gerar as regras. No exemplo anterior, se a confiança mínima for 60% a regra se comprou 3, então comprou 5 seria válida. 2.5 Algoritmo Apriori O algoritmo Apriori (AGRAWAL; SRIKANT, 1994) é uma proposta de implementação da técnica de geração de regras de associação e foi projetado inicialmente para encontrar padrões em banco de dados de transações comerciais. Geralmente, cada linha da base de dados consiste de um conjunto de itens pertencentes a uma transação. O objetivo do Apriori é gerar regras de associação baseando-se na quantidade de vezes que dois ou mais itens ocorreram juntos no conjunto de transações, efetuando diversas combinações entre os itens. Para que o algoritmo gere todas as regras interessantes para o usuário, é necessário efetuar diversas leituras na base de dados de transações. Na primeira leitura, o objetivo é efetuar a contagem do suporte dos itens individualmente (1- itemset), identificando quais possuem um suporte maior do que o suporte mínimo definido, para utilizá-los na geração dos próximos conjuntos de itens de tamanho k (k-itemsets), k > 1.

29 27 Para a geração dos conjuntos de itemsets de tamanho k, é realizado um procedimento de junção entre os itens do conjunto de itemsets de tamanho k-1, de acordo com o critério dos prefixo iguais proposto em (AGRAWAL; SRIKANT, 1994). Ou seja, as combinações só são efetivadas entre os itens que possuem o mesmo prefixo, como ilustrado pela Figura 2.6. Observa-se que no conjunto de itemsets de tamanho 2, os itens com o mesmo prefixo são combinados entre si, resultando em um novo conjunto de itemsets de tamanho 3. O mesmo procedimento é executado para a geração do itemset de tamanho 4. Na Figura 2.6, somente os 3-itemsets a b c e a b d possuem o mesmo prefixo. Logo, são combinados gerando o itemset de tamanho 4. Figura 2.6: Geração de itemsets Cada novo conjunto de itens gerados é denominado conjunto de itens candidatos e o suporte é calculado consultando novamente a base de dados de transações. Em seguida os itemsets que não atingirem o valor do suporte mínimo são podados do conjunto candidatos, gerando um novo conjunto de itens denominado conjunto de itens frequentes. O processo continua até que nenhum novo conjunto de itens candidatos seja criado. A próxima e última etapa consiste na geração das regas. Para cada conjunto de itens frequentes gera-se as regras de acordo com o valor de confiança definido pelo usuário. Existem diversas propostas de melhorias para o algoritmo Apriori. No mesmo trabalho que apresentam o algoritmo descrito acima (AGRAWAL; SRIKANT,

30 ), os autores também demostram uma variação do Apriori, denominada AprioriTid cujo a principal características é a leitura da base de dados de transações somente uma vez, na etapa de geração dos itens de tamanho 1. Isso é possível mapeando a base de dados original para uma estrutura semelhante a um array indexado, onde o índice é o identificador da transação (TID) e o valor é o conjunto de k-itemsets presentes na transação. Dessa forma o suporte pode ser calculado contando quantas vezes o mesmo itemset ocorreu para TID diferentes. Outros trabalhos como (CHEN et al., 2011) apresentam uma proposta de melhoria na etapa de poda para evitar a leitura da base de dados diversas vezes. Em (PARK et al., 1995) utiliza-se uma estrutura de tabela hash para otimizar o processo de geração do k-itemsets. Uma técnica de segmentação da base de dados transações também são utilizadas para melhorar o desempenho do Apriori, como apresentado em (SAVASERE et al., 1995). 2.6 Algoritmo Apriori Utilizando o MapReduce Com o surgimento do MapReduce, muitas portas se abriram para soluções de problemas que necessitam processar volumosos conjuntos de dados. É possível mapear algoritmos de mineração de dados para o MapReduce de modo que a quantidade de dados processados não seja uma gargalo para as aplicações. Existem vários trabalhos que propõem implementações do algoritmo Apriori (AGRAWAL; SRIKANT, 1994) para o arcabouço Hadoop/MapReduce, como (YANG et al., 2010), (CRYANS et al., 2010), (LI et al., 2012) e (LIN et al., 2012). Eles se diferem em aspectos como origem dos dados de entrada, estratégia de implementação e o modo de utilização do framework. Em (CRYANS et al., 2010), a origem dos dados é do sistema de armazenamento HBase (APACHE, 2014), enquanto nos demais é utilizado o sistema de arquivos distribuídos do Hadoop. Em (YANG et al., 2010) e (CRYANS et al., 2010), o Hadoop/MapReduce é utilizado principalmente para contagem e poda dos itemsets. Já em (LI et al., 2012) o framework também é utilizado

31 29 para efetuar as combinações entre os itens. No trabalho de (LIN et al., 2012) são apresentadas 3 versões do algoritmo Apriori distribuído utilizando a estratégia de processo iterativo para a geração e poda dos itemsets. O pseudo código da implementação do algoritmo Apriori proposta por (YANG et al., 2010) é apresentado logo abaixo. 1 L 1 = find_frequent_1-itemset(d); 2 for (k = 2; L k 1!= /0; k++){ 3 C k = candidate_gen(l k 1, min_sup); 4 for each row of data t D { 5 C t = map(); 6 } 7 L k = reduce(); 8 } 9 return L = L k L k ; Nessa implementação, a função Map efetua a contagem dos itens no conjunto candidato de entrada, gerando um subconjunto que será a entrada da função Reduce. Esta, por sua vez, irá podar os itens candidatos gerando um subconjunto de itens frequentes com combinações de itens de tamanho k. Depois de todas as combinações possíveis serem feitas, retorna-se o conjunto de todos os itens frequentes L que será utilizado para gerar as regras de associação. Nos experimentos realizados, foram executados testes de Speedup, e observou-se que a proporção é mais relevante para conjunto de dados maiores, enquanto que, para o processamento de quantidade de dados menores, fatores como comunicação entre os nós, troca de dados e inicialização do ambiente tem maior influência no tempo de execução. A proposta de implementação do algoritmo apresentada em (CRYANS et al., 2010) tem como principal objetivo processar um grande volume de dados contendo feeds de notícias para encontrar relações entre entidades. Utiliza o conhecimento contido na Internet para revelar as ligações entre cidades, pessoas, objetos, monu-

32 30 mentos, ou outros conceitos tangíveis. A Figura 2.7 ilustra o fluxo de execução dessa proposta. Figura 2.7: Fluxo de execução do processamento das entidades (CRYANS et al., 2010) A implementação do Apriori tem a tarefa de identificar os conjuntos de itemsets (entidades) que possuem uma quantidade mínima de ocorrências maior do que a definida previamente. Os artigos são coletados da Web e armazenados no HBase. A fase Map consiste em obter os HTML s dos artigos armazenados no HBase e extrair as entidades que contenham um determinado número de ocorrências na página, gerando conjuntos de itemsets que são enviados para a função Reduce. Nessa função, os conjuntos são armazenados novamente em uma nova tabela no HBase. Na próxima etapa, os conjuntos de itemsets armazenados anteriormente são recuperados por meio de outra função Map e enviados para a função Reduce, onde são contados, podados e armazenados no HBase. Foram realizados experimentos em um cluster com 5 máquinas escravas, executando testes adicionando um escravo de cada vez. Percebeu-se que utilizando todas as máquinas o tempo de execução não é 5 vezes mais rápido do que os testes com apenas uma máquina. Os autores atribuíram como motivo a qualidade da distribuição dos dados no sistema de armazenamento de dados HBase. Quando se executa em apenas uma máquinas, todos os dados estão armazenados localmente, não necessitando acessar outras máquinas para obtê-los, algo que demandaria determinado tempo.