Options d'infrastructure pour les pipelines de données dans le secteur publicitaire (partie 2)

Cet article porte sur les pipelines de données et les tâches de machine learning communes aux différentes plates-formes publicitaires. Il vient compléter l'article Options d'infrastructure pour les charges de travail de diffusion publicitaire (partie 1). Ces deux articles fournissent le contexte nécessaire à la série mentionnée ci-après.

Cet article fait partie de la série suivante :

Pour obtenir une présentation de l'interaction entre ces plates-formes et de la terminologie adtech employée tout au long de cette série, consultez l'article Construire des plates-formes publicitaires (présentation).

Les datastores (voir partie 1) employés dans les pipelines de données sont le magasin de profils utilisateur (uniques), le magasin de contexte (voir partie 1) et le magasin de rapports/tableaux de bord (voir partie 1). Ces datastores sont alimentés par deux sources principales : les événements et les données tierces. Cet article porte sur la gestion des événements. Pour plus d'informations sur les données tierces et leur utilisation en vue d'enrichir les données utilisateur, consultez la section sur l'enrichissement des données (voir partie 4).

Cycle de vie des événements

Le pipeline de données, qui part d'événements bruts pour parvenir à des données utiles, peut être divisé ainsi :

  • Collecte et stockage (ingestion) : via un système de messagerie ou des importations récurrentes de fichiers dans un système de stockage.
  • Traitement : soit par lot, soit par flux pour un traitement en temps réel, lorsque la fraîcheur des données est importante.
  • Exportation (ou chargement) : directement à partir de l'outil de traitement de données ou via un workflow personnalisé. Les destinations sont généralement les magasins mentionnés ci-dessus.

Les événements les plus courants dans l'adtech sont les suivants :

  • Demandes d'annonces et d'enchères : généralement en provenance d'un système externe. Les demandes contiennent des détails qui font partie de l'entrée pour la sélection d'annonces.
  • Impressions : les créations chargées sur une page Web ne sont pas toujours visibles.
  • Impressions facturables : impressions affichées et/ou visibles.
  • Clics : actions qu'un utilisateur peut effectuer en cliquant sur une création.
  • Conversions : actions qu'un utilisateur ciblé effectue sur le site Web de l'annonceur.

Les événements associés aux enchères en temps réel sont traités dans l'article Options d'infrastructure pour les enchères RTB (partie 4).

Collecte

Les événements peuvent être créés par :

  • des instances de demandes d'annonces ou d'enchères : les instances qui reçoivent une demande renvoient soit une URL pour la création, soit une réponse à l'enchère ;
  • des instances de collecteur : instances qui renvoient un pixel invisible pour consigner les impressions et/ou collecter les actions qu'un utilisateur ciblé a effectuées sur une annonce (par exemple, des clics ou des lectures de vidéos) ;
  • Cloud Logging : dans certains cas, cette journalisation peut remplacer les instances de collecteur et les fichiers journaux du serveur.

Les événements peuvent être collectés par :

  • un code personnalisé qui publie l'événement sur un système de messagerie tel que Pub/Sub ou écrit dans un fichier journal local ;
  • des outils tiers ou une fonctionnalité de journalisation native sur votre serveur Web ;
  • un agent Google Cloud Logging qui prend en charge des logiciels tiers sélectionnés et qui s'intègre à Cloud Logging.

Les événements peuvent être ingérés :

  • quasiment en temps réel, lorsque les fichiers journaux sont écrits localement, puis copiés régulièrement sur un espace de stockage partagé, tel que Cloud Storage ou BigQuery Capacitor à des fins de traitement. L'espace de stockage BigQuery est généralement employé si ce traitement implique des requêtes analytiques.
  • en temps réel, lorsque vous vous servez de Cloud Logging ou lorsque les collecteurs écrivent directement dans un système de messagerie ou un datastore à faible latence tel que Pub/Sub, Apache Kafka ou RabbitMQ. Les systèmes de traitement en temps réel utilisent souvent cette option.

Cloud Logging peut faciliter bon nombre de ces tâches, car il peut capturer des données directement à partir de produits Google Cloud tels que Compute Engine ou Google Kubernetes Engine, et même à partir de l'équilibrage de charge HTTP. Cloud Logging peut également exporter des données directement vers BigQuery pour des analyses ad hoc, les insérer en flux continu dans Pub/Sub à des fins d'alerte et de traitement en temps réel, et les exporter par lot vers Cloud Storage à des fins de sauvegarde ou d'analyse fédérée.

Voici quelques exemples illustrant les points précédents et prenant en compte les opérations, le coût et la fraîcheur des données :

Option Coût Coûts opérationnels Fraîcheur des données
Copier les fichiers journaux dans Cloud Storage toutes les X secondes, puis dans BigQuery à l'aide de bq load Aucun coût d'entrée pour Cloud Storage

Aucun coût d'ingestion pour BigQuery

Coûts de stockage BigQuery
Nécessite la gestion des fichiers, des échecs, des tentatives et de la synchronisation Quasiment en temps réel
Copier les fichiers journaux dans Cloud Storage toutes les X secondes, puis dans BigQuery à l'aide de Cloud Functions Aucun coût d'entrée pour Cloud Storage

Aucun coût d'ingestion pour BigQuery

Coût supplémentaire avec Cloud Functions

Coûts de stockage BigQuery
Les fonctions Cloud Functions facilitent la gestion de la charge. La logique doit toujours être codée. Quasiment en temps réel
Utiliser Cloud Logging avec une exportation vers Pub/Sub Coûts de Pub/Sub Faibles Temps réel
Insérer les journaux en flux continu dans Kafka à l'aide d'un démon local Coûts liés au stockage et au calcul nécessaires à l'exécution de Kafka Configuration et gestion de Kafka sauf en cas d'utilisation de l'option gérée par Google Cloud En temps réel ou quasiment selon la configuration de Kafka

Conseil : En cas de collecte des événements à l'aide d'instances de calcul, envisagez toujours d'utiliser des VM préemptives, comme expliqué dans la section sur la plate-forme de calcul, afin de réduire les coûts.

Stockage de données

L'emplacement de stockage des données est influencé par leur format, leur mode d'accès et d'utilisation, ainsi que leur coût de stockage. Si les données ne sont pas structurées ou si un stockage est nécessaire avant leur traitement, envisagez d'utiliser Cloud Storage comme recommandé précédemment. Pour les données structurées, vous devez également prendre en compte les efforts requis pour accéder aux enregistrements. Le schéma suivant peut vous aider à évaluer le modèle d'accès afin de réduire le nombre d'opérations et le coût.

Recommandations pour vous aider à exporter des données

La section Modèles de stockage à lecture intensive (voir partie 1) traite des options employées pour le stockage et la diffusion. Le reste de cette section couvre les datastores analytiques employés à la fois avec le traitement par flux et le traitement par lot.

En cas de traitement par flux, vous traitez les données brutes avant de les stocker. Si vous souhaitez également que les données soient immédiatement disponibles pour des requêtes ad hoc, envisagez de les insérer en flux continu dans BigQuery. Vous pouvez réaliser facilement cette opération à l'aide du modèle Dataflow Pub/Sub vers BigQuery.

En cas de traitement récurrent par lot, vous consolidez les données en les stockant dans un environnement partagé et adaptable. Un modèle courant consiste à déplacer les fichiers journaux de leur emplacement local vers le stockage d'objets à un intervalle de quelques minutes. Les noms de fichiers comportent souvent des préfixes et des suffixes, par exemple : logs_serverABC_timestamp123.txt.

Vous pouvez exécuter vos charges de travail d'analyse sur les systèmes de stockage suivants :

  • Cloud Storage : avec ses classes de stockage Standard, Nearline et Coldline, vous pouvez enregistrer des données à des fins d'accès rapide, de sauvegarde ou d'archivage. Si possible, configurez le stockage standard, qui est l'option recommandée pour les analyses, en tant que bucket régional. Configurez le stockage dans la même région que les ressources de calcul qui traitent les données. Cloud Storage est accessible depuis la plupart des produits Google Cloud, y compris Dataproc, Dataflow, Dataprep by Trifacta et BigQuery.
  • BigQuery : BigQuery n'est pas qu'un puissant moteur de requêtes. Il dispose également de son propre espace de stockage, appelé Capacitor, lequel vous permet de stocker des exaoctets de données. L'espace de stockage BigQuery est accessible à partir de Dataproc, de Dataflow et du moteur de requêtes de BigQuery. Avec le stockage à long terme de BigQuery, vos coûts de stockage baissent d'environ 50 % pour les partitions non modifiées pendant 90 jours.
  • Cloud Bigtable : avec des milliards d'événements collectés chaque jour, Cloud Bigtable est un excellent choix si vous avez besoin d'écritures et de lectures intensives dans un délai de l'ordre de la milliseconde. Il est accessible via l'API HBase et d'autres clients. Cloud Bigtable peut également être employé avec l'écosystème de big data pour les graphiques, les séries temporelles et les analyses.

Voici nos recommandations générales :

  • Stockez les données brutes dans BigQuery en parallèle de tout autre traitement. À partir de là, il est facile de réaliser des cumuls sur une base horaire, quotidienne, hebdomadaire ou mensuelle. Les options de chargement dépendent de vos exigences. Pour en savoir plus, consultez la documentation sur le chargement de données dans BigQuery.
  • Si vous êtes soucieux des coûts, sachez que les données stockées dans Cloud Storage peuvent être chargées gratuitement dans BigQuery, ou à un prix inférieur à celui de l'insertion en flux continu, à l'aide de bq load, de Cloud Functions, de l'API Job ou de requêtes fédérées. Les deux premières options sont soumises à des quotas.
  • Réduisez la durée et les coûts des requêtes grâce aux fonctionnalités de stockage de BigQuery, telles que les partitions et le clustering.

Traitement des événements

Lorsque vous choisissez la technologie avec laquelle créer vos pipelines de traitement, tenez compte des points suivants :

  • Latence : déterminez les données qui doivent être traitées en temps réel. Par exemple, vous devrez peut-être calculer les compteurs de budget aussi rapidement que possible.
  • Exactitude : certaines valeurs (par exemple, les montants de facturation) doivent être calculées avec précision, mais peut-être pas immédiatement.
  • Haute disponibilité : avec des milliards d'entrées de données chaque jour, un temps d'arrêt de quelques minutes peut avoir un impact financier important.
  • Coûts opérationnels : "Garder les lumières allumées" n'est peut-être pas la meilleure façon d'utiliser vos ressources techniques.

Prenons l'exemple suivant :

  • Les journaux d'équilibrage de charge HTTP sont ingérés en temps réel à l'aide de Cloud Logging.
  • Certains journaux doivent être traités immédiatement pour calculer le budget restant.
  • Le nombre d'impressions est agrégé et requis toutes les heures. La limite du nombre d'expositions d'une campagne est quotidienne.

Il est courant que les entreprises emploient l'architecture lambda pour leurs pipelines de traitement de données afin de trouver un équilibre concernant :

  • des approximations rapides, via un pipeline de traitement en temps réel ;
  • l'exactitude, via un pipeline supplémentaire de traitement par lot hors connexion.

Pipeline de traitement de données lambda

Cette section décrit certains des produits Google Cloud avec lesquels vous pouvez mettre en œuvre des architectures de traitement de données lambda et kappa, ainsi que Dataflow :

  • Dataproc (traitement par lot et par flux) : si vous avez déjà des tâches et des scripts Hadoop ou Spark existants, vous pouvez les migrer tels quels vers Dataproc, le service Spark géré par Google Cloud, ou Hadoop.
  • Dataflow (traitement par lot et par flux) : si vous avez de nouvelles charges de travail, si vous envisagez d'utiliser des fonctionnalités avancées d'insertion en flux continu ou si vous souhaitez un modèle de programmation de modèle unifié, Dataflow fournit un service entièrement géré exécutant Apache Beam, qui est mis à disposition en Open Source par Google. Par ailleurs, Dataflow accepte de nombreuses entrées et sorties, comme Pub/Sub et Kafka. Dataflow offre un modèle de programmation unifié pour les données traitées par flux et par lot, qui est compatible avec le traitement "exactement une fois".
  • BigQuery (traitement par lot) : lorsque vous envisagez une approche ELT (extraction, chargement et transformation) ou quand vous effectuez des transformations ultérieures après le chargement des données dans l'entrepôt de données, vous pouvez utiliser BigQuery pour les transformations SQL. Il est géré et fournit également des fonctions définies par l'utilisateur. Pour l'orchestration de ces requêtes, envisagez de faire appel à Cloud Composer, qui est un service Apache Airflow géré.
  • Outils tiers : vous pouvez installer et gérer des outils de l'écosystème Hadoop ou des outils tels que Storm sur Compute Engine ou Google Kubernetes Engine (GKE).

L'architecture ci-dessous décrit une recommandation basée sur les exigences suivantes :

  • Ingestion des événements en temps réel
  • Calcul des compteurs toutes les secondes
  • Cumul du nombre d'impressions toutes les heures
  • Calcul quotidien du taux de clics des annonces

Pipeline de traitement de données utilisant Pub/Sub

Le flux de traitement des données est le suivant :

  1. Les événements sont écrits dans Pub/Sub.
  2. Dataflow écrit les données de niveau événement directement dans BigQuery.
  3. Dataflow divise également les données en intervalles d'une seconde pour effectuer les agrégations requises, et écrit les compteurs dans des instances régionales de Cloud Bigtable.
  4. BigQuery exécute de manière récurrente une requête pour cumuler les données, puis matérialise les résultats. Ces opérations peuvent être planifiées via des tâches Cron ou en utilisant les options de planification Apache Airflow via Cloud Composer.
  5. Les interfaces utilisateur peuvent employer BigQuery comme base de données OLAP. Pour en savoir plus, consultez la section sur la création de rapports (voir partie 1).
  6. Les serveurs publicitaires régionaux interrogent les instances Cloud Bigtable à proximité pour récupérer rapidement les compteurs.

Suivez ces recommandations générales pour créer un pipeline de traitement de données :

  • Servez-vous de Pub/Sub pour réduire les coûts opérationnels, ou envisagez d'exécuter Apache Kafka en tant que service géré sur Google Cloud.
  • Songez à écrire le pipeline avec Apache Beam pour procéder au traitement par lot et par flux via un modèle de programmation unifié.
  • Exécutez Apache Beam sur Dataflow pour bénéficier d'un service entièrement géré capable de procéder à un autoscaling du nombre de nœuds de calcul tout au long de la durée de vie de la tâche, ainsi qu'au rééquilibrage dynamique de la tâche afin de réduire son temps de traitement global.

Si vous souhaitez explorer, nettoyer et préparer des événements ou d'autres données à analyser, envisagez d'utiliser Dataprep. Vous n'avez pas besoin d'écrire de code, et Dataprep vous permet d'exporter des modèles Dataflow, que vous pouvez réutiliser et planifier.

Exportations

Une fois les événements ingérés et traités, les résultats peuvent être exportés vers les destinations suivantes :

  • Des magasins hors connexion tels que BigQuery ou Cloud Storage à des fins de traitement hors connexion, y compris pour les cumuls et les analyses.
  • Des magasins de diffusion tels que Cloud Bigtable, Datastore, Memorystore et des magasins tiers. Les serveurs frontend utilisent ces magasins, par exemple, pour récupérer des informations sur les profils utilisateur et mettre à jour les compteurs lorsque les annonces sont sélectionnées.
  • Des systèmes de messagerie tels que Pub/Sub ou Kafka, lorsque les données nécessitent un traitement en aval supplémentaire ou sont envoyées en tant qu'alerte, par exemple lors de la gestion des budgets.

La réplication de données est un autre cas d'utilisation des exportations. Par exemple, lorsque vous souhaitez que les données soient proches de vos serveurs frontend ou même éventuellement sur les serveurs, il existe deux approches :

  • Dans certains cas, si la technologie pour laquelle vous avez opté le permet, vous pouvez employer des fonctionnalités de réplication native. Des technologies, telles que Redis et Aerospike, sont compatibles avec la réplication dans les régions. Cependant, la réplication interrégionale peut s'avérer plus difficile.
  • D'autres technologies peuvent ne pas accepter la réplication, auquel cas vous pouvez la mettre en œuvre avec un système de messagerie et des processeurs s'exécutant sur Compute Engine ou Pub/Sub.

Le schéma suivant présente différentes approches :

Structure de la réplication de données avec les magasins Google Cloud

Les données sont traitées en temps réel à l'aide de Dataflow et hors connexion à l'aide de BigQuery, après quoi :

  • Dataflow écrit les données directement dans un cluster Redis, à l'aide de l'E/S Redis Apache Beam, qui à son tour réplique les données sur ses nœuds de calcul locaux.
  • Dataflow publie des messages dans Pub/Sub. Les messages sont ensuite lus par un groupe d'abonnés avec autoscaling, déployés sur Compute Engine, qui les écrit ensuite dans un cluster Aerospike exécuté sur Compute Engine.
  • les enregistrements des tâches hors connexion BigQuery, planifiés via Cloud Composer, sont exportés vers les clusters Redis et Aerospike.

Lorsque vous exportez des données, voici nos recommandations :

  • Assurez-vous que le datastore choisi peut gérer à la fois les modèles de lecture et d'écriture. Sinon, envisagez de découpler l'infrastructure de lecture, comme indiqué dans la section sur les modèles de stockage à lecture intensive (voir partie 1).
  • Pour les analyses, utilisez BigQuery avec les fonctionnalités de clustering et de partitionnement afin de réduire les coûts et la durée des requêtes.
  • Pour les lectures et les écritures dans un délai de l'ordre de la milliseconde, envisagez d'utiliser Cloud Bigtable. Activez la réplication pour la haute disponibilité.
  • Pour les écritures en temps réel dans BigQuery, servez-vous de l'API Streaming par défaut de l'E/S BigQuery Apache Beam. Avec le SDK Java Apache Beam, vous pouvez écrire par micro-lots via Cloud Storage en utilisant FILE_LOADS pour réduire les coûts.
  • Pour les écritures intensives inférieures à une milliseconde, envisagez d'employer un datastore tiers installé sur Compute Engine ou Pub/Sub.

Automatisation

Vous pouvez exécuter l'un des flux hors connexion suivants pour le pipeline de données :

  • Copiez les données de cumul BigQuery dans un autre magasin pour obtenir des tableaux de bord OLAP rapides.
  • Copiez les données de diffusion, telles que les segments de clientèle mis à jour, dans Redis, Aerospike ou Cloud Bigtable.
  • Répliquez les données dans des centres de données.
  • Copiez les métadonnées de la base de données de l'interface utilisateur (voir partie 1) dans des magasins pouvant gérer les lectures intensives (voir partie 1).

Pour l'automatisation de bout en bout et la gestion des échecs, envisagez d'utiliser Cloud Composer pour Apache Airflow. Airflow est la technologie Open Source recommandée pour la gestion des workflows sur Google Cloud. Les graphes orientés acycliques peuvent être déclenchés manuellement, par un événement, ou planifiés en vue d'une exécution récurrente.

Si vous avez besoin d'une action plus simple basée sur des événements, vous pouvez déclencher des fonctions Cloud Functions sur les nouveaux fichiers créés sur Cloud Storage ou sur les nouveaux événements publiés dans Pub/Sub. Cloud Functions est entièrement géré, ce qui élimine les coûts opérationnels. Pour en savoir plus sur les options sans serveur personnalisées, n'hésitez pas à vous renseigner sur Knative, un module complémentaire prometteur basé sur Kubernetes permettant de créer, de déployer et de gérer des charges de travail sans serveur.

Analytics

BigQuery est l'entrepôt de données que nous recommandons pour le traitement analytique et les requêtes ad hoc, pour les raisons suivantes :

Conseils :

Envisagez d'utiliser les vues autorisées BigQuery. Une vue autorisée vous permet de partager les résultats d'une requête sans donner accès aux tables sous-jacentes, et de limiter les colonnes que les utilisateurs peuvent interroger.

Si vous souhaitez migrer depuis Hive, envisagez de charger des fichiers Parquet dans BigQuery.

Bien que nous vous recommandions d'utiliser BigQuery pour les analyses et le traitement hors connexion basé sur SQL, Google Cloud propose également d'autres options :

  • Pour les charges de travail Hadoop, y compris Apache Spark, Hive et Pig, envisagez de faire appel à Dataproc. Le connecteur Dataproc vous permet d'exécuter des tâches Apache Spark et Hadoop sur Cloud Storage. En outre, il offre de nombreux avantages, comme la haute disponibilité des données, l'interopérabilité avec d'autres services Google Cloud et la compatibilité HDFS.
  • Vous pouvez installer et gérer des outils tiers sur Compute Engine ou Pub/Sub. Druid est couramment employé en plus de BigQuery comme base de données OLAP à faible latence pour les utilisateurs frontend.

Créer des fonctionnalités de machine learning

Le traitement des événements ne consiste pas seulement en opérations de nettoyage et d'agrégation. L'ajout de fonctionnalités de machine learning au pipeline de données vous permet d'intégrer des informations, telles que la recommandation de meilleures annonces ou la création de segments d'utilisateurs virtuels, pouvant servir de caractéristiques de modèles. Google Cloud propose une gamme complète de composants d'IA pour le machine learning, par exemple :

Avec les milliards d'événements quotidiens collectés et stockés dans votre entrepôt ou lac de données, qu'il s'agisse de Cloud Storage ou de BigQuery, vous pouvez entraîner des modèles puissants liés aux enchères, par exemple pour :

  • décider si vous souhaitez enchérir ou non ;
  • estimer le CTR ;
  • optimiser le prix de l'enchère ;
  • segmenter les clients ;
  • calculer la valeur vie client (LTV) ;
  • recommander une annonce à sélectionner.

Lorsque vous choisissez votre plate-forme de machine learning, vous devez répondre à quelques questions :

  • Dans quelle mesure connaissez-vous vos données ?
  • De quel volume de données disposez-vous ?
  • Quel volume de données servira à l'entraînement ?
  • L'entraînement sera-t-il effectué en ligne ou hors connexion ?
  • Les prédictions seront-elles effectuées en ligne ou hors connexion ?
  • La diffusion peut-elle avoir lieu indépendamment de la prédiction ?

Le schéma suivant illustre un flux de machine learning courant, comprenant les étapes suivantes :

  1. Nettoyer/préparer les ensembles de données avec BigQuery
  2. Exporter les ensembles de données d'entraînement et d'évaluation vers Cloud Storage
  3. Entraîner le modèle à l'aide d'AI Platform
  4. Exporter le modèle vers Cloud Storage
  5. En cas d'initialisation d'un nœud de calcul, importer le modèle à partir de Cloud Storage
  6. Utiliser le modèle TensorFlow localement pour effectuer des prédictions à une faible latence.

Un flux de machine learning courant

Préparer l'extraction de caractéristiques et de données

Pour que les données soient prêtes à être intégrées dans un modèle de machine learning, effectuez les tâches suivantes :

  1. Explorez l'ensemble de données afin de déterminer si les données sont adaptées à la tâche à accomplir.
  2. Nettoyez et préparez l'ensemble de données en associant les données de plusieurs tables et en filtrant les enregistrements non applicables.
  3. Extrayez, élaborez et sélectionnez des caractéristiques pour créer des propriétés informatives et discriminantes de l'élément observé.

BigQuery convient parfaitement à ces tâches pour les données stockées dans BigQuery et pour les sources de données fédérées externes. Vous pouvez utiliser BigQuery pour interroger et explorer les données avant d'exporter les ensembles de données filtrés et sélectionnés vers Cloud Storage à des fins d'extraction des caractéristiques.

Conseil : En plus d'employer BigQuery pour explorer les données, vous pouvez associer Dataprep à BigQuery pour les échantillonner et les profiler visuellement.

La tâche suivante nécessite généralement de déterminer si les prédictions seront effectuées en ligne ou hors connexion. En cas de prédictions en ligne, il est important de prendre en compte la manière dont les caractéristiques seront extraites des données de demande de la prédiction :

  • Pour les prédictions en ligne, vous devez suivre les mêmes étapes de création de caractéristiques pendant l'entraînement et la prédiction afin d'éviter tout décalage. tf.Transform vous permet de définir ces étapes de prétraitement, d'exploiter Apache Beam pour effectuer ce travail à grande échelle pendant l'entraînement et l'évaluation, et également d'exporter les étapes dans le cadre d'un graphe TensorFlow pour diffuser les prédictions. Ce blog fournit d'autres renseignements importants sur le fonctionnement de ce processus.
  • Pour les prédictions hors connexion, vous pouvez utiliser la même approche pendant les phases d'entraînement et de prédiction. Vous pouvez vous servir de BigQuery pour créer les caractéristiques dans le cadre du prétraitement par lot. Par exemple, vous avez la possibilité de vectoriser des caractéristiques à l'aide d'une fonction de hachage ou de rechercher une valeur associative via une jointure.

Entraînement et évaluation

Google Cloud propose différentes options pour entraîner et évaluer un modèle, par exemple :

  • Utilisation d'AI Platform pour exécuter les tâches d'entraînement et d'évaluation XGboost, Scikit-Learn et TensorFlow dans un environnement entièrement géré. AI Platform fournit également des fonctionnalités supplémentaires telles que le réglage automatisé des hyperparamètres et l'entraînement distribué.

  • Exécution des tâches d'entraînement et d'évaluation directement sur les instances Compute Engine. Vous devrez installer les packages logiciels souhaités. Vous pouvez également exploiter des GPU, des TPU ou des VM préemptives, le cas échéant, pour réduire les coûts et le temps de traitement.

  • Utilisation de Kubeflow pour installer et exécuter TensorFlow et de nombreux outils de machine learning, tels qu'un notebook dans un environnement en conteneurs sur Kubernetes.

  • Utilisation de BigQuery ML directement depuis l'interface SQL pour effectuer un entraînement hors connexion sur des données structurées.

Choisissez votre plate-forme de ML en fonction de vos exigences :

  • Pour minimiser les coûts, employez Compute Engine avec des VM préemptives.
  • Si vous avez besoin d'un environnement entièrement géré pour l'entraînement, le déploiement et la diffusion, utilisez AI Platform.
  • Pour créer des environnements de ML étendus et reproductibles que vous pouvez exécuter sur n'importe quel cluster Kubernetes, optez pour Kubeflow.
  • Lorsque vous avez des données structurées, que vous allez effectuer des prédictions hors connexion et que vous souhaitez mettre en œuvre une régression linéaire ou logistique, utilisez BigQuery ML.

Prédiction

Les prédictions sont effectuées soit hors connexion, soit en ligne, à l'aide des mêmes produits que ceux mentionnés dans la section spécifique à l'entraînement. Compute Engine, Kubeflow et AI Platform peuvent tous effectuer des prédictions à l'aide de TensorFlow Serving. Les différences entre ces options sont les coûts opérationnels, les options de réglage et le tarif.

Si une latence faible est une exigence critique, vous pouvez également utiliser directement le modèle sérialisé ou compilé, ce qui peut également être utile dans les pipelines de données. Vous trouverez des liens supplémentaires dans la section Étapes suivantes.

Actif

La prédiction et la diffusion sont parfois considérées comme la même tâche, ce qui est vrai pour les prédictions en ligne. Toutefois, si vous effectuez des prédictions hors connexion, puis conservez les résultats dans un datastore, vous devrez diffuser ces prédictions à mesure qu'elles sont demandées.

La diffusion de prédictions rapides est un compromis entre efficacité et efficience. Vous pouvez recourir à différentes approches ou à une combinaison de certaines d'entre elles. Si vous décidez d'effectuer des prédictions en temps réel à l'aide de TensorFlow Serving, envisagez d'employer des accélérateurs tels que des GPU ou des TPU, et d'optimiser votre modèle pour la diffusion à l'aide de l'une des méthodes suivantes :

  • Procédez à une quantification avec tf.quantize.
  • Figez les variables du graphique en constantes.
  • Structurez le code pour vous assurer que le code de prédiction ne contient aucune des surcharges associées à l'entraînement ou aux évaluations, par exemple une journalisation excessive.
  • Envisagez de réaliser des opérations fusionnées telles que la normalisation par lots fusionnés, en cas d'utilisation d'un GPU.

Si vous décidez d'utiliser des prédictions prédéfinies à partir d'un magasin de valeurs/clés rapide, vous devez créer des clés basées sur les permutations de caractéristiques. Supposons que vous souhaitiez prédire si vous souhaitez faire une enchère ou non en fonction du continent et du type d'appareil :

  1. Créez toutes les combinaisons possibles de noms de continent et d'appareils mobiles/Web.
  2. Stockez le résultat des prédictions pour ces combinaisons.

    Clé Prédiction
    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

    Vous pouvez ensuite effectuer une extraction rapide au niveau de la clé correcte lorsque vous recevez une demande. Redis, Aerospike et Cloud Bigtable se prêtent très bien à ce cas d'utilisation.

Avant de procéder à la mise en œuvre, gardez à l'esprit les points suivants :

  • Si vous disposez de nombreuses caractéristiques, la taille de la combinaison peut être supérieure à la taille maximale autorisée pour une clé.
  • Pour accepter un grand nombre de demandes et de clés, prenez en compte la distribution et le hachage (une partie) de la clé si nécessaire pour éviter tout hotspotting sur des lignes spécifiques. Cloud Bigtable dispose de l'outil Key Visualizer pour aider à diagnostiquer de tels problèmes.
  • Si vous ne possédez pas de données catégoriques pour une telle valeur continue, vous devez les séparer en buckets. Déterminer la taille de bucket de chaque caractéristique est une tâche en soi.
  • Utilisez des représentations vectorielles continues afin de calculer la distance entre les clés. Si la clé n'existe pas, vous pouvez trouver le voisin le plus proche. Il existe différentes techniques permettant de créer un hachage sensible à la localité (LSH, Locality-Sensitive Hashing). Le calcul de ces hachages est une tâche de machine learning.

Étapes suivantes