Esta página se ha traducido con Cloud Translation API.

Preprocesamiento de datos para ML: opciones y recomendaciones

Este documento es el primero de una serie de dos partes que explora el tema de la ingeniería de datos y la ingeniería de características para el aprendizaje automático (ML), centrándose en las tareas de aprendizaje supervisado. Esta primera parte analiza las mejores prácticas para el preprocesamiento de datos en una canalización de ML en Google Cloud. El documento se centra en el uso de TensorFlow y la biblioteca de código abierto TensorFlow Transform ( tf.Transform ) para preparar datos, entrenar el modelo y servir el modelo para predicción. Este documento destaca los desafíos del preprocesamiento de datos para ML y describe las opciones y escenarios para realizar la transformación de datos en Google Cloud de manera efectiva.

En este documento se supone que estás familiarizado con BigQuery , Dataflow , Vertex AI y la API de TensorFlow Keras .

El segundo documento, Preprocesamiento de datos para ML con Google Cloud , proporciona un tutorial paso a paso sobre cómo implementar una canalización tf.Transform .

Introducción

ML le ayuda a encontrar automáticamente patrones complejos y potencialmente útiles en los datos. Estos patrones se condensan en un modelo de aprendizaje automático que luego se puede usar en nuevos puntos de datos, un proceso llamado hacer predicciones o realizar inferencias .

La creación de un modelo de ML es un proceso de varios pasos. Cada paso presenta sus propios desafíos técnicos y conceptuales. Esta serie de dos partes se centra en las tareas de aprendizaje supervisado y el proceso de selección, transformación y aumento de los datos de origen para crear poderosas señales predictivas para la variable objetivo. Estas operaciones combinan el conocimiento del dominio con técnicas de ciencia de datos. Las operaciones son la esencia de la ingeniería de características .

El tamaño de los conjuntos de datos de entrenamiento para modelos de aprendizaje automático del mundo real puede ser fácilmente igual o superior a un terabyte (TB). Por lo tanto, se necesitan marcos de procesamiento de datos a gran escala para poder procesar estos conjuntos de datos de manera eficiente y distribuida. Cuando usa un modelo de ML para hacer predicciones, debe aplicar las mismas transformaciones que usó para los datos de entrenamiento en los nuevos puntos de datos. Al aplicar las mismas transformaciones, presenta el conjunto de datos en vivo al modelo de ML de la manera que el modelo espera.

Este documento analiza estos desafíos para diferentes niveles de granularidad de las operaciones de ingeniería de características: agregaciones a nivel de instancia, de paso completo y de ventana de tiempo. Este documento también describe las opciones y escenarios para realizar la transformación de datos para ML en Google Cloud.

Este documento también proporciona una descripción general de TensorFlow Transform ( tf.Transform ), una biblioteca para TensorFlow que le permite definir la transformación de datos tanto a nivel de instancia como de paso completo a través de canalizaciones de preprocesamiento de datos. Estas canalizaciones se ejecutan con Apache Beam y crean artefactos que le permiten aplicar las mismas transformaciones durante la predicción que cuando se entrega el modelo.

Preprocesamiento de datos para ML

Esta sección presenta las operaciones de preprocesamiento de datos y las etapas de preparación de los datos. También analiza los tipos de operaciones de preprocesamiento y su granularidad.

Ingeniería de datos comparada con ingeniería de características

El preprocesamiento de datos para ML implica tanto ingeniería de datos como ingeniería de características. La ingeniería de datos es el proceso de convertir datos sin procesar en datos preparados . Luego, la ingeniería de funciones ajusta los datos preparados para crear las funciones que espera el modelo de ML. Estos términos tienen los siguientes significados:

Datos sin procesar (o solo datos ): Los datos en su forma fuente, sin ninguna preparación previa para ML. En este contexto, los datos pueden estar en su forma original (en un lago de datos) o en forma transformada (en un almacén de datos). Los datos transformados que se encuentran en un almacén de datos pueden haberse convertido de su forma original sin procesar para utilizarlos en análisis. Sin embargo, en este contexto, los datos sin procesar significan que los datos no se han preparado específicamente para su tarea de aprendizaje automático. Los datos también se consideran datos sin procesar si se envían desde sistemas de transmisión que eventualmente llaman a modelos de aprendizaje automático para realizar predicciones.
Datos preparados: El conjunto de datos en el formulario está listo para su tarea de aprendizaje automático: las fuentes de datos se han analizado, unido y puesto en forma tabular. Los datos preparados se agregan y se resumen con la granularidad adecuada; por ejemplo, cada fila del conjunto de datos representa un cliente único y cada columna representa información resumida del cliente, como el total gastado en las últimas seis semanas. En una tabla de datos preparada, se eliminaron las columnas irrelevantes y se filtraron los registros no válidos. Para tareas de aprendizaje supervisadas, la función de destino está presente.
Funciones diseñadas: El conjunto de datos con las características ajustadas que espera el modelo, es decir, características que se crean al realizar ciertas operaciones específicas de ML en las columnas del conjunto de datos preparado y crear nuevas características para su modelo durante el entrenamiento y la predicción, como se describe más adelante. en Operaciones de preprocesamiento . Ejemplos de estas operaciones incluyen escalar columnas numéricas a un valor entre 0 y 1, recortar valores y características categóricas de codificación one-hot .

El siguiente diagrama, figura 1, muestra los pasos que intervienen en la preparación de datos preprocesados:

Diagrama de flujo que muestra datos sin procesar pasando a datos preparados pasando a funciones de ingeniería. — **Figura 1.** El flujo de datos desde datos sin procesar hasta datos preparados, funciones de ingeniería y aprendizaje automático.

En la práctica, los datos de la misma fuente suelen encontrarse en diferentes etapas de preparación. Por ejemplo, un campo de una tabla en su almacén de datos podría usarse directamente como una característica de ingeniería. Al mismo tiempo, es posible que otro campo de la misma tabla deba pasar por transformaciones antes de que se convierta en una característica de ingeniería. De manera similar, las operaciones de ingeniería de datos y de ingeniería de características podrían combinarse en el mismo paso de preprocesamiento de datos.

Operaciones de preprocesamiento

El preprocesamiento de datos incluye varias operaciones. Cada operación está diseñada para ayudar a ML a construir mejores modelos predictivos. Los detalles de estas operaciones de preprocesamiento están fuera del alcance de este documento, pero algunas operaciones se describen brevemente en esta sección.

Para datos estructurados, las operaciones de preprocesamiento de datos incluyen lo siguiente:

Limpieza de datos: eliminar o corregir registros que tienen valores corruptos o no válidos de los datos sin procesar y eliminar registros a los que les falta una gran cantidad de columnas.
Selección y partición de instancias: selección de puntos de datos del conjunto de datos de entrada para crear conjuntos de entrenamiento, evaluación (validación) y prueba . Este proceso incluye técnicas de muestreo aleatorio repetible, sobremuestreo de clases minoritarias y partición estratificada.
Ajuste de características: mejorar la calidad de una característica para ML, lo que incluye escalar y normalizar valores numéricos, imputar valores faltantes, recortar valores atípicos y ajustar valores que tienen distribuciones sesgadas.
Transformación de características: convertir una característica numérica en una característica categórica (mediante cubetaización ) y convertir características categóricas en una representación numérica (mediante codificación one-hot, aprendizaje con recuentos , incrustaciones de características dispersas, etc.). Algunos modelos funcionan sólo con funciones numéricas o categóricas, mientras que otros pueden manejar funciones de tipo mixto. Incluso cuando los modelos manejan ambos tipos, pueden beneficiarse de diferentes representaciones (numéricas y categóricas) de la misma característica.
Extracción de características: reducir la cantidad de características mediante la creación de representaciones de datos más poderosas y de menor dimensión utilizando técnicas como PCA , extracción de incrustación y hashing .
Selección de funciones: seleccionar un subconjunto de las funciones de entrada para entrenar el modelo e ignorar las irrelevantes o redundantes, utilizando métodos de filtro o contenedor . La selección de funciones también puede implicar simplemente eliminar funciones si a las funciones les falta una gran cantidad de valores.
Construcción de características: creación de nuevas características mediante el uso de técnicas típicas, como la expansión polinomial (mediante el uso de funciones matemáticas univariadas) o el cruce de características (para capturar interacciones de características). Las características también se pueden construir utilizando la lógica empresarial del dominio del caso de uso de ML.

Cuando se trabaja con datos no estructurados (por ejemplo, imágenes, audio o documentos de texto), el aprendizaje profundo reemplaza la ingeniería de características basada en el conocimiento del dominio incorporándola a la arquitectura del modelo. Una capa convolucional es un preprocesador de funciones automático. Construir la arquitectura del modelo correcto requiere cierto conocimiento empírico de los datos. Además, se necesita cierta cantidad de preprocesamiento, como el siguiente:

