Install Tensorflow with GPU support on Windows 10

I am writing this little guide for people who, like myself, have the following characteristics:

  • Have a computer with a decent enough GPU
  • Use this computer to play games
  • Would like to use it also to run experiments on Tensorflow
  • Are too lazy to build a dual boot with linux to proper run it
  • Are also too lazy to install packages and prefer using Anaconda

I remember it was a huge pain to make Tensorflow work with my GPU (980ti) the first time I tried and recently my Windows 10 machine crashed and I had to install it all again (thank you Microsoft!)

Bear in mind that this guide was written in 2017-June and given the speed in which Tensorflow related stuff moves it has an increasing probability of being outdated the farther you are reading it from this date

Steps:

1 – Download and install Anaconda 3.6

https://www.continuum.io/downloads

1.1 Add Anaconda to the Path variable

  • Windows+Break / advanced system settings / system properties / advanced / environment variables
    • under System Variables add   “<your path>\Anaconda3” and “<your path>\Anaconda3\Scripts”

2 – Create a virtual environment:

  • Tensorflow works with Python 3.5 so we will have to create a virtual environment for this.
  • It is important to copy everything when creating this environment otherwise you will have to install it all again
  • In the Windows Command Prompt: “conda create -n tf python=3.5 anaconda”

3 – Install Tensorflow-gpu

  • At the time of this writing the conda instructions on Tensorflow’s website did not work for me, so I had to use pip
  • In the Windows Command Prompt: “pip install –upgrade tensorflow-gpu “

4 – Requirements

5 – Test it

  • Now you should be able to open the Command Prompt and use the following commands
    • activate tensorflow
    • python
    • import tensorflow as tf
    • hello = tf.constant(‘Hello, TensorFlow!’)
    • sess = tf.Session()
    • print(sess.run(hello))
  • If everything was ok, you should see a message telling that it was running on the GPU and the print
Advertisements

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…

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…

 

 

Whatsapp vs produtividade

whatsapp2

Aproveitando o início de um novo ano, nada como pensar em coisas que gostaríamos de fazer: Um regime, começar academia, estudar X, mudar de emprego etc.

No meu caso, eu gostaria de diminuir o ‘ruído’.

Não tem muito tempo, me dei conta que estava com 4 softwares diferentes pingando conversas no meu computador, email, Skype for Business, Slack, whatsapp web enquanto que eu respondia um colega pelo Facebook Messenger no meu celular.

Vou dar um exemplo do que quero diminuir…

Whatsapp e seus grupos

Tenho um grupo no Whatsapp de mais ou menos uns 14 amigos que em média se conhecem há 15 anos e como foi dito internamente, é um ‘grupo sem propósito’, ele não tem uma função, objetivo ou finalidade mas foram trocadas 34.742 mensagens desde 20/10/2014.

dailyMessages

Vamos quebrar pelos 10 usuários mais ativos:

MessageCount

Para um grupo só até que é razoável, considerando que os usuários mandam me média 1.200 mensagens e recebem 2.200. (fonte)

Quando mandei esses gráficos no grupo, a primeira coisa que os ‘primeiros colocados’ responderam foi que estão acostumados a mandar várias mensagens em sequencia ao invés de um grande bloco de texto, por isso esses gráficos estavam inflados.

wordCount

MENTIRA!

Quebrei os textos por palavras e contei, o que aumentou ainda mais a distância dos ‘primeiros colocados’. Os três primeiros colocados correspondem a 48% do ruído gerado nesse grupo! (infelizmente eu sou era um deles)

Mas não é só isso, resolvi fazer uma análise do vocabulário olhando o número de palavras ‘únicas’ no texto de cada um e comparei com o número de mensagens. A tendência é clara, quanto mais se escreve, mais se repete. É o efeito “Vai Curintia!”, repetir isso a exaustão não te faz um cara mais legal…

Vocab_Palavras

Datas e horários

E quando é que essas mensagens aparecem?

WeeklyMsg

É lógico que é durante a semana…

hourlyMsgs

Bem no horário comercial, especialmente as 10:00…bem depois do primeiro café!

77,6% no horário ‘comercial’ (9:00 as 19:00)

82.9% de segunda a sexta

Se um usuário médio manda 1.200 mensagens e recebe 2.200 por mês, então ele sofre em média um pouco mais de 100 interrupções por dia no trabalho!!! Só no Whatsapp.

Tempo gasto

Só para termos uma noção de dimensão, vamos comparar a quantidade de texto produzida nesse grupo do Whatsapp com alguns livros:

WhatsVsLivros

Em um pouco mais de um ano, escrevemos coletivamente mais de 180.000 palavras,  3x o Livro Memórias Póstumas de Brás Cubas que tem 60.426.

Toma essa Machadão!

Multitasking

O maior problema disto é o efeito que realizar diversas tarefas tem no nosso cérebro, onde ao realizar diversas tarefas ao mesmo tempo, temos um desempenho inferior em todas.

http://www.forbes.com/sites/work-in-progress/2013/01/15/how-multitasking-hurts-your-brain-and-your-effectiveness-at-work/

http://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/

Sem contar que isso atrapalha para entrar no estado de ‘flow’

https://en.wikipedia.org/wiki/Flow_%28psychology%29

O resultado é, 100 interrupções por dia do Whatsapp, um punhado do Slack, Skype, Facebook Messenger e trocentas notificações de recebimento de emails nas contas do trabalho e pessoal, além de Twitter e Facebook, é fácil afirmar que somos interrompidos pelo menos uma vez a cada dois minutos…

…Pelo menos o telefone raramente toca hoje em dia…

Próximos passos:

Eu gostaria de fazer uma análise no conteúdo dessas mensagens, porém alguns desafios se apresentam, como a informalidade, a coloquialidade da conversa, os erros e português e as figuras de linguagem. Por exemplo quando um chama o outro para jogar Age of Mythology…

“Zoomm!”

Outra coisa legal seria ver as relações entre o pessoal, mas para isso eu precisaria tratar os apelidos (e as vezes xingamentos) que se referem carinhosamente aos indivíduos do grupo.

Além disso, fazer uma análise de sentimento nos textos. Será que segundas feiras são mais tristes que sextas? É possível um texto negativo mudar o sentimento do grupo de negativo para positivo? Qual a intensidade necessária?

Por fim, que termos deixam o pessoal mais irritado?

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

}