Data Lineage

Data Lineage ist eine visuelle Karte, die den gesamten Lebenszyklus Ihrer Daten verfolgt. 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 Karte des Datenflusses 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. Fortgeschrittene Nutzer können diese Informationen auch mit der Data Lineage API abrufen.

Warum Sie Data Lineage benötigen

Moderne Unternehmen verschieben und ändern ständig große Datenmengen. Beispielsweise werden Rohdaten zu Kundenkäufen in Berichte, Dashboards und Modelle für maschinelles Lernen 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 Daten geändert oder gelöscht werden (z. B. eine Spalte in einer Tabelle), müssen Teams zwingend alle nachgelagerten Berichte oder Modelle kennen, die darauf basieren, um zu vermeiden, dass kritische Systeme beschädigt werden.

  • Compliance: Führungskräfte benötigen Einblick in die Verwendung sensibler Daten (z. B. Kunden- oder Finanzinformationen) im gesamten Unternehmen, um die gesetzlichen Anforderungen zu erfüllen.

Data Lineage löst diese Probleme, indem es einen klaren, visuellen und dokumentierten Verlauf Ihrer Daten bietet. So können Sie Datenquellen schnell nachvollziehen, Fehler verfolgen, die Auswirkungen von Änderungen bewerten und die Compliance einhalten.

Data Lineage-Workflow

Der Data Lineage-Workflow umfasst die folgenden Schritte:

  1. Datenquellen und Aufnahme: Informationen zur Herkunft aus Ihren Datenquellen initiieren den gesamten Prozess. Weitere Informationen finden Sie unter Quellen für die Herkunft.

    • 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 Systeme, die nicht automatisch durch Google Cloud Integrationen unterstützt werden, können Sie die Data Lineage API verwenden, um Herkunftsinformationen manuell aufzuzeichnen. Wir empfehlen, Ereignisse zu importieren, die gemäß dem OpenLineage-Standard formatiert sind.

  2. Plattform für die Herkunft: Auf dieser zentralen Plattform werden alle Herkunftsdaten aufgenommen, modelliert und gespeichert. Weitere Informationen finden Sie unter Herkunftsinformationsmodell und Granularität.

    • Data Lineage API: Diese API dient als einziger Einstiegspunkt für alle eingehenden Herkunftsinformationen. 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 Herkunftsinformationen interagieren:

    • Visuelle Analyse: In der Google Cloud Console ruft ein Front-End-Dienst die Herkunftsdaten 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. Dies ist ideal, um den Verlauf Ihrer Daten visuell zu analysieren. Weitere Informationen finden Sie unter Herkunftsansichten in der Google Cloud Console.

    • Programmatischer Zugriff: Mit einem API-Client können Sie direkt mit der Data Lineage API kommunizieren, um die Herkunftsverwaltung 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.

Quellen für die Herkunft

Sie können Herkunftsinformationen in Knowledge Catalog auf folgende Arten eingeben:

  • 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 Herkunft der Daten 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 Symbol „Prozessdetails“, um die Prozessdetails aufzurufen.

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

Weitere Dienste

Data Lineage unterstützt die Einbindung in die folgenden Google Cloud Dienste:

Herkunft von Daten für benutzerdefinierte Datenquellen

Mit der Data Lineage API können Sie Herkunftsinformationen für jede Datenquelle manuell aufzeichnen, die von integrierten Systemen nicht unterstützt wird.

Knowledge Catalog kann Herkunftsdiagramme 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 Eintrag erstellen.

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 Data Lineage-Diagramms eine Codehervorhebung zu rendern. Die SQL-Anweisung wird so angezeigt, wie sie angegeben wurde. Sie sind dafür verantwortlich, vertrauliche Informationen herauszufiltern. Bei dem Schlüsselnamen sql wird zwischen Groß- und Kleinschreibung unterschieden.

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 Herkunft von Daten

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

Aufnahme der Herkunft steuern

Sie können steuern, welche Google Cloud Dienste Herkunftsdaten 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 unterstützt diese Funktion nur die Konfiguration der Aufnahme der Herkunft für Managed Service for Apache Spark. Wenn Sie die Aufnahme der Herkunft für Managed Service for Apache Spark deaktivieren, wird sie auch für Managed Service for Apache Spark Managed Service for Apache Spark deaktiviert.

Knowledge Catalog wertet die Ressourcenhierarchie (Projekt, dann Ordner, dann Organisation) aus, 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 Herkunftsaktivierung 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 Managed Service for Apache Spark-Herkunftskonfigurationen:

  • 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 die Steuerung der Generierung von Herkunftsdaten 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 Verfolgung der Herkunft erforderlich ist.

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

Beschränkungen

Für die Herkunft von Daten 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 ihre Herkunft bis zu 30 Tage lang über die API und die Console ansehen.

  • Die Herkunft von Daten zeichnet keine direkten Herkunftsinformationen für BigQuery-Routinen automatisch auf. Wenn eine Routine in einer Abfrage verwendet wird, zeichnet die Herkunft von Daten 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 Herkunftsdiagramm nicht erkannt werden.

  • Einschränkungen der Console:

    • Die Durchquerung des Herkunftsdiagramms 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 Herkunft von Daten in Rechnung zu stellen. Weitere Informationen finden Sie unter Preise.

  • Wenn Sie die Gebühren für die Herkunft von Daten von anderen Gebühren in der Premium-Verarbeitungs-SKU von Knowledge Catalog trennen möchten, verwenden Sie im Cloud Billing report 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