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

Lidar com dados em larga escala exige diversas precauções sob o meio que vamos fazer a leitura, escrita e as iminentes transformações. O Spark traz garantias de tolerância à falhas e também escalabilidade quando desejamos trabalhar com grande volumes. Ele junto às novas APIs de Structured Streaming podem ser a solução ideal quando precisamos de armazenamento em estruturas de datalake ou data lakehouse. Vamos desvendar aqui um pouco sobre o vocabulário, alguns conceitos e pontos de partida para uso da ferramenta....

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....

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....

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....

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?...