La hoja de ruta de los datos de autoservicio

Capítulo 4. Servicio de Almacén de Características

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Hasta ahora, hemos descubierto los conjuntos de datos y artefactos disponibles que pueden utilizarse para generar la perspectiva necesaria. En el caso de los modelos ML, hay un paso adicional de descubrimiento de características. Por ejemplo, un modelo de previsión de ingresos que necesite ser entrenado necesitaría como entrada las cifras de ingresos anteriores por mercado, línea de producto, etc. Una característica es un atributo de datos que puede extraerse directamente o derivarse mediante cálculo de una o varias fuentes de datos: por ejemplo, la edad de una persona, una coordenada emitida por un sensor, una palabra de un fragmento de texto o un valor agregado como el número medio de compras en la última hora. Los valores históricos del atributo de datos son necesarios para utilizar una característica en modelos ML.

Los científicos de datos dedican una gran parte de su tiempo a crear conjuntos de datos de entrenamiento para los modelos de ML. Construir canalizaciones de datos para generar las características para el entrenamiento, así como para la inferencia, es un punto de dolor significativo. En primer lugar, los científicos de datos tienen que escribir código de bajo nivel para acceder a los almacenes de datos, lo que requiere conocimientos de ingeniería de datos. En segundo lugar, los conductos para generar estas características tienen múltiples implementaciones que no siempre son coherentes, es decir, hay conductos separados para el entrenamiento y la inferencia. En tercer lugar, el código de la canalización está duplicado en todos los proyectos de ML y no es reutilizable, ya que forma parte de la implementación del modelo. Por último, no hay gestión del cambio ni gobierno de las funciones. Estos aspectos repercuten en el tiempo total de comprensión. Esto es especialmente cierto porque los usuarios de datos suelen carecer de los conocimientos de ingeniería necesarios para desarrollar canalizaciones sólidas y monitorizarlas en producción. Además, las canalizaciones de características se construyen repetidamente desde cero, en lugar de compartirse entre proyectos de ML. El proceso de construcción de modelos ML es iterativo y requiere la exploración con diferentes combinaciones de características.

Idealmente, un servicio de almacenamiento de características debería proporcionar características bien documentadas, gobernadas, versionadas y curadas para el entrenamiento y la inferencia de modelos de ML (como se muestra en la Figura 4-1). Los usuarios de datos deben poder buscar y utilizar características para construir modelos con un mínimo de ingeniería de datos. Las implementaciones del canal de características para el entrenamiento y la inferencia son coherentes. Además, las características se almacenan en caché y se reutilizan en todos los proyectos de ML, reduciendo el tiempo de entrenamiento y los costes de la infraestructura . La métrica del éxito de este servicio es el tiempo para featurizar. A medida que el servicio de almacén de características se construye con más características, proporciona economías de escala al facilitar y agilizar la construcción de nuevos modelos.

Figura 4-1. El almacén de características como repositorio de características que se utilizan para el entrenamiento y la inferencia de modelos a través de múltiples proyectos de datos.

Mapa del viaje

Desarrollar y gestionar características es una pieza fundamental en el desarrollo de modelos de ML. A menudo, los proyectos de datos comparten un conjunto común de características, lo que permite reutilizarlas. Un aumento del número de características reduce el coste de implementación de nuevos proyectos de datos (como se muestra en la Figura 4-2). Existe un buen solapamiento de características entre proyectos. En esta sección se analizan los escenarios clave de la hoja de ruta para el servicio de almacén de características.

Figura 4-2. El tiempo y el esfuerzo necesarios para nuevos proyectos de datos disminuyen a medida que aumenta el número de características disponibles en el almacén de características.

Encontrar funciones disponibles

Como parte de la fase de exploración, los científicos de datos buscan características disponibles que puedan aprovecharse para construir el modelo ML. El objetivo de esta fase es reutilizar características y reducir el coste de para construir el modelo. El proceso implica analizar si las características disponibles son de buena calidad y cómo se utilizan actualmente. Debido a la falta de un repositorio centralizado de características, los científicos de datos a menudo se saltan la fase de búsqueda y desarrollan conductos de entrenamiento ad hoc que tienen tendencia a volverse complejos con el tiempo. A medida que aumenta el número de modelos, se convierte rápidamente en una jungla de tuberías difícil de gestionar.

Generación del conjunto de entrenamiento

Durante el entrenamiento del modelo, se necesitan conjuntos de datos formados por una o más características para entrenar el modelo. El conjunto de entrenamiento, que contiene los valores históricos de estas características, se genera junto con una etiqueta de predicción. El conjunto de entrenamiento se prepara escribiendo consultas que extraen los datos de las fuentes del conjunto de datos y transforman, limpian y generan valores de datos históricos de las características. Se dedica una cantidad significativa de tiempo a desarrollar el conjunto de entrenamiento. Además, el conjunto de características debe actualizarse continuamente con nuevos valores (un proceso denominado backfilling). Con un almacén de características, los conjuntos de datos de entrenamiento de las características están disponibles durante la construcción de los modelos.

Canal de características para la inferencia en línea

Para la inferencia del modelo, los valores de las características se proporcionan como entrada al modelo, que luego genera la salida predicha. La lógica de canalización para generar características durante la inferencia debe coincidir con la lógica utilizada durante el entrenamiento, de lo contrario las predicciones del modelo serán incorrectas. Además de la lógica de canalización, un requisito adicional es tener una baja latencia para generar la característica para la inferencia en los modelos en línea. Hoy en día, los conductos de características integrados en el conducto ML no son fácilmente reutilizables. Además, es posible que los cambios en la lógica de la tubería de entrenamiento no se coordinen correctamente con las correspondientes tuberías de inferencia del modelo.

Minimizar el tiempo para featurizar

El tiempo de featurización es el tiempo empleado en crear y gestionar características. En la actualidad, el tiempo empleado se divide en dos categorías: cálculo de características y servicio de características. El cómputo de características implica canalizaciones de datos para generar características tanto para el entrenamiento como para la inferencia. El servicio de características se centra en servir conjuntos de datos masivos durante el entrenamiento, valores de características de baja latencia para la inferencia de modelos, y facilitar a los usuarios de datos la búsqueda y colaboración entre características.

Cálculo de características

El cálculo de características es el proceso de convertir los datos brutos en características. Esto implica construir conductos de datos para generar valores históricos de entrenamiento de la característica, así como valores actuales de la característica utilizados para la inferencia del modelo. Los conjuntos de datos de entrenamiento deben rellenarse continuamente con muestras más recientes. Hay dos retos clave en el cálculo de características.

En primer lugar, está la complejidad de gestionar las junglas de tuberías. Los pipelines extraen los datos de los almacenes de datos de origen y los transforman en características. Estos pipelines tienen múltiples transformaciones y necesitan manejar los casos de esquina que surgen en producción. Gestionarlos a escala en producción es una pesadilla. Además, el número de muestras de datos de características sigue creciendo, especialmente para los modelos de aprendizaje profundo. Gestionar grandes conjuntos de datos a escala requiere optimizaciones de programación distribuida para el escalado y el rendimiento. En general, la creación y gestión de canalizaciones de datos suele ser una de las partes que más tiempo consumen del tiempo total necesario para comprender la creación de modelos.

En segundo lugar, se escriben conductos separados para el entrenamiento y la inferencia de una característica determinada. Esto se debe a que los requisitos de frescura son diferentes, ya que el entrenamiento del modelo suele estar orientado a lotes, mientras que la inferencia del modelo es un flujo con una latencia cercana al tiempo real. Las discrepancias en el cálculo de los conductos de entrenamiento e inferencia son una razón clave de los problemas de corrección de los modelos y una pesadilla para depurar a escala de producción.

Función Servir

