BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Spark in Action revisão e entrevista com autores

Spark in Action revisão e entrevista com autores

Favoritos

No livro Spark in Action, os autores Petar Zečević e Marko Bonaci discutem a estrutura do Apache Spark para processamento de dados (tanto em lote, como com streaming de dados). Foi apresentado a arquitetura e os conceitos essenciais do Spark, tais como: Resilient Distributed Datasets (RDDs) e DataFrames.

Os autores discutem, a partir de exemplos de código, o processamento de dados por meio de bibliotecas, como: SQL Spark e Spark Streaming, bem como a utilização de algoritmos de aprendizagem de máquina com o MLlib. Os autores também comentam sobre análise de dados em grafo com a biblioteca GraphX.

A seção do livro "Operações do Spark" aborda a execução do Spark em um cluster standalone, bem como em um cluster distribuído, usando outros frameworks como YARN e Mesos. O InfoQ conversou com Petar Zečeviće e Marko Bonaci sobre o framework Apache Spark, sobre as ferramentas de desenvolvimento, além das próximas funcionalidades e melhorias nas futuras versões.

InfoQ: Quando comparado com outras tecnologias, quais são as vantagens e funcionalidades oferecidas pelo Spark para o processamento de dados? Poderiam falar sobre algumas dessas funcionalidades?

Petar Zečević: Sim, o Spark é um sistema de processamento de dados de uso geral, que pode ser utilizado para diversas tarefas. A maior vantagem do Spark, em comparação ao MapReduce do Hadoop, é a sua velocidade. É um fato bem conhecido que o Spark é muito mais rápido que o MapReduce, fato que resultou no impulso inicial de comercialização do Spark. Outro diferencial é a sua natureza unificadora. Através de uma única biblioteca, pode-se usar o Spark para processamento em tempo real, processamento em lote, aprendizado de máquina e consultas SQL. Além disso, disponibiliza APIs para quatro linguagens de programação diferentes (Python, Scala, Java e R). Além de suas funcionalidades, o que o torna atraente é o seu uso generalizado: ainda que com apenas uma fração das distribuições do Hadoop, muitas empresas estão utilizando em seus fluxos de processamento de dados. A recente decisão da IBM de envolver 3000 desenvolvedores exclusivamente para o Spark é um sinal que o framework passou a ser considerado mainstream.
Marko Bonaci: Sim, a IBM está sempre atrasada, mas os chamados "usuários corporativos" usam timidamente softwares de código aberto até que um gigante "batize" o produto. Por isso, agora podemos esperar um aumento de usuários corporativos. Se estiver pensando em fazer um investimento em Spark, este é o momento.

InfoQ: Quais são as limitações do Apache Spark?

Zečević: O Spark não é adequado para aplicações OLTP, quando é necessário muitas leituras e atualizações de pequenas porções de dados por muitos usuários. É mais adequado para análise e tarefas de ETL. Uma limitação do Spark Streamming é que seu processamento tem uma latência de ao menos meio segundo. Além disso, o Apache Spark ainda tem que implementar outros algoritmos de aprendizado de máquina, por exemplo: redes neurais (atualmente em andamento).
Bonaci: Existem alguns esforços recentes para integrar o Spark com o Tensor Flow, um framework para Deep Learning, cujo código foi aberto em dezembro de 2015. Nesta integração, o Spark atua na paralelização de algumas partes do algoritmo de Deep Learning. Será interessante ver como o Spark poderá ser empregado no campo de aprendizado de máquina. Pouco antes do Google, a Microsoft também abriu o código do CNTK, sua estrutura de Deep Learning.

InfoQ: Podem comentar as considerações na criação de clusters do Apache Spark para aumentar as funcionalidades de processamento de dados de maneira distribuída?

Zečević: A primeira decisão é escolher o tipo de cluster. Algumas estatísticas recentes sugerem que a escolha mais popular é o cluster standalone, seguido de perto pelo YARN. Mesos é a terceira escolha, mas ainda assim, é utilizado por um número significativo de usuários. O cluster standalone é simples de configurar e foi construído especificamente para o Spark, por isso, é uma boa escolha quando precisa-se executar apenas o Spark, sem a necessidade de executar outros frameworks distribuídos. O YARN e o Mesos, por outro lado, são ambientes de execução abertos que podem ser utilizados para a execução de outras aplicações, além das aplicações específicas do Spark. O Mesos oferece um modo de controle mais granular, não disponível no YARN, e atualmente é o único gerenciador de clusters que permite a execução do Spark através de imagens Docker. Mas se for preciso acessar HDFS Kerberos-secured, o YARN é a única opção. Uma característica importante dos três gerenciadores de clusters é a disponibilização de bastante memória ao Spark. Além disso, a localidade é muito importante para o desempenho. Isso significa que deve-se executar o Spark o mais próximo possível dos dados (por exemplo, ter o Spark instalado nos mesmos nós que o HDFS).
Bonaci: Há razões para pensar que Mesos será o futuro vencedor. Uma vez que o YARN e o próprio cluster do Spark não são genéricos o suficientemente para executar softwares em geral. Portanto, o Mesos tem um futuro brilhante, não apenas relacionado ao Spark, mas como um sistema operacional para data centers. Tenho certeza de que veremos um aumento significativo das implantações de Spark com Mesos num futuro próximo, uma vez que as empresas começam a utilizar o Mesos para executar todas as suas cargas de trabalho. Como exemplo, pode-se citar a AirBnB, Twitter, Apple e muitos outros que possuem grandes infraestruturas.

InfoQ: Quais são as ferramentas de desenvolvimento e testes que os desenvolvedores que estão apenas começando a aprender o Spark podem usar em suas aplicações?

Zečević: Como os aplicativos do Spark podem ser escritos em quatro linguagens diferentes: Scala, Java, Python e R, a resposta depende da linguagem escolhida. Eclipse e IDEA são os dois ambientes de desenvolvimento mais utilizados. O livro disponibiliza instruções passo-a-passo para a criação de um projeto no Eclipse. O Eclipse foi escolhido uma vez que já haviam muitos recursos disponíveis sobre o uso de IDEA para o desenvolvimento Spark.

InfoQ: O que deve ser considerado em termos de otimizações ao utilizar o Spark para processamento de dados e analytics?

Zečević: Existem muitas opções de configuração para alterar o comportamento do cluster Spark, que são diferentes para cada gerenciador de clusters. Primeiro, é preciso familiarizar-se com as diferentes opções de configuração.

As exceções de falta de memória são comuns no Spark. Além de aumentar a memória, a solução é também aumentar o paralelismo. Entretanto, é difícil dizer antecipadamente quantas partições devem ser utilizadas para o paralelismo, por isso, muitas vezes é uma questão de tentativa e erro. O processo é altamente dependente da natureza dos dados e do gerenciador de clusters utilizado. Sendo assim, a configuração inicial pode ser complicada.

Bonaci: O livro contém um capítulo dedicado ao Spark em execução, que inclui as mais importantes recomendações de parâmetros de configuração.
Zečević: O local também é importante para o desempenho, como citado anteriormente, os executores devem estar o mais próximo possível dos dados.

Os programas desenvolvidos com o Spark devem evitar embaralhar desnecessariamente os dados (mais detalhes no livro). Além disso, pode-se utilizar outros truques de otimização, como a transmissão de pequenos conjuntos de dados e a utilização de particionadores personalizados.

Os desenvolvedores do Spark alcançaram um avanço significativo de desempenho com o projeto Tungsten. Esse projeto ainda não atingiu a fase de disponibilidade geral, mas pode-se ter a certeza de que as versões futuras do Spark irão se beneficiar das suas otimizações.

