Diese Seite wurde von der Cloud Translation API übersetzt.

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 externe BigQuery-Tabellen.

Weitere Informationen finden Sie unter Aufgaben zur Datenqualität: Übersicht

Hinweise

In diesem Dokument wird davon ausgegangen, dass Sie einen vorhandenen Dataplex-Lake haben, um die Aufgabe zur Datenqualität erstellen.

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
Privaten Google-Zugriff aktivieren für Ihr Netzwerk und/oder Subnetzwerk. Privaten Google-Zugriff aktivieren für Das Netzwerk, das Sie mit der Dataplex-Datenqualität verwenden möchten Aufgaben. Wenn Sie beim Erstellen der Funktion Dataplex-Datenqualitätsaufgabe, Dataplex verwendet die Standardsubnetz zu ändern. In diesem Fall müssen Sie Privater Google-Zugriff im Standardsubnetz

Spezifikationsdatei erstellen

Dataplex verwendet Open-Source-CloudDQ als das Treiberprogramm. Anforderungen für Dataplex-Datenqualitätsprüfungen in CloudDQ-YAML-Spezifikationsdateien definiert sind.

Als Eingabe für die Datenqualitätsaufgabe können Sie eine einzelne YAML-Datei oder ein einzelnes ZIP-Archiv verwenden die eine oder mehrere YAML-Dateien enthalten. Es ist empfohlen, die Anforderungen an die Datenqualitätsprüfung in einer separaten YAML-Spezifikation zu erfassen -Dateien mit einer Datei pro Abschnitt.

So bereiten Sie eine Spezifikationsdatei vor:

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

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

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 erstellen und REGEX, oder Sie können sie durch benutzerdefinierte SQL-Anweisungen wie CUSTOM_SQL_EXPR und CUSTOM_SQL_STATEMENT. 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 zulässigen Liste mit Dimensionen für Datenqualitätsregeln, die eine Regel in der entsprechenden dimension.

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 in der CloudDQ-Referenzhandbuch und die Beispieldateienspezifikationen.

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 befinden wie die Tabellen, für die Sie die Aufgabe zur Datenqualität ausführen.

Dataplex verwendet dieses Dataset und erstellt oder wiederverwendet eine Tabelle Ihrer Wahl, um um die Ergebnisse zu speichern.

Dienstkonto erstellen

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

Lesezugriff auf den Cloud Storage-Pfad mit der YAML-Datei Spezifikationen. 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 zum Erstellen einer Tabelle (falls erforderlich) und schreiben Sie die Ergebnisse in diese Tabelle. 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 dem Nutzer, 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 im aktuellen Nutzerprojekt Datenqualitätsprüfungen durch ist standardmäßig aktiviert. 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 in derselben Google Cloud-Region.

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.
Gehen Sie im Abschnitt Spezifikation der Datenqualität so vor: <ph type="x-smartling-placeholder">
1. Klicken Sie im Feld 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. Verwende nicht den Namen dq_summary, da er für interne Verarbeitungsaufgaben reserviert ist.
Wählen Sie im Abschnitt Dienstkonto ein Dienstkonto aus der Dienstkonto des Nutzers:
Klicken Sie auf Weiter.
Konfigurieren Sie im Bereich Zeitplan festlegen den Zeitplan für die Ausführung der Daten. und Qualitätssicherung.
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 wurde. Dieser Dienst muss aktiviert sein Konto hat ausreichende IAM-Berechtigungen, wie hier beschrieben im Abschnitt Vorbereitung.

Für --execution-args müssen die folgenden Argumente als Positionierte Argumente und somit in dieser Reihenfolge:

Argument	Beschreibung
`clouddq-executable.zip`	Eine vorkompilierte ausführbare Datei, die übergeben wurde `spark-file-uris` aus einem öffentlichen Cloud Storage Bucket.
`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` übereinstimmen und `target_bigquery_summary_table`.
`gcp-bq-dataset-id`	BigQuery-Dataset, das zum Speichern der `rule_binding`-Ansichten und der Zwischendaten der Zusammenfassung der Datenqualität.
`target-bigquery-summary-table`	Tabellen-ID-Referenz der BigQuery-Tabelle, in der der Wert werden die endgültigen Ergebnisse der Datenqualitätsprüfungen gespeichert. 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 Validierungsergebniszeilen die bei der letzten Ausführung in der Tabelle `dq_summary` erstellt wurden, werden als JSON-Datensätze in Cloud Logging `stdout`.

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

API

Dabei gilt:

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-Airflow-DAG für die Dataplex-Datenqualitätsaufgabe.

Geplante Datenqualitätsaufgabe überwachen

Weitere Informationen zum Überwachen Ihrer Aufgabe

Ergebnisse aufrufen

Die Ergebnisse der Datenqualitätsvalidierungen werden im BigQuery-Dataset gespeichert und die Übersichtstabelle, die Sie angegeben haben, Erstellen Sie ein Dataset zum Speichern der Ergebnisse. Die Übersichtstabelle enthält Zusammenfassung der Ausgabe für jede Kombination aus Regelbindung und Regel für jede Validierung ausführen. Die Ausgabe in 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 Tabelle enthält zu überprüfen.
`dataplex_asset_id`	(String) ID des Dataplex-Assets, das die Tabelle enthält zu überprüfen.
`execution_ts`	(Zeitstempel) Zeitstempel für die Ausführung der Validierungsabfrage.
`rule_binding_id`	(String) ID der Regelbindung, für die Validierungsergebnisse angezeigt werden gemeldet.
`rule_id`	(String) ID der Regel unter der Regelbindung, für die eine Validierung gilt Ergebnisse gemeldet werden.
`dimension`	(String) Datenqualitätsdimension von `rule_id`. Dieser Wert kann nur einer der Werte, die im YAML-Knoten `rule_dimensions` angegeben sind.
`table_id`	(String) ID der Entität, für die Validierungsergebnisse gemeldet werden. Diese ID wird im Parameter `entity` der entsprechenden Regelbindung.
`column_id`	(String) ID der Spalte, für die Validierungsergebnisse gemeldet werden. Diese ID wird im Parameter `column` der entsprechenden Regelbindung.
`last_modified`	(Zeitstempel) Der Zeitstempel der letzten Änderung von `table_id` zu überprüfen.
`metadata_json_string`	(String) Schlüssel/Wert-Paare des angegebenen Metadatenparameterinhalts oder während der Datenqualitätsausführung.
`configs_hashsum`	(String) Die Hash-Summe des JSON-Dokuments, das die Regelbindung enthält sowie alle zugehörigen Regeln, Regelbindungen, Zeilenfilter und Entitätskonfigurationen. `configs_hashsum` ermöglicht das Tracking, Die `rule_binding`-ID oder eine der Konfigurationen, auf die verwiesen wird, wurde geändert.
`dq_run_id`	(String) Eindeutige ID des Eintrags.
`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 auf `NULL` für `CUSTOM_SQL_STATEMENT` Regeln.
`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 auf `NULL` für `CUSTOM_SQL_STATEMENT` Regeln.
`null_count`	(Ganzzahl) Gesamtzahl der Datensätze, die während der Validierung Null zurückgegeben haben. Dieses Feld ist auf `NULL` für `NOT_NULL` und `CUSTOM_SQL_STATEMENT`-Regeln.
`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 auf `NULL` für `NOT_NULL` und `CUSTOM_SQL_STATEMENT`-Regeln.
`failed_records_query`	Für jede fehlgeschlagene Regel wird in dieser Spalte eine Abfrage gespeichert, mit denen fehlgeschlagene Einträge abgerufen werden können. In diesem Dokument Fehlerbehebung bei fehlgeschlagenen Regeln mit `failed_records_query`

Bei BigQuery-Entitäten wird für jede rule_binding mit der SQL-Validierungslogik von der letzten Ausführung. Diese Ansichten finden Sie in der BigQuery- Dataset, das im Argument --gcp-bq-dataset-id angegeben ist.

Kostenoptimierung

Mit den folgenden Optimierungen können Sie die 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 müssen Sie eine Spalte vom Typ TIMESTAMP oder DATETIME haben in der Tabelle an, bei der der Spaltenwert monoton ansteigt. Sie können die Spalten, nach denen Ihre BigQuery-Tabelle partitioniert ist.

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

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

Beispiel für Spezifikationsdateien

Erstellen Sie ein BigQuery-Dataset, um diese Beispiele zu verwenden. mit dem Namen sales. Erstellen Sie dann eine Faktentabelle mit dem Namen sales_orders und fügen Sie Beispieldaten nach Abfrage ausführen durch die folgenden GoogleSQL-Anweisungen:

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 Werte:

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 zu einem Dataplex-Lake gehört, haben Sie folgende Möglichkeiten: geben Sie die Tabellen in der Lake- oder Zonen-Notation an. Auf diese Weise können Sie nach Lake oder Zone sortiert. Sie können beispielsweise eine Punktzahl auf Zonenebene generieren.

Erstellen Sie einen Dataplex-Lake mit der Lake-ID, um dieses Beispiel zu verwenden operations und die Zonen-ID procurement. Fügen Sie dann die Tabelle sales_orders hinzu. als Asset für die Zone festlegen.

# 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-Lake, 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 wird Beispiel 3 um inkrementelle Validierungen mit der Methode last_modified_timestamp. Sie können inkrementelle Validierungen für eine oder mehr Regelbindungen.

# 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

Fehler bei Regeln mit `failed_records_query` beheben

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

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

Hinweis: Fehlgeschlagene Eintragsabfragen verwenden nicht reference_columns für CUSTOM_SQL_STATEMENT-Regeln. Die Ausgabe der Abfrage für fehlgeschlagene Einträge hängt vom Abfrage in CUSTOM_SQL_STATEMENT selbst. 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 ein oder mehrere Referenzspaltensätze, wobei jeder Satz eine oder mehrere Spalten angibt.
Der Abschnitt rule_bindings. In diesem Abschnitt können Sie einer Regel eine Zeile hinzufügen, Bindung, die eine Referenzspalten-ID (reference_columns_id) angibt, die für die in dieser Regelbindung. Es sollte eine der Referenzspalten sein, die im reference_columns Abschnitt.

Die folgende YAML-Datei gibt beispielsweise einen reference_columns-Abschnitt und einen definiert drei Spalten: id, last_modified_timestamp und item_id als Teil des ORDER_DETAILS_REFERENCE_COLUMNS-Satzes. Die 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 Datensätze generiert eine Zeile für jeden Datensatz mit einer Regel, die fehlgeschlagen. Sie enthält den Namen der Spalte, die den Fehler ausgelöst hat, den Wert, den Fehler und die Werte für die Referenzspalten ausgelöst. Außerdem enthält sie Metadaten, mit denen Sie sich auf die Ausführung der Datenqualitätsaufgabe beziehen können.

Das folgende Beispiel zeigt die Ausgabe einer fehlgeschlagenen Datensatzabfrage für die YAML-Datei. wie unter Referenzspalten angeben beschrieben. Es wird eine Fehler für Spalte amount und fehlgeschlagener Wert von -10. Außerdem zeichnet er den entsprechenden Wert für die Referenzspalte.

_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 in diesem Beispiel werden eine oder mehrere Zeilen für die custom_sql_statement_validation_errors enthalten. Spalte mit einer Zeile für jedes Vorkommen, in dem existing_id!=replacement_id.

Bei der Darstellung im JSON-Format könnte der Inhalt einer Zelle in dieser Spalte wie folgt aussehen:

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

Sie können diese Ergebnisse über einen verschachtelten Verweis wie join on custom_sql_statement_valdation_errors.product_key mit der Originaltabelle verknüpfen.

Nächste Schritte

Referenz zur YAML-Spezifikation für CloudDQ
Beispiele für Regeln für die Datenqualität: siehe Einfache Regeln und 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

Beispiel für Spezifikationsdateien

Beispiel 1

Sample 2

Beispiel 3

Beispiel 4

Fehler bei 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

Fehler bei Regeln mit `failed_records_query` beheben