Deep Dive: Arquitectura Híbrida de Feature Store para Búsqueda en Escala Hyperscaler

La construcción de sistemas de búsqueda y recomendación a escala de hyperscaler, especialmente aquellos que dependen de modelos de Machine Learning en tiempo real, presenta un desafío fundamental en la gestión y servicio de 'features' (características). Estos sistemas requieren la capacidad de acceder a decenas o cientos de características por cada elemento evaluado (documento, producto, etc.) con latencias de milisegundos, mientras se mantienen los datos frescos y se procesan volúmenes masivos de información histórica y en streaming. La complejidad se agrava en entornos híbridos que combinan infraestructura on-premise con servicios en la nube.

El problema central es cómo conciliar la necesidad de procesamiento batch de datos históricos con la ingesta y servicio de datos en tiempo real, manteniendo una alta disponibilidad y baja latencia para la inferencia del modelo. Esto implica diseñar una arquitectura que desacople la ingeniería de características de la infraestructura de servicio, permitiendo a los ingenieros de ML iterar rápidamente, mientras se optimiza el rendimiento y el costo. La solución propuesta por Dropbox Dash aborda esto mediante una Feature Store híbrida que integra componentes de código abierto con infraestructura interna, adaptándose a las restricciones específicas de un entorno distribuido y de alta escala.

Arquitectura del Sistema

La arquitectura de la Feature Store de Dropbox Dash se basa en un diseño híbrido que integra Feast como capa de orquestación y APIs de servicio, Apache Spark para la computación y procesamiento de características, y Dynovault (una solución interna compatible con DynamoDB) para el almacenamiento y servicio de características en línea de baja latencia. Este diseño busca optimizar cada componente para su rol específico, superando las limitaciones de las soluciones 'off-the-shelf' en un entorno de infraestructura dual (on-premise y cloud).

Feast proporciona la abstracción para la definición de características y la orquestación de pipelines, permitiendo a los ingenieros de ML enfocarse en las transformaciones PySpark. Sin embargo, la capa de servicio en línea de Feast, originalmente en Python, fue reemplazada por un servicio personalizado en Go. Esta reimplementación fue crucial para alcanzar los requisitos de concurrencia y latencia (sub-100ms) necesarios para la búsqueda en Dash, evitando los cuellos de botella del Global Interpreter Lock (GIL) de Python y el parsing JSON intensivo en CPU. El servicio Go utiliza goroutines y memoria compartida para lograr una concurrencia eficiente.

La ingesta de características se gestiona mediante un sistema de tres partes: ingesta batch para transformaciones complejas y de alto volumen (utilizando una arquitectura de medallón con detección de cambios para reducir el volumen de escrituras), ingesta streaming para señales de rápido movimiento (como actividad de colaboración), y escrituras directas para características ligeras o precomputadas. Dynovault, co-ubicado con las cargas de trabajo de inferencia en la infraestructura híbrida de Dropbox, garantiza latencias de ~20ms para las búsquedas de características, evitando la latencia de llamadas a la internet pública. La observabilidad se integra a través de monitoreo de fallos de jobs, seguimiento de frescura y visibilidad del linaje de datos.

Fundamentos Teóricos

El problema de la gestión de características en sistemas de Machine Learning a gran escala se relaciona con principios fundamentales de bases de datos distribuidas y sistemas de procesamiento de datos. La necesidad de baja latencia y alta disponibilidad para el servicio de características en línea, junto con la consistencia de los datos, evoca los desafíos abordados por el teorema CAP (Consistency, Availability, Partition tolerance) y el teorema PACELC (Latency, Consistency, Availability, Eventual consistency, Latency). La elección de Dynovault, un sistema compatible con DynamoDB, para el servicio en línea subraya la preferencia por la disponibilidad y la baja latencia sobre una consistencia fuerte en un entorno distribuido, un trade-off común en sistemas NoSQL de alto rendimiento.

La arquitectura de ingesta de datos, que combina procesamiento batch y streaming, refleja el patrón Lambda Architecture o Kappa Architecture, propuestos para manejar grandes volúmenes de datos con requisitos de procesamiento en tiempo real y batch. La Lambda Architecture, popularizada por Nathan Marz, busca equilibrar la latencia y la precisión, mientras que la Kappa Architecture simplifica el diseño al unificar el procesamiento batch y streaming en un solo pipeline basado en logs. La estrategia de detección de cambios para la ingesta batch, reduciendo el volumen de escrituras, es una aplicación práctica de optimizaciones de bases de datos y sistemas de almacenamiento, similar a las técnicas de Write-Ahead Logging (WAL) y estructuras de datos como LSM-trees (Log-Structured Merge-trees) que optimizan las escrituras y lecturas en sistemas de almacenamiento persistente.