Las Vistas de Características de Databricks unifican el entrenamiento y el servicio con una latencia de 200ms

Databricks ha lanzado Vistas de Características en vista pública, proporcionando una abstracción gestionada que consolida el cálculo histórico de características y el servicio en tiempo real bajo una única definición del Catálogo de Unidad, logrando una latencia de 200ms de p99 de extremo a extremo desde el evento de Kafka hasta la disponibilidad en línea.

La pila se basa en el SDK de Ingeniería de Características, que opera dentro del Databricks Runtime 14.2 ML. Un practicante puede definir una característica en un cuaderno, como un resumen de 10 minutos de valores de transacción, y esta definición genera automáticamente un conjunto de entrenamiento correcto en el momento y una tubería de producción. Este enfoque aborda el sesgo entrenamiento-servicio, un problema común en sistemas de ML de producción, almacenando la lógica de cálculo de características con los datos y aplicando la corrección temporal, evitando así la divergencia entre el código de entrenamiento por lotes y el código de servicio en tiempo real.

Las Vistas de Características, al registrarse en el Catálogo de Unidad, se convierten en objetos regulados con linaje y control de acceso. Una sola llamada a `materialize_features` aprovisiona la infraestructura necesaria de backend sin orquestración adicional. Databricks utiliza el Modo en Tiempo Real de Spark para actualizaciones acumulativas continuas por evento y Lakebase como la tienda en línea optimizada para streaming, diseñada para minimizar la amplificación de escritura durante las actualizaciones de alta frecuencia y pequeños. El Modo en Tiempo Real de Spark calcula ventanas deslizantes hacia atrás desde la marca de tiempo de cada evento con resolución de milisegundo, mientras que el Servicio de Modelos recupera características en tiempo de inferencia a través de puntos de conexión de escalado automático dentro del límite de red del cliente.

La latencia de p99 de 200ms de extremo a extremo cubre todo el proceso desde la ingesta de Kafka hasta la disponibilidad de la tienda en línea, lo cual es crucial para aplicaciones sensibles a la latencia como la detección de fraudes o la fijación de precios de viajes. El cliente pionero Skyscanner informa que la abstracción redujo el volumen de código de características, permitiendo a los científicos de datos centrarse en la modelación de valor para el viajero. La plataforma también admite la recuperación de datos estructurados para aplicaciones RAG, lo que indica la intención de Databricks de posicionar el almacén de características como infraestructura para pilas agenticas, más allá de la ML tabular tradicional.

Sin embargo, el estado de vista previa implica riesgos potenciales de despliegue, ya que los SLA, la tarifa por característica y el comportamiento de inicio en frío para los puntos de conexión de escalado automático aún no se han finalizado. La latencia de p99 de 200ms es un punto de referencia informado por la plataforma bajo condiciones gestionadas por Databricks y puede variar con la particionado de Kafka, la cardinalidad del evento y la complejidad de las agregaciones deslizantes. El modelo de servicio gestionado reduce la gestión de infraestructura pero limita las capacidades de observabilidad y ajuste en comparación con una pila de Flink a Redis autogestionada. La migración no es trivial, requiere que la lógica de características existente se reescriba en el SDK de Databricks, y los equipos se ven atados al ciclo de lanzamiento de Databricks para la infraestructura de inferencia crítica.

Los arquitectos deben considerar la adopción del contrato de API, que implica definir características de forma declarativa, aplicar automáticamente la corrección en el momento y enrutear la misma lógica tanto al entrenamiento por lotes como a la inferencia de flujo con una sola llamada a materialización.