El Feature Store de Databricks ahora ofrece una garantía de latencia end-to-end p99 de 200ms — medida desde que un evento bruto llega a Kafka hasta que una feature está disponible para la inferencia del modelo. Para sistemas de detección de fraude y personalización que previamente toleraban minutos a horas de retraso de features en jobs batch de Spark, esto representa un cambio estructural en lo que una plataforma de features administrada puede entregar.
La arquitectura funciona a través de cuatro saltos: los eventos llegan a Kafka; Spark Real-Time Mode (RTM) en Lakeflow Spark Delta Pipelines sin servidor los procesa continuamente; los agregados actualizados se vacían a Lakebase a través de un sumidero JDBC de streaming; los endpoints de Model Serving extraen features de Lakebase en tiempo de inferencia. La diferencia clave: RTM procesa filas conforme llegan en lugar de acumular microlotes, eliminando el piso de latencia de límite de batch que hacía imposible la actualización en sub-segundo en versiones anteriores.
La gestión de estado utiliza instancias RocksDB por nodo. Para una suma de transacciones en ventana deslizante de 10 minutos — una señal canónica de fraude — cada evento entrante accede al almacén RocksDB local, incrementa el total, aplica expiración de ventana y envía el valor actualizado a Lakebase. La lectura-incremento-escritura permanece en memoria; solo el valor de la feature atraviesa la red. El checkpointing se amortiza entre eventos en lugar de bloquear por fila, preservando el presupuesto de latencia.
Lakebase maneja el lado de escritura. Los pequeños upserts de agregaciones de streaming crean trampas de amplificación de escritura para almacenamiento tradicional. La separación compute-storage de Lakebase lo maneja: escrituras de alto rendimiento al ritmo de streaming sin presión de compactación que degrada las latencias de cola en formatos orientados por columnas.
Feature Store soporta tres semánticas de ventana. Las ventanas tumbling se alinean con intervalos de reloj de pared, emitiendo solo en límites — fresco a las 12:10, obsoleto hasta las 12:20. Las ventanas sliding se superponen: una ventana de 10 minutos con desplazamiento de 5 minutos reduce la obsolescencia a la mitad pero persiste el problema de límite. Las ventanas rolling miran hacia atrás desde la marca de tiempo de cada evento con resolución en milisegundos, actualizándose en cada evento. Los sistemas de fraude y personalización que necesitan el SLA de 200ms requieren ventanas rolling; las ventanas tumbling en este ritmo desperdiciarían la inversión en streaming.
Una definición de feature ahora alimenta tanto pipelines batch offline como pipelines streaming online. Anteriormente, los equipos de fraude mantenían jobs batch separados para líneas base y jobs de streaming personalizados para agregaciones, cada uno con su propia infraestructura. Feature Store enruta ambos a través de una definición y un framework — Spark RTM, Lakebase y Model Serving orquestados por debajo. Los deployments en producción probarán si esta abstracción se sostiene bajo evolución de esquema y backfills.
Para arquitectos evaluando plataformas en tiempo real, 200ms p99 ancla las conversaciones sobre SLA. El tradeoff: el estado RocksDB por nodo significa que la escalabilidad horizontal introduce overhead de coordinación cuando las ventanas abarcan múltiples particiones. Evalúe esto antes de comprometerse con agregaciones de ventana rolling en cardinalidad alta.