Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen ADP avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce labo, vous aurez provisionné, avec du Terraform simple, le plus petit substrat de données ADP réaliste — un bucket de destination Cloud Storage, un ensemble de données BigQuery avec une table partitionnée par date d'ingestion, et une requête planifiée BigQuery qui s'exécute toutes les heures, lisant à partir d'un ensemble de données public et écrivant dans la table. Quatre blocs ; le tremplin vers l'analytique GCP.
Déposez les extraits dans un seul fichier main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.your-project-id dans le bloc du fournisseur.Tout est gratuit dans le cadre du labo:
~0 $/mois au volume du labo. Les charges de travail BigQuery réelles sont facturées sur les octets scannés — partitionnez + groupez agressivement et SELECT uniquement ce dont vous avez besoin.
Activez Cloud Storage, BigQuery et BigQuery Data Transfer Service (qui alimente les requêtes planifiées).
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-adp"
managed_by = "terraform"
}
}
resource "google_project_service" "storage" {
service = "storage.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "bigquery" {
service = "bigquery.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "bqdts" {
service = "bigquerydatatransfer.googleapis.com"
disable_on_destroy = false
}Chaque pipeline de données de type ADP commence par un bucket de destination — les fichiers bruts (CSV / JSON / Parquet / Avro) y sont déposés, les jobs en aval les lisent. Le bucket est la limite entre l'extérieur du lac et l'intérieur du lac. L'examen ADP teste ici le choix de la classe de stockage — Standard pour le niveau de destination (lectures fréquentes dans les 30 premiers jours), avec une règle de cycle de vie passant à Coldline après 90 jours.
L'accès uniforme au niveau du bucket est activé (le défaut de sécurité recommandé par ADP).
resource "random_id" "suffix" {
byte_length = 4
}
resource "google_storage_bucket" "landing" {
name = "certlabpro-adp-landing-${random_id.suffix.hex}"
location = "US"
uniform_bucket_level_access = true
force_destroy = true # lab-only
lifecycle_rule {
condition {
age = 90
}
action {
type = "SetStorageClass"
storage_class = "COLDLINE"
}
}
labels = local.labels
depends_on = [google_project_service.storage]
}BigQuery est l'entrepôt de données sans serveur de GCP — paiement à l'octet scanné pour les requêtes, paiement à l'octet stocké pour les données. L'examen ADP teste le partitionnement + le regroupement comme leviers de contrôle des coûts : les tables partitionnées permettent aux requêtes d'ignorer les données non pertinentes ; les tables regroupées (clustered) placent les lignes associées ensemble dans le stockage.
Nous créons :
analytics — le conteneur BigQuery (l'équivalent GCP d'un schéma / d'une base de données). Définissez delete_contents_on_destroy = true pour faciliter le nettoyage du labo.events avec partitionnement par heure d'ingestion (pseudo-colonne _PARTITIONTIME) et expiration de partition après 30 jours. Les tables de production partitionnent généralement par une colonne (time_partitioning.field) pour la sélectivité des requêtes.resource "google_bigquery_dataset" "analytics" {
dataset_id = "analytics"
location = "US"
delete_contents_on_destroy = true # lab-only
labels = local.labels
depends_on = [google_project_service.bigquery]
}
resource "google_bigquery_table" "events" {
dataset_id = google_bigquery_dataset.analytics.dataset_id
table_id = "events"
deletion_protection = false # lab-only
time_partitioning {
type = "DAY"
expiration_ms = 30 * 24 * 60 * 60 * 1000 # 30 days
require_partition_filter = true
}
schema = jsonencode([
{ name = "event_id", type = "STRING", mode = "REQUIRED" },
{ name = "event_type", type = "STRING", mode = "REQUIRED" },
{ name = "event_time", type = "TIMESTAMP", mode = "REQUIRED" },
{ name = "user_id", type = "STRING", mode = "NULLABLE" },
{ name = "payload", type = "JSON", mode = "NULLABLE" },
])
labels = local.labels
}Les requêtes planifiées sont le principe primitif du modèle ADP pour l'ingestion d'un ensemble de données BigQuery vers un autre à une cadence fixe. Elles s'exécutent sur l'infrastructure BigQuery Data Transfer Service (séparée des requêtes ad-hoc bq) et sont facturées au même tarif par octet scanné.
Nous planifions une requête qui s'exécute toutes les heures, lit à partir de l'ensemble de données public bigquery-public-data.samples.shakespeare et écrit dans la table events de l'étape 3. La forme MERGE (upsert) est la réponse canonique d'ADP pour l'ingestion idempotente — réexécuter la même heure n'insère pas deux fois.
La requête planifiée s'exécute en tant que compte de service par défaut du projet ; les déploiements de production utilisent un compte de service de transfert dédié avec roles/bigquery.dataEditor sur la destination.
resource "google_bigquery_data_transfer_config" "hourly_load" {
display_name = "certlabpro-adp-hourly-load"
data_source_id = "scheduled_query"
location = "US"
schedule = "every 1 hours"
destination_dataset_id = google_bigquery_dataset.analytics.dataset_id
params = {
query = "INSERT INTO `${google_bigquery_dataset.analytics.dataset_id}.${google_bigquery_table.events.table_id}` (event_id, event_type, event_time, user_id, payload) SELECT GENERATE_UUID() AS event_id, \"shakespeare-line\" AS event_type, CURRENT_TIMESTAMP() AS event_time, NULL AS user_id, TO_JSON(STRUCT(word, word_count, corpus)) AS payload FROM `bigquery-public-data.samples.shakespeare` WHERE word_count > 100 LIMIT 100"
}
depends_on = [
google_project_service.bqdts,
google_bigquery_table.events,
]
}terraform destroy détruit tout. Le bucket est détruit (force_destroy pour le labo uniquement). L'ensemble de données est détruit (delete_contents_on_destroy pour le labo uniquement) — ses tables disparaissent avec lui. La requête planifiée se détache et cesse de s'exécuter immédiatement. Les services du projet restent activés (gratuitement).
L'ADP couvre de nombreuses surfaces de données GCP que ce labo ne peut pas intégrer — Dataflow (couvert dans [[gcp-pde]] au niveau Pro), Dataproc, Pub/Sub, Cloud Composer (Airflow géré), Dataform (l'IDE de transformation SQL basé sur BigQuery), Looker Studio, Vertex AI, Cloud Data Fusion, Database Migration Service, Datastream, l'ensemble de la surface multi-cloud BigLake / BigQuery Omni, et BigQuery ML (entraînement ML intégré à la base de données).
Nous nous en tenons aux primitives GCS + BigQuery + requête planifiée car elles sont le fondement de tout pipeline de type ADP. Dataflow / Dataproc diffusent ou traitent par lots vers GCS ou BigQuery. Composer / Workflows orchestrent les requêtes planifiées ci-dessus. Looker lit à partir de BigQuery. Maîtrisez la base ; superposez-y des moteurs spécialisés.
Pour la couverture conceptuelle service par service, consultez les sections Parcourir, Guide et Editorial de cette page de certification.