Trilha Sistemas de Streaming: tudo o que estudar, tópico por tópico

Compreender a falsa dicotomia entre batch e streaming: streaming é um superconjunto que processa dados não-limitados com baixa latência, enquanto batch é streaming sobre um conjunto de dados limitado

A natureza dos conjuntos de dados não-limitados (infinitos): dados que chegam continuamente sem um fim conhecido, exigindo processamento incremental e uma estratégia para emitir resultados antes de todos os dados terem chegado

A dualidade fundamental: um stream é o changelog de uma tabela, e uma tabela é o snapshot acumulado de um stream. O agrupamento converte um stream em tabela; o desagrupamento converte uma tabela de volta em stream

Os dois domínios de tempo: tempo do evento (quando o evento de fato ocorreu) versus tempo de processamento (quando o sistema o observa), e o desvio (skew) variável e imprevisível entre eles

As quatro perguntas que estruturam qualquer pipeline de processamento de dados fora de ordem: O QUÊ é computado (transformações), ONDE no tempo do evento é computado (janelamento), QUANDO no tempo de processamento é materializado (gatilhos/watermarks) e COMO os refinamentos se relacionam (acumulação)

Janelas fixas (tumbling) particionam o tempo do evento em intervalos contíguos, não sobrepostos e de tamanho igual, com cada elemento atribuído a exatamente uma janela

Janelas deslizantes (hopping) definidas por um tamanho e um período; quando o período é menor que o tamanho, as janelas se sobrepõem e um único elemento pertence a múltiplas janelas

Janelas dinâmicas e orientadas a dados que agrupam rajadas de atividade separadas por intervalos maiores que uma duração de intervalo configurada; a extensão das janelas depende dos próprios dados

A mecânica de mesclagem que faz as janelas de sessão funcionarem: cada elemento inicialmente forma uma proto-janela, depois janelas sobrepostas se mesclam; a mesclagem interage com gatilhos, watermarks e estado

Uma watermark é uma noção de completude da entrada no tempo do evento: uma afirmação monotônica de que não se espera mais dados com tempo do evento anterior à watermark

Watermarks perfeitas garantem que não haja dados atrasados, mas exigem conhecimento perfeito da entrada; watermarks heurísticas estimam a completude e podem errar, produzindo dados atrasados que devem ser tratados

Como as watermarks fluem por um pipeline de múltiplos estágios: watermarks de entrada/saída por estágio, o mínimo entre entradas e entre chaves/shards, e como a fonte mais lenta limita o progresso geral

Diagnosticar a saúde do pipeline via desvio (skew) da watermark (o quanto a watermark fica atrás do tempo real) e a interação entre completude, latência e watermarks travadas por stragglers ou fontes lentas

Gatilhos que disparam quando a watermark ultrapassa o fim de uma janela, materializando um único resultado pontual quando a completude no tempo do evento é alcançada

Gatilhos que disparam em intervalos de tempo de processamento (por exemplo, a cada N segundos) para entregar resultados parciais de baixa latência e atualizados regularmente, independentemente da completude

Gatilhos que disparam com base em propriedades dos dados acumulados em uma janela, como uma contagem de elementos ou um limite de tamanho, em vez de com base no tempo

Combinar gatilhos para expressar políticas realistas: disparos especulativos antecipados no tempo de processamento, um disparo pontual na watermark e disparos atrasados conforme dados atrasados chegam (o padrão antecipado/pontual/atrasado)

Como disparos sucessivos de painéis se relacionam: descartar (deltas), acumular (sobrescritas cumulativas) e acumular-e-retratar (emite uma retratação do valor anterior mais o novo valor)

Tratar dados que chegam depois que a watermark ultrapassou o fim de sua janela (dados atrasados), o que ocorre sempre que uma watermark heurística avança de forma agressiva demais

O horizonte de atraso permitido limita por quanto tempo, além da watermark, o estado da janela é retido para que dados atrasados ainda possam ser processados; além dele, o estado é coletado e dados posteriores são descartados

Alcançar semântica de saída efetivamente-uma-vez apesar de novas tentativas e falhas, por meio de operações determinísticas, checkpointing, destinos idempotentes ou transacionais e deduplicação

Primitivas gerais de processamento com estado — estado persistente por chave e temporizadores por tempo do evento/tempo de processamento — que fundamentam janelamento, junções e agregações incrementais customizadas

O modelo unificado Beam/Dataflow que separa as perguntas o quê/onde/quando/como do runner, permitindo que um único pipeline execute em batch ou streaming entre engines com semântica consistente

A arquitetura Lambda executa camadas batch e de velocidade em paralelo e as reconcilia; a Kappa serve todas as consultas a partir de uma única camada de streaming reproduzível. O argumento semântico por um único sistema de streaming

A visão mais profunda de streams e tabelas que reformula todo o modelo: agrupamento/gatilhos transformam um stream em tabela e o desagrupamento transforma uma tabela em stream, unificando batch, streaming, SQL e junções