#bigdata #hadoop #spark
No período outubro 27~29 eu estive no Spark Summit Europe
2015, em Amsterdam. Um dos assuntos muito debatidos
nesse Summit foi o Project Tungsten, que está prometido para ser entregue
como um módulo dentro da versão 1.6 do Spark. A incorporação do Project Tungsten
ao Spark é uma orientação estratégica de alta tecnologia, com consequências
para quem pretende desenvolver software para Spark.
A proposta original do Spark é centrada na classe RDD
(Resilient Distributed Dataset), concebida pelo autor do Spark - Matei Zaharia
- em sua tese de doutorado. O texto dessa tese pode ser baixado nesse link.
O código com uso de RDD, associado ao conceito de “lazy execution”, faz criar
um DAG (Directed Acyclic Graph), que é o grafo que descreve como a execução
será feita quando chegar o momento. A análise especializada do código gerado
dessa forma permite que se façam propostas de padrões de código que melhoram o
desempenho de execução. Mas essa análise requer aprofundamento muito intrincado
em tecnologia, o que torna o uso de Spark menos palatável para o grande público
do que se desejaria.
Os “gurus do Spark” acreditam que com o Project Tungsten
chegaram a uma proposta adequada para entregar uma versão de Spark que é ao
mesmo tempo otimizada em eficiência de execução e relativamente pouco complexa
para ser programada. Para que essas qualidades sejam de fato obtidas,
recomenda-se aos usuários de Spark que dentro do possível deixem de trabalhar
com RDDs e passem a trabalhar com DataFrames. Isso porque o RDD, embora seja e
será sempre o centro do Spark, não permite otimização automática das DAGs. Mas
o DataFrame gera um tipo de estrutura que pode ser otimizada antes de ser
executada, e essa otimização faz bastante diferença no desempenho. No final das
contas, um programa com RDD, se for otimizado “na mão”, com todas as
intrincadas técnicas de análise de DAG, terá na melhor das hipóteses um
desempenho tão bom quanto um programa feito com DataFrame, que é otimizado
automaticamente e não requer análise intrincada por parte do programador Spark.
E há uma vantagem adicional: considerando que todas as linguagens Spark usam o
mesmo DataFrameAPI, o desempenho otimizado dos DataFrames ocorre igualmente
para qualquer linguagem que o programador desejar usar (atualmente incluindo
Scala, R, Python, entre outras). Em contraste, o uso direto de RDD tem
desempenho melhor quando feito em Scala, em relação a outras linguagens.
Para quem está aprendendo Spark agora, a mensagem é a
seguinte: é preciso aprender RDD, porque há funcionalidades de Spark que apenas
funcionam assim, e porque ainda há muito código com o qual se precisa interagir
que é baseado em RDD. As novas versões do Spark não terão qualquer problema com
código para RDD. Mas ao mesmo tempo, seja pela simplicidade de uso, seja por
desempenho, é bom apostar na estrutura de dados baseado em DataFrame, pois
sinaliza-se que o futuro do código Spark tende para essa direção. Pode-se usar
DataFrame desde as versões atuais. Mas será a partir da futura versão 1.6 (que
inclui o Project Tungsten) que se espera que o uso pleno de DataFrames, com seu
potencial e desempenho plenos sejam disponibilizados para o público.
A propósito: considerando que no Summit havia um clima de
forte incentivo ao open-source, eu pedi para o pessoal da Databricks que me
dessem o código com o qual eles implementaram a famosa quebra de recorde de
benchmark, em outubro de 2014 (aqui e aqui).
Eles não me deram esse código, e explicaram o motivo. Acontece que o código
realmente bateu o recorde, mas foi feito com muitos “truques de baixo nível”.
Esses truques são úteis para pesquisa, mas não são boas práticas de
programação. Com a pesquisa feita com esses truques, eles evoluíram e criaram
estruturas de alto nível, e as colocaram no Project Tungsten.
Em resumo: o Spark segue evoluindo rapidamente, como a comunidade
espera, e como deve ser. Para o desenvolvedor Spark, o Data Analyst ou
Cientista de Dados, o que interessa é que a estrutura de dados no foco deve ser
mais e mais o DataFrame, ao invés de RDD, mas esse último continuará sempre
funcionando muito bem. A próxima versão 1.6 vai ser liberada em breve, e será
um marco no estímulo ao uso de DataFrames. As versões atuais já permitem o uso
de DataFrames, para quem quiser fazer experiências com essa estrutura de dados.
--------------------------------------------------------------------------------
Sergio
Barbosa Villas-Boas (sbVB), Ph.D.
software development, Big Data,
cloud, mobile, IoT, HPC, optimization
sbvillasboas@gmail.com,
sbvb@poli.ufrj.br
Skype: sbvbsbvb
http://www.sbVB.com.br
https://www.linkedin.com/in/sbvbsbvb
+55-21-97699-1337
Nenhum comentário:
Postar um comentário