Para documentos de texto: derivación y lematización , cálculo TF-IDF y extracción de n-gramas , búsqueda de incrustación.
Para imágenes: recorte, cambio de tamaño, recorte, desenfoque gaussiano y filtros canarios.
Para todo tipo de datos (incluidos texto e imágenes): transferencia de aprendizaje , que trata todas las capas, excepto las últimas, del modelo completamente entrenado como un paso de ingeniería de características.

Granularidad de preprocesamiento

Esta sección analiza la granularidad de los tipos de transformaciones de datos. Muestra por qué esta perspectiva es fundamental a la hora de preparar nuevos puntos de datos para predicciones mediante transformaciones que se aplican a los datos de entrenamiento.

Las operaciones de preprocesamiento y transformación se pueden clasificar de la siguiente manera, según la granularidad de la operación:

Transformaciones a nivel de instancia durante el entrenamiento y la predicción . Estas son transformaciones sencillas, donde solo se necesitan valores de la misma instancia para la transformación. Por ejemplo, las transformaciones a nivel de instancia pueden incluir recortar el valor de una característica a algún umbral, expandir polinomialmente otra característica, multiplicar dos características o comparar dos características para crear un indicador booleano.
Estas transformaciones deben aplicarse de manera idéntica durante el entrenamiento y la predicción, porque el modelo se entrenará en las características transformadas, no en los valores de entrada sin procesar. Si los datos no se transforman de manera idéntica, entonces el modelo se comporta mal porque se le presentan datos que tienen una distribución de valores con la que no fue entrenado. Para obtener más información, consulte la discusión sobre el sesgo en la entrega de capacitación en la sección Desafíos de preprocesamiento .
Transformaciones de paso completo durante el entrenamiento, pero transformaciones a nivel de instancia durante la predicción . En este escenario, las transformaciones tienen estado porque utilizan algunas estadísticas precalculadas para realizar la transformación. Durante el entrenamiento, se analiza todo el conjunto de datos de entrenamiento para calcular cantidades como mínimo, máximo, media y varianza para transformar los datos de entrenamiento, los datos de evaluación y los datos nuevos en el momento de la predicción.
Por ejemplo, para normalizar una característica numérica para el entrenamiento, se calcula su media (μ) y su desviación estándar (σ) en todos los datos de entrenamiento. Este cálculo se denomina operación de paso completo (o análisis ). Cuando entrega el modelo para predicción, el valor de un nuevo punto de datos se normaliza para evitar un sesgo en el servicio de entrenamiento. Por lo tanto, los valores μ y σ que se calculan durante el entrenamiento se utilizan para ajustar el valor de la característica, que es la siguiente operación simple a nivel de instancia :
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Las transformaciones de paso completo incluyen lo siguiente:
- MinMax escala características numéricas utilizando el mínimo y el máximo calculados a partir del conjunto de datos de entrenamiento.
- Características numéricas de escala estándar (normalización de puntuación z) utilizando μ y σ calculadas en el conjunto de datos de entrenamiento.
- Clasificación de características numéricas en cubos mediante cuantiles.
- Imputar valores faltantes utilizando la mediana (características numéricas) o la moda (características categóricas).
- Conversión de cadenas (valores nominales) a números enteros (índices) extrayendo todos los valores distintos (vocabulario) de una característica categórica de entrada.
- Contar la aparición de un término (valor de característica) en todos los documentos (instancias) para calcular TF-IDF.
- Calcular el PCA de las características de entrada para proyectar los datos en un espacio de menor dimensión (con características linealmente dependientes).
Debes usar solo los datos de entrenamiento para calcular estadísticas como μ, σ, min y max . Si agrega los datos de prueba y evaluación para estas operaciones, está filtrando información de los datos de evaluación y prueba para entrenar el modelo. Hacerlo afecta la confiabilidad de los resultados de la prueba y la evaluación. Para asegurarse de aplicar una transformación coherente a todos los conjuntos de datos, utilice las mismas estadísticas calculadas a partir de los datos de entrenamiento para transformar los datos de prueba y evaluación.
Agregaciones históricas durante el entrenamiento y la predicción . Esto implica crear agregaciones, derivaciones e indicadores comerciales como señales de entrada para la tarea de predicción; por ejemplo, crear métricas de actualidad, frecuencia y monetarias (RFM) para que los clientes creen modelos de propensión. Estos tipos de funciones se pueden calcular previamente y almacenar en un almacén de funciones para utilizarlas durante el entrenamiento del modelo, la puntuación por lotes y la publicación de predicciones en línea. También puede realizar ingeniería de funciones adicionales (por ejemplo, transformación y ajuste) en estas agregaciones antes del entrenamiento y la predicción.
Agregaciones históricas durante el entrenamiento, pero agregaciones en tiempo real durante la predicción . Este enfoque implica crear una característica resumiendo valores en tiempo real a lo largo del tiempo. En este enfoque, las instancias que se agregarán se definen mediante cláusulas de ventana temporal. Por ejemplo, puede utilizar este enfoque si desea entrenar un modelo que estime el tiempo de viaje en taxi en función de las métricas de tráfico de la ruta en los últimos 5 minutos, en los últimos 10 minutos, en los últimos 30 minutos y en otros intervalos. También puede utilizar este enfoque para predecir la falla de una pieza del motor basándose en el promedio móvil de los valores de temperatura y vibración calculados durante los últimos 3 minutos. Aunque estas agregaciones se pueden preparar fuera de línea para el entrenamiento, se calculan en tiempo real a partir de un flujo de datos durante el servicio.
Más precisamente, cuando prepara datos de entrenamiento, si el valor agregado no está en los datos sin procesar, el valor se crea durante la fase de ingeniería de datos. Los datos sin procesar generalmente se almacenan en una base de datos con un formato de (entity, timestamp, value) . En los ejemplos anteriores, entity es el identificador del segmento de ruta para las rutas de rodaje y el identificador de la parte del motor para la falla del motor. Puede utilizar operaciones de ventanas para calcular (entity, time_index, aggregated_value_over_time_window) y utilizar las funciones de agregación como entrada para el entrenamiento de su modelo.
Cuando se entrega el modelo para predicción en tiempo real (en línea), el modelo espera características derivadas de los valores agregados como entrada. Por lo tanto, puede utilizar una tecnología de procesamiento de flujo como Apache Beam para calcular las agregaciones a partir de los puntos de datos en tiempo real transmitidos a su sistema. La tecnología de procesamiento de flujo agrega datos en tiempo real basándose en ventanas de tiempo a medida que llegan nuevos puntos de datos. También puede realizar ingeniería de funciones adicionales (por ejemplo, transformación y ajuste) en estas agregaciones antes del entrenamiento y la predicción.

Canalización de aprendizaje automático en Google Cloud

En esta sección se analizan los componentes principales de una canalización típica de un extremo a otro para entrenar y ofrecer modelos de TensorFlow ML en Google Cloud mediante servicios administrados. También analiza dónde puede implementar diferentes categorías de operaciones de preprocesamiento de datos y los desafíos comunes que podría enfrentar al implementar dichas transformaciones. La sección Cómo funciona tf.Transform muestra cómo la biblioteca TensorFlow Transform ayuda a abordar estos desafíos.

Arquitectura de alto nivel

El siguiente diagrama, figura 2, muestra una arquitectura de alto nivel de una canalización de ML típica para entrenar y servir modelos de TensorFlow. Las etiquetas A, B y C en el diagrama se refieren a los diferentes lugares del proceso donde puede tener lugar el preprocesamiento de datos. Los detalles sobre estos pasos se proporcionan en la siguiente sección.

Diagrama de arquitectura que muestra las etapas de procesamiento de datos. — **Figura 2.** Arquitectura de alto nivel para la capacitación y el servicio de ML en Google Cloud.

El pipeline consta de los siguientes pasos:

Una vez importados los datos sin procesar, los datos tabulares se almacenan en BigQuery y otros datos, como imágenes, audio y video, se almacenan en Cloud Storage. La segunda parte de esta serie utiliza datos tabulares almacenados en BigQuery como ejemplo.
La ingeniería de datos (preparación) y la ingeniería de características se ejecutan a escala utilizando Dataflow. Esta ejecución produce conjuntos de prueba, evaluación y capacitación listos para ML que se almacenan en Cloud Storage. Idealmente, estos conjuntos de datos se almacenan como archivos TFRecord , que es el formato optimizado para los cálculos de TensorFlow.
Se envía un paquete de entrenador de modelos TensorFlow a Vertex AI Training, que utiliza los datos preprocesados de los pasos anteriores para entrenar el modelo. El resultado de este paso es un TensorFlow SavedModel entrenado que se exporta a Cloud Storage.
El modelo TensorFlow entrenado se implementa en Vertex AI Prediction como un servicio que tiene una API REST para que pueda usarse para predicciones en línea. El mismo modelo también se puede utilizar para trabajos de predicción por lotes.
Una vez que el modelo se implementa como API REST, las aplicaciones cliente y los sistemas internos pueden invocar la API enviando solicitudes con algunos puntos de datos y recibiendo respuestas del modelo con predicciones.
Para orquestar y automatizar esta canalización, puede utilizar Vertex AI Pipelines como programador para invocar los pasos de preparación de datos, entrenamiento de modelos e implementación de modelos.