Bonaci: O projeto Tungsten é um desses esforços para "aproximar ao máximo o Spark do hardware", no qual o objetivo é remover qualquer software de uso geral entre o Spark e o sistema operacional (o Tungsten permite ao Spark ignorar a JVM e gerenciar a sua memória). O Tungsten faz muito sentido, principalmente porque corrige um grande conjunto de problemas relacionados com a JVM, sendo o garbage collection o principal deles. Como os usuários finais não estão gerenciando a memória manualmente, não há risco de erros de segmentation fault, de modo que o Spark pode obter grandes espaços de memória fora da heap, com melhorias significativas de desempenho sem qualquer problema visível a partir da perspectiva do usuário final.

InfoQ: Os bancos de dados NoSQL oferecem soluções de armazenamento para diferentes tipos de dados. Como podemos aproveitar o uso de bancos de dados NoSQL e Big Data com o Spark para obter o melhor dos dois mundos?

Zečević: O Spark comunica-se com muitos bancos de dados NoSQL, como o MongoDB e Redis, através de conectores próprios. Além disso, recentemente foi desenvolvido o conector para Redis, que parece ser muito promissor como uma alternativa (mais rápida) em memória para o HDFS. O Cassandra e o Spark complementam-se muito bem, especialmente para armazenar e analisar dados de séries temporais. Cassandra não foi projetado para certos tipos de consultas e é aí que o Spark pode ajudar. Muitos outros bancos de dados, como o HBase, Couchbase e HyperTable, possuem conectores construídos por sua própria comunidade e podem ser efetivamente aproveitados com o Spark.
Bonaci: Além do Cassandra, o Riak da Basho é outro banco de dados inspirado no Dynamo da Amazon, cuja comunidade construiu um conector para o Spark. Também estão disponíveis conectores para: ElasticSearch, Infinispan, SequoiaDB, Cloudant e outros.

InfoQ: O processamento de dados em tempo real e analytics está recebendo muita atenção ultimamente. Como este processamento se compara ao processamento em lote? Qual é a diferença em termos de padrões de projeto e considerações em relação ao desenvolvimento de soluções?

Zečević: O processamento de dados em tempo real manipula conjuntos de dados muito menores do que o processamento em lote. Entretanto, precisa-se processar os dados rapidamente. O processamento em lote, por outro lado, não possui tantas restrições relacionadas ao tempo. Os trabalhos em lote podem levar horas para serem concluídos e, por vezes, envolvem o processamento de todos os dados disponíveis em um departamento ou organização.

Sendo assim, o processamento em tempo real é capaz de disponibilizar os resultados quase ao mesmo tempo em que ocorre a entrada de dados, enquanto os trabalhos em lote retornam resultados com grandes latências.

A arquitetura Lambda é a solução mais adotada para superar esta lacuna de tempo, considerando o momento em que os dados são incluídos, o tempo necessário para processá-los e agregá-los a outros dados da organização, e o momento em que os dados estão disponíveis para o consumo. A arquitetura Lambda envia os mesmos dados a serem processados em lote ao sistema de processamento em tempo real. A saída do sistema de processamento em tempo real é considerada como temporária e pode ser usada enquanto espera a finalização dos trabalhos em lote.

O Spark concilia o processamento tanto em tempo real, quanto em lote, dividindo os fluxos de dados de tempo real em mini-lotes. Desta forma, a mesma API pode ser utilizada para ambas as abordagens. Com um planejamento e design cuidadosos, grande parte do código Spark para o processamento em lote pode ser reutilizada em programas de processamento em tempo real.

Bonaci: Pode-se pensar sobre a dicotomia de tempo real versus processamento em lote da seguinte forma: todo lote começa como um fluxo de dados.

Os dados não estão sendo todos processados em tempo real simplesmente porque não existe capacidade suficiente, principalmente devido aos desafios técnicos e aos custos. Atualmente, as organizações com visão de futuro tendem a processar todos os seus dados de entrada em tempo real, e extrair informações valiosas nos primeiros momentos em que os dados estão disponíveis. Pode-se pensar este paradigma como um banco de dados relacional constantemente atualizado com visualizações materializadas. Por que não usar um banco de dados relacional então? Bem, essa quantidade de dados não cabe em um banco de dados relacional. Pelo menos não um com preço acessível.

