Amazon SageMaker Feature Store anuncia duas novas APIs para ingestão em lote e descoberta de registros
A Amazon apresentou duas novas interfaces de programação de aplicações para o Amazon SageMaker Feature Store, serviço totalmente gerenciado voltado ao armazenamento, compartilhamento e gerenciamento de recursos utilizados em modelos de aprendizado de máquina. As APIs denominadas BatchWriteRecord e ListRecords foram desenvolvidas para resolver dois gargalos operacionais enfrentados por equipes que utilizam pipelines de dados em larga escala, especialmente em aplicações que exigem inferência em tempo real.
O Amazon SageMaker Feature Store funciona como um repositório centralizado de recursos de machine learning, oferecendo baixa latência no atendimento online para inferência em tempo real, além de um repositório offline destinado à retenção histórica de dados usados em treinamento. A plataforma também suporta diferentes padrões de ingestão, tanto em streaming quanto em lote, atendendo a variados cenários de uso.
O primeiro problema identificado está relacionado ao desempenho na escrita de registros. O método tradicional, chamado PutRecord, grava um único registro por chamada em um grupo de recursos específico. Em pipelines de alto volume, esse modelo força um padrão de chamadas em proporção direta ao número de registros e de grupos de recursos envolvidos. A própria documentação da AWS cita o exemplo de um sistema de detecção de fraudes que ingere dez mil registros por segundo distribuídos em cinco grupos de recursos, totalizando cinquenta mil chamadas de API por segundo apenas para manter os dados atualizados. Esse volume gera sobrecarga de conexões, latência elevada e limitação de throughput, prejudicando o desempenho geral da operação.
Para resolver essa questão, a nova API BatchWriteRecord permite gravar até 25 registros em uma única chamada, distribuídos em um ou mais grupos de recursos simultaneamente. Cada registro é processado de forma independente, com semântica de sucesso parcial, ou seja, a falha de um registro individual não compromete a operação completa. O recurso preserva as garantias de ordenação baseadas em EventTime, que é o marcador temporal utilizado para definir a versão mais recente de um registro, mantendo a mesma lógica do método PutRecord. Caso o EventTime do registro recebido seja mais recente do que o existente, ele se torna a versão mais recente no repositório online. Caso contrário, o registro é gravado apenas como versão histórica no repositório offline. Registros que falharem por motivos de autenticação, validação ou limitação de serviço são retornados na resposta com detalhes do erro, permitindo que a aplicação tente novamente apenas os itens não processados.
A nova API também oferece suporte ao recurso de TTL (Time-to-Live), que define o tempo de vida dos registros antes de expirarem. O controle pode ser definido em três níveis de prioridade: no registro individual, na requisição completa ou no próprio grupo de recursos, sendo o nível mais específico sempre prevalente. Outro ponto destacado é a flexibilidade na escolha do destino de cada registro, que pode ser direcionado ao repositório online, ao offline ou a ambos, de forma independente.
O segundo problema abordado pela AWS envolve a descoberta e o gerenciamento de registros já armazenados. Até então, os métodos disponíveis, como PutRecord, GetRecord e DeleteRecord, exigiam que o usuário soubesse previamente o identificador exato de cada registro. Para o nível de armazenamento Standard, que utiliza o Amazon DynamoDB como base, era possível contornar a limitação consultando o repositório offline por meio do Amazon Athena, serviço de consultas em linguagem SQL. No entanto, essa abordagem exige configuração adicional, gera custos extras e não opera em tempo real.
A situação se torna mais crítica no nível In-Memory, que utiliza o Redis, banco de dados em memória, como base. Nesse caso, não há um repositório offline equivalente por padrão. Caso os identificadores de registros sejam perdidos em razão de falhas em pipelines ou erros de programação, os dados se tornam permanentemente irrecuperáveis. Não existia uma forma de listar, descobrir ou excluir esses registros, gerando o acúmulo de dados órfãos, desperdício de armazenamento e potenciais riscos em cenários que exigem conformidade com regulamentações de proteção de dados, como solicitações de exclusão por titulares.
Para preencher essa lacuna, a nova API ListRecords permite enumerar os identificadores de registros dentro de um grupo de recursos por meio de paginação. A ferramenta retorna apenas os registros ativos, que não foram excluídos nem expiraram, prontos para uso com os métodos GetRecord ou DeleteRecord. A API funciona de maneira idêntica tanto no nível Standard quanto no nível In-Memory, filtrando automaticamente registros com exclusão lógica, expirados por TTL ou chaves internas do sistema. O tamanho da página pode ser configurado, com limite máximo de cem identificadores por requisição, e a navegação entre páginas é feita por meio de tokens opacos fornecidos pela própria API.
Conforme destacado pelos autores da publicação, Harshil Shah, Dhaval Shah, Chirag Pandey e Siamak Nariman, profissionais da AWS, as duas APIs se complementam e viabilizam cenários antes considerados complexos ou inviáveis. Entre os exemplos citados estão pipelines de ingestão em massa com menor número de conexões e latência reduzida, fluxos de conformidade capazes de verificar a exclusão completa de dados de um usuário em múltiplos grupos de recursos e ferramentas operacionais que permitem navegar pelo conteúdo dos grupos de recursos em tempo real.
