Never leave it in the hands of the judges

Como a grande maioria dos pre-adolescentes bobos nos anos 90 eu adorava assistir filmes de luta como “O grande dragão branco”, “Leão branco”, “Kickboxer”, você já entendeu a tendência…Todos os filmes do Van Damme, basicamente.

Porém, toda a graça acabou como um passe de mágica quando um colega e eu alugamos 3 fitas de video com os primeiros “The ultimate fighting championship” (UFC), era como se um sonho tivesse virado realidade já que era possível ver lutadores de diferentes estilos em combates totalmente livres de regras, era como “O grande dragão branco” com muito menos carisma.

Vinte e poucos anos se passaram desde aquele momento de descoberta e aquilo que era considerado uma barbárie ganhou regras, se profissionalizou e hoje é um dos esportes que mais cresce no mundo conseguindo chegar a um tamanho inimaginável pelos fans do esporte, sendo recentemente vendido por $4 bilhões de dólares.

Provavelmente assisti 90% de todos os eventos oficiais (os numerados), alguns UFC fight nights e até alguns “The ultimate fighters”, então é bem provável que eu tenha assistido alguns milhares de combates, porém em uma recente conversa com amigos, declarei que não tenho mais o interesse que tinha antes pelo esporte, exceto por algumas poucas lutas principais, o problema é que não consegui explicar o porque disso.

Os fãs citam diversos fatores, entre eles o principal sendo o excesso de exposição, já que é possível ver eventos praticamente todas as semanas, então não é mais um bem tão escasso como era antigamente, porém eu desconfio que não é só isso, minha opinião é que os eventos estão mais chatos* na média, que muitos lutadores lutam para não perder ao invés de ganhar e que a grande maioria de técnicas já está arbitrada, portanto é mais difícil surpreender o oponente e principalmente a audiência com uma técnica nova, como a revolução que o jiu-jitsu Brasileiro fez no esporte.

Primeiramente tenho que definir o que é um ‘evento chato’. Nocautes e Submissões são legais, são surpreendentes e inesperados, não existe uma forma melhor de definir o triunfo de um lutador sobre o outro. Em contraste, lutas que terminam por pontos são menos interessantes, pois elas terminam (na grande maioria dos casos) sem um vencedor claro e esse término é artificial, forçado e, pior ainda, são 15 ou 25 minutos em que nada aconteceu. Portanto, um evento como um todo pode ser definido como chato ou interessante baseado no número de KOs/Submissões sobre o número total de lutas.

Dada esta definição, vamos olhar para o comportamento dos eventos ao longo do tempo. No gráfico abaixo calculo a razão entre KO+Sub sobre o número total de lutas. Os eventos vão desde o primeiro UFC em 1993 até o Fight Night 83 em 2016-02-21, para um total de 3.569 lutas (os dados podem ser encontrados nesse link)

ko_sub

Nos primeiros eventos, até o final dos anos 90, as regras eram poucas (bem poucas) e as lutas não eram divididas em rounds, o que obviamente infla o número de finalizações de lutas, mas mesmo com uma grande variância entre os eventos, na média o número de finalizações caiu de 3 em cada 4 para pouco mais que 1 a cada 2 lutas.

Uma das explicações para esse número em declínio pode ser que o Jiu Jitsu foi assimilado pelos lutadores e atualmente finalizações por submissão são bem mais raras do que antigamente. Olhando para o gráfico abaixo é difícil tomar essa explicação como sendo a maior causa do problema, pois o o número de KOs em relação as Submissões aumentou um pouco ao longo do tempo, mas ainda 1 em cada 3 finalizações é devido a submissões.

ko_sub

Outra explicação pode ser dada com a introdução de categorias de peso mais baixas, principalmente depois da compra do WEC (World Extreme Cagefighting) a qual era a casa dos lutadores menores. O gráfico abaixo mostra o percentual de lutas finalizadas por classe de peso.

weight

Tem um tempo que comento com meus colegas que pouca coisa é mais legal que luta de pesos pesados no UFC, imagine duas pessoas que possuem mais músculos e gordura do que é humanamente aceitável, os quais possuem força para nocautear seus oponentes com apenas 1 soco e são incapazes de se esquivar tão bem quanto as categorias mais leves. Toda luta é uma surpresa, nenhum campeão dos pesos pesados conseguiu manter seu cinturão por muito tempo, é a roleta russa do UFC, por isso uma de minhas lutas preferidas foi a do Minotauro vs Bob Sapp em 2002. Ok, o Bob Sapp nem era um oponente tão respeitado assim, mas vale lembrar que sem o espetáculo não teríamos uma empresa tão grande quanto o UFC é hoje.

