Datenqualitätsaufgaben verwenden

In diesem Dokument erfahren Sie, wie Sie Dataplex-Datenqualitätsaufgaben erstellen, mit denen Sie Datenqualitätsprüfungen für Ihre integrierten und externen BigQuery-Tabellen planen und ausführen können.

Weitere Informationen finden Sie unter Datenqualitätsaufgaben – Übersicht.

Hinweise

In diesem Dokument wird davon ausgegangen, dass Sie einen vorhandenen Dataplex-Lake haben, in dem Sie die Datenqualitätsaufgabe erstellen können.

Führen Sie die folgenden Schritte aus, bevor Sie eine Aufgabe zur Datenqualität erstellen.

Google APIs und Google-Dienste aktivieren

die Dataproc API aktivieren

API aktivieren
Aktivieren Sie den privaten Google-Zugriff für Ihr Netzwerk und/oder Subnetzwerk. Aktivieren Sie den privaten Google-Zugriff in dem Netzwerk, das Sie für Dataplex-Datenqualitätsaufgaben verwenden möchten. Wenn Sie beim Erstellen der Dataplex-Datenqualitätsaufgabe kein Netzwerk oder Subnetzwerk angeben, verwendet Dataplex das Standardsubnetz. In diesem Fall müssen Sie den privater Google-Zugriff im Standardsubnetz aktivieren.

Spezifikationsdatei erstellen

Dataplex verwendet das Open-Source-CloudDQ als Treiberprogramm. Die Anforderungen für die Datenqualitätsprüfung von Dataplex werden in den YAML-Spezifikationsdateien von CloudDQ definiert.

Als Eingabe für die Aufgabe der Datenqualität können Sie eine einzelne YAML-Datei oder ein einzelnes ZIP-Archiv mit einer oder mehreren YAML-Dateien verwenden. Es empfiehlt sich, die Anforderungen an die Datenqualitätsprüfung in separaten YAML-Spezifikationsdateien mit einer Datei für jeden Abschnitt zu erfassen.

So bereiten Sie eine Spezifikationsdatei vor:

Erstellen Sie eine oder mehrere CloudDQ-YAML-Spezifikationsdateien, die die Anforderungen an die Datenqualitätsprüfung definieren. Weitere Informationen zur erforderlichen Syntax finden Sie im Abschnitt Informationen zur Spezifikationsdatei in diesem Dokument.

Speichern Sie die YAML-Spezifikationsdatei im Format .yml oder .yaml. Wenn Sie mehrere YAML-Spezifikationsdateien erstellen, speichern Sie alle Dateien in einem einzelnen ZIP-Archiv.
Cloud Storage-Bucket erstellen
Laden Sie die Spezifikationsdatei in den Cloud Storage-Bucket hoch.

Informationen zur Spezifikationsdatei

Ihre CloudDQ-YAML-Spezifikationsdatei muss folgende Abschnitte enthalten:

Regeln (definiert im übergeordneten YAML-Knoten rules): Eine Liste der auszuführenden Regeln. Sie können diese Regeln aus vordefinierten Regeltypen wie NOT_NULL und REGEX erstellen oder mit benutzerdefinierten SQL-Anweisungen wie CUSTOM_SQL_EXPR und CUSTOM_SQL_STATEMENT erweitern. Die CUSTOM_SQL_EXPR-Anweisung meldet jede Zeile, die custom_sql_expr in False ausgewertet hat, als Fehler. Die CUSTOM_SQL_STATEMENT-Anweisung kennzeichnet alle Werte, die von der gesamten Anweisung zurückgegeben werden, als Fehler.
Zeilenfilter (definiert im übergeordneten YAML-Knoten row_filters): SQL-Ausdrücke, die einen booleschen Wert zurückgeben, der Filter definiert, um eine Teilmenge der Daten aus dem zugrunde liegenden Subjekt zur Validierung abzurufen.
Regelbindungen (im übergeordneten YAML-Knoten rule_bindings definiert): Definiert rules und rule filters, die auf die Tabellen angewendet werden sollen.
Regeldimensionen (im YAML-Knoten rule_dimensions definiert): Definiert die Liste der zulässigen Dimensionen für Datenqualitätsregeln, die eine Regel im entsprechenden Feld dimension definieren kann.

Beispiel:
```
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
```
Das Feld dimension ist für eine Regel optional. Der Abschnitt zu den Regeldimensionen ist obligatorisch, wenn dimension in einer beliebigen Regel aufgeführt ist.

Weitere Informationen finden Sie im CloudDQ-Referenzhandbuch und in den Dateien mit Beispielspezifikationen.

