Data Lineage

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

Sie können diese vollständige Übersicht über den Weg Ihrer Daten 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 den Iceberg REST Catalog erstellt wurden) und Vertex AI erstellt wurden. Da sich Workflows oft über mehrere Regionen erstrecken, unterstützt Knowledge Catalog die multiregionale Datenherkunft. So erhalten Sie einen einheitlichen Überblick über den Weg Ihrer Daten im globalen Google Cloud -Ökosystem. Erfahrene Nutzer können diese Informationen auch über die 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 Modelle für maschinelles Lernen umgewandelt. Diese Komplexität stellt Ihr Team vor große Herausforderungen:

  • Vertrauen und Überprüfung. Daten werden häufig von Nutzern verwendet, die Schwierigkeiten haben, 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) in der gesamten Organisation verwendet werden, um behördliche Anforderungen zu erfüllen.

Die Datenherkunft löst diese Probleme, indem sie einen klaren, visuellen und dokumentierten Weg Ihrer Daten bietet. So können Sie Datenquellen nachvollziehen, Fehler nachverfolgen, die Auswirkungen von Änderungen bewerten und die Compliance aufrechterhalten.

Funktionsweise der Datenherkunft

Der Workflow für den Datenursprung umfasst die folgenden Schritte:

  1. Datenquellen und Aufnahme: Die Herkunftsinformationen aus Ihren Datenquellen sind der Ausgangspunkt für den gesamten Prozess.

    • Google Cloud Dienste: Wenn die Data Lineage API aktiviert ist, werden von unterstützten Diensten wie BigQuery und Dataflow automatisch Lineage-Ereignisse gemeldet, 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 Lineage-Informationen manuell aufzuzeichnen. Wir empfehlen, Ereignisse zu importieren, die gemäß dem OpenLineage-Standard formatiert sind.

  2. Lineage-Plattform: Auf dieser zentralen Plattform werden alle Herkunftsdaten aufgenommen, modelliert und gespeichert.

    • Data Lineage API: Diese API fungiert als einziger Einstiegspunkt für alle eingehenden Informationen zur Herkunft von Daten. Dabei wird ein hierarchisches Datenmodell mit drei Kernkonzepten verwendet: Prozess, Ausführung und Ereignis.

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

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

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

    • 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 Lineage-Daten 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 für sofortige Lookups auf einer Ebene. Wenn Sie einen vollständigen Herkunftsgraphen erstellen oder eine detaillierte Wirkungsanalyse (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 Wirkungsanalyse

Richtung erkennen

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

Informationsmodell für die Datenherkunft

Die Datenherkunft ist ein Datensatz, in dem die Transformation von Daten aus Quellen in Ziele aufgezeichnet wird. Die Data Lineage API erfasst diese Informationen und organisiert sie in einem hierarchischen Datenmodell, in dem die Konzepte „Prozesse“, „Ausführungen“ und „Ereignisse“ verwendet werden.

Konzept Beschreibung
Prozess Eine Definition der Datentransformation.
Laufen Eine Ausführung eines Prozesses.
Ereignis Ein Datensatz mit Datenbewegungen während eines Laufs.

Was ist ein Lineage-Prozess?

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

Die folgende SQL-Abfrage ist beispielsweise ein Prozess. Mit dieser Abfrage wird eine Tabelle erstellt, indem 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 Lineage-Lauf?

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

Jeder Lauf ist ein eindeutiger Vorgang, der durch eine startTime, eine endTime und einen Endstatus wie COMPLETED, FAILED oder ABORTED gekennzeichnet ist.

Wenn Sie beispielsweise die SQL-Abfrage aus dem Abschnitt Prozess um 9:00 Uhr ausführen, wird ein bestimmter Lauf erstellt. Wenn Sie dieselbe Abfrage um 10:00 Uhr noch einmal ausführen, wird ein neuer, separater Lauf erstellt. Beide Läufe sind mit demselben übergeordneten Prozess verknüpft.

Das REST-Ressourcennamenformat für einen Lauf zeigt, dass er ein untergeordnetes Element eines Prozesses ist: projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID/runs/RUN_ID.

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

Weitere Informationen zur run-Ressource finden Sie in der Referenz zur Ausführung von Ressourcen.

Was ist ein Herkunftsereignis?

Ein Ereignis stellt einen Zeitpunkt dar, zu dem Daten durch eine Datentransformation zwischen einer Quell- und einer Zielentität verschoben werden. Ein Ereignis ist ein detaillierter Datensatz einer bestimmten Datenübertragung, der Quell- und Zieltabelle für einen bestimmten Lauf verbindet. Ein Ereignis kann auch mehrere Quellen und Ziele haben.

Wenn bei Ihrem Lauf beispielsweise die im Abschnitt Prozess beschriebene SQL-Abfrage ausgeführt wird, wird in einem Lineage-Ereignis 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 Lineage-Ereignis enthält eine Liste von Links, die die Quelle und das Ziel definieren. Ereignisse werden verwendet, um Herkunftsgraphen zu erstellen. In der Google Cloud Konsole werden zwar diese Lineage-Diagramme angezeigt, einzelne Ereignisse werden jedoch nicht direkt dargestellt. 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 Datenfluss von einer Quell- zu einer Zielentität. Eine Entität ist ein Verweis auf ein Daten-Asset, z. B. eine BigQuery-Tabelle, und wird durch ihren vollständig qualifizierten Namen (Fully Qualified Name, 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 Arten einfügen:

  • Automatisch aus integrierten Google Cloud Diensten
  • Manuell über die Data Lineage API für benutzerdefinierte Quellen
  • Ereignisse aus OpenLineage importieren

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.

Wenn Sie die Prozessdetails aufrufen möchten, klicken Sie im Herkunftsdiagramm auf das Symbol Prozessdetails Prozessdetails..

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

Weitere Dienste

Die Datenherkunft unterstützt die Integration mit den folgendenGoogle Cloud -Diensten:

  • Cloud Data Fusion

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

  • Dataflow

    Sie können Lineage-Ereignisse 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 mit Datenherkunft wird unterstützt. Data Lineage muss auf der Ressourcenebene von Looker (Google Cloud Core) und auf der Ebene des Data Lineage-Dienstes aktiviert sein.

  • Managed Service for Apache Airflow

    Managed Airflow verwendet die Steuerung der Datenherkunft auf Umgebungsebene. Die Datenherkunft wird automatisch für alle neuen Managed Airflow-Umgebungen aktiviert, die die Anforderungen erfüllen. Bei vorhandenen Umgebungen können Sie die Datenherkunftsintegration in den Umgebungseinstellungen aktivieren oder deaktivieren. Sie können die Aufnahme von Datenherkunftsinformationen für Managed Airflow konfigurieren, um die automatische Aufnahme von Datenherkunftsinformationen zu aktivieren oder zu deaktivieren.

  • Managed Service for Apache Spark: Apache Hive-Cluster

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

  • Managed Service for Apache Spark: Apache Spark-Cluster

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

  • Managed Service for Apache Spark: Serverless-Bereitstellung

    Sie können Lineage-Ereignisse mit serverlosen Jobs von Managed Service for Apache Spark erfassen und in der Data Lineage API veröffentlichen. Sie können die Erfassung von Datenherkunftsinformationen für Managed Service for Apache Spark konfigurieren, um die automatische Erfassung von Datenherkunftsinformationen 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 ist für Vertex AI Pipelines-Pipelines automatisch aktiviert. Dabei werden Eingabeartefakte und Ausführungsparameter (z. B. Modelle, Datasets und Komponenten) sowie nachgelagerte abgeleitete Assets verfolgt.

Datenherkunft für benutzerdefinierte Datenquellen

Mit der Data Lineage API können Sie Lineage-Informationen für alle Datenquellen manuell aufzeichnen, die von integrierten Systemen nicht unterstützt werden, z. B. externe Datenbanken oder lokale Pipelines. Knowledge Catalog kann Herkunftsgraphen für manuell aufgezeichnete Herkunft erstellen, wenn Sie ein fullyQualifiedName verwenden, das mit den voll qualifizierten Namen vorhandener Knowledge Catalog-Einträge übereinstimmt. Wenn Sie den Datenursprung 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 Attributliste einen sql-Schlüssel enthalten. Der Wert dieses Schlüssels wird verwendet, um eine Codehervorhebung im Detailbereich des Datenherkunftsgraphen zu rendern. Die SQL-Anweisung wird so angezeigt, wie sie angegeben wurde. Sie sind dafür verantwortlich, sensible Informationen herauszufiltern. Beim Schlüsselnamen sql wird zwischen Groß- und Kleinschreibung unterschieden.

Beispiel für die Nutzlast einer Prozessressource 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 erfassen.

OpenLineage

Wenn Sie OpenLineage bereits verwenden, um Informationen zur Datenherkunft aus anderen Datenquellen zu erfassen, können Sie OpenLineage-Ereignisse in Knowledge Catalog importieren und in der Google Cloud -Konsole ansehen. Weitere Informationen finden Sie unter Mit OpenLineage integrieren.

Automatisierte Nachverfolgung der Datenherkunft

Wenn Sie die Data Lineage API aktivieren, Google Cloud beginnen Systeme, die die Datenherkunft unterstützen, mit der Berichterstellung über ihre Datenbewegungen. Jedes integrierte System kann Herkunftsinformationen für einen anderen Bereich von Datenquellen übermitteln.

Aufnahme von Lineage-Informationen steuern

Zur Verwaltung von Kosten und Governance-Richtlinien können Sie die Lineage-Generierung für bestimmte Google Cloud Dienste aktivieren oder deaktivieren. Sie können diese Aufnahme zentral auf Organisations-, Ordner- und Projektebene konfigurieren. Während der Vorschauphase wird mit dieser Funktion die Konfiguration der Lineage-Erfassung für Managed Service for Apache Spark, BigQuery und Managed Service for Apache Airflow unterstützt.

Im Knowledge Catalog wird die Ressourcenhierarchie (Projekt, dann Ordner, dann Organisation) ausgewertet, um die effektive Konfiguration zu ermitteln. Die erste Konfiguration, die auf einer beliebigen Ebene in diesem Aufwärtslauf explizit festgelegt wird, wird wirksam.

  • Wenn Sie eine Konfiguration auf Projektebene festlegen, wird sie vom Knowledge Catalog verwendet.
  • Wenn auf Projektebene keine Konfiguration festgelegt ist, verwendet Knowledge Catalog die Konfiguration des nächstgelegenen übergeordneten Ordners mit einer expliziten Konfiguration.
  • Wenn keine Konfiguration auf Projekt- oder Ordnerebene festgelegt ist, wird die Konfiguration auf Organisationsebene verwendet.
  • Wenn auf keiner dieser Ebenen eine Konfiguration festgelegt ist, verwendet Knowledge Catalog den Systemstandard für die Integration. Die Standardeinstellung für die Konfiguration der Lineage-Aktivierung kann Aktiviert oder Deaktiviert sein. Für Managed Service for Apache Spark, BigQuery und Managed Service for Apache Airflow ist die Erfassung von Lineage-Daten standardmäßig aktiviert, wenn die Data Lineage API aktiv ist.

Angenommen, Sie haben eine Organisation test-org mit den folgenden Lineage-Konfigurationen für 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 von Lineage-Informationen deaktiviert. Knowledge Catalog beginnt mit der Auswertung von project-a, findet keine Konfiguration, wechselt zu folder-a und wendet die Konfiguration Deaktiviert aus folder-a an.
  • Für project-b ist die Aufnahme von Lineage-Informationen deaktiviert. Knowledge Catalog beginnt mit der Auswertung ab project-b und wendet die Deaktiviert-Konfiguration an. Dadurch werden die Einstellungen unter folder-b und test-org überschrieben.

Wenn Sie die Generierung von Herkunftsdaten steuern, können Sie Kosten und Governance-Richtlinien besser verwalten. Sie können beispielsweise die Erfassung von Lineage-Informationen für Entwicklungsprojekte oder Arbeitslasten mit hohem Volumen deaktivieren, für die kein Lineage-Tracking erforderlich ist.

Informationen zum Konfigurieren und Steuern der Lineage-Erfassung finden Sie unter Lineage-Erfassung für einen Dienst steuern.

Regionsübergreifende Datenherkunft

Die Datenherkunft ist ein von Natur aus regionalisierter Dienst. Herkunftsmetadaten, einschließlich Links, Prozessen und Ereignissen, werden sicher aufgezeichnet und an dem geografischen Standort isoliert, an dem die zugrunde liegende Datentransformation oder Asset-Änderung erfolgt.

Da moderne Unternehmensdatenarchitekturen skaliert werden, überschreiten Pipeline-Workflows häufig Projekt- und regionale Grenzen. 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.

Um einen umfassenden End-to-End-Überblick über den Lebenszyklus Ihrer Daten in diesen unabhängigen geografischen Einheiten zu erhalten, verwenden Sie eine multiregionale Methode zur Suche nach dem Datenursprung.

Weitere Informationen finden Sie unter Suche nach Lineage in mehreren Regionen.

Überlegungen und Einschränkungen zur Data Lineage

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

Steuerung des Datenursprungs auf Produktebene

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

Auswirkungen auf die Abrechnung

Zusätzlich zu den Standardpreisen sollten Sie Folgendes beachten:

  • Die Data Lineage API wird pro Projekt ausgeführt. Prüfen Sie die Auswirkungen auf die Abrechnung, bevor Sie die Funktion für datenintensive Projekt-Workflows aktivieren.
  • Bei BigQuery Omni wird die Verarbeitung von Lineage-Daten auf bestimmte Regionen verteilt. Die Kosten hängen von den Regionen ab, in denen die Verarbeitung erfolgt.

Compliance mit der Datenherkunft

  • Data-Lineage-Datensätze enthalten Metadaten zur Datenübertragung, aber nicht die Daten selbst. Weitere Informationen dazu, welche Felder in den Metadaten enthalten sind, finden Sie im Modell für Informationen 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 Lineage-Metadaten zu verwenden.

Einschränkungen bei der Datenherkunft

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

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

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

  • Bei der Datenherkunft werden keine Informationen zur direkten Herkunft für BigQuery-Routinen aufgezeichnet. Wenn eine Routine in einer Abfrage verwendet wird, werden in den Datensatz zur Datenherkunft die Herkunft zwischen den Tabellen, aus denen die Routine Daten liest, als Abhängigkeiten von Tabellen geschrieben, in die die Abfrage Daten 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, in der die Ressource gehostet wird.

Einschränkungen der Herkunft auf Spaltenebene

Für den Spaltenursprung gelten die folgenden zusätzlichen Einschränkungen:

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

  • Der Upstream-Lineage auf Spaltenebene wird für externe Tabellen nicht erfasst.

  • Die Herkunft auf Spaltenebene wird nicht erfasst,wenn in einem Job mehr als 1.500 Links auf Spaltenebene erstellt werden. In diesen Fällen wird nur die Lineage auf Tabellenebene erfasst.

  • Die Unterstützung für den Datenursprung auf Spaltenebene ist auf Spalten der obersten Ebene in BigQuery-Tabellen beschränkt. Verschachtelte Felder in komplexen Typen wie STRUCT oder JSON werden nicht unterstützt.

  • Die Suchfunktion mit dem Feldparameter funktioniert nur für Links, in denen Spalte-zu-Spalte-Beziehungen explizit definiert sind. Es werden keine Ergebnisse zurückgegeben oder Links durchlaufen, die nur auf Tabellenebene definiert sind. Die Suche zwischen Links auf Tabellen- und Spaltenebene wird nicht unterstützt. Sie können also beispielsweise nicht alle Spalten finden, die mit einem Link auf Tabellenebene verknüpft sind, oder umgekehrt. Die API gibt nur Links zurück, bei denen sowohl für die Quelle als auch für das Ziel ein Feld angegeben ist.

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

  • Einschränkungen der Konsole:

    • Das Durchlaufen des Lineage-Diagramms 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 abzurechnen. Weitere Informationen finden Sie unter Preise.

  • Wenn Sie die Gebühren für die Datenherkunft von anderen Gebühren in der Premium-Verarbeitungs-SKU für den 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