o problema
Um stream não para, e uma consulta contínua sobre ele só faz sentido sobre uma janela — “latência média por região nos últimos 5 minutos, atualizada a cada 10 segundos”. Sem recorte temporal a agregação nunca fecha. Cada consulta chega com a sua janela: tamanho e passo escolhidos por quem montou o painel, não por quem opera o sistema. Numa instalação real não existe uma consulta; existem dezenas sobre o mesmo fluxo, com janelas parecidas e nenhuma idêntica. A execução ingênua mantém um estado por consulta e empurra cada tupla por todos eles. O custo cresce com o número de consultas, e a taxa de chegada dos dados não colabora. Pior: o dado passa uma vez. Não dá para reler o stream depois, como se relê uma tabela.
A resposta clássica de banco de dados é otimização multi-consulta em tempo de compilação: achar a subexpressão comum, montar um plano que a calcula uma vez e distribui o resultado para quem precisa. Isso pressupõe conhecer o conjunto de consultas antes de começar a executar. Stream é o caso em que essa premissa não vale. Alguém abre um painel novo às três da tarde, outro fecha o dele, e o sistema não pode parar o mundo para recompilar — o estado acumulado das janelas é a única cópia do passado que ele tem.
a ideia
O movimento anunciado pelo título é tirar a decisão de compartilhar do compilador e colocá-la na execução. Não é procurar subexpressão comum no texto das consultas antes de rodar; é perceber, com os dados já correndo, que dois consumidores querem o mesmo trabalho e fazê-lo uma vez. A sobreposição entre janelas é a matéria-prima: a mesma tupla entra na resposta de várias consultas, e cada recomputação é trabalho repetido que o sistema pagou porque não olhou.
Aqui este verbete para. O que chegou do paper foi a ficha — título, os três autores, SIGMOD 2006, páginas 623 a 634 — sem o resumo. A estrutura de dados, o critério de decisão e os experimentos ficam de fora porque não os vi. Use isto como referência do problema e do alvo, não da solução: para a solução, o original é obrigatório.
o que isso custou
As limitações declaradas pelos autores eu não posso listar, pelo mesmo motivo: elas estariam no texto que não veio, e atribuir a eles uma ressalva que ninguém escreveu seria inventar.
O que dá para dizer é o que a abordagem cobra pela própria forma do problema. Decidir em tempo de execução significa gastar tempo de execução decidindo: a contabilidade de quem compartilha o quê é paga no caminho quente, tupla a tupla, e precisa ser mais barata que a recomputação que evita. Compartilhar também acopla. Consultas que dividem estado deixam de ser independentes — admitir uma nova ou remover uma velha mexe no que as outras estão usando, e o isolamento entre elas, que na execução ingênua era grátis, vira problema de projeto. E memória compartilhada não se descarta pelo critério de um único consumidor: enquanto a janela mais longa precisar de um dado, ninguém libera. O ganho de não recomputar aparece como estado que fica vivo mais tempo.
onde isso aparece hoje
A janela deixou de ser detalhe de implementação e virou vocabulário. O The Dataflow Model formaliza janela, gatilho e chegada fora de ordem como conceitos de primeira classe, e é o lugar onde hoje se discute o que significa “o resultado dos últimos 5 minutos” quando os dados chegam atrasados — a mesma pergunta que agregação sobre stream levanta desde os anos 2000.
A outra metade da história é a infraestrutura que tornou o cenário comum. Com Kafka e o que veio depois, ter dezenas de consumidores no mesmo tópico virou o normal, não a exceção; e descrições de operação em escala como a de Real-time Data Infrastructure at Uber mostram o formato que o problema assume em produção — muitas consultas concorrentes sobre o mesmo fluxo, com o custo de recomputação aparecendo na conta de CPU e no atraso do resultado.