Hinweis: Aufgrund einer CloudDQ-Beschränkung können Sie nicht mehr als einen übergeordneten Knoten pro Abschnitt (z. B. rules oder rule_bindings) in einer einzelne YAML-Datei haben, da CloudDQ nur den letzten Knoten jedes Typs innerhalb einer Datei parst.

Dataset zum Speichern der Ergebnisse erstellen

Erstellen Sie ein BigQuery-Dataset, um die Ergebnisse zu speichern.

Das Dataset muss sich in derselben Region wie die Tabellen befinden, für die Sie die Datenqualitätsaufgabe ausführen.

Dataplex verwendet dieses Dataset und erstellt oder verwendet eine Tabelle Ihrer Wahl zum Speichern der Ergebnisse.

Dienstkonto erstellen

Erstellen Sie ein Dienstkonto mit den folgenden IAM-Rollen und -Berechtigungen (Identity and Access Management):

Lesezugriff auf den Cloud Storage-Pfad, der die YAML-Spezifikationen enthält. Sie können die Rolle Storage-Objekt-Betrachter (roles/storage.objectViewer) für den Cloud Storage-Bucket verwenden.
Lesezugriff auf BigQuery-Datasets mit zu validierenden Daten. Sie können die Rolle BigQuery-Datenbetrachter verwenden.
Schreibzugriff auf das BigQuery-Dataset, um eine Tabelle zu erstellen (falls erforderlich) und die Ergebnisse in diese Tabelle zu schreiben. Sie können die Rolle BigQuery-Datenbearbeiter (roles/bigquery.dataEditor) auf Dataset-Ebene verwenden.
Rolle BigQuery-Jobnutzer (roles/bigquery.jobUser) auf Projektebene, um BigQuery-Jobs in einem Projekt zu erstellen.
Die Dataplex Metadata Reader-Rolle (roles/dataplex.metadataReader) auf Projekt- oder Lake-Ebene.
Die Rolle Service Usage-Nutzer (roles/serviceusage.serviceUsageConsumer) auf Projektebene.
Die Dataproc-Worker-Rolle.
Die Berechtigung iam.serviceAccounts.actAs, die dem Nutzer erteilt wurde, der den Job sendet.
Die Rolle Dienstkontonutzer, die dem Dataplex-Lake-Dienstkonto zugewiesen wurde. Sie können das Dataplex-Lake-Dienstkonto in der Google Cloud Console aufrufen.

Optional: Erweiterte Einstellungen verwenden

Diese Schritte sind optional:

BigQuery führt standardmäßig Datenqualitätsprüfungen im aktuellen Nutzerprojekt durch. Alternativ können Sie ein anderes Projekt wählen, um die BigQuery-Jobs auszuführen. Verwenden Sie dazu das Argument --gcp_project_id TASK_ARGS für das --execution-args-Attribut der Aufgabe.
Wenn sich die zum Ausführen von BigQuery-Abfragen angegebene Projekt-ID von dem Projekt unterscheidet, in dem das Dienstkonto (durch --execution-service-account angegeben) erstellt wird, muss die Organisationsrichtlinie, die die projektübergreifende Dienstkontonutzung deaktiviert, (iam.disableServiceAccountCreation) ausgeschaltet sein. Achten Sie außerdem darauf, dass das Dienstkonto auf den BigQuery-Jobzeitplan in dem Projekt zugreifen kann, in dem BigQuery-Abfragen ausgeführt werden.

Beschränkungen

Alle für eine bestimmte Datenqualitätsaufgabe angegebenen Tabellen müssen zur selben Google Cloud-Region gehören.

Datenqualitätsaufgabe planen

Console

Rufen Sie in der Google Cloud Console die Dataplex-Seite Prozess auf.
Zur Seite Prozess
Klicken Sie auf Aufgabe erstellen.
Klicken Sie auf der Karte Datenqualität prüfen auf Aufgabe erstellen.
Wählen Sie für Dataplex-Lake Ihren Lake aus.
Geben Sie für ID eine ID ein.
Führen Sie im Abschnitt Datenqualitätsspezifikation die folgenden Schritte aus:
1. Klicken Sie im Feld GCS-Datei auswählen auf Durchsuchen.
2. Wählen Sie Ihren Cloud Storage-Bucket aus.
3. Klicken Sie auf Auswählen.
Gehen Sie im Bereich Ergebnistabelle so vor:
1. Klicken Sie im Feld BigQuery-Dataset auswählen auf Durchsuchen.
2. Wählen Sie das BigQuery-Dataset zum Speichern der Validierungsergebnisse aus.
3. Klicken Sie auf Auswählen.
4. Geben Sie im Feld BigQuery-Tabelle den Namen der Tabelle ein, in der die Ergebnisse gespeichert werden sollen. Wenn die Tabelle nicht vorhanden ist, wird sie von Dataplex für Sie erstellt. Verwenden Sie nicht den Namen dq_summary, da er für interne Verarbeitungsaufgaben reserviert ist.
Wählen Sie im Bereich Dienstkonto aus dem Menü Nutzerkonto ein Dienstkonto aus.
Klicken Sie auf Weiter.
Konfigurieren Sie im Abschnitt Zeitplan festlegen den Zeitplan zum Ausführen der Aufgabe zur Datenqualität.
Klicken Sie auf Erstellen.

gcloud-CLI

Das folgende Beispiel zeigt die Ausführung einer Datenqualitätsaufgabe, die den gcloud CLI-Befehl der Dataplex-Aufgaben verwendet:

export USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH="USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH"

# Google Cloud project where the Dataplex task is created.
export GOOGLE_CLOUD_PROJECT="GOOGLE_CLOUD_PROJECT"

# Google Cloud region for the Dataplex lake.
export DATAPLEX_REGION_ID="DATAPLEX_REGION_ID"

# Public Cloud Storage bucket containing the prebuilt data quality executable artifact. There is one bucket for each Google Cloud region.
export DATAPLEX_PUBLIC_GCS_BUCKET_NAME="dataplex-clouddq-artifacts-${DATAPLEX_REGION_ID}"

# The Dataplex lake where your task is created.
export DATAPLEX_LAKE_NAME="DATAPLEX_LAKE_NAME"

# The service account used for running the task. Ensure that this service account
has sufficient IAM permissions on your project, including
BigQuery Data Editor, BigQuery Job User,
Dataplex Editor, Dataproc Worker, and Service
Usage Consumer.

# The BigQuery dataset used for storing the intermediate data
quality summary results and the BigQuery views associated with
each rule binding.
export TARGET_BQ_DATASET="TARGET_BQ_DATASET"

# If you want to use a different dataset for storing the intermediate data quality summary results and the BigQuery views associated with each rule binding, use the following:
export CLOUDDQ_BIGQUERY_DATASET=$TARGET_BQ_DATASET

# The BigQuery dataset where the final results of the data quality checks are stored. This could be the same as CLOUDDQ_BIGQUERY_DATASET.
export TARGET_BQ_DATASET="TARGET_BQ_DATASET"

# The BigQuery table where the final results of the data quality checks are stored.
export TARGET_BQ_TABLE="TARGET_BQ_TABLE"

# The unique identifier for the task.
export TASK_ID="TASK_ID"

gcloud dataplex tasks create \
    --location="${DATAPLEX_REGION_ID}" \
    --lake="${DATAPLEX_LAKE_NAME}" \
    --trigger-type=ON_DEMAND \
    --execution-service-account="$DATAPLEX_TASK_SERVICE_ACCOUNT" \
    --spark-python-script-file="gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq_pyspark_driver.py" \
    --spark-file-uris="gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq-executable.zip","gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq-executable.zip.hashsum","${USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH}" \
    --execution-args=^::^TASK_ARGS="clouddq-executable.zip, ALL, ${USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH}, --gcp_project_id='GOOGLE_CLOUD_PROJECT', --gcp_region_id='${DATAPLEX_REGION_ID}', --gcp_bq_dataset_id='${TARGET_BQ_DATASET}', --target_bigquery_summary_table='${GOOGLE_CLOUD_PROJECT}.${TARGET_BQ_DATASET}.${TARGET_BQ_TABLE}'," \
    "$TASK_ID"

Parameter	Beschreibung
`USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH`	Der Cloud Storage-Pfad zu Ihrer YAML-Konfigurationskonfiguration für die Datenqualitätsaufgabe. Sie können eine einzelne YAML-Datei im Format `.yml` oder `.yaml` oder ein ZIP-Archiv mit mehreren YAML-Dateien haben.
`GOOGLE_CLOUD_PROJECT`	Das Google Cloud-Projekt, in dem die Dataplex-Aufgabe und die BigQuery-Jobs erstellt werden.
`DATAPLEX_REGION_ID`	Die Region des Dataplex-Lake, in der die Datenqualitätsaufgabe erstellt wird.
`SERVICE_ACCOUNT`	Das Dienstkonto, das zum Ausführen der Aufgabe verwendet wird. Sorgen Sie dafür, dass dieses Dienstkonto die erforderlichen IAM-Berechtigungen hat, wie im Abschnitt Vorbereitung beschrieben.

Für --execution-args müssen die folgenden Argumente als positionierte Argumente übergeben werden, und zwar in dieser Reihenfolge:

