Data Lineage

Die Datenherkunft ist eine visuelle Karte, die den gesamten Lebenszyklus Ihrer Daten verfolgt. Sie zeigt, woher Ihre Daten stammen (der Ursprung), wohin sie übertragen werden (die Ziele) und alle Änderungen oder Transformationen, die auf dem Weg dorthin vorgenommen werden.

Sie können diese vollständige Karte des Datenflusses direkt in derGoogle Cloud -Konsole für Assets aufrufen, die in Produkten wie Knowledge Catalog (früher Dataplex Universal Catalog), BigQuery (einschließlich externer Tabellen, die für Iceberg REST Catalog erstellt wurden) und Vertex AI erstellt wurden. Da Workflows oft mehrere Regionen umfassen, unterstützt Knowledge Catalog die multiregionale Herkunft, die eine einheitliche Ansicht der Reise Ihrer Daten im globalen Google Cloud -Ökosystem bietet. Fortgeschrittene Nutzer können diese Informationen auch über die Data Lineage API abrufen.

Gründe für die Datenherkunft

Moderne Unternehmen verschieben und ändern ständig große Datenmengen. Beispielsweise können Sie Rohdaten zu Kundenkäufen in Berichte, Dashboards und Modelle für maschinelles Lernen umwandeln. Diese Komplexität stellt Ihr Team vor große Herausforderungen:

  • Vertrauen und Verifizierung. Datennutzer haben oft Schwierigkeiten, zu bestätigen, dass die Berichte und Zahlen, die sie sehen, korrekt sind und aus einer vertrauenswürdigen Quelle stammen.

  • Fehlerbehebung Wenn in einem Abschlussbericht ein Fehler auftritt, kann es für Datenteams schwierig und zeitaufwendig sein, das Problem über jeden Schritt bis zur Ursache zurückzuverfolgen.

  • Änderungsmanagement Bevor Daten geändert oder gelöscht werden (z. B. eine Spalte in einer Tabelle), müssen Teams alle nachgelagerten Berichte oder Modelle kennen, die auf diesen Daten basieren, um zu vermeiden, dass kritische Systeme beschädigt werden.

  • Compliance. Führungskräfte müssen wissen, wie sensible Daten (z. B. Kunden- oder Finanzinformationen) im gesamten Unternehmen verwendet werden, um gesetzliche Anforderungen zu erfüllen.

Die Datenherkunft löst diese Probleme, indem sie eine klare, visuelle und dokumentierte Darstellung des Wegs Ihrer Daten bietet. So können Sie Datenquellen nachvollziehen, Fehler verfolgen, die Auswirkungen von Änderungen bewerten und die Compliance aufrechterhalten.

Funktionsweise: Datenherkunft

Der Datenherkunfts-Workflow umfasst die folgenden Schritte:

  1. Datenquellen und -aufnahme: Herkunftsinformationen aus Ihren Datenquellen initiieren den gesamten Prozess.

    • Google Cloud -Dienste: Wenn die Data Lineage API aktiviert ist, melden unterstützte Dienste wie BigQuery und Dataflow automatisch Herkunftsereignisse, wenn Daten verschoben oder transformiert werden.

    • Benutzerdefinierte Quellen: Für alle Systeme, die nicht automatisch vonGoogle Cloud -Integrationen unterstützt werden, können Sie die Data Lineage API verwenden, um Informationen zur Datenherkunft manuell aufzuzeichnen. Wir empfehlen, Ereignisse zu importieren, die gemäß dem OpenLineage-Standard formatiert sind.

  2. Herkunftsplattform: Diese zentrale Plattform nimmt alle Herkunftsdaten auf, modelliert sie und speichert sie.

    • Data Lineage API: Diese API fungiert als einziger Einstiegspunkt für alle eingehenden Herkunftsinformationen. Es verwendet ein hierarchisches Datenmodell, das aus drei Kernkonzepten besteht: Prozess, Ausführung und Ereignis.

    • Verarbeitung und Speicherung: Die Plattform verarbeitet eingehende Daten und speichert sie in zuverlässigen, abfrageoptimierten Datenbanken.

  3. Nutzererfahrung: Sie können auf zwei Arten mit den gespeicherten Herkunftsinformationen interagieren:

    • Visuelle Untersuchung: In der Google Cloud Console ruft ein Frontend-Dienst die Herkunftsdaten ab und rendert sie als interaktives Diagramm oder Liste. Dies wird für Knowledge Catalog, BigQuery, Lakehouse (für Iceberg REST Catalog-Tabellen), die physische Ebene (Cloud Storage) und Vertex AI (für Modelle, Datasets, über Pipelines sowie Feature Store-Ansichten und Featuregruppen) unterstützt. Das ist ideal, um den Weg Ihrer Daten visuell zu erkunden.

    • Programmatischer Zugriff: Mit einem API-Client können Sie direkt mit der Data Lineage API kommunizieren, um die Verwaltung der Datenherkunft zu automatisieren. So können Sie Herkunftsinformationen aus benutzerdefinierten Quellen schreiben. Außerdem können Sie die gespeicherten Herkunftsdaten lesen und abfragen, um sie in anderen Anwendungen zu verwenden oder benutzerdefinierte Berichte zu erstellen.

Welche Methode sollte ich für die Datenherkunft verwenden?

Verwenden Sie die Methode SearchLinks, um sofortige Abfragen auf einer Ebene durchzuführen. Wenn Sie ein vollständiges Herkunftsdiagramm erstellen oder eine tiefgreifende Auswirkungsanalyse (bis zu 100 Ebenen) durchführen möchten, verwenden Sie die Methode SearchLineageStreaming.

Wählen Sie je nach Anwendungsfall die am besten geeignete Methode aus:

Funktion SearchLinks SearchLineageStreaming
Tiefe 1 Stufe (unmittelbare Nachbarn) Bis zu 100 Stufen
Ausführung Synchron Streaming in Echtzeit
Anwendungsfall Einfache Suchvorgänge für direkte Quellen oder Ziele Erstellen eines vollständigen Herkunftsdiagramms oder Durchführen einer Auswirkungsanalyse

Richtung bestimmen

  • Upstream (Ursprünge):
    • Legen Sie in SearchLinks das Feld target auf den FQN Ihres Assets fest.
    • Legen Sie in SearchLineageStreaming für direction den Wert UPSTREAM fest.
  • Downstream (Ziele):
    • Legen Sie in SearchLinks das Feld source auf den FQN Ihres Assets fest.
    • Legen Sie in SearchLineageStreaming für direction den Wert DOWNSTREAM fest.

Informationsmodell für die Datenherkunft

Die Datenherkunft ist ein Datensatz, der die Transformation von Daten von Quellen zu Zielen beschreibt. Die Data Lineage API erfasst diese Informationen und organisiert sie in einem hierarchischen Datenmodell, das die Konzepte von Prozessen, Ausführungen und Ereignissen verwendet.

Konzept Beschreibung
Prozess Eine Datentransformationsdefinition.
Laufen Eine Ausführung eines Prozesses.
Event Ein Datensatz der Datenbewegung während einer Ausführung.

Was ist ein Herkunftsprozess?

Ein Prozess ist die Definition eines Datentransformationsvorgangs für ein bestimmtes System. Für die BigQuery-Herkunft ist ein Prozess ein Job eines unterstützten Jobtyps. Alle Ausführungen derselben SQL-Abfrage sind mit einem einzigen Prozess verknüpft. So können Sie jede Instanz verfolgen, in der eine bestimmte Transformationslogik verwendet wird.

Die folgende SQL-Abfrage ist beispielsweise ein Prozess. Mit dieser Abfrage wird eine Tabelle erstellt, in der die Gesamtzahl der Fahrten für jeden Anbieter aus zwei Quelltabellen gezählt wird. 

  CREATE TABLE `dataplex-docs.data_lineage_demo.total_green_trips_22_21`
  AS
  SELECT
      vendor_id,
      COUNT(*) AS number_of_trips
  FROM
      (
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2022`
          UNION ALL
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2021`
      )
  GROUP BY
      vendor_id;

Das REST-Ressourcennamenformat für einen Prozess ist projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID.

Beispiel: projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6

Weitere Informationen zur Ressource process finden Sie in der Referenz zur Prozessressource.

Was ist ein Herkunftslauf?

Ein Run ist eine einzelne Ausführung eines Prozesses. Prozesse können mehrere Ausführungen haben.

Jeder Durchlauf ist ein eindeutiger Vorgang, der durch eine startTime, eine endTime und einen endgültigen Status wie COMPLETED, FAILED oder ABORTED gekennzeichnet ist.

Wenn Sie beispielsweise die SQL-Abfrage aus dem Abschnitt Verarbeiten um 9:00 Uhr ausführen, wird eine bestimmte Ausführung erstellt. Wenn Sie dieselbe Abfrage um 10:00 Uhr noch einmal ausführen, wird ein neuer, separater Durchlauf erstellt. Beide Ausführungen sind mit demselben übergeordneten Prozess verknüpft.

Das REST-Ressourcennamenformat für eine Ausführung zeigt, dass es sich um ein untergeordnetes Element eines Prozesses handelt: projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID/runs/RUN_ID.

Beispiel: projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6/runs/83dd03a51cd2ac80f465c9e267a950b1

Weitere Informationen zur Ressource run finden Sie in der Referenz zu Run-Ressourcen.

Was ist ein Herkunftsereignis?

Ein Ereignis stellt einen Zeitpunkt dar, zu dem eine Datentransformation Daten zwischen einer Quell- und einer Zielentität verschiebt. Ein Ereignis ist ein detaillierter Datensatz einer bestimmten Datenbewegung, die Quell- und Zieltabellen für eine bestimmte Ausführung verbindet. Ein Ereignis kann auch mehrere Quellen und Ziele haben.

Wenn Ihre Ausführung beispielsweise die im Abschnitt Verarbeiten beschriebene SQL-Abfrage ausführt, wird in einem Herkunftsereignis aufgezeichnet, dass die Quelltabellen nyc_green_trips_2021 und nyc_green_trips_2022 zum Erstellen der Zieltabelle total_green_trips_22_21 verwendet werden.

Ein Herkunftsereignis enthält eine Liste von Links, die die Quelle und das Ziel definieren. Ereignisse werden verwendet, um Herkunftsgrafiken zu erstellen. Obwohl die Google Cloud Console diese Herkunftsgrafiken darstellt, werden einzelne Ereignisse nicht direkt angezeigt. Mit der Data Lineage API können Sie Ereignisse erstellen, lesen und löschen, aber nicht aktualisieren.

Jede Verknüpfung in einem Ereignis definiert einen einzelnen Pfad des Datenflusses von einer Quellentität zu einer Zielentität. Eine Entität ist ein Verweis auf ein Daten-Asset, z. B. eine BigQuery-Tabelle, und wird durch ihren voll qualifizierten Namen (FQN) identifiziert. Ein einzelnes Ereignis kann mehrere Links enthalten. Das ist bei Vorgängen wie Tabellen-Joins üblich, bei denen mehrere Quellen zu einem Ziel beitragen.

Weitere Informationen dazu, wie Ereignisse die Herkunft auf Spaltenebene unterstützen, finden Sie unter Herkunft auf Spaltenebene.

Welche Datenquellen werden für die Datenherkunft unterstützt?

Sie können Herkunftsinformationen in Knowledge Catalog auf folgende Weise einfügen:

  • Automatisch aus integrierten Google Cloud Diensten
  • Manuell mit der Data Lineage API für benutzerdefinierte Quellen
  • Durch Importieren von Ereignissen aus OpenLineage

BigQuery

Wenn Sie die Datenherkunft in Ihrem BigQuery-Projekt aktivieren, zeichnet Knowledge Catalog automatisch Herkunftsinformationen für Folgendes auf:

BigQuery-Kopier-, Abfrage- und Ladejobs werden als Prozesse dargestellt.

Klicken Sie im Herkunftsdiagramm auf das Symbol Prozessdetails Prozessdetails., um die Prozessdetails aufzurufen.

Jeder Prozess enthält die BigQuery-job_id in der Liste attributes für den neuesten BigQuery-Job.

Weitere Dienste

Data Lineage unterstützt die Integration in die folgendenGoogle Cloud -Dienste:

  • Cloud Data Fusion

    Sie können das Herkunftstracking nicht nur auf Cloud Data Fusion beschränken, wenn die Data Lineage API in einem Projekt aktiviert ist.

  • Dataflow

    Sie können Herkunftsereignisse mit Dataflow-Jobs erfassen und in der Data Lineage API veröffentlichen.

  • Lakehouse für Iceberg-REST-Katalogtabellen

  • Looker (Google Cloud Core) (Vorabversion)

    Die Visualisierung von Looker (Google Cloud Core)-Metadaten aus BigQuery-Quellen mithilfe der Datenherkunft wird unterstützt. Die Datenherkunft muss auf der Ressourcenebene von Looker (Google Cloud Core) und auf der Dienstebene der Datenherkunft aktiviert sein.

  • Managed Service for Apache Airflow

    Managed Airflow verwendet die Integration der Datenherkunft auf Umgebungsebene. Die Datenherkunft wird automatisch für alle neuen Managed Airflow-Umgebungen aktiviert, die die Anforderungen erfüllen. Verwenden Sie für vorhandene Umgebungen die Umgebungseinstellungen, um die Integration der Datenherkunft zu aktivieren oder zu deaktivieren. Sie können die Datenaufnahme für Managed Airflow konfigurieren, um die automatische Datenaufnahme zu aktivieren oder zu deaktivieren.

  • Managed Service for Apache Spark: Apache Hive-Cluster

    Sie können Herkunftsereignisse mit Managed Service for Apache Spark-Hive-Jobs erfassen und in der Data Lineage API veröffentlichen. Sie können die Datenherkunftserfassung für Managed Service for Apache Spark konfigurieren, um die automatische Datenherkunftserfassung zu aktivieren oder zu deaktivieren.

  • Managed Service for Apache Spark: Apache Spark-Cluster

    Sie können Herkunftsereignisse mit Managed Service for Apache Spark-Jobs erfassen und in der Data Lineage API veröffentlichen. Sie können die Datenherkunftserfassung für Managed Service for Apache Spark konfigurieren, um die automatische Datenherkunftserfassung zu aktivieren oder zu deaktivieren.

  • Managed Service for Apache Spark: serverlose Bereitstellung

    Sie können Herkunftsereignisse mit serverlosen Jobs von Managed Service for Apache Spark erfassen und in der Data Lineage API veröffentlichen. Sie können die Datenherkunftserfassung für Managed Service for Apache Spark konfigurieren, um die automatische Datenherkunftserfassung zu aktivieren oder zu deaktivieren.

  • Vertex AI Feature Store

    Die Datenherkunft verfolgt Metadaten für Feature Store-Ansichten und Featuregruppen.

  • Vertex AI Pipelines

    Die Datenherkunft wird automatisch für Vertex AI-Pipelines aktiviert. Dabei werden Eingabeartefakte und Ausführungsparameter (z. B. Modelle, Datasets und Komponenten) sowie nachgelagerte abgeleitete Assets erfasst.

Datenherkunft für benutzerdefinierte Datenquellen

Mit der Data Lineage API können Sie Informationen zur Datenherkunft für alle Datenquellen manuell aufzeichnen, die von integrierten Systemen nicht unterstützt werden, z. B. externe Datenbanken oder lokale Pipelines. Knowledge Catalog kann Herkunftsdiagramme für manuell aufgezeichnete Herkunft erstellen, wenn Sie einen fullyQualifiedName verwenden, der mit den vollständig qualifizierten Namen vorhandener Knowledge Catalog-Einträge übereinstimmt. Wenn Sie die Herkunft für eine benutzerdefinierte Datenquelle aufzeichnen möchten, müssen Sie zuerst einen benutzerdefinierten Eintrag erstellen.

Jeder Prozess für eine benutzerdefinierte Datenquelle kann einen sql-Schlüssel in der Attributliste enthalten. Der Wert dieses Schlüssels wird verwendet, um eine Codehervorhebung im Detailbereich des Datenherkunftsdiagramms zu rendern. Die SQL-Anweisung wird so angezeigt, wie sie bereitgestellt wurde. Sie sind dafür verantwortlich, vertrauliche Informationen herauszufiltern. Beim Schlüsselnamen sql wird zwischen Groß- und Kleinschreibung unterschieden.

Beispiel für eine Prozessressourcen-Nutzlast mit einem benutzerdefinierten sql-Attribut:

{
  "displayName": "custom-sql-query",
  "attributes": {
    "sql": "SELECT user_id, SUM(amount) FROM `project.dataset.purchases` GROUP BY user_id"
  }
}

Weitere Informationen finden Sie unter Informationen zur Herkunft externer Systeme verfolgen.

OpenLineage

Wenn Sie OpenLineage bereits verwenden, um Herkunftsinformationen aus anderen Datenquellen zu erfassen, können Sie OpenLineage-Ereignisse in Knowledge Catalog importieren und diese Ereignisse in der Google Cloud Console ansehen. Weitere Informationen finden Sie unter In OpenLineage einbinden.

Automatisierte Data Lineage-Verfolgung

Wenn Sie die Data Lineage API aktivieren, beginnen Google Cloud -Systeme, die die Datenherkunft unterstützen, mit der Meldung ihrer Datenbewegungen. Jedes integrierte System kann Herkunftsinformationen für eine andere Reihe von Datenquellen senden.

Aufnahme von Herkunftsdaten steuern

Durch die Steuerung der Generierung von Herkunftsdaten können Sie Kosten und Governance-Richtlinien verwalten. Sie können die Herkunftserfassung beispielsweise für Entwicklungsprojekte oder Arbeitslasten mit hohem Volumen deaktivieren, für die keine Herkunftsverfolgung erforderlich ist.

Informationen zum Konfigurieren und Steuern der Datenaufnahme für die Herkunft finden Sie unter Datenaufnahme für die Herkunft für einen Dienst steuern.

Multiregionale Datenherkunft

Die Datenherkunft ist ein inhärent regionalisierter Dienst. Herkunftsmetadaten, einschließlich Links, Prozesse und Ereignisse, werden sicher aufgezeichnet und innerhalb des spezifischen geografischen Standorts isoliert, an dem die zugrunde liegende Datentransformation oder Asset-Änderung erfolgt.

Da moderne Unternehmensdatenarchitekturen skalieren, überschreiten Pipeline-Workflows häufig Projekt- und Regionsgrenzen. Beispielsweise könnte eine BigQuery-Transformationspipeline, die in us-central1 ausgeführt wird, eine Quelltabelle in us-east1 lesen und aggregierte Messwerte in einen Cloud Storage-Bucket in europe-west1 ausgeben.

Wenn Sie eine umfassende End-to-End-Ansicht des Lebenszyklus Ihrer Daten in diesen unabhängigen geografischen Bereichen erstellen möchten, verwenden Sie eine multiregionale Suchmethode für die Datenherkunft.

Weitere Informationen finden Sie unter Multiregionale Herkunftssuche.

Überlegungen und Einschränkungen zur Datenherkunft

Berücksichtigen Sie bei der Planung Ihrer Data-Governance-Strategie die folgenden Herkunftsintegrationen, Compliance-Parameter und Dienstbeschränkungen.

Herkunftseinstellungen auf Produktebene

Wenn die Data Lineage API aktiviert ist, melden unterstützte Systeme die Datenherkunft gemäß ihren Einstellungen auf Produktebene. Eine vollständige Liste der unterstützten Systeme und ihrer Steuerelemente finden Sie unter Unterstützte Systeme für die Datenherkunft.

Compliance mit der Datenherkunft

  • In der Datenherkunft werden Metadaten zur Datenbewegung aufgezeichnet, aber nicht die Daten selbst. Weitere Informationen zu den in den Metadaten enthaltenen Feldern finden Sie im Informationsmodell zur Datenherkunft und in der Data Lineage API-Referenz.
  • Die Datenherkunft als Teil von Knowledge Catalog bietet VPC-SC-Unterstützung.
  • Knowledge Catalog bietet nicht die Möglichkeit, vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) zum Schutz der erfassten Herkunftsmetadaten zu verwenden.

Einschränkungen der Datenherkunft

Für die Datenherkunft gelten die folgenden Einschränkungen:

  • Alle Herkunftsinformationen werden nur 30 Tage lang im System aufbewahrt.

  • Herkunftsinformationen bleiben erhalten, nachdem Sie die zugehörige Datenquelle gelöscht haben. Wenn Sie beispielsweise eine BigQuery-Tabelle löschen, können Sie die Herkunft bis zu 30 Tage lang über die API und die Console aufrufen.

  • Die Datenherkunft zeichnet nicht automatisch direkte Herkunftsinformationen für BigQuery-Routinen auf. Wenn eine Routine in einer Abfrage verwendet wird, zeichnet die Datenherkunft die Herkunft zwischen den Tabellen auf, die die Routine als Abhängigkeiten von Tabellen liest, in die die Abfrage schreibt.

Wenn Sie einen Knoten im Herkunftsdiagramm auswählen, ist die Seitenleiste mit den Knotendetails in den folgenden Fällen leer:

  • Die Ressource befindet sich in einer anderen Organisation.
  • Der Nutzer ist kein Mitglied der Organisation, die die Ressource hostet.

Einschränkungen der Lineage auf Spaltenebene

Für die Herkunft auf Spaltenebene gelten die folgenden zusätzlichen Einschränkungen:

  • Benutzerdefinierte OpenLineage-Ereignisse, die über die Data Lineage API gesendet werden, unterstützen keine Herkunft auf Spaltenebene.

  • Die Herkunft auf Spaltenebene wird nicht für BigQuery-Ladejobs oder für Routinen erfasst. Dazu gehören Skripts mit mehreren Anweisungen und inkrementelle Dataform-Tabellen, die in temporäre gespeicherte Prozeduren kompiliert werden.

  • Die Herkunft auf Spaltenebene wird nicht für Abfragen erfasst, deren Quelltabellen sich vollständig in temporären Datasets befinden.

  • Für externe Tabellen wird keine vorgelagerte Herkunft auf Spaltenebene erfasst.

  • Die Herkunft auf Spaltenebene wird nicht erfasst,wenn ein Job mehr als 1.500 Verknüpfungen auf Spaltenebene erstellt. In diesen Fällen wird nur die Herkunft auf Tabellenebene erfasst.

  • Die Herkunft auf Spaltenebene wird nicht übertragen oder beibehalten, wenn Tabellen mit ALTER TABLE RENAME-Vorgängen umbenannt werden (häufig in ETL-Mustern für den Tabellenaustausch verwendet).

  • Die Unterstützung der Datenherkunft auf Spaltenebene ist auf Spalten der obersten Ebene in BigQuery-Tabellen beschränkt. Verschachtelte Felder in komplexen Typen (z. B. STRUCT oder JSON) werden nicht unterstützt.

  • Die Suchfunktion mit dem Feldparameter funktioniert nur bei Links, die explizit Spalte-zu-Spalte-Beziehungen definieren. Es werden keine Ergebnisse zurückgegeben oder Links durchlaufen, die nur auf Tabellenebene definiert sind. Die Suche zwischen Links auf Tabellenebene und Links auf Spaltenebene wird nicht unterstützt (z. B. die Suche nach allen Spalten, die sich auf einen Link auf Tabellenebene beziehen, oder umgekehrt). Die API gibt nur Links zurück, bei denen sowohl Quelle als auch Ziel ein Feld angeben.

  • Die Unterstützung für partitionierte Tabellen ist eingeschränkt, da Partitionierungsspalten wie _PARTITIONDATE und _PARTITIONTIME im Herkunftsdiagramm nicht erkannt werden.

  • Einschränkungen der Console:

    • Die Durchquerung des Herkunftsdiagramms ist auf eine Tiefe von 20 Ebenen und 10.000 Links in jede Richtung beschränkt.

Preise

Knowledge Catalog verwendet die Premium-Verarbeitungs-SKU (gemessen in Data Recheneinheiten oder DCUs), um die Datenherkunft abzurechnen. Einzelheiten zu den Preisen finden Sie unter Knowledge Catalog-Preise oder im Google Cloud -Preisrechner.

Kostenfaktoren und Auswirkungen auf die Abrechnung

Beachten Sie bei der Planung der Datenherkunftsimplementierung die folgenden Kostenfaktoren:

  • Aktivierung pro Projekt. Die Data Lineage API wird pro Projekt ausgeführt. Prüfen Sie die Auswirkungen auf die Abrechnung, bevor Sie die Funktion für datenintensive Projektworkflows aktivieren.
  • Metadatenspeicherung und -suche: Herkunftsmetadaten (Prozesse, Ausführungen, Ereignisse und Links), die während des 30-tägigen Aufbewahrungszeitraums gespeichert werden, werden unter der SKU für Metadatenspeicher abgerechnet. Für das Aufrufen der Herkunft in der Google Cloud Console fallen keine BigQuery-Abfrage- oder Scangebühren an.
  • BigQuery Omni Die Herkunftsverarbeitung wird auf bestimmte Regionen verteilt. Die Kosten hängen von den Regionen ab, in denen die Verarbeitung erfolgt.
  • Multiregionale BigQuery-Datasets. Wenn Sie multiregionale Datasets verwenden (z. B. die Multiregion US), leitet BigQuery Abfragen dynamisch über physische Rechenzentrumszonen weiter. Die Datenherkunft wird zusammen mit der Abfrageausführung am physischen Standort ausgeführt, an dem der Job ausgeführt wurde (z. B. us-east1). Dies führt zu regionalen Lineage-DCU-SKU-Einträgen auf Ihrer Cloud Billing-Rechnung.
  • Benutzerdefinierte Quelltypen Wenn Sie die Data Lineage API Origin sourceType mit einem anderen Wert als CUSTOM aufrufen, fallen zusätzliche Kosten an.

Kosten im Blick behalten und kontrollieren

  • Einschränkung von Cloud Monitoring-Messwerten Der DCU-Verbrauch für die Datenherkunft wird auf serverlosem Computing ausgeführt und gibt keine Echtzeit-Zeitreihenmesswerte unter dataplex.googleapis.com/* an Cloud Monitoring aus.
  • Gebühren in Cloud Billing filtern und zuordnen Wenn Sie die Gebühren für die Datenherkunft von anderen Gebühren in der SKU für die Premium-Verarbeitung im Knowledge Catalog trennen und zuordnen möchten, verwenden Sie im Cloud Billing-Bericht oder im Cloud Billing-Export nach BigQuery das Label goog-dataplex-workload-type mit dem Wert LINEAGE. Detaillierte Abfragebeispiele finden Sie unter Knowledge Catalog-DCU-Kosten mit Cloud Billing-Export überwachen und zuordnen.
  • In Entwicklungsprojekten deaktivieren. Um unnötige Verarbeitungskosten zu vermeiden, aktivieren Sie die Data Lineage API nur für Projekte, für die ein Herkunftstracking erforderlich ist.
  • Kosten stoppen: Für die Data Lineage API fallen Gebühren an, die von der Dataplex API getrennt sind. Wenn Sie die Dataplex API deaktivieren, wird die Data Lineage API nicht deaktiviert und die Gebühren werden nicht gestoppt. Wenn Sie keine Gebühren für die Datenherkunft mehr zahlen möchten, müssen Sie die Datenherkunft deaktivieren. Deaktivieren Sie dazu die Data Lineage API.

Nächste Schritte