Storm vs. Spark: uma introdução à Fast Data

Muitos analistas apontam que o Big Data não pode ser visto como a solução para todos os problemas computacionais atuais, mesmo para os que envolvem dados. Isso porque a análise de dados das aplicações modernas envolve muitas facetas, como análise de estatísticas, aprendizado de máquina e soluções em tempo real.

Do ponto de vista do desenvolvimento de software, o principal fator que permitiu a construção de aplicações Big Data foi o advento do paradigma de MapReduce.

Esse paradigma, publicado em 2004, foi desenvolvido pelo Google para seu mecanismo de busca e tem como objetivo processar grandes quantidades de dados através da execução de Jobs em lote (tradução do termo em inglês batch), podendo assim computar um incrível volume de dados com enorme vasão (tradução do termo em inglês throughput).

Durante a última década, o MapReduce revolucionou a TI, principalmente através do Apache Hadoop, sua implementação mais difundida.

Contudo, ao longo do tempo descobriu-se que esse paradigma não é suficiente para lidar com aplicações Big Data nas quais a latência é tão ou mais importante que o throughput.

Para entender a diferença entre esses dois conceitos, imagine uma aplicação de controle de servidores responsável por enviar e-mails aos administradores de sistemas em caso de falhas. Nestes casos, ter uma grande vazão (alcançada, por exemplo, com o uso do Hadoop) representaria avisar uma quantidade enorme de usuários ao mesmo tempo.

Por outro lado, uma latência pequena representaria avisar tais usuários em poucos segundos após a falha ocorrer.

No cenário dessa aplicação, claramente uma latência pequena é mais importante que uma vazão grande, pois um retardo de horas não seria interessante mesmo que a quantidade enorme de administradores seja avisada após a falha ocorrer.

Em vista disso, passou a ser natural o desenvolvimento de ferramentas que garantam baixa latência no cenário de Big Data. Ao conceito que engloba estas novas ferramentas foi dado o nome de Fast Data (dados rápidos, em inglês). Segundo a InfoWorld, representam o próximo passo na evolução do Big Data, pois podem ser entendidos como uma contraposição à limitação do Hadoop em prover baixa latência.

Nesse contexto, tempo real pode ser entendido como um sinônimo de streaming, pois aplicações de Fast Data são desafiadas a examinar em poucos segundos uma enxurrada de dados recebida de forma incessante, sendo esse exame fundamental para o modelo de negócio no qual estão inseridas.

Esse problema vem sendo estudado em paralelo e de diferentes maneiras pelos grandes players de redes sociais, sendo criados, portanto, distintos tipos de soluções para streaming como, por exemplo: baseada no modelo publisher/subscriber, como a proposta pelo LinkedIn; em troca de mensagens, como a adotada pelo Twitter; e no uso intensivo de agregações, como a projetada pelo Facebook.

Com base nesses conceitos, este artigo apresentará dois frameworks que propõem soluções para análise em tempo real de informações Big Data: Apache Storm e Apache Spark. Ainda que possam ser usados por um grande número de linguagens, Storm e Spark – desenvolvidos respectivamente em Clojure e Scala, duas linguagens executadas pela JVM – guardam como semelhança o fato do Java ser comum a ambos.

Por isso, este artigo apresenta o desenvolvimento de aplicações usando as APIs Java destas tecnologias com foco principal na criação de uma aplicação de monitoramento em tempo real de páginas web.

Além desta, outras similaridades importantes entre estes frameworks são: baseiam-se em clusters e no uso intensivo de memória principal, e têm a baixa latência como principal requisito de projeto. Contudo, essa aparente sobreposição é apenas superficial, pois a forma de implementação e os casos de uso variam bastante de uma ferramenta para outra, como poderemos constatar nos próximos tópicos.

Apache Storm

O Storm é um framework projetado para ser escalável, tolerante a falhas, com garantia de resposta e ainda pensado para prover facilidade de configuração e operação. Esses objetivos de projeto são atingidos através de quatro abstrações básicas, analisadas a seguir e ilustradas na Figura 1:

· Tuple (em português, Tupla): representa uma mensagem que flui através da arquitetura do Storm. As tuplas carregam informações que vão sendo computadas, transformadas ou persistidas pelos componentes dessa arquitetura.

Essas informações podem ser, por exemplo, um twitter postado pouco tempo antes, um documento recentemente cadastrado ou uma nova leitura do GPS feita por um sensor;

· Spout (em português, torneira): são elementos de código (mais propriamente classes) que estão conectados a uma fonte de dados para transformar estes dados em tuplas, que por sua vez passam a ser processadas pelo Storm;

· Bolt (em português, raio): são classes responsáveis unicamente por fazer computações (como transformações, cálculos, filtros, agregações, persistência) sobre as tuplas enviadas pelos spouts ou por outros bolts;

· Topologia: define como Spouts e Bolts são combinados em certa aplicação.