Datenqualitätsaufgaben verwenden

In diesem Dokument erfahren Sie, wie Sie Datenqualitätsaufgaben in Dataplex 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 Übersicht: Datenqualitätsaufgaben.

Hinweise

  1. die Dataproc API aktivieren

    API aktivieren

  2. 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 Datenqualitätsaufgaben von Dataplex verwenden möchten. Wenn Sie beim Erstellen der Datenqualitätsaufgabe von Dataplex 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 Open-Source-CloudDQ als Treiberprogramm. Anforderungen an die Datenqualitätsprüfung in Dataplex sind in CloudDQ-YAML-Spezifikationsdateien definiert. Sie können eine Spezifikationsdatei im YAML- oder ZIP-Format oder ein einzelnes ZIP-Archiv mit einer oder mehreren YAML-Dateien im Format .yml oder .yaml in einem Cloud Storage-Pfad erstellen.

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 (definiert im YAML-Knoten rule_dimensions): Definiert die zulässige Liste der Dimensionen für Datenqualitätsregeln, die eine Regel im entsprechenden dimension-Feld definieren kann.
    Beispiele: 
        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 zur YAML-Spezifikation finden Sie im Referenzhandbuch.

Als Eingabe für die Aufgabe zur Datenqualität können Sie eine einzelne YAML-Datei im Format .yml oder .yaml oder ein einzelnes ZIP-Archiv mit einer oder mehreren YAML-Dateien haben. Es wird empfohlen, die Anforderungen an die Datenqualitätsprüfung in separaten YAML-Spezifikationsdateien zu erfassen, mit einer Datei pro Abschnitt.

Beispiele finden Sie in den Spezifikationsdateien.

Ergebnisse speichern

Erstellen Sie ein BigQuery-Dataset, um die Ergebnisse zu speichern. Dataplex verwendet dieses Dataset und erstellt oder verwendet eine Tabelle Ihrer Wahl, um die Ergebnisse zu speichern.

Dienstkonto erstellen

Sie können ein Dienstkonto mit den folgenden IAM-Rollen und -Berechtigungen erstellen:

Optional: Erweiterte Einstellungen verwenden

Diese Schritte sind optional:

  1. 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.

  2. 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.
  • So vermeiden Sie Ausführungsfehler:
    • Die Tabelle, in der die Ausgabemesswerte gespeichert werden, befindet sich in derselben Google Cloud-Region.

Aufgabe für die Datenqualität planen

Console

  1. Rufen Sie in der Google Cloud Console die Dataplex-Seite Prozess auf.

    Zur Seite Prozess

  2. Klicken Sie auf Aufgabe erstellen.
  3. Klicken Sie auf der Karte Datenqualität prüfen auf Aufgabe erstellen.
  4. Wählen Sie für Dataplex-Lake Ihren Lake aus.
  5. Geben Sie für ID eine ID ein.
  6. Führen Sie im Abschnitt Datenqualitätsspezifikation folgende 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.

  7. Führen Sie im Abschnitt Ergebnistabelle die folgenden Schritte aus:

    1. Klicken Sie im Feld BigQuery-Dataset auswählen auf Durchsuchen.

    2. Wählen Sie das BigQuery-Dataset aus, in dem die Validierungsergebnisse gespeichert werden sollen.

    3. Klicken Sie auf Auswählen.

    Optional: Geben Sie anstelle des Suchens einen Namen in das Feld BigQuery-Tabelle ein. Wenn die Tabelle nicht vorhanden ist, wird sie von Dataplex erstellt.

  8. Wählen Sie im Bereich Dienstkonto aus dem Menü Nutzerdienstkonto ein Dienstkonto aus.

  9. Klicken Sie auf Weiter.

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="operations"

      # 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="data_quality_summary_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="data_quality_summary_dataset"

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

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

      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 genügend IAM-Berechtigungen hat, wie im Abschnitt Hinweise beschrieben.

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

Argument Beschreibung
clouddq-executable.zip Eine vorkompilierte ausführbare Datei, die in spark-file-uris aus 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, mit der die BigQuery-Abfragen ausgeführt werden.
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 Zwischenergebnisse der Datenqualität verwendet wird.
target-biggquery-summary-table Tabellen-ID-Referenz der BigQuery-Tabelle, in der die Endergebnisse der Datenqualitätsprüfungen gespeichert sind.
target-biggquery-summary-table Tabellen-ID-Referenz der BigQuery-Tabelle, in der die Endergebnisse der Datenqualitätsprüfungen gespeichert sind.
--summary_to_stdout (Optional) Wenn dieses Flag übergeben wird, werden alle in der Tabelle dq_summary bei der letzten Ausführung erstellten Validierungsergebniszeilen als JSON-Einträge in Cloud Logging und stdout protokolliert.

API

  1. 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 having 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 dq summary results"
          TARGET_TABLE_NAME = "Your target table name to store the results in BigQuery dataset"
  2. HTTP-POST-Anfrage senden: 
              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}"
          }

Siehe auch Beispiel für einen Airflow-DAG für die Dataplex-Datenqualitätsaufgabe.

Geplante Datenqualitätsaufgabe überwachen

Weitere Informationen zum Überwachen Ihrer Aufgabe

Ergebnisse aufrufen

In der Übersichtstabelle werden die Ergebnisse der Datenqualitätsprüfungen gespeichert. Sie enthält eine Ausgabezusammenfassung für die verschiedenen Kombinationen aus Regelbindung und Regel je Validierungsausführung. Die Ausgabe in der Übersichtstabelle ist so strukturiert:

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 mit der zu validierenden Tabelle.
execution_ts (Zeitstempel) Zeitstempel, der angibt, wann die Validierungsabfrage ausgeführt wurde.
rule_binding_id (String) Die 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) Datenqualitätsdimension von „rule_id“. Dies kann nur einer der Werte sein, die im YAML-Knoten rule_dimensions angegeben ist.
table_id (String) Die ID der Entität, für die Validierungsergebnisse gemeldet werden. Diese ID wird unter dem Parameter entity der jeweiligen Regelbindung angegeben.
column_id (String) Die ID der Spalte, für die Validierungsergebnisse gemeldet werden. Diese ID wird unter dem Parameter column der jeweiligen Regelbindung angegeben.
last_modified (Zeitstempel) Der Zeitstempel der letzten Änderung des table_id, das validiert wird.
metadata_json_string (String) Schlüssel/Wert-Paare des Metadatenparameterinhalts, die unter der Regelbindung oder während der Datenqualität angegeben sind.
configs_hashsum (String) Die Hash-Summe des JSON-Dokuments mit der Regelbindung und allen zugehörigen Regeln, Regelbindungen, Zeilenfiltern und Entitätskonfigurationen. code>configs_hashsum ermöglicht das Tracking, wenn der Inhalt einer rule_binding-ID oder einer der referenzierten Konfigurationen geändert wurde.
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 Einträge, 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, die nicht validiert werden konnten. 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 Einträge, die während der Überprüfung 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 Für jede fehlgeschlagene Regel wird in dieser Spalte eine Abfrage gespeichert, mit der Sie fehlerhafte Einträge abrufen können. In diesem Dokument findest du Informationen zur Fehlerbehebung mit failed_records_query.

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

Kostenoptimierung

Mithilfe der folgenden Optimierungen können Sie die Kosten senken.

Zusätzliche 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 in der Tabelle haben, bei der der Spaltenwert monoton steigt. Sie können die Spalten verwenden, in die Ihre BigQuery-Tabelle partitioniert ist.

Wenn Sie die inkrementelle Validierung festlegen möchten, geben Sie 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.

Nutzung von Slot-Reservierungen

Wenn Sie inkrementelle Validierungen verwenden, können Sie die Abfragezeit erheblich reduzieren. Aufgrund einer aktuellen Einschränkung werden Sie die verarbeiteten Byte jedoch nicht reduzieren. Daher empfehlen wir zum Sparen von Abfragekosten die Verwendung reservierter Slots.

Beispiel für Spezifikationsdateien

Erstellen Sie eine Faktentabelle sales_orders mit der folgenden Struktur:

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 zum Validieren 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
   # Replace <location-id> with your region.
   # Replace <dataset-id> with your dataset identifier.
   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
   # Replace <location-id> with your region.
   # Replace <dataset-id> with your dataset identifier.
   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
   # Replace <location-id> with your region.
   # Replace <dataset-id> with your dataset identifier.
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

Sample 2

Wenn die zu prüfende Tabelle Teil eines Dataplex-Sees ist, können Sie die Tabellen mit Lake- oder Zonennotation angeben. Auf diese Weise können Sie Ihre Ergebnisse nach See oder Zone aggregieren. Sie können beispielsweise einen Zonenwert generieren.

In diesem Beispiel wird davon ausgegangen, dass sich die Tabelle sales_order im Dataplex-See operations und in der Zone procurement befindet.

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: <project-id> # Replace "project-id" with your project ID.
   locations: <region-id> # Replace "region-id" with the region ID of the Dataplex lake in which the table exists. For example, us-central1.
   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 # replace "project-id" with your project ID and "region-id" with your region
   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

Beispiel 3

Dieses Beispiel verbessert Beispiel 2 durch Hinzufügen einer benutzerdefinierten SQL-Prüfung, 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> # Replace "project-id" with your project ID.
   locations: <region-id> # Replace "region-id" with the region ID of the Dataplex lake in which the table exists. For example, us-central1.
   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 # replace "project-id" with your project ID and "region-id" with your region
   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

Dieses Beispiel verbessert Beispiel 3 durch Hinzufügen zusätzlicher Validierungen mithilfe der Spalte last_modified_timestamp. 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> # Replace "project-id" with your project ID.
   locations: <region-id> # Replace "region-id" with the region ID of the Dataplex lake in which the table exists. For example, us-central1.
   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 # replace "project-id" with your project ID and "region-id" with your region
   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

Fehlerbehebung bei failed_records_query

Für jede fehlgeschlagene Regel wird in der Übersichtstabelle eine Abfrage in der Spalte failed_records_query gespeichert, mit der Sie fehlgeschlagene Datensätze abrufen können.

Sie können für die Fehlerbehebung auch reference columns in Ihrer YAML-Datei verwenden. Dadurch können Sie die Ausgabe von failed_records_query mit den Originaldaten zusammenführen, um den gesamten Eintrag abzurufen. Sie können beispielsweise eine primary_key-Spalte oder eine zusammengesetzte primary_key-Spalte als Referenzspalte angeben.

Referenzspalten angeben

Um Referenzspalten zu generieren, können Sie Ihrer YAML-Spezifikation Folgendes hinzufügen:

  1. Der Abschnitt reference_columns. In diesem Abschnitt können Sie einen oder mehrere Referenzspaltensätze erstellen, wobei jeder Satz eine oder mehrere Spalten angibt.

  2. Der Abschnitt rules_bindings. In diesem Abschnitt können Sie einer Regelbindung eine Zeile hinzufügen, die eine Referenzspalten-ID (reference_columns_id) angibt, die für die Regeln in dieser Regelbindung verwendet werden soll. Er sollte eine der Referenzspalten sein, die im Abschnitt reference_columns angegeben sind.

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 ORDER_DETAILS_REFERENCE_COLUMNS-Sets.



  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, der eine fehlgeschlagene Regel hat. 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.

Das folgende Beispiel zeigt die Ausgabe einer Abfrage zu fehlgeschlagenen Einträgen für die YAML-Datei, die unter Referenzspalten angeben beschrieben wird. Hier werden ein Fehler in der Spalte amount und ein fehlgeschlagener Wert von -10 angezeigt. Außerdem wird der entsprechende Wert für die Referenzspalte aufgezeichnet.

_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

Abfragen für fehlgeschlagene Einträge 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 enthalten eine oder mehrere Zeilen für die Spalte custom_sql_statement_validation_errors mit einer Zeile für jedes Auftreten mit existing_id!=replacement_id.

Beim Rendern im JSON-Format könnte 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 ursprünglichen Tabelle mit einer verschachtelten Referenz wie join on custom_sql_statement_valdation_errors.product_key zusammenführen.

Nächste Schritte