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

Dirichlet Allocation (LDA), Stack Overflow, taxonomia.

Identification of difficulties and issues of interest to BigData application developers using the Apache Spark

Author: Denis José Sousa de Albuquerque

Supervisor: Prof. Dr. Umberto Souza da Costa

Abstract

This research aims to identify and classify the main difficulties and issues of interest of

Apache Spark application developers regarding the framewok usage. For this purpose,

we use the Latent Dirichlet Allocation algorithm to perform a probabilistic modeling of

topics on information extracted from Stack Overflow, since the manual inspection of the

entire dataset is not feasible. From the knowledge obtained by the comprehensive study of

related works, we established and applied a methodology based on the practices usually

employed. We developed Spark applications for the automated execution os tasks, such

as the data selection and preparation, the discovery of topics - applying the probabilistic

modeling algorithm with various configurations - and metrics computation. Analyzes of

the results were carried by a group of 5 researchers: two doctor professors, one doctoral

student and two master students. Based on the semantic analysis of the labels assigned

to each of the identified topics, a taxonomy of interests and difficulties was constructed.

Finally, we ranked the most important themes according to the various calculated metrics

and compared the methods and results of our study with those presented in another work.

Keywords : Big Data, Apache Spark, Probabilistic Topic Models, Latent Dirichlet Alloca-

tion (LDA), Stack Overflow, Taxonomy.

Lista de figuras

1 Interesse pelos frameworks Spark e Hadoop de acordo com Google Trends1. p. 20

2 Pilha de tecnologias envolvidas em uma aplicação Spark. . . . . . . . . p. 22

3 Componentes de uma aplicação Spark2. . . . . . . . . . . . . . . . . . . p. 23

4 Transformações e ações para contagem das palavras de um arquivo texto. p. 25

5 APIs de Spark e Spark SQL. Adaptado de (ARMBRUST et al., 2015b). . p. 27

6 Transformação de um Dataframe utilizando Spark SQL . . . . . . . . . p. 29

7 Parametrização do Algoritmo LDA. . . . . . . . . . . . . . . . . . . . . p. 35

8 Exemplo de página do Stack Overflow com pergunta e uma resposta aceita3. p. 37

9 Valores utilizados nos trabalhos relacionados para o hiperparâmetro α. p. 52

10 Valores utilizados nos trabalhos relacionados para o hiperparâmetro β. p. 52

11 Atividades comumente realizadas. . . . . . . . . . . . . . . . . . . . . . p. 64

12 Visão geral da metodologia. . . . . . . . . . . . . . . . . . . . . . . . . p. 65

13 Inter-relacionamento entre tópicos dos experimentos para Coeficiente de

Jaccard maior que 0,3. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

14 Dados do processo de rotulação de tópicos nos experimentos . . . . . . p. 84

15 Árvore de conceitos relacionados à abstração de dados. . . . . . . . . . p. 87

16 Árvore de conceitos relacionados à abstração de processos. . . . . . . . p. 87

17 Árvore de conceitos relacionados ao uso de bibliotecas. . . . . . . . . . p. 88

18 Árvore de conceitos relacionados ao gerenciamento de arquivos. . . . . p. 89

19 Árvore de conceitos relacionados à integração e execução de aplicações

Spark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 90

20 Continuação da árvore de conceitos relacionados à integração e execução

de aplicações Spark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91

21 Árvore de conceitos relacionados a falhas em geral. . . . . . . . . . . . p. 91

22 Árvore de conceitos relacionados à linguagens. . . . . . . . . . . . . . . p. 92

23 Taxonomia de interesses e dificuldades acerca do processamento de Big

Data utilizando o framework Apache Spark. . . . . . . . . . . . . . . . p. 93

24 Distribuição de temas de acordo com a métrica TS. . . . . . . . . . . . p. 96

25 Distribuição de temas de acordo com a métrica V S. . . . . . . . . . . . p. 97

26 Distribuição de temas de acordo com a métrica AS. . . . . . . . . . . . p. 98

27 Distribuição de temas de acordo com a métrica CS. . . . . . . . . . . . p. 98

28 Distribuição de temas de acordo com a métrica FS. . . . . . . . . . . . p. 99

29 Distribuição de temas de acordo com a métrica SS. . . . . . . . . . . . p. 100

30 Distribuição de temas de acordo com a métrica TE. . . . . . . . . . . . p. 101

31 Distribuição de temas de acordo com a métrica DT . . . . . . . . . . . . p. 102

32 Distribuição dos grupos de temas. . . . . . . . . . . . . . . . . . . . . . p. 102

33 Importância dos temas de acordo com as diversas métricas aferidas. . . p. 103

34 Métricas para o grupo Abstração de Dados. . . . . . . . . . . . . . . . p. 104

35 Métricas para o grupo Abstração de Processos. . . . . . . . . . . . . . . p. 104

36 Métricas para o grupo Bibliotecas. . . . . . . . . . . . . . . . . . . . . . p. 104

37 Métricas para o grupo Falhas. . . . . . . . . . . . . . . . . . . . . . . . p. 104

38 Métricas para o grupo Gerenciamento de Arquivos. . . . . . . . . . . . p. 105

39 Métricas para o grupo Linguagens . . . . . . . . . . . . . . . . . . . . . p. 105

40 Métricas para o grupo Integração e Execução. . . . . . . . . . . . . . . p. 105

Lista de tabelas

1 Análises realizadas sobre dataset do Stack Overflow utilizando LDA. . . p. 41

2 Procedimentos de preparação do corpus nos trabalhos relacionados . . . p. 48

3 Parâmetros utilizados no LDA nos trabalhos relacionados. . . . . . . . p. 54

4 Métodos de rotulação de tópicos . . . . . . . . . . . . . . . . . . . . . . p. 56

5 Exemplo de matriz de proporções tópicos para os documentos em um

corpus de N documentos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

6 Quantidades de documentos e tópicos por trabalho relacionado. . . . . p. 69

7 Resultado do LDA para 20 Tópicos. . . . . . . . . . . . . . . . . . . . . p. 70

8 Exemplos de documentos para o tópico T1. . . . . . . . . . . . . . . . . p. 72

9 Distribuição de termos para dois tópicos semelhantes entre experimentos. p. 74

10 Estatística descritiva sobre valores do Coeficiente de Jaccard. . . . . . . p. 75

11 Distribuição de frequências em intervalos de classe para os Coeficientes

de Jaccard calculados. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75

12 Rótulos padronizados para as diversas Modelagens de Tópicos . . . . . p. 81

13 Valores das métricas para a modelagem de 50 tópicos . . . . . . . . . . p. 94

14 Coeficientes de Pearson calculados para identificar o grau de correlação

linear entre as métricas. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 96

15 Correspondência de tópicos entre os utilizados em nosso trabalho e os

utilizados em (RODRIGUEZ; WANG; KUANG, 2018) . . . . . . . . . . . . p. 108

Lista de abreviaturas e siglas

SQL – Structured Query Language

RDBMS – Relational Database Management Systems

API – Application Programming Interface

RDD – Resilient Distributed Dataset

DAG – Directed Acyclic Graph

JVM – Java Virtual Machine

IDE – Integrated Development Environment

LDA – Latent Dirichlet Allocation

UDF – User Defined Functions

Sumário

1 Introdução p. 13

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

1.3 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

1.4 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . p. 17

2 Revisão Bibliográfica p. 18

2.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.2 Apache Spark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.2.1 Resilient Distributed Dataset (RDD) . . . . . . . . . . . . . . . p. 23

2.2.2 Dataframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2.3 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

2.3 Modelagem de Tópicos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

2.3.1 Latent Dirichlet Allocation . . . . . . . . . . . . . . . . . . . . . p. 32

2.4 Stack Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3 Trabalhos Relacionados p. 40

3.1 Preparação do Corpus . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.2 Parametrização do LDA . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

3.3 Computação de Métricas e Análise de Resultados . . . . . . . . . . . . p. 55

4 Experimentos p. 63

4.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

4.2 Seleção de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

4.3 Pré-processamento de Textos . . . . . . . . . . . . . . . . . . . . . . . . p. 67

4.4 Aplicação do LDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68

4.5 Computação de métricas e análises . . . . . . . . . . . . . . . . . . . . p. 71

5 Resultados p. 80

5.1 Tópicos Identificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

5.2 Taxonomia de Dificuldades e Interesses . . . . . . . . . . . . . . . . . . p. 86

5.3 Importância Relativa dos Tópicos . . . . . . . . . . . . . . . . . . . . . p. 94

5.4 Comparação com Trabalho Relacionado . . . . . . . . . . . . . . . . . . p. 106

5.4.1 Preparação do Corpus . . . . . . . . . . . . . . . . . . . . . . . p. 106

5.4.2 Parametrização do LDA . . . . . . . . . . . . . . . . . . . . . . p. 107

5.4.3 Computação de Métricas e Análise de Resultados . . . . . . . . p. 107

6 Considerações Finais p. 110

6.1 Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . p. 111

6.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 112

6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 112

Referências p. 114

13

1 Introdução

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

simples denominado MapReduce (DEAN; GHEMAWAT, 2008).

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

10https://aws.amazon.com/pt/s311https://mesos.apache.org

22

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

Engenharia de Software, Geografia, Ciência Política, Ciências Médicas, etc (BLEI, 2012b).

Na Engenharia de Software, conforme levantamento realizado por Jelodar et al. (2018),

o LDA tem sido utilizado para análises de código-fonte, detecção de eventos, classificação

de imagens, sistemas de recomendação, classificação de emoções, categorização automática

de software, mineração de logs e muitas outras aplicações.

Segundo Treude e Wagner (2018), o LDA é a técnica mais frequentemente utilizada

para modelagem de tópicos. O termo Latent (latente), parte do nome LDA, foi utilizado

porque na Estatística uma variável que é inferida ao invés de ser diretamente observada

recebe este nome. No LDA, as variáveis observadas são os termos dos documentos, en-

quanto que os tópicos, a distribuição de termos por tópico e a distribuição de tópicos

por documento são variáveis escondidas (não-observadas, latentes). Já o termo “Dirich-

let” refere-se ao nome – atribuído em homenagem ao matemático Johann Peter Gustav

Lejeune Dirichlet – da distribuição de probabilidades utilizada no algoritmo para obter

aleatoriamente a distribuição de tópicos por documento. E o termo Allocation (aloca-

ção) significa que o algoritmo irá atribuir tópicos para os documentos e palavras para os

tópicos.

A intuição por trás do LDA é que os documentos são uma mistura de múltiplos tópicos

e os tópicos são grupos de palavras associadas a um assunto. Segundo Blei, Ng e Jordan

(2003) os termos que constituem um tópico são frequentemente relacionados semantica-

mente em razão da natureza da linguagem humana. No LDA, um documento é modelado

como uma distribuição de probabilidades sobre um conjunto de diferentes tópicos, ou seja,

documentos discutem múltiplos tópicos em diferentes proporções, enquanto que um tópico

é uma distribuição de probabilidades sobre um vocabulário fixo.

De acordo com Blei (2012a), LDA pode ser formalmente descrito com a seguinte

notação:

• Os tópicos são β1:K , onde βk é a distribuição de probabilidades para os termos do

vocabulário do corpus para o tópico k, com 1 6 k 6 K;

• As proporções de tópicos para os documentos são θ1:D, onde θd,k é a proporção do

tópico k no documento d, com 1 6 d 6 D;

33

• As atribuições de tópicos para os documentos são Z1:D, onde Zd,n é a atribuição de

tópico para a n-ésima palavra no documento d, com 1 6 d 6 D;

• As palavras observadas nos documentos são W1:D, onde Wd,n é a n-ésima palavra

no documento d, com 1 6 d 6 D;.

O trabalho do LDA é o de inferir as variáveis latentes (β1:K , θ1:D, Z1:D) considerando

as variáveis observadas (W1:D). A inferência sobre as variáveis desconhecidas é feita por

meio de inferência bayesiana (a posteriori), ou seja, calculando a probabilidade condici-

onal das variáveis escondidas dadas as variáveis observadas. Dessa forma, de acordo com

Blei (2012a), o problema computacional de inferência da estrutura de tópicos latente é o

problema de computar:

p(β1:K , θ1:D, Z1:D | W1:D) =p(β1:K , θ1:D, Z1:D,W1:D)