También puede utilizar Vertex AI Feature Store para almacenar funciones de entrada para hacer predicciones. Por ejemplo, puede crear periódicamente funciones diseñadas a partir de los datos sin procesar más recientes y almacenarlas en Vertex AI Feature Store. Las aplicaciones cliente obtienen las funciones de entrada requeridas de Vertex AI Feature Store y las envían al modelo para recibir predicciones.

Dónde hacer el preprocesamiento

En la figura 2, las etiquetas A, B y C muestran que las operaciones de preprocesamiento de datos pueden realizarse en BigQuery, Dataflow o TensorFlow. Las siguientes secciones describen cómo funciona cada una de estas opciones.

Opción A: BigQuery

Normalmente, la lógica se implementa en BigQuery para las siguientes operaciones:

Muestreo: seleccionar aleatoriamente un subconjunto de los datos.
Filtrado: eliminar instancias irrelevantes o no válidas.
Partición: dividir los datos para producir conjuntos de entrenamiento, evaluación y prueba.

Los scripts SQL de BigQuery se pueden usar como consulta de origen para el proceso de preprocesamiento de Dataflow, que es el paso de procesamiento de datos en la figura 2. Por ejemplo, si se usa un sistema en Canadá y el almacén de datos tiene transacciones de todo el mundo, filtrar a La mejor manera de obtener datos de capacitación exclusivos para Canadá es BigQuery. La ingeniería de funciones en BigQuery es simple y escalable, y admite la implementación de transformaciones de funciones de agregaciones históricas y a nivel de instancia.

Sin embargo, le recomendamos que use BigQuery para la ingeniería de funciones solo si usa su modelo para la predicción por lotes (puntuación) o si las funciones se calculan previamente en BigQuery, pero se almacenan en Vertex AI Feature Store para usarse durante la predicción en línea. Si planea implementar el modelo para predicciones en línea y no tiene la característica diseñada en una tienda de características en línea, debe replicar las operaciones de preprocesamiento de SQL para transformar los puntos de datos sin procesar que generan otros sistemas. En otras palabras, debes implementar la lógica dos veces: una vez en SQL para preprocesar los datos de entrenamiento en BigQuery y una segunda vez en la lógica de la aplicación que consume el modelo para preprocesar los puntos de datos en línea para la predicción.

Por ejemplo, si su aplicación cliente está escrita en Java, deberá volver a implementar la lógica en Java. Esto puede introducir errores debido a discrepancias en la implementación, como se describe en la sección de sesgo en la prestación de capacitación de Desafíos de preprocesamiento más adelante en este documento. También supone una sobrecarga adicional mantener dos implementaciones diferentes. Siempre que cambie la lógica en SQL para preprocesar los datos de entrenamiento, deberá cambiar la implementación de Java en consecuencia para preprocesar los datos en el momento de la publicación.

Si usa su modelo solo para la predicción por lotes (por ejemplo, usando la predicción por lotes de Vertex AI) y si sus datos para la puntuación provienen de BigQuery, puede implementar estas operaciones de preprocesamiento como parte del script SQL de BigQuery. En ese caso, puede utilizar el mismo script SQL de preprocesamiento para preparar datos de entrenamiento y puntuación.

Las transformaciones con estado de paso completo no son adecuadas para implementarse en BigQuery. Si usa BigQuery para transformaciones de paso completo, necesita tablas auxiliares para almacenar las cantidades necesarias para las transformaciones con estado, como medias y varianzas para escalar características numéricas. Además, la implementación de transformaciones de paso completo usando SQL en BigQuery crea una mayor complejidad en los scripts SQL y crea una dependencia compleja entre el entrenamiento y los scripts SQL de puntuación.

Opción B: flujo de datos

Como se muestra en la figura 2, puede implementar operaciones de preprocesamiento computacionalmente costosas en Apache Beam y ejecutarlas a escala utilizando Dataflow. Dataflow es un servicio de escalado automático totalmente administrado para el procesamiento de datos por lotes y en streaming. Cuando usas Dataflow, también puedes usar bibliotecas especializadas externas para el procesamiento de datos, a diferencia de BigQuery.

Dataflow puede realizar transformaciones a nivel de instancia y transformaciones de funciones de agregación históricas y en tiempo real. En particular, si sus modelos de aprendizaje automático esperan una característica de entrada como total_number_of_clicks_last_90sec , las funciones de ventanas de Apache Beam pueden calcular estas características basándose en la agregación de los valores de las ventanas de tiempo de los datos de eventos (transmisión) en tiempo real (por ejemplo, eventos de clic). En la discusión anterior sobre la granularidad de las transformaciones , esto se denominó "Agregaciones históricas durante el entrenamiento, pero agregaciones en tiempo real durante la predicción".

El siguiente diagrama, figura 3, muestra la función de Dataflow en el procesamiento de datos de flujo para predicciones casi en tiempo real.

Arquitectura para utilizar datos de flujo para predicción. — **Figura 3.** Arquitectura de alto nivel que utiliza datos de flujo para predicción en Dataflow.

Como se muestra en la figura 3, durante el procesamiento, los eventos llamados puntos de datos se incorporan a Pub/Sub . Dataflow consume estos puntos de datos, calcula características basadas en agregados a lo largo del tiempo y luego llama a la API del modelo ML implementado para realizar predicciones. Luego, las predicciones se envían a una cola Pub/Sub saliente. Desde Pub/Sub, las predicciones pueden ser consumidas por sistemas posteriores, como monitoreo o control, o pueden enviarse (por ejemplo, como notificaciones) al cliente solicitante original. Las predicciones también se pueden almacenar en un almacén de datos de baja latencia como Cloud Bigtable para recuperarlas en tiempo real. Cloud Bigtable también se puede utilizar para acumular y almacenar estas agregaciones en tiempo real para poder buscarlas cuando sea necesario para realizar predicciones.

La misma implementación de Apache Beam se puede utilizar para procesar por lotes datos de entrenamiento que provienen de un almacén de datos fuera de línea como BigQuery y procesar datos en tiempo real para ofrecer predicciones en línea.

En otras arquitecturas típicas, como la arquitectura que se muestra en la figura 2, la aplicación cliente llama directamente a la API del modelo implementado para realizar predicciones en línea. En ese caso, si se implementan operaciones de preprocesamiento en Dataflow para preparar los datos de entrenamiento, las operaciones no se aplican a los datos de predicción que van directamente al modelo. Por lo tanto, transformaciones como estas deben integrarse en el modelo durante la publicación de predicciones en línea.

El flujo de datos se puede utilizar para realizar una transformación de paso completo, calculando las estadísticas requeridas a escala. Sin embargo, estas estadísticas deben almacenarse en algún lugar para usarse durante la predicción para transformar los puntos de datos de predicción. Al utilizar la biblioteca TensorFlow Transform ( tf.Transform ), puede incrustar directamente estas estadísticas en el modelo en lugar de almacenarlas en otro lugar. Este enfoque se explica más adelante en Cómo funciona tf.Transform .

Opción C: TensorFlow

Como se muestra en la figura 2, puede implementar operaciones de transformación y preprocesamiento de datos en el propio modelo de TensorFlow. Como se muestra en la figura, el preprocesamiento que implementa para entrenar el modelo TensorFlow se convierte en una parte integral del modelo cuando el modelo se exporta e implementa para predicciones. Las transformaciones en el modelo TensorFlow se pueden lograr de una de las siguientes maneras:

Implementar toda la lógica de transformación a nivel de instancia en la función input_fn y en la función serving_fn . La función input_fn prepara un conjunto de datos utilizando la API tf.data.Dataset para entrenar un modelo. La función serving_fn recibe y prepara los datos para las predicciones.
Poner el código de transformación directamente en su modelo de TensorFlow mediante el uso de capas de preprocesamiento de Keras o la creación de capas personalizadas .

El código de lógica de transformación en la función serving_fn define la interfaz de servicio de su SavedModel para la predicción en línea. Si implementa las mismas transformaciones que se usaron para preparar los datos de entrenamiento en el código lógico de transformación de la función serving_fn , se garantiza que se apliquen las mismas transformaciones a los nuevos puntos de datos de predicción cuando se entreguen.

Sin embargo, debido a que el modelo TensorFlow procesa cada punto de datos de forma independiente o en un lote pequeño, no se pueden calcular agregaciones a partir de todos los puntos de datos. Como resultado, las transformaciones de paso completo no se pueden implementar en su modelo de TensorFlow.

Desafíos de preprocesamiento

Los siguientes son los principales desafíos de la implementación del preprocesamiento de datos:

"Sesgo de servicio de formación" . El sesgo de entrenamiento-servicio se refiere a una diferencia entre efectividad (rendimiento predictivo) durante el entrenamiento y durante el servicio. Este sesgo puede deberse a una discrepancia entre la forma en que se manejan los datos en las canalizaciones de capacitación y de servicio. Por ejemplo, si su modelo está entrenado en una característica transformada logarítmicamente, pero se le presenta la característica sin procesar durante la publicación, es posible que el resultado de la predicción no sea preciso.
Si las transformaciones pasan a formar parte del modelo en sí, puede resultar sencillo manejar las transformaciones a nivel de instancia, como se describió anteriormente en la Opción C: TensorFlow . En ese caso, la interfaz de servicio del modelo (la función serving_fn ) espera datos sin procesar, mientras que el modelo transforma internamente estos datos antes de calcular la salida. Las transformaciones son las mismas que se aplicaron en los puntos de datos sin procesar de entrenamiento y predicción.
Transformaciones de paso completo . No puede implementar transformaciones de paso completo, como transformaciones de escalado y normalización, en su modelo de TensorFlow. En las transformaciones de paso completo, algunas estadísticas (por ejemplo, valores max y min para escalar características numéricas) se deben calcular de antemano en los datos de entrenamiento, como se describe en Opción B: Flujo de datos . Luego, los valores deben almacenarse en algún lugar para usarse durante la entrega del modelo para que la predicción transforme los nuevos puntos de datos sin procesar como transformaciones a nivel de instancia, lo que evita el sesgo en la entrega de entrenamiento. Puede utilizar la biblioteca TensorFlow Transform ( tf.Transform ) para incrustar directamente las estadísticas en su modelo de TensorFlow. Este enfoque se explica más adelante en Cómo funciona tf.Transform .
Preparar los datos por adelantado para una mejor eficiencia del entrenamiento . La implementación de transformaciones a nivel de instancia como parte del modelo puede degradar la eficiencia del proceso de capacitación. Esta degradación se produce porque las mismas transformaciones se aplican repetidamente a los mismos datos de entrenamiento en cada época. Imagine que tiene datos de entrenamiento sin procesar con 1000 funciones y aplica una combinación de transformaciones a nivel de instancia para generar 10 000 funciones. Si implementa estas transformaciones como parte de su modelo y luego alimenta el modelo con los datos de entrenamiento sin procesar, estas 10,000 operaciones se aplican N veces en cada instancia, donde N es el número de épocas. Además, si utiliza aceleradores (GPU o TPU), permanecen inactivos mientras la CPU realiza esas transformaciones, lo que no constituye un uso eficiente de sus costosos aceleradores.
Idealmente, los datos de entrenamiento se transforman antes del entrenamiento, utilizando la técnica descrita en Opción B: Flujo de datos , donde las 10 000 operaciones de transformación se aplican solo una vez en cada instancia de entrenamiento. Luego, los datos de entrenamiento transformados se presentan al modelo. No se aplican más transformaciones y los aceleradores están ocupados todo el tiempo. Además, usar Dataflow te ayuda a preprocesar grandes cantidades de datos a escala mediante un servicio totalmente administrado.
Preparar los datos de entrenamiento por adelantado puede mejorar la eficiencia del entrenamiento. Sin embargo, implementar la lógica de transformación fuera del modelo (los enfoques descritos en la Opción A: BigQuery o la Opción B: Flujo de datos ) no resuelve el problema del sesgo en la entrega de entrenamiento. A menos que almacene la característica diseñada en el almacén de características para usarla tanto para el entrenamiento como para la predicción, la lógica de transformación debe implementarse en algún lugar para aplicarse a los nuevos puntos de datos que vienen para la predicción, porque la interfaz del modelo espera datos transformados. La biblioteca TensorFlow Transform ( tf.Transform ) puede ayudarle a solucionar este problema, como se describe en la siguiente sección.

Cómo funciona tf.Transform

La biblioteca tf.Transform es útil para transformaciones que requieren un pase completo. El resultado de la biblioteca tf.Transform se exporta como un gráfico de TensorFlow que representa la lógica de transformación a nivel de instancia y las estadísticas calculadas a partir de transformaciones de paso completo, que se utilizarán para el entrenamiento y el servicio. Usar el mismo gráfico tanto para el entrenamiento como para el servicio puede evitar sesgos, porque se aplican las mismas transformaciones en ambas etapas. Además, la biblioteca tf.Transform se puede ejecutar a escala en una canalización de procesamiento por lotes en Dataflow para preparar los datos de entrenamiento por adelantado y mejorar la eficiencia del entrenamiento.

El siguiente diagrama, figura 4, muestra cómo la biblioteca tf.Transform preprocesa y transforma datos para entrenamiento y predicción. El proceso se describe en las siguientes secciones.

Diagrama que muestra el flujo desde datos sin procesar a través de tf.Transform a predicciones. — **Figura 4.** Comportamiento de `tf.Transform` para preprocesar y transformar datos.

Transforme los datos de capacitación y evaluación

Usted preprocesa los datos de entrenamiento sin procesar utilizando la transformación implementada en las API tf.Transform Apache Beam y los ejecuta a escala en Dataflow. El preprocesamiento se produce en las siguientes fases:

Fase de análisis: durante la fase de análisis, las estadísticas requeridas (como medias, varianzas y cuantiles) para las transformaciones con estado se calculan en los datos de entrenamiento con operaciones de paso completo. Esta fase produce un conjunto de artefactos de transformación, incluido el gráfico transform_fn . El gráfico transform_fn es un gráfico de TensorFlow que tiene la lógica de transformación como operaciones a nivel de instancia. Incluye las estadísticas calculadas en la fase de análisis como constantes.
Fase de transformación: durante la fase de transformación, el gráfico transform_fn se aplica a los datos de entrenamiento sin procesar, donde las estadísticas calculadas se utilizan para procesar los registros de datos (por ejemplo, para escalar columnas numéricas) a nivel de instancia.

Un enfoque de dos fases como este aborda el desafío del preprocesamiento de realizar transformaciones de paso completo.

Cuando los datos de evaluación se preprocesan, solo se aplican operaciones a nivel de instancia, utilizando la lógica en el gráfico transform_fn y las estadísticas calculadas a partir de la fase de análisis en los datos de entrenamiento. En otras palabras, no se analizan los datos de evaluación en forma completa para calcular nuevas estadísticas, como μ y σ, para normalizar las características numéricas en los datos de evaluación. En su lugar, utiliza las estadísticas calculadas a partir de los datos de entrenamiento para transformar los datos de evaluación a nivel de instancia.

Los datos de entrenamiento y evaluación transformados se preparan a escala utilizando Dataflow, antes de usarlos para entrenar el modelo. Este proceso de preparación de datos por lotes aborda el desafío de preprocesamiento de preparar los datos por adelantado para mejorar la eficiencia de la capacitación. Como se muestra en la Figura 4, la interfaz interna del modelo espera características transformadas.

Adjuntar transformaciones al modelo exportado

Como se señaló, el gráfico transform_fn producido por la tubería tf.Transform se almacena como un gráfico de flujo tensor exportado. El gráfico exportado consiste en la lógica de transformación como operaciones a nivel de instancia, y todas las estadísticas calculadas en las transformaciones de paso completo como constantes gráficas. Cuando el modelo entrenado se exporta para servir, el gráfico transform_fn se adjunta al Modelo Saved como parte de su función serving_fn .

Si bien está sirviendo al modelo de predicción, la interfaz de servicio del modelo espera puntos de datos en el formato sin procesar (es decir, antes de cualquier transformación). Sin embargo, la interfaz interna del modelo espera los datos en el formato transformado.

El gráfico transform_fn , que ahora es parte del modelo, aplica toda la lógica de preprocesamiento en el punto de datos entrante. Utiliza las constantes almacenadas (como μ y σ para normalizar las características numéricas) en la operación a nivel de instancia durante la predicción. Por lo tanto, el gráfico transform_fn convierte el punto de datos sin procesar en el formato transformado. El formato transformado es lo que se espera por la interfaz interna del modelo para producir predicción, como se muestra en la Figura 4.

Este mecanismo resuelve el desafío de preprocesamiento del sesgo que sirve a la formación, porque la misma lógica (implementación) que se utiliza para transformar los datos de capacitación y evaluación se aplica para transformar los nuevos puntos de datos durante la servicio de predicción.

Resumen de opciones de preprocesamiento

La siguiente tabla resume las opciones de preprocesamiento de datos que discutió este documento. En la tabla, "n/a" representa "no aplicable".

Opción de preprocesamiento de datos

