Opciones de infraestructura para canalizar datos de anuncios (Parte 2)

Este artículo se centra en las canalizaciones de datos y las tareas de aprendizaje automático comunes a las diferentes plataformas publicitarias. El artículo complementa las Opciones de infraestructura para entregar cargas de trabajo de publicidad (Parte 1). Ambos artículos proporcionan el contexto necesario para la serie:

Este artículo forma parte de la siguiente serie:

Para obtener una descripción general sobre el modo en que estas plataformas funcionan en conjunto y sobre la terminología de la tecnología publicitaria que se usa en esta serie, consulta Crea plataformas publicitarias (descripción general).

Los almacenes de datos (en la Parte 1) que se usan en las canalizaciones de datos son el Almacén de perfil de usuario (único), el almacén de contexto (en la Parte 1) y el Almacén de informes y paneles (en la Parte 1). Estos almacenes de datos se alimentan a través de dos fuentes principales: eventos y datos de terceros. Este artículo se centra en la administración de eventos. Para obtener más información sobre los datos de terceros y su uso en el enriquecimiento de datos del usuario, consulta la sección sobre enriquecimiento de datos (en la Parte 4).

Ciclo de vida del evento

La canalización de datos desde eventos sin procesar hasta datos útiles se puede dividir de la siguiente forma:

  • Recopilación y almacenamiento (transferencia): a través de un sistema de mensajería o carga recurrente de archivos a un sistema de almacenamiento.
  • Procesamiento: ya sea en lotes o en modo de transmisión para el procesamiento en tiempo real, cuando la actualidad de los datos es importante.
  • Exportar (o cargar): directamente desde la herramienta de procesamiento de datos o mediante un flujo de trabajo personalizado. Los destinos suelen ser los almacenamientos ya mencionados.

Los eventos más comunes en la tecnología de anuncios son los siguientes:

  • Solicitudes de ofertas y anuncios: por lo general, se reciben de un sistema externo. Las solicitudes contienen detalles que forman parte de la entrada para la selección de anuncios.
  • Impresiones: creatividades que se cargan en una página web, pero no siempre son visibles.
  • Impresiones facturables: impresiones procesadas o visibles.
  • Clics: acciones que un usuario puede realizar con tan solo un clic en una creatividad.
  • Conversiones: acciones que realiza un usuario específico en el sitio web del anunciante.

Los eventos asociados con las ofertas en tiempo real se tratan en Opciones de infraestructura para ofertantes de RTB (Parte 4).

Recolección

Los eventos se pueden crear mediante los siguientes métodos:

  • Instancias de solicitud de ofertas o anuncios: las instancias que reciben una solicitud muestran una URL para la creatividad o una respuesta de oferta.
  • Instancias colectoras: instancias que muestran un píxel invisible para registrar impresiones o recolectar acciones que un usuario específico realizó en un anuncio (acciones como clics o reproducciones de video).
  • Cloud Logging: en algunos casos, este registro puede reemplazar las instancias colectoras y los archivos de registro del servidor.

Los eventos se pueden recolectar a través de lo siguiente:

  • Código personalizado que publica el evento en un sistema de mensajería, como Pub/Sub, o que realiza operaciones de escritura en un archivo de registro local.
  • Herramientas de terceros o funciones de registro nativas en tu servidor web.
  • Un agente de Logging de Google Cloud que admite software de terceros seleccionado y se integra a Cloud Logging.

Los eventos pueden transferirse en las siguientes condiciones:

  • Casi en tiempo real, cuando los archivos de registro se escriben de forma local y, luego, se copian periódicamente en un almacenamiento compartido, como Cloud Storage o BigQuery Capacitor para su procesamiento. El almacenamiento de BigQuery se suele usar si ese procesamiento involucra consultas estadísticas.
  • En tiempo real, cuando se usa Cloud Logging o cuando los colectores realizan operaciones de escritura directamente en un almacén de datos de baja latencia o en un sistema de mensajería, como Cloud Pub/Sub, Apache Kafka o RabbitMQ. Los sistemas de procesamiento en tiempo real a menudo usan esta opción.

