Databricks Lakebase Elimina los Picos de Latencia 10× en ERGO Hestia

ERGO Hestia ha migrado su pila de precios de seguros de 100 modelos a Databricks Lakebase y Mosaic AI Model Serving Endpoints, resolviendo problemas con los picos de latencia de ventana de lotes y las restricciones de despliegue fuera de horas pico que anteriormente obstaculizaban la cobranza B2C en tiempo real. La plataforma del asegurador polaco, que depende de más de 1,000 variables para cotizaciones de nivel de milisegundos, antes canalizaba datos a través de una tubería Delta a Azure PostgreSQL, un adaptador de caché personalizado y finalmente a la aplicación del motor de precios.

Este proceso de varios pasos resultó en tres restricciones de producción: la gobernanza y la linaje estaban divididas entre Databricks y PostgreSQL, complicando la auditoría; las actualizaciones de modelos requerían ventanas de despliegue fuera de horas pico para evitar la desestabilización de la capa de adaptador externo; y las grandes ingestas de datos causaban picos de latencia de 10× a 20× en la capa de servicio externo, lo que requería actualizaciones de ventana de lotes y evitaba los ajustes de precios del mismo día.

La nueva arquitectura mantiene los datos y el servicio dentro del lakehouse. Lakebase ofrece una capa transaccional relacional sobre las tablas Delta, con Sync Tables sincronizando los datos procesados a la capa de servicio sin extracción manual. Mosaic AI Model Serving Endpoints exponen los resultados directamente al motor de precios a través de la API, eliminando la aplicación intermedia y la base de datos externa. Unity Catalog gestiona tanto la linaje de datos como de modelos, preservando los conjuntos de entrenamiento históricos y versiones de modelos para cumplir con los requisitos de auditoría de seguros polacos.

El estudio de caso carece de detalles operativos. Menciona un pico de latencia de 10×–20× como un problema heredado, pero no proporciona benchmarks p50 o p99 para la nueva pila, ni enumera tipos de instancias, horas de GPU o costos por inferencia. Afirma una mayor rapidez en el envío de modelos y una respuesta al mercado instantánea, pero no proporciona métricas de frecuencia de despliegue o reducciones de tiempo de liderazgo. Las únicas métricas de escala concretas proporcionadas son los más de 100 modelos y más de 1,000 variables; la latencia de nivel de milisegundos sigue siendo un objetivo, no una cifra verificada. Las afirmaciones de rendimiento y velocidad deben considerarse direccionales hasta que esté disponible una telemetría de producción independiente.

El esfuerzo de migración de Azure PostgreSQL y código de adaptador personalizado a Lakebase no se cuantifica en horas de ingeniería o tiempo de inactividad, y el riesgo de regresión de mover 100 modelos fuera de una capa de caché personalizada no se examina. Reemplazar una base de datos externa con Sync Tables y Model Serving Endpoints administrados por Databricks introduce nuevos límites de proveedor, y los modos de fallo de sincronización no se caracterizan. Para equipos fuera del ecosistema de Databricks, replicar este patrón requiere importar el modelo de gobernanza de Unity Catalog o construir un puente de auditoría equivalente, un costo de integración no abordado en el estudio de caso. La arquitectura se describe como posicionando al equipo para la cobranza B2C en tiempo real, pero no está claro si actualmente está en producción.

Lo que un arquitecto podría considerar adoptar: reemplazar cadenas de servicio de extracción-transformación-carga fragmentadas con una capa relacional administrada coubicada en el lakehouse y frente a endpoints de modelo directos, siempre que el límite de servicio del proveedor y el marco de cumplimiento se alineen con los primitivos de auditoría del catálogo.