Opción de preprocesamiento de datos	Nivel de instancia (Transformaciones sin estado)	Paso completo durante la capacitación y el nivel de instancia durante la entrega (transformaciones con estado)	Agregaciones en tiempo real (ventana) durante la capacitación y servicio (transformaciones de transmisión)
BigQuery (SQL)	Calificación por lotes: OK : la misma implementación de transformación se aplica en los datos durante la capacitación y la puntuación por lotes. Predicción en línea: no recomendado : puede procesar datos de capacitación, pero da como resultado un sesgo de servicio de capacitación porque procesa los datos de servicio utilizando diferentes herramientas.	Puntuación por lotes: no recomendado . Predicción en línea: no recomendado . Aunque puede usar estadísticas calculadas utilizando transformaciones de lotes/en línea de nivel BigQuery, por ejemplo, no es fácil porque debe mantener un almacén de estadísticas para poblar durante la capacitación y utilizar durante la predicción.	Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real. Predicción en línea: no recomendado : puede procesar datos de capacitación, pero da como resultado un sesgo de servicio de capacitación porque procesa los datos de servicio utilizando diferentes herramientas.
DataFlow (Beam Apache)	Calificación por lotes: OK : la misma implementación de transformación se aplica en los datos durante la capacitación y la puntuación por lotes. Predicción en línea: OK : si los datos en el tiempo de servicio provienen del pub/sub para ser consumido por DataFlow. De lo contrario, da como resultado un sesgo que sirve al entrenamiento.	Puntuación por lotes: no recomendado . Predicciones en línea: no recomendado . Aunque puede usar estadísticas calculadas utilizando DataFlow para transformaciones por lotes de nivel de instancia/en línea, no es fácil porque debe mantener un almacén de estadísticas para poblar durante la capacitación y utilizar durante la predicción.	Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real. Predicción en línea: OK : la misma transformación del haz de Apache se aplica en los datos durante la capacitación (lote) y el servicio (transmisión).
DataFlow (Apache Beam + TFT)	Puntuación por lotes: OK : la misma implementación de transformación se aplica a los datos durante la capacitación y la puntuación por lotes. Predicción en línea: Recomendado : evita que la capacitación sea sesgada y prepara datos de capacitación por adelantado.	Puntuación por lotes: recomendado . Predicción en línea: recomendado . Se recomiendan ambos usos porque la lógica de transformación y las estadísticas calculadas durante la capacitación se almacenan como un gráfico de flujo tensor que se adjunta al modelo exportado para servir.	Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real. Predicción en línea: OK : la misma transformación del haz de Apache se aplica en los datos durante la capacitación (lote) y el servicio (transmisión).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Puntuación por lotes: no recomendado . Predicción en línea: no recomendado . Para la eficiencia de capacitación en ambos casos, es mejor preparar los datos de capacitación por adelantado.	Puntuación por lotes: no es posible . Predicción en línea: no es posible .	Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real. Predicción en línea: no es posible .

Nivel de instancia
(Transformaciones sin estado)

Paso completo durante la capacitación y el nivel de instancia durante la entrega (transformaciones con estado)

Agregaciones en tiempo real (ventana) durante la capacitación y servicio (transformaciones de transmisión)

BigQuery (SQL)

Calificación por lotes: OK : la misma implementación de transformación se aplica en los datos durante la capacitación y la puntuación por lotes.

Predicción en línea: no recomendado : puede procesar datos de capacitación, pero da como resultado un sesgo de servicio de capacitación porque procesa los datos de servicio utilizando diferentes herramientas.

Puntuación por lotes: no recomendado .

Predicción en línea: no recomendado .

Aunque puede usar estadísticas calculadas utilizando transformaciones de lotes/en línea de nivel BigQuery, por ejemplo, no es fácil porque debe mantener un almacén de estadísticas para poblar durante la capacitación y utilizar durante la predicción.

Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real.

DataFlow (Beam Apache)

Calificación por lotes: OK : la misma implementación de transformación se aplica en los datos durante la capacitación y la puntuación por lotes.

Predicción en línea: OK : si los datos en el tiempo de servicio provienen del pub/sub para ser consumido por DataFlow. De lo contrario, da como resultado un sesgo que sirve al entrenamiento.

Puntuación por lotes: no recomendado .

Predicciones en línea: no recomendado .

Aunque puede usar estadísticas calculadas utilizando DataFlow para transformaciones por lotes de nivel de instancia/en línea, no es fácil porque debe mantener un almacén de estadísticas para poblar durante la capacitación y utilizar durante la predicción.

Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real.

Predicción en línea: OK : la misma transformación del haz de Apache se aplica en los datos durante la capacitación (lote) y el servicio (transmisión).

DataFlow (Apache Beam + TFT)

Puntuación por lotes: OK : la misma implementación de transformación se aplica a los datos durante la capacitación y la puntuación por lotes.

Predicción en línea: Recomendado : evita que la capacitación sea sesgada y prepara datos de capacitación por adelantado.

Puntuación por lotes: recomendado .

Predicción en línea: recomendado .

Se recomiendan ambos usos porque la lógica de transformación y las estadísticas calculadas durante la capacitación se almacenan como un gráfico de flujo tensor que se adjunta al modelo exportado para servir.

Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real.

Predicción en línea: OK : la misma transformación del haz de Apache se aplica en los datos durante la capacitación (lote) y el servicio (transmisión).

TensorFlow ^*
( input_fn & serving_fn )

Puntuación por lotes: no recomendado .

Predicción en línea: no recomendado .

Para la eficiencia de capacitación en ambos casos, es mejor preparar los datos de capacitación por adelantado.

Puntuación por lotes: no es posible .

Predicción en línea: no es posible .

Puntuación por lotes: N/A: los agregados como estos se calculan en función de eventos en tiempo real.

Predicción en línea: no es posible .

^* Con el flujo de tensor, las transformaciones como el cruce, la incrustación y la codificación única deben realizarse declarativamente como columnas feature_columns .

¿Qué sigue?

Para implementar una tubería tf.Transform y ejecutarla utilizando DataFlow, lea la segunda parte de esta serie, preprocesamiento de datos para ML utilizando la transformación de flujo tensor .
Tome la especialización de Coursera en ML con TensorFlow en Google Cloud .
Aprenda sobre las mejores prácticas para ML Ingeniería en Reglas de ML .
Para obtener más arquitecturas de referencia, diagramas y mejores prácticas, explore las soluciones de nube TFX .

Este documento es el primero de una serie de dos partes que explora el tema de la ingeniería de datos y la ingeniería de características para el aprendizaje automático (ML), con un enfoque en tareas de aprendizaje supervisadas. Esta primera parte analiza las mejores prácticas para el preprocesamiento de datos en una tubería de ML en Google Cloud. El documento se centra en el uso de TensorFlow y la biblioteca de transformación TensorFlow de código abierto ( tf.Transform ) para preparar datos, capacitar al modelo y servir al modelo para su predicción. Este documento destaca los desafíos de los datos de preprocesamiento para ML, y describe las opciones y escenarios para realizar la transformación de datos en Google Cloud de manera efectiva.

Este documento supone que está familiarizado con BigQuery , DataFlow , Vertex AI y la API Keras TensorFlow.

El segundo documento, preprocesamiento de datos para ML con Google Cloud , proporciona un tutorial paso a paso sobre cómo implementar una tubería tf.Transform .

Introducción

ML le ayuda a encontrar patrones complejos y potencialmente útiles en los datos. Estos patrones se condensan en un modelo ML que luego se puede usar en nuevos puntos de datos, un proceso llamado predicciones o una inferencia de rendimiento .

Construir un modelo ML es un proceso de varios pasos. Cada paso presenta sus propios desafíos técnicos y conceptuales. Esta serie de dos partes se centra en las tareas de aprendizaje supervisadas y el proceso de selección, transformación y aumento de los datos de origen para crear señales predictivas potentes a la variable de destino. Estas operaciones combinan el conocimiento del dominio con las técnicas de ciencia de datos. Las operaciones son la esencia de la ingeniería de características .

El tamaño de los conjuntos de datos de entrenamiento para modelos ML del mundo real puede ser fácilmente igual o mayor que un terabyte (TB). Por lo tanto, necesita marcos de procesamiento de datos a gran escala para procesar estos conjuntos de datos de manera eficiente y distribuida. Cuando usa un modelo ML para hacer predicciones, debe aplicar las mismas transformaciones que utilizó para los datos de capacitación en los nuevos puntos de datos. Al aplicar las mismas transformaciones, presenta el conjunto de datos en vivo al modelo ML de la forma en que el modelo espera.

Este documento analiza estos desafíos para diferentes niveles de granularidad de las operaciones de ingeniería de características: agregaciones a nivel de instancia, paso completo y ventanilla de tiempo. Este documento también describe las opciones y escenarios para realizar la transformación de datos para ML en Google Cloud.

Este documento también proporciona una descripción general de la transformación de TensorFlow ( tf.Transform ), una biblioteca para TensorFlow que le permite definir la transformación de datos de nivel completo y de paso completo a través de tuberías de preprocesamiento de datos. Estas tuberías se ejecutan con el haz Apache , y crean artefactos que le permiten aplicar las mismas transformaciones durante la predicción que cuando se sirve el modelo.

Preprocesamiento de datos para ML

Esta sección introduce operaciones de preprocesamiento de datos y etapas de la preparación de datos. También analiza los tipos de operaciones de preprocesamiento y su granularidad.

Ingeniería de datos en comparación con la ingeniería de características

El preprocesamiento de los datos para ML implica tanto la ingeniería de datos como la ingeniería de características. La ingeniería de datos es el proceso de convertir datos sin procesar en datos preparados . La ingeniería de características luego sintoniza los datos preparados para crear las características que esperan el modelo ML. Estos términos tienen los siguientes significados:

Datos sin procesar (o solo datos ): Los datos en su formulario fuente, sin ninguna preparación previa para ML. En este contexto, los datos pueden estar en su forma sin procesar (en un lago de datos) o en forma transformada (en un almacén de datos). Los datos transformados que se encuentran en un almacén de datos podrían haberse convertido de su forma cruda original para ser utilizada para análisis. Sin embargo, en este contexto, los datos sin procesar significan que los datos no se han preparado específicamente para su tarea ML. Los datos también se consideran datos sin procesar si se envían desde sistemas de transmisión que eventualmente llaman a los modelos ML para predicciones.
Datos preparados: El conjunto de datos en el formulario listo para su tarea ML: las fuentes de datos se han analizado, unido y puesto en una forma tabular. Los datos preparados se agregan y se resumen a la granularidad correcta, por ejemplo, cada fila en el conjunto de datos representa un cliente único, y cada columna representa información resumida para el cliente, como el total gastado en las últimas seis semanas. En una tabla de datos preparada, se han eliminado columnas irrelevantes y se han filtrado registros no válidos. Para las tareas de aprendizaje supervisadas, la característica objetivo está presente.
Características diseñadas: El conjunto de datos con las características sintonizadas que esperan el modelo, es decir, las características que se crean realizando ciertas operaciones específicas de ML en las columnas en el conjunto de datos preparado y creando nuevas características para su modelo durante el entrenamiento y la predicción, como se describe más adelante. en operaciones de preprocesamiento . Ejemplos de estas operaciones incluyen escalar columnas numéricas a un valor entre 0 y 1, valores de recorte y características categóricas que codifican un punto .

El siguiente diagrama, Figura 1, muestra los pasos que están involucrados en la preparación de datos preprocesados:

Diagrama de flujo que muestra los datos sin procesar en movimiento a datos preparados que se mueven a las características de ingeniería. — **Figura 1.** El flujo de datos de los datos sin procesar a los datos preparados a las funciones de ingeniería al aprendizaje automático.

En la práctica, los datos de la misma fuente a menudo se encuentran en diferentes etapas de preparación. Por ejemplo, un campo desde una tabla en su almacén de datos podría usarse directamente como una característica de ingeniería. Al mismo tiempo, otro campo en la misma tabla podría necesitar pasar por transformaciones antes de que se convierta en una característica de ingeniería. Del mismo modo, la ingeniería de datos y las operaciones de ingeniería de características podrían combinarse en el mismo paso de preprocesamiento de datos.

Operaciones de preprocesamiento

Para datos estructurados, las operaciones de preprocesamiento de datos incluyen lo siguiente:

Limpieza de datos: eliminar o corregir registros que tienen valores corruptos o no válidos de los datos sin procesar, y eliminando registros que les faltan una gran cantidad de columnas.
Selección y partición de instancias: seleccionar puntos de datos del conjunto de datos de entrada para crear capacitación, evaluación (validación) y conjuntos de pruebas . Este proceso incluye técnicas para muestreo aleatorio repetible, clases minoritarias sobremuestreo y partición estratificada.
Ajuste de características: Mejora de la calidad de una característica para ML, que incluye escalar y normalizar los valores numéricos, imputar valores faltantes, recortar valores atípicos y ajustar valores que tienen distribuciones sesgadas.
Transformación de características: convertir una característica numérica en una característica categórica (a través de la cubierta ) y convertir las características categóricas en una representación numérica (a través de una codificación única, aprendizaje con recuentos , combinación de características escasas, etc.). Algunos modelos solo funcionan con características numéricas o categóricas, mientras que otros pueden manejar características de tipo mixto. Incluso cuando los modelos manejan ambos tipos, pueden beneficiarse de diferentes representaciones (numéricas y categóricas) de la misma característica.
Extracción de características: reduciendo el número de características mediante la creación de representaciones de datos de baja dimensión, más potentes utilizando técnicas como PCA , extracción de incrustación y hash .
Selección de características: seleccionar un subconjunto de las características de entrada para capacitar al modelo e ignorar las irrelevantes o redundantes, utilizando métodos de filtro o envoltorio . La selección de características también puede implicar simplemente soltar características si a las características les falta una gran cantidad de valores.
Construcción de características: creando nuevas características mediante el uso de técnicas típicas, como la expansión polinomial (mediante el uso de funciones matemáticas univariadas) o cruce de características (para capturar interacciones de características). Las características también se pueden construir utilizando la lógica de negocios desde el dominio del caso de uso de ML.

Cuando trabaja con datos no estructurados (por ejemplo, imágenes, audio o documentos de texto), el aprendizaje profundo reemplaza la ingeniería de características basada en el conocimiento del dominio al doblarla en la arquitectura del modelo. Una capa convolucional es un preprocesador automático de características. La construcción de la arquitectura del modelo correcto requiere algún conocimiento empírico de los datos. Además, se necesita cierta cantidad de preprocesamiento, como el siguiente:

Para documentos de texto: derivación y lemmatización , cálculo de TF-IDF y extracción de N-gram , búsqueda de búsqueda.
Para imágenes: recorte, cambio de tamaño, cultivo, desenfoque gaussiano y filtros canarios.
Para todos los tipos de datos (incluidos el texto y las imágenes): transferir el aprendizaje , que trata las capas totalmente perdidas del modelo totalmente capacitado como un paso de ingeniería de características.

Granularidad de preprocesamiento

Esta sección analiza la granularidad de los tipos de transformaciones de datos. Muestra por qué esta perspectiva es crítica al preparar nuevos puntos de datos para predicciones que utilizan transformaciones que se aplican en los datos de entrenamiento.

Las operaciones de preprocesamiento y transformación se pueden clasificar de la siguiente manera, en función de la granularidad de la operación:

Transformaciones de nivel de instancia durante el entrenamiento y la predicción . Estas son transformaciones directas, donde solo se necesitan valores de la misma instancia para la transformación. Por ejemplo, las transformaciones a nivel de instancia pueden incluir recortar el valor de una característica a algún umbral, expandir polinómicamente otra característica, multiplicar dos características o comparar dos características para crear una bandera booleana.
Estas transformaciones deben aplicarse de manera idéntica durante el entrenamiento y la predicción, porque el modelo estará entrenado en las características transformadas, no en los valores de entrada sin procesar. Si los datos no se transforman de manera idéntica, entonces el modelo se comporta mal porque se presenta con datos que tienen una distribución de valores con los que no estaba entrenado. Para obtener más información, consulte la discusión de la sesgo de servicio de capacitación en la sección de desafíos de preprocesamiento .
Transformaciones de paso completo durante el entrenamiento, pero transformaciones a nivel de instancia durante la predicción . En este escenario, las transformaciones son con estado, porque usan algunas estadísticas precomputadas para realizar la transformación. Durante el entrenamiento, analiza todo el cuerpo de datos de entrenamiento para calcular cantidades como mínimo, máximo, media y varianza para transformar datos de entrenamiento, datos de evaluación y nuevos datos en el tiempo de predicción.
Por ejemplo, para normalizar una característica numérica para el entrenamiento, calcula su media (μ) y su desviación estándar (σ) en toda la totalidad de los datos de entrenamiento. Este cálculo se llama operación de paso completo (o analizar ). Cuando sirve al modelo de predicción, el valor de un nuevo punto de datos se normaliza para evitar el sesgo que sirve al servicio. Por lo tanto, los valores μ y σ que se calculan durante el entrenamiento se utilizan para ajustar el valor de la característica, que es la siguiente operación simple de nivel de instancia :
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Las transformaciones de paso completo incluyen lo siguiente:
- Características numéricas de escala Minmax utilizando Min y Max calculados a partir del conjunto de datos de entrenamiento.
- Características numéricas de escala estándar (normalización de puntaje Z) que usan μ y σ calculados en el conjunto de datos de entrenamiento.
- Coloque las características numéricas que usan cuantiles.
- Imputar valores faltantes utilizando la mediana (características numéricas) o el modo (características categóricas).
- Convirtiendo cadenas (valores nominales) a enteros (índices) extrayendo todos los valores distintos (vocabulario) de una característica categórica de entrada.
- Contando la ocurrencia de un término (valor de características) en todos los documentos (instancias) para calcular para TF-IDF.
- Calcula el PCA de las características de entrada para proyectar los datos en un espacio de menor dimensión (con características dependientes linealmente).
Debe usar solo los datos de entrenamiento para calcular estadísticas como μ, σ, Min y Max . Si agrega los datos de prueba y evaluación para estas operaciones, está filtrando información de los datos de evaluación y prueba para capacitar al modelo. Hacerlo afecta la fiabilidad de los resultados de la prueba y la evaluación. Para asegurarse de aplicar una transformación consistente a todos los conjuntos de datos, utiliza las mismas estadísticas calculadas a partir de los datos de capacitación para transformar los datos de prueba y evaluación.
Agregaciones históricas durante el entrenamiento y la predicción . Esto implica la creación de agregaciones comerciales, derivaciones y indicadores como señales de entrada a la tarea de predicción, por ejemplo, la creación de métricas de recuperación, frecuencia y monetarias (RFM) para que los clientes creen modelos de propensión. Estos tipos de características se pueden precomputar y almacenar en una tienda de características que se utilizarán durante la capacitación de modelos, la puntuación por lotes y el servicio de predicción en línea. También puede realizar ingeniería de características adicional (por ejemplo, transformación y ajuste) a estas agregaciones antes de la capacitación y la predicción.
Agregaciones históricas durante la capacitación, pero agregaciones en tiempo real durante la predicción . Este enfoque implica crear una característica al resumir los valores en tiempo real a lo largo del tiempo. En este enfoque, las instancias que se agregarán se definen a través de cláusulas de ventanas temporales. Por ejemplo, puede usar este enfoque si desea entrenar un modelo que estima el tiempo de viaje de taxi según las métricas de tráfico para la ruta en los últimos 5 minutos, en los últimos 10 minutos, en los últimos 30 minutos y en otros intervalos. También puede usar este enfoque para predecir la falla de una parte del motor en función del promedio móvil de la temperatura y los valores de vibración calculados en los últimos 3 minutos. Aunque estas agregaciones se pueden preparar fuera de línea para el entrenamiento, se calculan en tiempo real desde un flujo de datos durante la entrega.
Más precisamente, cuando prepara datos de capacitación, si el valor agregado no está en los datos sin procesar, el valor se crea durante la fase de ingeniería de datos. Los datos sin procesar generalmente se almacenan en una base de datos con un formato de (entity, timestamp, value) . En los ejemplos anteriores, entity es el identificador de segmento de ruta para las rutas de taxi y el identificador de la parte del motor para la falla del motor. Puede usar operaciones de ventanas para calcular (entity, time_index, aggregated_value_over_time_window) y usar las características de agregación como una entrada para la capacitación de su modelo.
Cuando se sirve el modelo para la predicción en tiempo real (en línea), el modelo espera características derivadas de los valores agregados como entrada. Por lo tanto, puede usar una tecnología de procesamiento de transmisión como Apache Beam para calcular las agregaciones de los puntos de datos en tiempo real transmitidos a su sistema. La tecnología de procesamiento de flujo agrega datos en tiempo real en función de las ventanas de tiempo a medida que llegan nuevos puntos de datos. También puede realizar ingeniería de características adicional (por ejemplo, transformación y ajuste) a estas agregaciones antes de la capacitación y la predicción.

Ml Tipeline en Google Cloud

Esta sección discute los componentes centrales de una tubería típica de extremo a extremo para entrenar y servir modelos ML TensorFlow en Google Cloud utilizando servicios administrados. También analiza dónde puede implementar diferentes categorías de las operaciones de preprocesamiento de datos y los desafíos comunes que podría enfrentar cuando implementa tales transformaciones. La sección Cómo funciona TF.Transform muestra cómo la biblioteca TensorFlow Transform ayuda a abordar estos desafíos.

Arquitectura de alto nivel

El siguiente diagrama, Figura 2, muestra una arquitectura de alto nivel de una tubería ML típica para capacitar y servir modelos de flujo de tensor. Las etiquetas A, B y C en el diagrama se refieren a los diferentes lugares en la tubería donde puede tener lugar el preprocesamiento de datos. Los detalles sobre estos pasos se proporcionan en la siguiente sección.

Diagrama de arquitectura que muestra etapas para procesar datos. — **Figura 2.** Arquitectura de alto nivel para ML de entrenamiento y servir en Google Cloud.

La tubería consta de los siguientes pasos:

Después de importar los datos sin procesar, los datos tabulares se almacenan en BigQuery, y otros datos como imágenes, audio y video se almacenan en el almacenamiento en la nube. La segunda parte de esta serie utiliza datos tabulares almacenados en BigQuery como ejemplo.
La ingeniería de datos (preparación) y la ingeniería de características se ejecutan a escala utilizando DataFlow. Esta ejecución produce entrenamiento, evaluación y conjuntos de pruebas listos para ML que se almacenan en el almacenamiento en la nube. Idealmente, estos conjuntos de datos se almacenan como archivos TFRecord , que es el formato optimizado para los cálculos de TensorFlow.
Un paquete de entrenador de modelo TensorFlow se envía a Vertex AI Training, que utiliza los datos preprocesados de los pasos anteriores para entrenar el modelo. La salida de este paso es un modelo guardado TensorFlow capacitado que se exporta al almacenamiento en la nube.
El modelo TensorFlow capacitado se implementa en la predicción de Vertex Ai como un servicio que tiene una API REST para que pueda usarse para predicciones en línea. El mismo modelo también se puede utilizar para trabajos de predicción por lotes.
Después de implementar el modelo como una API REST, las aplicaciones del cliente y los sistemas internos pueden invocar la API enviando solicitudes con algunos puntos de datos y recibir respuestas del modelo con predicciones.
Para orquestar y automatizar esta tubería, puede usar las tuberías de AI Vertex como programador para invocar los pasos de preparación de datos, capacitación del modelo y implementación del modelo.

También puede usar la tienda de funciones Vertex AI para almacenar funciones de entrada para hacer predicciones. Por ejemplo, puede crear periódicamente funciones de ingeniería a partir de los últimos datos sin procesar y almacenarlos en Vertex AI Feature Store. Las aplicaciones del cliente obtienen las funciones de entrada requeridas de Vertex AI Feature Store y las envían al modelo para recibir predicciones.

Donde hacer el preprocesamiento

En la Figura 2, las etiquetas A, B y C muestran que las operaciones de preprocesamiento de datos pueden tener lugar en BigQuery, DataFlow o TensorFlow. Las siguientes secciones describen cómo funciona cada una de estas opciones.

Opción A: BigQuery

Por lo general, la lógica se implementa en BigQuery para las siguientes operaciones:

Muestreo: seleccionando aleatoriamente un subconjunto de los datos.
Filtrado: eliminación de instancias irrelevantes o inválidas.
Partición: dividir los datos para producir entrenamiento, evaluación y conjuntos de pruebas.

Los scripts SQL BigQuery se pueden utilizar como una consulta de origen para la tubería de preprocesamiento de flujo de datos, que es el paso de procesamiento de datos en la Figura 2. Por ejemplo, si se usa un sistema en Canadá, y el almacén de datos tiene transacciones de todo el mundo, filtrándose hasta Obtener datos de capacitación solo de Canadá se realizan mejor en BigQuery. La ingeniería de características en BigQuery es simple y escalable, y admite la implementación de las transformaciones de funciones de agregaciones históricas de nivel de instancia.

Sin embargo, le recomendamos que use BigQuery para la ingeniería de características solo si usa su modelo para la predicción de lotes (puntuación), o si las características son precomputadas en BigQuery, pero se almacenan en Vertex AI Feature Store para ser utilizado durante la predicción en línea. Si planea implementar el modelo para predicciones en línea, y si no tiene la función de ingeniería en una tienda de funciones en línea, debe replicar las operaciones de preprocesamiento SQL para transformar los puntos de datos sin procesar que otros sistemas generan. En otras palabras, debe implementar la lógica dos veces: una vez en SQL para preprocesar datos de capacitación en BigQuery, y una segunda vez en la lógica de la aplicación que consume el modelo para preprocesar puntos de datos en línea para su predicción.

Por ejemplo, si su aplicación de cliente está escrita en Java, debe volver a implementar la lógica en Java. Esto puede introducir errores debido a las discrepancias de implementación, como se describe en la sección de sesgo que sirve a la capacitación de los desafíos de preprocesamiento más adelante en este documento. También es una sobrecarga adicional para mantener dos implementaciones diferentes. Cada vez que cambia la lógica en SQL para preprocesar los datos de capacitación, debe cambiar la implementación de Java en consecuencia a los datos del preprocesamiento en el tiempo de servicio.

Si está utilizando su modelo solo para predicción por lotes (por ejemplo, utilizando la predicción de lotes de AI Vertex), y si sus datos para la puntuación se obtienen de BigQuery, puede implementar estas operaciones de preprocesamiento como parte del script SQL BigQuery. En ese caso, puede usar el mismo script SQL de preprocesamiento para preparar datos de entrenamiento y puntuación.

Las transformaciones con estado de paso completo no son adecuadas para la implementación en BigQuery. Si usa BigQuery para transformaciones de paso completo, necesita tablas auxiliares para almacenar cantidades necesarias por transformaciones con estado, como medios y variaciones para escalar características numéricas. Además, la implementación de transformaciones de paso completo usando SQL en BigQuery crea una mayor complejidad en los scripts SQL y crea una dependencia intrincada entre el entrenamiento y los scripts SQL de puntuación.

Opción B: Dataflow

