Spark e Storm: depois do MapReduce (arquiteturas Lambda e Kappa)

01 · CONTEXTO

O que o MapReduce deixou sem resposta

Nos frameworks de análise em cluster da época do paper dos RDDs, como o MapReduce, reaproveitar dados entre duas computações tinha um custo alto: na maior parte deles, o único caminho era gravar o resultado num sistema de armazenamento estável externo, como um sistema de arquivos distribuído. Esse caminho traz sobrecarga de replicação, de I/O de disco e de serialização.

O Spark nasce dessa limitação. O paper que o apresenta parte de duas classes de aplicação que os frameworks da época tratavam de forma ineficiente: algoritmos iterativos e ferramentas interativas de mineração de dados. A resposta do Spark a essas duas classes é o ponto de partida deste caso, que segue até o processamento de streams.

02 · RDDS E LINHAGEM

Dados em memória sem pagar a réplica

1. Para reaproveitar dados entre duas computações, a maioria dos frameworks da época exigia gravá-los no armazenamento estável externo.

2. Com RDDs, o usuário pode pedir explicitamente que resultados intermediários fiquem persistidos em memória.

3. Se uma partição de um RDD se perde, o RDD tem informação suficiente sobre como foi derivado de outros RDDs para recomputar apenas aquela partição.

4. A tolerância a falhas vem de registrar as transformações usadas para construir o conjunto, a linhagem, em vez dos dados em si.

O truque está na interface. Os RDDs oferecem transformações de granularidade grossa, como map, filter e join, que aplicam a mesma operação a muitos itens. Já nas interfaces de atualização fina de estado, as únicas formas de tolerar falhas são replicar os dados entre máquinas ou registrar as atualizações em log entre máquinas.

03 · STREAMING EM MICROLOTES

Spark Streaming: o fluxo vira uma sequência de lotes

O próprio paper dos RDDs aponta o caminho do processamento em lotes periódicos: aplicações que atualizam um resultado com dados novos, como estatísticas de cliques em anúncios a cada 15 minutos, combinando o estado da janela anterior com os logs novos. Os sistemas desse tipo citados no paper guardam o estado da aplicação em sistemas de arquivos distribuídos, e o passo seguinte, neste caso, é ver como o Spark Streaming trata esse fluxo em pipelines de dados.

1. O Spark Streaming recebe fluxos de dados ao vivo, de fontes como Kafka e Kinesis, e os divide em lotes.

2. Cada lote é processado pelo motor do Spark, e o fluxo de resultados também sai em lotes.

3. Para evitar a perda dos dados já recebidos, o Spark introduziu logs de escrita antecipada; com eles e com receivers confiáveis não há perda de dados, e a semântica é de pelo menos uma vez.

4. Para exatamente uma vez de ponta a ponta, cada etapa do processamento precisa oferecer essa garantia, inclusive a entrega ao destino.

04 · STORM

Topologias que rodam para sempre

1. No Storm, a lógica da aplicação é uma topologia: um grafo de spouts e bolts ligados por stream groupings, que roda para sempre, ao contrário de um job MapReduce.

2. O stream é uma sequência ilimitada de tuplas, processada e criada em paralelo de forma distribuída.

3. Uma tupla que saiu do spout é considerada totalmente processada quando a árvore de tuplas foi esgotada e todas as mensagens da árvore foram processadas.

4. Se a árvore não é totalmente processada e a tupla estoura o tempo limite, o Storm chama o método fail no spout; com tuplas ancoradas, a tupla raiz é reemitida.

05 · SEMÂNTICA DE PROCESSAMENTO

Exatamente uma vez, mas onde?

Na documentação do Spark Streaming, o processamento de qualquer stream tem, em linhas gerais, três etapas. Na etapa de transformação, todos os dados recebidos são processados exatamente uma vez, graças às garantias dos RDDs, desde que os dados de entrada recebidos continuem acessíveis. Já na recepção, cada fonte de entrada oferece garantias diferentes, e por isso a garantia de ponta a ponta depende de todas as etapas.

No Storm, a página sobre garantia de processamento descreve o nível de pelo menos uma vez com base na árvore de tuplas, no tempo limite que gera falha e na reemissão da tupla raiz.

06 · ARQUITETURA LAMBDA

Duas camadas para consultas rápidas e corrigíveis

1. Os eventos chegam a um conjunto mestre de dados imutáveis, que só recebe acréscimos.

2. A camada batch pré-computa as consultas sobre todo o conjunto de dados, o jeito mais fácil de deixá-las rápidas.

3. Os dados mais antigos que algumas horas já estão nas views batch; a camada de tempo real pré-computa as consultas só para as últimas horas.

4. Para responder, o serviço consulta a view batch e a view de tempo real e junta os resultados.

5. Um erro na camada de tempo real é corrigido pela camada batch, que acaba sobrescrevendo o que o tempo real calculou.

O mesmo desenho dá um caminho de correção. Se uma consulta tem um bug, basta corrigir, publicar a versão corrigida e recomputar tudo a partir do conjunto mestre; e, como os dados são imutáveis e o conjunto só recebe acréscimos, gravar dado ruim não sobrescreve nem destrói dado bom.

07 · ATUALIDADE

O que mudou desde então

A documentação atual do Spark descreve o Spark Streaming (DStreams) como a geração anterior do motor de streaming do Spark.