Como o Databricks Feature Store disponibiliza features com atualização em menos de um segundo

Modelos de machine learning são tão bons quanto os sinais que recebem. Um caso de uso de detecção de fraude deve decidir em milissegundos, a partir do momento em que o usuário clica em comprar, se permite ou não a transação. Tomar a decisão certa depende de identificar uma transação suspeita que ocorreu há apenas alguns segundos. Combinar a média de transações de um usuário nos últimos 30 dias com o valor total de transações dos últimos 10 minutos destaca a fraude em potencial. As agregações de longo prazo definem um perfil de referência do usuário para determinar o que é normal, enquanto os dados mais recentes ajudam a evidenciar qualquer comportamento anormal no exato momento em que ele acontece. A personalização enfrenta a mesma pressão: os sinais mais recentes são os que capturam a intenção atual do usuário e geram engajamento.

Os pipelines do Spark são uma maneira consolidada de processar dados em lote no Lakehouse para features históricas de baseline. Executar esses jobs em lote de forma programada é algo bem consolidado, mas introduz minutos ou horas de atraso (lag). Para sinais de baseline sobre os usuários, esse atraso é um preço aceitável para se ter uma infraestrutura mais simples. Quando os modelos exigem sinais recentes, essa infraestrutura falha; reduzir o tempo para segundos ou milissegundos não é possível nas plataformas de feature store existentes. Para entregar o valor de features recentes, os cientistas de dados são forçados a implementar lógicas complexas e específicas de streaming para lidar com essas agregações e estruturar uma infraestrutura de hospedagem personalizada.

O Databricks Feature Store permite que você crie uma feature uma única vez e a use em qualquer lugar: a mesma definição alimenta fluxos em lote de grande escala offline e pipelines de features altamente atualizados online. O framework elimina a sobrecarga de infraestrutura, orquestrando o Spark Real-Time Mode (RTM) para processamento contínuo de fluxo (streaming), o Lakebase para armazenamento online otimizado para streaming e o Model Serving para recuperação em escala. E, uma vez criada, essa feature é disponibilizada em milissegundos: latência p99 de ponta a ponta de 200 ms, desde a chegada de um evento no Kafka até a sua disponibilidade no feature store online.

Arquitetura: do Kafka ao Feature Store em 200 ms

Vamos dar uma olhada nos bastidores para ver como o Databricks Feature Store pega uma definição de Feature independente de infraestrutura e constrói um pipeline para computá-la de forma consistente em milissegundos. O caminho de ponta a ponta para uma feature de streaming funciona assim:

1. Os eventos chegam ao Kafka — dados brutos como transações de cartão de crédito, impressões de anúncios ou eventos de clickstream
2. Um pipeline do Spark RTM no serverless Lakeflow Spark Delta Pipelines processa eventos continuamente, computando agregações contínuas em tempo real
3. As agregações atualizadas são gravadas no Lakebase por meio de um novo sink de streaming JDBC, chegando ao feature store online
4. Endpoints do Model Serving recuperam as features mais recentes do Lakebase no momento da inferência, alimentando-as no modelo de forma automática

Vamos associar isso à nossa feature de fraude: a soma do valor das transações de um usuário nos últimos 10 minutos. Cada evento recebido traz os detalhes da transação — valor, localização, ID do usuário, informações do estabelecimento — e é direcionado para um pipeline com estado (stateful). O pipeline consulta uma instância local do RocksDB que mantém o total acumulado de transações do usuário, com tempos de expiração que limitam a janela aos últimos 10 minutos. O pipeline lê e incrementa o valor localmente e, em seguida, grava o valor atualizado da feature no Lakebase. Assim, quando uma consulta chega ao modelo para aprovar uma nova transação, a soma atualizada das transações fica disponível no feature store com atualização em menos de um segundo. Essa feature de soma será buscada juntamente com a baseline histórica de compras do usuário para subsidiar a aprovação. Uma soma muito acima da baseline histórica é um forte indicador de fraude em potencial para o modelo.

Cada componente desse pipeline foi otimizado para que os eventos recebidos sejam roteados, as agregações sejam calculadas e as features sejam gravadas no store online o mais rápido possível.

