O documento compara o desempenho do Hadoop MapReduce e do Apache Spark para cargas de trabalho distribuídas, usando duas tarefas: wordcount distribuído em um conjunto de dados de 18GB e clusterização K-means em um conjunto de dados de livros da Amazon de 15GB. O Spark mostrou desempenho superior, especialmente para tarefas iterativas como K-means. A configuração correta é importante para o desempenho, e o Spark se beneficiou da alocação dinâmica de recursos.

1. Hadoop MapReduce and Apache Spark:
Comparing Performance for Distributed
Workloads
Felipe Almeida (falmeida1988@gmail.com)
Rosângela Oliveira (rosangelaoliveira4@yahoo.com.br)
Bancos de Dados não Convencionais 2015/02
Prof. Alexandre Assis

2. Estrutura
● Motivação
● Ambiente
● Trabalho Preliminar
● Dados utilizados
● Pré-processamento
● Experimentos
● Experimento 1
● Experimento 2
● Conclusões
● Lições aprendidas 2

3. Motivação
Comparar Hadoop MapReduce e Spark em tarefas
distribuídas, em especial workloads iterativos.
1ª tarefa: Wordcount distribuído
2ª tarefa: Clusterização K-means (ingênua)
3

4. Ambiente
Os experimentos foram executados em instâncias EC2
do tipo m3.xlarge com:
● 4 processadores
● 15GB RAM
● 80GB de SSD storage.
4

5. Ambiente
Configuração de cada nó Hadoop
5
YARN_RESOURCEMANAGER_HEAPSIZE 2396
YARN_PROXYSERVER_HEAPSIZE 2396
YARN_NODEMANAGER_HEAPSIZE 2048
HADOOP_JOB_HISTORYSERVER_HEAPSIZE 2396
HADOOP_NAMENODE_HEAPSIZE 1740
HADOOP_DATANODE_HEAPSIZE 757
mapreduce.map.java.opts -Xmx1152m
mapreduce.reduce.java.opts -Xmx2304m
mapreduce.map.memory.mb 1440
mapreduce.reduce.memory.mb 2880

6. Ambiente
Configuração de cada nó Spark (Setup 1)
Configuração de cada nó Spark (Setup 2)
A configuração com a alocação dinâmica habilitada só é possivel no Yarn.
6
spark.dynamicAllocation.enabled true
--num-executors 2
spark.executor.cores 1
spark.executor.memory 4096
spark.dynamicAllocation.enabled false

7. Trabalho Preliminar
Dois datasets foram utilizados com o objetivo de
fixar o entendimento do ambiente Hadoop e Spark.
● Text 8: dataset de +- 100Mb, utilizado para
executar o Wordcount local.
● Billion word - dataset de +- 4Gb, utilizado para
executar o Wordcount local e no ambiente EMR da
Amazon.
7

8. Dados utilizados: Wordcount
Na fase 1 foi utilizado um dataset composto por:
● Informações de pesquisas efetuadas na internet;
● 408 arquivos.txt;
● Tamanho total de 18Gb.
8
Estrutura das Linhas

9. Dados Utilizados: K-means
Dataset de avalização de produtos vendidos na Amazon.
Originado na UCSD; o dataset é composto por:
● Tamanho total de 60Gb+ (nós usamos 15Gb)
● Total de 24 categorias de produtos (usamos 1 - livros)
● Formato Json
● Abrangendo o período de maio 1996 - julho 2014.
9
Exemplo de uma
review

10. Pré-processamento
Normalização e limpeza no dataset das reviews da
Amazon, com o objetivo de:
● Obter features das avaliações
● Agrupar características consideradas relevantes
● Adequar os dados para o K-means
● Featurização
● Normalização
Foi usado SparkSQL para a limpeza e formatação dos
dados.
10

11. Pré-processamento
Features númericas selecionadas:
1. Média da avaliação
2. Tamanho do texto da avalição
3. Número de “estrelas” dado
4. Review feita em dia útil
5. Review feita em fim de semana
6. Review feita durante o dia
7. Review feita durante a noite
11

12. Pré-processamento
Usamos também o Spark para o pré-processamento:
12
Cria um novo DataFrame com os
dados pré-tratados

13. Experimentos
Os experimentos foram feitos com o intuito de
comparar o Hadoop MapReduce com o Spark no que
tange à performance e na capacidade de lidar com
grande volume de dados.
Foi usado Amazon EMR para ajudar na reprodutibilida-
de e para facilitar o desenvolvimento dos programas.
13

14. Experimentos
r
14
Script para criar um cluster na Amazon EMR Interface da Amazon EMR

15. Experimento 1
15
Execução do Wordcount Distribuido - UMBC DATASET 18Gb

16. Experimento 1
Ao utilizar a opção Dynamic Allocation do spark, o mesmo
demonstrou uma melhora significativa de desempenho:
16

17. Experimento 1
17

18. Experimento 2
O K-means pode ser distribuído da seguinte forma:
Em cada iteração, cada nó pega as suas amostras e os
centros dos clusters atuais para decidir a que cluster cada
amostra pertence. (mapper)
Feito isso, os reducers pegam os centros dos clusters e as
respectivas amostras e calculam novos centros para os
clusters.
18

19. Experimento 2
19

20. Experimento 2
20

21. Conclusões
Em geral, mais nós apresentaram um ganho grande em perfor-
mance, como era esperado.
O Spark tem, em geral, performance superior ao Hadoop, sobre-
tudo em tarefas iterativas, mas também em tarefas de poucas
passadas (como o WordCount).
Utilizar uma configuração com mais nós pode, a partir de um
determinado momento, não causar muita melhora, principalmen-
te quando se analisa o custo-benefício.
21

22. Conclusões
O algoritmo K-means convergiu relativamente rápido;
● Em geral, menos de 10 iterações
22

23. Lições Aprendidas
● Configurações podem fazer muita diferença.
● Se o seu projeto usa outras bibliotecas, precisa colocar
todas dentro do Jar que você manda para o cluster.
● Usamos sbt-assembly para montar os Jars do Spark e do
Hadoop
● As versões adequadas devem ser utilizadas a fim de
evitar quebra de pacote.
23

24. Lições Aprendidas
● Em vez de baixar arquivos grandes para a sua máquina
e fazer upload para o S3, é melhor criar uma outra
máquina EC2, baixar o arquivo nessa máquina e fazer o
upload de lá pois, se os dois estiverem na mesma área
AWS, a transferência é muito mais rápida.
● Testes locais devem ser feitos com pelo menos duas
threads, pois há muitos erros que só aparecem quando
há mais de um nó.
24

25. Lições Aprendidas
● UDFs (User-defined Functions) são formas ótimas de se
ir incrementando um DataFrame e podem ser usadas
para vários fins:
● Extração de features derivadas
● Adição de dados
● Normalização
● etc.
25

26. Referências
O código utilizado em todas as etapas está em https:
//github.com/queirozfcom/hadoop_spark_ml_comparison
26