p(W1:D)

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-dataframe , spark-streaming , spark-r , spark-mllib , spark-ml ,

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

(VÁSQUEZ; DIT; POSHYVANYK, 2013; VENKATESH et al.,2016; REBOUÇAS et al., 2016; ROSEN; SHIHAB, 2016; ZOUet al., 2017; MARTINEZ, 2018; RODRIGUEZ; WANG; KUANG,2018)

Observações acerca da evolução e dastendências para os tópicos identificadosna modelagem de tópicos

(BARUA; THOMAS; HASSAN, 2012; BAJAJ; PATTABIRAMAN;MESBAH, 2014; ZOU et al., 2015; VENKATESH et al., 2016;KOCHHAR, 2016; ZOU et al., 2017; JOHRI; BANSAL, 2018;RODRIGUEZ; WANG; KUANG, 2018)

Entendimento sobre as questões quenão foram respondidas

(VÁSQUEZ; DIT; POSHYVANYK, 2013; ZOU et al., 2015; YANGet al., 2016; ROSEN; SHIHAB, 2016; ZOU et al., 2017; AHMED;BAGHERZADEH, 2018)

Identificação das questões mais relevan-tes para os tópicos identificados na mo-delagem

(ROSEN; SHIHAB, 2016; KOCHHAR, 2016; MARTINEZ, 2018)

Entendimento sobre os conceitos discu-tidos e os tipos de perguntas realizadas

(ALLAMANIS; SUTTON, 2013)

Identificação de usuários especialistasna comunidade

(TIAN et al., 2013)

Elaboração de hierarquia dos tópicosidentificados

(AHMED; BAGHERZADEH, 2018)

vas ao desenvolvimento de aplicações para dispositivos móveis (WANG; GODFREY, 2013;

VÁSQUEZ; DIT; POSHYVANYK, 2013; ROSEN; SHIHAB, 2016; MARTINEZ, 2018), tecnologias

da Web (BAJAJ; PATTABIRAMAN; MESBAH, 2014; VENKATESH et al., 2016), linguagens

de programação (REBOUÇAS et al., 2016; JOHRI; BANSAL, 2018), segurança da informa-

ção (YANG et al., 2016), teste de softwares (KOCHHAR, 2016), análise de requisitos não-

funcionais (ZOU et al., 2015, 2017), programação concorrente (AHMED; BAGHERZADEH,

2018), utilização de logs (GUJRAL et al., 2018), uso de frameworks (RODRIGUEZ; WANG;

KUANG, 2018), bem como análises para compreensão abrangente do conjunto de dados do

Stack Overflow como um todo (BARUA; THOMAS; HASSAN, 2012; WANG; LO; JIANG, 2013;

ALLAMANIS; SUTTON, 2013).

De forma semelhante, nosso trabalho propõe a modelagem de tópicos– mediante apli-

cação do LDA sobre corpus de documentos do Stack Overflow – para identificação das

dificuldades e questões de interesses de desenvolvedores de aplicações para Big Data com

Apache Spark.

42

3.1 Preparação do Corpus

Os resultados da modelagem probabilística de tópicos é substancialmente afetada pela

qualidade dos termos extraídos dos documentos. Diversos trabalhos (BARUA; THOMAS;

HASSAN, 2012; CHEN; THOMAS; HASSAN, 2016; YANG et al., 2016; JOHRI; BANSAL, 2018;

AHMED; BAGHERZADEH, 2018; PROTO et al., 2018) indicam que, na etapa de preparação

do dataset, é importante remover os ruídos – termos que não são relevantes para identificar

os tópicos dos documentos – que afetariam negativamente o resultado do LDA. Em geral,

na maior parte dos trabalhos (ver tabela 2 ao fim desta Seção), foi empregado algum tipo

de pre-processamento dos documentos, com a realização de tarefas como:

• Remoção de trechos de código-fonte. Segundo Barua, Thomas e Hassan (2012),

as palavras reservadas das linguagens de programação e os elementos de sintaxe de

códigos introduzem ruídos na fase de análise, atrapalhando a modelagem de tópicos.

Para o autor, grande parte do código-fonte presente no Stack Overflow é feito de

pequenos fragmentos, não havendo contexto suficiente para permitir a extração de

conteúdo significante;

• Remoção de Stop Words. Stop Words são termos comuns em todos os textos, tais

como artigos, conjunções, preposições, pronomes, etc. Para Barua, Thomas e Hassan

(2012), as Stop Words não ajudam na criação de tópicos significantes;

• Remoção de elementos de formatação. É comum realizar a remoção de tags HTML

(<b> , <p> e <a href="..."> por exemplo), uma vez que esse conteúdo adiciona

ruído no vocabulário;

• Remoção de caracteres de pontuação, símbolos especiais ou números, uma vez que

eles adicionam pouco valor na identificação de tópicos (YANG et al., 2016);

• Remoção de termos muito frequentes ou raros. Termos do vocabulário do corpus

muito frequentes (aparecem na maioria dos documentos) ou raros (aparecem em

poucos documentos) afetam negativamente o modelo de tópicos. Por exemplo, em

nosso trabalho não faz sentido considerarmos o termo “Spark” na modelagem LDA,

uma vez que a palavra está presente praticamente em todos os documentos, não

servindo para identificar tópicos. Segundo Proto et al. (2018), uma vez que o LDA

sorteia palavras do vocabulário considerando as probabilidades dos termos para cada

tópico, a exclusão de palavras que aparecem apenas uma vez no corpus reduz o ruído

no vocabulário e melhora a modelagem probabilística em geral;

43

• Realização de Stemming. Stemming é o processo de reduzir termos ao seu radical,

ou seja, transformar palavras em sua forma básica (por exemplo, “programming” e

“programmer ” são ambas transformadas em “program”). Isto reduz o tamanho do

vocabulário na medida em que agrupa palavras com a mesma raiz. O algoritmo de

Stemming de Porter (PORTER, 1980) é frequentemente utilizado para essa transfor-

mação.

Em nosso trabalho, utilizaremos todas as diversas tarefas identificadas como impor-

tantes no pré-processamento dos textos que compõem os documentos do corpus.

Ainda quanto à preparação do corpus, não há consenso acerca de quais dados extraídos

do Stack Overflow devem compor os documentos a serem processados pelo LDA. Em geral,

podemos identificar três estratégias:

1. Gerar documentos a partir do títulos das perguntas e dos corpos das per-

guntas e respostas. Essa estratégia foi utilizada em (BARUA; THOMAS; HASSAN,

2012; ALLAMANIS; SUTTON, 2013; VÁSQUEZ; DIT; POSHYVANYK, 2013; WANG; LO;

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-

DEH, 2018; JOHRI; BANSAL, 2018; MARTINEZ, 2018; RODRIGUEZ; WANG; KUANG, 2018).

Essa ferramenta permite personalização dos parâmetros, mas utiliza por padrão os valores

α = 50/K e β = 0, 01 para os hiperparâmetros e 1.000 para a quantidade de iterações.

No trabalho de Rodriguez, Wang e Kuang (2018), curiosamente, a ferramenta MALLET

também foi utilizada, ainda que os autores estudassem o uso do framework Apache Spark

– que possui implementações do LDA em suas bibliotecas de aprendizagem de máquina.

Diferentemente, nosso estudo empregará o próprio Spark em todo o processo computa-

cional. Enquanto que em 55,6% das publicações foi declarada a utilização da ferramenta

MALLET, em outros trabalhos (27,8%) não foi informado se alguma ferramenta em parti-

cular foi utilizada e outras ferramentas – Gensim, JGibbLDA e uma biblioteca em Python

– foram empregadas em um trabalho cada.

A tabela 3 sumariza os valores utilizados para parametrização do LDA nos trabalhos

relacionados. O valor N.D. (não discutido) é utilizado para indicar que a configuração do

parâmetro em questão não foi abordada no trabalho relacionado.

54

Tabe

la3:

Parâm

etrosutilizado

sno

LDA

nostrab

alho

srelacion

ados.

Referên

cia

Ferram

enta

utilizada

Número

de

tópicos

(K)

Hiperparâ-

metroα

Hiperparâ-

metroβ

Número

de

iterações

Justificativasparaesco-

lhados

parâm

etros

(AHMED;

BAGHERZA

-DEH,2

018)

MALL

ET

301,66

7(50/

K)

0,01

1.00

0Tr

abalho

sAnteriores

(ALL

AMANIS;

SUTTON,

2013

)MALL

ET

100e150

N.D

.N.D

.2.00

0Empiricamente

para

agra-

nularida

deespe

rada

(BAJA

J;PA

TTABIR

A-

MAN;M

ESB

AH,2

014)

N.D

.15

N.D

.N.D

.N.D

.N.D

.

(BARUA;THOMAS;

HAS-

SAN,2

012)

MALL

ET

40N.D

.N.D

.50

0Exp

erim

entação

(GUJR

ALet

al.,20

18)

Gensim

50N.D

.N.D

.N.D

.Exp

erim

entação

(JOHRI;BANSA

L,20

18)

MALL

ET

40N.D

.N.D

.1.00

0Exp

erim

entação

(KOCHHAR,2

016)

N.D

.8

N.D

.N.D

.N.D

.N.D

.(M

ARTIN

EZ,

2018

)MALL

ET

400,02

50,1

1.00

0Tr

abalho

sAnteriores

(REBOUÇASet

al.,20

16)

N.D

.25

N.D

.N.D

.N.D

.Exp

erim

entação

(RODRIG

UEZ;

WANG;K

U-

ANG,2

018)

MALL

ET

300,01

0,01

2000

N.D

.

(ROSE

N;S

HIH

AB,2

016)

MALL

ET

401,25

(50/

K)

0,01

900

Exp

erim

entação

(VÁSQ

UEZ;

DIT

;POSH

Y-

VANYK,2

013)

N.D

.20

0,01

0,01

1.00

0Exp

erim

entação

(VENKATESH

etal.,20

16)

N.D

.40

N.D

.N.D

.1.00

0Exp

erim

entaçãoetrab

alho

san

teriores

(WANG;L

O;J

IANG,2

013)

JGibbL

DA

5N.D

.N.D

.N.D

.N.D

.(W

ANG;G

ODFREY,2

013)

MALL

ET

100

N.D

.N.D

.N.D

.N.D

.(Y

ANG

etal.,20

16)

lda

(biblio

-teca

Pytho

n)30

N.D

.N.D

.N.D

.Algoritmos

genéticos

para

estimarK

(ZOU

etal.,20

15,2

017)

MALL

ET

202,5(50/

K)

0,01

1.00

0Exp

erim

entação

evalores

padrão

55

3.3 Computação de Métricas e Análise de Resultados

Para análise dos resultados do LDA, na grande maioria dos trabalhos foi realizada a

nomeação (atribuição de rótulos) dos tópicos inferidos pelo algoritmo. Dos 17 trabalhos

estudados, apenas Allamanis e Sutton (2013) não realizou a nomeação dos tópicos. Estes

autores apresentaram análises com base na modelagem de tópicos sobre vários corpora de

forma a categorizar as questões em duas visões ortogonais: uma visão sobre conceitos de

programação e outra sobre o tipo de pergunta (categorização quanto às razões que levaram

as perguntas a serem feitas). A análise foi realizada mediante comparação dos resultados

obtidos pela aplicação do LDA em diferentes corpus. O estudo identificou, por exemplo,

a semelhança entre os tipos de perguntas realizadas para as linguagens de programação

Java e Python.

Considerando que a maioria dos trabalhos relacionados atribuiu rótulos para signifi-

cação dos tópicos, podemos concluir que essa é uma atividade importante para a compre-

ensão do dataset do Stack Overflow. O método mais empregado foi o de atribuir um nome

para o tópico com base nos termos mais frequentemente associados a ele. Entretanto, a

interpretação dos tópicos é bastante subjetiva e requer muito esforço humano. Um método

de nomeação automática dos tópicos seria importante, mas esta é uma tarefa de difícil

realização cujos resultados são questionáveis. Apenas em (ZOU et al., 2015, 2017) buscou-se

rotular os tópicos de forma automática, utilizando-se, para tanto, listas de palavras-chave

sobre requisitos não-funcionais (RNF) que foram elaboradas com base no modelo de qua-

