{"id":38322,"date":"2026-10-14T11:36:17","date_gmt":"2026-10-14T14:36:17","guid":{"rendered":"https:\/\/building.nu.com\/?p=38322"},"modified":"2026-10-14T14:08:54","modified_gmt":"2026-10-14T17:08:54","slug":"feature-stores-em-ml-em-tempo-real-parte-3-exemplos-do-nubank","status":"publish","type":"post","link":"https:\/\/building.nu.com\/pt-br\/feature-stores-em-ml-em-tempo-real-parte-3-exemplos-do-nubank\/","title":{"rendered":"Feature stores em ML em tempo real, parte 3:\u00a0 Exemplos do Nubank"},"content":{"rendered":"\n

Escrito por: Felipe Almeida<\/a>, com contribui\u00e7\u00f5es de Luiz Felix<\/a>, V\u00edvian Miranda<\/a>, Lucas Nolasco<\/a> e Caroline Custodio<\/a>.<\/p>\n\n\n\n

Esta \u00e9 a parte 3 de uma s\u00e9rie de 3 partes sobre Feature Stores para ML em tempo real. Veja a<\/strong> parte 1<\/strong><\/a> e a<\/strong> parte 2<\/strong><\/a>.<\/strong><\/p>\n\n\n\n

Breve recapitula\u00e7\u00e3o e introdu\u00e7\u00e3o<\/strong><\/h2>\n\n\n\n

Na parte 1<\/a> desta s\u00e9rie, descrevemos o que s\u00e3o feature stores e por que elas fazem sentido quando uma organiza\u00e7\u00e3o orientada a dados atinge um certo n\u00edvel de maturidade, especialmente ao usar sistemas em tempo real habilitados por ML. Na parte 2<\/a>, listamos as li\u00e7\u00f5es que aprendemos ao aplicar conceitos de feature store a problemas reais no Nubank.<\/p>\n\n\n\n

Nas pr\u00f3ximas se\u00e7\u00f5es, vamos apresentar alguns padr\u00f5es arquiteturais concretos que implementamos. Alguns deles s\u00e3o o que poder\u00edamos chamar de uma feature store completa (com defini\u00e7\u00f5es de features comuns para os caminhos de treinamento e de serving, por exemplo), enquanto outros focam em resolver apenas um problema espec\u00edfico.<\/p>\n\n\n\n

Features pr\u00e9-computadas a partir de dados em batch, materializadas em uma camada de serving chave-valor<\/strong><\/h2>\n\n\n\n

Nesta variante, produzimos um dataset totalmente desnormalizado<\/strong> (com todas as features de cada entidade combinadas em uma \u00fanica linha) como parte dos nossos jobs noturnos de <\/em>ETL\/ELT e o disponibilizamos em uma \u201ccamada de serving\u201d (por exemplo, DynamoDB), indexado pelo ID, para ser usado em tempo de infer\u00eancia. Isso pode ser visto na Figura 1:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figura 1:<\/em><\/strong> Nesta estrat\u00e9gia, uma etapa extra \u00e9 adicionada aos jobs noturnos de ETL\/ELT: produzir um dataset, indexado pelo ID da entidade (por exemplo, ID do cliente, ID da conta), em que cada coluna \u00e9 o valor de uma feature para aquela entidade. Em seguida, esse snapshot \u00e9 enviado para um armazenamento chave-valor (KV) de baixa lat\u00eancia, como DynamoDB ou Redis. Em tempo de serving, o modelo de ML em tempo real vai  recuperar uma \u00fanica linha desse armazenamento, j\u00e1 que ele \u00e9 totalmente desnormalizado. Isso \u00e9 r\u00e1pido e f\u00e1cil.<\/em><\/p>\n\n\n\n

Esse costuma ser o primeiro \u201cpadr\u00e3o\u201d de feature store para o qual muitas empresas convergem, muitas vezes sem saber que se trata de uma feature store. Ele \u00e9 baseado na arquitetura lambda<\/em><\/a> (sem a speed layer).<\/p>\n\n\n\n

\u00c9 um caso de uso simples, mas bastante poderoso:<\/p>\n\n\n\n