Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação Mestrado Acadêmico em Sistemas e Computação Identificação de dificuldades e questões de interesse de desenvolvedores de aplicações para Big Data com o framework Apache Spark Denis José Sousa de Albuquerque Natal-RN Setembro de 2019
119
Embed
Identificaçãodedificuldadesequestõesde ... · Apache Spark / Denis José Sousa de Albuquerque. - 2019. 117f.: il. Dissertação (mestrado) - Universidade Federal do Rio Grande
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra
Departamento de Informática e Matemática AplicadaPrograma de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Identificação de dificuldades e questões deinteresse de desenvolvedores de aplicações para
Big Data com o framework Apache Spark
Denis José Sousa de Albuquerque
Natal-RN
Setembro de 2019
Denis José Sousa de Albuquerque
Identificação de dificuldades e questões de interesse dedesenvolvedores de aplicações para Big Data com o
framework Apache Spark
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.
Linha de pesquisa:Linguagens de Programação e Métodos For-mais
Orientador
Prof. Dr. Umberto Souza da Costa
PPgSC – Programa de Pós-Graduação em Sistemas e ComputaçãoDIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da TerraUFRN – Universidade Federal do Rio Grande do Norte
Natal-RN
Setembro de 2019
Albuquerque, Denis José Sousa de. Identificação de dificuldades e questões de interesse dedesenvolvedores de aplicações para Big Data com o frameworkApache Spark / Denis José Sousa de Albuquerque. - 2019. 117f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grandedo Norte, Centro de Ciências Exatas e da Terra, Programa de Pós-Graduação em Sistemas e Computação. Natal, 2019. Orientador: Umberto Souza da Costa.
1. Computação - Dissertação. 2. Big Data - Dissertação. 3.Apache Spark - Dissertação. 4. Modelagem de tópicosprobabilística - Dissertação. 5. Latent Dirichlet Allocation(LDA) - Dissertação. 6. Stack Overflow - Dissertação. 7.Taxonomia - Dissertação. I. Costa, Umberto Souza da. II. Título.
RN/UF/CCET CDU 004
Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Elaborado por Joseneide Ferreira Dantas - CRB-15/324
Dedico este trabalho à Maria Lúcia (mãe), Mirella (esposa) e Alice (filha).
Agradecimentos
Agradeço à minha esposa, Mirella Albuquerque, pelo apoio em todos os momentos.
Aos amigos Roberta Freitas e João Batista pelas inúmeras contribuições.
Ao professor Dr. Martin Musicante pelas valiosas e sempre bem-humoradas colabora-
ções.
Ao meu orientador, Prof. Dr. Umberto Costa, pela oportunidade, confiança, ensina-
mentos e paciência.
Este trabalho não seria possível sem a participação de vocês.
Obrigado.
Identificação de dificuldades e questões de interesse dedesenvolvedores de aplicações para Big Data com o
framework Apache Spark
Autor: Denis José Sousa de Albuquerque
Orientador: Prof. Dr. Umberto Souza da Costa
Resumo
Este trabalho de pesquisa busca identificar e classificar as principais dificuldades e questões
de interesse dos desenvolvedores de aplicações para o processamento de Big Data utili-
zando o framework Apache Spark. Nesse sentido, utilizamos o algoritmo Latent Dirichlet
Allocation para realizar a modelagem probabilística de tópicos em informações extraí-
das do Stack Overflow, uma vez que não é viável a inspeção manual de todo o conjunto
de dados. A partir do conhecimento obtido pelo estudo abrangente de trabalhos rela-
cionados, estabelecemos e aplicamos uma metodologia baseada nas práticas usualmente
empregadas. Construímos aplicações Spark para execução automatizada das tarefas, tais
como a seleção e preparação dos dados, o agrupamento de tópicos – aplicação do algo-
ritmo de modelagem probabilista para várias configurações – e a computação de métricas.
Análises sobre os resultados obtidos foram conduzidas por um grupo composto por 5 pes-
quisadores: dois professores doutores, um aluno doutorando e dois alunos mestrandos. A
partir da análise semântica dos rótulos atribuídos para cada um dos tópicos identificados,
uma taxonomia de interesses e dificuldades foi construída. Por fim, estabelecemos um
ranqueamento dos temas mais importantes de acordo com as várias métricas calculadas
e comparamos os métodos e resultados de nosso estudo com os apresentados em outro
trabalho.
Palavras-chave: Big Data, Apache Spark, modelagem de tópicos probabilística, Latent
O grande volume de dados disponível nos dias atuais tem criado novos desafios e
oportunidades. O termo Big Data é frequentemente utilizado para referir-se a grandes
conjuntos de dados (datasets) que crescem rapidamente e possivelmente contém dados em
diversos formatos. Um ambiente de computação distribuída é normalmente necessário para
processar o Big Data, uma vez que o grande volume de dados pode exceder as capacidades
de armazenamento e processamento de uma única máquina. Neste cenário, é necessário
que os desenvolvedores de software tratem questões difíceis como o particionamento dos
dados, a distribuição da computação e o tratamento das falhas que ocorrem de forma
muito mais complexa.
Vários esforços de pesquisa foram realizados com objetivo de ajudar os desenvolve-
dores no enfrentamento da complexidade de sistemas distribuídos. Conforme declarado
por Ranganathan e Campbell (2007), os desenvolvedores geralmente enfrentam grandes
curvas de aprendizagem antes que possam iniciar a programação de um grande sistema
distribuído. Nesse sentido, o uso de tecnologias bem estabelecidas – como, por exemplo, a
linguagem de consulta SQL (Structured Query Language) – pode ajudar nesse processo,
uma vez que os desenvolvedores serão capazes de utilizar seu conhecimento prévio, bem
como já existe uma grande quantidade de material educacional disponível.
Frameworks de programação têm sido propostos para ajudar os desenvolvedores de
sistemas distribuídos (RANGANATHAN; CAMPBELL, 2007). Um exemplo de framework é
o Apache Spark1 que foi lançado em 2010 e tem sido adotado por muitas organizações,
tornando-se o mais ativo projeto de código aberto para processamento de Big Data, com
mais de 1.200 pessoas que contribuíram para o projeto (XIN, 2018).
Spark é um framework de computação em cluster – um conjunto de computadores
que compartilham seus recursos e trabalham como um único sistema – para o desenvol-
vimento de aplicações de processamento de dados com grande escalabilidade e tolerância1https://spark.apache.org
14
a falhas (ZAHARIA et al., 2010). Utilizando Spark, os desenvolvedores escrevem programas
que implementam operações em alto-nível, utilizando alguma das linguagens de progra-
mação suportadas (Java, Scala, Python ou R), enquanto que o framework trata boa parte
das complexidades relacionadas a distribuição dos dados e da computação. Usuários do
Spark também podem fazer uso de um conjunto de bibliotecas que proveem uma grande
variedade de funcionalidades, incluindo a biblioteca Spark SQL para o processamento de
dados relacionais, MLlib para algoritmos de aprendizagem de máquina, GraphX para o
manipulação de grafos e Spark Streaming para o processamento de fluxos contínuos de
dados.
No contexto do processamento de dados, a linguagem SQL e os RDBMS (Sistemas
Gerenciadores de Bancos de Dados Relacionais, do inglês Relational Database Manage-
ment Systems) têm sido bastante utilizados. A popularidade de SQL é uma evidência que
desenvolvedores preferem utilizar consultas declarativas para o processamento de dados.
Entretanto, de acordo com Armbrust et al. (2015b), a abordagem estritamente relacional
utilizando SQL é insuficiente para muitas aplicações de Big Data, tais como aquelas que
empregam algoritmos de aprendizagem de máquina e processamento de grafos. Spark,
mediante uso da biblioteca Spark SQL, busca permitir o uso combinado tanto de con-
sultas declarativas relacionais quanto de algoritmos procedimentais imperativos. Spark
SQL estende Spark com APIs (Interface de Programação de Aplicativos, do inglês Ap-
plication Programming Interface) construídas para prover um ambiente integrado e de
fácil uso. Segundo Armbrust et al. (2015b), benchmarks e feedbacks de usuários mostram
que Spark SQL torna significativamente mais simples e eficiente a escrita de pipelines de
processamento de dados que misturam o processamento relacional e o procedural.
Apesar do suporte oferecido pelas bibliotecas, a implementação de uma aplicação para
processamento de Big Data utilizado Spark não é uma tarefa trivial. Considerando que
os desenvolvedores geralmente recorrem à sistemas de perguntas e respostas disponíveis
na Internet para sanar dúvidas, este trabalho propõe a identificação e classificação das
questões comumente enfrentadas por programadores Spark no desenvolvimento dessas
aplicações.
Dentre as plataformas de perguntas e respostas, o maior exemplo é o Stack Overflow2
que, com mais de 18 milhões de perguntas e mais de 28 milhões de respostas registradas3,
tornou-se um grande e popular repositório de conhecimento relacionado ao desenvolvi-
mento de softwares. Isso faz com que ele seja uma importante fonte de dados para apren-2https://stackoverflow.com3Dados de agosto de 2019 obtidos em https://data.stackexchange.com
15
der sobre as dificuldades e interesses dos desenvolvedores. No que diz respeito a Spark,
atualmente conseguimos identificar mais de 49 mil perguntas cadastradas no Stack Over-
flow. Entretanto, para analisar grandes volumes de dados, precisamos utilizar técnicas
computacionais que sumarizem as informações, tais como a modelagem de tópicos (BLEI,
2012a).
A modelagem de tópicos busca identificar os assuntos tratados em um conjunto de
documentos. Em geral, algoritmos de modelagem de tópicos são utilizados para descobrir
a estrutura temática dos documentos de uma grande coleção, para que posteriormente
seja possível organizá-los, sumarizá-los, visualizá-los, etc (BLEI, 2012a). O Latent Dirichlet
Allocation é a técnica mais frequentemente utilizada para modelagem de tópicos (TREUDE;
WAGNER, 2018). Trata-se de algoritmo para modelagem probabilística de tópicos que
emprega métodos estatísticos pelos quais busca-se inferir os assuntos (tópicos) abordados
em um conjunto de documentos a partir das palavras que o compõem. Discutiremos essa
técnica com mais detalhes na Seção 2.3.
Dessa forma, este trabalho propõe identificar as dificuldades e interesses de desenvol-
vedores relacionadas ao desenvolvimento de aplicações para o processamento de grandes
volumes de dados utilizando o Apache Spark. Esperamos alcançar esse resultado através
da extração de conhecimento – a partir de perguntas e respostas feitas por desenvolvedores
Spark – da plataforma Stack Overflow. Acreditamos que esse trabalho revele observações
interessantes acerca dos desafios encontrados pelos desenvolvedores Spark, sendo estas
informações úteis não somente para os desenvolvedores de aplicações, mas também para
pesquisadores, educadores e os próprios criadores do framework. Considerando a enorme
quantidade de documentos a serem estudados, o que inviabiliza sua inspeção, análise e
síntese manual, recorreremos ao auxílio de técnica de modelagem probabilística de tópicos.
1.1 Objetivos
O objetivo principal desta pesquisa é o de identificar e classificar as principais difi-
culdades e interesses de desenvolvedores de aplicações para o processamento de Big Data
utilizando o framework Apache Spark.
Propomos uma taxonomia construída a partir da modelagem probabilística de tópicos
aplicada sobre dados extraídos da plataforma Stack Overflow. Avaliar como a modelagem
probabilística de tópicos pode ser utilizada na construção de uma hierarquia de assuntos
é um objetivo secundário deste trabalho.
16
O estudo detalhado dos trabalhos de pesquisa que aplicaram o algoritmo Latent Diri-
chlet Allocation para modelagem probabilística de tópicos em datasets extraídos do Stack
Overflow é outro objetivo secundário deste trabalho. Esse estudo é importante para iden-
tificar como o algoritmo foi aplicado e parametrizado, além de indicar como os dados de
entrada foram preparados e como os resultados obtidos foram analisados.
Para identificação das questões mais importantes, objetivamos também ranquear os
tópicos a partir de diversas métricas relacionadas a frequência de ocorrência das questões
e de sua popularidade na plataforma de perguntas e respostas.
1.2 Motivação
Embora exista uma boa quantidade de documentação sobre o Apache Spark, os pro-
gramadores frequentemente recorrem a plataformas de perguntas e respostas para sanar
dúvidas e encontrar ajuda no desenvolvimento de aplicações para processamento de Big
Data. É necessário identificar sistematicamente as dificuldades frequentemente encontra-
das por esses desenvolvedores para melhor ajudá-los.
Taxonomias são ferramentas úteis para organização do conhecimento na medida em
que proveem uma estrutura hierárquica que facilita a classificação e o acesso ao conhe-
cimento. Uma taxonomia de interesses e dificuldades frequentemente enfrentadas pelos
desenvolvedores pode ser um passo chave para endereçar os problemas de forma sistemá-
tica. Em nosso cenário, a taxonomia de interesses e dificuldades pode ser utilizada para
categorizar os tipos de problemas e apontar estratégias de intervenção apropriadas. Por
exemplo, ela poderia ser utilizada para produzir guias de práticas de desenvolvimento,
com recomendações para a melhoria da qualidade de aplicações Spark e diminuição da
quantidade de problemas enfrentados durante o desenvolvimento das aplicações.
Ainda, esse entendimento é útil não somente para os desenvolvedores, mas também
para as comunidades de educadores e de pesquisadores que podem utilizar esse conheci-
mento para decidir onde concentrar seus esforços.
1.3 Contribuições
Este trabalho apresenta as seguintes contribuições:
1. Identificação das principais questões relacionadas ao desenvolvimento de aplicações
17
para o processamento de Big Data utilizando o framework Apache Spark;
2. Computação de oito métricas, onde uma delas é uma nova métrica proposta neste
trabalho, para ranqueamento dos tópicos identificados;
3. Uma taxonomia de dificuldades e interesses de desenvolvedores construída a partir
de dados do Stack Overflow;
4. Estudo sistemático e detalhado dos trabalhos de pesquisa que aplicaram o Latent
Dirichlet Allocation para a modelagem probabilística de tópicos em datasets do
Stack Overflow;
5. Implementação e disponibilização de uma Aplicação Spark de código aberto para
aplicação de modelagem probabilística de tópicos sobre dados do Stack Overflow.
1.4 Organização do Documento
O restante deste documento segue a seguinte organização:
• No Capítulo 2 apresentamos uma revisão bibliográfica com os conceitos necessários
ao entendimento e desenvolvimento deste trabalho;
• No Capítulo 3 discutimos em detalhes os trabalhos relacionados a este, apresentando
os métodos, técnicas e métricas utilizadas neles. O conhecimento obtido a partir do
estudo dos trabalhos relacionados serão aplicados na condução de experimentos para
obtenção de dados necessários para alcançar nossos objetivos;
• O Capítulo 4 discorre sobre a metodologia concebida para esse estudo, bem como
sobre os experimentos realizados.
• No Capítulo 5 apresentamos os resultados obtidos a partir da modelagem de tópicos,
a taxonomia de dificuldades e interesses de desenvolvedores, a identificação dos
principais assuntos relacionados ao uso do Apache Spark;
• O Capítulo 6 encerra o documento com as considerações finais, contribuições do
estudo e propostas de trabalhos futuros.
18
2 Revisão Bibliográfica
Neste Capítulo apresentamos uma revisão bibliográfica acerca dos conceitos necessá-
rios ao entendimento e desenvolvimento deste trabalho. Na Seção 2.1 conceituaremos o
Big Data e as razões que levaram à construção de frameworks como o Apache Spark. O
funcionamento e arquitetura do framework Apache Spark será abordado em detalhes na
Seção 2.2. A modelagem de tópicos e o algoritmo Latent Dirichlet Allocation serão trata-
dos na Seção 2.3. Por fim, apresentamos informações sobre a plataforma Stack Overflow
na Seção 2.4.
2.1 Big Data
O termo Big Data popularizou-se nos últimos anos devido a natureza pervasiva das
tecnologias digitais e da grande variedade de aplicações baseadas em dados (MAURO;
GRECO; GRIMALDI, 2016). Segundo Hilbert e López (2011), a quantidade de dados ar-
mazenados têm crescido exponencialmente. Talvez por ser algo novo, a conceituação do
Big Data muitas vezes é imprecisa, com várias definições encontradas na literatura. O
termo pode dar a impressão de estar relacionado apenas a grandes volumes de dados,
entretanto seu uso também se refere à outras características dos dados, tais como sua va-
riedade e a velocidade em que são gerados. Buscando estabelecer um consenso a cerca de
uma definição precisa, Mauro, Greco e Grimaldi (2016) estudaram a literatura científica
e propuseram a seguinte definição:
Big Data representa os ativos de informação caracterizados por tão grandevolume, velocidade e variedade que requerem tecnologias e métodos ana-líticos específicos para sua transformação em valor (MAURO; GRECO;GRIMALDI, 2016). .
Extrair valor do Big Data não é uma tarefa simples, pois envolve a análise de dados
heterogêneos e desestruturados que crescem em um ritmo tão acelerado que os Sistemas
Gerenciadores de Bancos de Dados e as ferramentas de análise tipicamente utilizadas não
19
estão preparadas para o seu gerenciamento. Por essa razão, o Big Data criou oportunida-
des para o surgimento de novas técnicas e sistemas capazes de tratá-lo. Nesse tratamento:
(i) a variedade dos dados demanda sistemas que possam acomodar eficientemente dados
em formatos estruturados e desestruturados; (ii) a velocidade em que os dados são gera-
dos demanda sistemas com capacidades de processamento próximo do tempo real; (iii) o
grande volume de dados é um aspecto que, para ser gerenciado, precisa de arquiteturas
distribuídas e escaláveis.
Nesse sentido, modelos de programação e frameworks foram desenvolvidos para pro-
mover o uso de clusters (grupos de computadores que compartilham recursos de hardware)
na realização de computações de forma paralela e distribuída. Apache Hadoop1 é um im-
portante exemplo de solução para Big Data. Ele é um framework para o processamento
distribuído de grandes conjuntos de dados em clusters usando um modelo de programação
MapReduce é um modelo de programação idealizado pelo Google que foi projetado
para processar paralelamente, com alta escalabilidade e tolerância a falhas, grandes quan-
tidades de dados em clusters de computadores comuns (DEAN; GHEMAWAT, 2008). Esse
modelo é baseado na aplicação de duas funções: map e reduce. A função map transforma
os dados de entrada para gerar um conjunto intermediário de dados em formato específico
e a função reduce combina esses resultados intermediários para obter valores agregados.
Um programa MapReduce executa essas funções em sequência, sendo bastante útil para o
processamento de dados em lote, onde os dados são manipulados de forma sequencial. A
ideia geral não é nova, ela é desde muito tempo utilizada em linguagens de programação
funcional como LISP. A novidade do MapReduce é a abordagem da implementação da
infraestrutura que abstrai grande parte da complexidade da paralelização e da distribui-
ção da computação, permitindo que o usuário programador se concentre na construção
das funcionalidades de alto nível do programa.
Embora o modelo MapReduce tenha se provado bastante útil e popular, ele não é
adequado para certos casos de uso, havendo críticas ao modelo na literatura. De acordo
com Bonner et al. (2017), os críticos ao MapReduce argumentam que o modelo possui
funcionalidade limitada, que sua API ainda é de baixo nível e que ele necessita de clusters
dedicados. Segundo Zaharia et al. (2012), o MapReduce não é eficiente para casos de uso
onde haja a necessidade de realizar trabalhos não sequenciais em que sejam realizadas
várias passagens sobre os mesmos dados, como é comum em algoritmos de aprendizagem1https://hadoop.apache.org
20
de máquina, por exemplo. Quando comparado com outras abordagens, tais como o uso
de RDBMS e da linguagem SQL, MapReduce oferece funcionalidades restritas e usabi-
lidade bastante dificultada. Operações comuns e simples na abordagem relacional como,
por exemplo, joins são complicadas de se expressar em programas MapReduce, sendo
geralmente necessário o uso de soluções mais sofisticadas e complexas. Para Chambers e
Zaharia (2018), construir grandes aplicações com MapReduce é desafiador e ineficiente.
Um grupo de pesquisadores da Universidade de Berkeley2 idealizou o framework Spark
com o objetivo de ser um modelo de computação para Big Data, com grande desempenho,
alta escalabilidade, tolerância a falhas e alternativo ao MapReduce, não apresentando
as desvantagens relativas ao processamento paralelo de múltiplas operações sobre um
mesmo conjunto de dados. Spark foi projetado para fornecer um modelo de computação
de propósito mais geral que o MapReduce e que pudesse ser executado de forma muito
eficiente em clusters. De acordo com Zaharia et al. (2010), em comparação com o Hadoop,
Spark pode melhorar em dez vezes o desempenho de aplicações iterativas.
2.2 Apache Spark
Spark é um framework que fornece um motor de computação e um conjunto de bibli-
otecas para o processamento paralelo de dados em clusters de computadores (CHAMBERS;
ZAHARIA, 2018). Spark foi lançado em 2010 como um software de código aberto3 e se
tornou o projeto para Big Data mais ativo da atualidade, com mais de 1300 contribui-
dores ao seu repositório de código-fonte4. De acordo com dados do Google (Figura 1), o
interesse por Spark tem crescido de forma considerável nos últimos anos.
Figura 1: Interesse pelos frameworks Spark e Hadoop de acordo com Google Trends5.
Empregando um modelo de computação com menos restrições que o MapReduce,2https://amplab.cs.berkeley.edu3https://github.com/apache/spark4https://github.com/apache/spark/graphs/contributors5https://trends.google.com.br
21
Spark permite que seus usuários construam e combinem eficientemente diferentes tipos de
cargas de trabalho, tais como: processamento sequencial de dados em lotes; processamento
de streaming de dados próximo ao tempo-real; consultas interativas; transformações itera-
tivas de dados para algoritmos de aprendizagem de máquina. De acordo com Bonner et al.
(2017), Spark apresenta três vantagens em relação ao MapReduce: (i) a criação dos pro-
gramas de usuários é menos complicada e requer menos linhas de código; (ii) a API mais
rica em funcionalidades e expressividade facilita a construção de algoritmos complexos;
(iii) computações serão realizadas em menos tempo devido ao ganho de desempenho.
Segundo Zaharia et al. (2010), Spark foi inicialmente criado para tratar a ineficiência
do modelo MapReduce em dois tipos de aplicações:
• Trabalhos iterativos: muitos algoritmos de aprendizagem de máquina aplicam fun-
ções repetidamente sobre um mesmo conjunto de dados. Apesar de ser possível
expressar essa computação como um trabalho MapReduce, cada trabalho neces-
sita carregar os dados do disco rígido, resultando em uma perda de desempenho
significante.
• Análise exploratória de dados: consultas em grandes conjuntos de dados em ambien-
tes Hadoop são frequentemente realizadas por meio de interfaces SQL tais como Pig6
e Hive7. Essas queries em Hadoop resultam em latências significantes porque são
executadas como trabalhos MapReduce separados, necessitando de muitas leituras
no disco rígido.
As funcionalidade de Spark são utilizadas por meio de APIs disponíveis para as lin-
guagens de programação Java, Scala, Python e R. Em constante evolução, Spark permite
a integração com diversas soluções de armazenamento distribuído de dados (Hadoop Dis-
tributed File System – HDFS, Cassandra8, HBASE9, Amazon S310, etc) e gerenciadores de
clusters (Hadoop YARN, Apache MESOS11, Spark Standalone). Usuários também podem
utilizar e combinar diversas bibliotecas que proveem um amplo conjunto de funcionalida-
des, incluindo as bibliotecas Spark SQL para o processamento de dados relacionais, MLlib
para algoritmos de aprendizagem de máquina, GraphX para o processamento de grafos,
Spark Streaming para o processamento de fluxos de dados contínuos, além de centenas6https://pig.apache.org7https://hive.apache.org8https://cassandra.apache.org9https://hbase.apache.org
de outras bibliotecas desenvolvidas por sua comunidade de usuários12. A Figura 2 ilustra,
em camadas, as tecnologias citadas que podem compor uma aplicação Spark.
Figura 2: Pilha de tecnologias envolvidas em uma aplicação Spark.
O modelo de computação de Spark se baseia no processamento de dados em memó-
ria principal que é realizado mediante funcionalidades expostas pela API da abstração
denominada RDD (Conjunto de Dados Distribuídos e Resilientes, do inglês Resilient Dis-
tributed Dataset). RDD é uma representação dos dados carregados pela aplicação Spark
na memória principal da máquina. Ele forma uma coleção de objetos Java que podem ser
distribuídos e manipulados em paralelo. Uma grande parte de Spark é construído sobre a
abstração de RDDs e mais detalhes sobre eles são apresentados na Seção 2.2.1.
Uma típica aplicação Spark é formada pelo programa do usuário (Driver), um geren-
ciador de recursos do cluster e nós trabalhadores (Workers). A Figura 3 ilustra esses com-
ponentes. A aplicação Spark executa um conjunto independente de processos coordenados
por um objeto (SparkContext) contido no Driver. Mais especificamente, o SparkContext
se comunica com o gerenciador do cluster de forma a obter os recursos computacionais
necessários para a execução das aplicações. O Driver é o ponto de entrada da aplicação.
Ele é responsável por mapear todas as operações sobre RDDs em um conjunto de tarefas
(Tasks) que formam um DAG (Grafo Acíclico Dirigido, do inglês Directed Acyclic Graph)
de dependências entre as operações. Essas tarefas são executadas por processos denomi-
nados executores (Executors) que rodam em nós trabalhadores (Workers) do cluster.
Executores recebem as tarefas do Driver, executam as operações requeridas sobre os12https://spark-packages.org13Adaptado da documentação de Spark em https://spark.apache.org/docs/latest/
cluster-overview.html
23
Figura 3: Componentes de uma aplicação Spark13.
dados e eventualmente retornam o resultado da computação para o Driver. Os processos
executores são JVMs (Máquina Virtual Java, do inglês Java Virtual Machine) que perma-
necem ativas durante todo o tempo de vida da aplicação e executam as tarefas por meio
de diferentes threads.
O Driver e os Executores se comunicam regularmente durante a execução da aplicação
para a execução das operações definidas no DAG, bem como para o reagendamento de
tarefas para outros nós do cluster em caso de falhas. Segundo estudo realizado por Shi
et al. (2015), com essa arquitetura e abstrações, Spark alcançou vantagens consideráveis,
especialmente em tarefas iterativas, em comparação com o projeto original do Hadoop
MapReduce.
2.2.1 Resilient Distributed Dataset (RDD)
RDD é uma abstração para uma memória distribuída que permite aos usuários a sua
manipulação de forma paralela por meio de um rico conjunto de operadores (ZAHARIA et
al., 2012). Essa abstração torna o particionamento das estruturas de dados, seu armaze-
namento e a sua manipulação paralela transparentes ao usuário Spark, permitindo que a
programação da aplicação seja tratada em mais alto nível. O nome RDD advém de três
características:
1. Resiliente (Resilient): RDDs são tolerantes a falhas, eles podem ser recriados em
caso de problemas nos nós do cluster ;
24
2. Distribuído (Distributed): os RDDs são particionados e distribuídos, podendo residir
em diferentes nós do cluster ;
3. Conjunto de dados (Dataset): RDDs armazenam uma coleção de dados que podem
ser representados em memória por tipos primitivos ou quaisquer outros objetos Java.
RDDs são implementados como uma coleção de objetos imutáveis que podem ser
recriados em caso de problemas, tornando a aplicação Spark tolerante a falhas. As opera-
ções disponíveis na API dos RDDs podem ser classificadas em duas categorias distintas:
transformações e ações.
As transformações são operações voltadas para a manipulação dos dados. Como os
RDDs são imutáveis, as transformações, ao invés de modificarem o RDD, criam novos
RDDs transformados. As operações rdd.map(function) e rdd.reduceByKey(function)
são exemplos de transformações para, respectivamente, aplicar uma função em todos os
elementos de um RDD e agregar elementos usando uma função de redução de elementos no
formato de pares (chave, valor). Essas transformações são preguiçosas (lazy), no sentido
de que o resultado da operação será computado sob demanda. Na verdade, o programa
Driver armazena a linhagem da sequência de transformações (um plano de execução
em forma de um DAG) que serão aplicadas sobre o conjunto de dados. Dessa forma, a
aplicação mantém o controle sobre todas as dependências entre os RDDs e esse plano de
transformações é executado apenas quando uma operação do tipo ação é chamada. Além
disso, é o histórico de transformações desses planos que será utilizado para reconstruir
RDDs em casos de falhas.
As ações são operações executadas sobre RDDs com objetivo de computar valores e
retorná-los para o Driver. Elas são gatilhos para iniciar a execução do plano das transfor-
mações que irão processar os dados. Adotando a estratégia de adiar as transformações para
somente quando seu resultado for necessário – para somente quando uma ação for cha-
mada – Spark pode realizar otimizações no plano de transformações, como, por exemplo,
combinar operações para evitar a necessidade de materialização de resultados intermediá-
rios e, dessa forma, executar o programa mais eficientemente. As operações rdd.count()
e rdd.collect() são exemplos de ações para, respectivamente, a contagem da quanti-
dade de elementos de um RDD e o retorno ao Driver de um array que contém todos os
elementos do RDD.
A Figura 4 ilustra um programa Spark simples que, por meio de transformações e
ações, realiza a contagem de cada uma das palavras de um texto. O programa realiza:
25
(1) a leitura do arquivo texto, usando o método do objeto SparkContext que retorna um
RDD com a coleção de linhas do texto; (2) a divisão de cada linha em seus termos; (3) a
transformação de cada termo em uma tupla (chave, valor), onde a chave é o próprio termo
e o valor é a constante 1; (4) agregação das tuplas pela chave com a soma acumulada das
respectivas constantes; (5) retorno do resultado que é um array de tuplas (chave, valor)
cuja chave é o termo e o valor é a frequência de ocorrência do termo no texto.
Figura 4: Transformações e ações para contagem das palavras de um arquivo texto.
As transformações e ações disponíveis para os RDDs constituem a chamada Spark
Core API. De forma a possibilitar maior usabilidade e expressividade em vários contextos,
Spark provê adicionalmente outra API de mais alto nível que foi construída com base na
API Core. De fato, a partir de sua versão 2.0, lançada em 26 de julho de 2016, o projeto
Spark passou a encorajar que seus usuários não mais adotassem primariamente a API
RDD na programação de suas aplicações. A recomendação atual é que os usuários utilizem
principalmente a API conhecida como Dataframe.
2.2.2 Dataframes
Grande parte dos Sistemas de Informações desenvolvidos para manipulação de bases
de dados utiliza a linguagem SQL. SQL é uma linguagem declarativa – declara o que deve
ser feito, não como fazê-lo – originalmente desenvolvida pela IBM em 1970 para servir
26
de interface para bancos de dados relacionais. Atualmente, a linguagem é empregada
em muitos outros casos de uso, sendo também muito utilizada por cientistas de dados e
usuários de sistemas de Business Intelligence para examinar dados interativamente.
Em razão da popularidade de SQL, existe uma forte demanda pela incorporação
de interfaces relacionais em frameworks para processamento de Big Data. Nesse sentido,
novas tecnologias como Hive, Pig, Drill 14, Impala 15 e outras foram criadas como forma de
fornecer uma experiência de uso mais amigável e produtiva na medida em que possibilita
a execução de consultas relacionais. No que diz respeito a Spark, aplicações podem fazer
uso de SQL por meio de funcionalidades da biblioteca Spark SQL, um componente de
Spark que teve origem no projeto Shark16 (XIN et al., 2013). De acordo com Xin (2018),
Spark SQL foi projetado para atender os seguintes requisitos:
1. API amigável para o programador com suporte ao processamento relacional;
2. Alto desempenho utilizando técnicas já empregadas e bem estabelecidas em sistemas
gerenciadores de bancos de dados relacionais;
3. Suporte fácil a novas fontes de dados, incluindo dados semi-estruturados e bancos
de dados externos;
4. Extensão com algoritmos analíticos avançados tais como processamento de grafos e
aprendizagem de máquina.
Spark SQL é executado como uma camada sobre a API (RDDs) do Spark Core,
provendo aos seus usuários uma interface (Dataframe) para operação relacional de dados
estruturados, conforme ilustrado de forma simplificada na Figura 5, cujos elementos serão
explicados nesta Seção.
Spark SQL introduziu a nova abstração chamada Dataframe que permite a seus usuá-
rios utilizarem tanto consultas relacionais declarativas quanto algoritmos procedimentais
em uma mesma aplicação. De acordo com Armbrust et al. (2015b), a utilização apenas
da abordagem relacional é insuficiente para várias das aplicações de Big Data, como, por
exemplo, as aplicações que envolvem processamento de grafos e aprendizagem de má-
quina. Xin (2018) afirma que as duas classes de sistemas – relacionais e procedurais –
permaneciam até então bastante disjuntas, forçando o usuário a escolher um paradigma14https://drill.apache.org15https://impala.apache.org16https://shark.cs.berkeley.edu
27
Figura 5: APIs de Spark e Spark SQL. Adaptado de (ARMBRUST et al., 2015b).
em detrimento do outro. A API DataFrame foi então projetada para permitir a fácil in-
tegração relacional/procedimental em programas Spark. Além disso, o módulo Catalyst
foi concebido para otimização de consultas e geração de código, realizando otimizações
baseadas em regras e em custos, semelhantemente as otimizações realizadas por RDBMS.
Dataframes são conjuntos distribuídos de dados organizados estruturalmente em co-
lunas. Eles são conceitualmente semelhantes à tabelas em bancos de dados relacionais,
onde cada objeto do Dataframe representa uma linha da tabela. Além de facilitar o de-
senvolvimento de aplicações, o uso da API Dataframe resulta em melhor desempenho em
razão das possibilidades de otimizações automáticas (ARMBRUST et al., 2015b).
Ao contrário dos RDDs, Dataframes mantêm o registro do esquema dos dados, per-
mitindo que Spark realize otimizações automáticas ao explorar essa estrutura. Segundo
Armbrust et al. (2015a), ainda que as otimizações aplicadas em nível de RDDs sejam
extremamente úteis, elas são limitadas porque as estruturas de dados contidos nos RDDs
e as funções dos usuários são opacas, ou seja, o otimizador não possui as informações
semânticas necessárias para otimizações mais avançadas. Segundo Xin (2018), Datafra-
mes são mais convenientes e eficientes que RDDs em situações como, por exemplo, a
computação de múltiplos valores agregados utilizando declarações SQL, algo que é difícil
de se expressar com a API dos RDDs. Além disso, Dataframes armazenam os dados na
memória em um formato colunar que é significativamente mais compacto que na forma
de atributos de objetos Java. Xin et al. (2013) declaram que Spark SQL é até 100 vezes
28
mais rápido que Hive para consultas SQL e até 100 vezes mais rápido que Hadoop para
algoritmos de Machine Learning.
Importante observar que o ganho de desempenho utilizando a API Dataframe é obtido
independentemente da linguagem de programação empregada na construção da aplicação
Spark SQL. Armbrust et al. (2015b) afirmam que isto é especialmente importante para
aplicações escritas em Python, considerando que Python é tipicamente mais lento que
Java. O otimizador de Spark SQL transforma o plano lógico construído em Python em
um plano físico compilado para código nativo Spark na forma de bytecode JVM, resultando
em uma execução mais eficiente.
Para além do ganho em desempenho, a API dos Dataframes apresenta funcionalidades
não oferecidas pela API RDD, incluindo o suporte a vários operadores relacionais como
junções (joins) e agregações que são familiares para muitos desenvolvedores e cientistas de
dados. Além disso, o usuário pode definir suas próprias funções (user defined functions)
para manipulações avançadas dos dados contidos nos Dataframes. Armbrust et al. (2015b)
declaram que dessa forma é possível combinar SQL com outras linguagens para fins de
realizar análises de dados complexas.
A Figura 6 ilustra um exemplo simples de transformação de dataframes. Nesse exem-
plo, supondo a existência do dataframe ViagensDF com informações sobre a quantidade
de voos entre países, buscamos relacionar os países de origem e destino cuja frequên-
cia de voos é menor que 20. A transformação (1) pode ser obtida utilizando a API
Dataframe de várias formas, como, por exemplo, val NovoDF = ViagensDF.select(
"Origem","Destino").where(col("Qtd_Voos").lt(20)) . É possível também realizar a
mesma transformação utilizando diretamente um comando SQL, por exemplo val NovoDF
= sql("select Origem, Destino from Viagens where Qtd_Voos < 20") desde que
o dataframe tenha sido previamente registrado como uma tabela no catálogo do Spark
SQL.
Spark SQL executa consultas SQL sobre Dataframes utilizando um processo seme-
lhante ao empregado pelos RDBMS tradicionais: (i) parsing da consulta; (ii) geração do
plano lógico da consulta; (iii) transformação do plano lógico em um plano de execução
físico, realizando automaticamente as possíveis otimizações; (iv) execução do plano físico
no cluster na forma de operações sobre RDDs.
Além da API Dataframe, outro importante marco na evolução de Spark foi a introdu-
ção da API denominada Dataset. Trata-se de uma extensão para a API Dataframe com
objetivo de prover segurança de tipos (type-safe), conforme abordaremos na Seção 2.2.3.
29
Figura 6: Transformação de um Dataframe utilizando Spark SQL
2.2.3 Datasets
Assim como Dataframes, Datasets são coleções distribuídas de objetos que represen-
tam tabelas relacionais, com linhas e colunas bem definidas. A diferença é que a API
Dataset permite que usuários associem classes Java (no padrão JavaBean) ou Scala (case
classes) com Dataframes, de forma a permitir a escrita de código estaticamente tipado.
Dessa forma, Dataset busca ser uma API type-safe, mais atrativa para codificação de
grandes aplicações. A verificação de conformidade entre os tipos do Dataset e a especifi-
cação da classe é realizada em tempo de compilação, enquanto que para Dataframes essa
verificação só é realizada em tempo de execução. Assim, Datasets permitem que alguns
erros de codificação das aplicações sejam detectados antes que a aplicação seja executada.
O compilador e a IDE (Ambiente Integral de Desenvolvimento, do inglês Integrated De-
velopment Environment) entendem os tipos usados e podem, portanto, fornecer ajuda e
mensagens de erros enquanto se constrói a aplicação.
O uso de Datasets só está disponível para as linguagens Scala e Java. É preciso utilizar
codificadores (encoders) para converter os objetos Java em sua representação tabular e
vice-versa. Spark SQL provê suporte para automaticamente gerar codificadores para uma
grande quantidade de tipos, incluindo os tipos primitivos (String, Integer, Long, etc), as
case classes de Scala e as classes Java Beans. Entretanto, essa conversão implica em perda
de desempenho da aplicação. De acordo com Chambers e Zaharia (2018), o mais comum
é utilizar Datasets e Dataframes em conjunto, avaliando caso-a-caso o equilíbrio entre
desempenho, flexibilidade e type safety.
A partir da versão 2.017, lançada em julho de 2016, Spark unificou as APIs Dataframe17https://spark.apache.org/releases/spark-release-2-0-0.html
30
e Dataset de forma que Dataframe passou a ser simplesmente um Dataset do tipo Row
(type DataFrame = Dataset[Row]), onde objetos da classe Row representam linhas de
uma tabela relacional.
De maneira geral, Spark SQL e suas APIs Dataframe e Dataset representaram im-
portantes evoluções para Spark. A API RDD é bastante geral, mas oferece oportunidades
limitadas para otimizações automáticas. Além disso, o uso dos Dataframes/Datasets faci-
lita consideravelmente a construção de aplicações Spark. Em razão disso, o projeto Spark
tem buscado incorporar essas novas APIs como a base para as demais bibliotecas do fra-
mework. Dataframes estão se tornando a representação de dados padrão para os algoritmos
das bibliotecas de grafos, de streaming e de aprendizagem de máquina.
No que diz respeito a algoritmos de aprendizagem de máquina, Spark fornece a bi-
blioteca MLlib com diversas funções que podem ser utilizadas com relativa facilidade. A
partir da versão 2.0 do framework, os algoritmos de aprendizagem de máquina passaram
a ser implementados exclusivamente com base na API Dataframes, enquanto que os algo-
ritmos previamente existentes – baseados na API RDD – estão sendo reimplementados.
As funções implementadas anteriormente sobre a API RDD foram mantidas na biblioteca
MLlib, mas não serão mais evoluídas e serão removidas na futura versão Spark 3.0. A
biblioteca fornece, por exemplo, funcionalidades para agrupamentos de elementos com
base em alguma noção de similaridade (Clustering). Neste trabalho, utilizamos algumas
dessas funções para realizar a técnica de modelagem de tópicos.
2.3 Modelagem de Tópicos
A obtenção de informação útil a partir de grandes quantidades de dados é um desafio
que requer bastante esforço, pois pode demandar perícia tanto para a escolha das técnicas
e métodos utilizados quanto para o domínio estudado. Segundo Proto (2018) a análise
sintática ou semântica de documentos textuais é complexa e envolve o uso de técnicas
específicas para o processamento de linguagem natural em razão da riqueza da linguagem
humana e da diversidade encontrada nos textos produzidos. Técnicas de mineração de
dados (Data Mining) auxiliam na extração de conhecimento implícito contido em um
conjunto de dados a partir da identificação de padrões e correlações (PROTO, 2018). De
acordo com Proto (2018), a mineração de textos – ramo da mineração de dados que busca
extrair informações anteriormente desconhecidas a partir da análise de dados textuais – é
uma área de grande interesse e pesquisa com diversas aplicações no cotidiano, tais como:
31
análise de sentimentos, agrupamento de documentos similares, sumarização, modelagem
de tópicos, etc.
A modelagem de tópicos é uma forma de identificar os assuntos tratados em um
conjunto de documentos. Em geral, algoritmos de modelagem de tópicos são utilizados
para descobrir a estrutura temática dos documentos de uma grande coleção, para que
posteriormente seja possível organizá-los, sumarizá-los, visualizá-los, etc (BLEI, 2012a).
Algumas abordagens foram propostas na literatura científica para a modelagem de tópicos
de documentos textuais. Em geral, os documentos são modelados como: conjuntos de
palavras ou frases; vetores ou matrizes; ou probabilidades de ocorrência das palavras.
Algoritmos para modelagem probabilística de tópicos empregam métodos estatísticos
pelos quais busca-se inferir os assuntos (tópicos) abordados em um conjunto de documen-
tos a partir das palavras o compõem. São algoritmos não-determinísticos, uma vez que seu
resultado depende de um processo de amostragens estocásticas (AGRAWAL; FU; MENZIES,
2018). De acordo com (CHEN; THOMAS; HASSAN, 2016), os trabalhos científicos acerca da
modelagem de tópicos probabilística compartilham uma terminologia comum. Definimos
abaixo alguns dos termos utilizados:
• Termo (palavra ou token) w: uma string de um ou mais caracteres alfanuméricos;
• Documento d: um conjunto ordenado de n termos, w1, ..., wn;
• Corpus D: um conjunto não-ordenado de n documentos, d1, ..., dn;
• Vocabulário V : o conjunto não-ordenado dos m termos de um corpus ;
• Tópico k: um conjunto de termos que frequentemente coocorrem em documentos de
um corpus.
Considerando a grande quantidade de dados textuais disponíveis nos dias atuais e a
sua natureza muitas vezes não-estruturada, busca-se ao máximo tornar o processo de mi-
neração de textos uma atividade automática, pois a necessidade de constante supervisão
humana resulta em um processo ineficiente. De acordo com Blei (2012a), os algoritmos
para modelagem de tópicos nos permite organizar e sumarizar documentos em uma escala
impossível de ser tratada por humanos. Algoritmos como, por exemplo, o LDA (Latent
Dirichlet Allocation) procuram descrever o corpus ainda que não se tenha conhecimento
acerca dos documentos nele contidos (aprendizagem não-supervisionada), ou seja, não
requerem anotações ou marcações prévias de documentos como é comum em outros algo-
ritmos de aprendizagem de máquina.
32
2.3.1 Latent Dirichlet Allocation
O algoritmo LDA foi apresentado em 2003 no trabalho de Blei, Ng e Jordan (2003)
e, desde então, deu origem a diversos estudos e aplicações em vários domínios, incluindo
Contudo, segundo Blei, Ng e Jordan (2003), esse problema é intratável computacional-
mente, pois seria necessário computar as distribuições conjuntas para todas as possíveis
instanciações da estrutura de tópicos. Portanto, na modelagem probabilística de tópi-
cos utilizam-se métodos para obtenção de resultados aproximados. De acordo com Blei
(2012a), o desenvolvimento de métodos eficientes para aproximação do resultado dessas
distribuições é um importante objetivo de pesquisa na modelagem probabilística moderna.
Jelodar et al. (2018) discutem vários desses métodos, dentre os quais destacamos o
Collapsed Gibbs Sampling (PORTEOUS et al., 2008) – por ser o método empregado pela
ferramenta MALLET18, muito utilizada em diversos trabalhos científicos, conforme ve-
remos no Capítulo 3 – além do Expectation Maximization (DEMPSTER; LAIRD; RUBIN,
1977) e do Online Variational Bayes (HOFFMAN; BACH; BLEI, 2010) – que são os métodos
implementados nas bibliotecas de aprendizagem de máquina do Spark19. Para os propó-
sitos deste trabalho, omitimos os detalhes dos métodos de computação das distribuições
probabilísticas de modelos como o LDA. Um rica literatura existe sobre o assunto, sendo
suficiente saber que tais métodos existem e o tema continua sendo ativamente pesquisado.
No que diz respeito a Spark, algoritmos para LDA estão disponíveis tanto para a
API RDD (org.apache.spark.mllib.clustering.LDA) quanto para a API Dataframe
(org.apache.spark.ml.clustering.LDA). Em ambos os casos, a versão atual de Spark
implementa tanto o Expectation Maximization quanto o Online Variational Bayes. Outras18https://mallet.cs.umass.edu19Apache Spark Machine Learning Library : https://spark.apache.org/mllib
34
ferramentas populares que implementam o LDA e que foram utilizadas em trabalhos
relacionados a este, conforme veremos no Capítulo 3, são: Gensim20, SciKit Learn21 e
LDA R package22.
A escolha do algoritmo de computação das distribuições do LDA depende do caso
de uso: o Online Variational Bayes é um algoritmo que processa os dados em lotes pe-
quenos de maneira a otimizar o uso da memória na medida em que descarta os dados
já processados. Dessa forma, o modelo resultante contém apenas o conjunto de tópicos
inferidos, sendo bastante escalável para conjuntos de dados muito grandes; o Expectation
Maximization obtém resultados mais completos na medida em que armazena não somente
o conjunto de tópicos inferidos, mas também todo o conjunto de dados usado no treina-
mento do modelo e a distribuição de tópicos por documento. Neste trabalho, utilizamos o
Expectation Maximization, pois as informações adicionalmente guardadas são úteis para
análises que desejamos realizar sobre o corpus.
Em geral, LDA tem sido bastante utilizado e produzido bons resultados para diferentes
domínios de aplicações. Entretanto, a parametrização do modelo para obtenção de bons
resultados não é uma tarefa trivial. De acordo com Martinez (2018), um dos desafios do
uso do LDA é a escolha de uma configuração – os valores dos parâmetros de entrada –
que produza tópicos significantes. De maneira geral, os algoritmos para LDA trabalham
com três parâmetros:
1. K: a quantidade de tópicos a serem inferidos.
2. α: hiperparâmetro da distribuição Dirichlet para a proporção de tópicos do docu-
mento. O parâmetro α representa a densidade documento-tópico (TREUDE; WAG-
NER, 2018). Valores altos para α indicam que cada documento contém uma mistura
da maior parte dos tópicos, enquanto que valores baixos indicam que cada docu-
mento tende a tratar de poucos tópicos de forma mais específica.
3. β : hiperparâmetro da distribuição Dirichlet para a proporção de palavras por tópico.
O parâmetro β representa a densidade tópico-palavra (TREUDE; WAGNER, 2018).
Valores altos para β indicam que cada tópico contém uma mistura da maior parte
das palavras do vocabulário, ou seja, compartilham muitas palavras, enquanto que
valores baixos indicam que os tópicos possuem palavras mais específicas.20https://radimrehurek.com/gensim21https://scikit-learn.org22https://cran.r-project.org/web/packages/lda
35
Ao aplicar o LDA em um corpus de N documentos, obtemos um conjunto deK tópicos
com suas respectivas distribuições de termos para o vocabulário de tamanhoM , conforme
ilustrado na Figura 7.
Figura 7: Parametrização do Algoritmo LDA.
O usuário deve conhecer de alguma forma a quantidade adequada de tópicos K para a
análise do corpus. A modelagem probabilística de tópicos será útil na medida em que essa
estrutura latente inferida se assemelhe a estrutura temática da coleção de documentos. O
número de tópicos possui grande influência sobre os resultados do LDA, mas geralmente
a avaliação do resultado é subjetiva, de difícil interpretação e consome bastante tempo
(PROTO, 2018). Encontrar o valor ótimo para o número de tópicos a serem descobertos
pelo LDA não é uma tarefa trivial. Este parâmetro deve ser pensado com cuidado, dado
que ele define o número de agrupamentos e, portanto, o resultado final poderá mudar con-
sideravelmente. Um valor baixo poderá conduzir a um resultado de granularidade grossa
que dificulte a identificação dos agrupamentos, enquanto um valor alto pode levar a mode-
los muitos complexos, de difícil interpretação e validação (WALLACH; MIMNO; MCCALLUM,
2009).
É importante observar que para cada um dos tópicos podemos escolher rótulos que
representem o assunto abordado. Essa escolha é manual – não identificamos nenhum
trabalho que tenha conseguido automatizar satisfatoriamente esse processo – com base
na semântica dos termos associados a cada tópico. Em geral, a escolha dos rótulos se
dá pela análise das palavras do vocabulário mais frequentemente atribuídas ao tópico
pelo algoritmo. Esse não é necessariamente o objetivo do LDA, mas diversos trabalhos
publicados utilizaram especificamente essa técnica para classificar grandes conjuntos de
documentos. Para Zou et al. (2017) é necessário conceber rótulos apropriados aos tópicos
para facilitar a análise e a discussão, uma vez que os tópicos extraídos são abstratos e de
difícil entendimento.
36
Conforme evidenciamos no Capítulo 3, diversas pesquisas já foram desenvolvidas na
área da Engenharia de Software aplicando LDA, dentre as quais destacamos as que uti-
lizaram o conjunto de dados disponível na plataforma Stack Overflow como fonte de
conhecimento para obtenção de compreensão das técnicas e problemas relacionados ao
desenvolvimento de software. Portanto, apresentamos a seguir mais informações sobre a
plataforma Stack Overflow.
2.4 Stack Overflow
Stack Overflow23 é provavelmente o mais popular website de perguntas e respostas
técnicas sobre Computação. Ele conta com uma comunidade rica de participantes especi-
alistas em vários domínios. Desenvolvedores do mundo todo costumam recorrer ao Stack
Overflow para fazer perguntas, responder a questões existentes ou encontrar respostas à
perguntas já respondidas anteriormente. Grande parte dos participantes da comunidade
do Stack Overflow são especialistas em áreas da Computação. Nesse sentido, o website é
hoje um enorme repositório de conhecimento sobre as várias necessidades dos desenvol-
vedores de software. Analisar e entender esse repositório pode nos ajudar a obter uma
melhor compreensão dos tópicos de interesse desses profissionais e das mais variadas ques-
tões relacionadas aos desenvolvimento de software. O conjunto de dados do Stack Overflow
compreende mais de 17 milhões de perguntas e mais de 26 milhões de respostas atual-
mente24.
A plataforma Stack Overflow conta com um sistema de avaliação no qual os usuários
votam para classificar as perguntas e respostas mais relevantes. De acordo com a quali-
dade de suas contribuições, os usuários recebem pontos de reputação que lhe dão acessos
privilegiados e servem como prêmio de reconhecimento, objetivando incentivar a partici-
pação dos usuários da comunidade. O participante que realizou a pergunta pode também
identificar a resposta que lhe foi mais útil, de forma que a resposta ficará em destaque
na página referente a questão. Os usuários também podem associar rótulos (tags) para
suas questões. As tags são escolhidas de listas predefinidas ou criadas quando não houve-
rem tags relevantes para classificação. Essa classificação por tags é subjetiva e pode não
contextualizar as questões corretamente.
A Figura 8 apresenta um exemplo de página do Stack Overflow destacando: o título da
pergunta (A); o corpo da pergunta (B); as tags associadas a pergunta (C); a classificação23https://stackoverflow.com24https://data.stackexchange.com
37
em pontos da pergunta (D);o número de vezes que a pergunta foi marcada como favorita
(E); o número de vezes que a pergunta foi visualizada (F); a quantidade de respostas para
a referida pergunta (G); o corpo da resposta (H); a classificação em pontos da resposta
(I); a marcação da resposta como aceita pelo usuário questionador (J).
Figura 8: Exemplo de página do Stack Overflow com pergunta e uma resposta aceita25.
O Stack Overflow é a plataforma recomendada26 pelo projeto Apache Spark para
que os utilizadores do framework busquem por ajuda. Recomenda-se que seja utilizada
a tag apache-spark ao postar uma pergunta sobre Spark na plataforma. Atualmente
essa tag está associada a mais de 45 mil perguntas. Além dessa, existem diversas outras
tags que podem ajudar a filtrar perguntas sobre temas específicos, tais como pyspark ,
spark-graphx , spark-graphframes , etc. Portanto, a análise dos dados do Stack Overflow
pode nos ajudar ricamente na compreensão de questões relacionadas ao processamento de
Big Data com Apache Spark.25https://stackoverflow.com/questions/3150808326https://spark.apache.org/community.html
38
O conjunto de dados do Stack Overflow está publicamente disponível27 no formato
XML sob uma licença Creative Commons28 que permite seu livre uso para qualquer pro-
pósito. Os dados estão organizados em 8 arquivos XML, cada um representando uma
entidade: Posts, Users, Comments, Tags, Votes, PostLinks, PostHistory e Badges. Para as
análises propostas neste estudo, trabalharemos os dados contidos no arquivo posts.xml .
No Capítulo 4 apresentamos como selecionamos do posts.xml apenas as questões rela-
cionadas ao Apache Spark, bem como quais atributos foram utilizados para obtermos as
informações para análise. Nesse arquivo, cada linha representa uma postagem (post), que
pode ser uma pergunta ou uma resposta e poder conter diversos atributos, dentre os quais
relacionamos:
• Id : número de identificação única do post ;
• PostTypeId : número que indica se o post é uma pergunta (1), ou uma resposta (2);
• AcceptedAnswerId : número do identificador da resposta marcada como aceita pelo
questionador. Atributo presente apenas em posts do tipo pergunta;
• ParentId : número identificador da pergunta a qual uma resposta se refere. Atributo
presente apenas em posts do tipo resposta;
• CreationDate : data de criação do post ;
• Score : número que representa a reputação de um post com base nas interações
positivas (upvote) e negativas (downvote) dos usuários da plataforma.
• ViewCount : número de visualizações do post ;
• Body : texto do corpo da pergunta ou da resposta em formato HTML.
• Title : texto do título da pergunta. Atributo presente apenas em posts do tipo
pergunta;
• Tags : rótulos para classificação das perguntas na plataforma. Atributo presente
apenas em posts do tipo pergunta;
• AnswerCount : quantidade de respostas para uma pergunta. Atributo presente ape-
nas em posts do tipo pergunta;
• CommentCount : quantidade de comentários feitos sobre um post ;27https://archive.org/details/stackexchange28https://creativecommons.org/licenses/by-sa/3.0
39
• FavoriteCount : quantidade de vezes que o post foi marcado como favorito por um
usuário.
No próximo Capítulo apresentamos como o LDA foi utilizado em diversos trabalhos
para a modelagem de tópicos de conjuntos de dados extraídos do Stack Overflow.
40
3 Trabalhos Relacionados
Neste Capítulo apresentaremos o estudo detalhado das publicações científicas rela-
cionadas ao nosso trabalho. Estudamos esses trabalhos no sentido de entender como –
mediante aplicação do LDA – identificar adequadamente as dificuldades e questões de in-
teresse relacionadas ao Spark. Nas seções deste Capítulo, apresentamos o resultado desse
estudo sob três perspectivas: (i) preparação do corpus – na Seção 3.1 tratamos como os
artigos relacionados abordaram a preparação dos documentos para a análise, uma etapa
essencial para alcançar bons resultados com o LDA; (ii) parametrização do LDA – na
Seção 3.2 discutimos como foi realizada a parametrização do modelo LDA em cada um
dos trabalhos que utilizou este método para a modelagem de tópicos; (iii) computação de
métricas e análise dos resultados. – na Seção 3.3 apresentamos questões relacionadas às
métricas e aos tipos de análise realizadas em cada um dos trabalhos estudados.
Na literatura científica, já foram publicados diversos artigos acerca do uso de técnicas
de modelagem de tópicos para suporte às atividades da Engenharia de Software. Segundo
(SUN et al., 2016), existe um interesse crescente na exploração da modelagem de tópicos
para várias atividades da Engenharia de Software, como por exemplo: compreensão de
códigos-fonte; localização de conceitos ou características; previsibilidade de defeitos; re-
cuperação de links de rastreabilidade entre artefatos (rastreabilidade entre código-fonte
e documentos de requisitos, por exemplo); compreensão da história e da evolução de
softwares; etc.
Diversos trabalhos estudaram repositórios de conhecimento, tais como o Stack Over-
flow, para obter entendimento sobre os tópicos de interesse de desenvolvedores de software.
Dentre os estudos já realizados, uma relevante quantidade aplicou LDA em conjuntos de
dados obtidos do Stack Overflow, demonstrando que a modelagem de tópicos é útil para
encontrar padrões nesses dados. A modelagem de tópicos com LDA sobre dados do Stack
Overflow permitiu a realização de diversas análises, conforme sumarizado na tabela 1.
Essas análises compreenderam diversas áreas de estudo, envolvendo questões relati-
41
Tabela 1: Análises realizadas sobre dataset do Stack Overflow utilizando LDA.
Análise Realizada Trabalhos RelacionadosIdentificação dos principais assuntosdiscutidos no Stack Overflow
(BARUA; THOMAS; HASSAN, 2012; WANG; LO; JIANG, 2013;BAJAJ; PATTABIRAMAN; MESBAH, 2014; ZOU et al., 2015;YANG et al., 2016; KOCHHAR, 2016; AHMED; BAGHERZA-DEH, 2018; GUJRAL et al., 2018; JOHRI; BANSAL, 2018)
Identificação dos tópicos discutidos noStack Overflow acerca de tecnologias es-pecíficas
JIANG, 2013; BAJAJ; PATTABIRAMAN; MESBAH, 2014; ZOU et al., 2015, 2017; KO-
CHHAR, 2016; VENKATESH et al., 2016; YANG et al., 2016; AHMED; BAGHERZADEH,
2018; JOHRI; BANSAL, 2018);
2. Gerar documentos a partir dos títulos e corpos das perguntas, não utilizando
os dados contidos nas resposta. Essa estratégia foi utilizada em (WANG; GOD-
FREY, 2013; REBOUÇAS et al., 2016; ZOU et al., 2015, 2017; GUJRAL et al., 2018;
RODRIGUEZ; WANG; KUANG, 2018);
3. Utilizar apenas os títulos das perguntas. Essa estratégia foi utilizada em (ROSEN;
SHIHAB, 2016) e (MARTINEZ, 2018). Rosen e Shihab (2016) justificam essa escolha
com três motivos: (i) os títulos sumarizam e identificam os principais conceitos
tratados na questão; (ii) o corpo das perguntas adiciona informações sem relevância
– por exemplo, como o usuário abordou o problema originalmente, o que o usuário
já tentou, trechos de código-fonte, etc – para a ideia principal da questão; (iii)
considerando que o interesse é nas questões perguntadas pelos desenvolvedores, a
adição das respostas não faz sentido. Para Rosen e Shihab (2016), ainda que o corpo
do post contenha observações interessantes sobre o que o desenvolvedor já tentou,
essa informação adicional se torna um ruído na análise pretendida, pois as questões
de pesquisa do trabalho estão interessadas em saber o que o desenvolvedor pergunta.
44
Em (ZOU et al., 2015, 2017), realizou-se a comparação entre os resultados do LDA apli-
cado a dois corpus : o primeiro continha apenas posts ; o segundo, além dos posts, também
contemplava os comentários realizados para cada um dos posts. Os autores identificaram
que os resultados para as duas configurações foram bastante semelhantes, não apresen-
tando diferenças significativas. Considerando esse resultado e o fato de que o conteúdo dos
comentários também não foi utilizado no demais trabalhos relacionados, não utilizamos
os textos dos comentários na construção do dataset que estudamos. Detalhes acerca da
configuração de nossos experimentos são discutidos no Capítulo 4.
O dataset utilizado por Barua, Thomas e Hassan (2012) foi extraído do Stack Over-
flow, compreendendo um período de 27 meses, entre os anos de 2008 e 2010, com 3.474.987
posts, sendo 973.267 (28%) perguntas e 2.501.720 (72%) respostas. Nesse trabalho, o LDA
foi aplicado para sumarizar os principais tópicos presentes em discussões do Stack Over-
flow, bem como identificar como esses tópicos evoluíram durante esse período de tempo,
identificando assim tendências tecnológicas.
A descoberta de tendências a partir de dados do Stack Overflow também foi abordada
por Bajaj, Pattabiraman e Mesbah (2014), onde um dataset de mais de 500 mil posts foi
particionado em subconjuntos compreendendo períodos de 6 meses de dados cada para fins
de identificação da evolução das discussões e das tendências da área de desenvolvimento
para Web, com perguntas e respostas sobre as tecnologias Javascript, HTML e CSS.
Wang, Lo e Jiang (2013) utilizaram um dataset composto por 63.863 documentos com
objetivo de investigar características das interações entre desenvolvedores na plataforma
Stack Overflow. Os autores buscaram descobrir como estavam distribuídos os desenvolve-
dores que fizeram perguntas e os que respondem as perguntas, além de agrupar as questões
em cinco categorias identificadas a partir da modelagem de tópicos.
A modelagem de tópicos realizada por Allamanis e Sutton (2013) compreendeu sete
corpus extraídos do dataset do Stack Overflow, totalizando 953.616 posts. Os corpora fo-
ram construídos a partir da filtragem dos posts de acordo com suas tags associadas, onde
cada corpus tratou de uma linguagem (Java, Python, CSS ou SQL) ou de uma tecnologia
(Android, controle de versões ou ferramentas de compilação e link-edição). Além da mo-
delagem de tópicos para identificar conceitos de programação, Allamanis e Sutton (2013)
também aplicaram o LDA para classificar os tipos de questões realizadas. Para isso, cons-
truiu outros corpora de forma incomum, removendo frases nominais e tratando as frases
verbais como um único token, de forma que o modelo de tópicos gerado se concentrasse
em termos que indicassem o tipo de questão realizada.
45
A modelagem de tópicos em questões do Stack Overflow relacionadas ao desenvolvi-
mento de aplicativos móveis foi tema em alguns trabalhos (VÁSQUEZ; DIT; POSHYVANYK,
2013; WANG; GODFREY, 2013; ROSEN; SHIHAB, 2016; MARTINEZ, 2018). Vásquez, Dit e
Poshyvanyk (2013) utilizaram o LDA para extrair os principais tópicos de mais de 400.000
questões. Wang e Godfrey (2013) trataram da descoberta dos obstáculos no uso de APIs,
especificamente no desenvolvimento de aplicativos para as plataformas Android e iOS.
Para Rosen e Shihab (2016) o objetivo principal foi determinar o que os desenvolvedores
mobile perguntavam no Stack Overflow. Para isso, um corpus com 1.642.602 documentos
foi construído a partir dos posts que continham tags relacionadas às tecnologias de dis-
positivos móveis. A metodologia empregada por Rosen e Shihab (2016) foi replicada por
Martinez (2018), mas com um objetivo mais específico – o de obter entendimento sobre
as principais questões relacionadas ao desenvolvimento de aplicativos móveis utilizando o
Xamarin1. Além do Stack Overflow como fonte de dados, esse trabalho também aplicou
o LDA sobre um dataset obtido do Xamarin Fórum2, objetivando comparar os resultados
obtidos.
No trabalho de Zou et al. (2015), o LDA foi aplicado ao dataset do Stack Overflow
como um todo para fins de extrair os tópicos relacionados à discussão de requisitos não-
funcionais (RNF). Os autores buscaram identificar quais RNF são mais discutidos na
plataforma, identificar a dificuldade na resolução de problemas envolvendo RNF, bem
como a evolução e as tendências na discussão de RNF, onde o dataset foi particionado
em períodos de 30 dias. Este trabalho foi refinado posteriormente (ZOU et al., 2017) com
análises mais detalhadas, onde a exploração dos tópicos foi estendida para identificar as
discussões sobre RNF para tecnologias específicas.
As preocupações que desenvolvedores enfrentam quando integrando suas aplicações
com serviços de terceiros mediante uso de APIs Web foi investigada no trabalho de Ven-
katesh et al. (2016). Nesse trabalho, o LDA foi aplicado em posts tanto do Stack Overflow
quanto em datasets extraídos de 32 comunidades (fóruns) mantidas pelos fornecedores
APIs, gerando um corpus com 92.471 documentos.
Na área de linguagens de programação, Johri e Bansal (2018) utilizaram o algoritmo
LDA sobre 11.097.716 posts do Stack Overflow com objetivo de identificar e comparar
tendências na popularidade de tecnologias e linguagens de programação. Já Rebouças et
al. (2016) aplicaram o LDA em um dataset composto por 59.156 questões relacionadas à
linguagem de programação Swift.1https://xamarin.com2https://forums.xamarin.com
46
Yang et al. (2016) apresentaram um estudo sobre os tópicos relacionados à segurança
da informação que foram obtidos a partir da aplicação do LDA em dataset extraído do
Stack Overflow com 30.054 documentos. Os autores informam terem removido do corpus
os termos cuja frequência foi menor que 10 vezes, justificando que essa medida serve para
reduzir o ruído causado por termos pouco frequentes. Ao final, o corpus utilizado possuía
um vocabulário composto por 4.333 termos diferentes.
O artigo de Kochhar (2016) trata da identificação dos principais desafios e tópicos de
discussão relacionados ao teste de software. LDA foi aplicado em um corpus composto
de 38.000 documentos extraídos do dataset do Stack Overflow. Os posts foram seleciona-
dos com base na presença do termo “test” em alguma das tags associadas às perguntas,
de forma a identificar questões para múltiplas linguagens de programação e diferentes
plataformas.
LDA também foi utilizado por Ahmed e Bagherzadeh (2018) para obter entendimento
acerca dos interesses e das dificuldades de desenvolvedores ao lidarem com questões re-
lacionada à concorrência. Para isso, utilizou-se um dataset com 245.541 posts do Stack
Overflow, sendo 156.777 perguntas e 88.764 respostas.
Gujral et al. (2018) discutiram a modelagem de tópicos para mais de 75 mil perguntas
do Stack Overflow relacionadas com a geração de logs de aplicações com objetivo de
identificar as questões enfrentadas por desenvolvedores nesse contexto.
Recentemente, em setembro de 2018, Rodriguez, Wang e Kuang (2018) publicaram
artigo que apresentou um estudo em que foi aplicado o LDA sobre um conjunto de da-
dos obtidos do Stack Overflow para fins de compreender o uso do framework Apache
Spark. Portanto, esse é o trabalho que mais se assemelha ao nosso. O corpus utilizado
foi elaborado a partir das perguntas obtidas utilizando uma API 3 do Stack Overflow,
filtrando as perguntas para obter apenas aquelas associadas com as tags onde o termo
“spark” aparece no nome. Esse processo resultou na construção de um corpus com 36.659
documentos. Em nosso trabalho, os documentos são extraído de um dataset mais atual
e completo do Stack Overflow, em processo automatizado por um programa escrito utili-
zando o próprio Spark, o que nos permitiu identificar 49.377 documentos, um acréscimo
de 35%. Em (RODRIGUEZ; WANG; KUANG, 2018), cada documento foi formado pelo tí-
tulo e pelo corpo das perguntas, excluindo as respostas da formação do corpus. Em nosso
trabalho, adicionalmente, realizamos experimentos sobre outros dois corpus : um formado
apenas pelos títulos das perguntas e outro que, além das perguntas, contempla também3https://api.stackexchange.com/2.2/questions
47
o corpo das respostas.
A tabela 2 relaciona os procedimentos empregados na preparação do corpus para cada
um dos trabalhos relacionados, bem como suas quantidades de documentos e tipos de posts
utilizados. Alguns dos trabalhos relacionados não apresentaram os detalhes do processo
de preparação dos documentos. Dessa forma, quando não foi possível identificar se um
procedimento foi aplicado, a célula correspondente na tabela apresenta o valor N.D. (não
discutido).
De maneira geral, muitos artigos não foram claros sobre os detalhes de como foi
realizado o pré-processamento dos dados, ainda que esse passo impacte significativamente
os resultados da modelagem de tópicos. Apenas em dois trabalhos (11,1%) há indicação
quanto à remoção dos termos mais raros ou frequentes, conforme pode ser observado na
Tabela 2. Ainda, apenas 22,2% dos trabalhos indicaram explicitamente que realizaram
a remoção de caracteres não alfabéticos (números, pontuações, caracteres especiais, etc).
Mas, nesse caso, diante da importância dessa tarefa para o bom resultado do LDA e da
trivialidade em sua implementação, entendemos que esses detalhes foram omitidos para
fins de simplificação textual.
Para reduzir o tamanho do vocabulário e aumentar a efetividade da modelagem de
tópicos, em pelo menos 88,9% dos trabalhos relacionados optou-se pela realização da
remoção de Stop Words, em pelo menos 77,8% aplicou-se o processo de Stemming, em
pelo menos 55,6% removeu-se as tags HTML e pelo menos 50% indicaram remover os
trechos de código. Em razão do observado, entendemos a importância dessas tarefas e,
em nosso trabalho, aplicamos todas essas transformações para obter melhores resultados.
48
Tabe
la2:
Procedimentosde
preparação
docorpus
nostrab
alho
srelacion
ados
Referên
cia
Tipos
de
post
sno
corp
usQuan
tidad
ede
docu-
mentos
Rem
oveu
códigos-
fonte?
Rem
oveu
tags
HTML?
Rem
oveu
ca-
racteres
não-
alfabéticos?
Rem
oveu
ter-
mos
comuns
ouraros?
Rem
oveu
Sto
pW
ords
?
Aplicou
Ste
m-
min
g?
(AH
ME
D;
BA
GH
ER
ZA
-D
EH,2
018)
Pergu
ntas
eRespo
stas
245.541
Sim
Sim
Sim
N.D
.Sim
Sim
(ALLA
MA
NIS
;SU
TT
ON,
2013)
Pergu
ntas
eRespo
stas
953.616
Não
N.D
.N.D
.N.D
.Não
Sim
(BA
JAJ;
PAT
TA
BIR
A-
MA
N;M
ESB
AH,2
014)
Pergu
ntas
eRespo
stas
500.046
N.D
.N.D
.N.D
.N.D
.Sim
Sim
(BA
RU
A;
TH
OM
AS;
HA
S-SA
N,2
012)
Pergu
ntas
eRespo
stas
3.474.987
Sim
Sim
N.D
.N.D
.Sim
Sim
(GU
JRA
Let
al.,2018)
Pergu
ntas
50.000
Sim
Sim
N.D
.Sim
Sim
Sim
(JO
HR
I;B
AN
SAL,2
018)
Pergu
ntas
eRespo
stas
11.097.716
Sim
Sim
N.D
.N.D
.Sim
Sim
(KO
CH
HA
R,2
016)
Pergu
ntas
eRespo
stas
38.298
N.D
.Sim
N.D
.N.D
.Sim
Sim
(MA
RT
INE
Z,2
018)
Pergu
ntas
(ape
-na
sTítulos)
44.434
Não
N.D
.N.D
.N.D
.Sim
Sim
(RE
BO
UÇ
AS
etal
.,2016)
Pergu
ntas
59.156
Sim
Sim
Sim
N.D
.Sim
Sim
(RO
DR
IGU
EZ;W
AN
G;K
U-
AN
G,2
018)
Pergu
ntas
36.659
Sim
Sim
N.D
.N.D
.Sim
Sim
(RO
SEN
;SH
IHA
B,2
016)
Pergu
ntas
(ape
-na
sTítulos)
1.642.602
Não
N.D
.N.D
.N.D
.Sim
N.D
.
(VÁ
SQU
EZ;
DIT
;P
OSH
Y-
VA
NY
K,2
013)
Pergu
ntas
eRespo
stas
400.000
Não
Sim
Sim
N.D
.Sim
Sim
(VE
NK
AT
ESH
etal
.,2016)
Pergu
ntas
eRespo
stas
92.471
Sim
Sim
N.D
.N.D
.Sim
Sim
(WA
NG
;LO
;JIA
NG,2
013)
Pergu
ntas
eRespo
stas
63.863
Sim
N.D
.N.D
.N.D
.Sim
Sim
(WA
NG
;GO
DFR
EY,2
013)
Pergu
ntas
N.D
.Não
N.D
.N.D
.N.D
.N.D
.N.D
.(Y
AN
Get
al.,2016)
Pergu
ntas
eRespo
stas
30.054
Sim
Sim
Sim
Sim
Sim
Sim
(ZO
Uet
al.,2015,2
017)
Pergu
ntas
eRespo
stas
21.700.000
Não
N.D
.N.D
.N.D
.Sim
N.D
.
Pergu
ntas
921.000
49
3.2 Parametrização do LDA
Nesta seção discutiremos os valores e abordagens utilizadas nos trabalhos relaciona-
dos quanto à parametrização do algoritmo LDA para a modelagem de tópicos realizada
para corpus do Stack Overflow. Objetivamos identificar os valores utilizados para a quan-
tidade de tópicos (K), para os hiperparâmetros da distribuição Dirichlet (α e β) e para a
quantidade de iterações do algoritmo.
De acordo com os trabalhos relacionados, a estratégia mais frequentemente utilizada
para escolha dos parâmetros foi a da experimentação com valores diversos (BARUA; THO-
MAS; HASSAN, 2012; VÁSQUEZ; DIT; POSHYVANYK, 2013; ZOU et al., 2015, 2017; REBOUÇAS
et al., 2016; ROSEN; SHIHAB, 2016; VENKATESH et al., 2016; YANG et al., 2016; GUJRAL et
al., 2018; JOHRI; BANSAL, 2018). Já a estratégia de parametrização baseada em valores
encontrados em outros trabalhos foi a adotada nos trabalhos de Martinez (2018) e Ahmed
e Bagherzadeh (2018). Enquanto o primeiro afirma que se baseou nas configurações em-
pregadas em (ROSEN; SHIHAB, 2016), o segundo seguiu os trabalhos de (BARUA; THOMAS;
HASSAN, 2012; BAJAJ; PATTABIRAMAN; MESBAH, 2014; ROSEN; SHIHAB, 2016; YANG et al.,
2016). Em nosso trabalho, adotaremos as duas abordagens, nos basearemos em trabalhos
anteriores para a escolha dos hiperparâmetros e da quantidade de iterações do algoritmo,
mas para a definição do número de tópico (K) também realizaremos experimentações com
diversos valores.
Quanto ao número de tópicos, Barua, Thomas e Hassan (2012) buscaram obter tópicos
de média granularidade, capazes de capturar tendências gerais das discussões mantendo
os tópicos distintos entre si. Eles declaram que, após experimentações com vários valores,
o número de tópico foi definido como 40, o que possibilitou uma adequada caracterização
do corpus a partir dos tópicos inferidos. Essa quantidade de tópicos (40) também foi o
valor utilizado no estudo de Venkatesh et al. (2016) após experimentação com valores
diversos.
Segundo Ahmed e Bagherzadeh (2018), é bem conhecido que é difícil determinar um
valor ótimo para o número de tópicos. Os autores escolheram K = 30 após a realização
de experimentos com objetivo de identificar uma granularidade suficiente para a análise
desejada. Rosen e Shihab (2016), após estudar os resultados das várias experimentações,
observando empiricamente a relação semântica entre os termos dominantes para cada
tópico, definiu K como 40. Martinez (2018) também declara que encontrar valores óti-
mos para parametrização do LDA é uma tarefa difícil e que nesse estudo foram testadas
50
diferentes configurações. Martinez (2018) decidiu utilizar as mesmas configurações em-
pregadas por Rosen e Shihab (2016), de forma que fosse permitida a comparação dos
resultados entre os trabalhos.
No trabalho de Vásquez, Dit e Poshyvanyk (2013), o LDA foi utilizado para extra-
ção de 20 tópicos, objetivando extrair apenas os tópicos de alto nível. A quantidade de
20 tópicos também foi a escolhida por Zou et al. (2015, 2017). Os autores indicam que
foram experimentados diferentes valores de K, escolhendo-se o valor que apresentou o me-
lhor resultado ao verificar a existência de palavras duplicadas entre os diferentes tópicos.
Segundo Zou et al. (2017), K = 20 talvez não seja a escolha ótima, mas foi uma esco-
lha apropriada para uma análise de granularidade média em seu caso de uso (requisitos
não-funcionais).
Allamanis e Sutton (2013) aplicaram LDA para identificar 150 tópicos acerca de con-
ceitos de programação e 100 tópicos para categorizar os tipos de perguntas feitas no Stack
Overflow. Os autores indicam que essas quantidades de tópicos foram concebidas para
permitir a descoberta dos tópicos em uma granularidade suficiente para as análises dese-
jadas. A escolha do número de tópicos baseada no nível de granularidade que o trabalho
demandava também foi a estratégia adotada por Rebouças et al. (2016). Os autores pa-
rametrizaram o LDA com diferentes valores de K, variando de 10 a 35, escolhendo-se
25 tópicos com base nos resultados da experimentação. Johri e Bansal (2018) buscaram
estabelecer uma quantidade de tópicos suficientes para uma análise de granularidade “mé-
dia”. Inicialmente foram realizados experimentos com K = 30, mas os tópicos produzidos
continham palavras para diferentes assuntos. Num segundo momento, tentou-se a aná-
lise com K = 50, mas, segundo os autores, tornou-se difícil rotular todos os tópicos de
maneira significante. Por fim, Os resultados desejados foram alcançados com K = 40.
Já Gujral et al. (2018) testaram várias granularidades de tópicos (K = 10, 20, 30, 40, e
50), onde, segundo os autores, os resultados mais significativos ocorreram para K=50. Os
autores não explicitaram no artigo a razão de não prosseguirem com mais experimentos
em maiores granularidades.
De maneira geral, a escolha do número de tópicos (parâmetro K) nos trabalhos relaci-
onados se deu mediante a partir da experimentação e da avaliação empírica dos resultados
apresentados. Diferentemente, Yang et al. (2016) empregaram algoritmos genéticos para
encontrar um valor ótimo para K no que se refere aos tópicos relacionados à segurança
da informação discutidos no Stack Overflow. A busca foi do valor 2 ao 50, uma vez que,
segundo os autores, deveria haver pelo menos 2 tópicos, e 50 é um número de tópicos
51
provavelmente suficiente para a análise que desejavam realizar. A partir da avaliação dos
agrupamentos resultantes do LDA utilizando a métrica Silhouette coeficient4, os autores
escolheram modelar as questões de segurança da informação em 30 tópicos.
Nos trabalhos de Wang, Lo e Jiang (2013), Wang e Godfrey (2013), Bajaj, Pattabira-
man e Mesbah (2014) e Kochhar (2016) pouco foi apresentado acerca da parametrização
do LDA. Wang, Lo e Jiang (2013) utilizou o LDA para identificar 5 tópicos, Wang e
Godfrey (2013) trabalhou com 100 tópicos e podemos deduzir, a partir dos resultados
apresentados, que Bajaj, Pattabiraman e Mesbah (2014) utilizou LDA para identificar
15 tópicos, pois a parametrização do LDA não foi explicitamente discutida. Os resulta-
dos apresentados por Kochhar (2016) indicam que o LDA foi aplicado para identificar 8
tópicos.
Em outro trabalho que também estudou o uso do Spark, Rodriguez, Wang e Kuang
(2018) utilizaram LDA para identificar 30 tópicos (K = 30). Diferentemente, em nosso
trabalho, para a escolha de K, realizaremos experimentações com diversos valores – com
K variando entre 20 e 60 – e analisaremos os diferentes resultados obtidos.
De acordo com Wallach, Mimno e McCallum (2009), a seleção do número de tópicos
é uma das mais problemáticas escolhas na modelagem de tópicos, pois não há um método
claro e bem definido para essa escolha. Os autores argumentam que o risco de utilizar mais
tópicos que o necessário é menor que o risco de utilizar menos tópicos, pois grandes valores
para K não afeta significativamente a qualidade dos tópicos gerados, onde alguns tópicos
gerados adicionalmente podem ser descartados na análise por serem considerados ruídos.
Enquanto que a escolha de pequenos valores para K pode não separar adequadamente
os tópicos (WALLACH; MIMNO; MCCALLUM, 2009). Ou seja, pode-se filtrar os tópicos de
ruído gerados adicionalmente (no caso de grandes valores deK), mas pode não ser possível
identificar os assuntos agrupados em um mesmo tópico (no caso de pequenos valores de
K).
No que diz respeito aos chamados hiperparâmetros α e β, (AHMED; BAGHERZADEH,
2018) utilizou α = 50/K e β = 0, 01. De acordo com Biggers et al. (2012), esses valeres
de hiperparâmetros (α = 50/K e β = 0, 01) são tipicamente utilizados, tornando-se
heurísticas-padrão de fato. Esses mesmos valores de hiperparâmetros também foram os
utilizados por Rosen e Shihab (2016) e por Zou et al. (2015, 2017). Em (MARTINEZ,
2018), declara-se que foi utilizada configuração similar a empregada por Rosen e Shihab4Silhouette coefficient é uma métrica comumente utilizada para avalair agrupamentos (KAUFMAN;
ROUSSEEUW, 2009) de dados.
52
(2016), mas inconsistentemente os valores utilizados foram α = 0, 025 e β = 0, 1. Já em
(VÁSQUEZ; DIT; POSHYVANYK, 2013) e em (RODRIGUEZ; WANG; KUANG, 2018), para os
hiperparâmetros foram utilizados valores α = 0, 01 e β = 0, 01. Vásquez, Dit e Poshyvanyk
(2013) declaram que escolheram valores baixos porque estavam interessados em uma alta
variabilidade na distribuição de tópicos, de forma a facilitar a identificação dos tópicos
dominantes. Os autores relatam ainda que, durante as experimentações, foram tentadas
várias combinações de parâmetros no LDA, tendo obtido resultados similares.
Enquanto alguns estudos utilizaram valores padrão da ferramenta utilizada para α e
β, a maior parte dos trabalhos não discutiu essa parametrização. Em geral, os estudos
utilizaram o LDA como uma caixa-preta, não considerando em detalhes os efeitos de di-
ferentes valores para os hiperparâmetros. Embora existam publicações da comunidade de
aprendizagem de máquinas que tratem a questão mais aprofundadamente, não encontra-
mos essa discussão em artigos em que o LDA tenha sido aplicado a datasets extraídos do
Stack Overflow. Também não é escopo do nosso trabalho encontrar valores ótimos para
esses parâmetros, podendo tal estudo ser realizado em trabalhos futuros. Dessa forma,
em nossos experimentos utilizamos os hiperparâmetros α = 50/K e β = 0.01, uma vez
que esses valores foram os mais utilizados dentre os trabalhos relacionados que discutiram
esta configuração, tratado-se de uma heurística padrão de fato, ratificando o declarado por
(BIGGERS et al., 2012). As Figuras 9 e 10 resumem as configurações dos hiperparâmetros
α e β utilizadas nos trabalhos relacionados.
Figura 9: Valores utilizados nos trabalhosrelacionados para o hiperparâmetro α.
Figura 10: Valores utilizados nos trabalhosrelacionados para o hiperparâmetro β.
Em relação ao número de iterações do algoritmo, o LDA foi parametrizado por Barua,
Thomas e Hassan (2012) para a execução de 500 iterações, após a qual, de acordo com
Griffiths e Steyvers (2004), o resultado é estabilizado. O valor de 2.000 iterações foi o
valor empregado por Allamanis e Sutton (2013) e por Rodriguez, Wang e Kuang (2018).
53
Já Venkatesh et al. (2016) utilizou 1.000 interações, justificando-se a escolha como sendo
um valor comumente utilizado em outros trabalhos. De fato, esse valor também foi o
empregado em outros seis trabalhos relacionados (VÁSQUEZ; DIT; POSHYVANYK, 2013;
ZOU et al., 2015, 2017; AHMED; BAGHERZADEH, 2018; JOHRI; BANSAL, 2018; MARTINEZ,
2018). Dessa forma, dentre os trabalhos que relataram o valor utilizado no número de
iterações, boa parte utilizou o valor 1.000, que também é o valor padrão para a ferramenta
MALLET. Parece seguro considerar que esse valor é suficiente para estabilizar o resultado
obtido.
A ferramenta MALLET (MCCALLUM, 2002) – que possibilita o uso de diversos al-
goritmos de aprendizagem de máquina – foi a mais utilizada para a aplicação do LDA
nos estudos pesquisados (BARUA; THOMAS; HASSAN, 2012; ALLAMANIS; SUTTON, 2013;
WANG; GODFREY, 2013; ZOU et al., 2015, 2017; ROSEN; SHIHAB, 2016; AHMED; BAGHERZA-
também foram utilizadas inspeções de amostras dos documentos (exemplos de perguntas)
associados a cada tópico, de forma a facilitar sua nomeação. Outras técnicas utilizadas
nesse processo de rotulação foram as de revisão por pares em (VENKATESH et al., 2016;
MARTINEZ, 2018) e a de Card Sorting em (AHMED; BAGHERZADEH, 2018). Em nosso es-
tudo, também utilizaremos a inspeção manual de exemplos de pergunta associados a cada
tópico gerado, bem como a revisão por pares. A tabela 4 relaciona os métodos utilizados
para rotular os tópicos em cada um dos trabalhos relacionados.
Tabela 4: Métodos de rotulação de tópicos
Referência RotulouTópicos?
Método utilizado para rotular os tópicos
(AHMED; BAGHERZA-DEH, 2018)
Sim Manual baseado nos 20 termos mais frequentese exame de 15 posts de exemplo. Uso de CardSorting com dois participantes.
(ALLAMANIS; SUTTON,2013)
Não
(BAJAJ; PATTABIRA-MAN; MESBAH, 2014)
Sim Manual baseado nos termos mais frequentes.
(BARUA; THOMAS; HAS-SAN, 2012)
Sim Manual baseado nos termos mais frequentes eexame de exemplos de posts.
(GUJRAL et al., 2018) Sim Não discutido. Aparentemente, manual base-ado em 6 a 10 termos mais frequentes.
(JOHRI; BANSAL, 2018) Sim Manual baseado nos termos mais frequentes.(KOCHHAR, 2016) Sim Manual baseado nos 5 termos mais frequentes.(MARTINEZ, 2018) Sim Manual baseado nos termos mais frequentes.
Revisão em pares com dois participantes.(REBOUÇAS et al., 2016) Sim Manual baseado nos termos mais frequentes.(RODRIGUEZ; WANG; KU-ANG, 2018)
Sim Manual baseado nos 10 termos mais frequentes.
(ROSEN; SHIHAB, 2016) Sim Manual baseado nos 19 termos mais frequentese exame de 15 posts de exemplo.
(VÁSQUEZ; DIT; POSHY-VANYK, 2013)
Sim Manual baseado nos 15 termos mais frequentese exame de posts de exemplo.
(VENKATESH et al., 2016) Sim Manual baseado nos termos mais frequentes.Revisão em pares com três participantes.
(WANG; LO; JIANG, 2013) Sim Manual baseado nos 50 termos mais frequentes.(WANG; GODFREY, 2013) Sim Manual baseado nos termos mais frequentes.(YANG et al., 2016) Sim Manual baseado nos 10 termos mais frequentes.(ZOU et al., 2015, 2017) Sim Automático, baseado em uma lista de palavras.
Validação manual de amostra.
Para análise dos resultados obtidos a partir da aplicação do LDA, métricas foram
57
propostas e computadas em vários dos trabalhos relacionados (BARUA; THOMAS; HAS-
KOCHHAR, 2016; JOHRI; BANSAL, 2018; AHMED; BAGHERZADEH, 2018). Em geral, as
metodologias desses trabalhos foram compostas por 4 atividades essenciais, ilustradas na
Figura 11, quais sejam:
1. Seleção dos dados que serão utilizados a partir de um Dataset do Stack Overflow;
2. Pré-processamento de textos para preparação do corpus em que será realizada
a modelagem de tópicos;
3. Aplicação do LDA para modelagem probabilística de tópicos;
4. Computação de métricas e realização de análises diversas sobre os resultados
do LDA para responder às questões de pesquisa.
64
Figura 11: Atividades comumente realizadas.
Nas próximas seções, discutiremos em detalhes cada uma dessas atividades, identifi-
cando para cada atividade as tarefas executadas. A Figura 12 apresenta uma visão geral
da metodologia empregada.
Para execução das atividades, construímos uma aplicação Spark utilizando as lingua-
gens Scala e SQL, bem como elementos das bibliotecas Spark SQL e de Machine Learning.
A escolha da linguagem Scala foi motivada pelo fato do próprio Spark ter sido escrito com
ela, de forma que é a linguagem mais naturalmente integrada ao framework. O código-
fonte da aplicação está disponível em https://github.com/zidenis/spark-overflow.
Todos os experimentos foram executadas em um cluster Standalone do Spark, versão 2.2.0,
formado por três computadores, cada qual com 8 núcleos de processamento trabalhando
a 2.666MHz e com 8 GB de memória RAM. O dataset extraído do Stack Overflow foi
carregado em um sistema de arquivos distribuído HDFS armazenado nesses três compu-
tadores. Essa infraestrutura foi alocada gratuitamente no Centro de Processamento de
Dados do Instituto Metrópole Digital2 da UFRN.
4.2 Seleção de Dados
O ponto inicial da nossa metodologia é a obtenção de um Dataset com dados do Stack
Overflow. Em nosso trabalho, copiamos o dataset que é disponibilizado publicamente
por meio do Stack Exchange Data Dump3. Trata-se de uma cópia anonimizada de todo
conteúdo construído pelos usuários da plataforma e que é disponibilizada para download
na forma de arquivos compactados. Sua mais recente versão foi publicada em 03 de junho1https://spark.apache.org/community.html2https://www.imd.ufrn.br3https://archive.org/details/stackexchange
65
Figura 12: Visão geral da metodologia.
66
de 2019, entretanto nossos experimentos foram realizados sobre o dump de 02 de dezembro
de 2018. Em nosso estudo, trabalhamos com o arquivo Posts.xml , um arquivo texto que,
na versão indicada, ocupa 59GB de armazenamento e compreende 39.646.925 registros,
entre perguntas e respostas registradas na plataforma. A etapa de seleção de dados e as
tarefas realizadas estão representadas na Figura 12 (1).
Uma vez obtido o dataset, passamos a realizar a análise exploratória dos dados para
fins de identificar quais informações seriam utilizadas. Segundo Cline et al. (2018), a aná-
lise exploratória de dados é um passo importante no processo de descoberta, ajudando a
responder questões e encontrar anomalias e restrições que podem impactar negativamente
os resultados. Fizemos a leitura do Posts.xml extraindo, dentre os atributos de cada
registro, os atributos id , postTypeId , acceptedAnswerId , parentId , creationDate ,
score , viewCount , body , title , tags , answerCount , commentCount e favoriteCount ,
cuja semântica está descrita na Seção 2.4.
Tratamos então de reduzir o dataset para que ele contivesse apenas os registros relaci-
onados às perguntas e respostas sobre o framework Apache Spark, descartando os demais
registros contidos no dump do Stack Overflow. Nesse sentido, aplicamos dois filtros ao
dataset:
1. Filtro por data. Identificamos que a primeira pergunta sobre Spark no Stack
Overflow foi registrada em 7 de dezembro de 2012. Então, o primeiro passo na
redução do dataset foi remover todos os posts criados em data anterior, utilizando
o atributo CreationDate de cada registro.
2. Filtro por tags . Para retirar do dataset os posts não relacionados a Spark, utiliza-
mos o atributo Tags para filtrar somente os posts relacionado as tags que contives-
sem o termo “spark” em seu nome. Esse método foi igualmente empregado por Ah-
med e Bagherzadeh (2018). Ocorre que, após inspeção dos resultados, identificamos
que esse método é falho, na medida em que não remove do dataset os posts que tem o
nome “spark” em suas tags atribuídas, mas que não dizem respeito ao Apache Spark,
como por exemplo as tags “flex-spark”, “sparklines”, “spark-java”, “laravel-spark” e
“bizspark”. Esses registros, se não removidos, seriam ruídos que atrapalhariam os
resultados da modelagem de tópicos. Após avaliação de todas as possíveis tags,
identificamos o conjunto de strings que corretamente identifica as tags relacionadas
a Spark, um conjunto formado por: “apache-spark”, “pyspark”, “sparklyr”, “sparkr”,
O filtro por tags permite a identificação das perguntas sobre Spark, mas não contempla
as respostas para essas perguntas, uma vez que no arquivo Posts.xml o atributo Tags
está presente apenas para registros do tipo pergunta (PostTypeId=1). Então, uma vez
identificadas as perguntas sobre Spark é preciso ainda obter as respostas para cada uma
delas. Spark SQL é de grande ajuda nessa tarefa, pois podemos obter esse resultado
utilizando uma operação SQL de join entre o conjunto de perguntas sobre Spark e o
conjunto de todas as respostas, onde Resposta.ParentId = Pergunta.Id .
Uma vez extraídos as perguntas e respostas de interesse – somente aquelas relacionados
ao Apache Spark – passamos a atividade de pré-processamento de textos.
4.3 Pré-processamento de Textos
Com o conjunto de dados reduzido, passamos então à etapa de pré-processamento
dos textos para preparar os documentos que constituem a entrada do algoritmo LDA. O
pré-processamento de textos ajusta e remove os elementos textuais dos documentos que
são considerados ruídos, mas não remove documentos do corpus. A Figura 12 (2) ilustra
a sequência de tarefas realizadas na etapa de pré-processamento dos textos. Nessa etapa,
todos os textos – atributos Title e Body das perguntas, e atributo Body das respostas –
a serem utilizados no LDA passaram pelas seguintes transformações:
1. Conversão para minúsculas. Normalização necessária para identificar duas pa-
lavras como iguais ainda que grafadas de forma diferente;
2. Remoção de trechos de código. Os trechos de código-fonte no XML do Stack
Overflow são marcados entre tags <pre> e </pre> , tornando fácil sua identificação
e substituição;
3. Remoção de tags HTML. Para identificação das tags HTML utilizamos a ex-
pressão regular <([^>])+> ;
4. Remoção de Números. Dados relativos a números de versões, anos e outros nú-
meros foram identificados pela expressão regular \\d+((\\.\\d+)?)* e removidos
do texto;
68
5. Remoção de Caracteres Especiais. A identificação de caracteres especiais tam-
bém é feita mediante uso de expressões regulares com objetivo de remover todos os
caracteres não-alfabéticos;
6. Remoção de Stopwords . Utilizamos a lista de palavras da língua inglesa fornecida
junto com a ferramenta MALLET4;
7. Stemming . A transformação dos termos em seus radicais foi realizada com auxílio
do Spark Stemming5, um pacote desenvolvido pela comunidade Spark para o uso de
algoritmos de stemming para diversas línguas.
4.4 Aplicação do LDA
O LDA é um algoritmo que procura descrever um corpus ainda que não se tenha
conhecimento acerca dos documentos contidos nele. Em nosso trabalho, conforme ilustrado
na Figura 12 (3), os textos pré-processados foram utilizados na construção de três corpus :
1. Corpus de títulos de perguntas, onde cada documento foi formado apenas pelos
títulos das perguntas sobre Spark encontradas no dataset do Stack Overflow;
2. Corpus de títulos e corpos das perguntas, onde cada documento foi formado
pela concatenação dos atributos título e corpo das perguntas;
3. Corpus de títulos das perguntas e corpos das perguntas e respostas, onde,
além do título e corpo da pergunta, os corpos das respostas também foram conca-
tenados na formação dos documentos constituintes do corpus.
A utilização de três corpus foi motivada pela necessidade de avaliar em qual dos três
cenários obteríamos melhores resultados na identificação dos tópicos discutidos. Dessa
forma, cada corpus foi composto de forma diferente para fins de identificação da abor-
dagem que apresenta os melhores resultados. Rosen e Shihab (2016) indicaram em seu
trabalho que a utilização apenas dos títulos seria suficiente, mas a maior parte dos tra-
balhos relacionados empregou uma das outras duas abordagens na construção do corpus
de estudo. Em nossos experimentos iniciais, percebemos que a identificação dos assuntos
discutidos (rotulação) nos tópicos identificados foi mais ágil, em decorrência dos tópicos
reunirem documentos mais relacionados entre si, para o corpus cujos documentos foram4https://github.com/mimno/Mallet/blob/master/stoplists/en.txt5https://github.com/master/spark-stemming
69
compostos estritamente pelos títulos das perguntas, corroborando o declarado em (ROSEN;
SHIHAB, 2016).
Uma vez definidos os corpora, iniciamos os experimentos para a modelagem de tópicos
mediante aplicação do LDA. Primeiramente, por meio de análise exploratória, computa-
mos algumas métricas como tamanho do corpus (quantidade de documentos), tamanho
do vocabulário (quantidade de termos) e a lista de palavras mais frequentes. Dessa lista,
identificamos alguns termos (“apache”, “spark”, “org” e “code”) tão frequentes que não servi-
riam para distinguir tópicos e, portanto, foram removidos dos corpora antes das aplicação
do LDA.
O algoritmo LDA, na forma como implementado na biblioteca de aprendizagem de
máquina de Spark (org.apache.spark.mllib.clustering.LDA), espera como entrada
vetores com tokens indexados e suas frequências. Portanto, é preciso transformar os
documentos do corpus nesses vetores, um trabalho que é facilitado pelo uso da classe
org.apache.spark.ml.feature.CountVectorizer .
Em nossos experimentos, os hiperparâmetros do LDA foram definidos como α =
50/K e β = 0.01, uma vez que esses valores foram os mais utilizados dentre os trabalhos
relacionados que discutiram este aspecto. De acordo com Biggers et al. (2012), esses
valores são tipicamente utilizados, sendo considerados como heurísticas-padrão de fato.
Não é escopo do nosso trabalho encontrar valores ótimos para esses parâmetros, podendo
tal estudo ser realizado em trabalhos futuros. Para a quantidade de iterações do algoritmo,
utilizamos o valor de 1.000 iterações, uma vez que após análise dos trabalhos relacionados,
parece seguro considerar que esse valor é suficiente para estabilizar o resultado obtido.
Quanto ao número de tópicos (K), de forma geral nos trabalhos relacionados, o valor
foi definido a partir da experimentação e teste com vários valores. Buscamos encontrar se,
nos valores apresentados nos trabalhos relacionados, há correlação entre a quantidade de
documentos constituintes do corpus e a quantidade de tópicos (relacionados na tabela 6).
Calculando o Coeficiente de Correlação de Pearson (p) (PEARSON, 1920) – uma medida
de associação muito utilizada em diferentes áreas da pesquisa científica – encontramos
que as duas variáveis não dependem linearmente uma da outra (p = −0, 086) para nossa
amostra de 18 trabalhos relacionados.
Tabela 6: Quantidades de documentos e tópicos por trabalho relacionado.
Trabalho Relacionado Tamanho
do corpus
Número de
Tópicos
(BARUA; THOMAS; HASSAN, 2012) 3.474.987 40
70
(ALLAMANIS; SUTTON, 2013) 953.616 100
(ALLAMANIS; SUTTON, 2013) 953.616 150
(VÁSQUEZ; DIT; POSHYVANYK, 2013) 400.000 20
(WANG; LO; JIANG, 2013) 63.863 5
(BAJAJ; PATTABIRAMAN; MESBAH, 2014) 500.046 15
(ZOU et al., 2015) 21.700.000 20
(KOCHHAR, 2016) 38.298 8
(REBOUÇAS et al., 2016) 59.156 25
(ROSEN; SHIHAB, 2016) 1.642.602 40
(VENKATESH et al., 2016) 92.471 40
(YANG et al., 2016) 30.054 30
(ZOU et al., 2017) 921.000 20
(AHMED; BAGHERZADEH, 2018) 245.541 30
(GUJRAL et al., 2018) 50.000 50
(JOHRI; BANSAL, 2018) 11.097.716 40
(MARTINEZ, 2018) 44.434 40
(RODRIGUEZ; WANG; KUANG, 2018) 36.659 30
Considerando os valores de K comumente utilizados nos trabalhos relacionados, re-
solvemos então realizar experimentos executando o algoritmo LDA para 20, 30, 40, 50 e
60 tópicos. Com a variação de K, podemos identificar como se comporta a modelagem de
tópicos em vários níveis de granularidade, de forma a encontrar o nível mais adequado à
identificação dos temas de interesse dos desenvolvedores e à construção da hierarquia de
tópicos. Dessa forma, podemos também comparar os resultados obtidos em nossos expe-
rimentos com aqueles apresentados por Rodriguez, Wang e Kuang (2018) que realizaram
estudo semelhante, mas modelando apenas 30 tópicos.
Como exemplo ilustrativo, a tabela 7 apresenta o resultado da aplicação do LDA
sobre o corpus de perguntas (somente títulos) para identificação de 20 tópicos (K = 20),
mostrando os 5 termos mais frequentes para cada tópico.
Tabela 7: Resultado do LDA para 20 Tópicos.
Tópico Os 5 termos mais comuns e suas proporções em cada um dos tópicos
plos de documentos para cada um dos tópicos. Por exemplo, a Tabela 8 relaciona 10
documentos associados ao tópico T1 que fora apresentado anteriormente na Tabela 7.
O identificador do documento pode ser utilizado para consultar, diretamente no web-
site do Stack Overflow, o post que forma o respectivo documento, acessando https:
//stackoverflow.com/questions/{Identificador}.
72
Tabela 8: Exemplos de documentos para o tópico T1.
Identificador Documento (Título da Pergunta)26499246 apache spark yarn cluster42337535 Spark clustering with yarn26530771 how to : spark yarn cluster40100038 Can we run apache spark 1.1.0 on yarn-cluster?35522999 Is it possible to run spark yarn cluster from the code?36274257 Preinstallation for spark yarn cluster30672648 How to autostart an Apache Spark cluster using Supervisord?39556204 Cannot run spark v2.0.0 example on cluster31863148 Using Silhouette Clustering in Spark49930909 How to run pyspark in YARN cluster mode
Pela inspeção dos termos mais frequentes para o tópico T1 (Tabela 7) e dos exemplos
de documentos (Tabela 8), parece razoável rotular o tópico T1 como “Cluster Spark”. Esse
foi precisamente o método utilizado em nosso estudo para realizar a rotulação de cada
um dos tópicos identificados pelo LDA.
A atividade de rotulação dos tópicos foi realizada manualmente por um grupo com-
posto por 5 pesquisadores: dois professores doutores, um aluno doutorando e dois alunos
mestrandos. Esse grupo reuniu-se em diversas ocasiões para estabelecer consenso acerca
da rotulação dos tópicos e padronização dos rótulos concebidos. Essa tarefa mostrou-se
bastante árdua e demorada, demandando muitas horas de análise e discussões em reuniões
presenciais e à distância.
Em um primeiro momento, realizamos a rotulação dos resultados da aplicação do
LDA sobre os três corpus e granularidades de 20, 30 e 40 tópicos. Durante esse processo,
o grupo percebeu empiricamente que a rotulação dos tópicos foi mais ágil, em decor-
rência dos tópicos reunirem documentos mais relacionados entre si, para o corpus cujos
documentos foram compostos apenas pelos títulos das perguntas do que quando realizado
para os outros dois corpus concebidos. Nesse sentido, concordamos com a decisão de Ro-
sen e Shihab (2016) que também optaram por utilizar apenas os títulos das perguntas
na construção do corpus, ratificando os fatores motivadores dessa decisão, quais sejam:
(i) os títulos sumarizam e identificam os principais conceitos tratados na questão; (ii) o
corpo das perguntas adiciona informações sem relevância – por exemplo, como o usuário
abordou o problema originalmente, o que o usuário já tentou, trechos de código-fonte, etc
– para a ideia principal da questão, onde essa informação adicional é um ruído na análise
pretendida. Portanto, com objetivo de reduzir o tempo despendido nessa etapa da meto-
dologia e, dessa forma, tornar o processo mais eficiente, decidimos que, a partir de então,
realizaríamos a atividade de rotulação apenas para o corpus dos títulos das perguntas.
73
Considerando então apenas o corpus de títulos das perguntas, foram analisados e
atribuídos rótulos para 200 tópicos em 5 execuções do LDA, ou seja, para 20, 30, 40,
50 e 60 tópicos. Os resultados completos da aplicação do LDA sobre o corpus de títulos
das perguntas em diferentes níveis de granularidade – K = (20, 30, 40, 50, 60) – estão
disponíveis para consulta em https://tiny.cc/sparkoverflow.
Em nossos resultados, para cada tópico, apresentamos os 20 termos mais frequentes e
relacionamos os 10 documentos em que o tópico foi o dominante (o tópico mais discutido
no documento). Esses termos e documentos de exemplo foram as informações utilizadas
para identificar os temas dos tópicos e assim rotulá-los. Em alguns casos não foi possível
atribuir um nome significante a um tópico, pois não conseguimos identificar um tema que
o identificasse de forma única. Nesses casos, utilizamos o rótulo “indefinido”. A relação
dos rótulos identificados, bem como a discussão acerca dos resultados encontrados serão
apresentados no Capítulo 5.
Ainda no que diz respeito a rotulação de tópicos, manter a consistência entre os nomes
atribuídos para os tópicos nos diversos experimentos com diferentes níveis de granulari-
dade demandou muitas horas de trabalho em um processo de constante revisão dos rótulos
identificados. Buscamos ao máximo evitar inconsistências, por exemplo, casos em que dois
rótulos diferentes fossem atribuídos a tópicos que tratassem do mesmo tema. Considerando
a natureza do funcionamento do LDA, dois tópicos de experimentos diferentes podem ser
considerandos semelhantes se as suas distribuições de termos forem semelhantes. Ou seja,
considerando os principais termos utilizados na identificação do rótulo de um tópico, de-
vemos atribuir esse mesmo rótulo a outro tópico se os mesmos termos forem os principais
termos desse outro tópico. Tomemos por exemplo a distribuição dos 20 principais termos
para o tópico 7 do experimento de 20 tópicos e para tópico 1 do experimento de 30 tópicos,
conforme representado na Tabela 9, onde associado a cada termo está, entre parenteses,
o valor da probabilidade de ocorrência do termo no tópico. Nesse caso, considerando as
semânticas de cada um dos termos presentes nas distribuições, tanto para o Tópico 7 do
resultado do LDA para 20 tópicos (K = 20) quanto para o Tópico 1 para 30 tópicos
(K = 30), escolhemos o rótulo “Machine Learning”. Destacamos a semelhança entre as
referidas distribuições de termos pelo conjunto de termos igualmente contidos nelas (“ml-
lib”, “model”, “featur”, “regress”, “random”, “predict”, “train”, “algorithm” e “tree”) que de
fato são termos frequentemente utilizados no contexto do domínio de Aprendizagem de
Máquina.
Considerando que a verificação manual de todas as combinações entre os 200 tópicos
74
Tabela 9: Distribuição de termos para dois tópicos semelhantes entre experimentos.
Transformamos os 52 conceitos em nós de uma árvore para representar a taxonomia.
A definição das relações hierárquicas entre os nós foi realizada com base na semântica
dos conceitos e no conhecimento adquirido durante a tarefa de rotulação dos tópicos. De
forma semelhante à tarefa de rotulação de tópicos, a tarefa de construção da taxonomia foi
realizada manualmente por um grupo de pesquisadores que se reuniu em diversas ocasiões
para estabelecer consenso.
Durante o processo de construção da taxonomia, o grupo identificou que os conceitos
poderia ser agrupados em sete grandes grupos temáticos: (i) Abstração de Dados; (ii)
Abstração de Processos; (iii) Bibliotecas; (iv) Gerenciamento de Arquivos; (v) Integra-
ção e Execução; (vi) Falhas; (vii) e Linguagens. Discutiremos a seguir cada um desses
grupos que estão representados nas Figuras 15, 16, 17, 18, 19, 20, 21 e 22. Nessas Figu-
87
ras, adicionamos os números dos tópicos associados ao conceito de cada nó. Por exemplo,
o nó Datasets (15 | 2 | X | 48 | X) indica que o conceito Datasets não foi
identificado nos experimentos de 40 e 60 tópicos, mas foi identificado no tópico 15 para
K = 20, no tópico 2 para K = 30, no tópico 48 para K = 50. Dessa forma, podemos man-
ter a rastreabilidade entre os conceitos da hierarquia gerada e os resultados obtidos pela
aplicação do LDA. Essa rastreabilidade pode ser utilizada para, por exemplo, relacionar
perguntas feitas no Stack Overflow para cada nó da árvore de taxonomia.
Figura 15: Árvore de conceitos relacionados à abstração de dados.
O grupo Abstração de Dados (Figura 15) reúne conceitos relacionados com a
forma como os dados distribuídos são representados em uma aplicação Spark. As abstra-
ções RDD, Dataframes e Datasets foram apresentadas na Seção 2.2 deste trabalho.
Figura 16: Árvore de conceitos relacionados à abstração de processos.
O grupo Abstração de Processos (Figura 16) agrega conceitos identificados em
tópicos que tratam de questões relativas a manipulação de dados. O nó Conversão de
Tipos representa a dificuldade dos desenvolvedores em saber como trabalhar com os tipos
de dados de uma aplicação Spark, especialmente quanto à conversão e compatibilidade
entre tipos. O nó Iterações identifica questões que envolvem o uso de estruturas
de repetição como while loops, objetos iteradores (Iterators) ou métodos para iterações
em coleções (forEach). Outras questões recorrentes dizem respeito a Manipulação de
88
Datas e Tempo, como, por exemplo, a manipulação de timestamps. Percebemos ainda a
necessidade do desenvolvedor em conhecer como trabalhar dados estruturados na forma de
vetores e matrizes, especialmente no contexto de algoritmos de aprendizagem de máquina.
Ainda no que diz respeito ao grupo Abstração de Processos, para as várias gra-
nularidades de experimentação com o LDA, encontramos diversos tópicos que agruparam
as questões sobre o funcionamento e uso das operações (transformações e ações) do Spark.
Esses tópicos foram identificados com o rótulo Operações. O uso de operações do tipo
Join, que relaciona elementos (RDDs ou Dataframes) a partir de um atributo em comum,
foram percebidas como temas principais em alguns tópicos identificados pelo LDA. As ope-
rações de Agrupamento, Contagem, Filtragem e Operações Chave-valor
se destacaram como subtemas nos tópicos do tema Operações em razão da frequência
em que foram percebidas. As operações de Agrupamento dizem respeito àquelas que
juntam elementos, quer seja mediante uso de métodos GroupBy das APIs RDD e Data-
frame ou pela cláusula Group By em comandos SQL, para aplicação posterior de funções
de agregação como count, sum, average, etc. O uso da função de agregação count – para
contagem de elementos de uma coleção – se destacou como subtema de Operações para
as granularidades de 40, 50 e 60 tópicos. A seleção de elementos de coleções a partir do
uso de condições de filtragem também se destacou como subtema e, portanto, foi identi-
ficada na taxonomia pelo nó Filtragem. Operações que combinam valores a partir de
atributos-chave, que identificamos como Operações Chave-Valor, também se desta-
ram em perguntas que, em geral, envolve o uso de métodos como o reduceByKey .
Figura 17: Árvore de conceitos relacionados ao uso de bibliotecas.
O grupo Bibliotecas (Figura 17) junta conceitos relacionados ao uso das biblio-
tecas Spark SQL, Spark Streaming e da biblioteca de aprendizagem de máquina
MLlib. Não foi possível identificar nos resultados do LDA nenhum tópico cujo tema esti-
89
vesse relacionado a biblioteca GraphX, evidenciando que seu uso é raro se comparado as
demais bibliotecas fornecidas junto com o Apache Spark. Perguntas relacionadas ao uso
da biblioteca Spark SQL são recorrentes, com destaque àquelas que dizem respeito aos
recursos de SQL denominados Windows Functions e User Defined Functions
(UDF ). Windows Functions são funções SQL que trabalham sobre dados de regis-
tros anteriores e posteriores à uma linha selecionada. UDF permite o uso, em comandos
SQL, de rotinas criadas pelo usuário para manipulação de dados selecionados. Diver-
sos foram os tópicos identificados para o tema Aprendizagem de Máquina, alguns a
respeito de algoritmos e outros mais específicos acerca do uso da biblioteca Mllib. A bi-
blioteca Spark Streaming também foi recorrentemente identificada em todos os níveis
de granularidade, destacando-se o uso em conjunto de Spark com a tecnologia Kafta1,
uma plataforma para processameto distribuído de fluxo de dados contínuos.
Figura 18: Árvore de conceitos relacionados ao gerenciamento de arquivos.
Questões relacionadas ao gerenciamento de arquivos também foram muito frequentes
nas perguntas sobre Spark no Stack Overflow, sendo identificadas em vários tópicos nos
diversos níveis de granularidade de aplicação do LDA. O grupo Gerenciamento de
Arquivos (Figura 18) juntou os conceitos identificados a partir dos tópicos que dizem
respeito à Entrada e Saída de dados e a manipulação de Formatos de Arquivos
diversos, com destaque para os formatos Parquet, JSON e CSV. O entendimento e uso
do sistema de arquivos distribuídos HDFS é uma questão de interesse frequente dos de-
senvolvedores.
O grupo Integração e Execução foi o que teve mais conceitos associados e por
isso necessitou ser ilustrado em duas figuras (19 e 20). O nó Build diz respeito as questões
sobre a compilação e empacotamento de aplicações Spark, com destaque para a impor-1https://kafka.apache.org
90
Figura 19: Árvore de conceitos relacionados à integração e execução de aplicações Spark.
tância das questões relativas ao gerenciamento de Dependências com bibliotecas. O
Ambiente de Execução em que as aplicações são executadas também é uma questão
de interesse dos desenvolvedores. Apesar das aplicações Spark poderem ser executadas
em apenas um computador (local mode), o objetivo do framework é que essas aplicações
sejam executadas em clusters de forma a proporcionar o ganho de desempenho. Dentre
as possibilidades de Cluster, destacam-se o uso do YARN e do cluster Standalone
que é a tecnologia fornecida pelo próprio framework. O nó Execução de jobs diz res-
peito aos tópicos relacionados com a submissão e execução de aplicações nos clusters. As
aplicações Spark também podem ser executadas em diversos ambientes de computação
em nuvem (Cloud), dentre os quais se destaca a Cloud Amazon. Para execução das
aplicações, Spark realiza a Serialização de tarefas que são então distribuídas para os
componentes executores, conforme explicado anteriormente na Seção 2.2. Outra forma de
uso comum do framework Spark é a execução de aplicações juntamente com ferramentas
tipo Notebooks que são muito utilizadas por cientistas de dados para análises de da-
dos interativas. No contexto de Spark, destaca-se o uso dos Notebooks Zeppelin2 e
Jupyter3.
O Desempenho na execução das aplicações Spark também é um tema muito frequente
e relevante para a comunidade Spark no Stack Overflow. Pela análise dos tópicos mode-
lados, percebemos muitas questões acerca do tempo de Duração da Execução das
aplicações, do dimensionamento e uso eficiente da Memória e do Particionamento
2https://zeppelin.apache.org3https://jupyter.org
91
Figura 20: Continuação da árvore de conceitos relacionados à integração e execução deaplicações Spark.
dos dados. Também relacionado ao desempenho de aplicações, identificamos um tópico
associado ao tema Broadcast Variables que é um recurso do framework utilizado
para o compartilhamento de variáveis somente-leitura para execução de tarefas de forma
eficiente na medida em que reduz custos de comunicação entre os componentes da aplica-
ção. Questões relacionadas ao uso do Spark em conjunto com componentes do Hadoop
também são relevantes na comunidade. Outro tema frequente é a execução de aplica-
ções integradas com sistemas gerenciadores de Bancos de dados, com destaque para
Cassandra4, HBase5, Hive6, e Mongodb7.
Figura 21: Árvore de conceitos relacionados a falhas em geral.
Os usuários do Spark utilizam a plataforma Stack Overflow para encontrar soluções
para as suas dificuldades enfrentadas no uso do framework. Percebemos que muitas vezes
os desenvolvedores realizaram perguntas utilizando termos copiados das mensagens de
erro e exceção percebidas ao executar as aplicações. A aplicação do LDA sobre o dataset
do Stack Overflow consegue capturar essas questões a partir de termos-chave como error,4https://cassandra.apache.org5https://hbase.apache.org6https://hive.apache.org7https://www.mongodb.com
92
fail e exception. Entretanto, não foi possível obter um agrupamento de perguntas que
possibilitasse uma classificação mais detalhada desse tema.
Figura 22: Árvore de conceitos relacionados à linguagens.
Para o grupo Linguagens (Figura 22) buscamos juntar os conceitos extraídos a
partir dos tópicos relacionados às perguntas sobre uso de linguagens de programação no
contexto de Spark. Como esperado, Scala se destacou por ser a principal linguagem de
desenvolvimento e uso do framework. Também evidencia-se o uso da linguagem Python,
com destaque para o Pyspark, componente do Spark responsável por disponibilizar o
modelo de programação e funcionalidades de Spark a partir de programas escritos em
Python. Não identificamos tópicos que pudessem ser rotulados com relacionados as lin-
guagens Java e R. A identificação de tópicos relativos a Java pode ter sido prejudicada
porque o termo está muito presente nas questões que relatam exceções e, portanto, fo-
ram classificadas para o tema Erros e Exceções. Quanto a linguagem R, termos que
poderiam ser associados ao uso da linguagem apresentaram baixa frequência nos tópicos
em que foram identificados. De fato, poucas perguntas estão associadas as tags sparkr
(cerca de 600 perguntas) e spark-java (cerca de 500 perguntas), evidenciando que o
uso dessas linguagens junto com framework é relativamente baixo.
Por fim, apresentamos a Figura 23 que ilustra a taxonomia concebida. Essa árvore
apresenta o conjunto de conceitos mais importantes no contexto de Spark na medida
em que foram os temas identificados nos tópicos modelados mediante aplicação do LDA.
Adicionalmente, nesse conjunto existem temas que são mais importantes que outros, em
termos de sua popularidade. Apresentaremos essa análise na seção a seguir.
93
Figura23
:Tax
onom
iade
interesses
edificulda
desacerca
doprocessamento
deBig
Datautilizand
oofram
eworkApa
cheSp
ark.
94
5.3 Importância Relativa dos Tópicos
Conforme apresentado na Seção 3.3, existem métricas que podemos computar para
analisarmos a importância relativa dos tópicos resultantes da modelagem de tópicos do
Stack Overflow com LDA.
Em nosso trabalho, computamos os valores dessas métricas para os diversos níveis
de granularidade experimentados. Os resultados completos estão disponíveis em https:
//tiny.cc/sparkoverflow, entretanto, utilizaremos os valores obtidos para o experi-
mento com 50 tópicos para os fins da análise quantitativa que discutiremos a seguir.
Escolhemos apenas um nível de granularidade para análise, pois entendemos que não é
possível combinar os valores das métricas entre os experimentos sem gerar distorções na
análise, dado que: (i) existem tópicos identificados em um nível de granularidade que não
foram identificados em outros; (ii) não há como estabelecer precisamente a relação entre
tópicos de diferentes granularidades e, portanto, não há como distribuir corretamente os
valores encontrados. Por exemplo, não temos como associar os valores obtidos para os tópi-
cos Cluster e Cluster (YARN) na granularidade K = 20 com os tópicos Cluster
(Bancos de Dados), Cluster (Cloud Amazon) e Cluster (Standalone,
YARN, Kafka) na granularidade K = 30. Em razão dos dados percebidos no processo
de rotulação para as quantidades de “tópicos indefinidos”, “temas únicos”, “novos temas”
e “temas complementares” (Figura 14), escolhemos realizar a análise quantitativa dos re-
sultados para a granularidade K = 50. A Tabela 13 apresenta os Valores das métricas
computadas para todos os rótulos identificados no experimento com LDA para 50 tópicos.
Tabela 13: Valores das métricas para a modelagem de 50 tópicos
Adicionalmente, utilizamos os tópicos identificados pelo LDA para descobrir os prin-
cipais temas discutidos. Computamos várias métricas – combinando o resultado do LDA
com atributos quantitativos das perguntas do Stack Overflow – para ranquear os temas
descobertos. Para além das métricas identificadas a partir do estudo de trabalhos relaci-
onados, nosso trabalho propôs a métrica Answer-count Topic Share (AS) para capturar
a popularidade dos temas em que os desenvolvedores mais interagem ativamente. Apesar
dos resultados encontrados para essa métrica terem sido semelhantes aos encontrados em
outras métricas, o resultado da métrica AS destacou maior importância para os temas
Spark Streaming, Scala e Cloud Amazon.
Considerando os resultados obtidos para o conjunto de todas as métricas, encon-
tramos que os temas mais importantes são, nessa ordem: Dataframes, Erros e
Exceções, RDD, Machine Learning, Bancos de Dados, Entrada e Saída,
Desempenho, Execução de Jobs, Operações e Cluster.
6.1 Principais Contribuições
Esta dissertação apresenta as seguintes contribuições:
1. A identificação das principais dificuldades e questões de interesse de desenvolvedores
de aplicações para Big Data com o framework Apache Spark;
2. Computação de oito métricas, onde uma delas é uma nova métrica proposta neste
trabalho, para ranqueamento dos tópicos identificados;
3. Uma taxonomia para organizar hierarquicamente os principais conceitos relaciona-
dos ao uso de Spark;
4. O estudo detalhado dos trabalhos de pesquisa que aplicaram o algoritmo LDA para
modelagem probabilística de tópicos em datasets extraídos do Stack Overflow;
5. Implementação e disponibilização de uma Aplicação Spark de código aberto para
aplicação de modelagem probabilística de tópicos sobre dados do Stack Overflow.
112
6.2 Limitações
Em nossa pesquisa, identificamos potenciais ameaças que podem afetar nossos resul-
tados:
1. Configuração do LDA: mudanças nos valores dos parâmetros α, β e K podem
gerar resultados significativamente diferentes. Buscamos mitigar esta ameaça iden-
tificando – a partir do estudo de vários trabalhos relacionados – heurísticas e valores
padrões para esses parâmetros. Ainda, realizamos experimentos sobre diferentes va-
lores de K sobre o mesmo dataset ;
2. Natureza aleatória do LDA: dado que trata-se de um modelo probabilístico, cada
execução do LDA produz resultados diferentes, ainda que a mesma configuração
seja utilizada. Considerando que aplicamos o LDA em vários níveis de agrupamento
de tópicos, pudemos identificar quais tópicos/temas/conceitos foram identificados
independentemente do nível de granularidade e, dessa forma, reduzir o risco da
análise dos resultados ser influenciada por essa ameaça;
3. Análise manual e subjetiva dos resultados: a rotulação dos tópicos e a definição
da hierarquia de conceitos da taxonomia é um procedimento que requer intervenção
intelectual humana. De forma semelhante a grande parte dos trabalhos relaciona-
dos, utilizamos a estratégia de rotular os tópicos com base nos principais termos e
documentos (perguntas) associados a cada tópico. Nós reduzimos a subjetividade de
análise ao realizar essa tarefa em um grupo de cinco pessoas, de forma a estabelecer
consenso na avaliação dos 200 tópicos identificados.
4. Adequação das métricas utilizadas: constatamos que a análise da importância
dos temas identificados varia conforme a métrica utilizada. Buscamos reduzir essa
ameaça ao analisar os resultados sob as perspectivas das várias métricas identificadas
no referencial teórico.
6.3 Trabalhos Futuros
Em trabalhos futuros, nós podemos expandir este estudo de várias formas. Uma pos-
sibilidade é o uso da taxonomia como base para orientar a identificação de casos de teste
relevantes no contexto de programas Spark.
113
A associação dos conceitos da taxonomia aos tópicos modelados e, consequentemente,
aos documentos utilizados, pode ser utilizada para permitir uma exploração das principais
perguntas e/ou respostas do Stack Overflow relacionadas a cada tema identificado. Um
sistema poderia ser construído para facilitar a visualização e a navegação dos resultados
apresentados.
Também pode ser interessante a realização de novos experimentos com outras con-
figurações do LDA, buscando identificar valores ótimos para os parâmetros α e β do
algoritmo no contexto de datasets do Stack Overflow, ou ainda pesquisar outros métodos
para automatizar a identificação da estrutura temática de um conjunto de documentos.
Considerando que o LDA infere os agrupamentos de tópicos com base na sintaxe dos
termos encontrados nos documentos, sem considerar os significados das palavras, termos
polissêmicos resultam em prejuízos nos resultados da modelagem de tópicos. Portanto,
um possível trabalho futuro é o de adaptar o processo de identificação de tópicos para
permitir a desambiguação de termos de acordo com o contexto semântico em que eles
foram utilizados. Nesse sentido, podemos recorrer ao uso de ontologias (PICKLER, 2007).
Assim como realizado em outros trabalhos relacionados, conforme discutido no Ca-
pítulo 3, a modelagem de tópicos pode ser utilizada para identificar a evolução histórica
e as tendências para os temas identificados. Dessa forma, um possível trabalho futuro é
a adaptação de nossa metodologia e dos programas desenvolvidos para realizar a identi-
ficação dos tópicos considerando períodos de tempo, intervalos, e, consequentemente, a
evolução temporal dos tópicos.
A metodologia empregada neste trabalho pode ser reutilizada para identificação dos
tópicos mais importantes em outras áreas de conhecimento. Poderíamos, por exemplo,
conduzir estudos para identificar as dificuldades e questões de interesse no domínio da
computação em nuvem. Podemos ainda empreender esforços para flexibilizar os programas
Spark desenvolvidos de forma que qualquer usuário do framework possa mais facilmente
reutilizá-los para realizar uma modelagem de tópicos sobre dados do Stack Overflow. Há
espaço para automatizar ainda mais o processo de construção de planilhas de análise dos
resultados, computação de métricas, geração de gráficos, etc.
114
Referências
AGRAWAL, A.; FU, W.; MENZIES, T. What is wrong with topic modeling? And howto fix it using search-based software engineering. Information and Software Technology,v. 98, p. 74–88, 2018.
AHMED, S.; BAGHERZADEH, M. What do concurrency developers ask about? alarge-scale study using stack overflow. In: ACM/IEEE Empirical Software Engineeringand Measurement. New York, New York, USA: ACM Press, 2018. p. 1–10.
ALLAMANIS, M.; SUTTON, C. Why, when, and what - analyzing stack overflowquestions by topic, type, and code. In: 2013 10th Working Conference on MiningSoftware Repositories (MSR). San Francisco, California, USA: IEEE, 2013. p. 53–56.
ARMBRUST, M. et al. Scaling spark in the real world: performance and usability. In:ACM VLDB. [S.l.]: VLDB Endowment, 2015. p. 1840–1843.
ARMBRUST, M. et al. Spark SQL: Relational Data Processing in Spark. In: ACMSIGMOD. New York, New York, USA: ACM Press, 2015. p. 1383–1394.
BAJAJ, K.; PATTABIRAMAN, K.; MESBAH, A. Mining questions asked by webdevelopers. In: IEEE Mining Software Repositories. New York, New York, USA: ACMPress, 2014. p. 112–121.
BARUA, A.; THOMAS, S.; HASSAN, A. What are developers talking about? Ananalysis of topics and trends in Stack Overflow. Empirical Software Engineering, v. 19,n. 3, p. 619–654, nov. 2012.
BIGGERS, L. R. et al. Configuring latent Dirichlet allocation based feature location.Empirical Software Engineering, v. 19, n. 3, p. 465–500, ago. 2012.
BLEI, D. M. Probabilistic topic models. Communications of the ACM, v. 55, n. 4, p.77–8, abr. 2012.
BLEI, D. M. Probabilistic topic models. Commun. ACM, ACM, New York,NY, USA, v. 55, n. 4, p. 77–84, abr. 2012. ISSN 0001-0782. Disponível em:<http://doi.acm.org/10.1145/2133806.2133826>.
BLEI, D. M.; NG, A. Y.; JORDAN, M. I. Latent dirichlet allocation. Journal of machineLearning research, v. 3, n. Jan, p. 993–1022, 2003.
BONNER, S. et al. Exploring the Evolution of Big Data Technologies. 1. ed. [S.l.]:Elsevier, 2017.
CHAMBERS, B.; ZAHARIA, M. Spark: The Definitive Guide Big Data Processing MadeSimple. Sebastopol, Califórnia, EUA: O’Reilly Media, 2018.
115
CHEN, T.-H.; THOMAS, S. W.; HASSAN, A. E. A survey on the use of topic modelswhen mining software repositories. Empirical Software Engineering, Springer, v. 21, n. 5,p. 1843–1919, 2016.
CLINE, V. et al. Stack Overflow Question Retrieval System. SMU Data Science Review,p. 1–36, jul. 2018.
DEAN, J.; GHEMAWAT, S. MapReduce: simplified data processing on large clusters.Communications of the ACM, v. 51, n. 1, p. 107, 2008.
DEMPSTER, A. P.; LAIRD, N. M.; RUBIN, D. B. Maximum likelihood fromincomplete data via the em algorithm. Journal of the royal statistical society. Series B(methodological), JSTOR, p. 1–38, 1977.
GRIFFITHS, T. L.; STEYVERS, M. Finding scientific topics. Proceedings of theNational academy of Sciences, National Acad Sciences, v. 101, n. suppl 1, p. 5228–5235,2004.
GUJRAL, H. et al. Empirical Analysis of the Logging Questions on the StackOverflowWebsite. In: 2018 Conference On Software Engineering & Data Sciences (CoSEDS).Srinagar, India: University of Kashmir, 2018. p. 1–6.
HILBERT, M.; LÓPEZ, P. The world’s technological capacity to store, communicate,and compute information. science, American Association for the Advancement of Science,v. 332, n. 6025, p. 60–65, 2011.
HOFFMAN, M.; BACH, F. R.; BLEI, D. M. Online learning for latent dirichletallocation. In: LAFFERTY, J. D. et al. (Ed.). Advances in Neural Information ProcessingSystems 23. Vancouver, Canada: Curran Associates, Inc., 2010. p. 856–864.
JACCARD, P. Étude comparative de la distribution florale dans une portion des alpeset des jura. Bull Soc Vaudoise Sci Nat, v. 37, p. 547–579, 1901.
JELODAR, H. et al. Latent dirichlet allocation (lda) and topic modeling: models,applications, a survey. Multimedia Tools and Applications, Springer, v. 77, p. 1–43, Nov2018. ISSN 1573-7721. Disponível em: <https://doi.org/10.1007/s11042-018-6894-4>.
JOHRI, V.; BANSAL, S. Identifying trends in technologies and programming languagesusing topic modeling. In: 2018 IEEE 12th International Conference on SemanticComputing (ICSC). Laguna Hills, CA, USA: IEEE, 2018. p. 391–396.
KAUFMAN, L.; ROUSSEEUW, P. J. Finding groups in data: an introduction to clusteranalysis. [S.l.]: John Wiley & Sons, 2009.
KOCHHAR, P. S. Mining testing questions on stack overflow. In: International WorkshopSoftware Mining. New York, New York, USA: ACM Press, 2016. p. 32–38.
MARTINEZ, M. Two Datasets of Questions and Answers for Studying the Developmentof Cross-platform Mobile Applications using Xamarin Framework. arXiv preprintarXiv:1712.09569, p. 1–27, jul. 2018.
MAURO, A. D.; GRECO, M.; GRIMALDI, M. A formal definition of Big Data based onits essential features. Library Review, v. 65, n. 3, p. 122–135, abr. 2016.
116
MCCALLUM, A. K. Mallet: A machine learning for language toolkit.Http://mallet.cs.umass.edu. 2002.
PEARSON, K. Notes on the history of correlation. Biometrika, JSTOR, v. 13, n. 1, p.25–45, 1920.
PICKLER, M. E. V. Web semântica: ontologias como ferramentas de representação doconhecimento. Perspectivas em Ciência da Informação, SciELO Brasil, v. 12, p. 65–83,04 2007. ISSN 1413-9936.
PORTEOUS, I. et al. Fast collapsed gibbs sampling for latent dirichlet allocation. In:ACM. Proceedings of the 14th ACM SIGKDD international conference on Knowledgediscovery and data mining. [S.l.], 2008. p. 569–577.
PORTER, M. F. An algorithm for suffix stripping. Program, MCB UP Ltd, v. 14, n. 3,p. 130–137, 1980.
PROTO, S. Enhancing topic modeling through Latent Dirichlet Allocation with self-tuningstrategies. Tese (Doutorado) — Politecnico di Torino, mar. 2018.
PROTO, S. et al. Useful ToPIC: Self-Tuning Strategies to Enhance Latent DirichletAllocation. In: IEEE. 2018 IEEE International Congress on Big Data (BigDataCongress). San Francisco, California, USA: IEEE, 2018. p. 33–40.
RANGANATHAN, A.; CAMPBELL, R. What is the complexity of a distributedcomputing system? In: Understanding Complex Systems Conference. [S.l.: s.n.], 2007. p.37–45.
REBOUÇAS, M. et al. An Empirical Study on the Usage of the Swift ProgrammingLanguage. In: IEEE. 2016 IEEE 23rd international conference on software analysis,evolution, and reengineering (SANER). Osaka, Japan: IEEE, 2016. v. 1, p. 634–638.
RODRIGUEZ, L. J.; WANG, X.; KUANG, J. Insights on Apache Spark Usage by MiningStack Overflow Questions. In: 2018 IEEE International Congress on Big Data (BigDataCongress). San Francisco, CA, USA: IEEE, 2018. p. 219–223.
ROSEN, C.; SHIHAB, E. What are mobile developers asking about? A large scale studyusing stack overflow. Empirical Software Engineering, v. 3, n. 21, p. 1192–223, 2016.
SHI, J. et al. Clash of the Titans: MapReduce vs. Spark for Large Scale Data Analytics.In: ACM VLDB. [S.l.: s.n.], 2015. p. 2110–2121.
SUN, X. et al. Exploring topic models in software engineering data analysis - A survey.In: 2016 17th IEEE/ACIS International Conference on Software Engineering, ArtificialIntelligence, Networking and Parallel/Distributed Computing (SNPD). Shanghai, China:IEEE, 2016. p. 357–362.
TIAN, Y. et al. Predicting Best Answerers for New Questions: An Approach LeveragingTopic Modeling and Collaborative Voting. In: Social Informatics. Berlin, Heidelberg:Springer, Berlin, Heidelberg, 2013. p. 55–68.
TREUDE, C.; WAGNER, M. Per-Corpus Configuration of Topic Modelling for GitHuband Stack Overflow Collections. 04 2018.
117
VÁSQUEZ, M. L.; DIT, B.; POSHYVANYK, D. An exploratory analysis of mobiledevelopment issues using stack overflow. In: THE COLLEGE OF WILLIAM ANDMARY, WILLIAMSBURG, UNITED STATES. 2013 10th Working Conference onMining Software Repositories (MSR). San Francisco, California, USA: IEEE, 2013. p.93–96.
VENKATESH, P. et al. what do client developers concern when using web apis? anempirical study on developer forums and stack overflow. In: 2016 IEEE InternationalConference on Web Services (ICWS). San Francisco, CA, USA: IEEE, 2016. p. 131–138.
WALLACH, H. M.; MIMNO, D. M.; MCCALLUM, A. Rethinking lda: Why priorsmatter. In: Advances in Neural Information Processing Systems (NIPS). Vancouver,B.C., Canada: Curran Associates, Inc, 2009. p. 1973–1981.
WANG, S.; LO, D.; JIANG, L. An empirical study on developer interactions inStackOverflow. In: ACM Symposium on Applied Computing. New York, New York, USA:ACM Press, 2013. p. 1019.
WANG, W.; GODFREY, M. Detecting API usage obstacles - a study of iOS and Androiddeveloper questions. In: 10th Working Conference on Mining Software Repositories. SanFrancisco, California, USA: IEEE, 2013. p. 61–64.
XIN, R. S. Go with the Flow: Graphs, Streaming and Relational Computations overDistributed Dataflow. Tese (Doutorado) — UC Berkeley, 2018.
XIN, R. S. et al. Shark: SQL and rich analytics at scale. In: ACM SIGMOD. New York,New York, USA: ACM, 2013. p. 13–24.
YANG, X. et al. What Security Questions Do Developers Ask? A Large-Scale Studyof Stack Overflow Posts. Journal of Computer Science and Technology, v. 31, n. 5, p.910–924, 2016.
ZAHARIA, M. et al. Resilient Distributed Datasets - A Fault-Tolerant Abstraction for In-Memory Cluster Computing. In: Proceedings of the 9th USENIX conference on NetworkedSystems Design and Implementation. Berkeley, CA, USA: USENIX Association, 2012.p. 2–2. Disponível em: <http://dl.acm.org/citation.cfm?id=2228298.2228301>.
ZAHARIA, M. et al. Spark: Cluster computing with working sets. USE-NIX Association, Berkeley, CA, USA, p. 10–10, 2010. Disponível em:<http://dl.acm.org/citation.cfm?id=1863103.1863113>.
ZOU, J. et al. Which non-functional requirements do developers focus on? an empiricalstudy on stack overflow using topic analysis. In: IEEE. 2015 IEEE/ACM 12th WorkingConference on Mining Software Repositories. Piscataway, NJ, USA: IEEE Press, 2015.p. 446–449. ISBN 978-0-7695-5594-2.
ZOU, J. et al. Towards comprehending the non-functional requirements throughDevelopers’ eyes: An exploration of Stack Overflow using topic analysis. Information andSoftware Technology, v. 84, p. 19–32, abr. 2017.