É por isso que software open source é importante, pois democratizou a área de Big Data. Sem o Hadoop, mesmo que armazenar grandes quantidades de dados fosse reservado apenas para as chamadas empresas com escala Web (Google, Facebook, LinkedIn, etc) que podem arcar com o esforço de engenharia e infraestrutura necessário. Sem o Kafka seria quase impossível lidar com um fluxo de dados em toda a empresa, muito menos processar os dados em tempo real com o Spark ligado na outra extremidade.

Esta tendência de tempo real foi iniciada pelo projeto Apache Kafka, desenvolvido no LinkedIn e, basicamente virou seus fluxos de dados de cabeça para baixo, partindo de fluxos fortemente orientados a processamento em lote para tempo real. A ideia de "visões em tempo real" também partiu do LinkedIn, na forma do projeto Apache Samza. Posso recomendar uma palestra chamada "Virando o banco de dados de dentro para fora com o Apache Samza", proferida pelo engenheiro do LinkedIn Martin Kleppmann.

InfoQ: O que os desenvolvedores que estão apenas começando com a biblioteca de aprendizagem de máquina devem focar em termos de diferentes algoritmos de ML e pipelines de dados?

Zečević: O Spark fornece os meios para treinar e utilizar vários algoritmos de aprendizado de máquina para a classificação, regressão e redução de dimensionalidade e assim por diante. Entretanto, o uso de algoritmos é apenas uma parte do processo de construção de uma aplicação de aprendizagem de máquina. A preparação de dados, limpeza e análise são também tarefas importantes e, felizmente, o Spark pode ajudar nesta etapa também. Portanto, além de aprender a utilizar algoritmos de aprendizagem de máquina, os desenvolvedores devem também se familiarizar com o Spark Core e a API de SQL. No livro, explicamos estas fases preparatórias e passamos por noções básicas de regressão, classificação e agrupamento, além disso, apresentamos como utilizar estes algoritmos no Spark. Dessa forma, esperamos que o livro ajude os desenvolvedores que estão apenas começando neste campo.

InfoQ: Existem alguma biblioteca que gostaria de ver adicionada ao Spark?

Bonaci: Há um site mantido pela equipe da Databricks (empresa privada fundada pelos criadores do Spark), chamado Spark Packages, que permite a qualquer pessoa enviar qualquer tipo de software relacionado ao Spark. Há quase 200 pacotes, que contemplam adições ao Core do Spark, conectores de fonte de dados, módulos e algoritmos de aprendizado de máquina, streaming e bibliotecas auxiliares para processamento grafo, além de vários outros tipos de pequenos projetos, como um conector de Spark para acessar dados de uma planilha Google.

InfoQ: Podem falar sobre outros componentes do ecossistema como BlinkDB e Tachyon e como eles complementam as funcionalidades do Spark?

Zečević: Existem muitos pacotes do Spark disponíveis para download no site spark-packages.org, e ainda há outros disponíveis de forma independente. BlinkDB é um projeto interessante com muito potencial, mas parece negligenciado (a última versão já tem 2 anos). Mas a ideia de resultados aproximados é muito interessante.

Tachyon foi utilizado desde o início do Spark. Ele fornece um armazenamento de dados distribuídos em memória. Dessa forma, contribui para melhorar o desempenho do Spark.

Há também outros projetos interessantes, como o Zeppelin (uma ferramenta Web de análise de dados que permite a execução de programas com o Spark, e a inspeção dos resultados de um navegador), IndexedRDD (um Spark RDD que contém dados atualizáveis e indexados), Sparkling Water (fornece uma maneira de executar clusters H2O com o Spark; H2O é um sistema que facilita a utilização de máquinas de aprendizagem, que possuem algoritmos para Deep Learning, etc), dentre outros projetos.

InfoQ: Quais são as novas funcionalidades do Spark que os usuários devem esperar?