El servicio de características implica servir valores de características en masa para el entrenamiento, así como a baja latencia para la inferencia. Requiere que las características sean fáciles de descubrir y comparar y analizar con otras características existentes. En una implementación típica a gran escala, el servicio de características admite miles de inferencias de modelos. Escalar el rendimiento es uno de los retos clave, como lo es evitar características duplicadas dada la rápida exploración de los usuarios de datos a través de cientos de permutaciones de modelos durante la creación de prototipos.

Hoy en día, uno de los problemas habituales es que el modelo funciona bien en el conjunto de datos de entrenamiento pero no en producción. Aunque esto puede deberse a múltiples razones, el problema clave se denomina fuga de etiquetas. Esto se debe a que las características del modelo tienen valores puntuales incorrectos. Encontrar los valores correctos de las características es complicado. Para ilustrarlo, Zanoyan et al. cubren un ejemplo ilustrado en la Figura 4-3. Muestra los valores de característica seleccionados en el entrenamiento para la predicción en el Tiempo T1. Se muestran tres características: F1, F2, F3. Para la predicción P1, hay que seleccionar los valores de característica 7, 3, 8 para las características de entrenamiento F1, F2, F3, respectivamente. En cambio, si se utilizan los valores de las características posteriores a la predicción (como el valor 4 para F1), habrá una fuga de características, ya que el valor representa el resultado potencial de la predicción, y representa incorrectamente una alta correlación durante el entrenamiento.

Figura 4-3. La selección de valores correctos en un momento dado para las características F1, F2, F3 durante el entrenamiento para la predicción P1. El resultado real Etiqueta L se proporciona para el entrenamiento del modelo ML supervisado.

Definir los requisitos

El servicio de almacén de características es un repositorio central de características, que proporciona tanto los valores históricos de las características a lo largo de periodos prolongados, como semanas o meses, como valores de características casi en tiempo real a lo largo de varios minutos. Los requisitos de un almacén de características se dividen en cálculo de características y servicio de características.

Cálculo de características

El cálculo de características requiere una profunda integración con el lago de datos y otras fuentes de datos. Hay tres dimensiones a tener en cuenta en las cadenas de cálculo de características.

En primer lugar, considera los diversos tipos de características que deben admitirse. Las características pueden estar asociadas a atributos de datos individuales o ser agregados compuestos. Además, las características pueden ser relativamente estáticas en lugar de cambiar continuamente en relación con el tiempo nominal. El cálculo de características suele requerir que el almacén de características admita varias funciones primitivas, similares a las funciones que utilizan actualmente los usuarios de datos, como:

• Convertir datos categóricos en numéricos

• Normalizar los datos cuando las características proceden de distribuciones diferentes

• Codificación en un solo paso o binarización de rasgos

• Binning de rasgos (por ejemplo, convertir rasgos continuos en rasgos discretos)

• Hashing de características (por ejemplo, para reducir la huella de memoria de las características codificadas en un solo paso )

• Cálculo de características agregadas (por ejemplo, recuento, mín., máx. y desviación estándar)

En segundo lugar, ten en cuenta las bibliotecas de programación que deben ser compatibles con la ingeniería de características. Spark es la opción preferida para la gestión de datos entre los usuarios que trabajan con conjuntos de datos a gran escala. Los usuarios que trabajan con conjuntos de datos pequeños prefieren marcos como NumPy y pandas. Los trabajos de ingeniería de rasgos se construyen utilizando cuadernos, archivos Python o archivos .jar y se ejecutan en marcos de computación como Samza, Spark, Flink y Beam.

En tercer lugar, considera los tipos de sistemas fuente en los que persisten los datos de características. Los sistemas fuente pueden ser una serie de bases de datos relacionales, almacenes de datos NoSQL, plataformas de streaming y almacenes de archivos y objetos.

Función Servir

Un almacén de características tiene que soportar una gran capacidad de colaboración. Las características deben definirse y generarse de forma que puedan compartirse entre equipos.

Grupos de características

