Projecto Em Engenharia Informatica

Home , Sanjay Ghemawat

UNIVERSIDADEDE LISBOA Faculdade de Cienciasˆ Departamento de Informatica´

ANALISE´ DE CORPORA JORNALISTICO´ ATRAVES´ DAS OCORRENCIASˆ DE N-GRAMAS

Joao˜ Antonio´ Monteiro de Oliveira

PROJECTO

MESTRADO EM ENGENHARIA INFORMATICA´ Especializac¸ao˜ em Sistemas de Informac¸ao˜

2015

UNIVERSIDADEDE LISBOA Faculdade de Cienciasˆ Departamento de Informatica´

ANALISE´ DE CORPORA JORNALISTICO´ ATRAVES´ DAS OCORRENCIASˆ DE N-GRAMAS

Joao˜ Antonio´ Monteiro de Oliveira

PROJECTO

Projecto orientado pelo Prof. Doutor Francisco Jose´ Moreira Couto e co-orientado pelo Prof. Doutor Bruno Emanuel da Graça Martins MESTRADO EM ENGENHARIA INFORMATICA´ Especializaçao˜ em Sistemas de Informaçao˜

2015

Agradecimentos

Gostaria de começar por agradecer ao meu orientador, o Professor Francisco Couto e ao meu co-orientador Bruno Martins por todo o apoio prestado durante todo o processo da criaçao˜ do trabalho que realizei e da tese resultante deste. Igualmente, gostaria de agradecer ao Professor Mario´ Silva e a todos os membros do projecto REACTION do INESC-ID que ajudaram a guiar o meu trabalho e me abriram as portas a uma experienciaˆ academica´ que me enriqueceu, tanto ao n´ıvel academico´ como ao n´ıvel pessoal. Devo a minha gratidao˜ a` minha fam´ılia, ao meu pai em especial, que me ajudaram a ver a importanciaˆ deste projecto quando a minha motivaçao˜ ja´ nao˜ era a mesma e a concluir este. Adicionalmente, gostaria de agradecer aos meus colegas de curso e amigos por toda a ajuda e conv´ıvio que partilharam comigo. Finalmente, tambem´ gostaria de agradecer a` FCT (Fundaçao˜ para a Cienciaˆ e Tecnologia) pelo seu apoio financeiro.

iii

Aos meus pais, Teresa Maria e Antonio´ Valdemar, pelo apoio e motivac¸ao˜

Resumo

O mundo jornal´ıstico mudou drasticamente com a transiçao˜ dos meios tradicionais de publicaçao˜ para o mundo digital. O aumento da informaçao˜ dispon´ıvel e o melhoramento dos meios de processamento desta facilitam a sua interpretaçao,˜ sendo assim poss´ıvel analisar a importanciaˆ de certos elementos informativos (memes) ao longo do tempo. O estudo destas tendenciasˆ permite avaliar as flutuaçoes˜ de interesse dos memes, possibilitando a previsao˜ de novos picos de popularidade e a correlaçao˜ destes com os eventos que estiveram na origem do referido interesse. Considerando esta realidade, o trabalho proposto nesta tese tem como objectivo a transformaçao˜ de um corpus jornal´ıstico em dados estat´ısticos que permitam a analise´ de tendenciasˆ ao longo de um per´ıodo de tempo. A soluçao˜ proposta deve ter em conta o tamanho do corpus a ser processado e como este afecta o tempo de processamento. Em termos anal´ıticos, deve considerar-se a performance da soluçao˜ e a validade dos resultados produzidos. Para responder aos objectivos propostos, construi a aplicaçao˜ Web Publico´ N-Gram Vi- ewer para a criaçao˜ de dados estat´ısticos e visualizaçao˜ de tendencaisˆ de N-Gramas. A analise´ da performance da soluçao˜ tem como base o tempo de execuçao˜ dos diversos algoritmos de criaçao˜ de N-Gramas para conjuntos de dados de tamanho variavel´ e o numero´ de maquinas´ usado para o processamento destes. Ao n´ıvel da validade dos resultados produzidos, sao˜ analisados exemplos onde se verifica a correlaçao˜ entre o numero´ de ocorrenciasˆ gerado e a ocorrenciaˆ de eventos que justifiquem o aumento de popularidade.

Palavras-chave: Prospecçao˜ de informaçao˜ em textos, Analise´ de N-Gramas, Indexaçao˜ de textos, jornalismo computacional, memes

vii

Abstract

The news world has changed drastically with the transition from the tradicional pub- lishing methods to the digital world. The increase of available information, as well as the improvement of the methods to process that information, facilitate its interpretation, al- lowing the analysis of the importance of memes along a period of time. The study of these tendencies allows the analysis and prediction of the future occurrences of the memes. Considering this reality, the point of this thesis is the creation of a software solution for the transformation of a corpus into statistic data and the study of the resulting trends for the given time period. The program must have in consideration the size of the corpus and how it will affect its performance. In terms of analysis, besides software performance, it is also necessary to confirm the validity of the produced statistics. In order to hit the goals defined for this thesis, the Publico´ N-Gram Viewer Web ap- plication was built. The solution creates statistical data from corpus text files given as input and allows the search for N-Gram interest tendencies in a time interval. The performance analysis is based on the time necessary for the completion of the algorithms for the creation of the N-Grams, given inputs of variable size and the number of nodes used for processing. Regarding the consistency of the produced results, examples are consid- ered where the correlation between the number of occurrences for a given N-Gram match events that occurred that justify the increase in popularity.

Keywords: Text data mining, N-gram analysis, full text search, computational journalism, memes

Conteudo´

Lista de Figuras xv

Lista de Tabelas xvii

1 Introduc¸ao˜ 1 1.1 Motivac¸ao...... ˜ 1 1.2 Objectivos ...... 2 1.3 Metodologia ...... 2 1.4 Estrutura do documento ...... 3 1.5 Conclusoes˜ do cap´ıtulo ...... 4

2 Trabalho relacionado 5 2.1 Back-End ...... 5 2.1.1 Finding and Exploring Memes in Social Media ...... 5 2.1.2 MapReduce: Simpliﬁed Data Processing on Large Clusters . . . .5 2.1.3 Computing n-Gram Statistics in MapReduce ...... 6 2.2 Interface ...... 7 2.2.1 Google NGram Viewer ...... 7 2.2.2 MemeTracker ...... 8 2.3 Conclusoes˜ do cap´ıtulo ...... 9

3 Analise´ 11 3.1 Arquitectura ...... 11 3.1.1 Camada de Dados ...... 12 3.1.2 Camada Logica´ ...... 13 3.1.3 Camada de Apresentac¸ao...... ˜ 14 3.2 Conlusoes˜ do cap´ıtulo ...... 14

4 Implementaçao˜ 17 4.1 Back-End ...... 17 4.1.1 Configuraçao/Inicializaç˜ ao...... ˜ 17 4.1.2 Tokenizador ...... 21

xi 4.1.3 MapReduce ...... 22 4.1.4 Algoritmo Principal ...... 23 4.1.5 Algoritmo de Categoria de Not´ıcias ...... 26 4.1.6 Algoritmo de Classificaçao˜ de Entidades ...... 26 4.1.7 Algoritmo de Classificaçao˜ Gramatical ...... 27 4.1.8 Construçao˜ das Estruturas de Dados ...... 28 4.1.9 Implementaçoes˜ descartadas ...... 29 4.2 Web Service ...... 30 4.3 Front-End ...... 35 4.3.1 Publico´ Online NGram Search ...... 36 4.3.2 Publico´ Online NGram Admin Client ...... 40 4.4 Principais Problemas Encontrados ...... 44 4.4.1 Actualizaçao˜ dos dados nas estruturas MapDB ...... 44 4.4.2 Criaçao˜ da aplicaçao˜ administrativa ...... 44 4.4.3 Criaçao˜ da estrutura de dados TreeMap na funçao˜ Reduce . . . . 45 4.4.4 Implementaçao˜ do cluster Hadoop ...... 45

5 Resultados 47 5.1 MapReduce ...... 47 5.1.1 Algoritmo Base ...... 48 5.1.2 Algoritmo de Categorias de Not´ıcias ...... 49 5.1.3 Algoritmo de Classificaçao˜ de Entidades ...... 50 5.1.4 Algoritmo de Classificaçao˜ Gramatical ...... 52 5.2 Estat´ısticas ...... 52 5.2.1 Pesquisa regular ...... 52 5.2.2 Pesquisa por Categoria ...... 54

6 Conclusao˜ 57 6.1 Trabalho Futuro ...... 58

Bibliograﬁa 60

Abreviaturas 61

A Anexos 63

Indice´ 71

xii xiv Lista de Figuras

2.1 Google Ngram Viewer ...... 7 2.2 MemeTracker ...... 8

3.1 Arquitectura da plataforma ...... 12

4.1 Publico´ Online N-Gram Search - News Articles ...... 34 4.2 Publico´ Online N-Gram Search - Start Screen ...... 36 4.3 Publico´ Online N-Gram Search - Normal Search ...... 37 4.4 Publico´ Online N-Gram Search - Category Search ...... 38 4.5 Publico´ Online N-Gram Search - Lexical Search ...... 38 4.6 Publico´ Online N-Gram Search - Entity Search ...... 39 4.7 Publico´ Online N-Gram Search - On Hover Info ...... 39 4.8 Publico´ Online N-Gram Search - Artigos que contem´ o N-Grama pesquisado 40 4.9 Publico´ N-Gram Search Admin Program - Main Window ...... 40 4.10 Publico´ N-Gram Search Admin Program - Upload Window ...... 41 4.11 Publico´ N-Gram Search Admin Program - Upload Conclu´ıdo ...... 42 4.12 Publico´ N-Gram Search Admin Program - Verificar Progresso ...... 43 4.13 Publico´ N-Gram Search Admin Program - Definiçoes˜ ...... 43

5.1 Tempo de execuçao˜ pelo tamanho do ficheiro corpus - Algoritmo Base . . 48 5.2 Funçoes˜ Map - Algoritmo Principal ...... 48 5.3 Tempo de execuçao˜ pelo tamanho do ficheiro corpus - Algoritmo Catego- ria Not´ıcias ...... 50 5.4 Tempo de execuçao˜ pelo tamanho do ficheiro corpus - Algoritmo Entidades 51 5.5 Tempo de execuçao˜ pelo tamanho do ficheiro corpus - Algoritmo Gramatical 52 5.6 Publico´ N-Gram Search - Pedro Passos Coelho ...... 53 5.7 Publico´ N-Gram Search Categoria - Pedro Passos Coelho ...... 54 5.8 Publico´ N-Gram Search Classe Gramatical - Pedro Passos Coelho . . . . 55

Lista de Tabelas

5.1 Conﬁgurac¸oes˜ das maquinas´ do cluster ...... 47

xvii

Cap´ıtulo 1

Introduc¸ao˜

A crescente transiçao˜ dos meios tradicionais de comunicaçao˜ social para o espaço digital veio trazer um novo conjunto de paradigmas relativos as` actividades normalmente associadas ao jornalismo, fornecendo um maior leque de analises´ sobre a informaçao˜ dispon´ıvel. Esta informaçao˜ encontra-se em constante crescimento, com dados a serem produzidos diariamente´ na Internet. O conceito de Big Data e´ actualmente uma realidade, sendo poss´ıvel processar grandes quantidades de informaçao˜ atraves´ de tecnicas´ especialmente desenhadas para esse proposito´ e do aumento da capacidade computacional dispon´ıvel. Um estudo poss´ıvel sobre grandes quantidades de dados consiste na analise´ da correlaçao˜ entre o numero´ de ocorrenciasˆ de entidades e eventos durante um determinado per´ıodo de tempo. Este tipo de estudo permite analisar tendenciasˆ de popularidade, observando quais os per´ıodos em que dadas entidades estiveram mais em foco, o que permite identificar casos de destaque de entidades, com poss´ıveis utilizaçoes˜ em areas´ como Marketing e estudos socio-politicos,´ entre outras.

1.1 Motivac¸ao˜

A popularidade de um tema pode ser estudada estatisticamente atraves´ da analise´ do numero´ de vezes que este e´ referido num espaço de tempo, sendo que quanto mais popular este for, maior sera´ o numero´ de vezes que e´ referenciado. A conjunçao˜ do numero´ de ocorrenciasˆ por data num per´ıodo de tempo e´ a base dos estudos de popularidade. Um estudo deste tipo permite identificar quando se realizaram eventos em que um tema tenha estado em destaque e quais os eventos em si. O principal desafio na realizaçao˜ de um estudo de popularidade e´ o calculo´ desta. Ao se utilizar um conjunto de dados textual, e´ poss´ıvel determinar a popularidade atraves´ da contagem de palavras. Porem,´ a contagem de palavras singulares e´ um metodo´ demasiadamente redutor, visto que descarta expressoes˜ mais complexas que envolvam mais que uma palavra. De modo a se conseguir formar conjuntos de palavras para analisar em termos de popularidade vai-se recorrer a N-Gramas.

1 Cap´ıtulo 1. Introduc¸ao˜ 2

O conceito de N-Gramas consiste num modelo de linguagem probabil´ıstico para a previsao˜ do proximo´ item numa sequenciaˆ na forma de uma cadeia de Markov (n-1). A utilizac¸ao˜ de N-Gramas e´ valida´ em diversos contextos, sendo a possibilidade de utilizar estes para o processamento de linguagem natural o de maior utilidade para o calculo´ de popularidade.

1.2 Objectivos

O objectivo principal desta tese sera´ o desenvolvimento de uma plataforma em que seja poss´ıvel analisar as flutuaçoes˜ do numero´ de ocorrenciasˆ de palavras-chave/conceitos ao longo de um per´ıodo de tempo contidas em grandes quantidades de informaçao,˜ em espec´ıfico em documentos noticiosos (analise´ de tendencias,ˆ por outras palavras). Para tal, a plataforma criada devera´ ter os seguintes componentes:

1. Back-End que transforme grandes conjuntos de conteudos´ textuais em N-Gramas e armazene estes numa base de dados/estrutura de dados

2. Camada intermediaria´ que permita um facil´ acesso aos N-Gramas e ao numero´ de ocorrenciasˆ destes ao longo de um per´ıodo de tempo

3. Interface para a pesquisa por N-Gramas que apresente os resultados de forma graﬁca´

O segundo objectivo sera´ a realizaçao˜ de uma analise´ aos algoritmos usados para a transformaçao˜ dos conteudos´ do corpus em N-Gramas, tanto ao n´ıvel de performance como em relaçao˜ a` consistenciaˆ e validez dos resultados produzidos.

1.3 Metodologia

O desenvolvimento de uma plataforma que alcance os objectivos propostos tera´ que recorrer a um conjunto de tecnologias e ferramentas que se adequem as` tarefas que se pretendem realizar. Para o Back-End proposto, dado que se vai trabalhar com grandes conjuntos de dados, ira´ ser implementado um cluster Hadoop de modo a distribuir o processamento de dados por varias´ maquinas.´ O acesso aos dados produzidos devera´ ser independente da interface utilizada, razao˜ pela qual o acesso a estes sera´ realizado atraves´ de serviços Web que utilizem a metodologia RESTful. Finalmente, a interface sera´ acess´ıvel atraves´ de um browser e tera´ dispon´ıvel um campo de pesquisa por N-Gramas, assim como opçoes˜ para a realizaçao˜ de pesquisas que incluam condicionantes (categoria da not´ıcia, tipo de entidade e classe gramatical). Cap´ıtulo 1. Introduçao˜ 3

1.4 Estrutura do documento

Este relatorio´ ira´ começar por identificar e descrever o trabalho que ja´ foi realizado sobre este topico´ que serviu de base para o trabalho desenvolvido nesta tese, nomeadamente a prospeçao˜ e analise´ de memes. Conclu´ıda esta fase, e´ discutida a arquitectura da soluçao˜ a implementar e, para cada camada da arquitectura, quais as tecnologias que que vao˜ servir como base para a implementaçao˜ da aplicaçao,˜ especificando quais as suas funcionalidades e em que parte da aplicaçao˜ estas serao˜ usadas. Os dois ultimos´ cap´ıtulos focam-se na descriçao˜ do trabalho que foi realizado, e numa discussao˜ sobre os resultados obtidos e o que se pode concluir acerca destes. Relativamente ao trabalho realizado, e´ descrita a implementaçao˜ dos actuais componentes da aplicaçao˜ de uma forma detalhada, realizando igualmente a forma como as tecnologias descritas no cap´ıtulo da metodologia foram usadas. No cap´ıtulo da analise,´ e´ avaliada a performance da soluçao˜ e a validez dos resultados produzidos por esta. O ultimo´ cap´ıtulo discute as conclusoes,˜ assim como as ideias e conceitos que poderiam ser usados para a expansao˜ do projecto desenvolvido. 1.5 Conclusoes˜ do cap´ıtulo

Neste cap´ıtulo foram analisados em maior detalhe os conceitos que vao˜ ser fundamentais para a implementac¸ao˜ do sistema. Sao˜ discutidos os objectivos propostos para a tese, a metodologia da soluc¸ao˜ a implementar e como o documento sera´ estruturado. Cap´ıtulo 2

Trabalho relacionado

A aplicac¸ao˜ que se pretende construir no contexto desta tese de mestrado inspira-se em trabalho ja´ existente referente a` analise de memes a partir de documentos de texto. As principais inspirac¸oes˜ que foram investigadas sao˜ descritas neste cap´ıtulo, com especial enfaseˆ no seu funcionamento.

2.1 Back-End

2.1.1 Finding and Exploring Memes in Social Media

O artigo [27] aplica os princ´ıpios de um algoritmo MapReduce para a construçao˜ de uma aplicaçao˜ que automaticamente descubra e realce memes existentes em artigos online. Pri- meiro e´ feito um pre-processamento´ para a extracçao˜ e normalizaçao˜ de conteudo´ textual, filtrando anuncios,´ tags HTML, documentos que nao˜ estejam em Ingles,ˆ e documentos curtos. O passo seguinte consiste em utilizar a tecnica´ MapReduce (recorrendo a` framework Apache Hadoop) para a identificaçao˜ de frases comuns que ocorrem em varios´ documentos. Estas frases sao˜ depois classificadas de forma a identificar quais as que sao˜ mais informativas para mostrar ao utilizador, sendo agrupadas por semelhança para a formaçao˜ de memes. Para consultar os memes foi constru´ıda uma pagina´ Web onde e´ poss´ıvel pesquisar por estes, com os resultados a serem representados numa linha temporal e o meme realçado no documento actual. Tambem´ e´ poss´ıvel ver outros documentos onde o meme esta´ presente, sejam da mesma fonte ou de outras fontes, assim como memes semelhantes.

2.1.2 MapReduce: Simpliﬁed Data Processing on Large Clusters

Outro exemplo da utilizaçao˜ do Hadoop numa situaçao˜ semelhante a` que se pretende implementar esta´ presente no artigo [7]. Neste e´ discutida uma soluçao˜ para a contagem de palavras de uma colecçao˜ de documentos atraves´ de uma implementaçao˜ de um algoritmo

5 Cap´ıtulo 2. Trabalho relacionado 6

Hadoop MapReduce.

Na implementaçao˜ da funçao˜ Map foi definido como parametroˆ um par chave/valor que representa o nome do documento e os conteudos´ deste, respectivamente. O metodo´ analisa os conteudos´ do documento, emitindo pares chave/valor em que a chave e´ uma palavra do documento e o valor e´ 1. O objectivo da funçao˜ Map e´ emitir todas as palavras do conjunto de documentos de forma a que se possa realizar a contagem na funçao˜ Reduce. Esta funçao˜ tem como parametroˆ um par chave/valor, em que a chave consiste numa palavra e o valor e´ uma lista das ocorrenciasˆ dessa palavra. Estes pares sao˜ os que foram gerados pela funçao˜ Map. Para a contabilizaçao˜ do numero´ de ocorrenciasˆ de uma palavra, a lista de ocorrenciasˆ associada a essa palavra e´ percorrida, somando-se os valores. Ao se ter o total de ocorrenciasˆ para a palavra, e´ emitido um par chave/valor com a palavra e o total de ocorrencias,ˆ respectivamente, para um documento de texto.

Esta soluçao˜ foi realizada para a contabilizaçao˜ de apenas palavras individuais, unigramas no contexto de N-Gramas, o que significa que esta implementaçao˜ e´ demasiadamente limitativa considerando o sistema a desenvolver.

2.1.3 Computing n-Gram Statistics in MapReduce

Este artigo [3] apresenta algumas soluçoes˜ para a computaçao˜ de N-Gramas atraves´ de algoritmos MapReduce. Sao˜ sugeridos quatro algoritmos, tresˆ de outros autores e um original. O primeiro e´ chamado de contagem ingenua´ e e´ igual ao descrito anteriormente no artigo [7]. Os outros dois metodos´ sao˜ chamados metodos´ a priori, sendo o primeiro a analise´ a priori e o segundo a indexaçao˜ a priori. A analise´ a priori consiste na realizaçao˜ de analises´ ao input N vezes, em que N representa o numero´ maximo´ de N-Gramas que se pretende obter. Em cada iteraçao˜ K, o metodo´ determina os K-Gramas presentes no conjunto de documentos dado como input, considerando apenas os que ocorrem mais que o numero´ m´ınimo de vezes. A verificaçao˜ de que os K-Gramas ocorrem mais que o numero´ m´ınimo de vezes e´ feita na funçao˜ Re- duce. No final da iteraçao˜ e´ analisado o output da iteraçao˜ anterior, visto que apenas vao˜ ser considerados os K-Gramas em que os (K-1)-Gramas que os constituem ocorrem mais vezes do que o numero´ m´ınimo necessario,´ sendo esta verificaçao˜ realizada na funçao˜ Map. O metodo´ termina assim que sao˜ feitas as N iteraçoes˜ ou uma iteraçao˜ nao˜ produz output. O outro metodo´ e´ a indexaçao˜ a priori, em que e´ constru´ıdo incrementalmente um ´ındice invertido de N-Gramas frequentes a partir de um conjunto de documentos que e´ percorrido atraves´ de um ciclo. Este metodo´ utiliza duas funçoes˜ Map e Reduce. As primeiras funçoes˜ Map e Reduce correspondem a` primeira fase da indexaçao,˜ em que e´ constru´ıdo o ´ındice invertido com informaçao˜ posicional para todos os N-Gramas frequentes ate´ ao Cap´ıtulo 2. Trabalho relacionado 7 tamanho K. As segundas funçoes˜ Map e Reduce correspondem a` segunda fase do metodo,´ em que sao˜ identificados os N-Gramas frequentes que ultrapassam o tamanho K atraves´ da analise´ do output da iteraçao˜ anterior. Estes tresˆ metodos´ apresentam problemas, nomeadamente o numero´ de leituras que temˆ de ser realizadas e a quantidade de memoria´ necessaria´ para a grandes necessidades de memoria.´ De forma a resolver os problemas dos restantes metodos,´ tem-se a soluçao˜ desenvolvida pelos autores do artigo, Klaus Berberich e Srikanta Bedathur, chamada Suffix-sigma. Esta consiste na utilizaçao˜ de sufixos de modo a evitar a emissao˜ de demasiados pares key/value. Para se determinar a frequenciaˆ de um N-Grama vai ser necessario´ determinar quan- tos dos sufixos emitidos temˆ o N-Grama como prefixo. Consideremos como exemplo o N- Grama ”bax”. Este subsume os N-Gramas ”ba”e ”b”, o que significa que so´ e´ necessario´ emitir ”bax”visto que ”ba”e ”b”podem ser obtidos a partir deste. Esta soluçao˜ tem como vantagem principal a menor quantidade de leituras e escritas efectuadas, situaçao˜ que vai resultar numa melhoria de performance.

2.2 Interface

2.2.1 Google NGram Viewer

A maior inspiraçao˜ deste projecto e´ o Google Ngram Viewer [14], uma aplicaçao˜ popular que apresenta uma simples interface com uma caixa de texto para a inserçao˜ de termos a pesquisar, outras duas em que se pode definir o intervalo de tempo em que se pretende pesquisar, e duas opçoes˜ de filtragem, uma para se definir qual a linguagem em que se vai pesquisar e outra para definir a escala temporal do grafo apresentado.

Figura 2.1: Google Ngram Viewer

Para a realizaçao˜ de pesquisas basta colocar os termos a pesquisar na caixa de texto, Cap´ıtulo 2. Trabalho relacionado 8 com v´ırgulas a separar cada termo independente, e seleccionar o botao˜ ”Search lots of books”. O resultado e´ apresentado num grafico,´ com linhas de cores diferentes para cada termo, em que o eixo das abcissas corresponde ao intervalo de tempo definido e o eixo das ordenadas corresponde a` percentagem de ocorrenciasˆ dos N-Gramas no corpus de todos os livros presentes na base de dados do Google. A principal funçao˜ desta aplicaçao˜ e´ a analise´ das tendenciasˆ dos termos pesquisados, tal como a aplicaçao˜ que se pretende construir nesta tese. A aplicaçao˜ tem como base os N-Gramas gerados a partir das palavras presentes em cerca de 20 milhoes˜ de livros.

2.2.2 MemeTracker

Uma outra aplicac¸ao˜ ja´ existente para a analise´ de tendenciasˆ de memes e´ o MemeTracker [22], cuja interface se encontra ilustrada na Figura 2.2.

Figura 2.2: MemeTracker

Esta aplicaçao˜ constroi mapas do ciclo de not´ıcias provenientes de cerca de um milhao˜ de fontes, desde blogs pessoais a fontes jornal´ısticas. A implementaçao˜ deste sistema recorreu a algo que a que os autores chamam de ”clusters de frases”, em que cada frase e´ re- presentada por um no,´ estando as suas arestas ligadas a nos´ contendo frases semelhantes. As unidades de analise´ consideradas apresentam algumas semelhanças com N-Gramas, especialmente na definiçao˜ de um limite para o numero´ de palavras que constituem uma frase, o equivalente ao N maximo´ para os N-Gramas. A representaçao˜ visual dos memes e´ feita atraves´ de um stacked plot, em que a largura de cada faixa representa o volume de not´ıcias ao longo do tempo. Cap´ıtulo 2. Trabalho relacionado 9

2.3 Conclusoes˜ do cap´ıtulo

O foco deste cap´ıtulo foi apresentar alguns dos trabalhos ja´ existentes que estivessem relacionados com o sistema que se pretende implementar. Em primeiro lugar foi analisado o NGram Viewer do Google, visto ser o que mais se assemelha a` aplicaçao˜ que eu pretendo desenvolver, especialmente em relaçao˜ a` utilizaçao˜ de N-Gramas. O Meme- Tracker foi outra aplicaçao˜ estudada, com o interesse a recair em especial no processo de construçao˜ de agregados de frases a partir das fontes de informaçao˜ que e´ bastante semelhante a` utilizaçao˜ de N-Gramas. No artigo [27] e´ analisada a forma como o modelo de programaçao˜ MapReduce e´ usado para a identificaçao˜ de frases comuns, assim como a maneira como estas frases sao˜ agrupadas de forma a serem consideradas como memes. Finalmente, e´ estudado o artigo [7] onde e´ feita uma analise´ de como se podem com- putar estat´ısticas de N-Gramas atraves´ de uma implementaçao˜ espec´ıfica do MapReduce chamada de Suffix-sigma.

Cap´ıtulo 3

Analise´

De forma a avanc¸ar com o desenvolvimento da plataforma, e´ necessario´ determinar qual a arquitectura a aplicar, qual o objectivo de cada componente da arquitectura e quais as tecnologias e ferramentas necessarias´ para o concretizar da implementac¸ao.˜ Estes temas sao˜ discutidos neste cap´ıtulo.

3.1 Arquitectura

A plataforma a desenvolver vai ser desenhada com base numa arquitectura cliente-servidor de tresˆ camadas. Cada camada tem um proposito´ espec´ıﬁco, descrito de seguida:

• Camada de dados: Camada onde a informac¸ao˜ e´ armazenada e acedida a partir de uma base de dados ou estrutura de dados.

• Camada logica:´ Esta camada e´ responsavel´ pela logica´ da aplicaçao,˜ processando pedidos e comandos dos clientes, decisoes˜ logicas,´ avaliaçoes˜ e calculos.´ Para alem´ da logica,´ esta tambem´ e´ responsavel´ pela comunicaçao˜ entre a camada de dados e a camada de apresentaçao.˜

• Camada de apresentaçao:˜ Interface para a interacçao˜ com os utilizadores. A principal funçao˜ da interface vai ser a traduçao˜ de funcionalidades e dados em resultados de facil´ compreensao.˜

Dada a natureza Web da plataforma, a arquitectura da soluc¸ao˜ e:´

11 Cap´ıtulo 3. Analise´ 12

Figura 3.1: Arquitectura da plataforma

Cada uma das camadas e´ descrita em maior detalhe nos cap´ıtulos seguintes.

3.1.1 Camada de Dados

A camada de dados, denominada de Back-End daqui a diante, e´ onde o corpus jornal´ısticos e´ transformado em N-Gramas, seguindo-se o calculo´ estat´ıstico do numero´ de Cap´ıtulo 3. Analise´ 13 ocorrenciasˆ dos N-Gramas para o per´ıodo de tempo do corpus e finalmente o armazenamento dos dados numa estrutura de dados. O desenvolvimento do Back-End recorreu a quatro tecnologias/ferramentas chave. Para a transformaçao˜ de textos em N-Gramas foi usado o LingPipe [1], uma biblioteca para o processamento de texto usando linguisticas computacionais. Usando esta biblioteca com o regex da Linguateca, foi constru´ıdo um tokenizador para a transformaçao˜ dos conteudos´ textuais em N-Gramas. De modo a que o sistema seja capaz de processar o corpus fornecido, recorri ao Apache Hadoop [11], uma framework para a construçao˜ de um cluster de maquinas´ para o processamento distribu´ıdo de grandes quantidades de dados usando o modelo de programaçao˜ MapReduce. Este modelo de programaçao˜ baseia-se em duas funçoes,˜ Map e Reduce. A funçao˜ Map leˆ o ficheiro de corpus, filtrando e ordenando os conteudos´ para que estes sejam processados em menores quantidades nos diversos nos´ do cluster. A funçao˜ Reduce transforma os conteudos´ em N-Gramas e calcula as estat´ısticas do numero´ de ocorrenciasˆ por mes.ˆ Para alem´ do Hadoop, foi tambem´ utilizado o Apache Lucene [12], uma biblioteca de alta performance para a pesquisa de texto escrita em Java. No contexto da plataforma, esta foi usada para a construçao˜ de um tokenizador de texto que vai separar o corpus em N-Gramas, desde unigramas ate´ N-Gramas (em que N e´ o valor maximo´ definido pelo utilizador). Foi criado um ´ındice onde cada entrada consiste num N-Grama, o URL da not´ıcia associada e a data desta (apenas o mesˆ e o ano). Este ´ındice e´ usado como suporte para as pesquisas, permitindo que o utilizador aceda as` not´ıcias que contem´ os N-Gramas pesquisados. Finalmente, para o armazenamento de dados recorri a` biblioteca MapDB [21] usada para a construçao˜ de estruturas de dados do tipo HashMap e TreeMap armazenaveis´ em disco. A estrutura de dados usada para o armazenamento dos N-Gramas foi o HashMap, em que a chave representa o N-Grama e o valor associado a este e´ um vector de inteiros em que cada posiçao˜ corresponde ao numero´ de ocorrenciasˆ de cada mesˆ do per´ıodo de tempo definido.

3.1.2 Camada Logica´

A camada logica´ e´ responsavel´ pela interacçao˜ entre a camada de dados e a camada de apresentaçao.˜ Dado que a plataforma e´ de natureza Web, decidi implementar um conjunto de Web Services RESTful associados a um leque de operaçoes˜ dispon´ıveis para o utilizador. Para a implementaçao˜ dos Web Services utilizei a biblioteca Jersey [19]. A escolha desta biblioteca deveu-se ao facto de esta simplificar o processo de criaçao˜ de Web Services em Java, nomeadamente ao n´ıvel da definiçao˜ dos metodos´ Java que estarao˜ associados aos pedidos HTTP e aos URIs usados para a distinçao˜ dos metodos,´ assim como a inclusao˜ de argumentos. Igualmente importante foi o facto de esta API facilitar o retorno Cap´ıtulo 3. Analise´ 14 de dados em formato JSON, que e´ usado nas respostas das queries realizadas.

3.1.3 Camada de Apresentac¸ao˜

O Front-End tem duas componentes distintas. A primeira consiste numa interface Web a partir da qual o utilizador vai realizar pesquisas por N-Gramas, enquanto a segunda e´ uma GUI Java usada para a realizaçao˜ de operaçoes˜ administrativas sobre a plataforma. Para a interface Web, criei uma pagina´ Web atraves´ do JSP (JavaServer Pages). Esta tecnologia e´ usada para a criaçao˜ de paginas´ Web, permitindo a utilizaçao˜ de codigo´ Java no contexto da pagina´ (para a geraçao˜ de conteudos´ dinamicamente,ˆ por exemplo). A razao˜ pela qual escolhi esta tecnologia deveu-se a` facilidade em interligar a interface com os serviços Web desenvolvidos num unico´ ficheiro WAR que pode depois ser carregado e acedido atraves´ de um servidor Tomcat. Tal como foi referido no cap´ıtulo anterior, o output dos pedidos de dados ao Web Service retorna a informaçao˜ no formato JSON. Apesar de este poder ser lido pelos utilizadores, de modo a que a interpretaçao˜ dos resultados fosse mais atractiva e simples, usei a biblioteca JavaScript Google Chart Tools [13] para representar os resultados atraves´ de histogramas. A realizaçao˜ de pesquisas por N-Gramas nao˜ deve implicar o recarregamento da pagina,´ apenas a realizaçao˜ de um novo pedido ao Web Service e o recarregamento do grafico´ de maneira a que este apresente os novos dados. Para que tal fosse poss´ıvel, recorri a` metodologia AJAX (Asynchronous JavaScript and XML). Esta metodologia implica a utilizçao˜ de funçoes˜ Javascript para o envio e recepçao˜ de dados assincronamente sem que haja uma interferenciaˆ com a pagina´ em disposiçao.˜ A metodologia foi usada para a realizaçao˜ de pesquisas de N-Gramas e o retorno dos dados estat´ısticos respectivos. Para alem´ da interface de pesquisa, criei igualmente uma interface administrativa. O objectivo principal desta componente consiste no upload de ficheiros corpus e na transformaçao˜ destes em N-Gramas. Para o comunicaçao˜ com o servidor recorri ao Jsch (Java Secure Channel), uma API Java usada para a realizaçao˜ de comunicaçoes˜ usando o protocolo SSH2. Esta biblioteca possibilita o envio de ficheiros de texto de corpus para o servidor e que estes sejam devidamente processados e integrados nas estruturas de dados existentes.

3.2 Conlusoes˜ do cap´ıtulo

Neste cap´ıtulo abordei as soluçoes˜ arquitecturais e tecnologicas´ escolhidas para responder aos desafios de implementaçao.˜ A camada de dados e´ a primeira componente em foco, com enfaseˆ na rede de nos´ Hadoop responsavel´ pela transformaçao˜ de ficheiros de corpus em N-Gramas e na contagem do numero´ de ocorrenciasˆ destes para cada mesˆ dos per´ıodo de tempo definido. Tambem´ no contexto desta camada e´ discutido o armazenamento dos N-Gramas gerados e do numero´ de ocorrenciasˆ para cada mes.ˆ Cap´ıtulo 3. Analise´ 15

O acesso aos dados gerados atraves´ de Web Services e´ descrito de seguida, na camada logica,´ onde e´ discutida a soluçao˜ tecnica´ para a implementaçao˜ dos serviços RESTful. Finalmente, sao˜ discutidas as interfaces disponibilizadas pelo sistema e quais as tecnologias necessarias´ para a construçao˜ destas. Cap´ıtulo 3. Analise´ 16 Cap´ıtulo 4

Implementac¸ao˜

Neste cap´ıtulo e´ discutida a implementaçao˜ do sistema em detalhe, começando pelo Back- End, responsavel´ pela transformaçao˜ da informaçao˜ em N-Gramas presentes em estruturas de dados de uma maneira distribu´ıda. De seguida e´ explicada a forma como os dados sao˜ acedidos recorrendo a serviços Web e quais os serviços que estao˜ dispon´ıveis para o utilizador, desde a simples obtençao˜ de N-Gramas e as suas ocorrencias,ˆ a possibilidade de fazer o download de um ficheiro CSV que contem´ a informaçao˜ pesqui- sada e a disponibilizaçao˜ das ligaçoes˜ (URLs) para os artigos a partir dos quais os N- Gramas foram gerados. Finalmente e´ discutido o Front-End, que permite a interaçao˜ do utilizador com a informaçao˜ de uma maneira acess´ıvel, sendo igualmente referenci- ada a ferramenta administrativa que permite o processamento de corpus jornal´ısticos e a construçao/actualizaç˜ ao˜ das estruturas de dados.

4.1 Back-End

A criacçao˜ dos meios de pesquisa e´ o primeiro passo na implementaçao˜ do sistema, em que o acto de transformar simples informaçao˜ textual num conjunto de dados pesquisavel´ e´ poss´ıvel recorrendo a` utilizaçao˜ dos sistemas descritos neste cap´ıtulo. Para a execuçao˜ de todos estes sistemas foi criado um ficheiro .jar executavel´ responsavel´ pela execuçao˜ ordenada destes, que e´ invocado atraves´ do cliente administrativo (ver 4.3.2), denominado de RunAllHadoopAlgorithms.jar.

4.1.1 Configuraçao/Inicializaç˜ ao˜

A fase de configuraçao˜ esta´ dividida em duas partes, a primeira sendo realizada antes do processamento do corpus atraves´ dos algoritmos MapReduce e a segunda a ser feita apos´ o processamento dos algoritmos, antes da criaçao˜ das estruturas de dados. Antes do processamento da informaçao,˜ e´ necessario´ configurar o sistema de acordo com os devidos parametros.ˆ A configuraçao˜ e´ feita recorrendo a ficheiros XML que contem´ a

17 Cap´ıtulo 4. Implementaçao˜ 18 informaçao˜ necessaria´ para o funcionamento do programa, desde os caminhos para o funcionamento do MapReduce ate´ ao per´ıodo de tempo presente nas estruturas de dados. No total, existem cinco ficheiros de configuraçao˜ que sao˜ necessarios´ para o funcionamento do sistema; o ficheiro config.xml engloba as configuraçoes˜ gerais para todo o sistema, com os restantes a conterem as configuraçoes˜ espec´ıficas de cada implementaçao˜ do algoritmo MapReduce. A informaçao˜ presente no primeiro ficheiro consiste em tags do seguinte tipo:

• Dados de configuraçao˜ do HDFS: A informaçao˜ presente nesta tag consiste no URL do HFDS (no meu caso, hdfs://reactionvm04:54310/) que vai ser usado para o acesso ao sistema de ficheiros, a pasta no HDFS onde os ficheiros a processar sao˜ armazenados, a pasta onde os ficheiros sao˜ armazenados apos´ o upload dos ficheiros a processar atraves´ do cliente admin e o caminho para a execuçao˜ de ficheiros .jar usando o Hadoop.

• Dados de configuraçao˜ para os processos MapReduce: Nestas tags estao˜ presentes as informaçoes˜ referentes aos algoritmos MapReduce para o tratamento de dados para as estruturas de pesquisa, começando pela pasta onde se encontra o ficheiro .jar, a pasta no HDFS onde estao˜ os ficheiros a processar, a pasta no HDFS onde os resultados do MapReduce vao˜ ficar, o caminho para o ficheiro que vai conter os resultados ordenados, o caminho para o ficheiro da base de dados MapDB, o caminho para o ficheiro que contem´ a estrutura TreeMap, a pasta onde os ficheiros de log vao˜ ser armazenados e, no caso da tag para a estrutura principal, o caminho para o a pasta onde os ficheiros CSV vao˜ estar disponiveis para download.

• Dados de configuraçao˜ do per´ıodo de tempo: Esta tag mantem´ as datas inicial e final do per´ıodo de tempo, que sao˜ usadas para se determinar o per´ıodo de tempo no array com as ocorrencias.ˆ

• Dados de conﬁgurac¸ao˜ do ´ındice Lucene: Presente nesta tag encontra-se o caminho onde o ´ındice Lucene vai estar armazenado.

• Dados de configuraçao˜ da aplicaçao˜ de administraçao:˜ Igualmente neste ficheiro esta´ a informaçao˜ usada no cliente de administraçao,˜ presente nesta tag. A informaçao˜ necessaria´ para o funcionamento do cliente consiste no nome do utilizador (no meu caso hadoopuser), no hostname da maquina´ onde o sistema se encontra instalado, na password associada ao utilizador e no caminho para a pasta onde os ficheiros a ser processados sao˜ armazenados apos´ o seu upload.

Os conteudos´ do ficheiro sao˜ exemplificados de seguida, de acordo com o que foi agora descrito: Cap´ıtulo 4. Implementaçao˜ 19

hdfs://reactionvm04:54310/ hdfs://reactionvm04:54310/srv/hadoopuser/textfiles/ /srv/hadoopuser/uploads/ /srv/hadoopuser/hadoop/bin/hadoop jar /srv/hadoopuser/hadoop/NGramMapReduceBuilderServer.jar /srv/hadoopuser/textfiles /srv/hadoopuser/output /srv/hadoopuser/text-temp/sortedOutput.txt /srv/hadoopuser/mapDBAux/ngrams_db /srv/hadoopuser/mapDBAux/ngrams /srv/hadoopuser/ngramcount_logs/ /srv/hadoopuser/csvFiles/ . . .

Os restantes ficheiros de configuraçao˜ contem´ as seguintes informaçoes:˜ • Dados de configuraçao˜ do HDFS: A informaçao˜ presente nesta tag consiste no URL do HFDS (no meu caso, hdfs://reactionvm04:54310/) que vai ser usado para o acesso ao sistema de ficheiros, a quantidade de RAM dispon´ıvel para as tarefas Map, a quantidade de RAM dispon´ıvel para as tarefas Reduce, o numero´ definido de tarefas Map e o numero´ definido de tarefas Reduce. Igualmente, o ficheiro contem´ a pasta onde os ficheiros de log vao˜ ser armazenados, o caminho no HDFS que indica a pasta onde estao˜ os ficheiros produzidos pelo MapReduce estao,˜ o caminho no HDFS que indica o ficheiro que vai conter os resultados combinados do processo MapReduce (chamado de merged file) e o caminho no sistema de ficheiros local para onde se vai copiar este ultimo´ ficheiro.

• Dados de configuraçao˜ para a ordenaçao˜ dos ficheiros: Presente nesta tag esta´ toda a Cap´ıtulo 4. Implementaçao˜ 20

informaçao˜ necessaria´ para a realizaçao˜ da ordenaçao˜ do ficheiro com os N-Gramas produzidos pelo algoritmo. A informaçao˜ presente nesta tag consiste no ficheiro a ordenar (chamado de merged file), a pasta onde se vai realizar a ordenaçao˜ e o ficheiro ordenado resultante.

Como exemplo de um destes ficheiros de configuraçao,˜ sao˜ apresentados os conteudos´ do ficheiro associado a` criaçao˜ da principal estrutura de dados: hdfs://reactionvm04:54310/ -Xmx4096m -Xmx4096m 4 4 /srv/hadoopuser/ngramcount_logs/ hdfs://reactionvm04:54310/srv/hadoopuser/output/ hdfs://reactionvm04:54310/srv/hadoopuser/output/merged_file /srv/hadoopuser/text-temp/ /srv/hadoopuser/text-temp/merged_file /srv/hadoopuser/external-sort-temp/ /srv/hadoopuser/text-temp/sortedOutput.txt

Ao se ter os valores de configuraçao˜ presentes em ficheiros de configuraçao˜ o sistema torna-se mais flex´ıvel, pois nao˜ depende de valores fixos e logo nao˜ funciona apenas no actual servidor.

Para alem´ da obtençao˜ dos valores que configuram o sistema, a fase de configuraçao˜ e´ igualmente responsavel´ pela inicializaçao˜ dos algoritmos MapReduce. Estes algoritmos estao˜ dispon´ıveis atraves´ de ficheiros .jar que sao˜ executados atraves´ da framework Ha- doop, com a descriçao˜ do funcionamento destes a ser feita na secçao˜ seguinte. A execuçao˜ dos algoritmos e´ feita atraves´ de processos que sao˜ executados a partir da classe principal do ficheiro RunAllHadoopAlgorithms.jar que, como foi referido acima, e´ Cap´ıtulo 4. Implementaçao˜ 21 responsavel´ pela construçao˜ do Back-End da aplicaçao.˜ No total e´ necessaria´ a execuçao˜ de quatro processsos, dada a existenciaˆ de quatro algoritmos MapReduce para o processamento de dados, em que cada processo vai consistir na execuçao˜ dos ficheiros .jar que representam os algoritmos. Visto que o funcionamento do MapReduce baseia-se na execuçao˜ de ficheiros .jar com os algortimos usando a shell da framework Hadoop, nao˜ havia maneira de simplesmente usar o codigo´ dos algoritmos directamente na classe, dai a necessidade de recorrer a` utilizaçao˜ de processos que consistem na utilizaçao˜ da classe Runtime que vai permitir que a aplicaçao˜ interacta directamente com o ambiente em que esta esta´ a correr, neste caso o ambiente Linux. A execuçao˜ de cada processo vai necessitar da localizaçao˜ da pasta onde o Hadoop esta´ instalado no servidor de maneira a aceder a` sua shell e para que seja poss´ıvel a execuçao˜ do algoritmo, a localizaçao˜ do ficheiro .jar com o algoritmo, o caminho no HDFS onde os corpus estao˜ armazenados e o caminho no HDFS onde o resultado do algoritmo vai ficar. Cada processo corre independentemente de maneira a que nao˜ haja o risco de ocorrem erros de excesso de memoria,´ visto que alguns dos algoritmos necessitam de utilizar a cache distribu´ıda para os modelos usados nos algoritmos para a classificaçao˜ de entidades e para a classificaçao˜ gramatical das palavras. Apos´ o processamento do corpus e´ necessario´ determinar qual o per´ıodo de tempo do corpus e se e´ necessario´ expandir o per´ıodo de tempo do recorrendo aos valores presentes no ficheiro de configuraçao˜ config.xml, vao˜ se comparar estes aos presentes no corpus, começando pela data final. Caso esta seja maior que o valor presente no ficheiro XML, ao n´ıvel do ano, vai ser feita uma actualizaçao˜ no ficheiro com o novo valor. No caso da data inicial do corpus, novamente ao n´ıvel do ano, ser menor que o valor presente no ficheiro XML ou caso este seja igual a zero, para alem´ de substituir no ficheiro XML o valor do ano inicial, vai se determinar a posiçao˜ a partir da qual se vao˜ incrementar os valores presentes nas estruturas de dados caso sejam feitas actualizaçoes.˜

4.1.2 Tokenizador

O processo de transformaçao˜ dos conteudos´ textuais em N-Gramas recorre a um tokenizador. Dadas as particularidades da l´ıngua portuguesa, o tokenizador vai necessitar de um padrao˜ especialmente desenhado para esta e que considere os seus casos espec´ıficos, como por exemplo palavras com hifens, acentuaçao˜ e com cesˆ de cedilha. Para alem´ dos casos espec´ıficos, tambem´ e´ necessario´ considerar outros casos, como por exemplo sites Web ou endereços de email. O padrao˜ completo aborda os seguintes casos:

• Tempo (12:32:05, por exemplo)

• Numero´ ordinais

• Numeros´ Cap´ıtulo 4. Implementac¸ao˜ 22

• Palavras com h´ıfens

• Palavras com plicas

• Emails

• Ordinais

• URLs

• URLs simpliﬁcados

• Unicode

• Nomes de ﬁcheiros

• Palavras

• Pontuac¸ao˜

• Numero´

Usando a biblioteca LingPipe [1], a classe RegExTokenizerFactory e´ extendida de maneira a criar uma classe costumizada para o tokenizador. Este passo nao˜ e´ absolutamente necessario,´ visto que a utilizaçao˜ da classe RegExTokenizerFactory e´ valida,´ sendo esta escolha mais estilistica do que funcional, com os metodos´ da classe que foram reescritos a consistirem na invocaçao˜ dos metodos´ da classe extendida, sem a realizaçao˜ de alteraçoes˜ substanciais.

4.1.3 MapReduce

O Hadoop MapReduce foi a framework escolhida para o processamento do corpus de not´ıcias do Publico´ visto tratar-se de uma biblioteca desenhada para o suporte de aplicaçoes˜ distribu´ıdas data-intensive/ para grandes conjuntos de dados/Big Data. Nesta tese foco- me na utilizaçao˜ do Hadoop para o processamento de texto, visto que o conjunto de dados com que trabalhei esta´ nesse formato, tendo o artigo/livro [24] como a principal referencia.ˆ O algoritmo MapReduce baseia-se em duas funçoes,˜ Map e Reduce. Segundo [24, p. 22], os conjuntos key/value forma a principal estrutura de dados do MapReduce, com cada um a ser um valor primitivo (inteiros, strings, etc) ou uma estrutura complexa (listas, tuplos, arrays, etc), cabendo ao programador escolher o que lhe mais convem.´ Parte do design de algoritmos MapReduce envolve a implementaçao˜ da estrutura key/value sobre o conjunto de dados que se vai usar como input. A outra parte consiste no programador em definir as funçoes˜ Map e Reduce, usando as seguintes assinaturas: Cap´ıtulo 4. Implementaçao˜ 23

• map: (c1, v1) → [(c2, v2)] (c1 = nome do documento, v1 = conteudo´ do documento, c2 = key 2/chave intermedia,´ v2 = value 2/ valor intermedio)´

• reduce: (c2, [v2]) → [(c3, v3)] (c2 = key 2/chave intermedia,´ v2 = value 2/valor intermedio,´ c3 = key 3/chave ﬁnal, v3 = value 3/valor ﬁnal)

O input de um job MapReduce esta´ presente numa pasta do sistema de ficheiros do Hadoop (HDFS), com o Map a ser aplicado a todo os pares key/value dados como input de forma a gerar um numero´ arbitrario´ de pares key/value intermedios.´ O Reduce e´ depois aplicado a todos os valores associados com a mesma chave intermedia´ de forma a gerar os pares key/value finais. A implementaçao˜ de cada funçao˜ para cada algoritmo e´ descrita nos cap´ıtulos que se seguem.

4.1.4 Algoritmo Principal

A principal funcionalidade disponibilizada pelo sistema e´ a pesquisa por N-Gramas e a obtençao˜ das suas respectivas ocorrenciasˆ ao longo do per´ıodo de tempo presente no ficheiro corpus definido. Para tal, foi constru´ıdo um algoritmo MapReduce que vai transformar os conteudos´ jornal´ısticos presentes no corpus num ficheiro que contem´ as estat´ısticas necessarias´ para a construçao˜ da estrutura de pesquisa.

Map

Para a implementaçao˜ do algoritmo MapReduce programaticamente usando a linguagem Java vao˜ ser criadas duas classes que representam as duas fases do algoritmo. A classe Map [24, p. 37] contemˆ o codigo´ referente a` primeira fase do algoritmo e vai extender a classe Mapper ([17]) que contem´ quatro parametrosˆ de tipo (type parameters) que representam as chaves e os valores associados a` funçao˜ Map, com os dois primeiros parametrosˆ a corresponderem ao input da funçao˜ e os dois ultimos´ a corresponderem ao seu output.O primeiro parametroˆ (LongWritter) representa os identificadores dos documentos recebi- dos como input da funçao˜ presentes no HDFS e o segundo parametroˆ (Text) corresponde aos conteudos´ desses documentos, consistindo no primeiro par key/value do algoritmo MapReduce. O segundo par vai corresponder aos valores intermedios´ produzidos pela funçao˜ Map, em que o terceiro parametroˆ da classe (Text) vai representar o agregado do ano e do mesˆ da data de cada artigo e o quarto e ultimo´ parametroˆ (Text) representa os conteudos´ textuais das not´ıcias (t´ıtulo ou conteudo).´ Tendo definido a classe, e´ necessario´ definir a funçao˜ Map dentro da classe que vai ser responsavel´ pelo actual funcionamento da fase de mapeamento. Tendo em conta a forma como a classe esta´ definida ao n´ıvel de parametrosˆ de tipo, os dois primeiros argumentos da funçao˜ vao˜ ser do tipo LongWritable e Text respectivamente, tendo os seus propositos´ Cap´ıtulo 4. Implementaçao˜ 24 sido discutidos acima. Em relaçao˜ ao segundo argumento, este consiste em linhas individuais desses ficheiros, e nao˜ todo o seu conteudo´ de uma vez. O terceiro argumento e´ do tipo Context e representa o contexto do funcionamento do algoritmo, permitindo a interaçao˜ com o HDFS e consequentemente a escrita das chaves e dos valores intermedios´ desta fase neste. Para o bom funcionamento do algoritmo, a informaçao˜ presente no corpus fornecido tem que ter o seguinte formato para cada linha do ficheiro: Categoria \tab Data \tab URL \tab T´ıtulo \tab Conteudo.´ Dado este facto, o primeiro passo na funçao˜ vai consistir numa simples verificaçao˜ de que o conteudo´ fornecido obedece ao formato descrito acima no sentido de terem de existir cinco elementos para cada linha, evitando assim o processamento de not´ıcias incompletas. Caso a linha recebida nao˜ falhe a verificaçao,˜ o campo que contem´ a data vai ser transformado numa versao˜ simplificada que contem´ apenas o mesˆ e o ano que vai ser usada como a chave dos pares intermedios´ (e.x.: 2006 08). Ao separar os conteudos´ jornal´ısticos desta maneira vai ser poss´ıvel fazer a contagem dos N-Gramas para cada mesˆ do per´ıodo de tempo dado e mais dificilmente ocorrem erros de excesso de memoria´ quando se acede aos pares intermedios´ na fase de reduçao.˜ Tendo transformado a data, o passo seguinte consiste na obtençao˜ dos conteudos´ jornal´ısticos a transformar em N-Gramas, o t´ıtulo e o conteudo´ da not´ıcia, presentes na linha do documento lida. Apos´ a sua obtençao,˜ vao˜ ser escritos dois pares chave/valor intermedios´ no HDFS, as chaves sendo a versao˜ simplificada da data descrita anteriormente e os valores sendo o t´ıtulo e o conteudo´ da not´ıcia. Em conclusao,˜ a fase de mapeamento serve como uma forma de organizar a informaçao˜ a processar atraves´ do mesˆ e ano associados aos conteudos´ jornal´ısticos de forma a facilitar o processo de contagem dos N-Gramas produzidos na fase de reduçao.˜ A implementaçao˜ da funçao˜ Map encontra-se em anexo.

Reduce

Apos´ a distribuiçao˜ categorizada dos dados na fase de mapeamento, vai ser necessario´ transformar a informaçao˜ em N-Gramas e fazer a respectiva contagem destes na fase de reduçao.˜ Semelhante a` implementaçao˜ da fase de mapeamento, foi criada uma classe denominada Reduce [24, p. 37] que extende a classe Reducer ([18]) e que contem´ a implementaçao˜ da funçao˜ reduce. Tal como a classe Mapper, a classe Reducer contem´ quatro tipos genericos´ em que os dois primeiros representam os tipos das chaves e dos valores intermedios´ emitidos na fase de mapeamento e os dois ultimos´ representam os tipos das chaves e dos valores finais produzidos pela fase de reduçao.˜ Dado que os dois primeiros tipos sao˜ correspondem aos tipos das chaves e dos valores emitidos pela funçao˜ map, estes temˆ que ser iguais aos definidos na classe Map definida acima, o que significa que ambos sao˜ do tipo Text. Os dois ultimos´ tipos vao˜ igualmente ser do tipo Text, em que a chave produzida vai corresponder aos N-Gramas produzidos e o valor vai consistir Cap´ıtulo 4. Implementaçao˜ 25 na combinaçao˜ da data simplificada produzida como chave na fase de mapeamento e o numero´ de ocorrenciasˆ do respectivo N-Grama. Um exemplo do output produzido e:´ Ca- vaco Silva \tab 2006 12 \tab 47. Tendo definido a classe, e´ necessario´ definir a funçao˜ Reduce. Tal como na classe Map, os dois primeiros argumentos da funçao˜ vao˜ corresponder aos dois primeiros tipos genericos´ da classe, o primeiro sendo do tipo Text e correspondendo a` versao˜ simplificada da data usada como chave intermedia.´ O segundo argumento consiste numa estrutura iteravel´ que contem´ os dados jornal´ısticos das not´ıcias que foram emitidos na fase de mapeamento (t´ıtulos e conteudos).´ O terceiro argumento e´ do tipo Context e representa o contexto do funcionamento do algoritmo, permitindo a interaçao˜ com o HDFS e consequentemente a escrita do output do algoritmo MapReduce neste. Para a realizaçao˜ da contagem do numero´ de ocorrenciasˆ vai-se recorrer a uma estrutura HashMap que vai armazenar pares chave/valor, em que a chave consiste no N-Grama e o valor consiste no numero´ de ocorrenciasˆ deste na data definida. Começando pela iteraçao˜ dos conteudos´ jornal´ısticos, o tokenizador vai ser aplicado a cada um destes de maneira a criar os N-Gramas, que podem depois ser acedidos atraves´ do iterador do tokenizador. Cada elemento no iterador vai ser sujeito a dois tratamentos, de maneira a evitar a inclusao˜ de N-Gramas que nao˜ sejam validos.´ O primeiro tratamento consiste na remoçao˜ de N-Gramas que nao˜ fazem sentido lexical, mais concretamente N-Gramas que consistam em sequenciasˆ de palavras que con- tenham algum tipo de pontuaçao˜ que indique o final de um per´ıodo (ponto final, ponto de interrogaçao,˜ ponto de exclamaçao˜ e ponto-e-v´ırgula) ou a indicaçao˜ de um prenuncio´ (dois pontos). Um exemplo deste tipo de N-Grama seria ”e pronto. No entanto”. Este tipo de N-Grama e´ exclu´ıdo, pois nao˜ faz sentido lexicalmente, o que significa que muito dificilmente sera´ pesquisado por um utilizador e logo nao˜ se justifica a sua inclusao.˜ O segundo tratamento consiste na removeçao˜ de toda a pontuaçao˜ presente nos N-Gramas, de maneira a evitar o caso em que ha´ N-Gramas que seriam iguais com a excepçao˜ de al- guma pontuaçao,˜ como por exemplo os seguintes N-Gramas: ”no entanto e”e´ ”no entanto, e”.´ Apos´ o tratamento dos N-Gramas, estes vao˜ ser inseridos na estrutura HashMap de maneira a se fazer a contagem das ocorrenciasˆ destes. Caso o N-Grama ja´ esteja presente no HashMap, o valor associado a este e´ incrementado num valor; caso contrario,´ o N-Grama e´ inserido na estrutura com o valor um associado. Finalmente, assim que ja´ nao˜ houver mais N-Gramas a acrescentar, obtem-se um iterador com as entradas na estrutura de dados que vai ser percorrido de maneira a produzir os resultados finais que vao˜ depois ser usados para a construçao˜ das estruras de dados para a pesquisa. Neste ficheiro vao˜ estar os seguintes valores, separados por tabs: N-Grama, data (so´ o ano e o mes,ˆ ligados com um ) e numero´ de ocorrencias.ˆ A implementaçao˜ da funçao˜ Reduce encontra-se em anexo. Cap´ıtulo 4. Implementaçao˜ 26

4.1.5 Algoritmo de Categoria de Not´ıcias

A existenciaˆ de categorias de not´ıcias no corpus fornecido permite a criaçao˜ de estruturas de pesquisa espec´ıficas para cada categoria, fornecendo desta forma meios de pesquisa mais especializados. Para tal, foi criado um algoritmo MapReduce que permite a criaçao˜ de estat´ısticas de N-Gramas que tenham em conta as categorias mencionadas.

Map

Tal como no algoritmo usado para a criaçao˜ das principais estat´ısticas dos N-Gramas, a implementaçao˜ da fase de mapeamento deste algoritmo vai seguir os mesmos princ´ıpios. A unica´ diferença reside no facto de o valor usado como chave de emissao˜ consiste na junçao˜ da versao˜ simplificada da data (conjunçao˜ do ano e do mesˆ da not´ıcia) com a categoria da not´ıcia, separados por uma linha vertical.

Reduce

A inclusao˜ da categoria na chave dos valores intermedios´ significa que a contagem realizada na fase de reduçao˜ vai ser especifica aos N-Gramas contidos nessa categoria. Em termos praticos,´ isto implica a inclusao˜ da categoria da not´ıcia no ficheiro de estat´ısticas produzido, de modo a que seja poss´ıvel identificar quais os N-Gramas pertencentes a cada categoria. Tendo em conta esta inclusao,˜ vai ser necessario´ começar por obter a categoria a partir da chave intermedia,´ separando esta dos conteudos´ jornal´ısticos emitidos. Apos´ o processamento destes, e´ necessario´ construir estruturas de dados para cada categoria de forma a que seja poss´ıvel distinguir os N-Gramas por cada categoria.

4.1.6 Algoritmo de Classiﬁcac¸ao˜ de Entidades

Para alem´ da utlizaçao˜ das categorias das not´ıcias como meio de pesquisas mais espec´ıficas, foi igualmente usado um modelo de classificaçao˜ de entidades de forma a fornecer a possibilidade de pesquisa por essas categorias. As entidades existentes consistem em Pessoas, Locais e Organizaçoes˜ e vao˜ se provar uteis´ nos casos em que existem N-Gramas que podem ser classificados em duas categorias distintas. Um exemplo desta situaçao˜ e´ o N-Grama ”Calvin Klein”, o famoso estilista americano, em que este vai estar classificado como uma entidade do tipo Pessoa e do tipo Organizaçao.˜

Map

A implementaçao˜ usada para a fase de mapeamento do algoritmo e´ igual a` usada no algoritmo principal 4.1.4, razao˜ pela qual nao˜ se justifica a repetiçao˜ da sua descriçao.˜ Cap´ıtulo 4. Implementaçao˜ 27

Reduce

Para a identificaçao˜ da categoria recorreu-se a um modelo de classificaçao˜ em que, dada informaçao˜ textual, sao˜ retornados os N-Gramas identificados e a sua respectiva categoria. Este algoritmo tem a particularidade de nao˜ recorrer ao tokenizador da Linguateca para a obtençao˜ de N-Gramas, sendo estes obtidos atraves´ do modelo de classificaçao˜ referido. A utilizaçao˜ deste requer a colocaçao˜ dos ficheiros que contem´ o modelo na cache distribu´ıda do Hadoop de modo a que estejam acess´ıveis na fase Reduce, sendo evocado nesta o classificador CRF que vai ser usado para a obtençao˜ das entidades. O processo de classificaçao˜ vai ser feito no metodo´ recognize, onde o N-Grama e o seu tipo sao˜ conca- tenados, usando uma barra vertical como separador entre os dois, sendo de seguida usada uma v´ırgula como o meio de separaçao˜ entre as varias´ concatenaçoes.˜ Um exemplo do resultado produzido e:´ Calvin Klein—PERSON , Lisboa—LOCATION , Portugal Tele- com—ORGANIZATION , etc. Tendo obtido os N-Gramas e as suas respectivas entidades, o conjunto de resultados produzido vai ser inserido numa estrutura de dados HashMap para a realizaçao˜ da contagem do seu numero´ de ocorrencias,ˆ sendo este processo igual ao que se verifica para os restantes algorirmos descritos anteriormente.

4.1.7 Algoritmo de Classiﬁcac¸ao˜ Gramatical

Para aumentar a riqueza da informaçao˜ dispon´ıvel para pesquisa, foi usado um modelo de classificaçao˜ gramatical [8] para a identificaçao˜ das classes gramaticais de cada palavra que consitui os N-Gramas. A inclusao˜ das categorias gramaticais vai assim permitir a realizaçao˜ de pesquisas e comparaçoes˜ ao n´ıvel lexical, alargando a pesquisa para alem´ do contexto das entidades.

Map

A implementaçao˜ usada para a fase de mapeamento do algoritmo e´ igual a` usada no algoritmo principal, razao˜ pela qual nao˜ se justifica a repetiçao˜ da sua descriçao.˜

Reduce

A fase Reduce vai consistir em duas partes, primeiro a transformaçao˜ dos conteudos´ textuais em N-Gramas e em segundo lugar a classificaçao˜ destes segundo a sua classe gramatical. A categorizacçao˜ gramatical e´ feita recorrendo a tresˆ modelos, em que o primeiro e´ usado para a separaçao˜ do texto em frases (Sentence Model), o segundo para a separaçao˜ das frases produzidas em palavras (Tokenizer Model) e o terceiro para a classificaçao˜ dessas palavras ao n´ıvel gramatical (POS Model [15]). A transformaçao˜ dos conteudos´ textuais em N-Gramas vai recorrer ao tokenizador da Lin- guateca, com o funcionamento a ser igual ao dos restantes algoritmos. Para cada N-Grama Cap´ıtulo 4. Implementaçao˜ 28 produzido, este vai ser classificado de acordo com a sua classe gramatical usando os tresˆ modelos referidos acima, que sao˜ inicializados recorrendo a` cache distribu´ıda do Hadoop de maneira a que os ficheiros que contem´ os modelos estejam acess´ıveis na execuçao˜ da fase Reduce. Os modelos vao˜ ser usados para a desconstruçao˜ dos N-Gramas, começando por separar estes por espaços brancos. As palavras resultantes desta separaçao˜ sao˜ depois classificadas com o tagger POS (Part-Of-Speech) para se determinar qual a classe gramatical de cada uma das palavras em que consiste o N-Grama, sendo feito um agrupamento de seguida, em que cada N-Grama tem a sua respectiva classe associada atraves´ de um underscore (algo do tipo ser verb), com estes agrupamentos separados por espaços brancos. Finalmente e´ feita uma separaçao˜ entre as palavras e as classes correspondentes, sendo substituido o underscore por uma barra comum (slash em ingles)ˆ por razoes˜ esteticas´ e sao˜ reconstru´ıdos os N-Gramas, agora contendo a classe gramatical (algo do tipo: Pe- dro\noun Passos\noun Coelho\noun). Tendo os N-Gramas devidamente classificados, o passo seguinte vai consistir na contagem destes usando uma estrutura de dados HashMap, em que a chave consiste no N-Grama e o valor no numero´ de ocorrencias.ˆ Caso o N-Grama esteja presente na estrutura de dados, o numero´ de ocorrenciasˆ associado e´ incrementado em um valor. Caso contrario,´ e´ feita uma inserçao˜ na estrutura com o N-Grama e o numero´ de ocorrenciasˆ igual a um. Assim que todos os N-Gramas sao˜ inseridos na estrutura, vao˜ se passar os valores desta para um ficheiro de texto, com a informaçao˜ separada por tabs (data, N-Grama e numero´ de ocorrencias,ˆ respectivamente).

4.1.8 Construc¸ao˜ das Estruturas de Dados

Concluido o processamento da informaçao˜ textual em N-Gramas e as suas respectivas estat´ısticas, tem-se a base para a criaçao˜ das estruturas de dados para a realizaçao˜ de pesquisas por N-Gramas. Os resultados produzidos, presentes nas pastas definidas no ficheiro XML de configuraçao˜ e denominados como merged file, vao˜ ter que ser copiados do HDFS para o sistema de ficheiros local em primeiro lugar. Estes ficheiros temˆ os seus conteudos´ presentes sem uma forma espec´ıfica de organizaçao,˜ o que significaria que ao realizar a construçao˜ das estruturas de dados seria necessario´ realizar verificaçoes˜ para a existenciaˆ dos N-Gramas na estrutura de dados, actualizando o numero´ de ocorrenciasˆ caso o actual N-Grama ja´ estivesse presente na estrutura. Este processo e´ custoso em termos de escritas de disco e de tempo necessario´ para o processamento da informaçao.˜ De maneira a evitar este cenario,´ vao˜ se ordenar os ficheiros de acordo com a ordem alfabetica´ dos N-Gramas [5], de maneira a evitar a necessidade de consistentemente verificar a presença destes na estrutura de dados. Desta forma, todos os N-Gramas iguais sao˜ processados apenas uma vez e garante-se que nao˜ ocorrerao˜ noutro ponto no ficheiro, deixando de ser necessario´ efectuar as verificaçoes˜ e actualizaçoes˜ mencionadas anteriormente. Cap´ıtulo 4. Implementaçao˜ 29

Dado que existem quatro algoritmos para a produçao˜ dos ficheiros de estat´ısticas e visto que se pretendem fornecer varias´ formas de pesquisa, vao˜ ser criadas quatro estruturas de dados. Para os algoritmos em que a entidade e´ inclu´ıda no ficheiro de estat´ısticas (algoritmo de categoria e de entidades), a decisao˜ logica´ consiste em construir uma estrutura de dados por categoria de modo a que os N-Gramas correspondentes estejam devidamente agrupados. Para os restantes algoritmos (algoritmo ”normal”e de classificaçao˜ gramatical), essa distinçao˜ nao˜ e´ necessaria,´ sendo apenas criada uma unica´ estrutura de dados (o nome desta pode ser definido no ficheiro XML de configuraçao˜ para cada algoritmo). Como nota final, foi necessario´ representar o numero´ de ocorrenciasˆ por uma String inves´ de um array de inteiros, visto que um HashMap MapDB nao˜ permite a realizaçao˜ de actualizaçoes˜ a estruturas de dados usadas como valor. O ultimo´ passo consiste na construçao˜ do ´ındice Lucene. O ´ındice vai ser construido com base nos ficheiros de corpus dados como input. Como tal, e´ necessario´ refazer o processamento dos N-Gramas e dos numeros´ de ocorrenciasˆ destes para cada data do periodo de tempo do corpus. Dado que neste ponto o processamento dos N-Gramas ja´ foi realizado pelos algoritmos MapReduce, o procedimento logico´ seria usar estes dados para a construçao˜ do ´ındice. Porem,´ dado que o objectivo deste ´ındice e´ associar not´ıcias a N- Gramas, como o URL das not´ıcias nao˜ esta´ presente em nenhum dos ficheiros produzidos pelos algoritmos e´ necessario´ realizar um novo processamento de dados. Como tal, o processamento dos N-Gramas e´ realizado por noticia individual. Os N- Gramas para a not´ıcia sao˜ armazenados numa estrutura de dados Map, aos quais sao˜ associados o numero´ de ocorrenciasˆ para o data da not´ıcia. Apos´ o processamento de todos os N-Gramas para a not´ıcia, sao˜ criados novos registos no ´ındice. Neste ´ındice, cada registo contem´ um N-Grama, o numero´ de ocorrencias,ˆ a data (mesˆ e ano) e o URL da not´ıcia onde este foi identificado. Apos´ a criaçao˜ dos registos, e´ repetido este processo para todas as not´ıcias presentes no ficheiro de corpus.

4.1.9 Implementac¸oes˜ descartadas

O processo da construçao˜ do Back-End implementado nem sempre seguiu os passos descritos, tendo sido consideradas outras soluçoes˜ que, por uma razao˜ ou outra, foram descartadas. Nesta secçao˜ sao˜ descritas as implementaçoes˜ alternativas consideradas e o porqueˆ de nao˜ terem sido implementadas.

Utilizac¸ao˜ de comandos Linux para a contagem

Para a contagem do numero´ de ocorrencias,ˆ foi considerada a realizaçao˜ desta atraves´ da utilizaçao˜ dos comandos Linux sort e uniq em conjunto para a contagem do numero´ de entradas repetidas no ficheiro gerado pelo MapReduce da aplicaçao˜ exemplo WordCount [16]. Esta soluçao˜ foi descartada pois nao˜ possibilitava a inclusao˜ de informaçao˜ adici- Cap´ıtulo 4. Implementaçao˜ 30 onal necessaria´ para a construçao˜ das estruturas de dados, nomeadamente a data e, caso existente, a categoria dos N-Gramas.

Contagem feita na estrutura TreeMap (fora do MapReduce)

Uma segunda soluçao˜ proposta consistia na simples construçao˜ de um ficheiro que texto atraves´ do algoritmo MapReduce que teria como chave a data simplificada associada ao N-Grama e como valor o N-Grama em si. Apos´ a construçao˜ deste ficheiro, a contagem seria feita na fase de inserçao˜ dos N-Gramas na estrutura de dados TreeMap, em que seria feita uma verificaçao˜ da existenciaˆ do N-Grama na estrutura e, caso esta se verificasse, o valor associado era incrementado de maneira a sinalizar uma nova ocorrencia.ˆ Esta soluçao˜ tem como vantagem a sua facilidade de implementaçao,˜ porem,´ apesar de ser funcional, nao˜ aproveitaria todo o potencial do MapReduce e seria bastante demorosa a concluir.

Aplicac¸ao˜ do algoritmo Sufﬁx-σ

Uma implementaçao˜ de um algoritmo para a criaçao˜ de N-Gramas consistiria em gerar estes na fase de mapeamento, fazendo a contagem do numero´ de ocorrenciasˆ dos N- Gramas na fase de reduçao.˜ Porem,´ esta soluçao˜ seria pouco elegante e implicaria uma maior quantidade de I/O na fase de escrita intermedia.´ De forma a melhorar esta situaçao˜ e´ implementado um metodo´ de filtragem que se baseia no algoritmo Sufix-σ [2], em que so´ sao˜ emitidos N-Gramas na fase de mapeamento que possam depois ser descompostos em N-Gramas de tamanho menor. Os N-Gramas emitidos na fase de mapeamento vao˜ depender do valor atribu´ıdo ao σ , valor esse que deve ser igual ao tamanho maximo´ definido no tokenizador da Linguateca. Caso o σ nao˜ correspondesse ao tamanho maximo´ dos N-Gramas, haveria repetiçoes˜ de N-Gramas na decomposiçao˜ feita na fase de reduçao.˜ Esta soluçao˜ chegou a ser implementada, mas verificou-se que esta nao˜ era ideal para a situaçao˜ presente, essencialmente por duas razoes.˜ A primeira razao˜ e´ que o algortimo defende que devem ser emitidos apenas os maiores N-Gramas na fase Map para que haja uma quantidade reduzida de I/O, porem,´ visto que o tamanho maximo´ definido e´ cinco, nao˜ ha´ uma diminuiçao˜ significativa de I/O. Logo, nao˜ se justifica a utilizaçao˜ do tokenizador nesta fase, pois esta vai tornar todo o processo mais demoroso. Em segundo lugar, visto que este algoritmo e´ optimizado para a realizaçao˜ da contagem usando apenas uma maquina,´ nao˜ se estaria a aproveitar a natureza distribu´ıda do algoritmo e o cluster que foi constru´ıdo para tal.

4.2 Web Service

Com o Back-End constru´ıdo, foi necessario´ desenvolver um meio de comunicaçao˜ entre este e o Front-End da aplicaçao˜ que fosse capaz de responder a um conjunto de pedidos Cap´ıtulo 4. Implementaçao˜ 31 dos utilizadores, desde pesquisas ate´ a` invocaçao˜ de um cliente administrativo que possibilite o processamento de corpus textuais e o consequente acrescimo´ de novos N-Gramas as` estruturas de dados. Dado que a interface e´ feita atraves´ de um browser Web, decidi que a melhor soluçao˜ seria construir um Web-Service RESTful. A arquitectura REST e´ definida por um conjunto de princ´ıpios atraves´ dos quais se podem desenhar serviços Web que se focam nos recursos do sistema, usando o protocolo HTTP para definir e endereçar os estados dos recursos. A popularidade deste estilo ar- quitectural resulta da simplicidade de implementaçao,˜ especialmente quando comparando com o estilo SOAP, e do facto de nao˜ necessitar de manter o estado da aplicaçao˜ do cliente, foram as principais razoes˜ que me levaram a escolher este tipo de arquitectura. A biblioteca Jersey [19] foi a escolhida para a criaçao˜ do Web Service RESTful visto que se encontra dispon´ıvel em Java, a linguagem de programaçao˜ predominante do projecto desenvolido nesta tese, e pela sua simplicidade de utilizaçao.˜ A utilizaçao˜ dos metodos´ do protocolo HTTP de uma maneira em que as acçoes˜ sejam consistentes com as definiçoes˜ dos metodos´ e´ uma das caracter´ısticas chave desta arquitectura, havendo uma relaçao˜ directa entre as operaçoes˜ CRUD (Create, Read, Update, Delete) e os metodos´ HTTP. O mapeamento entre as operaçoes˜ e os metodos´ HTTP e:´

• Para criar um recurso no servidor deve-se usar o metodo´ POST.

• Para obter um recurso usa-se o metodo´ GET.

• Para mudar o estado de um recurso ou para o actualizar e´ usado o metodo´ PUT.

• Para remover ou apagar um recurso e´ usado o metodo´ DELETE.

Para este projecto nao˜ foram criadas operaçoes˜ associadas a todos os metodos´ HTTP, apenas para o metodo´ GET. Dada a existenciaˆ de uma vertente administrativa, normalmente seria feita a inclusao˜ das operaçoes˜ desta no Web Service, associando estas aos metodos´ HTTP. Tal nao˜ foi poss´ıvel, pelas razoes˜ apresentadas em 4.4.2. Igualmente fundamental para o processo de construçao˜ do Web Service e´ o URI usado no pedido que, juntamente com o metodo´ HTTP, identifique qual a operaçao˜ a realizar e quais os argumentos dessas operaçoes.˜ O URI base vai conter tresˆ componentes chave para a utilizaçao˜ dos Web Services, presentes no caminho para o recurso. O primeiro e´ o componente REST que e´ usado para indicar qual o Web Service RESTful a que se pretende aceder no servidor. No caso desta aplicaçao,˜ dado que a maioria das funçoes˜ a aceder seriam de pesquisa, definiu-se o serviço como search, sendo este o segundo componente chave. Tendo feito o acesso aos serviços RESTful, mais em espec´ıfico ao que vai ser usado para a realizaçao˜ de pesquisas, e´ necessario´ definir quais os argumentos a passar as` funçoes.˜ Dado que a aplicaçao˜ constru´ıda tem como objectivo a pesquisa pelo numero´ de ocorrenciasˆ de N-Gramas num intervalo de tempo, vai ser necessario´ ter como Cap´ıtulo 4. Implementaçao˜ 32 argumentos os N-Gramas a pesquisar e qual o per´ıodo de tempo onde o fazer. Tendo isto em conta, foi definido que apos´ o componente search, usado tambem´ para identificar o serviço, estariam os N-Gramas a pesquisar, cada um separado por v´ırgulas e que apos´ estes estaria presente o componente timeLimit onde esta´ identificado o per´ıodo de tempo aonde se vai realizar a pesquisa, com as datas inicial e final separadas por v´ırgulas (ambas representadas por ano mes).ˆ As operaçoes˜ disponibilizadas pelo Web Service sao˜ descritas nas secçoes˜ seguintes.

Pesquisa

Seguindo a logica´ de associar os metodos´ HTTP aos serviços fornecidos, a realizaçao˜ de pesquisas vai estar associada ao metodo´ GET, o metodo´ para a obtençao˜ de recursos. Porem,´ visto que vao˜ estar dispon´ıveis varios´ tipos de pesquisas, e´ igualmente necessario´ identificar qual o tipo de pesquisa atraves´ do URL. Para a pesquisa por categoria e´ usado um URL espec´ıfico, pois a categoria onde se quer pesquisar nao˜ e´ identificada atraves´ dos N-Gramas. No caso das restantes pesquisas, estas sao˜ identificadas atraves´ dos N-Gramas presentes no URI, em que N-Gramas ”simples”(Cavaco Silva, por exemplo) devem ser pesquisados na estrutura de dados ”principal”, N-Gramas inseridos entre tags de entidades (Cavaco Silva, por exemplo) devem ser pesquisados na estrutura de dados referente a` entidade descrita na tag e N-Gramas com a sua classe gramatical concatenada (Cavaco—noun Silva—noun) devem ser pesquisados na estrutura de dados para N-Gramas classificados atraves´ do modelo de Stanford. Seguindo a nomenclatura do URI definida, sao˜ de seguida apresentados tresˆ exemplos de URLs para as pesquisas descritas nesta secçao.˜ Para a pesquisa regular, o URI vai ser: http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ PedroPassosCoelho/timeLimit/2000_1,2012_12 Este URI, em conjunto com o metodo´ HTTP GET vai devolver todos as ocorrenciasˆ do N-Grama Pedro Passos Coelho desde Janeiro de 2000 ate´ Dezembro de 2012. Para a pesquisa por entidades, consideremos o caso em que o mesmo N-Grama pode referir-se a duas entidades diferentes, no caso deste exemplo o famoso estilista e a marca de roupa associada a este, Calvin Klein. Repare-se a utilizaçao˜ das categorias a envol- ver o N-Grama, que vao˜ desta forma indicar qual a estrutura de dados aonde realizar as pesquisas. http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ CalvinKlein,CalvinKlein /timeLimit/2000_1,2012_12 Finalmente, caso se pretenda realizar uma pesquisa em que a componente chave sao˜ as classes lexicais das palavras que constituem o N-Grama, vao˜ se incluir estas (em ingles)ˆ juntamente com cada palavra do N-Grama, separando a classe da palavra atraves´ de uma barra vertical. Cap´ıtulo 4. Implementaçao˜ 33

http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ Pedro|nounPassos|nounCoelho|noun/timeLimit/2000_1,2012_12 O resultado destas pesquisas vai ser um ﬁcheiro JSON que contem´ o ano inicial, o(s) N-Grama(s) e um array com o numero´ de ocorrenciasˆ que, associado com o ano inicial, vai deﬁnir as ocorrenciasˆ para cada mesˆ do per´ıodo de tempo.

[{"nGram":"Pedro Passos Coelho", "numberTimes":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0, 0,0,9,3,1,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0, 0,0,0,59,219,32,7,3,6,9,17,7,10,5,9,6,11,19,30,42,26, 51,23,5,45,117,341,331,236,181,282,123,352,342,245,44, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], "startYear":2000}]

Pesquisa por Categoria

Ao se ter a categoria de cada not´ıcia presente no corpus, foi criada uma funçao˜ de pesquisa que, dada a categoria desejada, realizaria a pesquisa dos N-Gramas numa estrutura espec´ıfica que contem´ apenas os N-Gramas derivados a partir das not´ıcias da respectiva categoria. Visto que se pretende obter informaçao˜ presente no servidor, o metodo´ HTTP mantem-se´ como o GET. Ao contrario´ das pesquisas anteriores, em que o N-Grama em si e´ usado para identificar qual o tipo de pesquisa a realizar, decidi que para a categoria seria incrementado ao URI para as pesquisas, apos´ os valores que determinam o intervalo de tempo, um novo componente denominado categorySearch que indica qual a categoria em que se pretende pesquisar pelos N-Gramas. Como exemplo, consideremos o seguinte URI: http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ PedroPassosCoelho/timeLimit/2000_1,2012_12/categorySearch/POLITICA Porem,´ esta implementaçao˜ tem a limitaçao˜ de nao˜ permitir a comparaçao˜ directa de resultados obtidos atraves´ de outros tipos de pesquisas ou de outras categorias.

Download dos Resultados em Ficheiro CSV

Ao se realizar uma pesquisa, pode ser do interesse do utilizador a utilizaçao˜ dos dados obtidos para se efectuarem outras analises´ estat´ısticas. Tendo em conta esta situaçao,˜ foi constru´ıdo um serviço que permite o download das estat´ısticas da pesquisa realizada num ficheiro CSV, em que cada linha contem´ o N-Grama, a junçao˜ do mesˆ e do ano e o numero´ de ocorrencias,ˆ todos separados por v´ırgulas. Cap´ıtulo 4. Implementaçao˜ 34

http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ PedroPassosCoelho/timeLimit/2000_1,2012_12/download

O resultado apresentado e´ algo do tipo:

"Pedro Passos Coelho","Jan/2000","0" "Pedro Passos Coelho","Fev/2000","0" "Pedro Passos Coelho","Mar/2000","0" "Pedro Passos Coelho","Abr/2000","0" "Pedro Passos Coelho","Mai/2000","0" "Pedro Passos Coelho","Jun/2000","0" "Pedro Passos Coelho","Jul/2000","0" "Pedro Passos Coelho","Ago/2000","0" "Pedro Passos Coelho","Set/2000","0" "Pedro Passos Coelho","Out/2000","0" "Pedro Passos Coelho","Nov/2000","0" "Pedro Passos Coelho","Dez/2000","0" "Pedro Passos Coelho","Jan/2001","0"

Pesquisa de not´ıcias associadas ao N-Grama e a` data de pesquisa

Para alem´ de retornar o numero´ de ocorrenciasˆ dos N-Gramas, foi considerada como uma situaçao˜ de interesse a obtençao˜ das not´ıcias de onde os N-Gramas foram gerados. Para tal, um ´ındice Lucene foi constru´ıdo que contem´ os urls para as not´ıcias associadas aos N-Gramas, para cada data do per´ıodo de tempo definido. Dado que o grafico´ possibilita a selecçao˜ dos pontos que representam as ocorrenciasˆ dos N-Gramas, aproveitou-se esta funcionalidade para a invocaçao˜ deste serviço. http://dmir.inesc-id.pt/ngramas-publico-2001-2010/rest/search/ PedroPassosCoelho,/timeLimit/2008_05,/luceneIndex

Figura 4.1: Publico´ Online N-Gram Search - News Articles Cap´ıtulo 4. Implementac¸ao˜ 35

PAI

Concluindo este cap´ıtulo, e´ apresentado um resumo dos web services disponibilizados:

Metodo´ URL Descriçao˜ GET /rest/search/ngram,ngram,.../ Obtençao˜ do numero´ de timeLimit/interval ocorrenciasˆ dos N-Gramas no intervalo de tempo definido GET /rest/search/ngram,ngram,.../ Obtençao˜ do numero´ de timeLimit/interval/category- ocorrenciasˆ dos N-Gramas Search/category de uma das categorias de not´ıcias (Politica, Desporto, etc) presentes no corpus GET /rest/search/ngram,ngram,.../ Disponibilizaçao˜ de um fi- timeLimit/interval/download cheiros CSV que contem´ os dados estat´ısticos dos N- Gramas para o intervalo de tempo definido GET /rest/search/ngram,ngram,.../ Obtençao˜ dos registos no timeLimit/interval/luceneIn- ´ındice Lucene que contem´ dex as noticias associadas aos N- Gramas pesquisados no intervalo de tempo definido

4.3 Front-End

Dado o objectivo central da aplicaçao˜ em estudar o numero´ de ocorrenciasˆ dos N-Gramas ao longo de um per´ıodo de tempo, considerei como os factores mais importantes para a aplicaçao˜ que iria interagir com o utilizador a facilidade da realizaçao˜ de pesquisas e a cla- reza dos resultados produzidos. Tendo em conta estes dois principios, procurei construir um aplicaçao˜ Web que, atraves´ de um design simples, possibilite a realizaçao˜ de pesquisas regulares e avançadas, demonstrando os seus resultados estat´ısticos num grafico´ de linhas que retrata as flutuaçoes˜ das ocorrenciasˆ ao longo de um per´ıodo de tempo. Foi construida igualmente uma componente administrativa que permite a realizaçao˜ do processo de desconstruçao˜ de um corpus jornal´ıstico em N-Gramas, incrementando os dados dispon´ıveis para pesquisa. Nas seguintes secçoes˜ sao˜ descritas ambas as implementaçoes˜ realizadas.

Tecnologias utilizadas

Para o desenvolvimento do Front-End como uma aplicac¸ao˜ Web, foram necessarias´ as seguintes tecnologias: Cap´ıtulo 4. Implementac¸ao˜ 36

HTML: O HTML e´ uma linguagem de marcaçao˜ utilizada para a produçao˜ de paginas´ Web. Esta vai ser usada atraves´ da tecnologia JSP (ver o cap´ıtulo ??) que vai criar a pagina´ Web dinamicamente com base na interacçao˜ do utilizador com o sistema.

CSS: O CCS e´ uma linguagem de estilo usada para a definiçao˜ da apresentaçao˜ de paginas´ Web, estando separada do conteudo´ da pagina.´ No CSS vao˜ estar definidos elementos como o layout, cores, fontes, entre outros.

JSON: O JSON (JavaScript Object Notation) e´ um formato baseado em texto usado para a troca de dados que podem ser lidos por humanos. Este vai ser usado na devoluc¸ao˜ de dados por parte do Web Service usado para as pesquisas, sendo prontamente convertido em visualizac¸oes˜ a serem apresentadas nas paginas´ Web.

JavaScript: O JavaScript e´ uma linguagem de programac¸ao˜ usada em aplicac¸oes˜ Web, sendo a sua principal utilidade a possibilidade de realizar pedidos HTTP de uma maneira ass´ıncrona. Esta funcionalidade e´ conhecida como AJAX.

4.3.1 Publico´ Online NGram Search

Dado que o objectivo principal da aplicac¸ao˜ centra-se na realizac¸ao˜ de pesquisas por N-Gramas, a componente central presente no Front-End e´ a caixa de texto onde sao˜ colo- cados os N-Gramas a pesquisar na base de dados.

Figura 4.2: Publico´ Online N-Gram Search - Start Screen

Ao se efectuar uma pesquisa padrao,˜ o resultado apresentado e:´ Cap´ıtulo 4. Implementac¸ao˜ 37

Figura 4.3: Publico´ Online N-Gram Search - Normal Search

Considerando as diversas estruturas de dados especificadas anteriormente, procurei criar metodos´ de acesso a estas que nao˜ involvessem uma sobrecarga de componentes interactivos (botoes,˜ drop-down lists, checkboxes, etc) na interface. Para tal, sao˜ usados identificadores (tags) em conjunto com os N-Gramas que identificam qual a estrutura a pesquisar. As tags dispon´ıveis sao:˜

• Tags de entidade - Usadas para a obtençao˜ das estat´ısticas de N-Gramas identificados com um modelo de classificaçao˜ que distingue entidades do tipo Pessoa, Local e Organizaçao.˜ A utilizacao˜ consiste em aplicar tags N- Grama.

• Tags de categoria gramatical - Usadas para a obtençao˜ de estat´ısticas de N-Gramas classificados com o modelo de classificaçao˜ gramatical. A utilizaçao˜ consiste em classificar cada palavra do N-Grama com o classe gramatical deste, como por exemplo: Cavaco—noun Silva—noun. As classes gramaticais dispon´ıveis para pesquisa estao˜ presentes na secçao˜ de FAQs da aplicaçao.˜

Para o caso das pesquisas por categoria, nao˜ se usaram tags juntamente com os N- Gramas, sendo a ﬁltragem feita atraves´ de um menu drop-down que contem´ as categorias de not´ıcias existentes. Cap´ıtulo 4. Implementac¸ao˜ 38

Figura 4.4: Publico´ Online N-Gram Search - Category Search

Em perpectiva esta implementaçao˜ e´ desnecessariamente´ limitativa, devendo ter sido trocada por uma implementaçao˜ usando identificadores para os N-Gramas semelhante as` usadas para as estruturas de entidade e para a estrutura com a classificaçao˜ gramatical, apresentadas de seguida.

Figura 4.5: Publico´ Online N-Gram Search - Lexical Search Cap´ıtulo 4. Implementac¸ao˜ 39

Figura 4.6: Publico´ Online N-Gram Search - Entity Search

Em relaçao˜ ao per´ıodo de tempo, sao˜ usadas duas caixas de texto para se definir o mesˆ e ano de in´ıcio e fim do per´ıodo de tempo aonde se vai realizar a pesquisa. Apesar do corpus estar definido para 10 anos de not´ıcias, dado que o sistema inclui uma ferramenta administrativa que permite o processamento de ficheiros de corpus, outro tipo de implementaçao˜ que limitasse o per´ıodo de pesquisa ao conjunto de 10 anos inicial impos- sibilitaria a expansao˜ da base de dados. Para alem´ das funcionalidades presentes inicialmente no Front-End, o grafico´ resultante das pesquisas realizadas nao˜ se limita a fornecer informaçao˜ meramente visual, possibilitando a obtençao˜ das not´ıcias que contem´ os N- Gramas pesquisados para um dos meses do per´ıodo de tempo definido atraves´ da selecçao˜ de um dos pontos presentes no grafico.´ Por exemplo, ao se seleccionar o mesˆ de Abril de 2010:

Figura 4.7: Publico´ Online N-Gram Search - On Hover Info Cap´ıtulo 4. Implementac¸ao˜ 40

A aplicac¸ao˜ apresentara´ os links para as not´ıcias que contem´ o N-Grama pesquisado.

Figura 4.8: Publico´ Online N-Gram Search - Artigos que contem´ o N-Grama pesquisado

Finalmente, para alem´ das funcionalidades em si, sao˜ igualmente fornecidas instruçoes˜ de utilizaçao˜ que explicam o funcionamento da aplicaçao˜ ate´ aqui descrito, assim como o ´ıcone de lançamento para a execuçao˜ da aplicaçao˜ administrativa.

4.3.2 Publico´ Online NGram Admin Client

O sistema desenvolvido, mesmo tendo em conta o foco no per´ıodo de dez anos definido, foi pensado de forma a que tivesse a capacidade de ser incrementado com nova informaçao˜ proveniente de ficheiros de texto corpus. Para que tal fosse poss´ıvel, foi constru´ıda uma componente administrativa que permite o upload de ficheiros de corpus e o processamento destes usando os algoritmos MapReduce.

Figura 4.9: Publico´ N-Gram Search Admin Program - Main Window Cap´ıtulo 4. Implementac¸ao˜ 41

As cinco funcionalidade disponibilizadas sao:˜

1. Send File

2. Start MapReduce

3. Remove Uploaded Files

4. Check Progress

5. Redeﬁne Server Access

Dentro destas, duas funcionalidades sao˜ chave para o acrescimo´ das bases de dados. A primeira e´ a ”Send File”, a partir da qual vai surgir uma janela para o upload de ﬁcheiros onde se pode escolher qual o ﬁcheiro de corpus a enviar para o servidor.

Figura 4.10: Publico´ N-Gram Search Admin Program - Upload Window

Assim que o upload do ficheiro corpus estiver concluido, o utilizador e´ informado a partir da aplicaçao:˜ Cap´ıtulo 4. Implementaçao˜ 42

Figura 4.11: Publico´ N-Gram Search Admin Program - Upload Conclu´ıdo

Caso sejam enviados ficheiros de texto por engano para o servidor, e´ poss´ıvel elimina-´ los atraves´ da opçao˜ ”Remove Uploaded Files”. Ao se seleccionar esta, e´ apresentada uma janela de confirmaçao˜ com os ficheiros presentes no servidor a eliminar, cabendo ao utilizador decidir se deseja eliminar os ficheiros ou nao.˜

Tendo um ou mais ficheiros de corpus presentes no servidor, o proximo´ passo sera´ transformar estes em N-Gramas e actualizar as estruturas de dados com as novas estat´ısticas de ocorrenciasˆ resultantes destes novos ficheiros. Para tal, e´ necessario´ usar a opçao˜ ”Start MapReduce”, que por sua vez vai executar um script que invoca o programa Java RunAllMapReduceAlgorithms, responsavel´ pela inicializaçao˜ dos processos MapReduce e pela construçao˜ das estruturas de dados. O processamento dos ficheiros de texto esta´ dividido em tresˆ partes. A primeira consiste na transferenciaˆ dos ficheiros corpus para o sistema de ficheiros HDFS, de maneira a que estes estejam acess´ıveis aos algoritmos MapReduce. Ao se ter os ficheiros presentes no HDFS, vao˜ se executar os algoritmos MapReduce individualmente de maneira a evitar um sobrecarregamento de jobs em clusters com menor capacidade, especialmente devido ao facto de certos algoritmos necessitarem de ter modelos presentes em cache o que pode levar a` existenciaˆ de erros de falta de memoria.´ Cada processo vai transformar os conteudos´ dos ficheiros de corpus em N-Gramas, escrevendo estes com a data e o numero´ de ocorrenciasˆ para um ficheiros de texto. Dado que o output produzido pelos algoritmos MapReduce nao˜ se encontra ordenado, e´ necessario´ organiza-lo´ de modo a que a inserçao˜ Cap´ıtulo 4. Implementaçao˜ 43 dos N-Gramas seja feita em tempo util.´ A qualquer momento durante a execuçao˜ do processo de construçao/acr˜ escimo´ das estruturas de dados e´ poss´ıvel visualizar o progresso realizado ate´ ao momento recorrendo a` opçao˜ ”Check Progress”que demonstra na aplicaçao˜ em que ponto de execuçao˜ o processo se encontra.

Figura 4.12: Publico´ N-Gram Search Admin Program - Veriﬁcar Progresso

Finalmente, caso o sistema seja instalado noutro servidor e´ necessario´ modiﬁcar os parametrosˆ de acesso a este (utilizador, hostname, password ou pasta de uploads).

Figura 4.13: Publico´ N-Gram Search Admin Program - Definiçoes˜ Cap´ıtulo 4. Implementaçao˜ 44

4.4 Principais Problemas Encontrados

A actual soluçao˜ evoluiu de implementaçoes˜ iniciais que, por uma razao˜ ou outra, nao˜ possibilitavam o funcionamento idealizado para a aplicaçao.˜ Neste cap´ıtulo sao˜ discutidas algumas destas implementaçoes˜ iniciais, analisando quais as razoes˜ que levaram ao seu desenvolvimento e o porqueˆ de estas terem sido discartas.

4.4.1 Actualizac¸ao˜ dos dados nas estruturas MapDB

A implementaçao˜ inicial das bases de dados MapDB foi feita de modo a que as estruturas TreeMap seguissem o modelo chave/valor em que a chave seria o N-Grama, representado por uma String, e o valor um conjunto de numeros´ que representaria o numero´ de ocorrenciasˆ em cada mesˆ do per´ıodo de tempo definido, representado atraves´ de um array de inteiros. Esta implementaçao˜ revelou-se funcional para a inserçao˜ inicial de dados, demonstrando uma boa performance tanto ao n´ıvel de inserçao˜ como ao n´ıvel de espaço ocupado. Porem,´ com o avanço do projecto, foi necessario´ incluir a capacidade de actualizar as bases de dados atraves´ do cliente administrativo. Inicialmente, a ideia seria usar o metodo´ replace dispon´ıvel para a substituiçao˜ do array de inteiros associado ao N-Grama por um novo que contivesse os novos valores de ocorrencias.ˆ Dado que este nao˜ se encontrava dispon´ıvel para os tipos de variaveis´ usados, o metodo´ implementado consistiu em verificar a existenciaˆ dos N-Gramas na estrutura e, caso este se verificasse, remover o registo com os antigos valores e inserir um novo registo com o array actualizado com o novo numero´ de ocorrencias.ˆ Esta abordagem revelou-se problematica,´ pois segundo o autor da biblioteca MapDB [20] e´ necessario´ que os pares chave/valor sejam imutaveis,´ o que significa que o processo de remoçao˜ e reinserçao˜ dos registos nao˜ e´ valido.´ A soluçao˜ para este problema foi substituir o tipo de variavel´ para os valores de um array de inteiros para uma String, alteraçao˜ que imediatamente disponibilizou o metodo´ replace para a estrutura de dados, que antes nao˜ se encontrava dispon´ıvel. Esta conversao˜ significa que e´ necessario´ transformar o valor num array de inteiros quando se quer actualizar as ocorrenciasˆ e depois retransformar o novo array numa String para armazenar na estrutura de dados.

4.4.2 Criac¸ao˜ da aplicac¸ao˜ administrativa

Um problema que se verificou no desenvolvimento do sistema foi na construçao˜ da aplicaçao˜ admin, que fornece uma interface para que facilita o upload de ficheiros de texto de corpus para o servidor e a sua respectiva transformaçao˜ em N-Gramas, assim como a actualizaçao˜ das estruturas de dados, com a ideia original sendo uma aplicaçao˜ Web tal como a versao˜ do cliente atraves´ do qual fosse poss´ıvel executar os algoritmos MapReduce para o processamento dos dados. Para a execuçao˜ destes algoritmos, a forma ideal consiste em Cap´ıtulo 4. Implementaçao˜ 45 colocar as classes num ficheiro .jar (para uma distribuiçao˜ simplificada entre as varias´ maquinas´ no cluster Hadoop) e executar este atraves´ da linha de comandos. Esta forma de funcionamento significa que e´ necessario´ recorrer a` classe Runtime de maneira a permitir que a aplicaçao˜ possa interagir com o ambiente onde esta esta´ a ser executada, neste caso de maneira a correr os comandos necessarios´ para a execuçao˜ dos ficheiros .jar que contem´ os algoritmos MapReduce. A necessidade de recorrer a esta forma de funcionamento vai ser a genese´ do problema, visto que nao˜ consegui encontrar uma forma de executar os ficheiros .jar usando a classe Runtime dentro de um servlet Java. Isto nao˜ quer dizer que e´ imposs´ıvel executar comandos do terminal num servlet (como se pode verificar na explicaçao˜ dada em [?]), apenas que eu nao˜ consegui identificar uma execuçao˜ que produzisse os resultados desejados. Resultante desta situaçao,˜ foi construida a aplicaçao˜ Java 4.3.2 que e´ descrita no cap´ıtulo anterior.

4.4.3 Criac¸ao˜ da estrutura de dados TreeMap na func¸ao˜ Reduce

A ideia inicial para a criaçao˜ da estrutura de dados onde os N-Gramas e as suas ocorrenciasˆ estariam presentes seria ter o preenchimento da estrutura de dados a ser feito na funçao˜ Reduce, com a geraçao˜ dos N-Gramas a ser realizada na funçao˜ Map. A razao˜ pela qual esta soluçao˜ nao˜ foi implementada deve-se ao facto de o sistema de ficheiros Hadoop (HDFS) nao˜ possuir os t´ıpicos daemons (rpc.nfsd e rpc.mountd) necessarios´ para a escrita de ficheiros, sendo apenas poss´ıvel criar ficheiros atraves´ da API do Hadoop.

4.4.4 Implementac¸ao˜ do cluster Hadoop

Idealmente, a implementaçao˜ de um cluster Hadoop teria todos os nos´ instalados no mesmo local no sistema de ficheiros nas diversas maquinas.´ Porem,´ tal nao˜ foi poss´ıvel devido ao facto de as maquinas´ usadas serem na realidade maquinas´ virtuais no mesmo servidor, o que significa que foi necessario´ realizar algumas modificaçoes˜ chave em dois scripts Shell usados para a inicializaçao˜ dos varios´ componentes nos diversos nos.´ Visto que as instalaçoes˜ estao˜ presentes em maquinas´ distintas, o primeiro passo foi criar um ficheiro que contivesse a informaçao˜ para cada maquina.´ Cada linha do ficheiro contem´ o nome da maquina´ onde este se encontra, o caminho da pasta de instalaçao˜ do hadoop e o caminho da pasta de configuraçao,˜ estando todos estes separados por ”;”. Este ficheiro foi denominado de paths. A primeira modificaçao˜ foi realizada no ficheiro hadoop-daemons, responsavel´ pela inicializaçao˜ dos daemons hadoop das outras maquinas,´ onde foi acrescentada a leitura do ficheiro paths descrito anteriormente, de modo a colocar a informaçao˜ das maquinas´ do cluster em variaveis.´ Estas vao˜ ser usadas na execuçao˜ do script slaves.sh, sendo en- globadas nos argumentos fornecidos. A primeira variavel´ a ser usada e´ a que contem o Cap´ıtulo 4. Implementaçao˜ 46 nome da maquina,´ tendo sido necessaria´ a inclusao˜ de um novo argumento identificado como machine. As duas restantes variaveis,´ hadoop casa e hadoop conf dir, contem´ os caminhos para a pasta de instalaçao˜ e configuraçao˜ do Hadoop na respectiva maquina´ respectivamente, sendo usadas para a execuçao˜ do script slaves. A primeira variavel´ e´ usada para o acesso a` pasta de instalaçao˜ do Hadoop na maquina´ e para a execuçao˜ do script para a inicializaçao˜ do daemon Hadoop, enquanto a ultima´ fornece o acesso a` pasta de configuraçao˜ do Hadoop na maquina.´ Finalmente, foi necessario´ colocar o comando de execuçao˜ do script slaves entre parentesesˆ para que este fosse executado como um sub- processo. As modificaçoes˜ realizadas estao˜ presentes em anexo. As modificaçoes˜ realizadas no script hadoop-daemons vao˜ estar directamente relaciona- das com o script slaves.sh, responsavel´ pela inicializaçao˜ dos nos´ do cluster em cada maquina.´ A primeira modificaçao˜ foi o acrescimo´ do argumento machine, usado para a identificaçao˜ da maquina´ aonde se vai inicializar um dos nos´ do cluster. Na implementaçao˜ original, os nomes das maquinas´ seriam obtidos a partir do ficheiro hosts presente no no´ mestre, e para cada uma seria realizada uma ligaçao˜ ssh para a inicializaçao˜ do no´ no cluster. Visto que a leitura do ficheiro paths foi realizada no script hadoop-daemons, onde toda a informaçao˜ necessaria´ para cada maquina´ esta´ presente, considerei que nao˜ seria uma boa soluçao˜ voltar a realizar a leitura do ficheiro no script slaves. A soluçao,˜ a segunda modificaçao˜ realizada no script, consistiu na utilizaçao˜ do argumento machine para a identificaçao˜ do nome da maquina´ a usar para a inicializaçao˜ do no,´ tendo sido removido o processo de leitura e iteraçao˜ do ficheiro hosts usado para esse proposito.´ Cap´ıtulo 5

Resultados

A eficienciaˆ da execuçao˜ do algoritmo MapReduce e´ descrita neste cap´ıtulo, sendo analisada a performance do algoritmo de acordo com um conjunto de variaveis´ (numero´ de funçoes˜ Map, numero´ de funçoes˜ Reduce, numeros´ de maquinas´ no cluster, tipo de algoritmo usado, entre outros). Para alem´ da analise´ a` performance dos algoritmos Ma- pReduce, sao˜ igualmente observadas as estat´ısticas produzidas por estes com o objectivo de verificar a credibilidade destas.

5.1 MapReduce

Nesta secc¸ao˜ e´ analisada a performance dos algoritmos MapReduce desenvolvidos para quatro conjuntos de dados, em que cada conjunto consiste nas not´ıcias presentes num intervalo de tempo. Os intervalos de tempo usados para a analise´ de desempenho dos algoritmos sao:˜ um dia, um mes,ˆ um ano e os dez anos entre 2001 e 2010. Para os resultados obtidos em cada algoritmo, foram realizadas as seguintes analises:´

1. Tempo de execuc¸ao˜ por tamanho do ﬁcheiro corpus

2.N umero´ de func¸oes˜ Map por tamanho do ﬁcheiro corpus

3.N umero´ de func¸oes˜ Reduce por tamanho do ﬁcheiro corpus

Os testes foram realizados em dois clusters, um com apenas um no´ da maquina´ reac- tionvm04 e outro que contem´ dois nos,´ um na maquina´ reactionvm04 e outro na maquina´ borat. Os componentes mais importantes para o funcionamento dos algoritmos MapRe- duce sao˜ apresentados na seguinte tabela:

Componente borat reactionvm04 Cores 8 4 Frequenciaˆ 2.93GHz 3.2GHz RAM 16GB 6GB Tabela 5.1: Conﬁgurac¸oes˜ das maquinas´ do cluster

47 Cap´ıtulo 5. Resultados 48

5.1.1 Algoritmo Base

O algoritmo base vai ser o responsavel´ pela criaçao˜ das estat´ısticas a usar para a pesquisa base, sem qualquer tipo de condicionantes (categorias de not´ıcias, tipos de entidades ou categorias gramaticais). Começando pela analise´ do tempo de execuçao˜ do algoritmo em relaçao˜ ao tamanho do ficheiro corpus, vai-se começar por comparar o tempo de execuçao˜ para o conjunto de not´ıcias para apenas um dia.

100 1 no´ 2 nos´ 80

40 Tempo (min)

0 0 100 200 300 400 500 Tamanho ﬁcheiro corpus (MB)

Figura 5.1: Tempo de execuc¸ao˜ pelo tamanho do ﬁcheiro corpus - Algoritmo Base

Como se pode verificar ao se compararem os graficos´ 5.1.1, o acrescimo´ de um segundo no´ ao cluster vai diminuir drasticamente´ o tempo de execuçao˜ do algoritmo. Igual- mente, foram analisadas funçoes˜ Map e Reduce para o algoritmo tendo em conta o tamanho do ficheiro de corpus fornecido. Os resultados obtidos foram:

1 no´ 8 2 nos´

6 ˜ oes Map 4 de func¸ o N 2

0 100 200 300 400 500 Tamanho ﬁcheiro corpus (MB)

Figura 5.2: Func¸oes˜ Map - Algoritmo Principal Cap´ıtulo 5. Resultados 49

Observando o grafico,´ verificasse que a inclusao˜ de mais um no´ ao cluster nao˜ vai diferenciar o numero´ de funçoes˜ invocadas. Este facto resulta do numero´ de funçoes˜ Map estar directamente relacionado com o tamanho definido para a divisao˜ dos ficheiros de input em blocos DFS. Para a implementaçao˜ utilizada, o tamanho maximo´ foi definido como 64 MB. Observando os valores obtidos, para os ficheiros de corpus referentes a um dia e a um mesˆ foi apenas emitida uma funçao˜ Map pois o tamanho destes e´ menor que 64MB e como tal foi usado apenas um bloco DFS. Para o ficheiro correspondente a um ano, dado que este ja´ ultrapassa o tamanho limite definido, foi necessario´ dividir este em dois blocos e para o ficheiro correspondente ao per´ıodo de dez anos foi necessario´ realizar a divisao˜ em oito blocos. Este comportamento vai-se verificar igualmente para os outros algoritmos realizados, dado que o tamanho dos blocos e´ o mesmo para todos os algoritmos, e como tal nao˜ se vai repetir esta analise´ abaixo. O numero´ de funçoes˜ Reduce e´ determinado manualmente, nos ficheiros XML de configuraçao,˜ ao contrario´ das funçoes˜ Map que sao˜ determinadas a partir do tamanho do ficheiro de input e do tamanho definido para os blocos DFS. O numero´ ideal de reducers esta´ directamente relacionado com o numero´ de nos´ do cluster usado, devendo-se multiplicar o numero´ de nos´ por 0.95 ou 1.75 para se determinar o funcionamento desejado para os reduces e qual a quantidade usada no processamento de dados. Com o valor a 0.95, um reduce por maquina´ no,´ todas as funçoes˜ de reduçao˜ podem ser inicializadas ao mesmo tempo e começar a transferir os outputs das funçoes˜ Map assim que estas acabam. Para o valor a 1.75, correspondente a cerca de duas funçoes˜ Reduce por no,´ os nos´ mais rapidos´ vao˜ completar uma primeira ronda de funçoes˜ Reduce, inicializando uma segunda ronda assim que as primeiras funçoes˜ acabem, distribuindo melhor os dados a processar. Tendo em conta que a quantidade de informaçao˜ a processar vai ser para um conjunto de not´ıcias de dez anos, decidi que a soluçao˜ mais rapida´ seria ter duas funçoes˜ Reduce por no´ no cluster. Esta decisao˜ implica que, independemente do tamanho do ficheiro corpus, o numero´ de funçoes˜ Reduce vai ser sempre quatro. Tendo em conta que o numero´ de funçoes˜ Map vai depender do tamanho dos ficheiros dados como input e que para a realizaçao˜ destes testes foram usados sempre os mesmos conjuntos de dados, o resultado desta analise´ sera´ sempre o mesmo, independentemente do algoritmo usado. Igualmente, visto que o numero´ de funçoes˜ Reduce foi definido manualmente, o resultado da analise´ sera´ sempre o mesmo. Logo, nao˜ se justifica a repetiçao˜ destas analises´ para os restantes algoritmos.

5.1.2 Algoritmo de Categorias de Not´ıcias

O algoritmo usado para a separaçao˜ de dados atraves´ da categoria da not´ıcia vai requerer que a emissao˜ efectuada na funçao˜ Map inclua a categoria da not´ıcia e que na funçao˜ Reduce essa categoria seja usada na identificaçao˜ dos N-Gramas. Naturalmente, preve-seˆ Cap´ıtulo 5. Resultados 50 que a inclusao˜ destas filtragens va´ prejudicar a performance do algoritmo. A performance do tempo de execuçao˜ deste algoritmo vai ser:

100 1 no´ 2 nos´

40 Tempo (min)

0 0 100 200 300 400 500 Tamanho ﬁcheiro corpus (MB)

Figura 5.3: Tempo de execuc¸ao˜ pelo tamanho do ﬁcheiro corpus - Algoritmo Categoria Not´ıcias

Como seria de esperar, o processo de separaçao˜ por categoria de not´ıcia aumenta o tempo de execuçao˜ do algoritmo em comparaçao˜ com o anterior, dada a necessidade de acrescentar uma validaçao˜ para a extracçao˜ da categoria da not´ıcia, assim como a inclusao˜ desta no processo de emissao˜ na funçao˜ Map. A funçao˜ Reduce, por seu lado, nao˜ requer alteraçoes˜ para acomodar a inclusao˜ da categoria da not´ıcia.

5.1.3 Algoritmo de Classiﬁcac¸ao˜ de Entidades

A categorizaçao˜ de um algoritmo pelo seu tipo de entidade requer a utilizaçao˜ de um modelo de classificaçao˜ que determina se os conteudos´ de uma frase contem´ uma entidade do tipo Local, Pessoa ou Organizaçao.˜ A fase de mapeamento vai consistir na emisao˜ das not´ıcias associadas a` sua data. A inclusao˜ do modelo de classificaçao˜ na fase de reduçao˜ significa que foram escritos menos registos no ficheiro de output produzido, porem´ a necessidade de aplicar o modelo a todas as not´ıcias significa um maior consumo de memoria´ interna e um maior quantidade de tempo necessario´ para a escrita. Cap´ıtulo 5. Resultados 51

1 no´ 800 2 nos´

600

400 Tempo (min) 200

0 100 200 300 400 500 Tamanho ﬁcheiro corpus (MB)

Figura 5.4: Tempo de execuc¸ao˜ pelo tamanho do ﬁcheiro corpus - Algoritmo Entidades

Como previsto, a aplicaçao˜ do modelo de classificaçao˜ de entidades vai resultar num tempo de execuçao˜ bastante superior, especialmente aquando a utilizaçao˜ de um cluster de apenas um no.´ Cap´ıtulo 5. Resultados 52

5.1.4 Algoritmo de Classiﬁcac¸ao˜ Gramatical

Igualmente ao algoritmo para a classificaçao˜ por entidade, o algoritmo para a classificaçao˜ gramatical dos N-Gramas produzidos vai requerer a utilizaçao˜ de um modelo de dados.

1 no´ 3,000 2 nos´ 2,500

2,000

1,500

Tempo1 (min) ,000

500

0 100 200 300 400 500 Tamanho ﬁcheiro corpus (MB)

Figura 5.5: Tempo de execuc¸ao˜ pelo tamanho do ﬁcheiro corpus - Algoritmo Gramatical

De todos os algoritmos, este e´ o que vai requerer uma maior quantidade de tempo a processar, especialmente devido a` necessidade de separar os N-Gramas em palavras individuais, categorizar estas segundo o modelo de classiﬁcac¸ao˜ gramatical e voltar a construir o N-Grama de origem.

5.2 Estat´ısticas

Para alem´ da analise´ do desempenho dos algoritmos, e´ necessario´ que os resultados obtidos tenham uma base logica.´ Isto significa que os fluxos de ocorrenciasˆ devem estar directamente relacionados com eventos significativos que justifiquem o aumento de interesse e de not´ıcias.

5.2.1 Pesquisa regular

Como exemplo para a verificaçao˜ da validade deste tipo de pesquisa, vou analisar os resultados produzidos para a pesquisa pelo N-Grama Pedro Passos Coelho. Como se pode verificar na imagem apresentada, o numero´ de ocorrenciasˆ do N-Grama Pedro Passos Coelho atinge o primeiro pico em Maio de 2008, data correspondente a` primeira candidatura deste ao cargo de l´ıder de partido do PSD, com o segundo pico ocorre em Março de 2010, altura da sua eleiçao˜ a` liderança do PSD. O pico final no numero´ de ocorrenciasˆ e´ verificado em Maio de 2011, altura das eleiçoes˜ legislativas em Portugal que resultaram na eleiçao˜ de Pedro Passos Coelho a primeiro-ministro. Tendo Cap´ıtulo 5. Resultados 53

Figura 5.6: Publico´ N-Gram Search - Pedro Passos Coelho em conta os resultados obtidos e a sua relac¸ao˜ com os acontecimentos pol´ıticos, pode-se concluir que os resultados sao˜ coerentes com os eventos. Cap´ıtulo 5. Resultados 54

5.2.2 Pesquisa por Categoria

Ao se limitar a pesquisa de um N-Grama a uma categoria espec´ıﬁca, o resultado logico´ sera´ uma diminuic¸ao˜ das ocorrenciasˆ do N-Grama ao longo do per´ıodo de tempo. Como exemplo, consideremos o numero´ de ocorrenciasˆ do N-Grama Pedro Passos Coelho para a categoria de not´ıcias Economia.

Figura 5.7: Publico´ N-Gram Search Categoria - Pedro Passos Coelho

Como se pode verificar, pela linha azul, o numero´ de ocorrenciasˆ decresce significa- tivamente em comparaçao˜ com as ocorrenciasˆ resultantes da pesquisa regular. O numero´ de ocorrenciasˆ para este N-Grama acentua-se no per´ıodo entre 2010 e 2011, per´ıodo em que Pedro Passos Coelho e´ eleito l´ıder do partido PSD, a necessidade de Portugal recorrer a um resgate financeiro e as vitoria´ do PSD nas eleiçoes˜ legislativas, que levaram a` negociaçao˜ com o FMI. Como se pode verificar, os picos de ocorrenciasˆ para a categoria estao˜ de acordo com acontecimentos economicos´ relevantes, verificando-se assim a coerencia.ˆ Para os restantes algoritmos, dado que estes baseiam-se na avaliaçao˜ dos N-Gramas em termos de entidade e classe gramatical, uma analise´ relacional com base no numero´ de ocorrenciasˆ sera´ sempre semelhante a` realizada para a pesquisa regular, em que o numero´ de ocorrenciasˆ sera´ semelhante. Como exemplo, consideremos a seguinte imagem: Cap´ıtulo 5. Resultados 55

Figura 5.8: Publico´ N-Gram Search Classe Gramatical - Pedro Passos Coelho

Como se pode veriﬁcar, o padrao˜ descrito para o numero´ de ocorrenciasˆ e´ igual ao veriﬁcado para a pesquisa regular.

Cap´ıtulo 6

Conclusao˜

Este relatorio´ apresenta o trabalho realizado no ambitoˆ do desenvolvimento do Publico´ N-Gram Viewer (PNGV), um sistema de analise´ do numero´ de ocorrenciasˆ de N-Gramas obtidos atraves´ do processamento de um corpus de dez anos de not´ıcias do jornal Publico.´ Ao n´ıvel da criaçao˜ de uma soluçao,˜ os principais objectivos definidos inicialmente para esta tese foram a criaçao˜ de um cluster Hadoop para o processamento paralelo de ficheiros de corpus em N-Gramas e a criaçao˜ de uma interface Web que permitisse aceder aos dados estat´ısticos dos N-Gramas. Em termos de objectivos de analise,´ foi proposto o estudo da performance dos algoritmos MapReduce e dos resultados produzidos por estes. Tendo em conta os objectivos propostos para este projecto, os resultados foram:

• Desenvolvimento da plataforma PNGV: Este objectivo foi cumprido com sucesso. Ao n´ıvel do Back-End, criei um cluster Hadoop de duas maquinas´ que foi usado para o processamento dos dados. Desenvolvi igualmente quatro algoritmos MapRe- duce que sao˜ executados sobre o cluster e que sao˜ responsaveis´ pela transformaçao˜ do corpus em N-Gramas. Cada um dos algoritmos e´ responsavel´ pela construçao˜ dos dados usados para a realizaçao˜ de tipos distintos de pesquisas (pesquisa regular, pesquisa por categoria, pesquisa por entidade e pesquisa por classe gramatical). Para a interface da aplicaçao,˜ dado que esta e´ de natureza Web, decidi que a melhor maneira de aceder aos dados produzidos seria atraves´ de Web Services RESTful. Para a criaçao˜ destes recorri a` biblioteca Jersey. Relativamente a` construçao˜ da interface Web, tendo em conta os Web Services criados em Java, a soluçao˜ mais logica´ passou pela criaçao˜ de uma pagina´ JSP. Finalmente, de maneira a que a realizaçao˜ de pesquisas na aplicaçao˜ fosse feita sem que fosse necessario´ recarregar a pagina´ Web, usei AJAX para realizar pedidos aos Web Services.

• Analise´ dos algoritmos MapReduce e dos resultados produzidos. Este objectivo foi igualmente cumprido, tendo realizado uma analise´ a` performance de cada algoritmo MapReduce. Foram analisadas as funçoes˜ Map e Reduce de cada algoritmo, comparando os tempos de execuçao˜ da funçao˜ Map entre clusters de um e dois

57 Cap´ıtulo 6. Conclusao˜ 58

nos.´ Igualmente, analisei os resultados que foram produzidos pelos algoritmos de maneira a verificar a correspondenciaˆ de picos de interesse com eventos que jus- tificassem estes, tendo usado como exemplo as eleiçoes˜ legislativas. Ambas as analises´ confirmaram os seus presupostos. O acrescimo´ de nos´ ao cluster melhora a performance dos algoritmos e os resultados produzidos por estes estao˜ de acordo com eventos que justifiquem o aumento de interesse.

Concluindo, tendo em conta os objectivos definidos para esta tese, posso afirmar com segurança que estes foram cumpridos com sucesso. Igualmente, foram incluidas instruçoes˜ neste relatorio´ que permitem a replicaçao˜ do sistema, tanto ao n´ıvel da construçao˜ dos algoritmos MapReduce como ao n´ıvel da aplicaçao˜ Web que permite a visualizaçao˜ dos dados.

6.1 Trabalho Futuro

Os desenvolvimentos futuros estao˜ separados em duas categorias. A primeira consiste em melhorias a` implementaçao˜ actual, mais especificamente ao n´ıvel dos algoritmos desenvolvidos e do cluster Hadoop sobre o qual estes correm. A segunda categoria corresponde a implementaçoes˜ adicionais para a expansao˜ das funcionalidades ja´ existentes. Começando pelas melhorias ao n´ıvel das implementaçoes˜ ja´ presentes, a primeira melhoria seria a inclusao˜ de mais nos´ ao cluster de modo a acelarar o processamento dos algoritmos de analise´ de dados. Outra melhoria seria ao n´ıvel da aplicaçao˜ administrativa, tanto ao n´ıvel visual como ao n´ıvel de funcionalidades. Ao n´ıvel da inclusao˜ das funcionalidades, poderiam ser realizadas melhorias na representaçao˜ da evoluçao˜ do processamento de dados e da criaçao˜ de estruturas de dados. Relativamente a` implementaçao˜ Hadoop, dado que o NameNode e´ um single point of failure, a implementaçao˜ de um mecanismo de reinicializaçao˜ automatica´ poderia ser usada para resolver esta situaçao.˜ Finalmente, poderiam ser implementadas soluçoes˜ de segurança. Dado que os nos´ do cluster comu- nicam entre si atraves´ de chamadas RPC e HTTP sem uma componente de encriptaçao,˜ a informaçao˜ pode ser interceptada e manipulada (ataques ”eavesdropping”e ”man-in- the-middle”). Para evitar este tipo de ataques poderia ser implementado um metodo´ de autenticaçao˜ bi-lateral para a confirmaçao˜ das identidades dos componentes. Igualmente, poderia-se encriptar as estruturas de dados MapDB de modo a evitar que a informaçao˜ esteja acess´ıvel. Em relaçao˜ a acrescimos´ adicionais a` actual implementaçao,˜ acredito que haveria interesse em processar conjuntos de dados que estivem escritos em Portuguesˆ Brasileiro, com o objectivo de se analisar as diferenças lexicais atraves´ do numero´ de ocorrenciasˆ em cada tipo de Portugues.ˆ Bibliografia

[1] Alias-i. LingPipe. http://alias-i.com/lingpipe/index.html.

[2] Klaus Berberich and Srikanta Bedathur. Computing n-gram statistics in mapreduce. In Proceedings of the 16th International Conference on Extending Database Tech- nology, EDBT ’13, pages 101–112, New York, NY, USA, 2013. ACM.

[3] Klaus Berberich and Srikanta J. Bedathur. Computing n-Gram Statistics in MapRe- duce. CoRR, abs/1207.4371, 2012.

[4] Alex Boisvert Cees De Groot. JDBM2 - Embedded Key Value Java Database. http://code.google.com/p/jdbm2/.

[5] Thomas Jung Christian Grant Eleftherios Chetzakis Daniel Lemire, Daniel Ha- ran. External-Memory Sorting in Java. http://code.google.com/p/ externalsortinginjava/.

[6] Richard Dawkins. The Selﬁsh Gene. 1976.

[7] Jeffrey Dean and Sanjay Ghemawat. MapReduce: simpliﬁed data processing on large clusters. Commun. ACM, 51(1):107–113, January 2008.

[8] Joao˜ Tiago Lu´ıs dos Santos. Linking Entities to Wikipedia Documents. 2013.

[9] Tamer Elsayed, Jimmy Lin, and Douglas W Oard. Pairwise document similarity in large collections with mapreduce. In Proceedings of the 46th Annual Meeting of the Association for Computational Linguistics on Human Language Technologies: Short Papers, pages 265–268. Association for Computational Linguistics, 2008.

[10] Roy Thomas Fielding. Architectural styles and the design of network-based software architectures. PhD thesis, University of California, 2000.

[11] Apache Software Foundation. Apache Hadoop. http://hadoop.apache. org/.

[12] Apache Software Foundation. Apache Lucene. http://lucene.apache. org/.

59 Bibliograﬁa 60

[13] Google. Google Chart Tools. https://developers.google.com/ chart/.

[14] Google. Google ngram viewer. http://books.google.com/ngrams.

[15] The Stanford Natural Language Processing Group. Stanford log-linear part-of- speech tagger. http://nlp.stanford.edu/software/tagger.shtml.

[16] Apache Hadoop.

[17] Apache Hadoop. Mapper class api. http://hadoop.apache.org/docs/ stable/api/org/apache/hadoop/mapreduce/Mapper.html.

[18] Apache Hadoop. Reducer class api. http://hadoop.apache.org/docs/ stable/api/org/apache/hadoop/mapreduce/Reducer.html.

[19] Java. Jersey. http://jersey.java.net/.

[20] Jan Kotek. BTreeMap¡String, ArrayList¡Integer¿¿ performance issues which huge ArrayList¡Integer¿. https://groups.google.com/forum/#!topic/ mapdb/VYXt1KJn3N0.

[21] Jan Kotek. MapDB. https://github.com/jankotek/mapdb.

[22] Jure Leskovec, Lars Backstrom, and Jon Kleinberg. Meme-tracking and the dyna- mics of the news cycle. pages 497–506, 2009.

[23] Jimmy Lin. Scalable language processing algorithms for the masses: A case study in computing word co-occurrence matrices with mapreduce. In Proceedings of the Conference on Empirical Methods in Natural Language Processing, pages 419–428. Association for Computational Linguistics, 2008.

[24] Jimmy Lin and Chris Dyer. Data-intensive text processing with mapreduce. In Pro- ceedings of Human Language Technologies: The 2009 Annual Conference of the North American Chapter of the Association for Computational Linguistics, Com- panion Volume: Tutorial Abstracts, NAACL-Tutorials ’09, pages 1–2, Stroudsburg, PA, USA, 2009. Association for Computational Linguistics.

[25] Linguateca. Perl extension for NLP of the Portuguese. http://search.cpan. org/dist/Lingua-PT-PLNbase/lib/Lingua/PT/PLNbase.pm.

[26] MongoDB. http://www.mongodb.org/.

[27] Hohyon Ryu, Matthew Lease, and Nicholas Woodward. Finding and exploring memes in social media. pages 295–304, 2012.

[28] Tom White. Hadoop: The Definitive Guide. 2012. Bibliografia 61 Bibliografia 62 Apendiceˆ A

Anexos

Tokenizador da Linguateca public class LinguatecaTokenizerPT extends com.aliasi.tokenizer.RegExTokenizerFactory { /* * */ private static final long serialVersionUID = 1L; private static String regex ="(\\d+((/\\d+)+))"+"|"+/ ** dates or similar,e.g. 12/21/1 */ "(\\d+\\:\\d+(\\:\\d+)?)"+"|"+/ ** the time,e.g. 12:12:2 */ "(\\d+(([.]?[oaAôAâAˆ◦])+))"+"|"+/ ** ordinal numbers, e.g. 12.o */ "(\\d+(([.,]\\d+)*\\%?)?)"+"|"+/ ** numbers */ "(\\p{L}+(-\\p{L}+)+)"+"|"+/ ** tokens liked A¡˜ -lo-A˜ */ "(\\p{L}+\\’\\p{L}+)"+"|"+/ ** word connected by "’" */ "([\\p{L}_.-]+ ?\\@ ?[\\p{L}_.-]+\\p{L})"+"|"+/ ** emails */ "(\\p{L}+\\.?[AôAâAˆ◦]\\.?)"+"|"+/ ** ordinals */ "((((http(s?))|(ftp)|(gopher))://|www)[\\p{L}_./˜:-]+\\p{L})" +"|"+/ ** urls */ "(\\p{L}+\\.((com)|(org)|(net)|(pt))?)"+"|"+/ ** simplified urls */ "(\\\\\\\\unicode\\{\\d+\\})"+"|"+/ ** unicode */ "((\\p{L}+\\.(?:(exe)|(htm(l?))|(zip)|"+ "(jpg)|(gif)|(wav)|(mp3)|(png)|((t?)gz)|(pl)|(xml))))"+ "|"+/ ** filenames */ "(\\p{L}+)"+"|"+/ ** word characters */ "([\\.,;:\\?!])"+"|"+/ ** punctation */ "(\\bn\\.o)";/ ** number */ public LinguatecaTokenizerPT ( ) { super(regex); }

63 Apendiceˆ A. Anexos 64 public com.aliasi.tokenizer.Tokenizer tokenizer(String str) { return tokenizer(str.toCharArray(),0,str.length()); } public String[] tokenize(char[] cs, int start, int length) { com.aliasi.tokenizer.Tokenizer tokenizer = tokenizer(cs,start,length); return tokenizer.tokenize(); } public String[] tokenize(String str) { com.aliasi.tokenizer.Tokenizer tokenizer = tokenizer(str.toCharArray(),0,str.length()); return tokenizer.tokenize(); } }

Func¸ao˜ Map public static class Map extends Mapper { private Text ngram = new Text(); private Text date = new Text(); public void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { // Here we obtain the lines from the file with the news items String line = value.toString(); if (line.split("\\t").length == 5) { /* * The first thing to do is to obtain the date, * storing it in the variable date in the following * way: year_month */ String temp_date = line.split("\\t")[1]; date.set(temp_date.split("-")[0] +"_"+ temp_date.split("-")[1]);

// The next thing to do is to get the contents of the news article

//String article= line.split("\\t")[3]; //String title= line.split("\\t")[2];

/* * The title and contents of the news article * are emitted, leaving the tokenization process Apendiceˆ A. Anexos 65

* to the reduce function. */

for(int i = 3; i < line.split("\\t").length; i++) { ngram.set(line.split("\\t")[i]); context.write(date, ngram); } } } }

Func¸ao˜ Reduce public static class Reduce extends Reducer { private LinguatecaTokenizerPT tokenizerLinguateca = new LinguatecaTokenizerPT(); private TokenizerFactory tf = tokenizerLinguateca; private TokenizerFactory ntf = new TokenNGramTokenizerFactory(tf,1,5); public void reduce(Text key, Iterable values, Context context) throws IOException, InterruptedException {

String tempNgram ="";

/* * This is the data structure where theN-Grams and their * occurrences are stored for each individual date */ HashMap map = new HashMap();

/* * For every title and contents of news articles in the given date, * the Linguateca tokenizer is used to divide the text into N-Grams */ for (Text t : values) {

Tokenizer tz = ntf.tokenizer(t.toString().toCharArray(), 0, t.toString().length());

Iterator it = tz.iterator(); Apendiceˆ A. Anexos 66

while (it.hasNext()) {

while (it.hasNext()) { /* * If there isa case of words with connected punctuation, * this regex is used to remove it. * Example: * -> Before replace:"this is it." * -> After replace:"this is it" */ String ngram = it.next();

/* * In case theN-Gram is something like"the end. After" * Thesen-grams don’t need to be included since they don’t * make lexical sense */ if (!ngram.matches("(.*)\\w+[?:!.;]\\s(.*)")) {

tempNgram = ngram.replaceAll ("[?:!.,;]*([\\sa-z\\s]+)[?:!.,;]*", "$1").trim(); tempNgram = tempNgram.replaceAll ("\\s+","");// Remove double white spaces

/* * If then-gram is already in the hashmap, * the number of occurrences is incremented. * If not, then-gram is stored in the hashmap, * with the number of occurrences equals one. */ if (map.containsKey(tempNgram)) { IntWritable numberOccurrences = map.get(tempNgram); int occurrences = numberOccurrences.get(); occurrences++; Apendiceˆ A. Anexos 67

numberOccurrences.set(occurrences); map.remove(tempNgram); map.put(tempNgram, numberOccurrences); } else{ IntWritable numberOccurrences = new IntWritable(); numberOccurrences.set(1); map.put(tempNgram, numberOccurrences); } } } }

/* * After storing everyn-gram and their respective occurrences in the * hashmap, the next step is to createa string that contains * this information for the given date. * Example: * -> 2001_10 this isan-gram|5\tab this is another|2 \tab...... */ StringBuilder builder = new StringBuilder(); Set> set = map.entrySet();

Text ngram = new Text(); Text info = new Text();

Iterator> it2 = set.iterator();

while (it2.hasNext()) { Entry entry = it2.next();

builder.append(key.toString()); builder.append("\t"); builder.append(entry.getValue().get());

ngram.set(entry.getKey()); info.set(builder.toString());

it2.remove();

context.write(ngram, info);

builder.setLength(0); } Apendiceˆ A. Anexos 68

map.clear(); } } }

Alterac¸oes˜ no script hadoop-daemons

# New code, reading from a file the paths for each machine ficheiro="bin/paths" for LINE in ‘cat "$ficheiro"‘ do

IFS=";" k=0 declare -a arr2

#echo "A linha no paths: " $LINE for i in $LINE do arr2[$k]=$i k=$((k+1)) done nome_maquina=${arr2[0]} hadoop_casa=${arr2[1]} hadoop_config_dir=${arr2[2]}

#echo "Casa: $hadoop_casa" #echo "Conf dir: $hadoop_config_dir"

(exec "$bin/slaves.sh" --config $hadoop_config_dir --machine $nome_maquina cd "$hadoop_casa" \; "$hadoop_casa/bin/hadoop-daemon.sh" --config $hadoop_config_dir "$@" ) done Apendiceˆ A. Anexos 69

# Original code #echo "Hadoop home: " $HADOOP_HOME #echo "Hadoop conf dir: " $HADOOP_CONF_DIR #exec "$bin/slaves.sh" --config $HADOOP_CONF_DIR cd "$HADOOP_HOME" \; "$bin/hadoop-daemon.sh" --config $HADOOP_CONF_DIR "$@"

Alterac¸oes˜ no script slaves

# Old usage # usage="Usage: slaves.sh [--config confdir] command..."

# New usage usage="Usage: slaves.sh [--config confdir] [--machine machineName] command..."

# if no args specified, show usage if [ $# -le 0 ]; then echo $usage exit 1 fi bin=‘dirname "$0"‘ bin=‘cd "$bin"; pwd‘

# Nome da maquina (novo) nome_maquina="$4" echo "Nome da maquina:$nome_maquina"

# Pasta de origem (novo) pasta_home="$2" tamanho_caminho=${#pasta_home}-5 #echo "Pasta home:${pasta_home:0:$tamanho_caminho}" if [ -e "$bin/../libexec/hadoop-config.sh" ]; then . "$bin"/../libexec/hadoop-config.sh else . "$bin/hadoop-config.sh" fi Apendiceˆ A. Anexos 70

# If the slaves file is specified in the command line, # then it takes precedence over the definition in # hadoop-env.sh. Save it here. HOSTLIST=$HADOOP_SLAVES if [ -f "${HADOOP_CONF_DIR}/hadoop-env.sh" ]; then . "${HADOOP_CONF_DIR}/hadoop-env.sh" fi if [ "$HOSTLIST" = "" ]; then if [ "$HADOOP_SLAVES" = "" ]; then export HOSTLIST="${HADOOP_CONF_DIR}/slaves" else export HOSTLIST="${HADOOP_SLAVES}" fi fi

#echo "All parameters:" "${*:3}"

# New code for the ssh connection ssh $HADOOP_SSH_OPTS $nome_maquina "${*:3}" \ 2>&1 | sed "s/ˆ/$nome_maquina: /" & if [ "$HADOOP_SLAVE_SLEEP" != "" ]; then sleep $HADOOP_SLAVE_SLEEP fi

# Old code for the ssh connection #for slave in ‘cat "$HOSTLIST"|sed "s/#.*$//;/ˆ$/d"‘; do # echo "Slave value: $slave" # echo "Other value: " $"${@// /\\ }" # ssh $HADOOP_SSH_OPTS $slave $"${@// /\\ }" \ # 2>&1 | sed "s/ˆ/$slave: /" & # if [ "$HADOOP_SLAVE_SLEEP" != "" ]; then # sleep $HADOOP_SLAVE_SLEEP # fi #done wait