Data Lineage

Die Datenherkunft ist eine visuelle Darstellung, die den gesamten Lebenszyklus Ihrer Daten nachverfolgt. Sie zeigt, woher Ihre Daten stammen (die Quelle), wohin sie übertragen werden (die Ziele) und alle Änderungen oder Transformationen, die dabei vorgenommen werden.

Sie können diese vollständige Darstellung des Lebenszyklus Ihrer Daten direkt in der Google Cloud Console für Assets ansehen, die in Produkten wie Knowledge Catalog (ehemals Dataplex Universal Catalog), BigQuery (einschließlich externer Tabellen, die für den Iceberg REST Catalog erstellt wurden) und Vertex AI erstellt wurden. Da Workflows oft mehrere Regionen umfassen, unterstützt Knowledge Catalog die Herkunft von Daten in mehreren Regionen. So erhalten Sie eine ganzheitliche Übersicht des Lebenszyklus Ihrer Daten im gesamten globalen Google Cloud Ökosystem. Fortgeschrittene Nutzer können diese Informationen auch mit der Data Lineage API abrufen.

Warum Sie die Datenherkunft benötigen

Moderne Unternehmen verschieben und ändern ständig große Datenmengen. Beispielsweise werden Rohdaten zu Kundenkäufen in Berichte, Dashboards und Machine-Learning-Modelle umgewandelt. Diese Komplexität stellt Ihr Team vor große Herausforderungen:

  • Vertrauen und Überprüfung: 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 in jedem Schritt bis zur Ursache zurückzuverfolgen.

  • Änderungsmanagement: Bevor ein Datenelement (z. B. eine Spalte in einer Tabelle) geändert oder gelöscht wird, müssen Teams alle nachgelagerten Berichte oder Modelle kennen, die darauf 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 die gesetzlichen Anforderungen zu erfüllen.

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

Workflow für die Datenherkunft

Der Workflow für die Datenherkunft umfasst die folgenden Schritte:

  1. Datenquellen und Aufnahme: Informationen zur Herkunft aus Ihren Datenquellen initiieren den gesamten Prozess. Weitere Informationen finden Sie unter Quellen der Datenherkunft.

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

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

  2. Plattform für die Datenherkunft: Auf dieser zentralen Plattform werden alle Daten zur Herkunft aufgenommen, modelliert und gespeichert. Weitere Informationen finden Sie unter Modell und Detaillierungsgrad der Informationen zur Herkunft.

    • Data Lineage API: Diese API dient als einziger Einstiegspunkt für alle eingehenden Informationen zur Herkunft. Sie 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, für Abfragen optimierten Datenbanken.

  3. Nutzererfahrung: Sie können auf zwei Arten mit den gespeicherten Informationen zur Herkunft interagieren:

    • Visuelle Analyse: In der Google Cloud Console ruft ein Frontend-Dienst die Daten zur Herkunft ab und rendert sie als interaktives Diagramm oder als 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 Feature-Gruppen) unterstützt. So können Sie den Lebenszyklus Ihrer Daten visuell analysieren. Weitere Informationen finden Sie unter Ansichten der Datenherkunft in der Google Cloud Console.

    • 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 Informationen zur Herkunft aus benutzerdefinierten Quellen schreiben. Außerdem können Sie die gespeicherten Daten zur Herkunft lesen und abfragen, um sie in anderen Anwendungen zu verwenden oder benutzerdefinierte Berichte zu erstellen.

Quellen der Datenherkunft

Sie können Informationen zur Herkunft in Knowledge Catalog auf folgende Arten hinzufü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 Informationen zur Herkunft für Folgendes auf:

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

Wenn Sie die Prozessdetails aufrufen möchten, klicken Sie im Diagramm zur Herkunft auf das Symbol Prozessdetails Symbol „Prozessdetails“.

Jeder Prozess enthält die BigQuery-job_id in der Attributliste für den letzten BigQuery-Job.

Weitere Dienste

Die Datenherkunft unterstützt die Einbindung in die folgenden Google Cloud Dienste:

Datenherkunft für benutzerdefinierte Datenquellen

Mit der Data Lineage API können Sie Informationen zur Herkunft für alle Datenquellen manuell aufzeichnen, die von integrierten Systemen nicht unterstützt werden.

Knowledge Catalog kann Diagramme zur Herkunft für manuell aufgezeichnete Herkunft erstellen, wenn Sie ein fullyQualifiedName verwenden, das 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 Eintragerstellen.

Jeder Prozess für eine benutzerdefinierte Datenquelle kann in der Liste der Attribute einen sql-Schlüssel enthalten. Der Wert dieses Schlüssels wird verwendet, um im Detailbereich des Diagramms zur Datenherkunft eine Codehervorhebung zu rendern. Die SQL-Anweisung wird so angezeigt, wie sie angegeben wurde. Sie sind für das Herausfiltern vertraulicher Informationen verantwortlich. Bei dem Schlüsselnamen sql wird zwischen Groß- und Kleinschreibung unterschieden.

OpenLineage

Wenn Sie OpenLineage bereits verwenden, um Informationen zur Herkunft 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 Nachverfolgung der Datenherkunft

Wenn Sie die Data Lineage API aktivieren, Google Cloud melden Systeme, die die Datenherkunft unterstützen, ihre Datenübertragung. Jedes integrierte System kann Informationen zur Herkunft für einen anderen Bereich von Datenquellen senden.

Aufnahme der Datenherkunft steuern

Sie können steuern, welche Google Cloud Dienste Daten zur Herkunft generieren, indem Sie die Aufnahme der Herkunft für bestimmte Integrationen aktivieren oder deaktivieren. Sie können die Aufnahme der Herkunft auf Organisations-, Ordner- und Projektebene steuern. In der Vorabversion kann die Aufnahme der Herkunft nur für Managed Service for Apache Spark konfiguriert werden.

Knowledge Catalog wertet die Ressourcenhierarchie aus (Projekt, dann Ordner, dann Organisation), um die effektive Konfiguration zu ermitteln. Die erste Konfiguration, die auf einer beliebigen Ebene in dieser Aufwärtsbewegung explizit festgelegt wird, wird wirksam.

  • Wenn Sie eine Konfiguration auf Projektebene festlegen, verwendet Knowledge Catalog diese.
  • Wenn auf Projektebene keine Konfiguration festgelegt ist, verwendet Knowledge Catalog die Konfiguration aus dem nächstgelegenen übergeordneten Ordner mit einer expliziten Konfiguration.
  • Wenn auf Projekt- oder Ordnerebene keine Konfiguration festgelegt ist, verwendet Knowledge Catalog die Konfiguration auf Organisationsebene.
  • Wenn auf keiner dieser Ebenen eine Konfiguration festgelegt ist, verwendet Knowledge Catalog die Standardeinstellung des Systems für die Integration. Die Standardeinstellung für die Konfiguration der Aktivierung der Herkunft kann Aktiviert oder Deaktiviert sein. Für Managed Service for Apache Spark ist die Aufnahme der Herkunft standardmäßig Aktiviert , wenn die Data Lineage API aktiv ist.

Betrachten Sie beispielsweise eine Organisation test-org mit den folgenden Konfigurationen für die Herkunft von Managed Service for Apache Spark:

  • Organisation test-org: Aktiviert
    • Ordner folder-a: Deaktiviert
      • Projekt project-a: Keine Konfiguration festgelegt
    • Ordner folder-b: Aktiviert
      • Projekt project-b: Deaktiviert

In diesem Szenario gelten die folgenden Einstellungen:

  • Für project-a ist die Aufnahme der Herkunft Deaktiviert. Knowledge Catalog beginnt mit der Auswertung von project-a, findet keine Konfiguration, wechselt zu folder-a und wendet die Deaktiviert Konfiguration aus folder-a an.
  • Für project-b ist die Aufnahme der Herkunft Deaktiviert. Knowledge Catalog beginnt mit der Auswertung von project-b und wendet die Konfiguration Deaktiviert an, wodurch die Einstellungen für folder-b und test-org überschrieben werden.

Durch das Steuern der Generierung von Daten zur Herkunft können Sie Kosten und Governance-Richtlinien verwalten. Sie können beispielsweise die Erfassung der Herkunft für Entwicklungsprojekte oder Arbeitslasten mit hohem Volumen deaktivieren, für die keine Nachverfolgung der Herkunft erforderlich ist.

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

Datenherkunft in mehreren Regionen

Die Datenherkunft ist ein von Natur aus regionalisierter Dienst. Metadaten zur Herkunft, einschließlich Links, Prozesse und Ereignisse, werden sicher aufgezeichnet und isoliert an dem geografischen Ort gespeichert, an dem die zugrunde liegende Datentransformation oder Asset-Änderung stattfindet.

Mit zunehmender Skalierung moderner Unternehmensdatenarchitekturen überschreiten Pipeline-Workflows häufig Projekt- und Regionsgrenzen. Beispielsweise kann 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 erhalten möchten, verwenden Sie eine Suchmethode für die Herkunft in mehreren Regionen.

Weitere Informationen finden Sie unter Suche nach der Herkunft in mehreren Regionen.

Beschränkungen

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

  • Alle Informationen zur Herkunft werden nur 30 Tage lang im System aufbewahrt.

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

  • Die Datenherkunft zeichnet keine direkten Informationen zur Herkunft für BigQuery-Routinen automatisch auf. Wenn eine Routine in einer Abfrage verwendet wird, zeichnet die Datenherkunft die Herkunft zwischen den Tabellen auf, die von der Routine als Abhängigkeiten von Tabellen gelesen werden, in die die Abfrage schreibt.

Einschränkungen der Herkunft auf Spaltenebene

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

  • Die Herkunft auf Spaltenebene wird nicht für BigQuery-Ladejobs oder für Routinen erfasst.

  • Die Upstream-Herkunft auf Spaltenebene wird nicht für externe Tabellen 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 Unterstützung für die Herkunft 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 Beziehungen zwischen Spalten definieren. Es werden keine Ergebnisse zurückgegeben oder Links durchlaufen, die nur auf Tabellenebene definiert sind. Es gibt keine Unterstützung für die Suche zwischen Links auf Tabellen- und Spaltenebene (z.B. alle Spalten finden, 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 begrenzt, da Partitionierungsspalten wie _PARTITIONDATE und _PARTITIONTIME im Diagramm zur Herkunft nicht erkannt werden.

  • Einschränkungen der Console:

    • Die Durchquerung des Diagramms zur Herkunft ist auf eine Tiefe von 20 Ebenen und 10.000 Links in jeder Richtung beschränkt.

Preise

  • Knowledge Catalog verwendet die Premium-Verarbeitungs-SKU, um die Datenherkunft in Rechnung zu stellen. Weitere Informationen finden Sie unter Preise.

  • Wenn Sie die Gebühren für die Datenherkunft von anderen Gebühren in der Premium-Verarbeitungs-SKU von Knowledge Catalog trennen möchten, verwenden Sie im Cloud Billing-Bericht das Label goog-dataplex-workload-type mit dem Wert LINEAGE.

  • Wenn Sie die Data Lineage API Origin sourceType mit einem anderen Wert als CUSTOM aufrufen, fallen zusätzliche Kosten an.

Nächste Schritte