Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der ADP-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit einfachem Terraform das kleinste realistische ADP-Daten-Substrat bereitgestellt – einen Cloud Storage Landing Bucket, ein BigQuery-Dataset mit einer nach Aufnahmedatum partitionierten Tabelle und eine geplante BigQuery-Abfrage, die stündlich ausgeführt wird, aus einem öffentlichen Dataset liest und in die Tabelle schreibt. Vier Blöcke; der GCP Analytics-Einstieg.
Legen Sie die Snippets in eine einzelne main.tf-Datei, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.your-project-id im Provider-Block.Alles kostenlos im Rahmen dieses Labs:
~$0/Monat bei Lab-Nutzung. Echte BigQuery-Workloads werden nach gescannten Bytes abgerechnet – partitionieren + clustern Sie aggressiv und wählen Sie mit SELECT nur das aus, was Sie benötigen.
Aktivieren Sie Cloud Storage, BigQuery und den BigQuery Data Transfer Service (der geplante Abfragen ermöglicht).
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
}Jede Datenpipeline nach dem ADP-Muster beginnt mit einem Landing Bucket – hier landen Rohdateien (CSV / JSON / Parquet / Avro), und nachgelagerte Jobs lesen daraus. Der Bucket ist die Grenze zwischen „außerhalb des Data Lake“ und „innerhalb des Data Lake“. Die ADP-Prüfung testet hier erneut die Auswahl der Speicherklasse – Standard für die Landing-Ebene (häufige Lesevorgänge in den ersten 30 Tagen), mit einer Lebenszyklusregel, die nach 90 Tagen zu Coldline wechselt.
Der einheitliche Zugriff auf Bucket-Ebene ist aktiviert (die von ADP empfohlene Standardsicherheitseinstellung).
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 ist GCPs serverloses Data Warehouse – Sie zahlen pro gescanntem Byte bei Abfragen und pro gespeichertem Byte für Daten. Die ADP-Prüfung testet Partitionierung + Clustering als Kosteneinsparungsmechanismen: Partitionierte Tabellen ermöglichen es Abfragen, irrelevante Daten zu überspringen; geclusterte Tabellen legen zusammengehörige Zeilen im Speicher nebeneinander ab.
Wir erstellen:
analytics – den BigQuery-Container (das GCP-Äquivalent eines Schemas / einer Datenbank). Setzen Sie delete_contents_on_destroy = true für eine einfachere Bereinigung im Lab.events mit Partitionierung nach Aufnahmezeit (_PARTITIONTIME Pseudospalte) und einer Partitionsablaufzeit von 30 Tagen. Produktionstabellen partitionieren typischerweise nach einer Spalte (time_partitioning.field) für bessere Abfrageselektivität.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
}Geplante Abfragen sind das ADP-Muster-Grundelement für das Einlesen von Daten von einem BigQuery-Dataset in ein anderes in einem festen Rhythmus. Sie werden auf der Infrastruktur des BigQuery Data Transfer Service ausgeführt (getrennt von bq-Ad-hoc-Abfragen) und werden zum gleichen Preis pro gescanntem Byte abgerechnet.
Wir planen eine Abfrage, die stündlich ausgeführt wird, aus dem öffentlichen Dataset bigquery-public-data.samples.shakespeare liest und in die Tabelle events aus Schritt 3 schreibt. Die MERGE-Form (Upsert) ist die ADP-kanonische Antwort für idempotentes Einlesen – ein erneutes Ausführen der gleichen Stunde führt nicht zu doppelten Einfügungen.
Die geplante Abfrage wird als Standard-Dienstkonto des Projekts ausgeführt; in Produktionsumgebungen wird ein dediziertes Transferdienstkonto mit roles/bigquery.dataEditor auf dem Ziel verwendet.
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 reißt alles ab. Der Bucket wird zerstört (nur im Lab force_destroy). Das Dataset wird zerstört (nur im Lab delete_contents_on_destroy) – seine Tabellen verschwinden mit ihm. Die geplante Abfrage wird getrennt und stoppt sofort. Projektdienste bleiben aktiviert (kostenlos).
ADP deckt viele GCP-Datenoberflächen ab, die dieses Lab nicht behandeln kann – Dataflow (im [[gcp-pde]] auf Pro-Ebene behandelt), Dataproc, Pub/Sub, Cloud Composer (verwaltetes Airflow), Dataform (die auf BigQuery basierende SQL-Transformations-IDE), Looker Studio, Vertex AI, Cloud Data Fusion, Database Migration Service, Datastream, die gesamte BigLake / BigQuery Omni Multi-Cloud-Oberfläche und BigQuery ML (In-Database-ML-Training).
Wir beschränken uns auf die Grundelemente GCS + BigQuery + geplante Abfrage, da sie die Basis bilden, von der jede ADP-Muster-Pipeline ausgeht. Dataflow / Dataproc streamen oder batchen Daten in GCS oder BigQuery. Composer / Workflows orchestrieren die oben genannten geplanten Abfragen. Looker liest aus BigQuery. Schaffen Sie die richtige Basis; darauf können Sie spezielle Engines aufsetzen.
Für eine konzeptionelle Abdeckung Dienst für Dienst siehe die Abschnitte Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite.