O problema com a escrita de registros completos
Quem trabalha com o Amazon SageMaker Feature Store já conhece bem o conceito de Feature Group: uma coleção lógica de features relacionadas, usadas por modelos de Aprendizado de Máquina (ML) tanto para treinamento quanto para geração de inferências. Até agora, atualizar qualquer valor dentro de um Feature Group — mesmo que fosse apenas um único campo — exigia um ciclo completo de leitura-modificação-escrita usando a API PutRecord.
Na prática, se um pipeline de detecção de fraudes precisasse atualizar o risk_score de um cliente, a aplicação precisava:
- Ler o registro completo (com todas as features) via GetRecord;
- Mesclar o novo valor no código da aplicação;
- Reescrever o registro inteiro de volta com PutRecord.
Esse padrão introduzia latência extra em cada atualização, consumia capacidade de leitura desnecessária e criava condições de corrida quando múltiplos pipelines atualizavam features diferentes do mesmo registro ao mesmo tempo. No pior cenário, a escrita de um pipeline podia silenciosamente sobrescrever a de outro — o clássico problema de “lost update” (atualização perdida).
Além dos problemas de latência e consistência, esse padrão também gerava custo adicional. As chamadas extras de GetRecord antes de cada escrita acumulavam cobranças de Unidades de Capacidade de Leitura (RCUs). Para quem opera em escala, com Feature Groups amplos e alta frequência de atualizações, esses valores crescem rapidamente.
Apresentando a API UpdateRecord
A AWS anunciou a API UpdateRecord, que elimina completamente o ciclo de leitura-modificação-escrita. Com ela, a aplicação informa apenas as features que deseja alterar, e o SageMaker Feature Store aplica as atualizações de forma atômica ao registro existente. As features não incluídas na requisição são preservadas exatamente como estão.
O diagrama abaixo ilustra como o fluxo de dados funciona com a nova API:
A aplicação cliente chama o UpdateRecord enviando apenas as features alteradas. O serviço do Feature Store valida as permissões do Gerenciamento de Identidade e Acesso (IAM), verifica a ordenação por EventTime para rejeitar escritas desatualizadas e realiza a mesclagem atômica. Apenas as features modificadas são gravadas no online store, enquanto um snapshot completo do registro é replicado automaticamente para o offline store, mantendo os datasets de treinamento precisos. Múltiplos pipelines — como clickstream, compras e scoring — podem escrever suas próprias features de forma independente no mesmo registro, sem necessidade de coordenação.
Formato da requisição
A estrutura da chamada à API segue o formato abaixo:
POST /FeatureGroup/{FeatureGroupName}/Record
{
"RecordIdentifierValueAsString": "user_123",
"Features": [
{ "FeatureName": "risk_score", "ValueAsString": "0.87" },
{ "FeatureName": "last_login", "ValueAsString": "2026-07-21T08:15:00Z" }
],
"TtlDuration": { // optional
"Unit": "Days",
"Value": 30
}
}Pontos importantes sobre os parâmetros:
- FeatureGroupName — o Feature Group de destino.
- RecordIdentifierValueAsString — a chave primária do registro a ser atualizado. O registro já deve existir (
UpdateRecordnão é um upsert). - Features — lista com uma ou mais features a serem definidas. Até 100 features por chamada.
- TtlDuration (opcional) — define ou sobrescreve o tempo de vida (TTL) por registro. Se informado, o
EventTimetambém deve estar presente.
Para atualizar o EventTime armazenado com o registro, basta incluí-lo na lista de features. Para que a atualização seja persistida, esse EventTime precisa ser mais recente do que o valor já armazenado — caso contrário, toda a chamada é rejeitada com um erro HTTP 409. Mais detalhes sobre erros estão disponíveis em esta documentação.
Novo formato de armazenamento: Standard_V2
O armazenamento online do SageMaker Feature Store sempre ofereceu dois tiers: o Standard, baseado no Amazon DynamoDB, e o In-Memory, baseado no Amazon ElastiCache (Redis OSS). Com esse anúncio, a AWS introduz um novo formato de armazenamento para o tier Standard chamado Standard_V2, que utiliza uma serialização diferente e habilita as escritas por feature individual.
Importante: quem usa o tier In-Memory não precisa fazer nada — as escritas por feature já funcionam em todos os Feature Groups In-Memory existentes. Já para o tier Standard, é necessário adotar o novo formato Standard_V2.
Para criar um Feature Group com o novo formato, basta especificar o StorageType na criação:
import boto3
sm = boto3.client("sagemaker")
sm.create_feature_group(
FeatureGroupName="user-profile-fg",
RecordIdentifierFeatureName="user_id",
EventTimeFeatureName="event_time",
OnlineStoreConfig={
"EnableOnlineStore": True,
"StorageType": "Standard_V2" # enables feature-level writes
},
FeatureDefinitions=[
{"FeatureName": "user_id", "FeatureType": "String"},
{"FeatureName": "event_time", "FeatureType": "String"},
{"FeatureName": "risk_score", "FeatureType": "Fractional"},
{"FeatureName": "last_login", "FeatureType": "String"},
{"FeatureName": "balance", "FeatureType": "Fractional"},
],
)Migrando Feature Groups existentes para Standard_V2
Para quem já possui Feature Groups no formato Standard original, a AWS disponibiliza duas estratégias de migração para o Standard_V2.
Estratégia A: Migração em bloco com o Feature Processor SDK
Utiliza o Feature Processor SDK para ler os registros do Feature Group existente e reingestá-los em um novo Feature Group Standard_V2.
- Vantagens: controle total sobre o timing; o Feature Group original permanece intacto durante a migração; rollback é simples, basta apontar de volta para o grupo antigo.
- Desvantagens: exige um job de migração gerenciado; você paga o custo completo de leitura e escrita de todo o dataset de uma vez; é necessário atualizar os clientes da aplicação para apontar para o novo nome do Feature Group.
Estratégia B: Troca controlada in-place com a API UpdateFeatureGroup
Basta chamar UpdateFeatureGroup com OnlineStoreConfig.StorageType = "Standard_V2" para alterar o formato do Feature Group sem criar um novo:
import boto3
sm = boto3.client("sagemaker")
sm.update_feature_group(
FeatureGroupName="my-existing-fg",
OnlineStoreConfig={"StorageType": "Standard_V2"}
)Após a declaração, as chamadas a PutRecord ou BatchWriteRecord já atualizam o formato subjacente para Standard_V2. Essa abordagem tem zero downtime e cobra o custo de migração apenas para os registros efetivamente tocados, além de preservar o código de aplicação existente, pois o nome do Feature Group e os endpoints da API permanecem os mesmos. O ponto de atenção é que a troca para Standard_V2 é irreversível, e registros “frios” que nunca forem escritos continuarão no formato legado até serem tocados.
Recomendação da AWS: para a maioria dos casos, a Estratégia B é a preferida, por causa do zero downtime e da economia de pagar apenas pelo que é tocado. A Estratégia A deve ser usada apenas quando for necessário um caminho de rollback completo ou quando houver necessidade de renomear ou reestruturar o Feature Group.
Ordenação temporal com EventTime
O UpdateRecord suporta a mesma ordenação baseada em EventTime que o PutRecord. Quando um EventTime é incluído na requisição:
- Se o
EventTimefornecido for mais recente ou igual ao atual do registro, a atualização é aplicada e oEventTimedo registro avança. - Se o
EventTimefornecido for anterior ao atual, a atualização é rejeitada com um erro 409 ConflictException.
Quando o EventTime é omitido, as novas features são aplicadas e o EventTime existente no registro permanece inalterado — ideal para arquiteturas multi-pipeline onde diferentes pipelines gerenciam features distintas e não compartilham um único relógio de evento.
Casos de uso
Hidratação de features em streaming
Cenários em tempo real geralmente envolvem dados gerados por múltiplos fluxos em frequências diferentes. Por exemplo: um pipeline de clickstream recebe page_views e session_duration a cada poucos segundos, enquanto um pipeline batch noturno atualiza lifetime_value e customer_segment. Com o UpdateRecord, cada pipeline envia apenas as features que gerencia, sem coordenação e sem risco de perda de atualizações.
Backfill de novas features
Quando a equipe adiciona novas features a um Feature Group existente — como preferred_language e notification_opt_in — basta chamar UpdateRecord com apenas os novos valores. Os valores de features existentes permanecem intocados.
Correção de erros em escala
Se um job de qualidade de dados descobrir que customer_segment está categorizado incorretamente em 50.000 registros, o UpdateRecord permite corrigir esse único campo em todos os registros sem risco de corromper outros valores de features.
Atualizações de features em alta velocidade
Em sistemas de detecção de fraudes que recebem transaction_velocity a cada transação de cartão, o UpdateRecord permite que cada escrita toque apenas a feature que mudou, eliminando o overhead de escritas de registro completo em escala.
Feature Groups multi-produtor para entidades corporativas
Grandes organizações costumam modelar seu Feature Store em torno de entidades de negócio centrais — um Feature Group por tipo de entidade — com dezenas de produtores independentes contribuindo features para os mesmos registros. Sem o UpdateRecord, cada produtor precisava ler o registro completo, injetar seu subconjunto e reescrever a entidade inteira, criando jobs de compactação, condições de corrida e custos mensais elevados em operações de leitura e escrita. Com o UpdateRecord, cada produtor escreve apenas suas próprias features de forma atômica, eliminando a necessidade de soluções customizadas de compactação.
Controle de acesso granular com IAM
O UpdateRecord se integra ao IAM, permitindo controlar exatamente quem pode atualizar quais features. Duas novas chaves de condição IAM foram disponibilizadas:
- sagemaker:IsUpdateRecord (Bool) — distingue operações de atualização parcial das escritas completas via
PutRecord. - sagemaker:UpdatableFeatures (ArrayOfString) — restringe quais nomes de features um principal pode atualizar.
Exemplo de política que permite atualizações apenas em features não sensíveis:
{
"Effect": "Allow",
"Action": "sagemaker:PutRecord",
"Resource": "arn:aws:sagemaker:*:*:feature-group/user-profile-fg",
"Condition": {
"Bool": {
"sagemaker:IsUpdateRecord": "true"
},
"ForAllValues:StringEquals": {
"sagemaker:UpdatableFeatures": ["age", "score", "last_activity"]
}
}
}Essa política permite ao principal chamar UpdateRecord apenas nas features age, score e last_activity, bloqueando atualizações em qualquer outra feature (como ssn ou salary) e bloqueando chamadas diretas ao PutRecord.
Um ponto importante sobre compatibilidade retroativa: políticas IAM existentes que negam sagemaker:PutRecord automaticamente bloqueiam o UpdateRecord também. Nenhuma migração de controles de segurança é necessária.
Integração com o offline store e considerações de preço
As atualizações feitas pelo UpdateRecord fluem para o offline store automaticamente pelo mesmo pipeline de replicação usado pelo PutRecord. Cada atualização emite um snapshot completo do registro para o offline store, mantendo os datasets de treinamento e análises históricas precisos.
Algumas restrições importantes a ter em mente:
- O registro deve existir previamente — o
UpdateRecordé estritamente uma operação de modificação. Use oPutRecordprimeiro para criar o registro. - Os nomes de features precisam estar definidos no schema do Feature Group — não é possível adicionar features que não existam.
- O identificador do registro é imutável — a chave primária não pode ser modificada via
UpdateRecord. - O TTL exige EventTime — se
TtlDurationfor especificado, oEventTimetambém deve estar presente na requisição.
Em relação ao preço, o UpdateRecord segue o mesmo modelo de precificação do PutRecord. Para o tier Standard, as cobranças de Unidades de Capacidade de Escrita (WCU) do DynamoDB são baseadas no tamanho do item após a atualização. A economia vem da eliminação das leituras que antes eram necessárias no ciclo de leitura-modificação-escrita. Mais detalhes estão disponíveis na página de preços do Amazon SageMaker Feature Store.
Como começar
As escritas por feature com o UpdateRecord já estão disponíveis em todas as regiões AWS onde o Amazon SageMaker Feature Store é oferecido. Para começar:
- Crie um Feature Group com
StorageType: Standard_V2(tier Standard) ou use qualquer Feature Group In-Memory existente. - Ingira registros usando o
PutRecordnormalmente. - Chame o
UpdateRecordpara atualizar features individuais sem reescrever o registro completo.
Para mais informações, consulte o Guia do Desenvolvedor do Amazon SageMaker Feature Store e a Referência da API UpdateRecord.
Conclusão
A API UpdateRecord representa uma evolução significativa na forma como equipes de ML gerenciam features em produção. Ao eliminar o ciclo de leitura-modificação-escrita, a AWS reduz latência, diminui custos de transferência de dados em atualizações de features individuais e minimiza o risco de perda de atualizações em arquiteturas multi-pipeline. Combinada com controles IAM granulares e replicação automática para o offline store, essa novidade simplifica a construção de workflows de engenharia de features mais eficientes e confiáveis — seja para atualizar um único risk score em tempo real ou para coordenar dezenas de produtores independentes escrevendo em Feature Groups compartilhados de nível corporativo.
Fonte
Amazon SageMaker Feature Store introduces UpdateRecord for feature-level writes (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-feature-store-introduces-updaterecord-for-feature-level-writes/)
Leave a Reply