1. Einführung
Dieses Codelab bietet eine technische Blaupause für Datenexperten. Darin wird ein „Code-First“-Ansatz für Data Governance beschrieben, der zeigt, wie sich robustes Qualitäts- und Metadatenmanagement direkt in den Entwicklungszyklus einbetten lässt. Im Grunde fungiert Knowledge Catalog als intelligente Datenstruktur, mit der Unternehmen Daten in ihrem gesamten Bestand, von Data Lakes bis hin zu Data Warehouses, zentral verwalten, überwachen und steuern können.
In diesem Codelab wird gezeigt, wie Sie mit Knowledge Catalog, BigQuery und der Antigravity-Befehlszeilenschnittstelle komplexe Daten vereinfachen, programmatisch profilieren, intelligente Vorschläge für Datenqualitätsregeln generieren und automatisierte Qualitätsscans bereitstellen können. Das primäre Ziel besteht darin, über manuelle, UI-gesteuerte Prozesse hinauszugehen, die fehleranfällig und schwer zu skalieren sind, und stattdessen ein robustes, versionskontrollierbares „Policy-as-Code“-Framework zu schaffen.
Lerninhalte
- Verschachtelte BigQuery-Daten mit materialisierten Ansichten vereinfachen, um umfassende Profilerstellung zu ermöglichen
- So lassen sich Knowledge Catalog-Profilscans programmatisch mit der Knowledge Catalog Python-Clientbibliothek auslösen und verwalten.
- So exportieren Sie Profildaten und strukturieren sie als Eingabe für ein generatives KI-Modell.
- So erstellen Sie einen Prompt für die Antigravity CLI, um Profildaten zu analysieren und eine Knowledge Catalog-kompatible YAML-Regeldatei zu generieren.
- Die Bedeutung eines interaktiven HITL-Prozesses (Human in the Loop) zur Validierung von KI-generierten Konfigurationen.
- So stellen Sie die generierten Regeln als automatisierten Datenqualitätsscan bereit.
Voraussetzungen
- Ein Google Cloud-Konto und ein Google Cloud-Projekt
- Ein Webbrowser wie Chrome
Schlüsselkonzepte: Die Säulen der Datenqualität in Knowledge Catalog
Es ist wichtig, die Kernkomponenten von Knowledge Catalog zu verstehen, um eine effektive Datenqualitätsstrategie zu entwickeln.
- Datenprofilscan:Ein Knowledge Catalog-Job, mit dem Daten analysiert und statistische Metadaten generiert werden, darunter Nullprozentsätze, Anzahl eindeutiger Werte und Werteverteilungen. Dies dient als unsere programmatische „Discovery“-Phase.
- Regeln zur Datenqualität:Deklarative Anweisungen, die die Bedingungen definieren, die Ihre Daten erfüllen müssen (z.B.
NonNullExpectation,SetExpectation,RangeExpectation). - Generative KI für Regelvorschläge:Ein Large Language Model (wie Gemini) wird verwendet, um ein Datenprofil zu analysieren und relevante Regeln für die Datenqualität vorzuschlagen. Dadurch wird die Definition eines grundlegenden Qualitätsframeworks beschleunigt.
- Datenqualitäts-Scan:Ein Knowledge Catalog-Job, mit dem Daten anhand einer Reihe vordefinierter oder benutzerdefinierter Regeln validiert werden.
- Programmatische Governance:Das zentrale Thema der Verwaltung von Governance-Kontrollen (z. B. Qualitätsregeln) als Code (z. B. in YAML-Dateien und Python-Skripts). Dies ermöglicht die Automatisierung, Versionsverwaltung und Integration in CI/CD-Pipelines.
- Human-in-the-Loop (HITL): Der kritische Kontrollpunkt für die Einbindung menschlichen Fachwissens und menschlicher Aufsicht in einen automatisierten Workflow. Bei KI-generierten Konfigurationen ist HITL unerlässlich, um die Richtigkeit, geschäftliche Relevanz und Sicherheit der Vorschläge vor der Bereitstellung zu validieren.
2. Einrichtung und Anforderungen
Cloud Shell starten
Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:
Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:
Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.
Erforderliche APIs aktivieren und Umgebung konfigurieren
Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist:
export PROJECT_ID=$(gcloud config get-value project)
gcloud config set project $PROJECT_ID
export LOCATION="us-central1"
export BQ_LOCATION="us"
export DATASET_ID="kc_dq_codelab"
export TABLE_ID="ga4_transactions"
gcloud services enable dataplex.googleapis.com \
bigquery.googleapis.com \
serviceusage.googleapis.com \
aiplatform.googleapis.com
In diesem Beispiel verwenden wir us (multiregional) als Standort, da sich die öffentlichen Beispieldaten, die wir verwenden, ebenfalls in us (multiregional) befinden. In BigQuery müssen sich die Quelldaten und die Zieltabelle für eine Abfrage am selben Standort befinden.
Eigenes BigQuery-Dataset erstellen
Erstellen Sie ein neues BigQuery-Dataset, in dem die Beispieldaten und Ergebnisse gespeichert werden.
bq --location=us mk --dataset $PROJECT_ID:$DATASET_ID
Beispieldaten vorbereiten
In diesem Codelab verwenden Sie ein öffentliches Dataset mit verschleierten E‑Commerce-Daten aus dem Google Merchandise Store. Da öffentliche Datasets schreibgeschützt sind, müssen Sie eine veränderbare Kopie in Ihrem eigenen Dataset erstellen. Mit dem folgenden bq-Befehl wird eine neue Tabelle (ga4_transactions) in Ihrem Dataset kc_dq_codelab erstellt. Es werden Daten von einem einzigen Tag (2021-01-31) kopiert, damit die Scans schnell ausgeführt werden.
bq query \
--use_legacy_sql=false \
--destination_table=$PROJECT_ID:$DATASET_ID.$TABLE_ID \
--replace=true \
'SELECT * FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_20210131`'
Demoverzeichnis einrichten
Klonen Sie zuerst ein GitHub-Repository, das die erforderliche Ordnerstruktur und die unterstützenden Dateien für dieses Codelab enthält.
# Perform a shallow clone to get only the latest repository structure without the full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
# Specify and download only the folder we need for this lab
git sparse-checkout set data-analytics/programmatic-dq
cd data-analytics/programmatic-dq
Dieses Verzeichnis ist jetzt Ihr aktiver Arbeitsbereich. Alle nachfolgenden Dateien werden hier erstellt.
3. Automatisierte Datenerkennung mit Knowledge Catalog-Profiling
Die Datenprofilerstellung in Knowledge Catalog ist ein leistungsstarkes Tool, mit dem statistische Informationen zu Ihren Daten automatisch ermittelt werden können, z. B. Nullprozentsätze, Eindeutigkeit und Werteverteilungen. Dieser Prozess ist wichtig, um die Struktur und Qualität Ihrer Daten zu verstehen. Eine bekannte Einschränkung der Profilerstellung für Knowledge Catalog besteht jedoch darin, dass verschachtelte oder wiederholte Felder (z.B. RECORD- oder ARRAY-Typen) in einer Tabelle nicht vollständig untersucht werden können. Sie kann erkennen, dass eine Spalte ein komplexer Typ ist, aber die einzelnen Felder in dieser verschachtelten Struktur nicht analysieren.
Um dieses Problem zu beheben, werden wir die Daten in speziell entwickelten materialisierten Ansichten zusammenführen. Bei dieser Strategie wird jedes Feld zu einer Spalte der obersten Ebene, sodass Knowledge Catalog jedes Feld einzeln analysieren kann.
Verschachteltes Schema
Sehen wir uns zuerst das Schema unserer Quelltabelle an. Das Google Analytics 4-Dataset (GA4) enthält mehrere verschachtelte und wiederkehrende Spalten. Wenn Sie das vollständige Schema, einschließlich aller verschachtelten Strukturen, programmatisch abrufen möchten, können Sie den Befehl „bq show“ verwenden und die Ausgabe als JSON-Datei speichern.
bq show --schema --format=json $PROJECT_ID:$DATASET_ID.$TABLE_ID > bq_schema.json
Bei der Untersuchung der bq_schema.json-Datei werden komplexe Strukturen wie Gerät, geografische Einheit, E-Commerce und wiederholte Datensatzelemente sichtbar. Dies sind die Strukturen, die für ein effektives Profiling vereinfacht werden müssen.
Daten mit materialisierten Ansichten zusammenführen
Das Erstellen von materialisierten Sichten (MVs) ist die effektivste und praktischste Lösung für diese Herausforderung mit verschachtelten Daten. Durch die Vorberechnung der zusammengefassten Ergebnisse bieten materialisierte Sichten erhebliche Vorteile in Bezug auf Abfrageleistung und Kosten. Gleichzeitig bieten sie eine einfachere, beziehungsähnliche Struktur für Analysten und Profiling-Tools.
Der erste Gedanke ist vielleicht, alles in einer einzigen, riesigen Ansicht zusammenzufassen. Dieser intuitive Ansatz birgt jedoch eine gefährliche Falle, die zu schwerwiegenden Datenbeschädigungen führen kann. Sehen wir uns an, warum das ein kritischer Fehler ist.
mv_ga4_user_session_flat.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_user_session_flat`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, event_name, user_pseudo_id, user_id, stream_id, platform,
device.category AS device_category,
device.operating_system AS device_os,
device.operating_system_version AS device_os_version,
device.language AS device_language,
device.web_info.browser AS device_browser,
geo.continent AS geo_continent,
geo.country AS geo_country,
geo.region AS geo_region,
geo.city AS geo_city,
traffic_source.name AS traffic_source_name,
traffic_source.medium AS traffic_source_medium,
traffic_source.source AS traffic_source_source
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`;
mv_ga4_ecommerce_transactions.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_transactions`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, user_pseudo_id, ecommerce.transaction_id,
ecommerce.total_item_quantity,
ecommerce.purchase_revenue_in_usd,
ecommerce.purchase_revenue,
ecommerce.refund_value_in_usd,
ecommerce.refund_value,
ecommerce.shipping_value_in_usd,
ecommerce.shipping_value,
ecommerce.tax_value_in_usd,
ecommerce.tax_value,
ecommerce.unique_items
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`
WHERE
ecommerce.transaction_id IS NOT NULL;
mv_ga4_ecommerce_items.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_items`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 30
) AS
SELECT
event_date, event_timestamp, event_name, user_pseudo_id, ecommerce.transaction_id,
item.item_id,
item.item_name,
item.item_brand,
item.item_variant,
item.item_category,
item.item_category2,
item.item_category3,
item.item_category4,
item.item_category5,
item.price_in_usd,
item.price,
item.quantity,
item.item_revenue_in_usd,
item.item_revenue,
item.coupon,
item.affiliation,
item.item_list_name,
item.promotion_name
FROM
`$PROJECT_ID.$DATASET_ID.ga4_transactions`,
UNNEST(items) AS item
WHERE
ecommerce.transaction_id IS NOT NULL;
Führen Sie diese Vorlagen jetzt mit dem bq-Befehlszeilentool aus. Mit dem Befehl envsubst wird jede Datei gelesen, die Variablen wie $PROJECT_ID und $DATASET_ID werden durch ihre Werte aus Ihrer Shell-Umgebung ersetzt und der endgültige, gültige SQL-Code wird an den Befehl „bq query“ weitergeleitet.
envsubst < mv_ga4_user_session_flat.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_transactions.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_items.sql | bq query --use_legacy_sql=false
Profilscans über den Python-Client ausführen
Nachdem wir unsere zusammengeführten, profilierbaren Ansichten haben, können wir für jede Ansicht programmatisch Knowledge Catalog-Datenprofilscans erstellen und ausführen. Das folgende Python-Skript verwendet die google-cloud-dataplex-Clientbibliothek, um diesen Vorgang zu automatisieren.
Bevor Sie das Skript ausführen, sollten Sie unbedingt eine isolierte Python-Umgebung in Ihrem Projektverzeichnis erstellen. So werden die Abhängigkeiten des Projekts separat verwaltet und Konflikte mit anderen Paketen in Ihrer Cloud Shell-Umgebung vermieden.
# Create the virtual environment
python3 -m venv dq_venv
# Activate the environment
source dq_venv/bin/activate
Installieren Sie nun die Knowledge Catalog-Clientbibliothek in der neu aktivierten Umgebung.
# Install the Knowledge Catalog client library
pip install google-cloud-dataplex
Nachdem Sie die Umgebung eingerichtet und die Bibliothek installiert haben, können Sie das Orchestrierungsskript erstellen.
Klicken Sie in der Cloud Shell-Symbolleiste auf „Editor öffnen“. Erstellen Sie eine neue Datei mit dem Namen 1_run_scan.py und fügen Sie den folgenden Python-Code ein. Wenn Sie das GitHub-Repository klonen, ist diese Datei bereits in Ihrem Ordner enthalten.
Mit diesem Skript wird für jede materialisierte Ansicht ein Scan erstellt (sofern noch nicht vorhanden), der Scan wird ausgeführt und dann wird so lange abgefragt, bis alle Scanjobs abgeschlossen sind.
import os
import sys
import time
from google.cloud import dataplex_v1
from google.api_core.exceptions import AlreadyExists
def create_and_run_scan(
client: dataplex_v1.DataScanServiceClient,
project_id: str,
location: str,
data_scan_id: str,
target_resource: str,
) -> dataplex_v1.DataScanJob | None:
"""
Creates and runs a single data profile scan.
Returns the executed Job object without waiting for completion.
"""
parent = client.data_scan_path(project_id, location, data_scan_id).rsplit('/', 2)[0]
scan_path = client.data_scan_path(project_id, location, data_scan_id)
# 1. Create Data Scan (skips if it already exists)
try:
data_scan = dataplex_v1.DataScan()
data_scan.data.resource = target_resource
data_scan.data_profile_spec = dataplex_v1.DataProfileSpec()
print(f"[INFO] Creating data scan '{data_scan_id}'...")
client.create_data_scan(
parent=parent,
data_scan=data_scan,
data_scan_id=data_scan_id
).result() # Wait for creation to complete
print(f"[SUCCESS] Data scan '{data_scan_id}' created.")
except AlreadyExists:
print(f"[INFO] Data scan '{data_scan_id}' already exists. Skipping creation.")
except Exception as e:
print(f"[ERROR] Error creating data scan '{data_scan_id}': {e}")
return None
# 2. Run Data Scan
try:
print(f"[INFO] Running data scan '{data_scan_id}'...")
run_response = client.run_data_scan(name=scan_path)
print(f"[SUCCESS] Job started for '{data_scan_id}'. Job ID: {run_response.job.name.split('/')[-1]}")
return run_response.job
except Exception as e:
print(f"[ERROR] Error running data scan '{data_scan_id}': {e}")
return None
def main():
"""Main execution function"""
# --- Load configuration from environment variables ---
PROJECT_ID = os.environ.get("PROJECT_ID")
LOCATION = os.environ.get("LOCATION")
DATASET_ID = os.environ.get("DATASET_ID")
if not all([PROJECT_ID, LOCATION, DATASET_ID]):
print("[ERROR] One or more required environment variables are not set.")
print("Please ensure PROJECT_ID, LOCATION, and DATASET_ID are exported in your shell.")
sys.exit(1)
print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}, Dataset: {DATASET_ID}")
# List of Materialized Views to profile
TARGET_VIEWS = [
"mv_ga4_user_session_flat",
"mv_ga4_ecommerce_transactions",
"mv_ga4_ecommerce_items"
]
# ----------------------------------------------------
client = dataplex_v1.DataScanServiceClient()
running_jobs = []
# 1. Create and run jobs for all target views
print("\n--- Starting Data Profiling Job Creation and Execution ---")
for view_name in TARGET_VIEWS:
data_scan_id = f"profile-scan-{view_name.replace('_', '-')}"
target_resource = f"//bigquery.googleapis.com/projects/{PROJECT_ID}/datasets/{DATASET_ID}/tables/{view_name}"
job = create_and_run_scan(client, PROJECT_ID, LOCATION, data_scan_id, target_resource)
if job:
running_jobs.append(job)
print("-------------------------------------------------------\n")
if not running_jobs:
print("[ERROR] No jobs were started. Exiting.")
return
# 2. Poll for all jobs to complete
print("--- Monitoring job completion status (checking every 30 seconds) ---")
completed_jobs = {}
while running_jobs:
jobs_to_poll_next = []
print(f"\n[STATUS] Checking status for {len(running_jobs)} running jobs...")
for job in running_jobs:
job_id_short = job.name.split('/')[-1][:13]
try:
updated_job = client.get_data_scan_job(name=job.name)
state = updated_job.state
if state in (dataplex_v1.DataScanJob.State.RUNNING, dataplex_v1.DataScanJob.State.PENDING, dataplex_v1.DataScanJob.State.CANCELING):
print(f" - Job {job_id_short}... Status: {state.name}")
jobs_to_poll_next.append(updated_job)
else:
print(f" - Job {job_id_short}... Status: {state.name} (Complete)")
completed_jobs[job.name] = updated_job
except Exception as e:
print(f"[ERROR] Could not check status for job {job_id_short}: {e}")
running_jobs = jobs_to_poll_next
if running_jobs:
time.sleep(30)
# 3. Print final results
print("\n--------------------------------------------------")
print("[SUCCESS] All data profiling jobs have completed.")
print("\nFinal Job Status Summary:")
for job_name, job in completed_jobs.items():
job_id_short = job_name.split('/')[-1][:13]
print(f" - Job {job_id_short}: {job.state.name}")
if job.state == dataplex_v1.DataScanJob.State.FAILED:
print(f" - Failure Message: {job.message}")
print("\nNext step: Analyze the profile results and generate quality rules.")
if __name__ == "__main__":
main()
Führen Sie das Skript nun über das Cloud Shell-Terminal aus.
python 1_run_scan.py
Das Profiling Ihrer drei materialisierten Ansichten wird nun vom Skript orchestriert. Sie erhalten Statusaktualisierungen in Echtzeit. Anschließend haben Sie für jede Ansicht ein umfangreiches, maschinenlesbares statistisches Profil, das für die nächste Phase unseres Workflows bereit ist: die KI-basierte Generierung von Datenqualitätsregeln.
Sie können sich die abgeschlossenen Profilscans in der Google Cloud Console ansehen.
- Rufen Sie im Navigationsmenü im Bereich Verwalten die Seiten Knowledge Catalog und Datenprofilerstellung und ‑qualität auf.
- Sie sollten die drei Profilscans zusammen mit dem aktuellen Jobstatus sehen. Klicken Sie auf einen Scan, um die detaillierten Ergebnisse aufzurufen.
Vom BigQuery-Profil zur KI-fähigen Eingabe
Die Knowledge Catalog-Profilscans wurden erfolgreich ausgeführt. Die Ergebnisse sind zwar in der Knowledge Catalog API verfügbar, aber um sie als Eingabe für ein generatives KI-Modell zu verwenden, müssen wir sie in eine strukturierte, lokale Datei extrahieren.
Das folgende Python-Skript 2_dq_profile_save.py sucht programmatisch nach dem letzten erfolgreichen Profilscanjob für unsere Ansicht mv_ga4_user_session_flat. Anschließend wird das vollständige, detaillierte Profilergebnis abgerufen und als lokale JSON-Datei mit dem Namen dq_profile_results.json gespeichert. Diese Datei dient im nächsten Schritt als direkte Eingabe für unsere KI-Analyse.
Erstellen Sie im Cloud Shell-Editor eine neue Datei mit dem Namen 2_dq_profile_save.py und fügen Sie den folgenden Code ein. Wie im vorherigen Schritt können Sie das Erstellen einer Datei überspringen, wenn Sie das Repository geklont haben.
import os
import sys
import json
from google.cloud import dataplex_v1
from google.api_core.exceptions import NotFound
from google.protobuf.json_format import MessageToDict
# --- Configuration ---
# The Materialized View to analyze is fixed for this step.
TARGET_VIEW = "mv_ga4_user_session_flat"
OUTPUT_FILENAME = "dq_profile_results.json"
def save_to_json_file(content: dict, filename: str):
"""Saves the given dictionary content to a JSON file."""
try:
with open(filename, "w", encoding="utf-8") as f:
# Use indent=2 for a readable, "pretty-printed" JSON file.
json.dump(content, f, indent=2, ensure_ascii=False)
print(f"\n[SUCCESS] Profile results were saved to '{filename}'.")
except (IOError, TypeError) as e:
print(f"[ERROR] An error occurred while saving the file: {e}")
def get_latest_successful_job(
client: dataplex_v1.DataScanServiceClient,
project_id: str,
location: str,
data_scan_id: str
) -> dataplex_v1.DataScanJob | None:
"""Finds and returns the most recently succeeded job for a given data scan."""
scan_path = client.data_scan_path(project_id, location, data_scan_id)
print(f"\n[INFO] Looking for the latest successful job for scan '{data_scan_id}'...")
try:
# List all jobs for the specified scan, which are ordered most-recent first.
jobs_pager = client.list_data_scan_jobs(parent=scan_path)
# Iterate through jobs to find the first one that succeeded.
for job in jobs_pager:
if job.state == dataplex_v1.DataScanJob.State.SUCCEEDED:
return job
# If no successful job is found after checking all pages.
return None
except NotFound:
print(f"[WARN] No scan history found for '{data_scan_id}'.")
return None
def main():
"""Main execution function."""
# --- Load configuration from environment variables ---
PROJECT_ID = os.environ.get("PROJECT_ID")
LOCATION = os.environ.get("LOCATION")
if not all([PROJECT_ID, LOCATION]):
print("[ERROR] Required environment variables PROJECT_ID or LOCATION are not set.")
sys.exit(1)
print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}")
print(f"--- Starting Profile Retrieval for: {TARGET_VIEW} ---")
# Construct the data_scan_id based on the target view name.
data_scan_id = f"profile-scan-{TARGET_VIEW.replace('_', '-')}"
# 1. Initialize client and get the latest successful job.
client = dataplex_v1.DataScanServiceClient()
latest_job = get_latest_successful_job(client, PROJECT_ID, LOCATION, data_scan_id)
if not latest_job:
print(f"\n[ERROR] No successful job record was found for '{data_scan_id}'.")
print("Please ensure the '1_run_scan.py' script has completed successfully.")
return
job_id_short = latest_job.name.split('/')[-1]
print(f"[SUCCESS] Found the latest successful job: '{job_id_short}'.")
# 2. Fetch the full, detailed profile result for the job.
print(f"[INFO] Retrieving detailed profile results for job '{job_id_short}'...")
try:
request = dataplex_v1.GetDataScanJobRequest(
name=latest_job.name,
view=dataplex_v1.GetDataScanJobRequest.DataScanJobView.FULL,
)
job_with_full_results = client.get_data_scan_job(request=request)
except Exception as e:
print(f"[ERROR] Failed to retrieve detailed job results: {e}")
return
# 3. Convert the profile result to a dictionary and save it to a JSON file.
if job_with_full_results.data_profile_result:
profile_dict = MessageToDict(job_with_full_results.data_profile_result._pb)
save_to_json_file(profile_dict, OUTPUT_FILENAME)
else:
print("[WARN] The job completed, but no data profile result was found within it.")
print("\n[INFO] Script finished successfully.")
if __name__ == "__main__":
main()
Führen Sie das Script jetzt über das Terminal aus:
python 2_dq_profile_save.py
Nach erfolgreichem Abschluss haben Sie eine neue Datei mit dem Namen dq_profile_results.json in Ihrem Verzeichnis. Diese Datei enthält die umfangreichen, detaillierten statistischen Metadaten, die wir zum Generieren von Datenqualitätsregeln verwenden. Wenn Sie den Inhalt von dq_profile_results.json prüfen möchten, führen Sie den folgenden Befehl aus:
cat dq_profile_results.json
4. Regeln für Datenqualität mit der Antigravity-Befehlszeile generieren
Jetzt können Sie die Antigravity CLI (agy) verwenden, um die Ergebnisse des lokalen Profilscans zu lesen. Das manuelle Erstellen von Spezifikationen für die Datenqualität für komplexe Datasets ist zeitaufwendig und fehleranfällig. Wenn Sie einen KI-Agenten für generative KI in Ihrem Terminal verwenden, wird dieser Workflow beschleunigt, da in Sekundenschnelle eine erste deklarative Konfiguration erstellt wird. So können sich Datenteams von der manuellen Syntaxerstellung auf die HITL-Aufsicht (Human-in-the-Loop) auf hoher Ebene konzentrieren, die auf die geschäftlichen Anforderungen abgestimmt ist.
Führen Sie den folgenden Befehl in Ihrem Terminal aus, um die Antigravity CLI zu starten:
agy
Jetzt können Sie Qualitätsregeln generieren. Da die CLI Dateien in Ihrem aktuellen Verzeichnis lesen kann, kann sie Ihre neuen Profilscandaten direkt verwenden.
KI‑Agenten auffordern, einen Plan zu erstellen
Zuerst bitten wir den Antigravity-Agenten, das statistische Profil zu analysieren und einen Aktionsplan vorzuschlagen. Wir weisen sie explizit an, die YAML-Datei noch nicht zu schreiben. Der Fokus liegt hier auf der Analyse und Begründung.
Geben Sie in Ihrer interaktiven Antigravity CLI-Sitzung den folgenden strukturierten Prompt ein:
# Context
You are preparing a data quality rule configuration plan for Google Cloud Knowledge Catalog based on data profile statistics.
# Input
- File Path: `./dq_profile_results.json` (contains metrics like null percentage, distinct counts, and distributions)
# Task
Analyze the input statistics and propose a step-by-step plan for establishing automated data quality rules.
*Do not write any YAML code in this step.* Focus only on analytical planning.
# Rule Mapping Strategy
For candidate columns, match the statistical metrics to the most appropriate expectations:
- `nonNullExpectation`: Propose for columns with 0% null values in the profile.
- `setExpectation`: Propose for columns with a highly limited, stable set of categorical values.
- `rangeExpectation`: Propose for numeric columns with consistent and predictable value boundaries.
# Guidelines
- Provide a metric-based justification for each proposed rule (e.g., "Recommend `nonNullExpectation` for column 'user_pseudo_id' because its null percentage is 0%").
- Flag volatile metrics such as hardcoded row counts that could cause false-positive alerts in production.
# Output Format
Provide your analysis and proposed rules as a structured, step-by-step markdown plan with clear headings.
Der KI-Agent analysiert die JSON-Datei und gibt einen strukturierten Plan zurück, der in etwa so aussieht:
Automated Data Quality Rule Configuration Plan
Google Cloud Knowledge Catalog (Dataplex Data Quality)
──────
## Executive Summary
This analytical planning document outlines a step-by-step strategy for configuring automated data quality (DQ) rules in Google Cloud Knowledge Catalog (formerly Dataplex Data Quality) based on profiling statistics.
The dataset contains 26,489 rows representing GA4 event logs. Based on statistical metrics (null ratios, distinct value distributions, and data types), candidate columns are mapped to appropriate expectation rules.
──────
## 1. Data Profile Overview & Statistical Highlights
Column Name │ Data Type │ Null Ratio │ Distinct Count │ Key Value Range / Categories
─────────────────┼───────────┼────────────────┼────────────────┼──────────────────────────────────────────────────
event_date │ STRING │ 0.0% (0) │ 1 (3.78e-05) │ "20210131" (100%)
event_timestamp │ INTEGER │ 0.0% (0) │ ~16,539 (0.62) │ Min: 1612051200657906, Max: 1612137595412363
event_name │ STRING │ 0.0% (0) │ 16 (0.0006) │ page_view (35.8%), user_engagement (18.9%), etc.
user_pseudo_id │ STRING │ 0.0% (0) │ ~2,545 (0.09) │ 18–21 characters string identifiers
user_id │ STRING │ 100.0% (1.0) │ 0 (0.0) │ Entirely NULL
device_category │ STRING │ 0.0% (0) │ 3 (0.0001) │ desktop (57.5%), mobile (40.1%), tablet (2.4%)
... │ ... │ ... │ ... │ ...
──────
## 2. Rule Mapping Strategy & Analytical Justifications
### Step 1: Nullability Rules (nonNullExpectation)
Propose nonNullExpectation for mandatory columns where the data profile demonstrates 0% null values.
• user_pseudo_id, event_timestamp, event_name, event_date, stream_id, platform, device_category (Metric Justification: nullRatio is 0.0%)
│ [!NOTE] Exclusions:
│ • user_id: Has a nullRatio of 100.0% (unauthenticated traffic).
│ • device_language: Has a nullRatio of 37.53%.
──────
### Step 2: Categorical Value Set Validation (setExpectation)
Propose setExpectation for columns with a highly limited, stable set of categorical domain values.
• device_category: Distinct count is exactly 3. Allowed set: ['desktop', 'mobile', 'tablet']
• platform: Distinct count is 1. Allowed set expanded to: ['WEB', 'ANDROID', 'IOS'] to avoid over-fitting.
• geo_continent: Distinct count is 6. Allowed set: ['Americas', 'Asia', 'Europe', 'Africa', 'Oceania', 'Antarctica', '(not set)']
──────
### Step 3: Numeric & Timestamp Boundary Validation (rangeExpectation)
Propose rangeExpectation for numeric columns with consistent and predictable value boundaries.
• event_timestamp: rangeExpectation requiring event_timestamp > 0 (avoid dynamic microsecond range hardcoding)
• stream_id: rangeExpectation requiring positive integer stream IDs (stream_id > 0)
──────
## 3. Risk Warning: Volatile Metrics & Production False Positives
│ [!WARNING] Volatile Metrics Flagged for Risk Mitigation:
1. Hardcoded Total Row Count (rowCount = 26,489) -> Daily event volume fluctuates. Use dynamic volume thresholds.
2. Hardcoded Partition Date (event_date = '20210131') -> Breaks on future runs. Validate against YYYYMMDD regex patterns.
3. Exact Timestamp Range Bounds -> Enforcing these microsecond limits on incoming live pipelines will reject all future data.
4. Single-Value Domain Restrictions -> Single profile sample might lack active streams. Set sets according to enterprise schema.
──────
## Summary Table of Proposed Rules
Target Column │ Rule Type │ Metric-Based Justification │ Operational Considerations
─────────────────┼────────────────────┼────────────────────────────┼──────────────────────────────────────────────────
user_pseudo_id │ nonNullExpectation │ Null Ratio: 0.0% │ Core identifier, strictly required
event_timestamp │ nonNullExpectation │ Null Ratio: 0.0% │ Temporal key, strictly required
event_timestamp │ rangeExpectation │ Min: > 0 (Microseconds) │ Avoid hardcoding epoch min/max
event_name │ nonNullExpectation │ Null Ratio: 0.0% │ Required event taxonomy key
event_name │ setExpectation │ Categorical distribution │ Map to standard GA4 event taxonomy
device_category │ nonNullExpectation │ Null Ratio: 0.0% │ Required form-factor dimension
device_category │ setExpectation │ Distinct Count: 3 values │ ['desktop', 'mobile', 'tablet']
... │ ... │ ... │ ...
Datenqualitätsregeln generieren
Dies ist der wichtigste Schritt im gesamten Workflow: die Human-in-the-Loop-Prüfung (HITL). Der vom Agent generierte Plan basiert ausschließlich auf statistischen Mustern in den Daten. Es berücksichtigt weder Ihren geschäftlichen Kontext noch zukünftige Datenänderungen oder die spezifische Intention hinter Ihren Daten. Ihre Rolle als menschlicher Experte besteht darin, diesen Plan zu validieren, zu korrigieren und zu genehmigen, bevor er in Code umgewandelt wird.
Sehen Sie sich den Plan, den der Kundenservicemitarbeiter bereitgestellt hat, genau an.
- Ist das verständlich?
- Passt es zu Ihrem geschäftlichen Know-how?
- Gibt es statistisch fundierte, aber praktisch nutzlose Regeln?
Die Ausgabe, die Sie vom Agent erhalten, kann variieren. Ihr Ziel ist es, sie zu optimieren. Angenommen, im Plan wird eine rowCount-Regel vorgeschlagen, weil die Tabelle in den Beispieldaten eine feste Anzahl von Zeilen hat. Als menschlicher Experte wissen Sie vielleicht, dass die Größe dieser Tabelle voraussichtlich täglich zunimmt. Eine strenge Regel für die Zeilenanzahl ist daher unpraktisch und führt wahrscheinlich zu falschen Benachrichtigungen. Das ist ein perfektes Beispiel dafür, wie Sie Geschäftskontext anwenden, der der KI fehlt.
Jetzt geben Sie dem Agent Feedback und den endgültigen Befehl zum Generieren des Codes. Sie müssen den folgenden Prompt an das tatsächlich erhaltene Konzept und die gewünschten Korrekturen anpassen.
Der Prompt unten ist eine Vorlage. In der ersten Zeile geben Sie Ihre konkreten Korrekturen an. Wenn der Plan, den der Kundenservicemitarbeiter Ihnen gegeben hat, perfekt ist und keine Änderungen erforderlich sind, können Sie diese Zeile einfach löschen.
Geben Sie in derselben Antigravity-Sitzung Ihre angepasste Version des folgenden Prompts ein:
# Feedback & Approvals
[YOUR CORRECTIONS AND APPROVAL GO HERE. Examples:
- "The plan looks good. Please proceed."
- "The rowCount rule is not necessary, as the table size changes daily. The rest of the plan is approved. Please proceed."
- "For the setExpectation on the geo_continent column, please also include 'Antarctica'."]
# Objective
Based on the approved analysis plan and the provided feedback, generate the final `dq_rules.yaml` file conforming to the standard `DataQualityRule` schema.
# Instructions
1. **Rule Justifications**: For every generated rule, add a YAML comment (`#`) on the line directly above it, briefly explaining the justification established in the plan.
2. **Schema Alignment**: Ensure the structure strictly adheres to the required Knowledge Catalog data quality scan specification. Refer to the `sample_rule.yaml` file in the current directory and the `DataQualityRule` class definition in the local virtual environment path (`./dq_venv/.../google/cloud/dataplex_v1/types/data_quality.py`) as the schema authority.
3. **Data-Driven Values**: Derive all rule parameters, such as thresholds or expected values, directly from the statistical metrics in `dq_profile_results.json`.
# Constraints
- **Output Purity**: Return ONLY the raw, valid, and properly formatted YAML code block.
- Do not include conversational preambles, introductory sentences, explanations, or markdown blocks around the YAML.
Der Agent generiert nun den YAML-Inhalt basierend auf Ihren präzisen, von Menschen validierten Anweisungen. Nach Abschluss finden Sie in Ihrem Arbeitsverzeichnis eine neue Datei mit dem Namen dq_rules.yaml.
Datenqualitätsscan erstellen und ausführen
Nachdem Sie nun eine vom Agent generierte und von einem Menschen validierte dq_rules.yaml-Datei haben, können Sie sie bedenkenlos bereitstellen.
Beenden Sie die Antigravity CLI, indem Sie /quit eingeben oder zweimal Ctrl+C drücken.
Mit dem folgenden gcloud-Befehl wird eine neue Ressource für den Knowledge Catalog-Datenscan erstellt. Der Scan wird noch nicht ausgeführt. Es werden lediglich die Definition und Konfiguration des Scans (unsere YAML-Datei) im Knowledge Catalog registriert.
Führen Sie diesen Befehl in Ihrem Terminal aus:
export DQ_SCAN="dq-scan"
gcloud dataplex datascans create data-quality $DQ_SCAN \
--project=$PROJECT_ID \
--location=$LOCATION \
--data-quality-spec-file=dq_rules.yaml \
--data-source-resource="//bigquery.googleapis.com/projects/$PROJECT_ID/datasets/$DATASET_ID/tables/mv_ga4_user_session_flat"
Nachdem der Scan definiert wurde, können Sie einen Job auslösen, um ihn auszuführen.
gcloud dataplex datascans run $DQ_SCAN --location=$LOCATION --project=$PROJECT_ID
Mit diesem Befehl wird eine Job-ID ausgegeben. Sie können den Status dieses Jobs in der Google Cloud Console im Bereich „Knowledge Catalog“ überwachen. Nach Abschluss werden die Ergebnisse zur Analyse in eine BigQuery-Tabelle geschrieben.
5. Die entscheidende Rolle von Human-in-the-Loop (HITL)
Der Antigravity-Agent ist ein sehr leistungsstarkes Tool, um die Regelerstellung zu beschleunigen. Es ist jedoch wichtig, die KI als hochqualifizierten Copiloten und nicht als vollständig autonomen Piloten zu betrachten. Der Human-in-the-Loop-Prozess (HITL) ist kein optionaler Vorschlag, sondern ein unverzichtbarer, grundlegender Schritt in jedem Data-Governance-Workflow. KI-generierte Artefakte ohne strenge menschliche Aufsicht einzusetzen, ist ein Rezept für das Scheitern.
Stellen Sie sich die KI-generierte dq_rules.yaml als Pull-Anfrage vor, die von einem extrem schnellen, aber unerfahrenen KI-Entwickler gesendet wurde. Bevor sie in den „Hauptzweig“ Ihrer Governance-Richtlinie aufgenommen und bereitgestellt werden kann, ist eine gründliche Überprüfung durch einen erfahrenen Experten erforderlich – also durch Sie. Diese Überprüfung ist unerlässlich, um die inhärenten Schwächen von Large Language Models zu minimieren.
Hier finden Sie eine detaillierte Aufschlüsselung, warum diese manuelle Überprüfung unerlässlich ist und worauf Sie besonders achten müssen:
1. Kontextbezogene Validierung: Der KI fehlt das Geschäftswissen.
- Schwäche des LLM: Ein LLM ist ein Meister der Muster und Statistiken, hat aber keinerlei Verständnis für Ihren Geschäftskontext. Wenn beispielsweise eine Spalte,
new_campaign_id, ein Nullverhältnis von 98% hat, kann es sein, dass ein LLM diese Spalte aus statistischen Gründen ignoriert. - Die entscheidende Rolle des Menschen:Sie als menschlicher Experte wissen, dass das Feld
new_campaign_iderst gestern für eine wichtige Produkteinführung nächste Woche hinzugefügt wurde. Sie wissen, dass das Nullverhältnis jetzt hoch sein sollte, aber voraussichtlich deutlich sinken wird. Außerdem wissen Sie, dass das Feld nach dem Ausfüllen ein bestimmtes Format haben muss. Die KI kann dieses externe Unternehmenswissen nicht ableiten. Ihre Aufgabe ist es, diesen geschäftlichen Kontext auf die statistischen Vorschläge der KI anzuwenden und sie bei Bedarf zu überschreiben oder zu ergänzen.
2. Richtigkeit und Präzision: Schutz vor Halluzinationen und subtilen Fehlern
- Schwäche des LLM:LLMs können „selbstbewusst falsch“ sein. Sie können „halluzinieren“ oder Code generieren, der subtil falsch ist. So kann es beispielsweise eine YAML-Datei mit einer korrekt benannten Regel, aber einem ungültigen Parameter generieren oder einen Regeltyp falsch schreiben (z.B.
setExpectationsanstelle des korrektensetExpectation). Diese subtilen Fehler führen dazu, dass die Bereitstellung fehlschlägt, sind aber schwer zu erkennen. - Die entscheidende Rolle des Menschen:Ihre Aufgabe ist es, als ultimativer Linter und Schemavalidierer zu fungieren. Sie müssen die generierte YAML-Datei sorgfältig mit der offiziellen
DataQualityRule-Spezifikation für den Knowledge Catalog vergleichen. Sie prüfen nicht nur, ob es „richtig aussieht“, sondern validieren auch die syntaktische und semantische Korrektheit, um sicherzustellen, dass es zu 100% mit der Ziel-API kompatibel ist. Aus diesem Grund wird der Agent im Codelab aufgefordert, auf die Schemadateien zu verweisen, um das Fehlerrisiko zu verringern. Die endgültige Überprüfung liegt jedoch bei Ihnen.
3. Sicherheit und Risikominimierung: Downstream-Folgen verhindern
- Schwäche des LLM:Eine fehlerhafte Datenqualitätsregel, die in der Produktion eingesetzt wird, kann schwerwiegende Folgen haben. Wenn die KI einen
rangeExpectationfür einen Finanztransaktionsbetrag vorschlägt, der zu breit ist, kann es sein, dass betrügerische Aktivitäten nicht erkannt werden. Wenn das Tool hingegen eine zu strenge Regel auf Grundlage einer kleinen Datenstichprobe vorschlägt, könnte dies dazu führen, dass Ihr Bereitschaftsteam mit Tausenden von falsch positiven Benachrichtigungen überflutet wird. Das kann zu einer Überlastung durch Benachrichtigungen führen und dazu, dass echte Probleme übersehen werden. - Die entscheidende Rolle des Menschen:Sie sind der Sicherheitsingenieur. Sie müssen die potenziellen Auswirkungen jeder einzelnen von der KI vorgeschlagenen Regel auf nachgelagerte Systeme bewerten. Fragen Sie sich: „Was passiert, wenn diese Regel fehlschlägt? Erfordert die Benachrichtigung eine Reaktion? Welches Risiko besteht, wenn diese Regel fälschlicherweise bestanden wird?“ Diese Risikobewertung ist eine einzigartige menschliche Fähigkeit, bei der die Kosten eines Fehlers gegen den Nutzen der Prüfung abgewogen werden.
4. Governance als kontinuierlicher Prozess: vorausschauendes Wissen einbeziehen
- Schwäche des LLM:Das Wissen der KI basiert auf einer statischen Momentaufnahme der Daten – das Profil ergibt sich aus einem bestimmten Zeitpunkt. Es hat kein Wissen über zukünftige Ereignisse.
- Die entscheidende Rolle des Menschen:Ihre Governance-Strategie muss zukunftsorientiert sein. Sie wissen, dass eine Datenquelle im nächsten Monat migriert werden soll, wodurch sich die stream_id ändert. Sie wissen, dass der Liste
geo_countryein neues Land hinzugefügt wird. Im HITL-Prozess fügen Sie dieses Wissen über den zukünftigen Zustand ein und aktualisieren oder deaktivieren Regeln vorübergehend, um Unterbrechungen bei geplanten geschäftlichen oder technischen Änderungen zu vermeiden. Datenqualität ist keine einmalige Einrichtung, sondern ein fortlaufender Prozess, der sich weiterentwickeln muss. Nur ein Mensch kann diese Entwicklung steuern.
Zusammenfassend lässt sich sagen, dass HITL der wesentliche Mechanismus für Qualitätssicherung und Sicherheit ist, der KI-gestützte Governance von einer neuartigen, aber riskanten Idee in eine verantwortungsbewusste, skalierbare und für Unternehmen geeignete Methode verwandelt. So wird sichergestellt, dass die endgültigen Richtlinien nicht nur durch KI beschleunigt, sondern auch von Menschen validiert werden. So wird die Geschwindigkeit von Maschinen mit dem Wissen und Kontext menschlicher Experten kombiniert.
Diese Betonung der menschlichen Aufsicht schmälert jedoch nicht den Wert der KI. Im Gegenteil: Die generative KI spielt eine entscheidende Rolle bei der Beschleunigung des HITL-Prozesses selbst.
Ohne KI müsste ein Data Engineer:
- Komplexe SQL-Abfragen manuell schreiben, um die Daten zu analysieren (z.B.
COUNT DISTINCT,AVG,MIN,MAXfür jede Spalte). - Analysieren Sie die Ergebnisse sorgfältig Tabelle für Tabelle.
- Jede einzelne Zeile der YAML-Regeldatei muss von Grund auf neu geschrieben werden. Das ist mühsam und fehleranfällig.
Die KI automatisiert diese mühsamen, zeitaufwendigen Schritte. Er fungiert als unermüdlicher Analyst, der das statistische Profil sofort verarbeitet und einen gut strukturierten, zu 80% vollständigen „ersten Entwurf“ der Richtlinie erstellt.
Dadurch ändert sich die Art der Arbeit des Menschen grundlegend. Anstatt Stunden mit der manuellen Datenverarbeitung und dem Boilerplate-Code zu verbringen, kann sich der menschliche Experte sofort auf die wichtigsten Aufgaben konzentrieren:
- Anwenden von wichtigem geschäftlichen Kontext
- Die Richtigkeit der KI-Logik wird überprüft.
- Strategische Entscheidungen darüber treffen, welche Regeln wirklich wichtig sind.
Bei dieser Partnerschaft übernimmt die KI das „Was“ (Was sind die statistischen Muster?), sodass sich der Mensch auf das „Warum“ (Warum ist dieses Muster für unser Unternehmen wichtig?) und das „Was nun?“ (Was sollte unsere Richtlinie sein?) konzentrieren kann. KI ersetzt den Loop also nicht, sondern macht jeden Zyklus schneller, intelligenter und wirkungsvoller.
6. Umgebung bereinigen
Löschen Sie das Projekt, das die Ressourcen enthält, um zu vermeiden, dass Ihrem Google Cloud-Konto die in diesem Codelab verwendeten Ressourcen in Rechnung gestellt werden. Wenn Sie das Projekt jedoch beibehalten möchten, können Sie die einzelnen Ressourcen löschen, die Sie erstellt haben.
Knowledge Catalog-Scans löschen
Löschen Sie zuerst die von Ihnen erstellten Profil- und Qualitätsscans. Damit wichtige Ressourcen nicht versehentlich gelöscht werden, verwenden diese Befehle die spezifischen Namen der in diesem Codelab erstellten Scans.
# Delete the Data Quality Scan
gcloud dataplex datascans delete dq-scan \
--location=us-central1 \
--project=$PROJECT_ID --quiet
# Delete the Data Profile Scans
gcloud dataplex datascans delete profile-scan-mv-ga4-user-session-flat \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-transactions \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-items \
--location=us-central1 \
--project=$PROJECT_ID --quiet
BigQuery-Dataset löschen
Löschen Sie als Nächstes das BigQuery-Dataset. Dieser Befehl ist nicht rückgängig zu machen. Er verwendet das Flag „-f“ (force), um das Dataset und alle zugehörigen Tabellen ohne Bestätigung zu entfernen.
# Manually type this command to confirm you are deleting the correct dataset
bq rm -r -f --dataset $PROJECT_ID:kc_dq_codelab
7. Das wars! Sie haben das Lab erfolgreich abgeschlossen.
Sie haben das Codelab erfolgreich abgeschlossen.
Sie haben einen End-to-End-Workflow für die programmatische Data Governance erstellt. Sie haben damit begonnen, komplexe BigQuery-Daten mithilfe von materialisierten Ansichten zu vereinfachen, damit sie sich für die Analyse eignen. Anschließend haben Sie Knowledge Catalog-Profilscans programmatisch ausgeführt, um statistische Metadaten zu generieren. Vor allem haben Sie die Antigravity-Befehlszeile verwendet, um die Profilausgabe zu analysieren und intelligent ein „Policy-as-Code“-Artefakt (dq_rules.yaml) zu generieren. Anschließend haben Sie die Befehlszeile verwendet, um diese Konfiguration als automatisierten Data Quality Scan bereitzustellen. So haben Sie den Kreis einer modernen, skalierbaren Governance-Strategie geschlossen.
Sie kennen jetzt das grundlegende Muster zum Erstellen zuverlässiger, KI-beschleunigter und von Menschen validierter Datenqualitätssysteme in Google Cloud.
Nächste Schritte
- In CI/CD einbinden:Nehmen Sie die Datei
dq_rules.yamlund übertragen Sie sie per Commit in ein Git-Repository. Erstellen Sie eine CI/CD-Pipeline (z.B. mit Cloud Build oder GitHub Actions), die den Knowledge Catalog-Scan automatisch bereitstellt, wenn die Regeldatei aktualisiert wird. - Benutzerdefinierte SQL-Regeln verwenden:Sie können mehr als die Standardregeltypen nutzen. Knowledge Catalog unterstützt benutzerdefinierte SQL-Regeln, um komplexere, unternehmensspezifische Logik zu erzwingen, die mit vordefinierten Prüfungen nicht ausgedrückt werden kann. Mit dieser Funktion können Sie die Validierung an Ihre individuellen Anforderungen anpassen.
- Scans für Effizienz und Kosten optimieren:Bei sehr großen Tabellen können Sie die Leistung verbessern und die Kosten senken, indem Sie nicht immer den gesamten Datensatz scannen. Sie können Filter verwenden, um den Scan auf bestimmte Zeiträume oder Datensegmente einzugrenzen, oder Stichprobenscans konfigurieren, um einen repräsentativen Prozentsatz Ihrer Daten zu prüfen.
- Ergebnisse visualisieren:Die Ausgabe jedes Knowledge Catalog-Scans zur Datenqualität wird in eine BigQuery-Tabelle geschrieben. Verbinden Sie diese Tabelle mit Looker Studio, um Dashboards zu erstellen, in denen Ihre Datenqualitätswerte im Zeitverlauf nach den von Ihnen definierten Dimensionen (z.B. Vollständigkeit, Gültigkeit) aggregiert dargestellt werden. So wird das Monitoring proaktiv und für alle Stakeholder sichtbar.
- Best Practices teilen:Fördern Sie den Wissensaustausch in Ihrem Unternehmen, um das kollektive Wissen zu nutzen und Ihre Datenqualitätsstrategie zu verbessern. Eine Kultur des Datenvertrauens ist entscheidend, um Ihre Governance-Bemühungen optimal zu nutzen.
- Dokumentation lesen