Un almacén de características tiene dos interfaces: escribir características en el almacén y leer características para el entrenamiento y la inferencia. Las características suelen escribirse en un archivo o en una base de datos específica del proyecto. Las características pueden agruparse en función de las calculadas por el mismo trabajo de procesamiento o a partir del mismo conjunto de datos sin procesar. Por ejemplo, para un servicio de coche compartido como Uber, todas las características relacionadas con el viaje para una región geográfica pueden gestionarse como un grupo de características, ya que todas pueden ser calculadas por un trabajo que escanea el historial de viajes. Las características pueden unirse con etiquetas (en el caso del aprendizaje supervisado) y materializarse en un conjunto de datos de entrenamiento. Los grupos de características suelen compartir una columna común, como una marca de tiempo o un ID de cliente, que permite unir los grupos de características en un conjunto de datos de entrenamiento. El almacén de características crea y gestiona el conjunto de datos de entrenamiento, persistiendo como TFRecords, Parquet, CSV, TSV, HDF5 o archivos .npy.

Escalado

Hay algunos aspectos a tener en cuenta con respecto al escalado:

• El número de características que debe admitir el almacén de características

• El número de modelos que llaman al almacén de características para inferencias en línea

• El número de modelos para la inferencia diaria fuera de línea, así como para el entrenamiento

• La cantidad de datos históricos que deben incluirse en los conjuntos de datos de entrenamiento

• El número de pipelines diarios para rellenar los conjuntos de datos de características a medida que se generan nuevas muestras

Además, hay requisitos específicos de escalado de rendimiento asociados a la inferencia del modelo en línea, por ejemplo, el valor de latencia TP99 para calcular el valor de la característica. Para el entrenamiento en línea, hay que tener en cuenta el tiempo necesario para rellenar conjuntos de entrenamiento y tener en cuenta las mutaciones del esquema de la BD. Normalmente, las características históricas deben tener menos de 12 horas de antigüedad, y los valores de las características casi en tiempo real deben tener menos de 5 minutos.

Análisis de características

Las características deben poder buscarse y ser fácilmente comprensibles, para garantizar su reutilización en todos los proyectos de ML. Los usuarios de los datos deben poder identificar las transformaciones, así como analizar las características, encontrando valores atípicos, desviaciones de distribución y correlaciones de características.

Requisitos no funcionales

Al igual que en el diseño de cualquier software, los siguientes son algunos de los NFR clave que deben tenerse en cuenta en el diseño de un servicio de almacén de características:

Monitoreo y alerta automatizados

La salud del servicio debe ser fácil de monitorear. Cualquier problema durante la producción debe generar alertas automáticas.

Tiempos de respuesta

Es importante que el servicio responda a las consultas de búsqueda de funciones en el orden de milisegundos.

Interfaz intuitiva

Para que el servicio de almacén de características sea eficaz, debe ser adoptado por todos los usuarios de datos de la organización. Por ello, es fundamental disponer de API, CLI y un portal web que sean fáciles de usar y comprender.

Patrones de aplicación

En correspondencia con el mapa de tareas existente, hay dos niveles de automatización para el servicio de almacén de características (como se muestra en la Figura 4-4). Cada nivel corresponde a la automatización de una combinación de tareas que actualmente son manuales o ineficaces:

Patrón híbrido de cálculo de rasgos

Define el patrón para combinar el procesamiento por lotes y por flujos para calcular las características.

Patrón de registro de características

Define el patrón que servirá a las características para el entrenamiento y la inferencia.

Figura 4-4. Los distintos niveles de automatización del servicio de almacén de características.

Los servicios de tienda de características son cada vez más populares: Michelangelo de Uber, Zipline de Airbnb, Feast de Gojek, Applied AI de Comcast, Hopsworks de Logical Clock, Fact Store de Netflix y Galaxy de Pinterest son algunos de los ejemplos populares de código abierto de un servicio de feature store. En featurestore.org hay una buena lista de tiendas de características emergentes. Desde el punto de vista de la arquitectura, cada una de estas implementaciones tiene dos componentes clave: el cálculo y el servicio de características.

Patrón híbrido de cálculo de características

El módulo de cálculo de rasgos tiene que soportar dos conjuntos de escenarios ML:

• Entrenamiento e inferencia fuera de línea, donde los datos históricos masivos se calculan con una frecuencia de horas

• Entrenamiento e inferencia en línea, donde los valores de las características se calculan cada pocos minutos

En el patrón de cálculo de rasgos híbridos, hay tres bloques de construcción (como se muestra en la Figura 4-5):

Canal de cálculo por lotes

El procesamiento por lotes tradicional se ejecuta como un trabajo ETL cada pocas horas, o diariamente, para calcular los valores históricos de las características. La tubería está optimizada para ejecutarse en grandes ventanas de tiempo .

Canalización de cálculo en streaming

Los análisis de flujo se realizan sobre eventos de datos en un bus de mensajes en tiempo real para calcular los valores de las características con baja latencia. Los valores de las características se rellenan en los datos históricos a granel del canal por lotes.

Especificaciones

Para garantizar la coherencia, en lugar de que los usuarios de datos creen canalizaciones para nuevas funciones, definen una especificación de función utilizando un lenguaje específico del dominio (DSL). La especificación especifica las fuentes de datos y las dependencias, así como la transformación necesaria para generar la función. La especificación se convierte automáticamente en pipelines por lotes y en streaming. Esto garantiza la coherencia en el código de la canalización, tanto para el entrenamiento como para la inferencia, sin intervención del usuario.

Figura 4-5. Canalizaciones paralelas en el patrón híbrido de cálculo de características.

Un ejemplo del patrón híbrido de cálculo de características es Michelangelo de Uber. Implementa una combinación de Apache Spark y Samza. Spark se utiliza para calcular características por lotes y los resultados se almacenan en Hive. Los trabajos por lotes calculan grupos de características y escriben en una única tabla Hive como una característica por columna. Por ejemplo, Uber Eats (el servicio de reparto de comida de Uber) utiliza la canalización por lotes para características como el tiempo medio de preparación de la comida de un restaurante en los últimos siete días. Para el canal de flujo, los temas de Kafka se consumen con trabajos de flujo de Samza para generar valores de características casi en tiempo real que se guardan en formato clave-valor en Cassandra. La precomputación y carga masiva de características históricas se realiza desde Hive a Cassandra de forma regular. Por ejemplo, Uber Eats utiliza el canal de streaming para características como el tiempo medio de preparación de la comida de un restaurante en la última hora. Las características se definen mediante un DSL que selecciona, transforma y combina las características que se envían al modelo en los momentos de entrenamiento y predicción. El DSL se implementa como un subconjunto de Scala, que es un lenguaje funcional puro con un conjunto completo de funciones de uso común. Los usuarios de datos también tienen la posibilidad de añadir sus propias funciones definidas por el usuario .

Puntos fuertes del patrón híbrido de cálculo de rasgos:

• Proporciona un rendimiento óptimo del cómputo de características en ventanas de tiempo por lotes y de flujo.

• El DSL para definir rasgos evita las incoherencias asociadas a las discrepancias en la implementación de tuberías para el entrenamiento y la inferencia.

Debilidad del patrón híbrido de cálculo de rasgos:

• El patrón no es trivial de implementar y gestionar en producción. Requiere que la plataforma de datos esté bastante madura.

El patrón híbrido de cálculo de características es un enfoque avanzado para implementar el cálculo de características que está optimizado tanto para el procesamiento por lotes como para el streaming. Los modelos de programación como Apache Beam están haciendo converger cada vez más la división entre batch y streaming.

Patrón de registro de características

El patrón de registro de características garantiza que sea fácil descubrir y gestionar características. También es eficaz a la hora de servir los valores de las características para el entrenamiento y la inferencia online/offline. Los requisitos para estos casos de uso son muy variados, como observaron Li et al. Para el entrenamiento por lotes y la inferencia se requiere un acceso masivo eficiente. Para la predicción en tiempo real se requiere un acceso por registro de baja latencia. Un único almacén no es óptimo tanto para las características históricas como para las casi en tiempo real por las siguientes razones: a) los almacenes de datos son eficientes para las consultas puntuales o para el acceso masivo, pero no para ambas, y b) el acceso masivo frecuente puede afectar negativamente a la latencia de las consultas puntuales, lo que dificulta su coexistencia. Independientemente del caso de uso, las características se identifican mediante nombres canónicos.