Acredito que consegui quantificar parte da minha insatisfação com o UFC atualmente, não é o excesso de eventos, mas sim o excesso de lutas em que nada acontece, com lutadores pequenos que ficam pulando por 25 minutos na tela incapazes de realizar qualquer movimento remotamente ameaçador. O UFC tem feito um bom trabalho em manter o evento interessante e os lutadores chatos são removidos dos eventos principais através da seleção natural, mas dificilmente retornaremos para os números do passado, não enquanto os lutadores estiverem lutando para não perder ao invés de lutando para ganhar.

Por fim, existe uma probabilidade de 29% de uma luta acabar no primeiro round com um KO ou Submissão, se isso não aconteceu, essa probabilidade cai para 23% de acontecer no segundo round, porém se a luta não terminou ainda, a probabilidade de uma finalização no terceiro round cai para 15,5% nos próximos rounds (caso a luta vá até 5), ou seja, se nada aconteceu no primeiro round, pode até ser que ocorra no segundo, caso nada ocorra, pode ser um bom motivo para desligar a televisão e ir dormir mais cedo, visitar o banheiro, buscar uma cerveja, abrir o facebook etc, pois é bem provável que nada aconteça mesmo…

Advertisements

Dinâmica da pirâmide etária entre 1990 e 2050 e a reforma da previdência

Recentemente a equipe econômica do presidente interino Michel Temer anunciou um conjunto de medidas para tentar conter a rápida deterioração das contas públicas brasileiras. A mais importante delas, que será apresentada a partir de uma Proposta  de Emenda Constitucional, tem como objetivo limitar o crescimento das despesas primárias à inflação do ano anterior. O governo também pretende que o BNDES antecipe a devolução de pelo menos R$ 100 bilhões em recursos repassados pelo Tesouro (de um total de mais de R$ 500 bilhões) e indicou, dentre outras coisas, que poderá extinguir o Fundo Soberano Nacional e utilizar os R$ 2 bilhões de seu patrimônio atual. Foi a raspa do tacho na tentativa de reduzir em alguma medida o enorme déficit primário herdado da administração Dilma, sem propor (por enquanto!) nova rodada de aumento de impostos, mudança nas regras de benefícios sociais e/ou venda de ativos da União.

Embora o pacote de medidas tenha agradado o mercado, o governo preferiu por ora não entrar no debate da questão previdenciária. Michel Temer apenas indicou que discutirá a reforma da previdência com centrais sindicais e classe política e que nenhuma medida econômica será tomada sem a “concordância” da sociedade. Fato é que nós brasileiros precisamos nos preocupar com essa questão, pois o Estado já gasta mais de 12% do PIB com previdência (incluindo BPC-LOAS, de uma arrecadação total de cerca de 25% do PIB) e, se nada for feito, a situação se tornará insustentável em pouquíssimo tempo, uma vez que o processo de envelhecimento da população brasileira será muito rápido. O gráfico abaixo mostra de forma mais clara a velocidade deste processo de envelhecimento da população entre 1990 e 2050, utilizando as projeções do U.S. Census Bureau.

brazil_pyramid

Pelo estreitamento da base da pirâmide é possível notar que a proporção de crianças e adolescentes com até 14 anos vem caindo rapidamente nos últimos anos, reflexo da menor taxa de fecundidade das mulheres. Segundo o IBGE, o número médio de filhos passou de 2,4 nos anos 2000 para 1,7 em 2015, uma queda de quase 30%. Com efeito, a expectativa é de um aumento expressivo da população de idosos nos próximos 30-40 anos, característica bastante distinta da observada no início da década de 90, quando predominavam crianças e jovens na pirâmide etária brasileira.

