o problema
Um data warehouse na nuvem toma dezenas de decisões antes de rodar uma linha de SQL. Essa query entra agora ou espera na fila? Quanta memória reservar? Vale a pena materializar essa view? Todas dependem de uma estimativa só: quanto tempo a query vai levar. O Redshift usa previsão de tempo de execução tanto em otimizações de alto nível, como criar materialized views automaticamente, quanto em tarefas no caminho crítico da execução — admissão, escalonamento e controle de recursos.
O incômodo é que essa estimativa é historicamente ruim. Os autores são diretos: as técnicas existentes, incluindo as que o próprio Redshift usava, sofrem de cold start, erram a estimativa e não são robustas a mudanças de workload ou de dados. Cold start é o pior dos três num produto de nuvem, porque cada cliente é uma instância nova. Um modelo que só aprende com o histórico local nasce cego, e fica cego justamente na janela em que o cliente está formando opinião sobre o produto. E um modelo treinado uma vez envelhece: a tabela cresce, o time troca o dashboard, e a estimativa que era boa vira ruído.
a ideia
Em vez de escolher entre um modelo por instância e um modelo para todo mundo, o Stage usa os dois, mais um cache, e trata a escolha entre eles como parte do sistema.
São três estados de modelo. Um cache de tempos de execução, que devolve a resposta ótima para o que já foi visto. Um modelo local, leve, otimizado para uma instância específica de banco, que carrega junto uma medição de incerteza. E um modelo global, complexo, treinado com conhecimento transferível entre todas as instâncias do Redshift. O nome hierárquico vem daí: existe um caminho sistemático para usar as três camadas, extraindo de cada uma o que ela faz melhor — otimalidade do cache, especialização do modelo local, conhecimento transferível do global.
A parte que interessa é o casamento entre cold start e incerteza. O modelo local não tem como ser bom numa instância recém-criada, e a medição de incerteza dá ao sistema um sinal explícito disso, em vez de deixar o modelo responder sempre com a mesma cara de confiança. O modelo global existe porque as instâncias do Redshift, apesar de diferentes, rodam o mesmo motor: o que se aprende sobre o comportamento de um operador no Redshift vale em qualquer conta.
o que isso custou
O preditor está no caminho crítico da query, então compete com a query pelos mesmos recursos. Os autores tratam latência de inferência e overhead de memória como restrições de primeira classe — o resultado que reportam é previsão mais precisa e mais robusta mantendo os dois em nível prático, não precisão a qualquer preço. Um modelo grande no caminho crítico é uma ideia que se paga sozinha por baixo.
O custo estrutural é operacional: três artefatos para treinar, versionar, servir e depurar, mais uma política de roteamento entre eles que também pode errar. Quando a previsão sai torta, a pergunta “qual das três camadas respondeu, e por quê” passa a fazer parte do trabalho.
Um alerta sobre o número. O ganho relatado é de 20% na latência média de execução, comparado ao preditor anterior do Redshift e medido nas instâncias do experimento. É melhoria de decisão, não de motor: o Stage não deixa nenhuma query mais rápida, ele evita as decisões que deixavam algumas mais lentas. E o resumo do trabalho não enumera as limitações declaradas pelos autores — para saber onde o Stage falha, o texto completo é obrigatório.
onde isso aparece hoje
Stage é uma peça de um programa longo. O Redshift vem publicando há uma década sobre a passagem de um warehouse configurado à mão para um que se ajusta sozinho: Amazon Redshift and the Case for Simpler Data Warehouses descreve a aposta inicial na simplicidade operacional, e Amazon Redshift Re-invented mostra o motor já cercado de componentes automáticos. Previsão de tempo de execução é a entrada que quase todos esses componentes consomem.
Do mesmo ano saíram Intelligent Scaling in Amazon Redshift e Predicate Caching. Decidir quando escalar um cluster e decidir o que vale a pena guardar são, no fundo, o mesmo tipo de aposta sobre custo futuro de execução — a mesma aposta que o Stage tenta transformar em número.