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. O primeiro mantém todos os registros já lidos pelo stream em memória por todo o tempo de execução da aplicação e sempre os reescreve no destino. O segundo escreve no destino apenas novos dados, se diferenciando do último por não escrever dados que foram atualizados. Os modos de saída se diferem para cada tipo de query, na documentação oficial é demonstrada a matriz de compatibilidade.
A contrapartida ao processamento em microbatch é o continuous programming model, que trata o stream evento a evento, tornando possível a entrega dos dados com intervalos próximos a 1ms. Esse modelo de processamento é amplamente considerado como experimental, mesmo quando se deseja entregar dados em plataformas de eventos como o Kafka. Com isso, numa eventual análise de uso do Spark Structured Streaming em que o tempo desejado de entrega de um dado tende estar mais ligado ao modelo de processamento contínuo, é ideal ficar em alerta e analisar outros serviços de streaming de dados.
Os modelos de processamento existentes são parte da abstração implementada pelo Spark para omitir a complexidade de tratar dados em stream de maneira distribuída, nos dando meios de tratarmos uma visão parcial de um conjunto de dados. A visão dos dados, a noção de tempo e a imprevisibilidade de streams servirão de guia quando necessário configurar e otimizar uma aplicação Spark em streaming.