O próximo gráfico mostra, a partir da mesma base do U.S. Census Bureau, que a taxa de fecundidade brasileira também é a menor da América Latina. Para visualizar os valores, basta clicar no gráfico.Taxa de Fertilidade, 2016 <br> Elaboração: dadosdadosdados. Fonte: U.S. Census BureauSe as informações demográficas apresentadas acima ainda não forem suficientes para convencer o leitor de que o debate sobre a reforma da previdência deve ser tratado em regime de urgência, sugiro a leitura da última versão (de março de 2015) do relatório de Projeções Financeiras e Atuariais para o Regime Geral de Previdência Social, disponível neste link. Na página 28 encontram-se as projeções oficiais (ou seja, do próprio governo), que indicam que, nas condições atuais, a despesa do INSS e o déficit da Previdência como proporção do PIB seguirão em tendência de crescimento até 2060, assim como mostrado nos gráficos abaixo. Importante também destacar que essas projeções levavam em conta um PIB de -0,9% em 2015, de +1,30% em 2016 e de +1,9% em 2017. A atualização do modelo com o recuo de -3,8% observado em 2015 e com as projeções mais recentes do Boletim Focus (-3,8% em 2016 e +0,55% em 2017), além de inflação mais elevada e crescimento nominal da massa salarial bem mais fraco, influenciará negativamente a estimativa de arrecadação, aumentando a previsão para o déficit da Previdência.

Despesa (azul) e Déficit (laranja) da Previdência como % do PIB <br> Elaboração: dadosdadosdados. Fonte: Previdência SocialOBS: para elaborar os gráficos deste post utilizei diversas bibliotecas do software R, sendo que as principais foram a idbr (que faz conexão direta com o API do US Census Bureau para obter os dados demográficos), ggplot e plotly (para criar os gráficos) e a animation (responsável por criar a animação do gráfico em GIF).

Arborização e o preço dos imóveis em São Paulo

Parece meio óbvio, mas será que é possível verificar uma correlação positiva entre a arborização de um local e os preços dos imóveis?

Outro dia, ao ir almoçar sozinho debaixo de um belo sol ‘de rachar’, de camiseta preta e sem uma única sombra para me ajudar comecei a delirar divagar sobre os prós e contras daquele local de trabalho. Por conta do momento, a falta de arborização naquele local era um ‘contra’, mas em oposição um fator positivo era o custo do aluguel (entre outros).

Por sorte temos o site http://geosampa.prefeitura.sp.gov.br/ que disponibiliza dados gerais sobre a cidade, como arborização, por exemplo:

arvores

Com esses dados, agregados aos da prefeitura de tamanho das subprefeituras e distritos podemos calcular o número de árvores por km²

top10

Eu poderia parar a análise por aqui já que quem mora/conhece a cidade de São Paulo sabe que esses são os bairros mais caros, porém vale a pena dar uma olhada nos preço médio do m² e comparar com a arborização do local.

Usando dados do properatidata.cartodb.com de preço de m² por distrito é possível criar o gráfico abaixo:

modelo

Razoável…

Obviamente existem diversos fatores que contribuem para o preço de um imóvel e é bem possível que a arborização de um local tenha uma importância boa em um modelo para prever preços de imóveis, como um modelo mais complexo que criei há um tempo atrás…

https://dadosdadosdados.wordpress.com/2015/09/15/alugueis-em-sao-paulo-um-benchmark/

Deep Learning com CUDA em tempos de crise

‘Neural Networks are cool again’ – Autor desconhecido

De quando em quando aparece uma notícia de um algoritmo mirabolante capaz de fazer alguma façanha que ninguém achava possível, porém ultimamente essas notícias estão ficando cada vez mais consistentes

Recentemente o Google anunciou algo que os especialistas achavam que demoraríamos pelo menos mais 10 anos para alcançar. Eles conseguiram montar um algoritmo capaz vencer um dos maiores campeões de GO do mundo.

http://www.wired.com/2016/03/googles-ai-wins-first-game-historic-match-go-champion/

Eu não conhecia o jogo GO a fundo. Joguei algumas vezes na infância porque alguém tinha o tabuleiro, mas nunca dei muita bola; e uma coisa que me deixou impressionado com essa notícia é a complexidade do GO em relação a outros jogos como jogo da velha e Xadrez.

https://en.wikipedia.org/wiki/Game_complexity#Complexities_of_some_well-known_games

‘Game-tree complexity’:
– Jogo da Velha = 10^5
– Xadrez = 10^123
– GO = 10^360