Cloud Logging puede facilitar muchas de estas tareas porque permite capturar datos directamente de los productos de Google Cloud, como Compute Engine, Google Kubernetes Engine e, incluso, del balanceo de cargas HTTP. Logging también puede exportar datos directamente a BigQuery para realizar estadísticas ad hoc, hacer transmisiones a Pub/Sub con fines de alerta y procesamiento en tiempo real y llevar a cabo exportaciones por lotes a Cloud Storage a fin de realizar copias de seguridad o estadísticas federadas.

Estos son algunos ejemplos que ilustran los puntos mencionados y que toman en consideración las operaciones, el costo y la actualidad de los datos:

Opción Costo Sobrecarga operativa Actualidad de los datos
Copiar los archivos de registro en Cloud Storage cada X segundos y luego a BigQuery mediante bq load Sin costo de entrada a Cloud Storage

Sin costo de transferencia a BigQuery

Costos de almacenamiento de BigQuery
Requiere administración de archivos, fallas, reintentos y sincronización Casi en tiempo real
Copiar los archivos de registro en Cloud Storage cada X segundos y luego a BigQuery mediante Cloud Functions Sin costo de entrada a Cloud Storage

Sin costo de transferencia a BigQuery

Costo adicional con Cloud Functions

Costos de almacenamiento de BigQuery
Cloud Functions hace que la administración de carga sea más fácil. La lógica aún debe codificarse. Casi en tiempo real
Usar Cloud Logging con una exportación a Pub/Sub Costos de Pub/Sub Baja Tiempo real
Usar un daemon local para transmitir los registros a Kafka Costos de almacenamiento y procesamiento requeridos para ejecutar Kafka Configurar y administrar Kafka, a menos que se use la opción administrada por Google Cloud Casi en tiempo real o en tiempo real según cómo se configura Kafka

Sugerencia: Cuando uses instancias de procesamiento para recolectar eventos, siempre considera usar VM interrumpibles, como se explica en la sección Plataforma de Compute, a fin de reducir costos.

Almacenamiento de datos

El lugar donde se almacenan tus datos varía según su formato, cómo se accede a ellos, cómo se usan y el costo de almacenarlos. Si el formato de los datos no está estructurado o estos requieren de un almacenamiento antes de ser procesados, entonces, como se recomendó con anterioridad, considera usar Cloud Storage. En cuanto a los datos estructurados, también debes considerar el esfuerzo que se requiere para acceder a los registros. El siguiente diagrama puede ayudarte a evaluar el patrón de acceso de modo que puedas minimizar el número de operaciones y el costo.

Recomendaciones para ayudarte a exportar datos

En los Patrones de almacenamiento con alto contenido de lectura (en la Parte 1) se analizan las opciones que se usan para el almacenamiento y la entrega. En el resto de esta sección, se abordan los almacenes de datos estadísticos que se usan con la transmisión y el procesamiento por lotes.

En la transmisión, se procesan los datos sin procesar antes de almacenarlos. Si también deseas que los datos estén disponibles de forma inmediata para consultas ad hoc, considera la transmisión a BigQuery. Puedes llevarla a cabo de forma sencilla con la plantilla de Dataflow de Pub/Sub a BigQuery.

En el procesamiento por lotes recurrente, puedes consolidar los datos almacenándolos en un entorno compartido y escalable. Un patrón común es mover los archivos de registro cada pocos minutos desde su ubicación local hacia el almacenamiento de objetos. Los nombres de archivo a menudo tienen prefijo y sufijo, por ejemplo: logs_serverABC_timestamp123.txt.

Puedes ejecutar tus cargas de trabajo estadísticas en los siguientes sistemas de almacenamiento:

  • Cloud Storage: con las clases de almacenamiento estándar, Nearline y Coldline, puedes guardar datos para acceder rápidamente a ellos, archivarlos o realizar copias de seguridad. Configura el almacenamiento estándar, la opción preferida para las estadísticas, como un bucket regional cuando sea posible. Configura el almacenamiento en la misma región que los recursos de procesamiento que procesan los datos. Se puede acceder a Cloud Storage desde la mayoría de los productos de Google Cloud, incluidos Dataproc, Dataflow, Dataprep by Trifacta y BigQuery.
  • BigQuery: BigQuery no solo es un potente motor de consulta. También tiene su propio almacenamiento, llamado Capacitor, que te permite almacenar exabytes de datos. Se puede acceder al almacenamiento de BigQuery desde Dataproc, Dataflow y el motor de consultas de BigQuery. Con el Almacenamiento a largo plazo de BigQuery, tus costos de almacenamiento se reducen alrededor de un 50% para las particiones que no se editan durante 90 días.
  • Bigtable: con miles de millones de eventos recolectados todos los días, Bigtable es una gran opción si necesitas operaciones con alto contenido de escritura y lectura en milésimas de segundo de un solo dígito. Se puede acceder a Bigtable a través de la API de HBase y otros clientes. Cloud Bigtable también se puede usar con el ecosistema de macrodatos para gráficos, series temporales y estadísticas.

Te recomendamos que tengas en cuenta las siguientes pautas generales:

  • Almacena datos sin procesar en BigQuery en paralelo a cualquier otro procesamiento. Desde ese punto, es fácil seguir agregando datos cada hora, día, semana o mes. Las opciones de carga dependen de tus requerimientos. Obtén más información en la documentación sobre carga de datos de BigQuery.
  • Si te preocupan los costos, los datos almacenados en Cloud Storage se pueden cargar en BigQuery sin cargo o a un precio menor que el de la transmisión usando bq load, Cloud Functions, la API de trabajo o las consultas federadas. Las primeras dos opciones están sujetas a cuotas.
  • Usa las funciones de almacenamiento de BigQuery, como las particiones y el agrupamiento en clústeres para minimizar el tiempo y los costos de consulta.

Procesamiento de eventos

Cuando elijas una tecnología para compilar tus canalizaciones de procesamiento, ten en cuenta lo siguiente:

  • Latencia: decide cuáles son los datos que se deben procesar en tiempo real. Por ejemplo, podrías tener que calcular los contadores de presupuesto lo más rápido posible.
  • Corrección: algunos valores deben calcularse con exactitud, aunque quizás no de manera inmediata. Por ejemplo, los importes de facturación.
  • Alta disponibilidad: con miles de millones de entradas de datos todos los días, unos pocos minutos de inactividad pueden producir un impacto financiero significativo.
  • Sobrecarga operativa: puede que "mantener las luces encendidas" no sea el mejor uso de los recursos técnicos.

Considera el siguiente ejemplo:

  • Se transfieren los registros de balanceo de cargas HTTP en tiempo real mediante Cloud Logging.
  • Se deben procesar algunos registros de forma inmediata para calcular el presupuesto restante.
  • Los recuentos de impresiones se agregan y se solicitan cada hora, y los límites de frecuencia de campaña, cada día.

Es común que las empresas empleen la arquitectura lambda en sus canalizaciones de procesamiento de datos para balancear lo siguiente:

  • Aproximaciones rápidas a través de una canalización de procesamiento en tiempo real.
  • Exactitud a través de una canalización de procesamiento por lotes adicional sin conexión

Canalización de procesamiento de datos lambda

En esta sección, se describen algunos de los productos de Google Cloud que puedes usar para implementar arquitecturas de procesamiento de datos lambda y kappa, así como Dataflow:

  • Dataproc (por lotes y de transmisión): si ya tienes secuencias de comandos y trabajos de Hadoop o Spark, puedes migrarlos tal como están a Dataproc, Spark administrado por Google Cloud o Hadoop.
  • Dataflow (por lotes y de transmisión): si tienes cargas de trabajo nuevas, consideras usar funciones de transmisión avanzadas o deseas un modelo de programación unificado, Dataflow proporciona un servicio completamente administrado que ejecuta Apache Beam y es de código abierto gracias a Google. Dataflow también admite muchas entradas y salidas, como Pub/Sub y Kafka, y ofrece un modelo de programación unificado para los datos de transmisión y por lotes que admite el procesamiento exactamente una vez.
  • BigQuery (por lotes): si consideras un enfoque ELT (extraer, cargar y transformar) o realizas transformaciones posteriores luego de que los datos se cargan en el almacén de datos, puedes usar BigQuery para las transformaciones de SQL. Está administrado y proporciona funciones definidas por el usuario. Para la organización de estas consultas, considera usar Cloud Composer, administrado por Apache Airflow.
  • Herramientas de terceros: puedes instalar y administrar herramientas del ecosistema de Hadoop o herramientas como Storm en Compute Engine o Google Kubernetes Engine (GKE).

La siguiente arquitectura describe una recomendación basada en estos requisitos:

  • Transferir los eventos en tiempo real
  • Procesar algunos contadores cada segundo
  • Agregar un recuento de impresiones cada hora
  • Calcular la tasa de clics de los anuncios todos los días

Canalización de procesamiento de datos que usa Pub/Sub

El flujo de procesamiento de datos es el siguiente:

  1. Los eventos se escriben en Pub/Sub.
  2. Dataflow escribe los datos a nivel de evento directamente en BigQuery.
  3. Dataflow también estructura los datos en intervalos de un segundo para realizar las agregaciones necesarias y escribe los contadores en instancias regionales de Bigtable.
  4. BigQuery ejecuta una consulta de forma recurrente para seguir agregando los datos y materializar los resultados. Esto se puede programar a través de trabajos cron o mediante las opciones de programación de Apache Airflow con Cloud Composer.
  5. Los frontends de usuario pueden usar BigQuery como una base de datos de OLAP. Para obtener más detalles, consulta la sección de informes (en la Parte 1).
  6. Los servidores de anuncios regionales consultan instancias de Bigtable cercanas para recuperar contadores rápidamente.

Sigue estas recomendaciones generales para compilar una canalización de procesamiento de datos:

  • Usa Pub/Sub para minimizar la sobrecarga operacional o considera ejecutar Apache Kafka como un servicio administrado en Google Cloud.
  • Considera escribir tu canalización con Apache Beam para abordar el proceso por lotes y de transmisión a través de un modelo de programación unificado.
  • Ejecuta Apache Beam en Dataflow para aprovechar los beneficios de un servicio completamente administrado que puede aumentar o reducir automáticamente la cantidad de trabajadores durante la vida útil del trabajo y rebalancear dinámicamente el trabajo a fin de disminuir el tiempo de procesamiento general de este.

Si tienes otros datos o eventos que quieras explorar visualmente, limpiar y preparar para el análisis, considera usar Dataprep. No necesitarás escribir código, ya que Dataprep te permite exportar plantillas de Dataflow que puedes reutilizar y programar.

Exportaciones

Una vez que los eventos se transfirieron y se procesaron, los resultados se pueden exportar a alguna de las siguientes opciones:

  • Almacenes sin conexión, como BigQuery o Cloud Storage, para un procesamiento sin conexión, incluidos los agregados y las estadísticas.
  • Almacenes de entrega, como Bigtable, Datastore, Memorystore y almacenamientos de terceros. Los servidores frontend usan estos almacenes, por ejemplo, para recuperar información de perfiles de usuario y actualizar los contadores cuando se seleccionan los anuncios.
  • Sistemas de mensajería, como Pub/Sub o Kafka, cuando los datos requieren un procesamiento posterior o se envían como una alerta, por ejemplo, cuando se administran los presupuestos.

La replicación de datos es otro caso práctico de exportación. Por ejemplo, cuando necesitas que los datos estén cerca de tus servidores frontend o incluso en los servidores, existen los siguientes dos enfoques:

  • En algunos casos, si tu elección de tecnología lo admite, puedes usar funciones de replicación nativas. Algunas tecnologías, como Redis y Aerospike, admiten la replicación dentro de las regiones. Sin embargo, la replicación entre regiones puede resultar más desafiante.
  • Es posible que otras tecnologías no admitan la replicación. En ese caso, puedes implementarla con un sistema de mensajería y procesadores que se ejecuten en Compute Engine o Pub/Sub.

El siguiente diagrama muestra algunos enfoques diferentes:

Estructura de la replicación de datos con los almacenes de Google Cloud

Los datos se procesan en tiempo real con Dataflow y sin conexión mediante BigQuery, después de lo cual ocurre lo siguiente:

  • Dataflow escribe datos directamente en un clúster de Redis mediante IO de Apache Beam Redis que, a su vez, los replica en sus trabajadores locales.
  • Dataflow publica mensajes en Pub/Sub. A estos los lee un grupo de suscriptores con ajuste de escala automático. Luego, se implementan en Compute Engine y este los escribe en un clúster de Aerospike que se ejecuta en Compute Engine.
  • Los registros de los trabajos sin conexión de BigQuery, programados a través de Cloud Composer, se exportan a los clústeres de Redis y Aerospike.

Si exportas datos, te recomendamos que tengas en cuenta lo siguiente:

  • Asegúrate de que el almacén de datos elegido pueda manejar los patrones de lectura y escritura. De lo contrario, considera desacoplar la infraestructura de lectura, como se detalla en Patrones de almacenamiento con alto contenido de lectura (en la Parte 1).
  • En cuanto a las estadísticas, usa BigQuery con agrupamiento en clústeres y particiones para minimizar los costos y la duración de las consultas.
  • Para las operaciones de lectura y escritura de milésimas de segundo de un solo dígito, considera usar Bigtable. Habilita la replicación para una alta disponibilidad.
  • Para escrituras en tiempo real en BigQuery, usa la API de transmisión predeterminada desde IO de Apache Beam BigQuery. Con el SDK de Java de Apache Beam, puedes escribir en microlotes a través de Cloud Storage con FILE_LOADS para reducir los costos.
  • En el caso de las operaciones con alto contenido de escritura de menos de 1 milésima de segundo, considera usar un almacén de datos de terceros instalado en Compute Engine o Pub/Sub.

Automatización

Tu canalización de datos puede tener uno de varios flujos sin conexión para hacer lo siguiente:

En cuanto a la administración de fallas y la automatización de extremo a extremo, considera usar Cloud Composer para Apache Airflow. Airflow es la tecnología de código abierto recomendada para administrar flujos de trabajo en Google Cloud. Los DAG se pueden activar de forma manual, mediante un evento, o programarse para ejecutarse de forma recurrente.

Si necesitas una acción más simple impulsada por eventos, puedes activar Cloud Functions en archivos nuevos creados en Cloud Storage o en eventos nuevos publicados en Pub/Sub. Cloud Functions está completamente administrado, lo que elimina la sobrecarga operativa. Para obtener más opciones personalizadas sin servidores, busca información acerca de Knative, un complemento prometedor basado en Kubernetes para compilar, implementar y administrar cargas de trabajo sin servidores.

Estadísticas

BigQuery es nuestro almacén de datos recomendado para el procesamiento estadístico para las consultas ad hoc debido a las siguientes razones:

  • Está totalmente administrado.
  • Proporciona una capa de almacenamiento optimizada y un motor de consulta escalable.
  • Permite consultas ad hoc en terabytes de datos mediante SQL estándar, incluidas las funciones analíticas y las UDF.
  • Ofrece opciones de precios a pedido o a tasa fija para el uso de consultas.
  • Ofrece precios de almacenamiento a largo plazo con una tasa a largo plazo.
  • Proporciona capacidades de aprendizaje automático con BigQuery ML.
  • Cuenta con control de costos y supervisión integrados.

Sugerencias:

Considera usar las vistas autorizadas de BigQuery. Una vista autorizada te permite compartir los resultados de las consultas sin brindar acceso a las tablas subyacentes y también restringir las columnas que los usuarios pueden consultar.

Si estás interesado en migrar desde Hive, considera cargar archivos de Parquet a BigQuery.

Si bien recomendamos usar BigQuery para el procesamiento sin conexión basado en SQL y las estadísticas, Google Cloud también ofrece otras opciones:

  • Para las cargas de trabajo de Hadoop, incluidas Apache Spark, Hive y Pig, considera Dataproc. El conector de Dataproc te permite ejecutar trabajos de Apache Spark y Hadoop en Cloud Storage y ofrece una gran cantidad de beneficios, como alta disponibilidad de datos, interoperabilidad con otros servicios de Google Cloud y compatibilidad con HDFS.
  • Puedes instalar y administrar herramientas de terceros en Compute Engine o Pub/Sub. Además de BigQuery, se suele usar Druid como una base de datos OLAP de baja latencia para los usuarios frontend.

Compilación de capacidades de aprendizaje automático

Procesar eventos no solo se trata de la limpieza y la agregación. Si agregas capacidades de aprendizaje automático a tu canalización de datos, puedes agregar inteligencia, como recomendar mejores anuncios o crear segmentos de usuarios virtuales que se pueden usar como características del modelo. Google Cloud ofrece un rango completo de piezas fundamentales de la IA de aprendizaje automático, incluidas las siguientes:

Con miles de millones de eventos diarios que se recopilan y almacenan en tu data lake o en tu almacén de datos, ya sea Cloud Storage o BigQuery, puedes usar estos datos para entrenar modelos potentes relacionados con las ofertas, por ejemplo:

  • Decidir si hacer una oferta o no
  • Estimar el CTR
  • Optimizar el precio de la oferta
  • Segmentar clientes
  • Calcular los valores del ciclo de vida del cliente (LTV)
  • Recomendar un anuncio para seleccionar

Cuando elijas tu plataforma de aprendizaje automático, debes responder algunas preguntas:

  • ¿Qué tan bien conozco mis datos?
  • ¿Cuántos datos tengo?
  • ¿Cuántos datos se usarán para el entrenamiento?
  • ¿El entrenamiento va a ser en línea o sin conexión?
  • ¿Las predicciones se harán en línea o sin conexión?
  • ¿Puede darse la entrega de forma independiente de la predicción?

El siguiente diagrama muestra un flujo de aprendizaje automático común, con los siguientes pasos:

  1. Limpiar/preparar los conjuntos de datos con BigQuery.
  2. Exportar los conjuntos de datos de entrenamiento y evaluación a Cloud Storage
  3. Entrenar el modelo con AI Platform
  4. Exportar el modelo a Cloud Storage
  5. Cuando se inicializa un trabajador, importar el modelo desde Cloud Storage
  6. Usar el modelo de TensorFlow de forma local para realizar predicciones con baja latencia

Un flujo de aprendizaje automático común

Prepara los datos y la ingeniería de atributos

Antes de que los datos estén listos para ingresar a un modelo de aprendizaje automático, realiza las siguientes tareas:

  1. Explora el conjunto de datos a fin de comprender la idoneidad de los datos para la tarea en cuestión.
  2. Limpia y prepara el conjunto de datos mediante la unión de los datos de varias tablas y el filtrado de los registros no aplicables.
  3. Extrae, construye y selecciona características; crea propiedades informativas y discriminativas de lo que se observa.

BigQuery se adapta bien a estas tareas para datos almacenados en BigQuery y fuentes de datos federadas externas. Puedes usar BigQuery si quieres consultar y explorar los datos antes de exportar tus conjuntos de datos seleccionados y filtrados a Cloud Storage para la ingeniería de atributos.

Sugerencia: Además de usar BigQuery para explorar tus datos, puedes conectar Dataprep a BigQuery a fin de obtener una muestra y crear un perfil visual de tus datos.

La siguiente tarea suele pedirte que evalúes si las predicciones se harán en línea o sin conexión. Es importante que cuando realices predicciones en línea evalúes cómo se extraerán las características desde los datos de solicitud de la predicción:

  • Para las predicciones en línea, debes realizar los mismos pasos de creación de características durante el entrenamiento y la predicción para evitar sesgos. tf.Transform te permite definir estos pasos de procesamiento previo, aprovechar Apache Beam para realizar este trabajo a gran escala durante el entrenamiento y la evaluación, y, también, exportar los pasos como parte de un grafo de TensorFlow a fin de entregar predicciones. Este blog proporciona información adicional importante sobre cómo funciona este proceso.
  • Para las predicciones sin conexión, puedes usar el mismo enfoque durante las fases de entrenamiento y predicción. Podrías usar BigQuery para crear las características como parte de tu procesamiento previo por lotes. Por ejemplo, podrías vectorizar características con una función hash o buscar un valor asociativo a través de una unión.

Entrenamiento y evaluación

Google Cloud ofrece varias opciones para entrenar y evaluar un modelo. Entre ellas, se incluyen las siguientes:

  • Usar AI Platform para ejecutar tareas de entrenamiento y evaluación de XGboost, scikit-learn y TensorFlow en un entorno completamente administrado. AI Platform también proporciona funciones adicionales, como el ajuste automatizado de hiperparámetros y el entrenamiento distribuido.

  • Ejecutar las tareas de entrenamiento y evaluación directamente en instancias de Compute Engine. Tendrás que instalar los paquetes de software que desees. También puedes aprovechar las GPU, TPU o VM interrumpibles cuando sea apropiado para reducir los costos y el tiempo de procesamiento.

  • Usar Kubeflow para instalar y ejecutar TensorFlow y muchas herramientas de aprendizaje automático, como Notebook, en un entorno en contenedores en Kubernetes.

  • Usar BigQuery ML directamente desde la interfaz de SQL para el entrenamiento sin conexión en datos estructurados.

La elección de tu plataforma de AA depende de los siguientes requisitos:

  • Para minimizar los costos, usa Compute Engine con VM interrumpibles.
  • Si necesitas un entorno completamente administrado para el entrenamiento, la implementación y la entrega, usa AI Platform.
  • Para crear entornos de AA extendidos y reproducibles que puedas ejecutar en cualquier clúster de Kubernetes, usa Kubeflow.
  • Cuando tienes datos estructurados, haces predicciones sin conexión y quieres implementar una regresión logística o lineal, usa BigQuery ML.

Predicción

La predicción se realiza sin conexión o en línea con los mismos productos mencionados en la sección de entrenamiento. Compute Engine, Kubeflow y AI Platform pueden usar TensorFlow Serving para realizar predicciones. Las diferencias entre estas opciones son la sobrecarga operativa, las opciones de ajuste y el precio.

Si la baja latencia es un requisito esencial, también puedes usar el modelo serializado o compilado directamente, lo que puede ser útil en las canalizaciones de datos. Consulta Pasos siguientes para ver vínculos adicionales.

Entrega

A veces se considera que la predicción y la entrega son la misma tarea, lo cual es cierto para las predicciones en línea. Sin embargo, si realizas las predicciones sin conexión y luego conservas los resultados en un almacén de datos, deberás entregar las predicciones de este almacenamiento cuando se soliciten.

Entregar predicciones rápidas comprende un equilibrio entre efectividad y eficiencia. Puedes usar diferentes enfoques o una combinación de algunos de ellos. Si decides usar Tensorflow Serving para hacer predicciones en tiempo real, considera usar aceleradores, como GPU o TPU, junto con uno de los siguientes métodos a fin de optimizar tu modelo para la entrega:

  • Cuantización con tf.quantize.
  • Congelar las variables del grafo a constantes.
  • Estructurar tu código para asegurarte de que el código de predicción no contenga ninguna de las sobrecargas usadas en el entrenamiento o las evaluaciones, por ejemplo, el registro de excedentes.
  • Considerar las operaciones fusionadas, como la normalización por lotes fusionada cuando se utiliza una GPU.

Si decides usar predicciones prediseñadas de un almacenamiento rápido de clave-valor, debes crear claves basadas en permutaciones de características. Supongamos que deseas predecir si realizar una oferta o no según el continente y el tipo de dispositivo:

  1. Crea todas las combinaciones posibles de nombres de continentes y móvil/web.
  2. Almacena el resultado de las predicciones para esas combinaciones.

    Clave Predicción
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    Luego, podrás realizar una recuperación rápida de la clave correcta cuando recibas una solicitud. Redis, Aerospike y Bigtable son buenos candidatos para este caso práctico.

Antes de realizar la implementación, ten en cuenta lo siguiente:

  • Si tienes muchas características, el tamaño de la combinación podría ser mayor que el tamaño máximo permitido para una clave.
  • Para admitir un gran número de solicitudes y de claves, considera la distribución de claves y genera un hash de la clave (o parte de ella) si es necesario para evitar hotspots en filas específicas. Bigtable tiene la herramienta Key Visualizer para ayudar a diagnosticar estos problemas.
  • Si no tienes datos categóricos para el valor continuo, debe agruparlos en un depósito. Determinar el tamaño del bucket para cada característica es una tarea en sí misma.
  • Usa incorporaciones para calcular la distancia entre las claves. Si la clave no existe, puedes encontrar el vecino más cercano. Existen diferentes técnicas para crear un hashing sensible a la localidad. Calcular esos hash es una tarea de aprendizaje automático.

Próximos pasos