Como se muestra en la Figura 2, puede implementar operaciones de preprocesamiento computacionalmente costosas en el haz Apache y ejecutarlas a escala usando DataFlow. DataFlow es un servicio de autoscalaje totalmente administrado para el procesamiento de datos por lotes y transmisión. Cuando usa DataFlow, también puede usar bibliotecas especializadas externas para el procesamiento de datos, a diferencia de BigQuery.

DataFlow puede realizar transformaciones a nivel de instancia y transformaciones de características de agregación históricas y en tiempo real. En particular, si sus modelos ML esperan una función de entrada como total_number_of_clicks_last_90sec , las funciones de ventanas de haz de Apache pueden calcular estas características basadas en agregar los valores de las ventanas de tiempo de datos de eventos en tiempo real (transmisión) (por ejemplo, hacer clic en eventos). En la discusión anterior de la granularidad de las transformaciones , esto se denominó "agregaciones históricas durante la capacitación, pero agregaciones en tiempo real durante la predicción".

El siguiente diagrama, Figura 3, muestra el papel del flujo de datos en el procesamiento de datos de flujo para predicciones cercanas a tiempo real.

Arquitectura para usar datos de transmisión para predicción. — **Figura 3.** Arquitectura de alto nivel utilizando datos de flujo para la predicción en DataFlow.

Como se muestra en la Figura 3, durante el procesamiento, los eventos llamados puntos de datos se ingieren en pub/sub . DataFlow consume estos puntos de datos, calcula las características basadas en agregados a lo largo del tiempo y luego llama a la API del modelo ML implementada para predicciones. Luego se envían predicciones a una cola de pub/sub -cola de salida. Desde Pub/Sub, los sistemas posteriores se pueden consumir predicciones como el monitoreo o el control, o pueden retroceder (por ejemplo, como notificaciones) al cliente solicitante original. Las predicciones también se pueden almacenar en un almacén de datos de baja latencia como Cloud BigTable para obtener una recuperación en tiempo real. Cloud BigTable también se puede usar para acumular y almacenar estas agregaciones en tiempo real para que puedan ser revisados cuando sea necesario para su predicción.

La misma implementación del haz Apache se puede utilizar para obtener datos de capacitación de procesos por lotes que provienen de un almacén de datos fuera de línea como BigQuery y datos en tiempo real de procesamiento real para servir predicciones en línea.

En otras arquitecturas típicas, como la arquitectura que se muestra en la Figura 2, la aplicación del cliente llama directamente a la API del modelo implementada para predicciones en línea. En ese caso, si las operaciones de preprocesamiento se implementan en el flujo de datos para preparar los datos de capacitación, las operaciones no se aplican a los datos de predicción que van directamente al modelo. Por lo tanto, las transformaciones como estas deben integrarse en el modelo durante el servicio para predicciones en línea.

DataFlow se puede utilizar para realizar la transformación de paso completo, calculando las estadísticas requeridas a escala. Sin embargo, estas estadísticas deben almacenarse en algún lugar para usarse durante la predicción para transformar los puntos de datos de predicción. Al usar la biblioteca de transformación TensorFlow ( tf.Transform ), puede incrustar directamente estas estadísticas en el modelo en lugar de almacenarlas en otro lugar. Este enfoque se explica más adelante en cómo funciona TF.Transform .

Opción C: TensorFlow

Como se muestra en la Figura 2, puede implementar operaciones de preprocesamiento y transformación de datos en el modelo TensorFlow. Como se muestra en la figura, el preprocesamiento que implementa para capacitar al modelo TensorFlow se convierte en una parte integral del modelo cuando el modelo se exporta e implementa predicciones. Las transformaciones en el modelo TensorFlow se pueden lograr de una de las siguientes maneras:

Implementación de toda la lógica de transformación a nivel de instancia en la función input_fn y en la función serving_fn . La función input_fn prepara un conjunto de datos utilizando la API tf.data.Dataset para capacitar a un modelo. La función serving_fn recibe y prepara los datos para las predicciones.
Poner el código de transformación directamente en su modelo TensorFlow utilizando capas de preprocesamiento de Keras o creando capas personalizadas .

El código de lógica de transformación en la función serving_fn define la interfaz de servicio de su Modelo Saved para la predicción en línea. Si implementa las mismas transformaciones que se utilizaron para preparar datos de capacitación en el código lógico de transformación de la función serving_fn , asegura que las mismas transformaciones se apliquen a nuevos puntos de datos de predicción cuando se sirven.

Sin embargo, debido a que el modelo TensorFlow procesa cada punto de datos de forma independiente o en un pequeño lote, no puede calcular las agregaciones de todos los puntos de datos. Como resultado, las transformaciones de paso completo no se pueden implementar en su modelo TensorFlow.

Desafíos de preprocesamiento

Los siguientes son los principales desafíos de implementar el preprocesamiento de datos:

Sesgo que sirve al entrenamiento . El sesgo que sirve a la capacitación se refiere a una diferencia entre la efectividad (rendimiento predictivo) durante la capacitación y durante la entrega. Este sesgo puede ser causado por una discrepancia entre cómo maneja los datos en la capacitación y las tuberías de servicio. Por ejemplo, si su modelo está entrenado en una característica transformada logarítmicamente, pero se presenta con la característica sin procesar durante la entrega, la salida de predicción podría no ser precisa.
Si las transformaciones se convierten en parte del modelo en sí, puede ser sencillo manejar las transformaciones a nivel de instancia, como se describió anteriormente en la opción C: TensorFlow . En ese caso, la interfaz de servicio del modelo (la función serving_fn ) espera datos sin procesar, mientras que el modelo transforma internamente estos datos antes de calcular la salida. Las transformaciones son las mismas que se aplicaron en los puntos de datos de entrenamiento y predicción sin procesar.
Transformaciones de paso completo . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Diagram showing flow from raw data through tf.Transform to predictions. — **Figure 4.** Behavior of `tf.Transform` for preprocessing and transforming data.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

¿Qué sigue?

To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
Take the Coursera specialization on ML with TensorFlow on Google Cloud .
Learn about best practices for ML engineering in Rules of ML .
For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Introducción

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data ): The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
Prepared data: The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
Engineered features: The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

Flow diagram showing raw data moving to prepared data moving to engineered features. — **Figure 1.** The flow of data from raw data to prepared data to engineered features to machine learning.

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervalos. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.
When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

Architecture diagram showing stages for processing data. — **Figure 2.** High-level architecture for ML training and serving on Google Cloud.

The pipeline consists of the following steps:

After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

Sampling: randomly selecting a subset from the data.
Filtering: removing irrelevant or invalid instances.
Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

Architecture for using stream data for prediction. — **Figure 3.** High-level architecture using stream data for prediction in Dataflow.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.
Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

Attach transformations to the exported model

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

¿Qué sigue?

To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
Take the Coursera specialization on ML with TensorFlow on Google Cloud .
Learn about best practices for ML engineering in Rules of ML .
For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Introducción

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Raw data (or just data ): The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
Prepared data: The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
Engineered features: The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

Preprocessing operations

For structured data, data preprocessing operations include the following:

Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$
Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervalos. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.
When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

High-level architecture

The pipeline consists of the following steps:

After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

Sampling: randomly selecting a subset from the data.
Filtering: removing irrelevant or invalid instances.
Partitioning: splitting the data to produce training, evaluation, and test sets.

Option B: Dataflow

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

Option C: TensorFlow

Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.
Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .
Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

Attach transformations to the exported model

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

Data preprocessing option

Data preprocessing option	Instance-level (stateless transformations)	Full-pass during training and instance-level during serving (stateful transformations)	Real-time (window) aggregations during training and serving (streaming transformations)
BigQuery (SQL)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.	Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.
Dataflow (Apache Beam)	Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.	Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
Dataflow (Apache Beam + TFT)	Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.	Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).
TensorFlow ^* ( `input_fn` & `serving_fn` )	Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front.	Batch scoring: Not Possible . Online prediction: Not Possible .	Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible .

Instance-level
(stateless transformations)

Full-pass during training and instance-level during serving (stateful transformations)

Real-time (window) aggregations during training and serving (streaming transformations)

BigQuery (SQL)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Batch scoring: Not recommended .

Online prediction: Not recommended .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools.

Dataflow (Apache Beam)

Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring.

Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew.

Batch scoring: Not recommended .

Online predictions: Not recommended .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

Dataflow (Apache Beam + TFT)

Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring.

Online prediction: Recommended —it avoids training-serving skew and prepares training data up front.

Batch scoring: Recommended .

Online prediction: Recommended .

Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving.

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream).

TensorFlow ^*
( input_fn & serving_fn )

Batch scoring: Not recommended .

Online prediction: Not recommended .

For training efficiency in both cases, it's better to prepare the training data up front.

Batch scoring: Not Possible .

Online prediction: Not Possible .

Batch scoring: N/A —aggregates like these are computed based on real-time events.

Online prediction: Not Possible .

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

¿Qué sigue?

To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
Take the Coursera specialization on ML with TensorFlow on Google Cloud .
Learn about best practices for ML engineering in Rules of ML .
For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .