Pilares e boas práticas do processamento de streams com Spark

Integrar o Spark com o Kafka é um desafio que pode envolver todos os usuários de um cluster Kafka, ainda assim algumas boas práticas podem nos auxiliar a acelerar o desenvolvimento desta ligação e otimizar nossos resultados. Toda a parte de produção de mensagens no Kafka utilizando Spark pode ser considerada experimental por escrever utilizando o modo continuous, desta forma nós engenheiros de dados acabando nos preocupando mais com o consumo dos dados do serviço....

Decidir a arquitetura para processamento dos dados é mais um caso no mundo tech onde não há bala de prata. A escolha entre Kappa e Lambda pode partir de duas questões, uma acerca da origem e outra do destino: A fonte dos dados é puramente um stream? Ou seja, o único meio de recuperar dados históricos é conectando ao stream? No destino, o dado proveniente do stream deve se unir a dados do mesmo contexto com outra fonte?...

Ao fazer a leitura de dados em streaming, temos duas opções para retirar um frame desse conjunto infinito; sendo o default deles o microbatch, que possibilita a acumulação de eventos de forma configurável, com limites superior e inferior de volume. Documentos do Spark abordam que um intervalo mínimo performático entre execuções de microbatches seja a partir de 100ms. A escrita de microbatches é subdivida em 3 modos: complete, append e update....

Ao trabalhar com cargas em batch, idealmente temos a visão completa ou parcialmente limitada de um dataset, como em pipelines incrementais. Tal visão holística dos dados garante que agregações ou visões do passado vão nos dar resultados ao mínimo constantes no passar do tempo. O consumo de dados que estão em constante movimento, nos obriga a pausar o processo de leitura caso necessário observar o que já foi lido. Aqui as agregações, por terem um contexto bem delimitado da visão observada durante o tempo, são possíveis mas exigem controles vindo de conceitos como watermarking e stateful streaming, que abordaremos em outra seção....

No meio clássico de uso do Spark, nós temos um grupo de máquinas que executam um ETL em um conjunto de dados previsível, onde já se conhece previamente o tamanho e quantidade de dados (finita) a serem processados, ou seja, conseguimos ajustar o tamanho desse cluster ao longo do tempo. Por outro lado, ao ler dados em streaming, podemos ter de zero a infinitos números de registros, que podem variar seu throughput ao longo do tempo....