Só para se ter uma ideia, quando o Deep Blue venceu o Kasparov, apesar de ter sido um grande feito na época, ele ‘apenas’ buscava a melhor sequencia de jogadas dentro de um banco de jogadas, ou, para quem gosta de Excel, imagine um ‘super procv()’.

Já no caso do GO, isso ainda é uma impossibilidade por conta da complexidade do jogo, então o pessoal do DeepMind tentou outra abordagem onde eles ensinaram o computador a jogar GO olhando para milhares e milhares de partidas e até mesmo jogando contra outros computadores.

Usando a tecnologia
Diferente da postura usada pela IBM nos casos do Deepblue e mais recentemente do Watson, a tecnologia usada pelo Google está aí para brincarmos, principalmente agora que o Google abriu o código fonte das suas bibliotecas de Machine Learning

https://www.tensorflow.org/

Não é nada demais e é até inferior em alguns aspectos a bibliotecas que já estão por aí a algum tempo, como o Theano, mas o importante é que essas tecnologias estão aí, disponíveis para usarmos.

Na pratica:
As tecnologias estão disponíveis, mas um limitante para utiliza-las é o tempo de processamento,  por exemplo: Para um projeto que estou trabalhando eu preciso rodar diversos modelos e combina-los para fazer uma previsão. Uma das pernas desse processo é um modelo de Deep Learning, relativamente simples com 2 hidden layers, 2 dropout e alguns outros detalhes.

Considerando o problema inteiro o que eu teria que fazer é rodar esse modelo com 400 epochs, em um cross-validation de pelo menos 5 folds, com no mínimo 30 combinações diferentes de parâmetros. Com um tempo médio de processamento de 14.5s por epoch eu levaria 14.5 x 400 x 5 x 30 / 60 / 60 =~240 horas para rodar esse processo.

Processamento
Como as redes neurais são extremamente flexíveis e sua ‘profundidade’ pode afetar significativamente os resultados, chegamos em uma situação em que os recursos computacionais são limitadores na hora de criar redes maiores e mais complexas. Não são raros exemplos de pessoas que deixam suas redes treinando por dias ou semanas.

Uma solução para isso foi mudar o local de processamento das redes do processador para a Placa de vídeo pois como elas são feitas para trabalhar com gráficos pesados, são capazes de realizar muito mais operações por segundo chegando a ser até 20x mais rápidas que um processador equivalente.

Todo esse poder de processamento tem seu custo, é claro, geralmente a placa de vídeo é o componente mais caro de um PC e uma placa top não sai por menos de R$3.500,00

Ok, ok, estamos em crise e vai ser bem difícil arrumar R$10.000,00++ para comprar um PC novinho para brincar de Data Scientist, então o que dá para fazer?

CUDA on a Budget
CUDA é a Tecnologia usada pelas placas de video Nvidia que se comunica com as bibliotecas de Deep Learning (Theano ou Tensorflow) para mandar os cálculos para a GPU, então teoricamente qualquer PC com uma placa de vídeo que suporte CUDA pode ser usada para treinar uma rede Neural.

Tenho um notebook da Asus que por acaso vem com uma placa integrada GeForce 740m, que é uma porcaria de uma placa (do ponto de vista de um Gamer), mas é o que tem para hoje.

Instalando o CUDA no Linux
Eu já tinha visto diversos comentários sobre o quão chato é fazer esse troço funcionar, mas nada como testar na pele para ver como é.

Vou passar o passo a passo, mas já aviso que coisas podem ‘quebrar’ e isso vai variar por sistema, versão, hardware e etc, então tenha paciência, vai funcionar, mas nunca na primeira tentativa.

  • Faça o download do driver em:
    https://developer.nvidia.com/cuda-downloads
  • Vá para o terminal com CTRL+ALT+F1
  • Pare o ‘X server’, no meu caso ‘sudo service mdm stop’
  • sudo init 3
  • sudo sh cuda_7.5.18_linux.run

A partir de agora é só seguir a instalação e adicionar algumas linhas no .bashrc

export CUDA_HOME=/usr/local/cuda-7.5
export LD_LIBRARY_PATH=${CUDA_HOME}/lib64

PATH=${CUDA_HOME}/bin:${PATH}
export PATH