Bonaci: Ocorreram alguns problemas com o conector de Kafka, devido principalmente à implementação de um consumidor de alto nível do Kafka 0.8, o que não permite a leitura da partição a partir de uma posição arbitrária, somente a partir do início ou do final. Isso implica que o Spark necessita confiar em seu próprio mecanismo de verificação para guardar as mensagens consumidas, a fim de minimizar a perda de dados em caso de falha do nó. Está em desenvolvimento um novo consumidor do Kafka 0.9, que une os consumidores de alto e baixo nível, mantendo-se o melhor dos dois mundos.
Zečević: Em relação as novidades mais importantes em desenvolvimento, destaco as redes neurais artificiais. Além disso, DataFrames estão chegando ao componente GraphX, que deve torná-lo mais rápido e mais fácil de usar. O projeto Tungsten também trará melhorias para grande parte do Spark. A IBM está adicionando mecanismos de monitoramento de recursos para a interface Web do usuário. Há também uma grande quantidade de pequenos recursos e melhorias que estão chegando, muito numerosas para mencionar aqui. O Spark é um projeto muito movimentado e coisas novas estão sendo adicionadas tão rapidamente que é difícil manter-se atualizado, portanto, fique atento.

InfoQ: Quais são os recursos ou aprimoramentos específicos desejáveis para as versões futuras do Spark?

Zecevic: Espero que o IndexedRDD se torne parte do Core do Spark em breve. As redes neurais já forma mencionadas, mas redes neurais convolucionais são também uma necessidade (já planejada). Seu desempenho se beneficiaria enormemente se elas pudessem ser executadas em GPUs. Então, outra melhoria seria ter uma forma simples de usar GPUs no Spark.

Muito pode ser feito em relação a usabilidade, por exemplo, poderiam ser feitos assistentes visuais para várias tarefas, tais como: modelos de aprendizagem de máquinas de construção e transformação, além de análise de dados com DataFrames.

Apesar de parecer ficção científica, seria ótimo se o Spark fosse capaz de se auto configurar (memória, CPU, paralelismo, tamanho do lote de streaming, etc) com base nos dados, na carga do usuário, na arquitetura de cluster e assim por diante. Em outras palavras, torná-lo mais plug-and-play.

Petar e Marko também falaram sobre como o livro pode ajudar os leitores a iniciar um novo projeto Spark, usando as instruções fornecidas no Capítulo 3.

Zečević: O Spark tornou-se mainstream e se estiver trabalhando com Big Data, seria um erro ignorá-lo. Se não tiver feito isso ainda, ao comprar o nosso livro, vamos ajudá-lo nessa jornada.
Bonaci: Seus leitores podem achar útil a informação que, no processo de escrita do livro, foi desenvolvido um archetype Maven (template Scala), que permite inicializar um novo projeto Spark no Eclipse ou no IDEA, em apenas alguns cliques. O processo é explicado no repositório GitHub disponível publicamente.

O livro fornece instruções passo-a-passo, que partem de passos bem iniciais, como o download do Spark, sua instalação, sua configuração inicial, a instalação do IDE e configuração, o uso do shell do Spark, a criação de um novo projeto em sua IDE, e exemplos de código. Temos até algumas histórias para tentar fazer exemplos ao vivo. Partes mais complicadas são ilustradas com imagens, de modo que o livro é realmente um grande tutorial de Spark. Estamos muito ativos na lista de discussão e prometemos auxiliar em qualquer dúvida.

O livro encontra-se na fase de acesso antecipado (MEAP) e estará disponível neste inverno.

Sobre os autores

Petar Zečević é CTO do Grupo SV. Durante os últimos 14 anos vem trabalhando em vários projetos como desenvolvedor Java, líder de equipe, consultor e especialista em software. É o fundador e organizador do meetup Spark@Zg.

Marko Bonaci trabalha com Java há 13 anos. Desenvolvedor full-stack e consultor na Sematext, atua principalmente com Kafka no back-end e React no frontend. É organizador do meetup Spark@Zg juntamente com Petar Zečević. Antes disso, foi líder da equipe Enterprise Content da IBM.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT