{"id":38305,"date":"2026-10-14T11:36:17","date_gmt":"2026-10-14T14:36:17","guid":{"rendered":"https:\/\/building.nu.com\/?p=38305"},"modified":"2026-10-14T14:11:26","modified_gmt":"2026-10-14T17:11:26","slug":"feature-stores-en-ml-en-tiempo-real-parte-3-ejemplos-de-nubank","status":"publish","type":"post","link":"https:\/\/building.nu.com\/es\/feature-stores-en-ml-en-tiempo-real-parte-3-ejemplos-de-nubank\/","title":{"rendered":"Feature stores en ML en tiempo real, parte 3:\u00a0 Ejemplos de Nubank"},"content":{"rendered":"\n

Escrito por: Felipe Almeida<\/a>, con contribuciones de Luiz Felix<\/a>, V\u00edvian Miranda<\/a>, Lucas Nolasco<\/a> y Caroline Custodio<\/a>.<\/p>\n\n\n\n

Esta es la parte 3 de una serie de 3 partes sobre Feature Stores para ML en tiempo real. Consulta la<\/strong> parte 1<\/strong><\/a> y la<\/strong> parte 2<\/strong><\/a>.<\/strong><\/p>\n\n\n\n

Breve resumen e introducci\u00f3n<\/strong><\/h2>\n\n\n\n

En la parte 1<\/a> de esta serie describimos qu\u00e9 son las feature stores y por qu\u00e9 tienen sentido cuando una organizaci\u00f3n orientada a datos alcanza cierto nivel de madurez, especialmente al usar sistemas en tiempo real habilitados por ML. En la parte 2<\/a>, enumeramos las lecciones que aprendimos al aplicar conceptos de feature store a problemas reales en Nubank.<\/p>\n\n\n\n

En las siguientes secciones repasaremos algunos patrones arquitect\u00f3nicos concretos que hemos implementado. Algunos de ellos son lo que podr\u00edamos llamar una feature store completa (con definiciones de features comunes para los caminos de entrenamiento y de serving, por ejemplo), mientras que otros se enfocan en resolver solo un problema particular.<\/p>\n\n\n\n

Features precalculadas a partir de datos batch, materializadas en una capa de serving clave-valor<\/strong><\/h2>\n\n\n\n

En esta variante producimos un dataset totalmente desnormalizado<\/strong> (con todas las features de cada entidad combinadas en una sola fila) como parte de nuestros jobs nocturnos de <\/em>ETL\/ELT y lo ponemos a disposici\u00f3n en una \u201ccapa de serving\u201d (por ejemplo, DynamoDB), indexado por el ID, para usarlo en tiempo de inferencia. Esto se puede ver en la Figura 1:<\/p>\n\n\n\n

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

Figura 1:<\/em><\/strong> En esta estrategia se agrega un paso extra a los jobs nocturnos de ETL\/ELT: producir un dataset, indexado por el ID de la entidad (por ejemplo, ID de cliente, ID de cuenta), donde cada columna es el valor de una feature para esa entidad. Luego, ese snapshot se env\u00eda a un almac\u00e9n clave-valor (KV) de baja latencia como DynamoDB o Redis. En tiempo de serving, el modelo de ML en tiempo real  recuperar\u00e1 una sola fila de ese almac\u00e9n, ya que est\u00e1 totalmente desnormalizado. Esto es r\u00e1pido y f\u00e1cil.<\/em><\/p>\n\n\n\n

Este suele ser el primer \u201cpatr\u00f3n\u201d de feature store al que convergen muchas empresas, a menudo sin saber que se trata de una feature store. Se basa en la arquitectura lambda<\/em><\/a> (sin la speed layer).<\/p>\n\n\n\n

Es un caso de uso simple, pero bastante poderoso:<\/p>\n\n\n\n