Benchmarking CSV vs Parquet

Nos dias de hoje, provavelmente o formato mais utilizado para troca de dados é o CSV (Comma-separated values) e embora aqui no Brasil estejamos mais acostumados com a separação por ponto e vírgula me estranha muito um formato que existe desde a década de 70 perdurar até hoje.

Não dá para reclamar muito do bom e velho CSV, afinal é bem melhor do aquelas bases de dados do governo com separação fixa (por número de caracteres) ou as malditas planilhas de Excel.

Deve existir algo melhor, tem que existir algo melhor!

Em 2010 alguns caras do Google publicaram um artigo propondo uma nova forma de analisar dados chamada ‘Dremel’ onde segundo eles:

“Dremel is a scalable, interactive ad-hoc query system for analysis of read-only nested data. By combining multi-level execution trees and columnar data layout, it is capable of running aggregation queries over trillion-row tables in seconds. The system scales to thousands of CPUs and petabytes of data, and has thousands of users at Google. In this paper, we describe the architecture and implementation of Dremel, and explain how it complements MapReduce-based computing. We present a novel columnar storage representation for nested records and discuss experiments on few-thousand node instances of the system.”

Em outras palavras, Dremel é um sistema de consultas de bases gigantescas com seu formato em colunas e como sendo complementar a computação baseada em Map-reduce.

Bacana, mas eles não publicaram o código fonte, então os caras do Twitter juntamente com a Cloudera criaram em 2012 algo similar baseado no paper do Google chamado “Parquet” o qual em abril de 2015 se tonou um ‘Top Level Project’ na Apache foundation.

A ideia mesma, armazenar os dados em colunas de forma que nas consultas aos dados somente as colunas necessárias sejam escaneadas, isso trás basicamente alguns benefícios:

1 – Como somente as colunas necessárias são escaneadas as consultas tendem a ser muito mais rápidas

2 – É possível otimizar o fluxo de dados entre o processador e a memória (http://www.cidrdb.org/cidr2005/papers/P19.pdf)

3 – Os dados são mais facilmente comprimidos, pois os dados em forma de colunas são mais semelhantes entre si do que em linhas, imagine que você tem uma base de  7.000.000 de linhas, mas a coluna de UF tem 20 e poucos valores possíveis, sexo tem dois ou três valores, cor/raça tem meia dúzia e etc.

4 – Os dados em ‘Parquet’ já vem mapeados. Em um CSV nunca sabemos que tipo de valores estão contidos em uma coluna, se são texto, números, fatores, datas etc, no Parquet os dados já vem mapeados o que facilita demais! Isso me lembra a criação do MP3, que diferente do CD cada MP3 contém dados sobre o seu álbum como o artista, nome do álbum e até onde está a capa do álbum.

Não vou entrar muito em detalhes, caso contrário o post vai ficar muito longo, mas deixo a apresentação para quem tiver curiosidade.

 

E que vantagens isso trás?

Aproveitando meus posts anteriores onde já utilizo as bases de dados do Enem resolvi testar o formato para ver se realmente temos alguma vantagem sobre o csv.

O teste é simples, para diferentes tamanhos de amostra de dados do ENEM  (10.000 , 50.000, 100.000, … 300.000 linhas) faço a seguinte consulta:

Qual o percentual de alunos que não realizou a prova de Matemática por estado?

A mesma consulta é feita de 3 formas diferentes, ‘read.csv’ padrão do R, ‘read.df’ ainda lendo o CSV, mas usando uma instancia local do Spark e por fim via ‘parquetFile’ também no Spark. (o código está no final do post).

O resultado pode ser visto nos gráficos abaixo:

Rplot01

 

Até que funciona bem! Eu já sabia que o ‘read.csv’ do R era ineficiente, mas não tanto!

Rplot03

 

Comparando o ‘read.df’ e o Parquet ambos rodando no Spark, conforme aumentamos o tamanho do arquivo aumentamos a diferença de tempo entre eles, sendo que para um arquivo de 300.000 linhas ler um Parquet já é 15x mais rápido.

Rplot02

Por fim, como ‘bônus’ podemos ver que o tamanho de um arquivo CSV tende a ser um pouco mais de 8x maior do que o de um Parquet. Os dados do ENEM, por exemplo, vão de 5 e poucos GB para pouco mais de 700 megas.

 

Conclusão e próximos passos

Ao se tratar de ‘Big Data’ acredito que não temos o que discutir, vale a pena gastar um tempo convertendo as bases para Parquet para que estas sejam utilizadas depois com mais eficiência.

 

Já para ‘Small Data’, temos uma questão importante de como o R usa a memória, pois os arquivos são carregados na RAM e depois podem ser manipulados de maneira muito eficiente com o Dplyr. Já no Spark temos que alocar os arquivos na memória (comando ‘cache()’), na prática acaba dando no mesmo, porém pouca coisa é mais eficiente (e elegante) que o Dplyr.

Apesar dos ganhos serem significativos em termos percentuais não estou certo se vale a pena gastar tempo convertendo arquivos para um ganho de 30-40 segundos.

Algumas perguntas que precisam ser respondidas ainda:

  • Será que converter os arquivos ‘grandinhos’ para Parquet, carrega-los via Spark e usar ‘collect()’ para trazer para converter para Data.Frame do R e depois usar o Dplyr para manipula-los é uma opção?
  • Qual a diferença de tempo gasto em diversas operações no Spark-cache() vs R-Dplyr?
  • Usar o Spark com outro formato de dados é uma pentelhação, mas será que não vale a pena usar o mesmo processo para trabalhar com qualquer tipo de dados em qualquer lugar?

Código

rm(list=ls())
library(dplyr)
library(tidyr)
#library(ggplot2)

# Set this to where Spark is installed
Sys.setenv(SPARK_HOME="/home/sandor/spark-1.5.2-bin-hadoop2.6")
# This line loads SparkR from the installed directory
.libPaths(c(file.path(Sys.getenv("SPARK_HOME"), "R", "lib"), .libPaths()))
library(SparkR)


i <- 50
tCSV <- NULL
tPARQ <- NULL
size <- NULL
tNORM <- NULL
for (i in 1:25){
sc <- sparkR.init(sparkPackages = 'com.databricks:spark-csv_2.10:1.3.0')
sqlContext <- sparkRSQL.init(sc)
caminho <- '/home/sandor/Enem/2013/DADOS/MICRODADOS_ENEM_2013.csv'

####################
t1 <- Sys.time()
sample <- read.csv(caminho, sep = ';', nrows = i*12000)

sample %>%
dplyr::group_by(UF_PROVA,IN_PRESENCA_MT) %>%
summarise(N=n()) %>%
spread(IN_PRESENCA_MT, N) %>%
dplyr::mutate(Faltas=`0`/(`1`+`0`)*100) %>% dplyr::select(UF_PROVA, Faltas)

#nrow(sample)
tNORM[i] <- as.numeric(Sys.time()-t1)
####################

write.table(sample, '/home/sandor/Enem/2013/DADOS/MICRODADOS_ENEM_2013_SAMPLE.csv', sep=';', row.names = F)

####################
t1 <- Sys.time()
ENEM <- read.df(sqlContext, path='/home/sandor/Enem/2013/DADOS/MICRODADOS_ENEM_2013_SAMPLE.csv',
source = "com.databricks.spark.csv", inferSchema = "false", delimiter=';', header='true')
#count(ENEM)
registerTempTable(ENEM, "EE")
resCSV <- sql(sqlContext, "SELECT UF_PROVA, count(case IN_PRESENCA_MT when '0' then 1 else null end)/count(IN_PRESENCA_MT)*100 as Faltas
FROM EE
GROUP BY UF_PROVA")

collect(resCSV)
tCSV[i] <- as.numeric(Sys.time()-t1)
####################

unlink('/home/sandor/R_files/Parquet/base_1', force=T, recursive = T)
saveAsParquetFile(ENEM, '/home/sandor/R_files/Parquet/base_1')

####################
t1 <- Sys.time()
PARQ <- parquetFile(sqlContext,'/home/sandor/R_files/Parquet/base_1')
#count(PARQ)
#cache(PARQ)

registerTempTable(PARQ, "PQ")
resPQ <- sql(sqlContext, "SELECT UF_PROVA, count(case IN_PRESENCA_MT when '0' then 1 else null end)/count(IN_PRESENCA_MT)*100 as Faltas
FROM PQ
GROUP BY UF_PROVA")

collect(resPQ)
tPARQ[i] <- as.numeric(Sys.time()-t1)
####################

setwd('/home/sandor/R_files/Parquet/base_1')
sPARQ <- sum(file.info(list.files(".", all.files = TRUE, recursive = TRUE))$size)
sCSV <- file.size('/home/sandor/Enem/2013/DADOS/MICRODADOS_ENEM_2013_SAMPLE.csv')

size[i] <- sCSV/sPARQ
sparkR.stop()

}
Advertisements

Analisando o ENEM

Nos últimos posts tenho explorado maneiras de se trabalhar com Big Data no R. Apesar de nova, a integração do R com o Apache Spark é bem razoável e a implementação do Hive funciona bem, apesar de alguns percalços ao criar grupos, travamentos aleatórios e algumas configurações pentelhas.


Como utilizei os dados do Enem para montar o post anterior, ao olhar o dicionário de dados acabei pensando em algumas perguntas que poderiam ser respondidas com dados, entre elas:

– qual a relação entre renda e a nota?
– qual a relação entre os anos de estudo dos pais e a nota do aluno?

Essas duas são bem básicas e sua resposta é esperada…

Outras perguntas tem a ver com o sexo e cor/raça dos alunos ajustadas pela renda.

Por fim é possível descobrir quais questões os alunos mais erraram/acertaram.

1 – Renda

Renda

O primeiro gráfico era esperado, quanto maior a renda da família, maior a média da nota.

2 – anos de estudo do pai

Anos_Estudo

Mesma coisa do primeiro gráfico, quanto mais anos de estudo tem o pai, maior a média da nota.

Obviamente, quanto mais anos de estudo, maior a renda, ou será que é o contrário?*

* – essa discussão vai ficar para uma próxima oportunidade

3 – sexo

Participei do Big Data week no final de outubro e somente um palestrante era mulher, que por coincidência apresentou um gráfico mostrando que 12% dos programadores Java são mulheres.

Esse número é bem baixo, mas não é muita novidade para o pessoal de exatas e até mesmo para o pessoal da Economia.

Minha hipótese era de que essa decisão é tomada na adolescência, levado talvez por uma deficiência nos cursos de matemática.

O gráfico abaixo mostra a distribuição das notas de matemática entre homens e mulheres. De fato a mediana das notas das mulheres foi menor mas nada tão alarmante que fosse capaz de desencorajar uma pessoa de fazer um curso.

sexo
4 – cor/raça

Na minha época de cursinho no Anglo Tamandaré (próximo o bairro da liberdade em São Paulo) tinha uma frase escrita em todas as cabines do banheiro masculino:

– “Enquanto você está cagando tem um Japonês estudando”

Finalmente, depois de tantos anos, vou poder colocar esse dito popular a teste!

Ao agregar os números por cor e raça não conseguimos observar nada demais, porém, quando controlamos pela renda, assumindo que são estes os alunos competindo pelas melhores vagas (ver gráfico 01) a mediana da nota dos alunos que se classificam como “amarelos” é a maior de todas, nada muito significativo, mas maior de qualquer forma.

asia
Talvez aqui seja interessante fazer um teste de hipóteses para verificar se a nota é significativamente maior.

5 – perguntas mais difíceis.

Por fim, existe um campo na base com todas as respostas de cada aluno, bem como o gabarito, cruzei um com o outro para pegar os acertos e somei isso para pegar o número de acertos por questão, a questão com menor número de acertos foi a mais difícil.

Seguem as questões mais difíceis, eu apaguei a resposta, mas se você tiver curiosidade o nome da figura é a resposta:
MT_E CN_C CL_B CH_C

Microdados ENEM com R / Hadoop / Spark / Hive

A definição de Big Data que acho mais interessante é algo mais ou menos assim:

  • “Big Data são os dados que não cabem na memória RAM”

Quem desenvolve em R sabe que essa definição é perfeita…

O problema é que há uns 15 anos atrás HDs de 100GB de memória eram raros e de lá para cá essa capacidade de armazenamento aumentou muito. Atualmente HDs de 1TB são bem comuns, porém a velocidade com que os dados são lidos não aumentou na mesma velocidade. Então, para ler um HD inteiro, leva-se mais tempo hoje do que a 15 anos atrás.

Mapreduce

Até que alguém teve uma ideia muito simples que é ler dados de diversos HDs ao mesmo tempo, uma analogia interessante é:

Você tem que contar os livros de uma biblioteca, uma opção seria contar um a um até chegar no total ou chamar seus amigos e dizer:

  • “Ok, temos 8 corredores (MAP), cada um de vocês conta os livros de cada corredor(REDUCE) e me fala o total”

Atualmente a aplicação mais famosa de Mapreduce é o Hadoop, que é provavelmente o projeto de Open Source de maior impacto no mundo dos negócios até hoje.

O problema agora, como comentei no meu post anterior (https://dadosdadosdados.wordpress.com/2015/11/09/o-varian-pirou/ ), é que existe um gigantesco ecossistema de ‘coisas’ para estudar, aprender, usar e manter o que torna impraticável na ‘vida real’, ou vai demandar uma gigantesca dedicação.

Spark

SPARK

A partir de meados de 2015 o R foi integrado ao Spark, que é uma plataforma de computação em cluster que foi desenhada para ser rápida e genérica. Sua diferença básica com o Hadoop é que ele faz suas computações na memória (ram) ao invés de usar os discos (hd), isso permite a ele realizar cálculos que antes eram bem complicados de serem feitos em uma operação de Mapreduce comum.

Outro ponto importante é que ao invés de termos que focar em diversas tecnologias ao mesmo tempo, a filosofia do Spark é de prover um pacote completo para os analistas não terem que gastar tempo mantendo 15 sistemas ao mesmo tempo, o que diminui drasticamente os custos.

No final das contas, com o Spark conseguimos nos aproximar muito do modelo proposto pelo Varian para análise de dados, com um overhead menor, seja em custos de se manter sistemas, em horas de aprendizado.

Simulando um ambiente

Para efeitos de treino/testes, é possível simular um ambiente de Spark em apenas 01 cluster, ou seja, ao invés de distribuir os cálculos em várias máquinas, usamos somente nosso computador. Não é a coisa mais eficiente do mundo (computação distribuída em 01 computador não é distribuída), mas é possível desenvolver seu código nesse cluster único e depois subir para a nuvem quando ele estiver pronto.

Pré requisitos:

1 – Virtualbox
https://www.virtualbox.org/wiki/Downloads

Eu costumo configurar essas máquinas virtuais com 50GB de HD, 8GB de RAM e 64MB de memória de vídeo, essas configurações devem variar dependendo da máquina que você vai rodar isso.

No meu notebook eu uso 2GB de RAM e 12MB de vídeo somente.

2 – Linux no virtualbox – A versão que uso é o Mint (Rafaela)
http://linuxmint.com/

3 – Extension pack do Virtual box
https://www.virtualbox.org/wiki/Downloads

No linux:
4 – Java
$ sudo apt-get install openjdk-7-jdk
$ export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64

5 – Hadoop

https://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-common/SingleCluster.html

6 – Hive
https://cwiki.apache.org/confluence/display/Hive/AdminManual+Installation#AdminManualInstallation-InstallingHive

7 – Spark – prestar atenção na versão do Hadoop, a versão pre-built serve
http://spark.apache.org/downloads.html

8 – R – Note que para o R, Trusty é a versão do Linux que estou usando, se você estiver usando uma versão diferente, é possível que você tenha que mudar o final do endereço

Adicionar em: /etc/apt/sources.list
deb https://cran.rstudio.com/bin/linux/ubuntu trusty/

Atualizar e instalar:
$ sudo apt-get update
$ sudo apt-get install r-base

$ R para checar a versão

9 – R-Studio
https://www.rstudio.com/products/rstudio/download/

Um caso real – Microdados ENEM

A pior coisa de usar tutoriais e demos é que tudo sempre dá certo, é uma beleza! O próprio tutorial do Spark usa um data.frame de umas 600 linhas, que meigo…

Eu encorajo a todos a tentarem algo diferente, para ver os problemas e dificuldades e o exemplo que vou mostrar aqui é dos microdados do ENEM.

É realmente uma pena a demora do INEP a divulgar os dados, pois os dados mais novos disponíveis são de 2013, mas é o que tem para hoje…

http://portal.inep.gov.br/basica-levantamentos-acessar

O legal dessa base de dados é que ela tem 5.1GB de dados, com 7.173.564 linhas e 166 colunas, o suficiente para travar minha máquina virtual, mesmo que ela possua 8GB de RAM, então ‘tecnicamente’ podemos considera-la como ‘BIG Data’.

Para essa análise quero comparar as notas das provas entre os estados do Brasil.

Rodando

O sparkR é realmente bacana, você basicamente precisa de dois comandos para começar a usar:

sc <- sparkR.init(master = 'local')
hiveContext <- sparkRHive.init(sc)

O primeiro comando inicia um contexto Spark e o segundo cria um contexto HIVE desse primeiro.

Depois, e é aí que as coisas começam a ficar diferentes de um exemplo comum, na hora de montar uma query no HIVE, você tem que declarar as colunas, o que é lindo quando você tem duas ou três, mas quando você tem 166 no caso do ENEM, você apela…

st <- rep('string', length(colnames(sample)))

st[match('NOTA_CN' ,colnames(sample))] <- 'int'
st[match('NOTA_CH' ,colnames(sample))] <- 'int'
st[match('NOTA_LC' ,colnames(sample))] <- 'int'
st[match('NOTA_MT' ,colnames(sample))] <- 'int'

Como queremos analisar somente as notas médias, vou forçar todos os campos a serem strings e somente a notas como números inteiros.

c1 <- paste(colnames(sample), st)
campos <- paste(c1, sep=',',  collapse = ', ')
cTable <- paste("Create external table src1 (", campos, ") row format delimited fields terminated by ';' SET skip.header.line.count = 1 ")

sql(sqlContext, "DROP TABLE src1")
sql(sqlContext, cTable)
sql(sqlContext, "LOAD DATA LOCAL INPATH '/home/sandor/Enem/2013/DADOS/MICRODADOS_ENEM_2013.csv' OVERWRITE INTO TABLE src1")

Agora é só agrupar os dados em um select comum

results1 <- sql(sqlContext, "SELECT UF_RESIDENCIA,
                avg(NOTA_MT) as AVG_MT,
                avg(NOTA_CN) as AVG_CN,
                avg(NOTA_CH) as AVG_CH,
                avg(NOTA_LC) as AVG_LC
                FROM src1 GROUP BY UF_RESIDENCIA")

Para transformar em data.frame do R usamos o comando ‘collect()’

tabela <- collect(results1)

Temos que pro fim ‘stopar’ o Spark

sparkR.stop()

O resultado

Agora, pegamos a nota média por estado por prova e subtraímos da média total para comparar as notas entre provas e estados.

Note que:

MT = Nota da prova de Matemática

LC = Nota da prova de Linguagens e Códigos

CH = Nota da prova de Ciências Humanas

CN = Nota da prova de Ciências da Natureza

plot of chunk unnamed-chunk-8