Obviamente, no meu caso a instalação do Driver de vídeo falhou, tentei de tudo e não deu certo e acabei instalando pelo Driver Manager do Linux mesmo (versão 352.63).

Como eu uso o Theano como motor eu precisei configura-lo para aceitar minha GPU, as instruções não são muito claras, mas eu criei um arquivo no root chamado ‘.theanorc’ com o seguinte conteúdo:

[cuda]
root = /usr/local/cuda-7.5

[global]
floatX = float32
device = gpu0

Isso deve ser o suficiente, com exceção de um detalhe que está marcado como Bug no site da Nvidia, mas eu não consegui resolver que é o seguinte, independente do programa que você usar (R ou Python) você deve abri-lo como administrador (sudo), caso contrário ele não reconhece a placa.

Resultados:
Na média, por epoch, consegui obter desta plaquinha uma velocidade 6x mais rápida para treinar minha network. Para diminuir o tempo de processamento de 10 dias para um pouco menos de 2 realmente fez valer a pena o trabalho com a instalação do CUDA.

chart1

Aquilo que não sei

Eu estava lendo o livro Rise of the “Robots: Technology and the Threat of a Jobless Future” e logo no começo o autor começa com a argumentação de que a produtividade do trabalho vem crescendo continuamente ao longo dos anos após a segunda guerra mundial.

us_productivity_and_real_wages

https://en.wikipedia.org/wiki/Workforce_productivity

Olhando para o gráfico, especialmente para a curva de produtividade (a de salários é um assunto para um outro momento) e pensando na maneira como trabalhamos hoje em dia é até difícil imaginar como era trabalhar na era ‘pre-Google’.

Vamos imaginar uma situação, você está em 1995 e precisa montar um report com alguns gráficos para seu chefe, porém você gostaria que os gráficos compartilhassem os eixos, mas você não faz ideia de como fazer isso. Você tinha basicamente três opções:

  • Perguntar para seus colegas de trabalho
  • Encontrar um livro
  • Tentativa e erro

Com um pouco de sorte existe um colega mais experiente ou você já possui um livro com a solução, mas a probabilidade era pequena, principalmente para problemas específicos.

Hoje em dia, por outro lado:

“matplotlib subplot”

O exemplo acima parece irrelevante, mas a quantidade de vezes que isso acontece é gigantesca, vou exemplificar:

Google Search History

O Google disponibiliza o histórico das suas pesquisas em:

https://history.google.com/history/

Nos últimos 1.000 dias eu realizei pouco mais de 17.000 pesquisas!!! E os sites mais acessados foram:

  1. stackoverflow.com
  2. en.wikipedia.org
  3. cran.r-project.org
  4. steamcommunity.com
  5. http://www.gamefaqs.com

Trabalho e jogos basicamente, porém é possível fazer o download de todas essas pesquisas, então é possível ir mais longe. Vamos analisar o número de pesquisas por dia da semana:

f1

f2

Bem, nenhuma novidade aqui, o número de pesquisas de Sábados e Domingos é menor e ao longo do mês as pesquisas são consistentes com exceção do dia 31, mas isso era esperado.

f3

A utilização desde 2013 aumentou consideravelmente, não só eu já utilizo bastante o Google como essa dependência tem aumentado ao longo do tempo.

Por fim, selecionei alguns dos termos que mais pesquisei para compara-los no tempo e o gráfico abaixo é o mesmo que dei como exemplo acima, onde eu apanhei um pouco para montar um gráfico que compartilhasse os eixos no Python (como vocês podem ver, eu só comecei a estudar Python recentemente)

f4

Alguns pontos são interessantes.

  • Wikipedia é uma constante em nossas vidas
  • Meu interesse pelo R provavelmente cresceu na mesma velocidade que a adoção do pacote ‘Dplyr’, que foi lançado no começo de 2014, até lá eu só o utilizava para rodar alguns modelos, mas não para ‘brincar’ com dados
  • Ultimamente, por conta do trabalho, tenho substituído o R pelo Python
  • As pesquisas sobre jogos costumam ter a mesma duração que meu interesse sobre eles e olhando para esse gráfico eu joguei muito mais Dota do que eu gostaria de admitir.
  • Apesar de parecer, não há correlação entre as pesquisas de jogos e trabalho, eu só não incluí mais gráficos…

 

 

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()

}

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