lidade ISO 91265. Os tópicos foram rotulados automaticamente a partir da identificação

de correspondência entre as palavras-chaves das listas e os termos mais frequentes do tó-

pico. Cada tópico pôde então ser rotulado com mais de um RNF quando da ocorrência

de múltiplas correspondências, ou foi associado ao rótulo “none”, quando não houve ne-

nhuma correspondência identificada. Para avaliar os resultados da rotulação automática,

quatro estudantes, pesquisadores da área de engenharia de software em nível PhD, rotu-

laram manualmente uma amostra do conjunto de dados. O resultado da rotulação manual

foi então comparado ao resultado da avaliação automática, o que, segundo os Zou et al.

(2015, 2017), validou o processo de rotulação automática. A rotulação automática de tó-

picos não será explorada em nosso trabalho em razão de que não termos como de antemão

identificar uma relação entre todos os possíveis tópicos latentes e palavras-chaves.

Nesse sentido, quase todos os trabalhos relacionados realizaram a atividade de rotula-

ção manual com base nos termos mais frequentes para cada um dos tópicos. Para além da5https://www.iso.org/standard/22749.html

56

análise dos termos frequentes, em alguns trabalhos (AHMED; BAGHERZADEH, 2018; BA-

RUA; THOMAS; HASSAN, 2012; ROSEN; SHIHAB, 2016; VÁSQUEZ; DIT; POSHYVANYK, 2013)

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-

SAN, 2012; VÁSQUEZ; DIT; POSHYVANYK, 2013; WANG; LO; JIANG, 2013; ROSEN; SHIHAB,

2016; REBOUÇAS et al., 2016; KOCHHAR, 2016; YANG et al., 2016; JOHRI; BANSAL, 2018;

RODRIGUEZ; WANG; KUANG, 2018; AHMED; BAGHERZADEH, 2018). Nesses trabalhos, iden-

tificamos a utilização das métricas relacionadas abaixo e que serão explicadas adiante.

1. Impacto do Tópico (Topic Impact – TI);

2. Participação do Tópico (Topic Share – TS);

3. Participação do Número de Visualizações do Tópico (View-count Topic Share –

V S);

4. Participação do Número de Comentários do Tópico (Comment-count Topic Share –

CS);

5. Participação do Número de Favoritos do Tópico (Favotire-count Topic Share – FS);

6. Participação da Pontuação do Tópico (Score-count Topic Share – SS);

7. Entropia do Tópico (Topic Entropy – TE);

8. Número de Documentos com Tópico Dominante (Number of Documents with Do-

minant Topic – NDDT );

9. Tópico Dominante (Dominant Topic – DT ).

Para compreender essas métricas, é preciso antes entender a definição do conceito

Topic Membership. Recapitulando, utilizamos o LDA para encontrar K tópicos (z, ..., zK)

em um corpus D, onde zk denota o k-ésimo tópico descoberto pelo LDA com (1 ≤ k ≤ K).

D é o conjunto de todos os documentos (|D| = N) e di denota o i-ésimo documento do

corpus com 1 ≤ i ≤ N (D = {d1, ..., dN}). Topic Membership, θ(di, zk), é o valor de

associação de um tópico particular zk para o documento di. É tarefa do LDA descobrir

esse valor para cada um dos tópicos em cada um dos documentos do corpus. A Tabela 5

ilustra um exemplo de matriz resultante do LDA com os valores de Topic Membership de

cada tópico zk para cada documento di, onde ∀i, k : ≤ θ(di, zk) ≤ e∑K

k= θ(di, zk) = .

Para esse resultado hipotético, temos, por exemplo, que o documento d2 trata do tópico

z1 na proporção de 83%, do tópico di na proporção de 5% e assim por diante.

A métrica Topic Impact (TI), utilizada no estudo de Johri e Bansal (2018), ajuda a

medir o impacto total de um tópico com base nas probabilidades atribuídas pelo LDA

58

Tabela 5: Exemplo de matriz de proporções tópicos para os documentos em um corpusde N documentos

z1 z2 z3 z4 z5d1 0,03 0,28 0,53 0,12 0,04d2 0,83 0,05 0,03 0,05 0,04d3 0,03 0,54 0,15 0,26 0,03d4 0,44 0,09 0,32 0,10 0,05d5 0,03 0,03 0,23 0,05 0,67d6 0,84 0,01 0,02 0,11 0,02d7 0,24 0,04 0,59 0,08 0,05... ... ... ... ... ...dN 0,06 0,18 0,25 0,25 0,27

para o tópico. A métrica foi utilizada para indicar o quão frequentemente um tópico foi

discutido em todo o dataset.

TI(zk) =∑di∈D

θ(di,zk)≥δ

θ(di, zk)

Apesar do uso da métrica Topic Impact ter sido explicitamente encontrada apenas

em (JOHRI; BANSAL, 2018), ideia semelhante é capturada pela métrica Topic Share (TS)

que foi definida por (BARUA; THOMAS; HASSAN, 2012) e também usada em (WANG; LO;

JIANG, 2013; REBOUÇAS et al., 2016; RODRIGUEZ; WANG; KUANG, 2018; JOHRI; BANSAL,

2018). A diferença é que enquanto Topic Impact mede a popularidade de um tópico

em valores absolutos, a métrica Topic Share utiliza valores proporcionais. Topic Share

mede a proporção de documentos que contém um determinado tópico. Busca-se aferir a

popularidade relativa de um tópico no corpus.

TS(zk) =

N

∑di∈D

θ(di,zk)≥δ

θ(di, zk)

Ambas as métricas – Topic Impact e Topic Share – utilizam um valor de limite inferior

(δ) que é o valor mínimo do Topic Membership para que um tópico seja considerado como

presente em um documento. O objetivo deste limiar é de manter apenas os principais

tópicos em cada documento ao tempo que tópicos pouco frequentes no documento não

seriam considerados e, dessa forma, informações ruidosas e erros probabilísticos seriam

evitados.

De acordo com Blei, Ng e Jordan (2003), em geral um documento terá entre 1 e 5 tó-

59

picos dominantes, cada qual com probabilidade de ocorrência (Topic Membership) de 10%

ou mais. Entretanto, segundo Barua, Thomas e Hassan (2012), devido a natureza proba-

bilística do LDA, algumas vezes são atribuídos pequenos valores de Topic Membership aos

tópicos. O valor mínimo δ utilizado nas métricas é portanto utilizado para remover ruído

dos valores de Topic Membership enquanto preserva apenas os tópicos dominantes em

cada documento. Nos estudos de Barua, Thomas e Hassan (2012), Johri e Bansal (2018),

Rebouças et al. (2016) foi utilizado δ = 0.10, enquanto que Rodriguez, Wang e Kuang

(2018) empregou δ = 0.05. Rebouças et al. (2016) declaram que manter apenas os tópicos

dominantes remove informações ruidosas, facilitando a análise dos resultados.

Conforme apresentado na Seção 2.4, para cada documento (post) do Stack Overflow,

o dataset também compreende alguns atributos quantitativos, tais como o número de

visualizações dos posts, o número de comentários, um valor de pontuação, o número de

vezes que o posts foi marcado como favorito e outros. Para Bajaj, Pattabiraman e Mes-

bah (2014), a contagem de visualizações é uma importante informação a ser observada na

medida em que muitos visitantes anônimos acessam o Stack Overflow sem participarem

ativamente, mas apenas utilizando as respostas para as questões previamente respon-

didas. Dessa forma, a contagem de visualizações pode representar a popularidade das

questões entre os desenvolvedores. Nesse sentido, alguns trabalhos (BAJAJ; PATTABIRA-

MAN; MESBAH, 2014; KOCHHAR, 2016; ROSEN; SHIHAB, 2016; YANG et al., 2016; AHMED;

BAGHERZADEH, 2018; RODRIGUEZ; WANG; KUANG, 2018) utilizaram o número de visu-

alizações de um post (vi) em suas análises, utilizando esse valor como peso associado ao

Topic Membership. Rodriguez, Wang e Kuang (2018) formalizou a métrica View-Count

Topic Share (V S) de definição abaixo.

V S(zk) =

V

N∑i=

θ(di, zk) · vi , V =N∑i=1

vi

De acordo com Rodriguez, Wang e Kuang (2018), a métrica View-Count Topic Share

sugere que se um documento di trata proporcionalmente θ(di, zk) sobre um tópico zk,

então o tópico zk deve ter gerado θ(di, zk) · vi visualizações. Essa mesma ideia – ponderar

o valor do Topic Membership por um dos atributos numéricos do documento no dataset

do Stack Overflow – foi aplicada nas métricas: Comment-count Topic Share (CS) que

utiliza o número de comentários no lugar do número de visualizações (YANG et al., 2016);

Favotire-count Topic Share (FS), que utiliza o número de favoritos (YANG et al., 2016;

AHMED; BAGHERZADEH, 2018); e Score-count Topic Share (SS) que utiliza o valor do

60

atributo Score (YANG et al., 2016; AHMED; BAGHERZADEH, 2018). De acordo com Ahmed

e Bagherzadeh (2018), intuitivamente, o tópico com valores maiores para as métricas

visualizações, marcações de favoritos e scores é o tópico mais popular.

Considerando que no dataset do Stack Oveflow também temos disponível o atributo

AnswerCount que informa a quantidade de respostas para uma pergunta, de forma análoga

as métricas aqui apresentadas, podemos também ponderar o valor do Topic Membership

para computar a métrica Answer-count Topic Share (AS), a qual propomos conforme a

definição apresentada abaixo, onde ai é o número de respostas a um post e A a quantidade

total de respostas para todo o corpus.

AS(zk) =

A

N∑i=

θ(di, zk) · ai , A =N∑i=1

ai

A métrica AS nos permite capturar os temas de maior engajamento na plataforma

Stack Overflow, na medida em que, ao invés do número de visualizações (vi), as probabi-

lidades dos tópicos são ponderadas com a quantidade de respostas (ai) dos documentos

associados ao tópico. Com esta métrica, buscamos identificar a popularidade dos temas

em que os desenvolvedores mais interagem ativamente.

A métrica Topic Entropy (TE) definida por Vásquez, Dit e Poshyvanyk (2013) busca

aferir o quão disperso é um tópico em todo o corpus, onde tópicos com baixa entropia são

concentrados em um conjunto de poucos documentos enquanto tópicos com alta entropia

estão dispersos por todo o corpus. Vásquez, Dit e Poshyvanyk (2013) consideraram os

tópicos com alta entropia como os principais tópicos discutidos.

TE(zk) = −N∑i=

θ(di, zk) · log θ(di, zk)

Outra métrica utilizada em análises realizadas em trabalhos relacionados é a chamada

Number of Documents with Dominant Topic (NDDT), conforme definida por Vásquez, Dit

e Poshyvanyk (2013). Um tópico k é chamado dominante em um documento d se e somente

se θk,d é a máxima probabilidade de tópico dentre todos os tópicos presentes em d.

NDDT (zk) =N∑i=

I(di, zk), I(di, zk) =

1 θ(di, zk) > θ(di, zj) ∀j 6= k

0 c.c.

61

Essa ideia de observar os tópicos dominantes de cada documento também foi utilizada

em (WANG; LO; JIANG, 2013; ROSEN; SHIHAB, 2016; RODRIGUEZ; WANG; KUANG, 2018).

Enquanto a métrica Number of Documents with Dominant Topic k, NDDT(k), resulta

na contagem do número de documentos em que o tópico k é dominante, a métrica Do-

minant Topic (DT ) formalizada por Rodriguez, Wang e Kuang (2018), obtém a mesma

informação, mas em valores proporcionais.

DT (zk) =

N

N∑i=

I(di, zk), I(di, zk) =

1 θ(di, zk) > θ(di, zj) ∀j 6= k

0 c.c.

Para além da computação de métricas e análises realizadas sobre dados resultantes da

aplicação do LDA, outras análises foram conduzidas sobre os dados do dataset do Stack

Overflow. Por exemplo, Yang et al. (2016) tratou também de encontrar os tópicos de

segurança da informação considerados difíceis, utilizando: (i) o tempo médio necessário

para que as questões de um tópico recebessem uma resposta marcada como aceita e (ii) a

proporção da quantidade média de respostas em relação ao número médio de visualizações

do tópico.

No que diz respeito a organização e apresentação dos resultados das análises, (RE-

BOUÇAS et al., 2016) agruparam manualmente os tópicos em 7 categorias. Nesse trabalho,

os valores das proporções de tópicos por documentos foram utilizados para identificar um

ranqueamento dos tópicos e das categorias inferidas. (AHMED; BAGHERZADEH, 2018) tam-

bém realizou o agrupamento de tópicos, o que resultou na construção de uma hierarquia

de tópicos de três níveis.

Quanto ao trabalho que mais se assemelha ao nosso (RODRIGUEZ; WANG; KUANG,

2018), os autores definiram manualmente os rótulos para os tópicos identificados e os

agruparam em categorias. Juntamente com a modelagem de tópicos, para aferir a popula-

ridade relativa dos tópicos foram computadas as métricas Topic Share, View-Count Topic

Share e Proportion of Documents with Dominant Topic k. (RODRIGUEZ; WANG; KUANG,

2018) trataram de aspectos da evolução histórica das discussões sobre Spark realizadas no

Stack Overflow desde o lançamento do Spark 1.0. Os resultados apresentados permitiram

conclusões como: (i) muitos tópicos identificados correspondem diretamente às bibliotecas

principais que são fornecidas juntamente com o Spark; (ii) as três principais preocupações

dos usuários Spark foram o desempenho, a conversão de tipos de dados e o uso da memória;

(iii) entrada e saída de dados, seja utilizando arquivos ou bancos de dados, também são

62

tópicos populares; (iv) a construção de projetos Spark e o tratamento de suas dependên-

cias também são questões relevantes; (v) métricas de popularidade dos tópicos indicaram

as categorias Spark SQL – formada pelos tópicos SQL, UDF, Agregações e Junções (joins)

– e Spark Core – formada pelos tópicos RDD e Partição – contemplam os tópicos mais

populares. (vi) dentre as bibliotecas, Spark SQL é a mais popular, seguida em ordem por

Spark Core, MLlib, Spark Streaming e GraphX. O interesse em Spark SQL tem crescido

com o tempo, enquanto tem decrescido para Spark Core; (vii) em termos de linguagens

de programação, Scala e Python geraram a maior parte das questões, seguidas por Java e

R em último. O interesse em Python tem crescido rapidamente, aproximando-se de Scala,

enquanto que as discussões acerca de Scala, Java e R permaneceram aproximadamente

constantes; (viii) Apache Kafka é a tecnologia de streaming mais popular, sendo usada

em conjunto com a biblioteca Spark Streaming; (ix ) bancos de dados construídos com

Apache Hive, Cassandra e HBase são frequentemente utilizados em conjunto com Spark.

Nosso trabalho pretende aprofundar a análise realizada por Rodriguez, Wang e Kuang

(2018), na medida em que propõe: (i) a construção de uma taxonomia das dificuldades

enfrentadas pelos desenvolvedores Spark; (ii) a aplicação do LDA em variados níveis

granularidade; (iii) a computação e comparação de outras métricas. Os resultados poderão

ser comparados de forma semelhante a realizada por Martinez (2018) que comparou os

resultados de seus estudos com os de Rosen e Shihab (2016), uma vez que ambos estudaram

o mesmo tema (mobile) em diferentes níveis de detalhes.

Com base no conhecimento adquirido pelo estudo dos trabalhos relacionados, utiliza-

remos os métodos, as técnicas e as métricas identificadas para alcançar nossos objetivos,

conforme metodologia e experimentos que apresentaremos no próximo capítulo.

63

4 Experimentos

Este trabalho de pesquisa busca identificar e classificar as principais dificuldades e

interesses dos desenvolvedores de aplicações para o processamento de Big Data utilizando

o Apache Spark. Para tanto, exploramos as informações do website Stack Overflow que

é a plataforma recomendada1 pelo projeto Apache Spark para que os utilizadores do

framework busquem por ajuda. Diante da inviabilidade da inspeção manual de todo o

conjunto de perguntas e respostas, utilizamos a modelagem probabilística de tópicos, me-

diante aplicação do algoritmo LDA, como forma de identificar os principais temas discuti-

dos pelos desenvolvedores na plataforma. Neste Capítulo, apresentaremos a metodologia

utilizada na condução do trabalho, bem como detalhes dos experimentos realizados.

4.1 Metodologia

Observando os trabalhos relacionados, é possível identificar um conjunto de passos

comumente empregados na condução desses estudos (BARUA; THOMAS; HASSAN, 2012;

WANG; LO; JIANG, 2013; BAJAJ; PATTABIRAMAN; MESBAH, 2014; REBOUÇAS et al., 2016;

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”,

“spark-dataframe”, “spark-streaming”, “spark-cassandra-connector”, “spark-graphx”,

67

“spark-submit”, “spark-structured-streaming”, “spark-observer”, “spark-csv”, “spark-

avro” e “spark-hive”.

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

T1 cluster (0,167) submit (0,105) yarn (0,099) local (0,064) mode (0,062)

T2 convert (0,143) string (0,142) map (0,119) list (0,111) key (0,092)

T3 time (0,097) window (0,074) input (0,047) zeppelin (0,046) version (0,036)

T4 creat (0,159) tabl (0,148) hive (0,147) partit (0,106) queri (0,091)

T5 array (0,112) add (0,064) variabl (0,054) oper (0,054) larg (0,044)

T6 stream (0,362) kafka (0,123) structur (0,064) messag (0,030) batch (0,027)

T7 error (0,293) fail (0,117) cassandra (0,104) collect (0,049) connector (0,046)

71

T8 class (0,089) except (0,086) lang (0,084) jar (0,056) found

T9 type (0,110) sparkr (0,057) date (0,047) vector (0,046) chang (0,041)

T10 save (0,092) issu (0,080) output (0,068) perform (0,067) access (0,066)

T11 process (0,087) result (0,066) method (0,060) transform (0,058) exist (0,045)

T12 read (0,214) write (0,136) csv (0,098) hdfs (0,082) parquet (0,077)

T13 hadoop (0,082) find (0,076) unabl (0,060) shell (0,058) instal (0,038)

T14 json (0,114) load (0,098) schema (0,061) custom (0,057) record (0,053)

T15 applic (0,095) connect (0,095) memori (0,077) executor (0,074) node (0,056)

T16 multipl (0,150) filter (0,090) base (0,074) count (0,068) group (0,066)

T17 task (0,067) mllib (0,060) model (0,053) calcul (0,039) word (0,029)

T18 work (0,117) log (0,063) api (0,053) differ (0,043) program (0,039)

T19 join (0,125) object (0,084) frame (0,071) udf (0,065) null (0,055)

T20 job (0,184) set (0,088) number (0,084) execut (0,064) context (0,026)

A partir da análise dos termos frequentes em cada um dos tópicos, podemos en-

tão utilizar o resultado do LDA para a identificação dos temas tratados no conjunto de

documentos. Essa identificação faz parte das tarefas executadas na próxima etapa da

metodologia.

4.5 Computação de métricas e análises

Nesta etapa são realizadas as análises dos resultados do LDA para responder às ques-

tões de pesquisa. Em nosso trabalho, utilizamos os resultados do LDA para identificação

dos principais tópicos discutidos sobre Apache Spark no Stack Overflow, além de construir

uma hierarquia dos tópicos identificados. Nesse sentido, conforme ilustrado na Figura 12

(4), realizamos três atividades: (i) rotulação dos tópicos; (ii) construção de hierarquia de

tópicos; (iii) computação de métricas e análises diversas.

A rotulação dos tópicos é a atribuição de um nome significante a um tópico a partir

dos seus termos mais frequentes. Esta é uma tarefa importante, mas bastante subje-

tiva. Para auxiliar na execução dessa tarefa, seguindo o método também empregado em

outros trabalhos relacionados (BARUA; THOMAS; HASSAN, 2012; VÁSQUEZ; DIT; POSHY-

VANYK, 2013; ROSEN; SHIHAB, 2016; AHMED; BAGHERZADEH, 2018), utilizamos exem-

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.

Tópico 7 para K=20 Tópico 1 para K=30mllib (0,056) mllib (0,076)model (0,049) model (0,067)input (0,039) featur (0,028)import (0,031) machin (0,028)packag (0,030) regress (0,026)sparklyr (0,030) random (0,026)extract (0,028) predict (0,025)test (0,023) pipelin (0,024)handl (0,022) train (0,024)featur (0,021) algorithm (0,019)regress (0,019) tree (0,017)random (0,019) al (0,016)predict (0,019) sampl (0,015)train (0,018) logist (0,014)member (0,016) kmean (0,014)algorithm (0,014) learn (0,014)item (0,013) label (0,013)document (0,013) recommend (0,013)tree (0,012) twitter (0,013)refer (0,012) metric (0,013)

identificados exigiria 15.500 verificações, recorremos ao uso do Coeficiente de Similaridade

de Jaccard (JACCARD, 1901). O Coeficiente Jaccard é uma medida do percentual de

sobreposição de dois conjuntos (A e B) definida como a cardinalidade da intersecção

dividida pela cardinalidade da união dos conjuntos.

J(A,B) =|A ∩B||A ∪B|

O Coeficiente de Jaccard é um valor entre 0 e 1, onde 0 indica nenhuma sobreposição

e 1 indica que os conjuntos são iguais. Nós automatizamos6 o cálculo do Coeficiente de

Jaccard para todas as possíveis combinações de tópicos entre os resultados dos experimen-

tos. Por exemplo, para os tópicos que tratam de Aprendizagem de Máquina e que foram

ilustrados na Tabela 9, o Coeficiente de Jaccard foi igual a 0,29, ou seja, 29% dos termos

utilizados para descrever cada tópico foram compartilhados. Esse valor foi suficiente para

indicar a similaridade entre esses dois tópicos. As Tabelas 10 e 11 resumem os valores

encontrados para os Coeficientes de Jaccard.6Planilhas eletrônicas foram criadas para computar os Coeficientes de Jaccard entre os conjuntos

formados pelos principais termos associados aos tópicos pelo LDA. Essas planilhas estão disponíveis paraconsulta em https://tiny.cc/sparkoverflow

75

Tabela 10: Estatística descritiva sobre valores do Coeficiente de Jaccard.

20X30

20X40

20X50

20X60

30X40

30X50

30X60

40X50

40X60

50X60

Qtd. = 0 432 613 798 977 936 1.238 1.514 1.644 1.994 2.621Qtd. > 0 168 187 202 223 264 262 286 356 406 379Qtd. Total 600 800 1.000 1.200 1.200 1.500 1.800 2.000 2.400 3.000Máximo 0,400 0,304 0,533 0,545 0,321 0,600 0,556 0,500 0,481 0,778Média 0,066 0,051 0,064 0,064 0,049 0,064 0,065 0,053 0,055 0,077Mediana 0,045 0,033 0,047 0,043 0,036 0,045 0,045 0,038 0,037 0,053

Tabela 11: Distribuição de frequências em intervalos de classe para os Coeficientes deJaccard calculados.

Classe Intervalo 20X30

20X40

20X50

20X60

30X40

30X50

30X60

40X50

40X60

50X60

0 0,0 |–| 0,0 432 613 798 977 936 1.238 1.514 1.644 1.994 2.6211 0,0 –| 0,1 142 171 174 197 243 224 251 325 367 3092 0,1 –| 0,2 22 11 24 19 18 31 25 23 28 563 0,2 –| 0,3 3 4 2 3 2 5 6 7 6 74 0,3 –| 0,4 1 1 1 2 1 1 2 0 4 25 0,4 –| 0,5 0 0 0 1 0 0 1 1 1 26 0,5 –| 0,6 0 0 1 1 0 1 1 0 0 17 0,6 –| 0,7 0 0 0 0 0 0 0 0 0 18 0,7 –| 0,8 0 0 0 0 0 0 0 0 0 19 0,8 –| 0,9 0 0 0 0 0 0 0 0 0 010 0,9 –| 1,0 0 0 0 0 0 0 0 0 0 0

Como era esperado, a maior parte das comparações entre tópicos dos experimentos

resultou em coeficientes iguais a zero (linha “Qtd. = 0”), pois não há nenhum termo

compartilhado entre os conjuntos comparados. Logo, não é necessário realizar nenhuma

verificação de inconsistência entre rótulos para esses 12.767 casos uma vez que os tópicos

são de fato distintos. Ainda assim uma quantidade considerável de combinações de tópicos

apresentaram pelo menos uma palavra em comum (linha “Qtd. > 0”), totalizando 2.733

casos. A Tabela 11 apresenta a distribuição de frequências em intervalos de classe para os

Coeficientes de Jaccard encontrados para esses casos.

Analisando os casos encontrados nas possíveis combinações de tópicos entre os expe-

rimentos para 20x30 e 20x40, verificamos empiricamente que, para os casos enquadrados

na Classe 1 (intervalo 0,0 –| 0,1), os poucos termos compartilhados entre os tópicos ana-

lisados não foram suficientes para indicar semelhança entre os temas enquadrados nesses

tópicos. Já para alguns casos da classe 2 – onde o Coeficiente de Jaccard foi entre 0,1 e

76

0,2 – identificamos que em alguns casos havia correspondência entre os temas. Logo, con-

centramos os esforços para garantir a consistência na rotulação dos tópicos para os casos

em que o Coeficiente de Jaccard entre os conjuntos de termos fosse superior ao valor 0,1.

Dessa forma, inspecionamos manualmente em detalhes 330 casos, comparando os termos

associados a cada tópico e garantindo que o mesmo rótulo fosse empregado quando os

tópicos tratassem de um mesmo tema.

Inicialmente, tínhamos a expectativa que essa abordagem também pudesse ser utili-

zada para rotular automaticamente os tópicos de um novo experimento com LDA a partir

de rótulos e conjuntos de termos associados. Por exemplo, uma vez definidos os rótulos

para os tópicos encontrados no experimento de 20 tópicos, identificaríamos a sobreposição

entre os conjuntos de termos desses tópicos e os conjuntos de termos para os novos tópicos

encontrados no experimento de 30 tópicos e, definindo um valor limite inferior para o Co-

eficiente de Jaccard, atribuiríamos automaticamente rótulos para os tópicos encontrados

nesse novo experimento. Entretanto, a grande quantidade de casos em que os tópicos tra-

tavam de temas distintos ainda que o Coeficiente de Jaccard fosse relativamente relevante

(acima de 0,1), mostrou que essa abordagem não seria eficaz. Seria necessário utilizar um

valor limite mínimo de cerca de 0,3 o que resultaria em pouquíssimos casos onde a rotu-

lação pudesse ser realizada automaticamente. A Figura 13 ilustra o inter-relacionamento

entre tópicos para os casos em que o Coeficiente de Jaccard entre os conjuntos formados

pelos principais termos de cada tópico foi um valor maior que 0,3. Considerando este valor

como limiar, podemos perceber que seria possível rotular automaticamente apenas 12 tó-

picos (20%) do experimento de identificação de 60 tópicos com base nos rótulos utilizados

para os experimentos de granularidade maiores K = (20, 30, 40, 50).

Muito embora não tenha sido eficaz utilizar o Coeficiente de Jaccard para rotular

tópicos automaticamente, seu uso favoreceu bastante a realização do trabalho de inspeção

manual para garantir a consistência na rotulação, uma vez que reduzimos nosso escopo

de análise de 15.500 casos de verificação para 330.

Após o trabalho de consolidação para obter consistência entre os rótulos empregados,

identificamos então o conjunto de rótulos empregados em todos os experimentos. A relação

dos rótulos será apresentada e discutida no Capítulo 5. Inicialmente identificamos 41 temas

distintos para rotular os tópicos. Posteriormente, aumentamos para 64 temas a partir da

inclusão de informações adicionais como discutimos a seguir. Esse conjunto de temas foi

então utilizado para realizarmos a segunda tarefa da quarta etapa de nossa metodologia,

ou seja, a construção da hierarquia de tópicos.

77

K=20 K=30 K=40 K=50 K=60

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

Figura 13: Inter-relacionamento entre tópicos dos experimentos para Coeficiente de Jac-card maior que 0,3.

78

Durante a nomeação dos tópicos, identificou-se a necessidade de relacionar informa-

ções adicionais acerca dos principais subtemas tratados em cada tópico. Por exemplo, o

rótulo “Cluster (YARN)” foi utilizado para indicar que o vigésimo tópico (no experimento

onde K = 20) trata do tema “Cluster” com destaque para o subtema “YARN”. Nessa

caso, “YARN” foi identificado como um conceito de destaque naquele tópico, pois mui-

tas das principais questões relacionadas ao tópico tratam de Clusters Spark com YARN,

mas “YARN” não poderia ser utilizado como rótulo do tópico uma vez que esse tópico

não trata exclusivamente de YARN, mas engloba também outras questões relacionadas

com Clusters Spark. Outro exemplo é o rótulo “Bancos de Dados (Cassandra, Mongodb)”

que foi utilizado para identificar os tópicos 24 para K = 40, 5 para K = 50 e 34 para

K = 60. Nesse caso, esses tópicos tratavam de questões relacionadas ao uso de Bancos

de Dados em programas Spark, especialmente quanto o uso dos sistemas Cassandra e

Mongodb. A adição da informação de subtema em cada rótulo é importante para o deta-

lhamento da taxonomia a ser gerada, pois além do tema geral tratado em cada tópico,

temos conhecimento adicional acerca dos conceitos importantes naquele tema específico.

Considerando as informações adicionais advindas da identificação de subtemas para

cada tópico, identificamos 64 conceitos distintos que então foram utilizados na construção

da hierarquia, de forma que a taxonomia foi enriquecida com 23 novos conceitos em relação

ao caso em que utilizássemos apenas os 41 rótulos distintos para identificar o tema geral

de cada tópico, um acréscimo de aproximadamente 56%.

No decorrer do processo de construção de uma estrutura de árvore que indicasse as re-

lações hierárquicas entre cada um dos conceitos, identificamos que os conceitos poderiam

ser agrupados em sete grandes grupos temáticos, quais sejam: (i) Abstração de Dados;

(ii) Abstração de Processos; (iii) Bibliotecas; (iv) Gerenciamento de Arquivos; (v) Inte-

gração e Execução; (vi) Linguagens; e (vii) Problemas. O resultado desse agrupamento e

construção de hierarquia será apresentado e discutido no Capítulo 5.

Por fim, para a terceira tarefa da etapa de computação de métricas e análises da

metodologia, construímos um novo programa Spark. Esse programa, cujo código-fonte está

disponível livremente7, realiza a computação das métricas, ora identificadas nos trabalhos

relacionados (Seção 3.3), para o nosso conjunto de dados estudado. Para tanto, utilizamos

os dados contidos nos modelos de tópicos gerados nos experimentos com o LDA para

as várias granularidades de tópicos, bem como valores dos atributos de cada uma das

perguntas sobre Spark registradas no dataset do Stack Overflow.7https://github.com/zidenis/spark-overflow

79

Os resultados obtidos a partir da computação das diversas métricas possibilita a aná-

lise quantitativa dos tópicos identificados quanto a sua popularidade relativa. No próximo

capítulo apresentaremos os valores computados para cada uma das métricas e discutiremos

o conhecimento que podemos extrair desses resultados.

80

5 Resultados

Neste Capítulo, apresentaremos os resultados obtidos da aplicação do LDA sobre o

conjunto de dados extraído do Stack Overflow para fins de identificação das principais

dificuldades e interesses de desenvolvedores de aplicações Spark. Apresentaremos e dis-

cutiremos os resultados obtidos sob três aspectos: (i) os tópicos que foram identificados

a partir do resultado da aplicação do LDA (Seção 5.1); (ii) a taxonomia de dificulda-

des e interesses de desenvolvedores Spark construída com base em conceitos identificados

na modelagem de tópicos (Seção 5.2); (iii) a importância relativa dos tópicos identifi-

cada a partir da computação de métricas (Seção 5.3). Por fim, na Seção 5.4, tratamos da

comparação dos resultados obtidos com outro trabalho relacionado.

5.1 Tópicos Identificados

Conforme discutido no Capítulo 4, realizamos o processo de rotulação de 200 tópi-

cos identificados pelo LDA em diferentes níveis de granularidade. Os resultados com-

pletos da aplicação do LDA sobre o corpus de títulos das perguntas sobre Spark para

granularidades de 20, 30, 40, 50 e 60 tópicos estão disponíveis para consulta em https:

//tiny.cc/sparkoverflow. Para esses 200 tópicos foram concebidos 84 rótulos que estão

relacionados na Tabela 12, onde identificamos em qual tópico dos experimentos cada ró-

tulo foi associado. Por exemplo, o rótulo Ambiente de Execução não foi identificado

na modelagem LDA para 20 tópicos, mas foi identificado no tópico 18 para K = 30, tópico

17 para K = 40, tópico 22 para K = 50 e tópicos 52 e 54 para K = 60. Adicionalmente,

o tema Ambiente de Execução também foi identificado no tópico 8 para K = 30,

mas, nesse caso, o subtema Notebooks foi adicionado ao rótulo do tópico. Conforme

discutido ao final do Capítulo 4, utilizamos a forma Tema (Subtema) na rotulação dos

tópicos para identificar informações adicionais acerca dos principais subtemas tradados

em alguns tópicos. A adição da informação de subtema nos rótulos é importante para

o detalhamento da taxonomia, pois além do tema geral tratado em cada tópico, temos

81

conhecimento adicional acerca dos conceitos importantes naquele tema específico. Dessa

forma, consideramos que o tema Ambiente de Execução foi identificado nos rótulos

tanto do tópico 8 quanto do tópico 18 para o experimento de modelagem de 30 tópicos.

Percebe-se também que alguns tópicos presentes em granularidades menores não fo-

ram identificados em granularidades maiores. Por exemplo, o tópico Memória que foi

identificado no tópico 1 para K = 20 e no tópico 15 para K = 30, não fora identificado

no experimento K = 40. Esse resultado é devido a natureza aleatória do LDA, onde cada

execução do LDA produz resultados diferentes, ainda que a mesma configuração seja uti-

lizada. Ao aplicar o LDA em vários níveis de agrupamento de tópicos, reduzimos o risco

de não identificar tópicos importantes.

Tabela 12: Rótulos padronizados para as diversas Modelagens de Tópicos

Rótulo K=20 K=30 K=40 K=50 K=60

Ambiente de Execução 18 17 22 52,54

Ambiente de Execução (Notebooks) 8

Bancos de Dados 3 56

Bancos de Dados (Cassandra, Hive) 24

Bancos de Dados (Cassandra, Mon-

godb)

24 5 34

Build (Dependências) 34 42 4

Cloud Amazon 2

Cluster 19

Cluster (Bancos de Dados) 26

Cluster (Cloud Amazon) 20 46

Cluster (Execução de Jobs) 2

Cluster (Standalone, YARN, Kafka) 19

Cluster (Standalone, YARN) 4

Cluster (Standalone) 35 7

Cluster (YARN) 20

Conversão de Tipos 10 11 15

Dataframes 33 15

Dataframes (Operações) 5,9 23,29 6,8,28 6,33,38 11,28,41,55

Datasets 2 48

Desempenho 16

Desempenho (Duração da Execução) 24 53

Desempenho (Particionamento) 13

Entrada e Saída 3 29

Entrada e Saída (Bancos de Dados) 36

Entrada e Saída (HDFS) 4 4

Entrada e Saída (Parquet) 14 1

82

Entrada e Saída (Serialização) 14

Erros e Exceções 10,18 6 12,31,39,40 13,44 5,13

Erros e Exceções (Broadcast Varia-

bles)

31

Erros e Exceções (Conversão de Ti-

pos)

21

Erros e Exceções (Python) 47

Erros e Exceções (Serialização) 30

Execução de Jobs 16 16 28,41 3

Execução de Jobs (Dependências) 16

Execução de Jobs (YARN, Cloud

Amazon)

11

Execução de Jobs (YARN) 40

Formatos de Arquivos (CSV) 37 14

Formatos de Arquivos (JSON, CSV,

Parquet)

3

Formatos de Arquivos (JSON) 7 29

Formatos de Arquivos (Parquet) 21

Hadoop 21 1

Hadoop (HDFS) 10

HBase 9 6

HDFS 4 37

Hive 3 60

Hive (Notebooks, Jupyter) 39

Indefinido 22 7,23 8,26,30,46 8,9,16,18,

20,22,24,32,

33,35,44,45,

47,48

Iterações 57

Joins 13 50

Joins (Datasets, RDD) 15

JSON 27 25

Machine Learning 7 1 20,26 12,21 19,42,43

Machine Learning (Trabalhando com

Vetores e Matrizes)

15 35

Manipulação de Datas e Tempo 38 20,36

Memória 1 15 19 49

Operações (Agrupamento, Contagem) 40

Operações (Agrupamento) 17 51

Operações (Contagem) 26

Operações (Filtragem, Contagem) 22

83

Operações (Filtragem) 17 7 17

Operações (UDF, Window Functions) 19

Operações (UDF) 28

Particionamento 12 18 49 27,58

Pyspark 8 29 18 30

Pyspark (Trabalhando com Vetores e

Matrizes)

9

Python ( Notebooks, Zeppelin, Jupy-

ter)

59

Python (Bancos de Dados, Cassandra) 11

Python (Build) 5

Python (Notebooks, Zeppelin, Jupy-

ter)

30

RDD 34 23

RDD (Duração da Execução) 1

RDD (Joins) 31

RDD (Operações Chave-Valor) 27 9 37,50 38

RDD (Operações) 12 25

Scala 14 13 5 17 25

Serialização 25

Spark SQL 11 32 45 36

Spark SQL (Hive) 2

Spark Streaming 10

Spark Streaming (Kafka) 6 14 23 2

Trabalhando com Vetores e Matrizes 12

UDF 27 39

Window Functions 32 10

Zeppelin 43

Ao fim da rotulação dos tópicos, considerando a forma Tema (Subtema), um total

de 36 temas foram identificados. O gráfico da Figura 14 apresenta dados dos resultados

obtidos para os itens Tópicos Indefinidos, Temas Únicos, Novos Temas e Temas

Complementares cujos significados discutiremos a seguir.

• Tópicos Indefinidos diz repeito a quantidade de tópicos em que não foi possível

estabelecer consenso em relação à atribuição de um nome significante. Para esses ca-

sos, atribuímos o rótulo indefinido. No decorrer dos experimentos, percebemos

que à medida em que foi aumentada a granularidade de tópicos, também foi aumen-

tado a quantidade de tópicos indefinidos, com aumento expressivo para aumentou

consideravelmente no experimento de 60 tópicos;

84

Figura 14: Dados do processo de rotulação de tópicos nos experimentos

• Temas Únicos informa a quantidade de temas distintos identificados em um expe-

rimento, considerando que um tema pode ter sido observado em mais de um tópico

no experimento. Por exemplo, no experimento de 20 tópicos, os temas Cluster,

Dataframes e Erros e Exceções foram observados em mais de um tópico,

portanto, um total de 17 temas únicos foram identificados para K = 20. Dessa

forma, percebemos que a quantidade de temas únicos cresceu junto com o acrés-

cimo da granularidade, estabilizando-se para as granularidades de 50 e 60 tópicos

na quantidade de 30 temas, valor equivalente a 83% do conjunto total de 36 temas

identificados para todas as granularidades;

• Novos Temas informa a quantidade de novos temas identificados no experimento

em relação ao conjunto de temas já identificados nos experimentos de menor gra-

nularidade. Por exemplo, no experimento de 30 tópicos, foram identificados 4 novos

temas que ainda não tinham sido identificados no experimento de 20 tópicos; no

experimento de 40 tópicos, foram identificados 8 novos temas que não tinham sido

identificados nos experimentos de 20 e 30 tópicos; e assim por diante;

• Temas Complementares informa a quantidade de temas que não foram iden-

tificados em uma granularidade específica em relação ao conjunto total de temas

identificados em todas granularidades.

Outras informações acerca do resultado da rotulação de tópicos em cada experimento

85

são apresentados abaixo.

• Para K = 20, foram atribuídos rótulos para todos os tópicos, ou seja, nenhum tópico

foi rotulado como indefinido. No total, dezessete temas únicos foram identifica-

dos uma vez que os temas Cluster, Dataframes e Erros e Exceções foram

utilizados para na identificação de dois tópicos distintos cada. Os temas identificados

foram: Cluster, Dataframes, Desempenho, Entrada e Saída, Erros e

Exceções, Execução de Jobs, Formatos de Arquivos, Joins, Machine

Learning, Memória, Operações, Pyspark, Python, RDD, Scala, Spark

SQL e Spark Streaming.

• Para K = 30, apenas um tópico foi rotulado como indefinido e dez tópicos

repetiram temas. Além de temas previamente identificados para K = 20, os se-

guintes novos temas foram identificados: Ambiente de Execução, Bancos de

Dados, Datasets e Particionamento;

• Para K = 40, dois tópicos (5%) foram marcados como indefinido e doze tópicos

repetiram temas. Dos 26 temas únicos identificados, oito foram novos em relação

aos experimentos anteriores: Build, Conversão de Tipos, Hadoop, HDFS,

Hive, JSON, Manipulação de Datas e Tempo e Serialização.

• Para K = 50, quatro tópicos (8%) foram marcados como indefinido e dezes-

seis tópicos repetiram temas. Dos 30 temas únicos identificados, Cloud Amazon,

HBase, UDF, Window Functions e Zeppelin foram novos. Do conjunto

total de temas, os seis que não foram identificados nessa granularidade foram:

HDFS, Iterações, Joins, Python, Serialização e Trabalhando

com Vetores e Matrizes;

• Para K = 60, ocorreu um grande aumento na quantidade de tópicos cujo tema

foi indefinido, quatorze no total (23,3%). Dezesseis tópicos repetiram temas. Dois

novos temas (Iterações e Trabalhando com Vetores e Matrizes) fo-

ram identificados e seis (Cloud Amazon, Datasets, JSON, Manipulação

de Datas e Tempo, Serialização e Zeppelin) não foram identificados.

Conforme discutido na Seção 4.4, os hiperparâmetros do LDA em nossos experimentos

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. Dessa forma, o

valor do hiperparâmetro α foi diminuindo na medida em que se aumentava a quantidade

86

de tópicos considerados no experimento. Valores altos para α indicam que cada documento

contém uma mistura da maior parte dos tópicos, enquanto que valores baixos indicam que

cada documento tende a tratar de poucos tópicos de forma mais específica. A utilização

de α = 50/K é coerente, na medida em que ao aumentar a granularidade de tópicos,

espera-se que os tópicos agrupem documentos mais específicos.

Em face dos dados aqui expostos, nossos experimentos mostraram que a granularidade

de 50 tópicos apresentou os melhores resultados para a modelagem de tópicos. Entretanto,

conforme discutido na Seção 5.2, utilizamos todos os resultados dos diversos experimentos

na construção da taxonomia de dificuldades e interesses.

5.2 Taxonomia de Dificuldades e Interesses

A partir dos 84 rótulos atribuídos, identificamos um total de 52 conceitos distintos

para construção da taxonomia de dificuldades e questões de interesse relativas ao desenvol-

vimento de aplicações para o processamento de Big Data utilizando o framework Apache

Spark. Esses conceitos foram extraídos a partir da informação de temas e subtemas con-

tidos em cada um dos rótulos. Cabe destacar que 22 desses conceitos foram identificados

em todos os níveis de granularidade, ou seja, provavelmente seriam identificados ainda

que tivéssemos realizado apenas uma aplicação do LDA. São eles: Bancos de Dados,

Cassandra, Cluster, Dataframes, Entrada e Saída, Erros e Exceções,

Execução de Jobs, Formatos de Arquivos, HDFS, Hive, JSON, Kafka,

Machine Learning, Operações, Particionamento, Pyspark, Python, RDD,

Scala, Spark SQL, Spark Streaming e YARN.

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

Rótulo TS V S AS CS FS SS TE DT

Ambiente de Execução 2,34% 2,78% 2,38% 2,39% 2,81% 2,94% 2,60% 2,19%

Bancos de Dados 2,17% 1,80% 2,06% 2,18% 2,05% 2,04% 2,22% 1,89%

Bancos de Dados (Cassandra,

Mongodb)

1,97% 1,14% 1,82% 1,80% 1,47% 1,59% 1,98% 2,20%

Build (Dependências) 1,73% 1,56% 1,69% 1,76% 1,38% 1,66% 1,92% 1,19%

Cloud Amazon 1,74% 1,18% 1,66% 1,55% 1,65% 1,80% 1,82% 1,56%

Cluster (Standalone, YARN) 2,93% 2,81% 2,68% 3,07% 3,67% 3,48% 2,77% 3,14%

Conversão de Tipos 2,04% 2,51% 2,31% 2,11% 1,53% 1,57% 2,26% 2,05%

Dataframes 1,34% 1,28% 1,38% 1,31% 1,26% 1,29% 1,50% 1,66%

Dataframes (Operações) 5,94% 8,14% 6,77% 5,55% 6,22% 6,02% 7,42% 6,07%

Datasets 1,60% 1,35% 1,62% 1,75% 1,56% 1,49% 1,87% 2,11%

Desempenho 1,73% 1,47% 1,61% 2,04% 1,97% 1,84% 1,99% 1,39%

95

Desempenho (Duração da Exe-

cução)

2,14% 1,37% 1,85% 2,33% 2,37% 2,23% 2,28% 1,81%

Entrada e Saída 2,40% 2,99% 2,57% 2,46% 2,61% 2,40% 2,87% 2,47%

Entrada e Saída (Parquet) 1,55% 1,39% 1,45% 1,77% 1,61% 1,57% 1,76% 2,40%

Erros e Exceções 4,76% 5,24% 4,61% 5,64% 4,35% 4,94% 4,75% 4,46%

Erros e Exceções (Python) 2,50% 2,43% 2,39% 2,69% 1,84% 2,14% 3,03% 2,17%

Execução de Jobs 3,86% 3,35% 3,65% 3,89% 3,60% 3,81% 4,26% 3,83%

Formatos de Arquivos (CSV) 1,91% 2,44% 2,03% 2,06% 1,79% 1,86% 2,28% 2,58%

Hadoop (HDFS) 1,95% 2,18% 1,96% 1,91% 2,13% 2,08% 2,20% 1,68%

HBase 1,37% 1,28% 1,30% 1,29% 1,32% 1,20% 1,53% 1,55%

Hive (Notebooks, Jupyter) 1,99% 1,72% 1,88% 2,00% 1,70% 1,61% 2,14% 2,88%

JSON 1,83% 1,80% 1,86% 1,65% 1,58% 1,55% 2,02% 2,03%

Machine Learning 3,67% 2,91% 3,43% 3,34% 3,58% 3,68% 3,77% 3,18%

Machine Learning (Traba-

lhando com Vetores e Matrizes)

1,86% 1,37% 1,77% 1,52% 1,81% 1,93% 1,83% 1,76%

Manipulação de Datas e Tempo 2,79% 3,16% 3,10% 2,65% 2,41% 2,42% 3,38% 3,15%

Memória 2,14% 1,78% 1,95% 2,20% 2,65% 2,72% 2,13% 1,90%

Operações (Agrupamento,

Contagem)

1,50% 1,68% 1,67% 1,48% 1,43% 1,42% 1,63% 1,95%

Operações (Filtragem) 1,64% 1,83% 1,79% 1,76% 1,45% 1,40% 1,92% 1,76%

Particionamento 1,76% 2,17% 1,75% 1,65% 3,21% 2,83% 1,97% 1,90%

Pyspark 1,84% 1,71% 1,74% 1,67% 1,67% 1,68% 2,68% 0,61%

RDD 2,28% 3,20% 2,54% 2,42% 2,56% 2,58% 2,64% 4,08%

RDD (Joins) 1,74% 1,67% 1,72% 1,65% 1,67% 1,72% 1,77% 2,44%

RDD (Operações Chave-Valor) 3,24% 3,72% 3,58% 3,18% 3,45% 3,23% 3,89% 4,06%

Scala 2,49% 2,43% 2,74% 2,81% 1,91% 1,85% 3,07% 3,46%

Spark SQL 2,22% 2,58% 2,31% 2,06% 2,11% 2,07% 2,83% 2,07%

Spark Streaming (Kafka) 3,01% 1,72% 2,59% 2,88% 2,61% 2,57% 2,69% 3,72%

UDF 1,64% 1,71% 1,63% 1,56% 1,56% 1,58% 2,16% 0,87%

Window Functions 2,18% 2,15% 2,20% 2,13% 2,32% 1,99% 2,41% 2,11%

Zeppelin 1,56% 1,49% 1,45% 1,51% 1,51% 1,64% 1,77% 1,94%

Para auxiliar na análise dos resultados, calculamos os Coeficientes de Correlação de

Pearson (PEARSON, 1920) entre pares de métricas. A Tabela 14 apresenta os resultados

obtidos. Percebemos que existe uma forte correlação linear entre algumas métricas –

TS ×AS, TS × CS, TS × TE, V S ×AS, AS × TE, FS × SS, por exemplo – de forma

que o resultado da análise será semelhante ao considerarmos estes pares de métricas.

A seguir, apresentamos gráficos com o ranqueamento dos temas de acordo com cada

uma das métricas calculadas. O ranking é apresentado por temas, pois não sabemos a

proporção do valor para os subtemas em cada tópico. Por exemplo, para o tópico Cluster

96

Tabela 14: Coeficientes de Pearson calculados para identificar o grau de correlação linearentre as métricas.

TS V S AS CS FS SS TE DTTS 90,93% 97,89% 97,49% 92,20% 94,71% 96,64% 85,70%V S 90,93% 96,32% 88,77% 88,53% 88,96% 94,85% 82,49%AS 97,89% 96,32% 94,51% 90,64% 91,91% 98,41% 87,26%CS 97,49% 88,77% 94,51% 88,99% 92,73% 92,79% 84,81%FS 92,20% 88,53% 90,64% 88,99% 98,49% 89,04% 79,28%SS 94,71% 88,96% 91,91% 92,73% 98,49% 90,16% 79,45%TE 96,64% 94,85% 98,41% 92,79% 89,04% 90,16% 81,89%DT 85,70% 82,49% 87,26% 84,81% 79,28% 79,45% 81,89%

(Standalone, YARN) não sabemos o quanto de uma métrica diz respeito ao subtema

Standalone ou ao subtema YARN. Dado que os subtemas não são considerados para a

análise, os valores das métricas são somados nos casos de rótulos com temas idênticos e

subtemas distintos. Por exemplo, os valores das métricas para os rótulos Dataframes e

Dataframes (Operações) são combinados, de forma que o valor da métrica TS para

o tema Dataframes é igual a 7,28%.

Figura 24: Distribuição de temas de acordo com a métrica TS.

Na Figura 24, apresentamos os resultados para a métrica TS (Topic Share) que busca

medir o impacto total de um tópico com base nas probabilidades atribuídas pelo LDA a

cada tópico. Por essa métrica, percebemos a tendência de que os temas de maior impacto

são aqueles que tratam de assuntos mais gerais (Dataframes, Erros e Exceções,

RDD, Machine Learning, Bancos de Dados, Entrada e Saída, Desempenho)

enquanto que assuntos específicos (HBase, Zeppelin, UDF, Cloud Amazon) apresen-

tam valores menores.

97

Figura 25: Distribuição de temas de acordo com a métrica V S.

A métrica V S (View-count Topic Share) busca obter a popularidade relativa dos

tópicos na medida em que pondera as probabilidades dos tópicos com a contagem de

visualizações dos documentos associados ao tópico. A contagem de visualizações é uma

informação importante, pois muitos desenvolvedores utilizam o Stack Overflow como uma

fonte de consulta, apenas utilizando as respostas para as questões previamente respondi-

das. Portanto, a quantidade de visualizações captura quais perguntas são mais populares

dentre aquelas cadastradas na plataforma. Em contraste com os resultados obtidos para

a métrica TS (Figura 24), os valores para a métrica V S (Figura 25) nos permite observar

que, embora os temas Dataframes, Erros e Exceções e RDD tenha impacto seme-

lhante, os tópicos referentes às abstrações de dados são mais populares, especialmente

o tema Dataframes; o tema Spark Streaming (décimo tema de maior impacto) é o

tema que mais perde posições no ranqueamento quando considerada a popularidade por

visualizações; os temas Formatos de Arquivos e Particionamento são os temas

que mais subiram posições no ranqueamento. Muito embora o valor do Coeficiente de

Correlação de Pearson para as métricas seja alto entre as métricas TS e V S (90,93%),

os resultados obtidos são consideravelmente distintos, uma vez que apenas quatro te-

mas (Dataframes, Cluster, Build e Datasets) mantiveram suas posições no

ranqueamento.

Nosso trabalho propõe (Seção 3.3) a métrica AS (Answer-count Topic Share) para

capturar os temas de maior engajamento na plataforma Stack Overflow, na medida em

que, ao invés do número de visualizações, as probabilidades dos tópicos são pondera-

das com a quantidade de respostas dos documentos associados ao tópico. Com esta mé-

98

Figura 26: Distribuição de temas de acordo com a métrica AS.

trica, buscamos identificar a popularidade dos temas em que os desenvolvedores mais

interagem ativamente. O valor do Coeficiente de Correlação de Pearson entre V S e AS

(96,32%) evidencia que os resultados são semelhantes, entretanto ocorreram várias mu-

danças no ranqueamento de temas, com destaque para: os temas Spark Streaming,

Scala e Cloud Amazon subiram, respectivamente, nove, cinco e quatro posições; o

tema Particionamento foi o que perdeu mais posições no ranqueamento.

De forma semelhante a métrica AS, trabalhos relacionados ao nosso (YANG et al., 2016;

AHMED; BAGHERZADEH, 2018) propuseram métricas que ponderam as probabilidades dos

tópicos com outros atributos (quantidade de comentários, quantidades de marcações de

favorito e pontuação) dos documentos.

Figura 27: Distribuição de temas de acordo com a métrica CS.

99

A métrica CS (Comment-Count Topic Share) pondera a probabilidade do tópico com

a quantidade de comentários associados ao documento. Os comentários8 em perguntas ou

respostas no Stack Overflow devem ser utilizados para: solicitar informações adicionais ao

autor da pergunta ou resposta; fazer criticas construtivas que guiem o autor na construção

de posts melhor elaborados; ou adicionar informações adjacentes ao posts como, por exem-

plo, links para perguntas relacionadas. Os resultados desta métrica (Figura 27) estão mais

fortemente correlacionados com a métrica TS, com Coeficiente de Correlação de Pearson

igual a 97,49%. Observa-se uma significante mudança nos resultados: o tema Erros e

Exceções passou para a primeira posição no ranqueamento. Devido a isso, entendemos

que as questões dos desenvolvedores que buscam soluções para as falhas encontradas no

desenvolvimento de aplicações Spark são mais frequentemente acompanhadas de comen-

tários para melhores esclarecimentos. Comparando CS com TS, os temas que perderam

mais posições (três) foram Spark Streaming e Cloud Amazon, e os temas que mais

subiram no ranqueamento foram Build (quatro posições) e Datasets (cinco posições).

Figura 28: Distribuição de temas de acordo com a métrica FS.

O Stack Overflow permite que os seus usuários marquem posts como favoritos, de

forma que o desenvolvedor pode registrar as questões que deseja acompanhar para saber

quando ocorrerem mudanças (edições, novas respostas e comentários) ou para referências

futuras. No dump do Stack Overflow, para cada post, encontramos a quantidade de vezes

em que ele foi marcado como favorito, de forma que esse valor também pode ser utilizado

para ponderar a probabilidade de um tópico em um documento. Essa ideia é empregada na

métrica FS (Favorite-count Topic Share) cujos resultados estão apresentados na Figura

28.8https://stackoverflow.com/help/privileges/comment

100

Uma outra forma de interação dos desenvolvedores com o Stack Overflow é mediante

um sistema de votação9. Ele permite que os desenvolvedores com boa reputação – aqueles

que participam ativamente na comunidade com perguntas e respostas – indiquem se um

post é bom ou ruim. Dessa forma, a comunidade pode retratar a qualidade das perguntas

e respostas, de forma que o bom conteúdo apareça no topo das buscas e o conteúdo ruim

seja eventualmente excluído. Com base nessa votação, uma pontuação é atribuída para

cada post. A pontuação dos posts também é um valor presente no dump do Stack Overflow,

de forma que pode podemos utilizá-la para computar uma nova métrica, a métrica SS

(Score-count Topic Share). Os resultados para a métrica SS estão apresentados na Figura

29.

Figura 29: Distribuição de temas de acordo com a métrica SS.

As métricas FS e SS apresentam uma visão qualitativa dos temas na medida em

que retrata os documentos escolhidos pelos usuários da plataforma. De fato, os resultados

dessas métricas são bastante similares, com o maior Coeficiente de Correlação de Pearson

calculado (98,49%). Por essas métricas, os seis temas mais importantes (Dataframes,

Erros e Exceções, RDD, Machine Learning, Bancos de Dados e Entrada e

Saída nessa ordem) mantiveram inalteradas suas posições no ranqueamento. O tema que

mais ganhou posições foi Build que saiu da 29a para a 23a posição. Os temas que mais

perderam posições, quatro posições cada, foram Hive, JSON e Datasets.

A métrica Topic Entropy (TE) indica o quão disperso é um tópico, ou seja, tópicos

com alta entropia estão presentes em um maior número de documentos do que tópi-

cos com baixa entropia, que estão concentrados em menos documentos. Vásquez, Dit e9https://stackoverflow.com/help/why-vote

101

Poshyvanyk (2013) consideraram os tópicos com alta entropia como os principais tópicos

discutidos. De acordo com os Coeficientes de Correlação de Pearson calculados entre as

métricas, os resultados da métrica TE (Figura 30) são mais semelhantes aos resultados

da métrica AS (Figura 26). Em ambos os casos, os temas mais relevantes foram, nessa

ordem, Dataframes, Erros e Exceções, RDD, Machine Learning e Entrada

e Saída.

Figura 30: Distribuição de temas de acordo com a métrica TE.

Por fim, como última métrica computada para aferir a importância relativa dos tópi-

cos, apresentamos, na Figura 31, os resultados para a métrica DT (Dominant Topic) que

indica a proporção de documentos em que um tópico é dominante. Tópico dominante é

aquele mais discutido em um documento, ou seja, o tópico com a máxima probabilidade

dentre todos os tópicos presentes no documento.

A métrica DT apresenta os resultados mais distintos em relação às outras métricas,

com Coeficientes de Correlação de Pearson mais baixos. Por essa métrica, rapidamente

observamos um grande destaque para o tema RDD que ficou em primeiro lugar no ran-

queamento com boa margem para os demais temas. Contrastando a métrica DT com a

métrica TE, podemos perceber os tópicos em que os seus documentos são mais focados,

uma vez que identificaremos os temas dominantes – pela métrica DT – que estão con-

centrados proporcionalmente em poucos documentos – pela métrica TE. Por exemplo,

o tema Hive é relativamente pouco disperso (22a posição pela métrica TE) e é um tó-

pico dominante em considerável parte dos documentos (14a posição pela métrica DT ).

Analisando inversamente, destaca-se que o tema Pyspark está relativamente disperso

em muitos documentos (15a posição na métrica TE) mas está na ultima posição para a

102

Figura 31: Distribuição de temas de acordo com a métrica DT .

métrica de tópicos dominantes.

Figura 32: Distribuição dos grupos de temas.

Na Figura 32, apresentamos os resultados das métricas de acordo com os grupos cri-

ados para classificação de conceitos na taxonomia (Seção 5.2). O valor de cada métrica é

o resultado da soma dos percentuais obtidos para cada um dos temas contidos no grupo.

Pela análise dos grupos, o grupo de maior destaque é o Integração e Execução.

103

Essa informação é interessante, pois, conforme observamos anteriormente na análise da

importância dos temas individualmente, os temas de maior destaque foram dos grupos

Abstração de Dados (temas Dataframes e RDD) e Falhas (tema Erros e Exce-

ções). Portanto, percebemos que o grupo Integração e Execução é composto por

vários temas que no agregado são relevantes.

De forma a permitir uma visualização unificada da importância relativa dos temas de

acordo com as diversas métricas computadas, concebemos a Figura 33. Por esse gráfico,

observamos que a posição do tópico no ranqueamento de importância depende da métrica

escolhida, ainda que algumas das métricas estejam fortemente correlacionadas. Essa cons-

tatação não fora abordada por nenhum dos trabalhos relacionados, possivelmente porque

suas análises se restringiram a poucas métricas, enquanto que nosso estudo buscou analisar

todas as métricas até então propostas, além de propor a métrica AS.

Figura 33: Importância dos temas de acordo com as diversas métricas aferidas.

Devido a grande quantidade de temas apresentados na Figura 33, a visualização das

métricas aferidas fica prejudicada em alguns casos. Dessa forma, concebemos as Figuras

34, 35, 36, 37, 38, 39 e 40 que apresentam métricas para cada grupo de temas identificados

na taxonomia.

104

Figura 34: Métricas para o grupo Abstraçãode Dados.

Figura 35: Métricas para o grupo Abstraçãode Processos.

Observando a Figura 34, percebemos facilmente que o grupo Abstração de Dados

engloba dois temas (Dataframes e RDDs) que estão sempre entre os mais importantes,

independentemente das métricas utilizadas. Para o grupo Abstração de Processos

(Figura 35), destaca-se o tema Operações.

Figura 36: Métricas para o grupo Bibliote-cas. Figura 37: Métricas para o grupo Falhas.

Em relação ao grupo Bibliotecas (Figura 36), destaca-se o tema Machine

Learning. O tema Spark SQL ganha destaque se considerarmos que UDF e Windows

Functions são sub-temas dele, conforme pode ser observado na taxonomia. Para o grupo

Falhas, conforme discutido anteriormente, em nossos experimentos não foram obtidos

agrupamentos que possibilitassem uma classificação mais detalhadas do grupo. Na Figura

37, percebemos facilmente que o tema Erros e Exceções é de grande importância.

105

Figura 38: Métricas para o grupo Gerencia-mento de Arquivos.

Figura 39: Métricas para o grupo Lingua-gens .

Para o grupo Gerenciamento de Arquivos, destaca-se o tema Entrada e

Saída e para o grupo Linguagens percebemos que o uso da linguagem Scala é mais

importante em relação à linguagem Python.

Figura 40: Métricas para o grupo Integração e Execução.

A importância dos temas considerando apenas o grupo Integração e Execução

é apresentada na Figura 40. Considerando apenas esse grupo, os temas de maior des-

taque são Bancos de Dados, Desempenho, Execução de Jobs, Cluster e

Ambiente de Execução. O tema Particionamento é destaque considerando ape-

nas as métricas FS e SS que capturam as preferências dos desenvolvedores quanto as

106

melhores perguntas e respostas registradas no Stack Overflow.

Em conclusão, podemos observar que existe um conjunto de temas mais impor-

tantes, considerando que esses temas estão consistentemente nas primeiras posições do

ranqueamento para as diversas métricas computadas. Dessa forma, concluímos que os

temas mais importantes são: Dataframes, Erros e Exceções, RDD, Machine

Learning, Bancos de Dados, Entrada e Saída, Desempenho, Execução

de Jobs, Operações e Cluster.

5.4 Comparação com Trabalho Relacionado

Como visto no Capítulo 3, o artigo de Rodriguez, Wang e Kuang (2018) apresentou

o trabalho de pesquisa mais semelhante ao nosso, uma vez que aplicou o LDA sobre

dados do Stack Overflow para obter conhecimento acerca do uso do Spark. Dessa forma,

é importante ressaltar as diferenças entre os trabalhos.

Em nosso trabalho, nos concentramos no conhecimento obtido a partir da modela-

gem de tópicos com LDA, enquanto que Rodriguez, Wang e Kuang (2018) utilizaram,

adicionalmente, informações associadas as tags das perguntas. Nós construímos aplica-

ções Spark para automatizar várias etapas da metodologia como a seleção dos dados, a

preparação do corpus, a aplicação do LDA e a computação de métricas. Diferentemente,

Rodriguez, Wang e Kuang (2018) utilizaram o MALLET e não discutiram suas razões

para tanto. Nós consideramos importante empregar o próprio Spark para obtermos ainda

mais experiência acerca do uso do framework.

Da mesma forma que estruturamos o Capítulo 3, nesta seção apresentaremos a com-

paração entre os trabalhos sob três perspectivas: (i) preparação do corpus ; (ii) parame-

trização do LDA; (iii) computação de métricas e análise dos resultados.

5.4.1 Preparação do Corpus

O corpus utilizado no trabalho de Rodriguez, Wang e Kuang (2018) compreendeu

36.659 perguntas obtidas do Stack Overflow em 1 de novembro de 2017, enquanto que

nosso corpus de trabalho compreendeu 49.377 perguntas (acréscimo de cerca de 35%)

obtidos a partir do dump de 02 de dezembro de 2018.

Em (RODRIGUEZ; WANG; KUANG, 2018), cada documento foi formado pelo título e pelo

107

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ém o corpo

das respostas. Percebemos que a rotulação dos tópicos foi mais ágil para o corpus cujos

documentos foram compostos estritamente pelos títulos das perguntas. Considerando que

a identificação dos assuntos discutidos nos tópicos identificados pelo LDA requer extenso

esforço de análise humana, prosseguimos com o processo de rotulação de tópicos apenas

para o corpus de títulos.

Em ambos os trabalhos, tarefas de pré-processamento de textos (remoção de tags

HTML, remoção de trechos de código, remoção de stop words, aplicação de stemming)

foram semelhantemente empregadas.

5.4.2 Parametrização do LDA

Rodriguez, Wang e Kuang (2018) abordaram brevemente a configuração do LDA.

O LDA foi utilizado em (RODRIGUEZ; WANG; KUANG, 2018) para descobrir 30 tópicos.

Os autores não discutiram as razões para a escolha desse valor para o parâmetro K.

Diferentemente, nós realizamos diversos experimentos aplicando LDA para 20, 30, 40,

50 e 60 tópicos. Pelo resultados apresentados na Seção 5.1, entendemos que K = 50

apresentou melhores resultados.

Quanto aos hiperparâmetros α e β, Rodriguez, Wang e Kuang (2018) utilizaram os

valores padrão da ferramenta MALLET α = β = 0, 01. Em nosso trabalho, o valor do

parâmetro α variou de acordo com o número de tópicos do experimento (α = 50/K) e

o valor de β foi igual a 0,01. Utilizamos essa configuração pois foram os valores mais

utilizados dentre os trabalhos relacionados e, segundo Biggers et al. (2012) trata-se de

uma heurística padrão de fato.

5.4.3 Computação de Métricas e Análise de Resultados

Os tópicos identificados também foram manualmente rotulados por Rodriguez, Wang

e Kuang (2018) a partir dos principais termos associados. Conseguimos estabelecer cor-

respondência direta entre 17 dos rótulos utilizados, conforme apresentado na Tabela

15. Cinco rótulos (Cassandra, YARN, Aggregate, Kafka, e Notebook) uti-

lizados em (RODRIGUEZ; WANG; KUANG, 2018) foram identificados como subtemas em

nosso trabalho. Não encontramos correspondência para 7 rótulos (Code, Compare,

108

Graph, Link, Log, Problem, e Trace) identificados por Rodriguez, Wang e Kuang

(2018) e 19 rótulos utilizados em nosso trabalho (Ambiente de Execução, Cloud

Amazon, Dataframes, Datasets, Execução de Jobs, Hadoop, HBase, HDFS,

Iterações, JSON, Manipulação de Datas e Tempo, Operações, Pyspark,

Python, Scala, Serialização, Trabalhando com Vetores e Matrizes,

Window Functions, e Zeppelin).

Tabela 15: Correspondência de tópicos entre os utilizados em nosso trabalhoe os utilizados em (RODRIGUEZ; WANG; KUANG, 2018)

Tópicos identificados em

nosso trabalho

Tópicos identificados em

(RODRIGUEZ; WANG; KUANG, 2018)

Bancos de Dados DB

Build Build

Cluster Cluster

Conversão de Tipos Conversion

Desempenho Performance

Entrada e Saída Access

Erros e Exceções Error

Formatos de Arquivos Format

Hive Hive

Joins Join

Machine Learning ML, Model

Memória Memory

Particionamento Partition

RDD RDD

Spark SQL SQL

Spark Streaming Streaming

UDF UDF

No que se refere ao uso de métricas para identificação da importância relativa dos

tópicos, Rodriguez, Wang e Kuang (2018) utilizaram as métricas Topic Share (TS), View-

count Topic Share (V S) e Dominant Topic (DT ) para descobrir as questões comumente

enfrentadas pelos desenvolvedores, as bibliotecas e os gerenciadores de clusters populares,

as linguagens de programação preferidas e as tecnologias frequentemente utilizadas com

Spark.

Portanto, nosso trabalho complementa o estudo apresentado em (RODRIGUEZ; WANG;

KUANG, 2018), na medida em que aprofunda a discussão sobre o uso do LDA para mo-

delagem de tópicos do Stack Overflow e apresenta resultados mais detalhados acerca da

utilização do Apache Spark. Além disso, apresentamos outras contribuições como: a ta-

109

xonomia dos principais conceitos relacionados ao uso do Spark; estudo abrangente dos

trabalhos de pesquisa relacionados; programas Spark para automatizar a aplicação do

LDA e computar métricas sobre dados do Stack Overflow;

Neste Capítulo, discutimos os resultados obtidos a partir da modelagem de tópicos

de dados do Stack Overflow acerca do uso do framework Apache Spark. Apresentamos

os tópicos identificados (Seção 5.1), a taxonomia de dificuldades e interesses construída

(Seção 5.2), a análise quanto a importância relativa dos tópicos (Seção 5.3) e concluímos

com a comparação dos resultados obtidos com outro trabalho relacionado (Seção 5.4). No

próximo capítulo, apresentaremos nossas considerações finais.

110

6 Considerações Finais

Este capítulo apresenta a conclusão desta pesquisa de mestrado, suas limitações e

discute as perspectivas de trabalhos futuros.

Neste trabalho, investigamos quais são os temas mais importantes para os usuários do

Apache Spark e propusemos uma taxonomia de dificuldades e questões de interesse acerca

do uso do framework. A identificação das questões importantes baseou-se na modelagem

de tópicos – mediante uso do algoritmo LDA – a partir de dados obtido do Stack Overflow

e na computação de métricas. O LDA permitiu o agrupamento das perguntas do Stack

Overflow em tópicos, provendo listas de termos frequentemente utilizadas em cada tópico

e que foram utilizadas para identificar os tópicos discutidos.

Com base no conhecimento obtido pelo estudo sistemático dos trabalhos relacionados,

várias configurações foram exploradas na execução do LDA. Esse conhecimento foi im-

portante – e pode ser reutilizado em outros trabalhos – para identificar como o algoritmo

foi parametrizado e aplicado, além de indicar como os dados de entrada foram preparados

e como os resultados obtidos foram analisados. Aplicamos o LDA para modelar tópicos

em várias granularidades de tópicos. Ao contrário de nossas expectativas, o aumento do

número de agrupamentos do LDA – maior granularidade – não necessariamente resultou

no refinamento dos temas identificados.

Os tópicos identificados foram então utilizados para extrair os conceitos empregados

na construção da taxonomia. Um possível uso da taxonomia é para organizar e produzir

guias de práticas de desenvolvimento de aplicações Spark, pois a implementação de uma

aplicação para processamento de Big Data utilizado Spark não é uma tarefa trivial. Ainda,

ela poderia ser utilizada como base de um sistema para facilitar a exploração das principais

perguntas do Stack Overflow associadas a cada conceito da taxonomia. Outra possibilidade

é a de ajudar na definição de casos de teste úteis para verificação de programas Spark.

Do conjunto total de 52 conceitos distintos da taxonomia, 22 conceitos foram iden-

tificados em todos os experimentos, independente da granularidade de tópicos do LDA.

111

Consequentemente, consideramos os seguintes conceitos como destaques: Bancos de

Dados, Cassandra, Cluster, Dataframes, Entrada e Saída, Erros e

Exceções, Execução de Jobs, Formatos de Arquivos, HDFS, Hive, JSON,

Kafka, Machine Learning, Operações, Particionamento, Pyspark, Python,

RDD, Scala, Spark SQL, Spark Streaming e YARN.

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.