12.3. Tempo, joins e tolerância a falhas em streams
Use o tempo do evento, não o de processamento; janelas, joins e checkpoints dão resultado correto mesmo com falhas.
Resumo
- Usos: CEP (padrões), analytics em janelas, manter views materializadas, busca em stream.
- Tempo do evento × tempo de processamento: atrasos e reprocessamento distorcem o segundo. Atrasados: watermark ou correção.
- Janelas: tumbling (fixa), hopping (sobreposta), sliding e session (por inatividade).
- Joins: stream-stream (cliques × buscas na janela), stream-tabela (enriquecer com cache via CDC), tabela-tabela (view materializada).
- Tolerância a falhas: microbatch ou checkpoints, commits atômicos e idempotência dão efeito exactly-once.
Perguntas-chave
responda de cabeça, depois abraPor que agrupar por tempo de processamento é perigoso?
Se o consumidor parar e voltar, processa um backlog de uma vez e cria um pico falso de eventos naquele minuto.
Como saber que uma janela pode ser fechada?
Com watermark: uma estimativa de que eventos anteriores a T já chegaram; atrasados depois disso são descartados ou geram correção.
O que é um join stream-tabela?
Enriquecer cada evento com dados de uma tabela (ex.: perfil do usuário), mantida localmente atualizada por CDC.
Exercícios de fixação
0/5 respondidas1.
O consumidor fica 10 minutos fora; ao voltar, o painel mostra um pico enorme de acessos às 10h10. A causa provável:
2.
Agrupar as ações de um usuário até ele ficar 30 minutos inativo usa janela:
3.
Calcular a taxa de cliques juntando eventos de busca e de clique ocorridos com até 1 hora de distância é um join:
4.
Cada evento de compra precisa do país do usuário. A abordagem mais eficiente é:
5.
Como frameworks como Flink oferecem resultado exactly-once após falhas?