Argument	Beschreibung
`clouddq-executable.zip`	Eine vorkompilierte ausführbare Datei, die in `spark-file-uris` von einem öffentlichen Cloud Storage-Bucket übergeben wurde.
`ALL`	Führen Sie alle Regelbindungen aus. Alternativ können Sie bestimmte Regelbindungen als durch Kommas getrennte Liste angeben. Beispiel: `RULE_1,RULE_2`.
`gcp-project-id`	Projekt-ID, die die BigQuery-Abfragen ausführt.
`gcp-region-id`	Region zum Ausführen der BigQuery-Jobs zur Validierung der Datenqualität. Diese Region sollte mit der Region für `gcp-bq-dataset-id` und `target_bigquery_summary_table` übereinstimmen.
`gcp-bq-dataset-id`	BigQuery-Dataset, das zum Speichern der `rule_binding`-Ansichten und der Übersichtsergebnisse der mittleren Datenqualität verwendet wird.
`target-bigquery-summary-table`	Tabellen-ID-Referenz der BigQuery-Tabelle, in der die Endergebnisse der Datenqualitätsprüfungen gespeichert werden. Verwenden Sie nicht den ID-Wert `dq_summary`, da er für interne Verarbeitungsaufgaben reserviert ist.
`--summary_to_stdout`	(Optional) Wenn dieses Flag übergeben wird, werden alle bei der letzten Ausführung in der Tabelle `dq_summary` erstellten Validierungsergebniszeilen als JSON-Einträge in Cloud Logging und `stdout` protokolliert.

Hinweis: Die Dataplex-Datenqualitätsaufgabe wird standardmäßig im Default-Netzwerk ausgeführt. Sie können das Netzwerk mit einem der Argumente --vpc-network-name oder --vpc-sub-network-name ändern. Hier erfahren Sie, wie Sie diese Argumente festlegen.

API

Ersetzen Sie Folgendes:

PROJECT_ID = "Your Dataplex Project ID"
REGION = "Your Dataplex lake region"
LAKE_ID = "Your Dataplex lake ID"
SERVICE_ACC = "Your service account used for reading the data"
DATAPLEX_TASK_ID = "Unique task ID for the data quality task"
BUCKET_NAME = "Your Cloud Storage bucket name containing the CloudDQ configs or YAML specification"
GCP_BQ_BILLING_PROJECT_ID = "Your BigQuery billing project"
GCP_BQ_REGION_ID = "Your BigQuery dataset region ID" #Optional
GCP_BQ_DATASET_ID = "Your BigQuery dataset to store the data quality summary results"
TARGET_TABLE_NAME = "Your target table name to store the results in BigQuery dataset"

Senden Sie eine HTTP-POST-Anfrage:

POST https://dataplex.googleapis.com/v1/projects/${PROJECT_ID}/locations/${REGION}/lakes/${LAKE_ID}/tasks?task_id=${DATAPLEX_TASK_ID}
{
"spark": {
    "python_script_file": f"gs://dataplex-clouddq-artifacts-us-central1/clouddq_pyspark_driver.py",
    "file_uris": [  f"gs://dataplex-clouddq-artifacts-us-central1/clouddq-executable.zip",
                    f"gs://dataplex-clouddq-artifacts-us-central1/clouddq-executable.zip.hashsum",
                    f"gs://dataplex-clouddq-artifacts-us-central1/your-clouddq-configs.zip"
                ]
},
"execution_spec": {
    "args": {
        "TASK_ARGS":f"clouddq-executable.zip, ALL, gs://BUCKET_NAME/your-clouddq-configs.zip, --gcp_project_id=${GCP_BQ_BILLING_PROJECT_ID}, --gcp_region_id=${GCP_BQ_REGION_ID}, --gcp_bq_dataset_id=${GCP_BQ_DATASET_ID}, --target_bigquery_summary_table=${GCP_BQ_BILLING_PROJECT_ID}.${GCP_BQ_DATASET_ID}.${TARGET_TABLE_NAME}"
    },
    "service_account": "SERVICE_ACC"
},
"trigger_spec": {
"type": "ON_DEMAND"
},
"description": "${DATAPLEX_TASK_DESCRIPTION}"
}

Weitere Informationen finden Sie unter Beispiel für einen Airflow-DAG für die Dataplex-Datenqualitätsaufgabe.

Geplante Datenqualitätsaufgabe überwachen

Weitere Informationen zum Überwachen von Aufgaben

Ergebnisse aufrufen

Die Ergebnisse der Datenqualitätsprüfungen werden im BigQuery-Dataset und in der Übersichtstabelle gespeichert, die Sie angegeben haben, wie unter Dataset zum Speichern der Ergebnisse erstellen beschrieben. Die Übersichtstabelle enthält die Ausgabezusammenfassung für jede Kombination aus Regelbindung und Regel für jede Validierungsausführung. Die Ausgabe der Übersichtstabelle enthält die folgenden Informationen:

Spaltenname	Beschreibung
`dataplex_lake`	(String) ID des Dataplex-Lake, der die zu validierende Tabelle enthält.
`dataplex_zone`	(String) ID der Dataplex-Zone, die die zu validierende Tabelle enthält.
`dataplex_asset_id`	(String) ID des Dataplex-Assets, das die zu validierende Tabelle enthält.
`execution_ts`	(timestamp) Zeitstempel der Ausführung der Validierungsabfrage.
`rule_binding_id`	(String) ID der Regelbindung, für die Validierungsergebnisse gemeldet werden.
`rule_id`	(String) ID der Regel unter der Regelbindung, für die Validierungsergebnisse gemeldet werden.
`dimension`	(String) Dimension der Datenqualität für `rule_id`. Dieser Wert kann nur einer der Werte sein, die im YAML-Knoten `rule_dimensions` angegeben sind.
`table_id`	(String) ID der Entität, für die Validierungsergebnisse gemeldet werden. Diese ID wird unter dem Parameter `entity` der jeweiligen Regelbindung angegeben.
`column_id`	(String) ID der Spalte, für die Validierungsergebnisse gemeldet werden. Diese ID wird unter dem Parameter `column` der jeweiligen Regelbindung angegeben.
`last_modified`	(Zeitstempel) Der zuletzt geänderte Zeitstempel des zu validierenden `table_id`.
`metadata_json_string`	(String) Schlüssel/Wert-Paare des Metadatenparameterinhalts, der in der Regelbindung oder während der Datenqualitätsausführung angegeben wurde.
`configs_hashsum`	(String) Die Hash-Summe des JSON-Dokuments, das die Regelbindung und alle zugehörigen Regeln, Regelbindungen, Zeilenfilter und Entitätskonfigurationen enthält. `configs_hashsum` ermöglicht das Tracking, wenn sich der Inhalt einer `rule_binding`-ID oder einer ihrer referenzierten Konfigurationen geändert hat.
`dq_run_id`	(String) Eindeutige ID des Datensatzes.
`invocation_id`	(String) ID der Datenqualitätsausführung. Alle Datenqualitätszusammenfassungen, die innerhalb derselben Datenqualitätsinstanz generiert wurden, haben denselben `invocation_id`.
`progress_watermark`	(Boolesch) Legt fest, ob dieser besondere Datensatz von der Datenqualitätsprüfung berücksichtigt wird, um die Hochmarke für die inkrementelle Validierung zu ermitteln. Bei `FALSE` wird der entsprechende Eintrag ignoriert, wenn der Wert für die Hochmarke festgelegt wird. Diese Informationen sind nützlich, wenn Sie Qualitätsprüfungen für Tests machen, die die Hochmarke nicht erhöhen sollen. Dataplex füllt dieses Feld standardmäßig mit `TRUE` aus. Der Wert kann jedoch überschrieben werden, wenn das `--progress_watermark`-Argument den Wert `FALSE` hat.
`rows_validated`	(Ganzzahl) Gesamtzahl der Datensätze, die nach dem Anwenden von `row_filters` und möglichen Hochmarken-Filtern auf die `incremental_time_filter_column_id`-Spalte validiert wurden, falls angegeben.
`complex_rule_validation_errors_count`	(Gleitkommazahl) Anzahl der Zeilen, die von einer `CUSTOM_SQL_STATEMENT`-Regel zurückgegeben werden.
`complex_rule_validation_success_flag`	(Boolesch) Erfolgsstatus von `CUSTOM_SQL_STATEMENT` Regeln.
`success_count`	(Ganzzahl) Gesamtzahl der Datensätze, die die Validierung bestanden haben. Dieses Feld ist für `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`success_percentage`	(Gleitkommazahl) Prozentsatz der Anzahl der Datensätze, die die Validierung innerhalb der Gesamtzahl der validierten Datensätze bestanden haben. Dieses Feld ist für `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`failed_count`	(Ganzzahl) Gesamtzahl der Datensätze, bei denen die Validierung fehlgeschlagen ist. Dieses Feld ist für `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`failed_percentage`	(Gleitkommazahl) Prozentsatz der Anzahl der Datensätze, die die Validierung innerhalb der Gesamtzahl der validierten Datensätze nicht bestanden haben. Dieses Feld ist für `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`null_count`	(Ganzzahl) Gesamtzahl der Datensätze, die während der Validierung null zurückgegeben haben. Dieses Feld ist für `NOT_NULL`- und `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`null_percentage`	(Gleitkommazahl) Prozentsatz der Anzahl der Datensätze, die während der Validierung innerhalb der Gesamtzahl der validierten Datensätze null zurückgegeben haben. Dieses Feld ist für `NOT_NULL`- und `CUSTOM_SQL_STATEMENT`-Regeln auf `NULL` gesetzt.
`failed_records_query`	In dieser Spalte wird für jede Regel, die fehlschlägt, eine Abfrage gespeichert, mit der Sie fehlgeschlagene Einträge abrufen können. In diesem Dokument finden Sie unter Fehlerhafte Regeln mit `failed_records_query` Fehler beheben.

Für BigQuery-Entitäten wird für jede rule_binding eine Ansicht erstellt, die die SQL-Validierungslogik der letzten Ausführung enthält. Sie finden diese Ansichten in dem BigQuery-Dataset, das im Argument --gcp-bq-dataset-id angegeben ist.

Kostenoptimierung

Mit den folgenden Optimierungen können Sie Ihre Kosten senken.

Inkrementelle Validierungen

Es gibt oft Tabellen, die regelmäßig mit neuen Partitionen (neue Zeilen) aktualisiert werden. Wenn Sie die alten Partitionen nicht bei jeder Ausführung neu validieren möchten, können Sie inkrementelle Validierungen verwenden.

Für inkrementelle Validierungen muss die Tabelle eine Spalte vom Typ TIMESTAMP oder DATETIME enthalten, in der der Spaltenwert monoton zunimmt. Sie können die Spalten verwenden, nach denen Ihre BigQuery-Tabelle partitioniert ist.

Geben Sie zur Angabe der inkrementellen Validierung einen Wert für incremental_time_filter_column_id=TIMESTAMP/DATETIME type column als Teil einer Regelbindung an.

Wenn Sie eine Spalte angeben, berücksichtigt die Datenqualitätsaufgabe nur Zeilen mit einem TIMESTAMP-Wert, der größer als der Zeitstempel der letzten ausgeführten Datenqualitätsaufgabe ist.

Beispielspezifikationsdateien

Wenn Sie diese Beispiele verwenden möchten, erstellen Sie ein BigQuery-Dataset mit dem Namen sales. Erstellen Sie dann eine Faktentabelle mit dem Namen sales_orders und fügen Sie Beispieldaten hinzu. Dazu führen Sie eine Abfrage mit den folgenden GoogleSQL-Anweisungen aus:

CREATE OR REPLACE TABLE sales.sales_orders
(
 id STRING NOT NULL,
 last_modified_timestamp TIMESTAMP,
 customer_id STRING,
 item_id STRING,
 amount NUMERIC,
 transaction_currency STRING
);

INSERT INTO sales.sales_orders
(id, last_modified_timestamp, customer_id, item_id, amount, transaction_currency)
VALUES
("order1",CURRENT_TIMESTAMP(),"customer1","ASDWQ123456789012345",100,"USD"),
("order1",CURRENT_TIMESTAMP(),"customer2","bad_item_id",-10,"XXX"),
("order2",CURRENT_TIMESTAMP(),"customer3","INTNL987654321098765",50,"GBP"),
("order3",CURRENT_TIMESTAMP(),"customer4","INTNL932716428593847",50,"GBP")

Beispiel 1

Im folgenden Codebeispiel werden Datenqualitätsprüfungen zur Validierung dieser Werte erstellt:

amount: Werte sind null oder positive Zahlen.
item_id: Ein alphanumerischer String mit 5 alphabetischen Zeichen, gefolgt von 15 Ziffern.
transaction_currency: Ein zulässiger Währungstyp, wie durch eine statische Liste definiert. In der statischen Liste dieses Beispiels sind GBP und JPY als Währungstypen zulässig. Diese Validierung gilt nur für Zeilen, die als international markiert sind.

# The following `NONE` row filter is required.
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 # This filters for rows marked as international (INTNL).
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# Rule dimensions are optional but let you aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can apply to multiple tables or columns.
rules:
 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

# Rule bindings associate rules to columns within tables.
rule_bindings:
  TRANSACTION_AMOUNT_VALID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

  TRANSACTION_VALID_ITEM_ID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

  TRANSACTION_CURRENCY_VALID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

Ersetzen Sie Folgendes:

PROJECT_ID: Ihre Projekt-ID.
DATASET_ID: Die Dataset-ID.

Sample 2

Wenn die zu prüfende Tabelle Teil eines Dataplex-Lakes ist, können Sie die Tabellen in Lake- oder Zonennotation angeben. So können Sie Ihre Ergebnisse nach Lake oder Zone aggregieren. Sie können beispielsweise einen Score auf Zonenebene generieren.

Wenn Sie dieses Beispiel verwenden möchten, erstellen Sie einen Dataplex-Lake mit der Lake-ID operations und der Zonen-ID procurement. Fügen Sie der Zone dann die Tabelle sales_orders als Asset hinzu.

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}
rule_bindings:
 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

Ersetzen Sie Folgendes:

PROJECT_ID: Ihre Projekt-ID.
REGION_ID: die Regions-ID des Dataplex-Lakes, in dem die Tabelle vorhanden ist, z. B. us-central1.

Beispiel 3

In diesem Beispiel wird Beispiel 2 um eine benutzerdefinierte SQL-Prüfung erweitert, um festzustellen, ob die ID-Werte eindeutig sind.

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
# This rule is parameterized with column_names as parameter
 NO_DUPLICATES_IN_COLUMN_GROUPS:
   rule_type: CUSTOM_SQL_STATEMENT
   dimension: duplication
   params:
     custom_sql_arguments:
       - column_names
     custom_sql_statement: |-
       select a.*
       from data a
       inner join (
         select
           $column_names
         from data
         group by $column_names
         having count(*) > 1
       ) duplicates
       using ($column_names)

 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}

rule_bindings:
 TRANSACTIONS_UNIQUE:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: id
   row_filter_id: NONE
   rule_ids:
     - NO_DUPLICATES_IN_COLUMN_GROUPS:
         column_names: "id"

 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

Beispiel 4

In diesem Beispiel werden in Beispiel 3 inkrementelle Validierungen mithilfe der Spalte last_modified_timestamp hinzugefügt. Sie können inkrementelle Validierungen für eine oder mehrere Regelbindungen hinzufügen.

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
# This rule is parameterized with column_names as parameter
 NO_DUPLICATES_IN_COLUMN_GROUPS:
   rule_type: CUSTOM_SQL_STATEMENT
   dimension: duplication
   params:
     custom_sql_arguments:
       - column_names
     custom_sql_statement: |-
       select a.*
       from data a
       inner join (
         select
           $column_names
         from data
         group by $column_names
         having count(*) > 1
       ) duplicates
       using ($column_names)

 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}

rule_bindings:
 TRANSACTIONS_UNIQUE:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: id
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - NO_DUPLICATES_IN_COLUMN_GROUPS:
         column_names: "id"

 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: amount
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: item_id
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALID_CURRENCY_ID

Fehlgeschlagene Regeln mit `failed_records_query` beheben

Für jede Regel, die fehlschlägt, speichert die Übersichtstabelle in der Spalte failed_records_query eine Abfrage, mit der Sie fehlgeschlagene Einträge abrufen können.

Zum Debuggen können Sie auch reference columns in Ihrer YAML-Datei verwenden, um die Ausgabe von failed_records_query mit den Originaldaten zu verknüpfen, um den gesamten Eintrag zu erhalten. Sie können beispielsweise eine primary_key-Spalte oder eine zusammengesetzte primary_key-Spalte als Referenzspalte angeben.

Hinweis: Fehlgeschlagene Eintragsabfragen verwenden nicht reference_columns für CUSTOM_SQL_STATEMENT-Regeln. Die Ausgabe der Abfrage für fehlgeschlagene Einträge hängt von der Abfrage in CUSTOM_SQL_STATEMENT selbst ab. Wenn Sie beispielsweise eine Referenzspalte in der Abfrage fehlgeschlagener Datensätze für eine CUSTOM_SQL_STATEMENT-Regel benötigen, müssen Sie die Spalte auch in die SQL-Anweisung aufnehmen. Weitere Informationen finden Sie unter Abfragen von fehlgeschlagenen Datensätzen für CUSTOM_SQL_STATEMENT-Regeln verwenden.

Referenzspalten angeben

Zum Generieren von Referenzspalten können Sie Ihrer YAML-Spezifikation Folgendes hinzufügen:

Der Abschnitt reference_columns. In diesem Abschnitt können Sie einen oder mehrere Referenzspaltensätze erstellen, wobei jeder Satz eine oder mehrere Spalten angibt.
Der Abschnitt rule_bindings. In diesem Abschnitt können Sie einer Regelbindung eine Zeile hinzufügen, in der eine Referenzspalten-ID (reference_columns_id) für die Regeln in dieser Regelbindung angegeben wird. Es sollte einer der im Abschnitt reference_columns angegebenen Referenzspaltensätze sein.

Die folgende YAML-Datei gibt beispielsweise einen reference_columns-Abschnitt an und definiert drei Spalten: id, last_modified_timestamp und item_id als Teil des Satzes ORDER_DETAILS_REFERENCE_COLUMNS. Im folgenden Beispiel wird die Beispieltabelle sales_orders verwendet.

reference_columns:
  ORDER_DETAILS_REFERENCE_COLUMNS:
    include_reference_columns:
      - id
      - last_modified_timestamp
      - item_id
rules:
  VALUE_ZERO_OR_POSITIVE:
  rule_type: CUSTOM_SQL_EXPR
  params:
    custom_sql_expr: |-

row_filters:
NONE:
  filter_sql_expr: |-
      True

rule_bindings:
TRANSACTION_AMOUNT_VALID:
  entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
  column_id: amount
  row_filter_id: NONE
  reference_columns_id: ORDER_DETAILS_REFERENCE_COLUMNS
  rule_ids:
    - VALUE_ZERO_OR_POSITIVE

Abfrage für fehlgeschlagene Einträge verwenden

Die Abfrage für fehlgeschlagene Einträge generiert eine Zeile für jeden Eintrag, für den eine Regel fehlgeschlagen ist. Sie enthält den Spaltennamen, der den Fehler ausgelöst hat, den Wert, der den Fehler ausgelöst hat, und die Werte für die Referenzspalten. Außerdem enthält sie Metadaten, mit denen Sie sich auf die Ausführung der Datenqualitätsaufgabe beziehen können.

Im Folgenden finden Sie ein Beispiel für die Ausgabe einer fehlgeschlagenen Datensatzabfrage für die YAML-Datei, die unter Referenzspalten angeben beschrieben wird. Hier wird ein Fehler für die Spalte amount und der fehlgeschlagene Wert -10 angezeigt. Außerdem wird der entsprechende Wert für die Referenzspalte erfasst.

_dq_validation_invocation_id	_dq_validation_rule_binding_id	_dq_validation_rule_id	_dq_validation_column_id	_dq_validation_column_value	_dq_validation_dimension	_dq_validation_simple_rule_row_is_valid	_dq_validation_complex_rule_validation_errors_count	_dq_validation_complex_rule_validation_success_flag	id	last_modified_timestamp	item_id
10a25be9-8dfa-446c-a42c-75f6bb4a49d9	TRANSACTION_AMOUNT_VALID	VALUE_ZERO_OR_POSITIVE	Menge	-10		FALSE			order1	2022-01-22T02:30:06.321Z	bad_item_id

Fehlgeschlagene Datensatzabfragen für CUSTOM_SQL_STATEMENT-Regeln verwenden

Bei CUSTOM_SQL_STATEMENT-Regeln enthalten fehlgeschlagene Datensatzabfragen die custom_sql_statement_validation_errors-Spalte. Die custom_sql_statement_validation_errors-Spalte ist eine verschachtelte Spalte mit Feldern, die der Ausgabe Ihrer SQL-Anweisung entsprechen. Referenzspalten sind nicht Teil der fehlgeschlagenen Datensatzabfragen für CUSTOM_SQL_STATEMENT-Regeln.

Ihre CUSTOM_SQL_STATEMENT-Regel könnte beispielsweise so aussehen:

rules:
  TEST_RULE:
    rule_type: CUSTOM_SQL_STATEMENT
    custom_sql_arguments:
      - existing_id
      - replacement_id
    params:
     CUSTOM_SQL_STATEMENT: |-
       (SELECT product_name, product_key FROM data
       where $existing_id != $replacement_id)

Die Ergebnisse für dieses Beispiel enthalten eine oder mehrere Zeilen für die Spalte custom_sql_statement_validation_errors mit einer Zeile für jedes Vorkommen, in dem existing_id!=replacement_id vorhanden ist.

In JSON kann der Inhalt einer Zelle in dieser Spalte so aussehen:

{
  "custom_sql_statement_valdation_errors" :{
    "product_name"="abc"
    "product_key"="12345678"
    "_rule_binding_id"="your_rule_binding"
  }
}

Sie können diese Ergebnisse mit der Originaltabelle mit einer verschachtelten Referenz wie join on custom_sql_statement_valdation_errors.product_key verknüpfen.

Nächste Schritte

Referenz zur YAML-Spezifikation von CloudDQ
Beispiele für Datenqualitätsregeln: siehe Einfache Regeln oder Erweiterte Regeln
Beispiel-Airflow-DAG für die Dataplex-Datenqualitätsaufgabe

Datenqualitätsaufgaben verwenden

Hinweise

Google APIs und Google-Dienste aktivieren

Spezifikationsdatei erstellen

Informationen zur Spezifikationsdatei

Dataset zum Speichern der Ergebnisse erstellen

Dienstkonto erstellen

Optional: Erweiterte Einstellungen verwenden

Beschränkungen

Datenqualitätsaufgabe planen

Console

gcloud-CLI

API

Geplante Datenqualitätsaufgabe überwachen

Ergebnisse aufrufen

Kostenoptimierung

Inkrementelle Validierungen

Beispielspezifikationsdateien

Beispiel 1

Sample 2

Beispiel 3

Beispiel 4

Fehlgeschlagene Regeln mit failed_records_query beheben

Referenzspalten angeben

Abfrage für fehlgeschlagene Einträge verwenden

Fehlgeschlagene Datensatzabfragen für CUSTOM_SQL_STATEMENT-Regeln verwenden

Nächste Schritte

Fehlgeschlagene Regeln mit `failed_records_query` beheben