Google PDE: Machine Learning, AI et diffusion de données — Guide d'étude

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Fait partie du Google Professional Data Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

La création de systèmes de machine learning et de service de données de qualité production sur Google Cloud nécessite une modélisation des données rigoureuse, des pipelines robustes et des garde-fous opérationnels. Cette section couvre le développement de modèles dans BigQuery ML, la gestion du cycle de vie sur Vertex AI (jeux de données, entraînement, pipelines, points de terminaison, ingénierie des caractéristiques et surveillance), la conception des chemins de prédiction (batch ou en ligne), les feature stores et l’exactitude à un instant T (point-in-time correctness), l’étiquetage et le contrôle des biais, la recherche vectorielle et les schémas de génération augmentée par récupération (retrieval-augmented generation), la traçabilité (lineage) et la gouvernance, la surveillance de la dérive (drift) et les déclencheurs de réentraînement, les couches de service analytique et l’utilisation des données respectueuse de la vie privée. L’accent est mis sur les décisions de conception, les stratégies de mise à l’échelle et les modes de défaillance courants à éviter.

BigQuery ML et Ingénierie des Caractéristiques (Feature Engineering)

BigQuery ML permet l’entraînement, l’évaluation et la prédiction directement en SQL, ce qui élimine les déplacements de données et aligne le développement des modèles sur les jeux de données analytiques.

Création de modèle : utilisez CREATE MODEL avec des colonnes de label explicites et des transformations de caractéristiques pour éviter la fuite de données (leakage) et standardiser les entrées. Exemple : CREATE OR REPLACE MODEL ds.churn_model OPTIONS( model_type=‘logistic_reg’, input_label_cols=[‘churned’], l1_reg=0.0, l2_reg=1.0, data_split_method=‘AUTO’ ) TRANSFORM( standardize(tenure_months) AS tenure_std, quantile_bucketize(monthly_spend, 10) AS spend_bkt, one_hot_encoder(region) AS region_ohe, ml.feature_cross(struct(bucketize(lat, 60), bucketize(lon, 60))) AS latlon_cross, (xx + yy) AS r2 – ajouter le support de frontières de décision circulaires si utile ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;
Évaluation : utilisez ML.EVALUATE pour obtenir des métriques appropriées au type de modèle (par ex., ROC AUC pour la classification, RMSE pour la régression). Suivez les performances de référence (baselines) et les intervalles de confiance ; conservez les jeux de données d’évaluation dans l’ordre chronologique pour approximer les performances futures. SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);
Prédiction : utilisez ML.PREDICT pour un scoring de type en ligne dans BigQuery, ou exportez les modèles pour les servir ailleurs. Tenez compte des budgets de latence du modèle lorsque vous utilisez BigQuery pour le scoring synchrone ; pour les API à QPS élevé, déployez sur des points de terminaison gérés (managed endpoints). SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);
Transformations de caractéristiques : préférez les fonctions déclaratives de TRANSFORM (standardize, one_hot_encoder, bucketize, quantile_bucketize, ml.feature_cross) pour la reproductibilité et pour lier le prétraitement à l’artefact du modèle. Maintenez les transformations idempotentes et déterministes.

Considérations opérationnelles et modes de défaillance :

Inserts en streaming et fraîcheur des requêtes : le streaming de BigQuery a une cohérence à terme (eventual consistency). Pour les agrégations en temps réel qui doivent inclure des lignes venant d’être écrites, exécutez les requêtes avec un délai qui dépasse la latence mesurée du tampon de streaming. Un point de départ prudent consiste à attendre environ 2 fois le délai de disponibilité moyen observé, ou à concevoir des watermarks et une gestion des données en retard (late-data) dans Dataflow avant leur arrivée dans BigQuery.
Coût et simultanéité : si les limites de simultanéité des slots à la demande (on-demand) deviennent un goulot d’étranglement, passez à des réservations à tarif forfaitaire (flat-rate) ou flexibles et mettez en œuvre une gestion de la charge de travail (hiérarchies et attributions de réservations) pour garantir une capacité prévisible.
Qualité des données : pour les chargements par lots depuis GCS avec des lignes mal formées, utilisez Dataflow pour analyser et valider les enregistrements, en écrivant les lignes correctes dans BigQuery et les mauvaises lignes dans une table de lettres mortes (dead-letter table) pour inspection. Évitez que BigQuery ne rejette des fichiers entiers à cause d’un petit nombre de mauvaises lignes.

Cycle de vie de Vertex AI, chemins de prédiction et magasins de caractéristiques

Vertex AI fournit des services gérés de bout en bout pour l’entraînement, les pipelines, le registre de modèles, les points de terminaison et la surveillance.

Ensembles de données et entraînement : enregistrez les ensembles de données et les métadonnées ; utilisez des tâches d’entraînement personnalisées ou AutoML le cas échéant. Choisissez les algorithmes en fonction des contraintes :
- Les charges de travail sur une seule VM avec des ressources limitées favorisent les modèles simples (par ex., régression linéaire ou régression logistique) en raison de leurs faibles exigences en mémoire/CPU.
- Les tâches à haute dimensionnalité bénéficient souvent de la sélection de caractéristiques ou de la combinaison de caractéristiques redondantes pour accélérer l’entraînement avec une perte de précision minimale.
- La détection d’anomalies non supervisée est appropriée lorsque les exemples positifs sont rares et que les anomalies futures devraient ressembler à des signatures anormales connues.
Pipelines : implémentez Vertex AI Pipelines pour codifier la préparation des données, l’entraînement, l’évaluation et les portes de déploiement. Conservez les paramètres, les SHA de commit de code, les digests de conteneurs et les instantanés d’ensembles de données pour garantir la reproductibilité.
Points de terminaison et prédiction :
- Prédiction en ligne pour les charges de travail à faible latence. Configurez les réplicas minimum et maximum et les politiques d’autoscaling ; profilez la latence du modèle à P95 et définissez les SLO en conséquence. Ajoutez des déploiements canary et une répartition du trafic pour des déploiements sécurisés.
- Prédiction par lots pour les tâches privilégiant le débit (par ex., scoring nocturne). Le traitement par lots évite la surcharge par requête et est moins cher pour de grands volumes, mais offre une latence plus élevée.
Ingénierie des caractéristiques et magasins de caractéristiques : utilisez Vertex AI Feature Store pour :
- Un magasin hors ligne dans BigQuery pour l’entraînement.
- Un magasin en ligne pour les recherches à faible latence par ID d’entité. Assurez la cohérence entre l’entraînement et le service en partageant la même logique de transformation (par ex., bibliothèque Dataflow ou définitions de caractéristiques) et en utilisant des horodatages de caractéristiques pour éviter la fuite de données. Maintenez l’exactitude à un instant T avec des jointures temporelles :

undefined

Compromis de conception :

Latence du magasin en ligne vs. fraîcheur : les magasins en ligne basés sur Bigtable offrent une faible latence ; assurez-vous que les remplissages (backfills) et les mises à jour en flux continu (upserts) sont idempotents. Une asymétrie d’écriture excessive ou des clés surchargées (hot keys) dégradent les performances — concevez les ID d’entité pour répartir uniformément le trafic.
Par lots vs. en ligne : le traitement par lots réduit la complexité et le coût du service, mais peut fournir des prédictions obsolètes. Pour un comportement dynamique (par ex., recommandations), combinez un réentraînement périodique avec des caractéristiques à jour au moment du service.

Qualité des données, étiquetage, biais, confidentialité et gouvernance

Des étiquettes de haute qualité et une gouvernance rigoureuse sont le fondement de modèles fiables.

Étiquetage et déséquilibre :
- Utilisez des directives d’étiquetage claires et un échantillonnage d’assurance qualité. Suivez l’accord inter-annotateurs.
- Traitez le déséquilibre des classes avec un échantillonnage stratifié, une repondération ou un rééchantillonnage ; surveillez la précision/le rappel par classe, et pas seulement la précision globale.
- Conservez intentionnellement les valeurs nulles. Si un modèle nécessite des entrées numériques, encodez les valeurs nulles explicitement (par ex., 0 avec un indicateur “was_null”) et validez l’impact en aval ; évitez de supprimer silencieusement une absence d’information significative.
Surapprentissage et généralisation :
- Les mesures d’atténuation incluent des données d’entraînement plus diversifiées, des ensembles de caractéristiques plus petits et une régularisation plus forte.
- L’arrêt anticipé et la validation croisée sont essentiels pour les réseaux de neurones ; le sous-échantillonnage peut réduire le temps d’entraînement lorsque la mise à l’échelle de l’architecture ou du matériel n’est pas viable.
Gouvernance et lignage :
- Suivez le lignage avec Vertex ML Metadata, Model Registry et Data Catalog. Enregistrez les versions des ensembles de données, les transformations, les hyperparamètres et l’environnement.
- Flux de travail d’approbation : exigez une approbation humaine avant le déploiement, en utilisant les états de Model Registry et Cloud Build/Deploy avec des vérifications de règles. Stockez les artefacts dans Artifact Registry ; signez les conteneurs et appliquez Binary Authorization pour des déploiements contrôlés.
Surveillance, dérive et réentraînement :
- Activez la surveillance des modèles pour la dérive de prédiction, la dérive des caractéristiques et la dégradation des performances. Utilisez des métriques distributionnelles (par ex., PSI, divergence KL) et une évaluation tenant compte du délai de la vérité terrain lorsque les étiquettes arrivent plus tard.
- Établissez des déclencheurs de réentraînement basés sur une dérive statistiquement significative, des violations de SLO ou des fenêtres d’événements métier. Automatisez les pipelines de réentraînement mais contrôlez la promotion avec des évaluations et des vérifications de biais.
- Méfiez-vous de la dérive de données silencieuse provenant de changements de schéma en amont ; appliquez des contrats de schéma et alertez en cas de caractéristiques manquantes ou décalées.
Conception respectueuse de la confidentialité :
- Classifiez les données à l’aide des tags de règles de Data Catalog ; appliquez la sécurité au niveau des colonnes et des lignes dans BigQuery, avec des règles de masquage de données.
- Minimisez la collecte de données ; mettez en œuvre des SLA de conservation et de suppression des données liés à la limitation des finalités.
- Appliquez DLP pour la découverte et la désidentification ; chiffrez les données avec CMEK ; isolez les services avec VPC Service Controls ; assurez un contrôle IAM affiné et utilisez des comptes de service dédiés avec le moindre privilège.
- Pour la surveillance et la journalisation, expurgez les informations personnelles identifiables (PII) et évitez la journalisation de la charge utile (payload) lorsque ce n’est pas nécessaire.

Recherche vectorielle, pipelines RAG et couches de service analytiques

La récupération (retrieval) et le service (serving) modernes nécessitent à la fois des composants natifs pour les vecteurs et des entrepôts analytiques éprouvés.

Recherche vectorielle et embeddings :
- Utilisez Vertex AI Vector Search ou la recherche vectorielle de BigQuery pour la récupération des plus proches voisins à grande échelle et à faible latence ; choisissez AlloyDB pour PostgreSQL avec pgvector pour une sémantique centrée sur l’application et les besoins transactionnels.
- Générez les embeddings par lots avec Vertex Pipelines ; stockez les vecteurs avec des métadonnées denses ; partitionnez et indexez intelligemment (par ex., par domaine de document) pour limiter la latence.
Pipelines de génération augmentée par la récupération (RAG) :
- Ingérez le contenu via Dataflow ou Dataproc, extrayez le texte, segmentez-le, vectorisez-le (embed) et indexez-le dans un magasin de vecteurs. Conservez les références à la source de vérité (source-of-truth) pour la traçabilité.
- Mettez en œuvre des stratégies de fraîcheur des données : ré-embedding périodique, invalidation lors des mises à jour de la source et indexation canary pour valider la qualité avant de remplacer les index.
- Surveillez la qualité de la récupération (taux de réussite, MRR, nDCG) et la sécurité du contenu ; appliquez des garde-fous et des contrôles d’accès pour les données à accès restreint.
Couches de service analytiques et produits de données :
- Organisez des produits de données bronze/silver/gold dans BigQuery ; utilisez le partitionnement et le clustering pour minimiser les coûts de balayage (scan). Les vues matérialisées peuvent accélérer les requêtes courantes.
- Pour des besoins clé-valeur à faible latence ou des compteurs à QPS élevé, utilisez Bigtable avec des clés de ligne bien distribuées ; évitez le hot-spotting en salant ou en hachant les préfixes.
- Pour les charges de travail OLTP et une cohérence forte, utilisez Cloud SQL ou Spanner ; délestez les analyses vers BigQuery via un ELT planifié.
- Architecture de streaming : Pub/Sub → Dataflow → BigQuery/Bigtable avec autoscaling. Surveillez les métriques de backlog et de watermark ; l’autoscaling par défaut suffit pour les charges élastiques tout en maîtrisant les coûts.

Conseil opérationnel :

Pour déclencher des notifications sur des tâches d’insertion spécifiques dans une table BigQuery, exportez les entrées Cloud Logging pertinentes vers Pub/Sub à l’aide d’un filtre avancé, puis connectez des alertes à partir de la souscription :

undefined

Scénario de problème pratique

AcmeStyle, une place de marché de la mode, souhaite maintenir à jour les recommandations sur son site au fur et à mesure que les préférences des utilisateurs changent d’heure en heure. Elle ingère en streaming le comportement de clics et d’achats et doit combiner cela avec le contexte du catalogue pour rafraîchir les recommandations avec une faible latence et des coûts maîtrisés.

Approche :

Ingestion en streaming et portails de qualité

Utiliser Pub/Sub pour l’ingestion d’événements depuis le web et le mobile. Une tâche de streaming Dataflow valide les schémas, enrichit avec les données du catalogue, et écrit :
- Les événements nettoyés dans des tables BigQuery partitionnées (event_date) pour l’analytique et l’entraînement hors ligne.
- Les mises à jour agrégées des caractéristiques utilisateur dans Vertex AI Feature Store (magasin en ligne) avec pour clé user_id. Justification : Pub/Sub découple les producteurs et les consommateurs ; Dataflow fournit une sémantique de traitement unique (exactly-once) avec des upserts idempotents ; BigQuery partitionné gère les coûts et la rétention ; le magasin en ligne permet des recherches en quelques millisecondes.

Définitions des caractéristiques (features) avec correction temporelle (point-in-time)

Définir des caractéristiques telles que le CTR glissant, l’affinité avec la marque et la récence avec un event_time explicite. Matérialiser vers :
- Un magasin hors ligne dans BigQuery pour l’entraînement avec des jointures temporelles contraintes par feature_ts <= label_ts.
- Un magasin en ligne pour le service (serving) avec des TTL pour éviter les valeurs obsolètes. Justification : Des horodatages clairs empêchent la fuite de labels (label leakage) ; des définitions cohérentes entre le hors ligne et le en ligne assurent la parité entre l’entraînement et le service (training-serving parity).