Cómo acelerar la ingestión y descubrir registros en Amazon SageMaker Feature Store

Introducción

Amazon SageMaker Feature Store es un repositorio administrado pensado para almacenar, compartir y gestionar features usados en modelos de machine learning. Ofrece un online store de baja latencia para inferencia en tiempo real y un offline store para retención histórica y entrenamiento. Con la madurez de las plataformas ML han aparecido dos problemas operativos recurrentes: la baja eficiencia al escribir registros uno por uno y la imposibilidad de explorar registros en el almacenamiento In-Memory.

AWS anunció dos nuevas APIs para Feature Store que abordan estos puntos: BatchWriteRecord y ListRecords. En este artículo explicamos qué resuelven, cómo funcionan y qué consideraciones operativas deben tener en cuenta los equipos, especialmente en contextos de alto volumen como detección de fraude o telemetría en América Latina.

El problema de la ingestión registro a registro

Hasta ahora, la API PutRecord escribía un único registro en un feature group por llamada. Cada operación incluye una comprobación condicional basada en EventTime: si el EventTime entrante es más reciente, el registro se conserva como la versión “latest” del online store; si no, se escribe como versión histórica en el offline store (cuando está disponible). Este enfoque garantiza fuerte ordenamiento temporal pero falla en escala porque obliga a un patrón N×M (N registros por M feature groups), con gran sobrecarga de conexiones y latencia en la cola.

Un ejemplo ilustrativo del artículo de AWS: un pipeline de detección de fraude que ingiera 10,000 registros por segundo a través de cinco feature groups tendría que sostener 50,000 llamadas API por segundo solo para mantener las features actualizadas. Ese volumen impacta costos, latencia y complejidad operacional.

Además, los equipos que usan el storage tier In-Memory (Redis-backed) no tenían forma de enumerar o explorar qué registros existían en el online store. Si se perdían identificadores por un bug o fallo en la pipeline, esos registros eran irrecuperables: no existía offline store ni consultas con Amazon Athena ni API para descubrirlos.

BatchWriteRecord: agrupar escrituras para mayor throughput

BatchWriteRecord permite enviar hasta 25 entradas en una sola llamada, apuntando a uno o varios feature groups. Cada entrada se procesa de forma independiente, por lo que la API es de “éxito parcial”: un fallo en una entrada no invalida el resto de la petición. Esto reduce drásticamente la cantidad de conexiones y llamadas necesarias en pipelines de alto rendimiento.

Principales características y comportamientos:

• Hasta 25 registros por request, con soporte para múltiples feature groups.
• Semántica de éxito parcial: la respuesta incluye solo las entradas que fallaron o quedaron sin procesar.
• Mantiene las garantías de ordenamiento basadas en EventTime iguales a PutRecord: si el EventTime entrante es más nuevo, la entrada es la versión “latest”; si es más antigua, puede terminar en el offline store (cuando aplica).
• Permite controlar TTL por registro (TtlDuration) para gestionar caducidad en el online store.
• Errores por validación, autenticación o throttling se retornan con detalles; las UnprocessedEntries pueden reintentarse.

La práctica recomendada es reintentar únicamente los registros que aparezcan en Errors o UnprocessedEntries usando backoff exponencial.

ListRecords: visibilidad incluso en In-Memory

La API ListRecords permite enumerar identificadores de registros dentro de un feature group usando paginación. Funciona tanto con el storage tier Standard (respaldado por Amazon DynamoDB) como con In-Memory (respaldado por Redis).

Esto cierra una brecha importante: cuando se usan feature groups en In-Memory, ahora es posible explorar y recuperar identificadores que antes podían perderse por errores de pipeline. No sustituye a prácticas de respaldo o instrumentación, pero ofrece una herramienta valiosa para diagnóstico y recuperación operativa.

Estructura de la petición y respuesta (resumen)

Una petición típica a BatchWriteRecord contiene una lista de Entries; cada Entry indica el feature group objetivo, los pares FeatureName/Value, los TargetStores (OnlineStore y opcionalmente OfflineStore) y opcionalmente TtlDuration. La respuesta incluye dos listas relevantes: Errors (entradas que fallaron con motivo) y UnprocessedEntries (entradas no procesadas que pueden reintentarse).

Es importante validar y normalizar los valores (por ejemplo, EventTime en formato ISO) antes de agrupar registros para evitar errores por validación.

Ejemplo básico con Boto3

A continuación, un ejemplo mínimo para ilustrar la llamada desde Python con boto3. Adapten nombres de feature groups y campos a su esquema.

import boto3

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

response = featurestore_runtime.batch_write_record(
    Entries=[
        {
            "FeatureGroupName": "click-features",
            "Record": [
                {"FeatureName": "user_id", "ValueAsString": "user-123"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                {"FeatureName": "click_count", "ValueAsString": "42"}
            ],
            "TargetStores": ["OnlineStore", "OfflineStore"],
            "TtlDuration": {"Unit": "Days", "Value": 7}
        }
    ]
)

# Revisar response["Errors"] y response["UnprocessedEntries"] para reintentos

Para usar ListRecords la llamada es similar: requiere el nombre del feature group y ofrece paginación para recorrer identificadores.

Requisitos mínimos y permisos

Para ejecutar estas APIs necesita:

• Cuenta AWS y permisos para crear recursos de SageMaker.
• Un rol de ejecución con acceso a S3 y AWS Glue según su pipeline, y permisos para las APIs del data plane de Feature Store.
• Las acciones mínimas de IAM incluyen: sagemaker:BatchWriteRecord, sagemaker:PutRecord y sagemaker:ListRecords en los recursos de feature-group correspondientes.
• Bibliotecas: boto3 (versión reciente) o SageMaker Python SDK v3.8.0+.

Recomendaciones operativas y para equipos en América Latina

• Consolidar llamadas con BatchWriteRecord para reducir costos y latencia en pipelines que procesan grandes volúmenes (por ejemplo, telemetría móvil, antifraude o analítica en tiempo real).
• Manejar reintentos únicamente para las entradas fallidas y aplicar backoff exponencial para evitar mayores throttles.
• Si usan In-Memory, incorporen ListRecords en sus playbooks de recuperación y monitoreo para evitar pérdidas irreversibles de datos.
• Validen formato y consistencia de EventTime antes de enviar lotes: las garantías de ordenamiento dependen de esa marca temporal.
• Para equipos latinoamericanos con deployments multi-región, revisen la latencia entre productores de datos y la región de AWS elegida; agrupar escrituras puede mitigar impacto de latencias de red.

Conclusión

BatchWriteRecord y ListRecords reducen dos fricciones importantes en Feature Store: mejoran el throughput de ingestión y añaden visibilidad sobre registros en memoria. Para plataformas ML que requieren alta ingestión y disponibilidad, estas APIs hacen posible arquitecturas más eficientes y resilientes. Equipos en América Latina que manejan grandes volúmenes de eventos o necesitan recuperación operativa encontrarán en estas funciones herramientas prácticas para optimizar costos, latencia y resiliencia de sus pipelines.