Como você lida com eventos que chegam atrasados em um pipeline de streaming?

Use tempo de evento em vez de tempo de processamento e defina um watermark, que é a estimativa heurística do motor de que nenhum evento mais antigo que um dado timestamp ainda vai chegar. As janelas fecham quando o watermark passa o fim delas. Configure um atraso tolerado para que eventos ligeiramente atrasados ainda atualizem os resultados e mande qualquer coisa mais atrasada para uma saída lateral ou uma tabela de reconciliação, em vez de descartar em silêncio.

Primeiro, tudo é chaveado por tempo de evento, porque resultados por tempo de processamento mudam a cada replay e isso os torna inúteis para reconciliação. Depois, o watermark é a afirmação do motor de que ele não espera mais eventos anteriores a esse timestamp, e as janelas se finalizam quando ele passa por elas. Escolher esse atraso é a decisão de design de verdade: um watermark curto entrega resultados rápidos que às vezes estão incompletos, um longo entrega resultados corretos com atraso. Eu defino a partir dos dados, não da intuição. Em um pipeline de app mobile nós medimos a diferença entre tempo de evento e tempo de ingestão e descobrimos que o percentil noventa e nove era de cerca de quatro minutos, causado por celulares offline, então definimos o atraso tolerado em dez minutos. Qualquer coisa mais atrasada ia para uma saída lateral que alimentava um job diário de reconciliação, que corrigia as janelas afetadas no warehouse. A regra que eu mantenho é que dado atrasado nunca é descartado em silêncio. Se a gente descarta, primeiro a gente conta.