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 ein robustes Qualitäts- und Metadatenmanagement direkt in den Entwicklungszyklus einbetten lässt. Im Grunde fungiert Dataplex Universal Catalog als intelligente Datenstruktur, mit der Organisationen Daten in ihrem gesamten Bestand zentral verwalten, überwachen und steuern können – von Data Lakes bis hin zu Data Warehouses.
In diesem Codelab wird gezeigt, wie Sie mit Dataplex, BigQuery und der Gemini-CLI 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.
Voraussetzungen
- Grundlegende Kenntnisse der Google Cloud Console
- Grundkenntnisse in der Befehlszeile und Google Cloud Shell
Lerninhalte
- Verschachtelte BigQuery-Daten mit materialisierten Ansichten vereinfachen, um eine umfassende Profilerstellung zu ermöglichen
- Hier erfahren Sie, wie Sie Dataplex-Profilscans programmatisch mit der Dataplex 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 Gemini CLI, um Profildaten zu analysieren und eine Dataplex-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 automatischen Datenqualitätsscan bereit.
Voraussetzungen
- Ein Google Cloud-Konto und ein Google Cloud-Projekt
- Ein Webbrowser wie Chrome
Schlüsselkonzepte: Die Säulen der Dataplex-Datenqualität
Um eine effektive Datenqualitätsstrategie zu entwickeln, müssen Sie die Kernkomponenten von Dataplex kennen.
- Datenprofilscan:Ein Dataplex-Job, mit dem Daten analysiert und statistische Metadaten generiert werden, darunter Nullprozentsätze, Anzahl eindeutiger Werte und Werteverteilungen. Dies dient als unsere programmatische „Erkennungsphase“.
- Datenqualitätsregeln: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 (z. B. Gemini) wird verwendet, um ein Datenprofil zu analysieren und relevante Datenqualitätsregeln vorzuschlagen. Dadurch wird die Definition eines grundlegenden Qualitätsrahmens beschleunigt.
- Datenqualitätsscan:Ein Dataplex-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-Skripten). Dies ermöglicht die Automatisierung, Versionierung und Einbindung 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 in der Symbolleiste oben rechts auf das Cloud Shell-Symbol:
Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment. 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="dataplex_dq_codelab"
export TABLE_ID="ga4_transactions"
gcloud services enable dataplex.googleapis.com \
bigquery.googleapis.com \
serviceusage.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 dataplex_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.
git clone https://github.com/GoogleCloudPlatform/devrel-demos
cd devrel-demos/data-analytics/programmatic-dq
Dieses Verzeichnis ist jetzt Ihr aktiver Arbeitsbereich. Alle nachfolgenden Dateien werden hier erstellt.
3. Automatisierte Datenerkennung mit Dataplex-Profiling
Die Dataplex-Datenprofilerstellung ist ein leistungsstarkes Tool, mit dem Sie automatisch statistische Informationen zu Ihren Daten ermitteln 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 Dataplex-Profilerstellung besteht jedoch darin, dass verschachtelte oder wiederholte Felder nicht vollständig untersucht werden können (z.B. RECORD- oder ARRAY-Typen) in einer Tabelle. Sie kann erkennen, dass eine Spalte ein komplexer Typ ist, aber die einzelnen Felder in dieser verschachtelten Struktur nicht profilieren.
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 Dataplex für jedes Feld ein eigenes Profil erstellen kann.
Geschachteltes 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 Datei bq_schema.json 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, relational ä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 Dataplex-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. Dadurch 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 Dataplex-Clientbibliothek in der neu aktivierten Umgebung.
# Install the Dataplex 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_dataplex_scans.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 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_dataplex_scans.py
Das Script orchestriert nun das Profiling Ihrer drei materialisierten Ansichten und stellt Statusaktualisierungen in Echtzeit bereit. 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ü unter „Govern“ (Verwalten) „Dataplex Universal Catalog“ (Dataplex Universal Catalog) und „Profile“ (Profil) 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-kompatiblen Eingabe
Die Dataplex-Profilscans wurden erfolgreich ausgeführt. Die Ergebnisse sind zwar in der Dataplex 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 Dataplex 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 'run_dataplex_scans.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 Gemini CLI generieren
Gemini CLI installieren und konfigurieren
Sie können die Gemini API zwar programmatisch aufrufen, aber mit einem Tool wie der Gemini CLI lässt sich generative KI auf leistungsstarke und interaktive Weise direkt in Ihre Terminal-Workflows einbinden. Die Gemini CLI ist nicht nur ein Chatbot, sondern auch ein Befehlszeilen-Workflow-Tool, das Ihre lokalen Dateien lesen, Ihren Code verstehen und mit anderen Systemtools wie gcloud interagieren kann, um komplexe Aufgaben zu automatisieren. Das macht es ideal für unseren Anwendungsfall.
Voraussetzung
Prüfen Sie zuerst, ob die erforderliche Voraussetzung erfüllt ist: Node.js Version 20 oder höher muss in Ihrer Cloud Shell-Umgebung installiert sein. Sie können Ihre Version mit dem Befehl node -v prüfen.
Installation
Es gibt zwei Möglichkeiten, die Gemini CLI zu verwenden: vorübergehend oder dauerhaft installieren. Wir werden beide Methoden hier behandeln.
Sie können die Gemini-Befehlszeile direkt für eine einzelne Sitzung ausführen, ohne dass eine dauerhafte Installation erforderlich ist. Das ist die einfachste und schnellste Methode, um die Funktion auszuprobieren, da Ihre Umgebung dadurch nicht verändert wird.
Führen Sie in Ihrem Cloud Shell-Terminal folgenden Befehl aus:
npx https://github.com/google-gemini/gemini-cli
Mit diesem Befehl wird das CLI-Paket vorübergehend heruntergeladen und ausgeführt.
Für jedes echte Projekt empfiehlt es sich, die CLI lokal in Ihrem Projektverzeichnis zu installieren. Dieser Ansatz bietet mehrere wichtige Vorteile:
- Abhängigkeitsisolation:Ihr Projekt hat seine eigene Version der CLI, wodurch Versionskonflikte mit anderen Projekten vermieden werden.
- Reproduzierbarkeit:Jeder, der Ihr Projekt klont, kann genau dieselben Abhängigkeiten installieren. Das macht Ihre Einrichtung zuverlässig und portabel.
- Best Practice: Es folgt dem Standardmodell für die Verwaltung von Node.js-Projektabhängigkeiten und vermeidet die Fallstricke globaler (-g) Installationen.
Führen Sie zum lokalen Installieren der CLI den folgenden Befehl in Ihrem Projektordner (programmatic-dq) aus:
npm install @google/gemini-cli
Dadurch wird im Ordner „programmatic-dq“ ein Ordner „node_modules“ erstellt. Verwenden Sie den Befehl „npx“, um die gerade installierte Version auszuführen.
npx gemini
Ersteinrichtung
Unabhängig davon, welche Methode Sie auswählen, werden Sie beim ersten Start der Befehlszeile durch einen einmaligen Einrichtungsvorgang geführt.
Sie werden aufgefordert, ein Farbdesign auszuwählen und sich dann zu authentifizieren. Die einfachste Methode ist, sich mit Ihrem Google-Konto anzumelden, wenn Sie dazu aufgefordert werden. Die kostenlose Stufe ist für dieses Codelab ausreichend.
Nachdem die CLI installiert und konfiguriert wurde, können Sie mit dem Generieren der Regeln fortfahren. Die CLI kennt die Dateien im aktuellen Verzeichnis, was für den nächsten Schritt wichtig ist.
Regeln für die Datenqualität generieren
Es ist zwar möglich, ein LLM zu bitten, eine Konfigurationsdatei in einem Schritt zu generieren, aber aufgrund der nicht deterministischen Natur generativer Modelle entspricht die Ausgabe möglicherweise nicht immer dem strengen Schema, das für Tools wie gcloud erforderlich ist. Eine zuverlässigere Methode ist ein interaktiver, mehrstufiger Prozess, bei dem die KI zuerst als Analyst fungiert und einen Plan vorschlägt. Sie (der menschliche Experte) überprüfen und genehmigen diesen Plan. Erst dann generiert die KI den endgültigen Code auf Grundlage Ihrer genehmigten Anweisungen.
So wird aus einem einfachen Befehl eine kollaborative Sitzung, in der das Endergebnis genau, validiert und bereit für die Bereitstellung ist.
Zuerst bitten wir Gemini, das statistische Profil zu analysieren und als Experte für Datenanalyse einen Aktionsplan vorzuschlagen. Wir weisen das Tool explizit an, die YAML-Datei noch nicht zu schreiben. Der Fokus liegt hier auf der Analyse und Begründung.
Fügen Sie in Ihrer interaktiven Gemini CLI-Sitzung den folgenden Prompt ein:
You are an expert Google Cloud Dataplex engineer.
Your first task is to create a plan. I have a file in the current directory named ./dq_profile_results.json.
Based on the statistical data within that file, propose a step-by-step plan to create a Dataplex data quality rules file.
Your plan should identify which specific columns are good candidates for rules like nonNullExpectation, setExpectation, or rangeExpectation, and explain why based on the metrics (e.g., "Plan to create a nonNullExpectation for column X because its null percentage is 0%").
Do not write the YAML file yet. Just provide the plan.
Gemini analysiert die JSON-Datei und gibt einen strukturierten Plan zurück, der in etwa so aussieht:
Plan to create Dataplex data quality rules
1. Create a row count rule:
- Analysis: The profile shows a total of 26,489 rows.
- Proposed Rule: I will implement a rowCount rule to ensure the table's row count remains within a healthy range (e.g., 20,000 to 30,000). This is a fundamental check to guard against major data loading failures or unexpected deletions.
2. Implement non-null expectation rules:
- Analysis: The profiling results show that many columns have no null values. For example, event_date, event_timestamp, event_name, user_pseudo_id, stream_id, and platform all appear to be fully populated.
- Proposed Rules: I will create nonNullExpectation rules for columns where the nullRatio is 0 or not present, indicating they are always expected to contain a value:
- event_date
- event_timestamp
- event_name
- user_pseudo_id
- stream_id
- platform
- device_category
- device_os
3. Implement set expectation rules:
- Analysis: Several columns contain a small, finite set of values, making them ideal for set validation.
- Proposed Rules: I will create setExpectation rules for these columns:
- platform: It only contains the value "WEB".
- device_category: It contains only "desktop", "mobile", and "tablet".
- geo_continent: It has a well-defined list of continents.
traffic_source_medium: It has a small list of valid mediums like "organic", "(none)", and "referral".
4. Implement range expectation rules:
- Analysis: The profile provides minimum and maximum values for numeric and string length fields.
- Proposed Rules: I will create rangeExpectation rules for the following:
- event_timestamp: The profile shows a clear min and max. I will use these values to create a range check.
- event_date (String Length): The profile indicates that the minLength and maxLength are both 8, which is perfect for enforcing a YYYYMMDD format.
Dies ist der wichtigste Schritt im gesamten Workflow: die Human-in-the-Loop-Prüfung (HITL). Der von Gemini 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.
Prüfen Sie den von Gemini bereitgestellten Plan sorgfältig.
- Ist das verständlich?
- Passt es zu Ihrem geschäftlichen Know-how?
- Gibt es statistisch fundierte, aber praktisch nutzlose Regeln?
Die Ausgabe, die Sie von Gemini erhalten, kann variieren. Ihr Ziel ist es, sie zu verfeinern.
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 für die Anwendung von Geschäftskontext, der der KI fehlt.
Jetzt geben Sie Gemini 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 von Gemini vorgeschlagene Plan perfekt ist und keine Änderungen erforderlich sind, können Sie diese Zeile einfach löschen.
Fügen Sie in derselben Gemini-Sitzung Ihre angepasste Version des folgenden Prompts ein:
[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'."]
Once you have incorporated my feedback, please generate the `dq_rules.yaml` file.
You must adhere to the following strict requirements:
- Schema Compliance: The YAML structure must strictly conform to the DataQualityRule specification. For a definitive source of truth, you must 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.
- Data-Driven Values: All rule parameters, such as thresholds or expected values, must be derived directly from the statistical metrics in dq_profile_results.json.
- Rule Justification: For each rule, add a comment (#) on the line above explaining the justification, as you outlined in your plan.
- Output Purity: The final output must only be the raw YAML code block, perfectly formatted and ready for immediate deployment.
Gemini generiert jetzt den YAML-Inhalt basierend auf Ihren präzisen, von Menschen validierten Anweisungen. Nach Abschluss finden Sie in Ihrem Arbeitsverzeichnis eine neue Datei namens „dq_rules.yaml“.
Datenqualitätsscan erstellen und ausführen
Nachdem Sie eine KI-generierte, von Menschen validierte dq_rules.yaml-Datei haben, können Sie sie bedenkenlos bereitstellen.
Beenden Sie die Gemini CLI, indem Sie /quit eingeben oder zweimal Ctrl+C drücken.
Mit dem folgenden gcloud-Befehl wird eine neue Dataplex-Datenprüfressource erstellt. Der Scan wird noch nicht ausgeführt. Es werden lediglich die Definition und Konfiguration des Scans (unsere YAML-Datei) bei Dataplex 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=$REGION \
--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 Sie den Scan definiert haben, können Sie einen Job auslösen, um ihn auszuführen.
gcloud dataplex datascans run $DQ_SCAN --location=$REGION --project=$PROJECT_ID
Dieser Befehl gibt eine Job-ID aus. Sie können den Status dieses Jobs im Dataplex-Bereich der Google Cloud Console überwachen. Nach Abschluss werden die Ergebnisse zur Analyse in eine BigQuery-Tabelle geschrieben.
5. Die entscheidende Rolle von Human-in-the-Loop (HITL)
Gemini kann die Regelerstellung erheblich 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 robusten und vertrauenswürdigen Data-Governance-Workflow. KI-generierte Artefakte ohne strenge menschliche Aufsicht bereitzustellen, 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äftsbewusstsein.
- Schwäche des LLM: Ein LLM ist ein Meister der Muster und Statistiken, hat aber keinerlei Verständnis für Ihren geschäftlichen Kontext. Wenn beispielsweise eine Spalte
new_campaign_idein 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, aber sie sind 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 Dataplex-
DataQualityRule-Spezifikation vergleichen. Sie prüfen nicht nur, ob es „richtig aussieht“, sondern validieren die syntaktische und semantische Korrektheit, um sicherzustellen, dass es zu 100% mit der Ziel-API kompatibel ist. Aus diesem Grund wird Gemini 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 Risikominderung: Downstream-Folgen verhindern
- Schwäche des LLM:Eine fehlerhafte Regel für die Datenqualität, die in der Produktion eingesetzt wird, kann schwerwiegende Folgen haben. Wenn die KI einen
rangeExpectationfür einen Betrag für Finanztransaktionen vorschlägt, der zu breit ist, kann es sein, dass betrügerische Aktivitäten nicht erkannt werden. Wenn das System hingegen eine Regel vorschlägt, die auf einer kleinen Datenstichprobe basiert und zu streng ist, könnte es Ihr Bereitschaftsteam mit Tausenden von falsch positiven Benachrichtigungen überfluten. Dies 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? Ist die Benachrichtigung umsetzbar? 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: Einbeziehung zukunftsorientierten Wissens
- 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 wird, 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, indem Sie Regeln aktualisieren oder vorübergehend deaktivieren, um Unterbrechungen bei geplanten geschäftlichen oder technischen Änderungen zu vermeiden. Die 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-basierte Governance von einer neuartigen, aber riskanten Idee in eine verantwortungsbewusste, skalierbare und unternehmenstaugliche Praxis 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 von menschlichen 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 die 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 Ergebnistabelle sorgfältig.
- 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. Es 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. Statt Stunden mit der manuellen Datenverarbeitung und dem Boilerplate-Coding 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 beibehalten möchten, können Sie die einzelnen Ressourcen löschen, die Sie erstellt haben.
Dataplex-Scans löschen
Löschen Sie zuerst die von Ihnen erstellten Profil- und Qualitätsscans. Um ein versehentliches Löschen wichtiger Ressourcen zu verhindern, werden in diesen Befehlen die spezifischen Namen der in diesem Codelab erstellten Scans verwendet.
# 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 data-scans delete profile-scan-mv-ga4-user-session-flat \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex data-scans delete profile-scan-mv-ga4-ecommerce-transactions \
--location=us-central1 \
--project=$PROJECT_ID --quiet
gcloud dataplex data-scans 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:dataplex_dq_codelab
7. Glückwunsch!
Sie haben das Codelab erfolgreich abgeschlossen.
Sie haben einen End-to-End-Workflow für die programmatische Data Governance erstellt. Zuerst haben Sie Materialized Views verwendet, um komplexe BigQuery-Daten zu vereinfachen und für die Analyse vorzubereiten. Anschließend haben Sie Dataplex-Profilscans programmatisch ausgeführt, um statistische Metadaten zu generieren. Am wichtigsten ist, dass Sie die Gemini CLI verwendet haben, um die Profilausgabe zu analysieren und ein „Policy-as-Code“-Artefakt (dq_rules.yaml) intelligent zu generieren. Anschließend haben Sie die CLI verwendet, um diese Konfiguration als automatischen Datenqualitäts-Scan bereitzustellen. So haben Sie den Kreis einer modernen, skalierbaren Governance-Strategie geschlossen.
Sie haben jetzt das grundlegende Muster zum Erstellen zuverlässiger, KI-beschleunigter und von Menschen validierter Datenqualitätssysteme in Google Cloud kennengelernt.
Wie geht es weiter?
- In CI/CD einbinden:Nehmen Sie die Datei „dq_rules.yaml“ und ü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 Dataplex-Scan automatisch bereitstellt, wenn die Regeldatei aktualisiert wird.
- Benutzerdefinierte SQL-Regeln verwenden:Nutzen Sie mehr als die Standardregeltypen. Dataplex unterstützt benutzerdefinierte SQL-Regeln, um komplexere, geschäftsspezifische Logik zu erzwingen, die mit vordefinierten Prüfungen nicht ausgedrückt werden kann. Dies ist eine leistungsstarke Funktion, mit der Sie die Validierung an Ihre individuellen Anforderungen anpassen können.
- 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 Dataplex-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 aggregiert nach den von Ihnen definierten Dimensionen (z.B. Vollständigkeit, Gültigkeit). So wird die Überwachung proaktiv und für alle Stakeholder sichtbar.
- Best Practices teilen:Fördern Sie den Wissensaustausch in Ihrer Organisation, 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