Janela contínua (rolling window): atualize agregações em milissegundos

Antes de nos aprofundarmos na infraestrutura, vamos falar sobre as features de agregação e a transição de um paradigma de sincronização em lote (batch) para atualizações em tempo real.

Features de agregação em uma janela de tempo — por exemplo, contagens, somas ou médias — são sinais poderosos e flexíveis para ML em tempo real. Uma feature em lote de longo prazo define uma baseline histórica para o usuário ao longo de um período, permitindo que o modelo se adapte e compreenda o comportamento de cada usuário. Uma feature recente e de curto prazo reage rapidamente a mudanças de cenário para distinguir um novo interesse do usuário ou uma atividade fraudulenta. As janelas de tempo definem um intervalo de tempo (por exemplo, 10 minutos), bem como a forma como esses intervalos devem evoluir ao longo do tempo (por exemplo, com sobreposição ou disjuntos).

O Databricks Feature Store suporta 3 janelas de tempo diferentes:

• As janelas de salto (tumbling windows) são alinhadas a intervalos de tempo fixos e começam assim que o último intervalo termina. Uma janela de salto de 10 minutos pode cobrir de 12:00 a 12:10 e, depois, de 12:10 a 12:20. Os eventos são agrupados em lotes nesses intervalos fixos, com o valor da feature sendo emitido ao final de um intervalo. Isso significa que a agregação só é atualizada nos limites do intervalo
• As janelas deslizantes (sliding windows) também são alinhadas a intervalos de tempo fixos, mas permitem a sobreposição de intervalos. Uma janela deslizante de 10 minutos com um intervalo de deslizamento de 5 minutos pode cobrir de 12:00 a 12:10, depois de 12:05 a 12:15 e, em seguida, de 12:10 a 12:20.
• As janelas contínuas (rolling windows) não são alinhadas a intervalos fixos, mas olham para trás a partir do timestamp de cada evento com resolução de milissegundos. "A soma das transações nos últimos 10 minutos em relação ao horário atual" está sempre atualizada, pois a janela se move a cada novo evento. Isso torna o RollingWindow a escolha natural para atendimento em tempo real, onde o "agora" está sempre mudando.

As janelas de salto e deslizantes continuam sendo úteis quando uma feature não muda com frequência: elas emitem menos atualizações, têm menor custo de manutenção e se encaixam naturalmente em pipelines programados mais simples. As janelas contínuas trocam essa eficiência pelo máximo de atualização dos dados, o que é extremamente valioso para sinais em que cada novo evento deve afetar imediatamente o valor fornecido ao modelo.

Veja como é simples definir uma feature de janela contínua com a API declarativa do Feature Store:

Spark Real-Time Mode: o mecanismo para computação de features

Passando para a infraestrutura subjacente, o pipeline de streaming é o que torna possível obter features atualizadas com alto rendimento (throughput). Esse pipeline leva os dados desde o Kafka até o feature store online. O pipeline de streaming é alimentado pelo Spark Real-Time Mode (RTM), um modo de execução fundamentalmente novo para o Spark Structured Streaming. O RTM é a principal inovação arquitetônica que viabiliza a atualização em milissegundos.

Estágios concorrentes e processamento com estado (stateful)

No modo tradicional de micro-lote (MBM), o Spark processa dados de streaming em lotes discretos. Cada lote coleta eventos ao longo de um intervalo configurável, processa-os sequencialmente em cada estágio, cria pontos de controle (checkpoints) e, em seguida, inicia o próximo lote. Isso cria um limite mínimo para a latência: mesmo com ajustes agressivos, os pipelines MBM para agregações com estado geralmente operam na ordem de segundos a minutos. O RTM, por outro lado, executa os estágios de forma concorrente. Os operadores de agregação processam as linhas imediatamente assim que ficam disponíveis, sem esperar que o estágio anterior termine de processar todas as linhas.

Para agregações contínuas, existem dois estágios importantes. O primeiro estágio é o processamento de dados, validação de esquema, coalescência de dados e conversão de tipos (type casting). Isso executa a lógica de negócios que converte eventos de ação genéricos no formato ideal para a sua agregação de features. O segundo estágio é a agregação de dados por entidade para calcular as agregações de janela contínua. Cada linha recebida atualiza imediatamente a agregação em um repositório de estado local do RocksDB e emite o novo valor para as etapas seguintes (downstream). A expiração da janela também acontece por linha: quando a duração da janela expira para um determinado evento, o pipeline remove a contribuição desse evento e envia a agregação corrigida para o Lakebase. O RocksDB é executado localmente em cada executor, permitindo tamanhos de estado que excedem a capacidade de memória do cluster.

Gerenciamento de estado de pipeline no RTM sem servidor (serverless)

O checkpointing é essencial para a tolerância a falhas no streaming com estado, pois permite que o pipeline se recupere caso ocorra falha em algum worker do pipeline. Mas o checkpointing tem seu custo. No modo de micro-lote, o Spark cria checkpoints em cada limite de lote, e cada checkpoint adiciona latência ao pipeline porque interage com repositórios de objetos na nuvem.

O RTM adota uma abordagem diferente: o custo de planejamento e checkpointing é amortizado em intervalos mais longos. O custo de checkpointing é distribuído por todas as linhas processadas nesse intervalo, em vez de bloquear o pipeline em cada limite de lote. Isso não sacrifica a tolerância a falhas. As garantias de processamento exactly-once são mantidas — em caso de falha, o pipeline reprocessa no máximo 5 minutos de dados da origem Kafka. A compensação é um aumento modesto no volume de reprocessamento para uma redução significativa na latência de processamento em estado estável.

O Feature Store executa pipelines RTM serverless no Lakeflow Spark Delta Pipelines (SDP), eliminando completamente o gerenciamento de clusters e o planejamento de capacidade. Você não precisa provisionar máquinas, ajustar a contagem de executores ou se preocupar com a manutenção do cluster. Quando as atualizações de infraestrutura exigem a reinicialização do pipeline, o SDP coordena a transição: o novo cluster serverless é provisionado e fica totalmente pronto antes que o antigo seja interrompido. Essa coordenação é sincronizada nos intervalos de checkpointing de 5 minutos, minimizando o tempo de inatividade e evitando lacunas de reprocessamento. Isso resulta em quase zero interrupção na atualização dos recursos durante as janelas de manutenção.

Lakebase: minimizando a sobrecarga para gravações de streaming

O Databricks Feature Store usa o Lakebase para armazenar os valores de recursos online para inferência. A arquitetura do Lakebase de separação de computação e armazenamento permite o escalonamento automático (autoscaling) para lidar com cargas variáveis na inferência de modelos. O Online Feature Store aproveita essa capacidade para escalar para dezenas de milhares de leituras por segundo com latência de dezenas de milissegundos.

As gravações de streaming são particularmente desafiadoras, pois consistem em um grande número de pequenos upserts à medida que novos valores de janela deslizante são emitidos para cada linha do Kafka recebida. No Postgres padrão, esse padrão pode gerar um grande volume de log de gravação antecipada (write-ahead log), pois o Postgres usa gravações de página inteira para facilitar a recuperação. Após cada checkpoint, la primeira modificação em uma página grava a imagem completa da página de 8 KB no write-ahead-log (WAL), e não apenas a pequena alteração lógica. Para linhas de entidades muito acessadas (hot) que são atualizadas com frequência, isso faz com que a amplificação de WAL seja o gargalo para a taxa de transferência de gravação, replicação e sobrecarga de recuperação.

O Lakebase agora aproveita a separação de computação e armazenamento distribuído para minimizar a amplificação de gravação de streaming em comparação com o Postgres padrão. A arquitetura do Lakebase permite que o Postgres grave registros de alteração pequenos e compactos, em vez de gravar repetidamente snapshots de página inteira de 8 KB no WAL. A durabilidade ainda é protegida porque esses registros compactos são confirmados por um quórum de nós safekeeper distribuídos. Snapshots de página inteira ainda são necessários para a recuperação após um número suficiente de registros de alteração, mas eles são gerados posteriormente na camada de armazenamento, em vez de sobrecarregar o caminho de gravação. Para o Feature Store, o resultado é que o RTM pode publicar continuamente novos valores de recursos no Lakebase com muito menos amplificação de WAL e latência adicional mínima.

Model Serving: recuperação de recursos de baixa latência em escala

A etapa final da jornada é recuperar recursos atualizados do Lakebase e entregá-los ao modelo no momento da inferência. Isso é gerenciado pelo Databricks Model Serving, uma infraestrutura de serviço totalmente gerenciada e otimizada para cargas de trabalho de alto QPS e baixa latência.

O Model Serving foi desenvolvido para as demandas de taxa de transferência de ML em tempo real:

• Arquitetura totalmente escalável horizontalmente: o servidor de inferência, a camada de autenticação, o proxy e o limitador de taxa (rate limiter) escalam de forma independente, suportando mais de 100 mil QPS em endpoints de CPU
• Escalonamento elástico rápido: o sistema se adapta a picos e quedas de tráfego sem provisionamento excessivo, mantendo os custos alinhados com a demanda real
• Governança e monitoramento de modelos: gerencie o acesso à rede, controle as permissões para endpoints de modelo e monitore a qualidade usando o AI Gateway.

Para o Feature Store, a integração é perfeita. Quando um modelo é registrado com o MLflow, suas dependências de recursos são gravadas. No momento da inferência, o Model Serving busca automaticamente os recursos necessários no Lakebase — sem código de busca personalizado, sem integrações manuais complexas. O agregado recente computado pelo RTM e armazenado no Lakebase é recuperado e combinado com a solicitação de inferência de forma transparente.

Feature Store além do streaming

Recursos em tempo real de alto desempenho são apenas parte do que um Feature Store pode resolver. Vale a pena considerar brevemente outros dois desafios:

Dados de treinamento para recursos de streaming

A geração de dados de treinamento pode ser difícil para recursos de streaming, pois as janelas curtas de retenção nos streams exigem a manutenção de um armazenamento offline separado. O Databricks Feature Store resolve isso armazenando uma cópia offline dos dados ingeridos do Kafka. Para o treinamento de modelos, o Feature Store calcula os mesmos valores de recursos que os pipelines de streaming calculariam para valores históricos e realiza junções precisas no ponto no tempo (point-in-time). Essa mesma capacidade é usada para preencher retroativamente (backfill) recursos de streaming online para permitir um lançamento rápido em produção.

Integrações

Como mostrado acima, os Feature Stores orquestram vários componentes de infraestrutura complexos. Essa fragmentação pode dificultar a governança, a linhagem (lineage) e a reutilização de recursos. Também retarda o desenvolvimento, pois os engenheiros precisam coordenar alterações entre as fronteiras do sistema.

No Databricks, os recursos (features) são objetos de primeira classe no Unity Catalog — fáceis de descobrir, controlados com controles de acesso e rastreados com linhagem completa. As transformações de recursos são empacotadas com o modelo, o MLflow captura quais recursos foram usados e a linhagem de implantação conecta os modelos às suas dependências de recursos. A plataforma é uma solução completa (one-stop shop) para desenvolver, implantar e governar toda a sua pilha de ML.

O Feature Store do Databricks orquestra blocos de construção essenciais como o Spark RTM, o Lakebase e o Model Serving para que você obtenha a melhor latência e escala da categoria sem precisar gerenciar a infraestrutura por conta própria. Cada um desses sistemas foi otimizado detalhadamente para cargas de trabalho de streaming para tornar a atualização de 200 ms uma realidade para os recursos de machine learning.

Consulte a documentação de Pipeline de Streaming para saber como definir recursos de streaming. Experimente com os recursos existentes para ver quão mais forte seria o sinal que eles forneceriam com atualização em nível de milissegundos.

Se você deseja entender melhor a tecnologia subjacente, consulte o blog do Lakebase sobre gravações mais rápidas e a análise da arquitetura RTM.

Se você quer trabalhar na resolução desse tipo de problema, estamos contratando!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original