Data Lineage

Mit der Datenherkunft in Knowledge Catalog (früher Dataplex Universal Catalog) können Sie nachvollziehen, woher Ihre Daten stammen, wie sie transformiert werden und wie sie sich durch Systeme wie BigQuery und Vertex AI bewegen. Mit diesen Herkunftsdatensätzen können Sie vertrauenswürdige Quellen verifizieren, Pipelinefehler auf ihre Ursache zurückführen, die nachgelagerten Auswirkungen von Änderungen bewerten und die Compliance unterstützen. Sie können interaktive Diagramme in der Google Cloud Console untersuchen, die multiregionale Herkunft durchsuchen oder Metadaten programmatisch mit der Data Lineage API aufzeichnen und abfragen.

Gründe für die Datenherkunft

Moderne Unternehmen verschieben und ändern ständig große Datenmengen. Beispielsweise können Rohdaten zu Kundenkäufen in Berichte, Dashboards und Modelle für maschinelles Lernen umgewandelt werden. 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 Einblick darin haben, wie sensible Daten (z. B. Kunden- oder Finanzinformationen) im gesamten Unternehmen verwendet werden, um gesetzliche Anforderungen zu erfüllen.

Die Datenherkunft adressiert diese Herausforderungen, indem sie aufzeichnet, woher Ihre Daten stammen (der Ursprung), wohin sie übertragen werden (die Ziele) und welche Änderungen oder Transformationen auf dem Weg vorgenommen werden. Anhand dieses dokumentierten Datensatzes 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 (einschließlich externer Tabellen, die für Apache Iceberg-Tabellen erstellt wurden, die vom Apache Iceberg REST-Katalogendpunkt verwaltet werden), Lakehouse (für Apache Iceberg-Tabellen, die vom Apache Iceberg REST-Katalogendpunkt verwaltet werden), 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 verfolgen.

    • 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 Suchvorgänge 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 Ebene (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 Lineage-Diagramms 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.
  • Nachgelagert (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 zur Datenherkunft

Die Herkunft ist ein Datensatz, der von Quellen zu Zielen transformiert wird. 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-Datenherkunft 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?

Eine Ausführung 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 eine neue, separate Ausführung 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 zur Run-Ressource.

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. Dies 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, indem Sie die Data Lineage API für benutzerdefinierte Quellen verwenden
  • 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.

  • Dataform

    Dataform meldet die Herkunft auf Tabellenebene für die Aktionen, die in Dataform-Workflows und BigQuery-Pipelines ausgeführt werden.

  • Lakehouse für Iceberg-REST-Katalogtabellen

  • Looker (Google Cloud Core)

    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 Steuerung der Datenherkunftsintegration 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 Datenherkunftserfassung für Managed Airflow konfigurieren, um die automatische Datenherkunftserfassung 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 Herkunftsinformationen für alle Datenquellen, die von integrierten Systemen nicht unterstützt werden, manuell aufzeichnen, z. B. für 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 Herkunftsinformationen für externe 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 Verfolgung der Datenherkunft

Wenn Sie die Data Lineage API aktivieren, beginnen Google Cloud -Systeme, 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 Erfassung von Herkunftsdaten beispielsweise für Entwicklungsprojekte oder Arbeitslasten mit hohem Volumen deaktivieren, für die kein Herkunfts-Tracking erforderlich ist. Wenn Sie die Aufnahme von Herkunftsdaten deaktivieren, fallen keine neuen Verarbeitungsgebühren an. Für bereits aufgenommene Metadaten fallen jedoch weiterhin Speichergebühren an, bis das 30-tägige Aufbewahrungsfenster abläuft oder Sie sie löschen (siehe Abschnitt Preise in diesem Dokument).

Weitere Informationen finden Sie unter Informationen zur Steuerung der Datenherkunftserfassung und Datenherkunftserfassung für einen Dienst konfigurieren.

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.

Mit der Skalierung moderner Unternehmensdatenarchitekturen ü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 einheitliche End-to-End-Ansicht des Lebenszyklus Ihrer Daten überGoogle Cloud -Regionen und -Projekte hinweg erstellen möchten, verwenden Sie eine multiregionale Herkunftssuchmethode.

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 Datenherkunft

  • In der Datenherkunft werden Metadaten zur Datenbewegung aufgezeichnet, aber nicht die Daten selbst. Weitere Informationen zu den Feldern in den Metadaten finden Sie im Informationsmodell zur Datenherkunft und in der Referenz zur Data Lineage API.
  • 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 Herkunft 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 Links 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 für 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 mit einem Link auf Tabellenebene verknüpft sind, 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 Lineage-Diagramms ist auf eine Tiefe von 20 Ebenen und 10.000 Links in jede Richtung beschränkt.

Preise

Knowledge Catalog stellt die Datenherkunft sowohl über die Premium-Verarbeitungs-SKU als auch über die Metadatenspeicher-SKU in Rechnung. Die Premium-Verarbeitungs-SKU rechnet das automatische Parsen von Herkunftsereignissen in Data Compute Unit-Stunden (DCU) ab. Die Metadatenspeicher-SKU rechnet Herkunftsmetadaten (Prozesse, Ausführungen, Ereignisse und Links) ab, die während des 30-tägigen Zeitraums in GiB pro Monat aufbewahrt werden. Preisdetails finden Sie unter Knowledge Catalog-Preise oder im Google Cloud -Preisrechner.

Kostenfaktoren und Auswirkungen auf die Abrechnung

Beachten Sie bei der Planung der Implementierung der Datenherkunft 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. Die Speichergebühren enden, wenn die Metadaten am Ende des 30-tägigen Aufbewahrungszeitraums ablaufen oder wenn Sie sie löschen. Für das Aufrufen der Herkunft in der Google Cloud Console fallen keine BigQuery-Abfrage- oder Scangebühren an.
  • BigQuery Omni. Die Verarbeitung von Herkunftsdaten 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). Diese Ausführung führt zu regionalen Lineage-DCU-SKU-Einträgen auf Ihrer Cloud Billing-Rechnung.
  • Benutzerdefinierte Ursprungsquelltypen Wenn Sie die Data Lineage API mit dem Feld Origin sourceType auf einen anderen Wert als CUSTOM setzen, fallen Premium-Verarbeitungsgebühren (DCU) an. Wenn Sie das Feld sourceType auf CUSTOM setzen, fallen keine Premium-Verarbeitungsgebühren an, da Sie die Herkunft selbst parsen. Die gespeicherten CUSTOM-Herkunftsmetadaten werden jedoch während des 30-tägigen Aufbewahrungszeitraums weiterhin über die SKU für die Metadatenspeicherung abgerechnet.

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-Zeitachsenmesswerte unter dem Präfix dataplex.googleapis.com/* an Monitoring aus.
  • Gebühren in Cloud Billing filtern und zuordnen Knowledge Catalog hängt das Label goog-dataplex-workload-type mit dem Wert LINEAGE sowohl an die Premium-Verarbeitungs-SKU als auch an die Metadatenspeicher-SKU-Positionen für die Datenherkunft an. Verwenden Sie dieses Label in Cloud Billing-Berichten oder im Cloud Billing-Export nach BigQuery, um die Rechen- und Speichergebühren für die Datenherkunft von anderen Knowledge Catalog-Gebühren zu trennen und zuzuordnen. Weitere Informationen finden Sie unter Abrechnungsberichte und Kostentrends ansehen und Knowledge Catalog-DCU-Kosten mit Cloud Billing-Export überwachen und zuordnen.
  • In Entwicklungsprojekten deaktivieren. Um unnötige Rechen- und Speicherkosten zu vermeiden, sollten Sie die Data Lineage API nur für Projekte aktivieren, für die ein Herkunftstracking erforderlich ist, oder die Herkunftsaufnahme für bestimmte Dienste deaktivieren. Eine Anleitung finden Sie im Abschnitt Aufnahme von Datenherkunft für einen Dienst deaktivieren unter „Aufnahme von Datenherkunft für einen Dienst konfigurieren“.
  • Gebühren stoppen: Die Data Lineage API wird separat von der Dataplex API abgerechnet. Wenn Sie die Dataplex API deaktivieren, wird die Data Lineage API nicht deaktiviert und die Gebühren werden nicht gestoppt. Wenn Sie die Data Lineage API deaktivieren, fallen für ein Projekt keine neuen Gebühren für die Verarbeitung der Datenherkunft mehr an. Nachdem Sie die Dienstaufnahme oder die Data Lineage API deaktiviert haben, fallen für vorhandene Herkunftsmetadaten bis zu 30 Tage lang Gebühren für die Metadatenspeicherung an, bis das Aufbewahrungsfenster abläuft oder Sie die Metadaten löschen. Eine Anleitung finden Sie im Abschnitt Datenherkunft deaktivieren unter „Datenherkunft für Google Cloud -Systeme ansehen“.

Nächste Schritte