Para el descubrimiento y la gestión de características, el patrón de registro de características es la interfaz de usuario para publicar y descubrir características y conjuntos de datos de entrenamiento. El patrón de registro de rasgos también sirve como herramienta para analizar la evolución de los rasgos a lo largo del tiempo, comparando sus versiones. Al iniciar un nuevo proyecto de ciencia de datos, los científicos de datos suelen empezar por escanear el registro de características en busca de características disponibles, añadiendo únicamente nuevas características que no existan ya en el almacén de características para su modelo.

El patrón de registro de características tiene los siguientes elementos básicos:

Almacenar valores de características

Almacena los valores de las características. Las soluciones habituales para almacenes masivos son Hive (utilizado por Uber y Airbnb), S3 (utilizado por Comcast) y Google BigQuery (utilizado por Gojek). Para los datos en línea, se suele utilizar un almacén NoSQL como Cassandra.

Almacén de registro de funciones

Almacena el código para calcular las características, la información sobre la versión de las características, los datos de análisis de las características y la documentación de las características. El registro de rasgos proporciona análisis automático de rasgos, seguimiento de dependencias de rasgos, seguimiento de trabajos de rasgos, vista previa de datos de rasgos y búsqueda por palabras clave en metadatos de rasgos/grupos de rasgos/conjuntos de datos de entrenamiento.

Un ejemplo del patrón de registro de características es el almacén de características de Hopsworks. Los usuarios consultan el almacén de características como SQL, o mediante programación, y entonces el almacén de características devuelve las características como un marco de datos (como se muestra en la Figura 4-6). Los grupos de características y los conjuntos de datos de entrenamiento del almacén de características Hopsworks están vinculados a trabajos Spark/NumPy/pandas, lo que permite reproducir y volver a calcular las características cuando sea necesario. Además de un grupo de características o un conjunto de datos de entrenamiento, el almacén de características realiza un paso de análisis de datos, que examina el análisis de conglomerados de valores de características, la correlación de características, los histogramas de características y las estadísticas descriptivas. Por ejemplo, la información sobre la correlación de rasgos puede utilizarse para identificar rasgos redundantes, los histogramas de rasgos pueden utilizarse para monitorear las distribuciones de rasgos entre distintas versiones de un rasgo para descubrir el desplazamiento de covariables, y el análisis de conglomerados puede utilizarse para detectar valores atípicos. Tener esas estadísticas accesibles en el registro de características ayuda a los usuarios a decidir qué características utilizar.

Figura 4-6. Las consultas de los usuarios al almacén de características generan marcos de datos (representados en formatos populares, como pandas, NumPy o Spark) (de la documentación de Hopsworks).

Puntos fuertes del patrón de registro de características:

• Proporciona un servicio eficaz de conjuntos de datos de entrenamiento y valores de características

• Reduce el tiempo de análisis de características para los usuarios de datos

Debilidad del patrón de registro de características:

• El posible cuello de botella de rendimiento al servir cientos de modelos

• Escalado para análisis de rasgos continuos con un número creciente de rasgos

Resumen

Hoy en día, no existe una forma basada en principios de acceder a las características durante el servicio y el entrenamiento del modelo. Las características no se pueden reutilizar fácilmente entre varios procesos de ML, y los proyectos de ML trabajan de forma aislada, sin colaboración ni reutilización. Dado que las características están profundamente integradas en los procesos de ML, cuando llegan nuevos datos, no hay forma de determinar exactamente qué características deben volver a calcularse, sino que es necesario ejecutar todo el proceso de ML para actualizar las características. Un almacén de características resuelve estos síntomas y permite economías de escala en el desarrollo de modelos de ML.