Data Mesh-Nutzerhandbuch

Das Data Mesh for Cortex-Framework erweitert die Datengrundlage, um Datengovernance, Auffindbarkeit und Zugriffssteuerung über BigQuery-Metadaten und Dataplex zu ermöglichen. Dazu wird eine grundlegende Reihe von Metadatenressourcen und BigQuery-Asset-Hinweisen bereitgestellt, die angepasst und optional zusammen mit der Datengrundlage bereitgestellt werden können. Diese Basisspezifikationen bieten eine benutzerdefinierte Konfiguration, die die Metadatengrundlage für die Cortex Framework Data Foundation ergänzt. Lesen Sie den Artikel Data Mesh-Konzepte, bevor Sie mit diesem Leitfaden fortfahren.

Die auf dieser Seite beschriebenen Schritte sind speziell für die Konfiguration von Data Mesh für das Cortex Framework vorgesehen. Die Data Mesh-Konfigurationsdateien finden Sie im Abschnitt Data Mesh-Verzeichnisse in den Ordnern, die für jede Arbeitslast spezifisch sind.

Design

Das Data Mesh von Cortex ist ähnlich aufgebaut wie die gesamte Datengrundlage und besteht aus drei Phasen mit verschiedenen Unterkomponenten, die von Cortex oder Nutzern verwaltet werden:

1. Aktualisierung der Basisressourcenspezifikationen: Mit jeder Version aktualisiert Cortex die Basisressourcenspezifikationen und bietet so eine standardisierte Metadatengrundlage für das Data Mesh.
2. Anpassung der Ressourcenspezifikationen: Vor der Bereitstellung können Nutzer die Ressourcenspezifikationen an ihre spezifischen Anwendungsfälle und Anforderungen anpassen.
3. Bereitstellung und Aktualisierung von Data Mesh:Nutzer können Data Mesh in der Cortex-Konfigurationsdatei aktivieren. Es wird nach den Datenassets während der Cortex-Bereitstellung bereitgestellt. Außerdem haben Nutzer die Möglichkeit, das Data Mesh unabhängig für weitere Updates bereitzustellen.

Data Mesh-Verzeichnisse

Die Basiskonfigurationsdateien für Data Mesh für jede Arbeitslast und Datenquelle finden Sie an den folgenden Speicherorten. Angenommen, die Verzeichnisse haben ein unterschiedliches Dateistruktur, aber alle Spezifikationen befinden sich im Ordner config.

Metadatenressourcen werden auf Datenquellenebene mit einer einzelnen YAML-Datei pro Google Cloud -Projekt definiert und enthalten eine Liste aller Ressourcen. Nutzer können die vorhandene Datei erweitern oder bei Bedarf zusätzliche YAML-Dateien mit zusätzlichen Ressourcenspezifikationen in diesem Verzeichnis erstellen.

Asset-Hinweise werden auf Asset-Ebene definiert und enthalten viele YAML-Dateien im Verzeichnis mit einer einzelnen Anmerkung pro Datei.

APIs aktivieren und Berechtigungen prüfen

Wenn Sie die Standardwerte für Data Mesh ändern, können Sie Funktionen implementieren, die über Beschreibungen hinausgehen. Wenn Sie die Standardwerte für Data Mesh in config.json ändern müssen, um Funktionen zu implementieren, die über Beschreibungen hinausgehen, müssen die erforderlichen APIs und Berechtigungen wie in der folgenden Tabelle beschrieben festgelegt sein. Wenn Sie Data Mesh mit der Datengrundlage bereitstellen, gewähren Sie dem Nutzer, der die Bereitstellung durchführt, oder dem Cloud Build-Konto Berechtigungen. Wenn die Bereitstellung verschiedene Quell- und Zielprojekte umfasst, müssen diese APIs und Berechtigungen in beiden Projekten aktiviert sein, sofern diese Funktionen verwendet werden.

Informationen zu den Basisressourcenspezifikationen

Die primäre Schnittstelle zur Konfiguration des Data Mesh für Cortex sind die Grundressourcenspezifikationen. Dabei handelt es sich um eine Reihe von YAML-Dateien, die die bereitgestellten Metadatenressourcen und Anmerkungen definieren. Die Basisspezifikationen enthalten erste Empfehlungen und Syntaxbeispiele, sollen aber an die Anforderungen der Nutzer angepasst werden. Diese Spezifikationen fallen in zwei Kategorien:

• Metadatenressourcen, die auf verschiedene Daten-Assets angewendet werden können. Dazu gehören beispielsweise Katalog-Tag-Vorlagen, mit denen festgelegt wird, wie Assets mit Geschäftsbereichen getaggt werden können.
• Anmerkungen, die angeben, wie die Metadatenressourcen auf ein bestimmtes Daten-Asset angewendet werden. Beispiel: Ein Katalog-Tag, das eine bestimmte Tabelle der Domain „Verkäufe“ zuordnet.

In den folgenden Abschnitten finden Sie grundlegende Beispiele für die einzelnen Spezifikationstypen und eine Anleitung zum Anpassen. Die Basisspezifikationen sind mit ## CORTEX-CUSTOMER getaggt. Dort sollten sie so angepasst werden, dass sie zu einer Bereitstellung passen, wenn die zugehörige Bereitstellungsoption aktiviert ist. Informationen zu erweiterten Verwendungsmöglichkeiten finden Sie in der kanonischen Definition dieser Spezifikationsschemata in src/common/data_mesh/src/data_mesh_types.py.

Metadaten-Ressourcen

Die Metadatenressourcen sind freigegebene Entitäten in einem Projekt, die auf viele Daten-Assets angewendet werden können. Die meisten Spezifikationen enthalten ein display_name-Feld, das den folgenden Kriterien unterliegt:

• Sie darf nur Unicode-Buchstaben, Ziffern (0–9), Unterstriche (_), Bindestriche (-) und Leerzeichen ( ) enthalten.
• Der Name darf nicht mit einem Leerzeichen beginnen oder enden.
• Maximale Länge: 200 Zeichen.

In einigen Fällen wird der display_name auch als ID verwendet, was zusätzliche Anforderungen mit sich bringen kann. In diesen Fällen sind Links zur kanonischen Dokumentation enthalten.

Wenn die Bereitstellung auf Metadatenressourcen in verschiedenen Quell- und Zielprojekten verweist, muss für jedes Projekt eine Spezifikation definiert sein. Cortex Salesforce (SFDC) enthält beispielsweise zwei Lake-Spezifikationen. Eine für die Roh- und CDC-Zonen und eine für die Berichterstellung.

Dataplex-Lakes

Mit Dataplex Lakes, Zonen und Assets werden die Daten aus technischer Sicht organisiert. Lakes haben eine region und Zonen eine location_type. Beide sind mit dem Cortex-Standort verknüpft (config.json > location). Der Cortex-Standort gibt an, wo die BigQuery-Datasets gespeichert werden. Er kann eine einzelne oder mehrere Regionen umfassen. Die Zone location_type sollte daher auf SINGLE_REGION | MULTI_REGION festgelegt sein. Lake-Regionen müssen jedoch immer eine einzelne Region sein. Wenn der Cortex-Speicherort und die Zone location_type mehrere Regionen umfassen, wählen Sie für die Lake-Region eine einzelne Region innerhalb dieser Gruppe aus.

• Anforderungen
  • Der See display_name wird als lake_id verwendet und muss den offiziellen Anforderungen entsprechen. Das gilt auch für die Zone und das Asset display_name. Zonen-IDs müssen in allen Lakes im Projekt eindeutig sein.
  • Seespezifikationen müssen einer einzelnen Region zugeordnet sein.
  • Die asset_name sollte mit der ID des BigQuery-Datasets übereinstimmen. Die display_name kann jedoch ein nutzerfreundlicheres Label sein.
• Einschränkungen
  • Dataplex unterstützt nur die Registrierung von BigQuery-Datasets und nicht von einzelnen Tabellen als Dataplex-Assets.
  • Ein Asset kann nur in einer einzigen Zone registriert sein.
  • Dataplex wird nur an bestimmten Standorten unterstützt. Weitere Informationen finden Sie unter Dataplex-Standorte.

Sehen Sie sich das folgende Beispiel in lakes.yaml an.

Diese Ressourcen werden in YAML-Dateien definiert, in denen data_mesh_types.Lakes angegeben ist.

Katalog-Tag-Vorlagen

Mit Data Catalog-Tag-Vorlagen können Sie BigQuery-Tabellen oder einzelnen Spalten Kontext hinzufügen. Sie helfen Ihnen, Ihre Daten sowohl aus technischer als auch aus geschäftlicher Sicht zu kategorisieren und zu verstehen, und sind in die Suchtools von Dataplex eingebunden. Sie definieren die Felder, die Sie zum Labeln Ihrer Daten verwenden können, und die Art der Informationen, die jedes Feld enthalten kann (z. B. Text, Zahl, Datum). Katalog-Tags sind Instanzen der Vorlagen mit tatsächlichen Feldwerten.

Das Vorlagenfeld display_name wird als Feld-ID verwendet und muss den Anforderungen für TagTemplate.fields entsprechen, die in Class TagTemplate angegeben sind. Weitere Informationen zu unterstützten Feldtypen finden Sie unter Data Catalog-Feldtypen.

In Cortex Data Mesh werden alle Tag-Vorlagen öffentlich lesbar erstellt. Außerdem wird ein zusätzliches level-Konzept für Tag-Vorlagenspezifikationen eingeführt, mit dem festgelegt wird, ob ein Tag auf ein gesamtes Asset, einzelne Felder innerhalb eines Assets oder beides angewendet werden soll. Die möglichen Werte sind: ASSET | FIELD | ANY. Dieser Schritt ist derzeit nicht zwingend erforderlich. Bei zukünftigen Validierungsüberprüfungen wird jedoch sichergestellt, dass Tags bei der Bereitstellung auf der richtigen Ebene angewendet werden.

Sehen Sie sich das folgende Beispiel an.

Vorlagen werden in YAML-Dateien definiert, in denen data_mesh_types.CatalogTagTemplates angegeben ist.

Katalog-Tags sind Instanzen der Vorlagen und werden unten im Abschnitt zu Asset-Hinweisen beschrieben.

Zugriffssteuerung auf Asset- und Spaltenebene mit Tag-Vorlagen

Mit Cortex Framework können Sie die Zugriffssteuerung auf Asset- oder Spaltenebene für alle Artefakte aktivieren, die mit einer Katalog-Tag-Vorlage verknüpft sind. Wenn Nutzer beispielsweise Zugriff auf Assets basierend auf dem Geschäftsbereich gewähren möchten, können sie asset_policies für die line_of_business-Katalog-Tag-Vorlage mit verschiedenen Hauptpersonen erstellen, die für jede Geschäftsdomain angegeben sind. Für jede Richtlinie ist filters zulässig. Damit können Tags nur mit bestimmten Werten abgeglichen werden. In diesem Fall können wir die domain-Werte abgleichen. Beachten Sie, dass diese filters-Werte nur Gleichheitsabgleiche und keine anderen Operatoren unterstützen. Wenn mehrere Filter aufgeführt sind, müssen die Ergebnisse alle Filter erfüllen (z. B. filter_a AND filter_b). Die endgültigen Asset-Richtlinien sind die Vereinigung der direkt in den Anmerkungen definierten und der aus den Vorlagenrichtlinien.

Die Zugriffssteuerung auf Spaltenebene mit Katalog-Tags funktioniert ähnlich. Dabei werden Richtlinien-Tags auf übereinstimmende Felder angewendet. Da jedoch nur ein Richtlinien-Tag auf eine Spalte angewendet werden kann, gilt folgende Priorität:

1. Direktes Richtlinien-Tag:Wenn ein Richtlinien-Tag direkt in der Spaltenanmerkung definiert ist, hat es Vorrang.
2. Richtlinie für die Abgleichs-Tag-Vorlage: Andernfalls wird der Zugriff durch die erste Abgleichsrichtlinie bestimmt, die für ein Feld in der zugehörigen Katalog-Tag-Vorlage definiert ist.

Wenn Sie diese Funktion verwenden, empfehlen wir dringend, die Bereitstellung von Katalog-Tags und Zugriffssteuerungslisten (ACLs) gemeinsam zu aktivieren oder zu deaktivieren. So wird sichergestellt, dass die ACLs ordnungsgemäß bereitgestellt werden.

Die technischen Daten für diese erweiterte Funktion finden Sie in den Definitionen der Parameter asset_policies und field_policies in data_mesh_types.CatalogTagTemplate.

Glossar für Kataloge

Mit dem Glossar können Sie ein Wörterbuch mit Begriffen erstellen, die in bestimmten Spalten in Datenassets verwendet werden und möglicherweise nicht allgemein bekannt sind. Nutzer können Begriffe manuell in der Console hinzufügen. Die Ressourcenspezifikationen unterstützen diese Funktion jedoch nicht.

Richtlinientaxonomien und -Tags

Mit Richtlinientaxonomien und ‑Tags können Sie die Zugriffssteuerung auf Spaltenebene für vertrauliche Datenressourcen standardisieren. So könnte es beispielsweise eine Taxonomie für Tags geben, mit der personenidentifizierbare Daten in einer bestimmten Branche gesteuert werden, bei der nur bestimmte Gruppen maskierte Daten, nicht maskierte Daten oder gar keinen Lesezugriff haben.

Weitere Informationen zu den Richtlinientaxonomien und ‑tags finden Sie in der Dokumentation Einführung in die Datenmaskierung von Spalten. Die folgenden Abschnitte sind besonders relevant:

• Rollen interagieren
• Autorisierungsübernahme
• Maskierungsregeln und Hierarchie
• Best Practices für Richtlinien-Tags

Das Cortex-Framework bietet Beispiel-Richtlinien-Tags, die zeigen, wie sie angegeben werden und welche Verwendungsmöglichkeiten sie haben. Ressourcen, die sich auf die Zugriffssteuerung auswirken, sind in der Data Mesh-Bereitstellung jedoch standardmäßig nicht aktiviert.

Sehen Sie sich das folgende Beispiel an.

Richtlinientaxonomien werden in YAML-Dateien definiert, in denen data_mesh_types.PolicyTaxonomies angegeben ist.

Asset-Anmerkungen

In Anmerkungen werden Metadaten für ein bestimmtes Asset angegeben. Sie können auf die definierten freigegebenen Metadatenressourcen verweisen. Anmerkungen können Folgendes umfassen:

• Asset-Beschreibungen
• Feldbeschreibungen
• Katalog-Tags
• Zugriffssteuerung auf Asset-, Zeilen- und Spaltenebene

Die Cortex Framework Data Foundation bietet vorkonfigurierte Anmerkungen (Beschreibungen) für die folgenden Arbeitslasten.

• SAP ECC (roh, CDC und Berichterstellung)
• SAP S4 HANA (roh, CDC und Berichte)
• SFDC (nur Berichterstellung)
• Oracle EBS (nur Berichterstellung)
• CM360 (nur Berichte)
• Google Ads (nur Berichte)
• Meta (nur Berichterstellung)
• SFMC (nur Berichterstellung)
• TikTok (nur Berichterstellung)
• YouTube (mit DV360) (nur Berichte)
• Google Analytics 4 (nur Berichte)

Sehen Sie sich das folgende Beispiel an.

Anmerkungen werden in YAML-Dateien definiert, in denen data_mesh_types.BqAssetAnnotation angegeben ist.

Katalog-Tags

Katalog-Tags sind Instanzen der definierten Vorlagen, denen Feldwerte zugewiesen sind, die für das jeweilige Asset gelten. Achten Sie darauf, Werte zuzuweisen, die mit den in der zugehörigen Vorlage deklarierten Feldtypen übereinstimmen.

TIMESTAMP-Werte müssen eines der folgenden Formate haben:

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

Sehen Sie sich das folgende Beispiel an.

Siehe Spezifikationsdefinition in data_mesh_types.CatalogTag.

Leser und Hauptkonten für Zugriffsrichtlinien angeben

Mithilfe von Zugriffsrichtlinien können Sie den Zugriff auf Ihre BigQuery-Daten im Cortex Framework steuern. Mit diesen Richtlinien wird festgelegt, wer (Rechteinhaber) auf bestimmte Daten-Assets, Zeilen innerhalb eines Assets oder sogar einzelne Spalten zugreifen kann. Hauptkonten müssen einem bestimmten Format entsprechen, das durch IAM Policy Binding member definiert ist.

Zugriff auf Asset-Ebene

Sie können Zugriff auf ganze BigQuery-Assets mit verschiedenen Berechtigungen gewähren:

• READER: Daten im Asset ansehen.
• WRITER: Das Asset ändern und ihm Daten hinzufügen.
• OWNER : Vollständige Kontrolle über das Asset, einschließlich Zugriffsverwaltung.

Diese Berechtigungen entsprechen der GRANT DCL-Anweisung in SQL.

Im Gegensatz zum Verhalten bei den meisten Ressourcen und Anmerkungen werden mit dem Überschreibungsflag keine vorhandenen Hauptkonten mit der Rolle OWNERS entfernt. Wenn Sie neue Inhaber hinzufügen, während die Option „Überschreiben“ aktiviert ist, werden sie nur den vorhandenen Inhabern angefügt. Dies ist eine Sicherheitsmaßnahme, um einen unbeabsichtigten Verlust des Zugriffs zu verhindern. Asset-Inhaber können Sie über die Console entfernen. Durch das Überschreiben werden vorhandene Hauptkonten mit der Rolle READER oder WRITER entfernt.

Sehen Sie sich das folgende Beispiel an.

Siehe Spezifikationsdefinition in data_mesh_types.BqAssetPolicy.

Zugriff auf Zeilenebene

Sie können Zugriff auf Zeilensätze gewähren, die bestimmte Spaltenwertfilter erfüllen. Wenn Sie die Zeilenzugriffsrichtlinie angeben, wird der angegebene Filterstring in eine CREATE DDL statement eingefügt. Wenn das Flag overwrite aktiviert ist, werden alle vorhandenen Zeilenzugriffsrichtlinien gelöscht, bevor neue angewendet werden.

Beachten Sie Folgendes zum Zugriff auf Zeilenebene:

• Wenn Sie Zeilenzugriffsrichtlinien hinzufügen, können Nutzer, die in diesen Richtlinien nicht angegeben sind, keine Zeilen sehen.
• Zeilenrichtlinien funktionieren nur mit Tabellen, nicht mit Ansichten.
• Verwenden Sie keine partitionierten Spalten in den Filtern für Zugriffsrichtlinien auf Zeilenebene. Informationen zum Asset-Typ und zu partitionierten Spalten finden Sie in der zugehörigen YAML-Datei mit den Berichtseinstellungen.

Weitere Informationen zu Zugriffsrichtlinien auf Zeilenebene finden Sie unter Best Practices für die Sicherheit auf Zeilenebene.

Sehen Sie sich das folgende Beispiel an.

Siehe Spezifikationsdefinition in data_mesh_types.BqRowPolicy.

Zugriff auf Spaltenebene

Wenn Sie den Zugriff auf Spaltenebene aktivieren möchten, versehen Sie einzelne Felder mit einem Richtlinien-Tag, das durch den Namen des Richtlinien-Tags und den Namen der Taxonomie gekennzeichnet ist. Aktualisieren Sie die Metadatenressource des Richtlinien-Tags, um die Zugriffssteuerung zu konfigurieren.

Sehen Sie sich das folgende Beispiel an.

Siehe Spezifikationsdefinition in data_mesh_types.PolicyTagId.

Data Mesh bereitstellen

Das Data Mesh kann entweder als Teil der Bereitstellung der Datengrundlage oder eigenständig bereitgestellt werden. In beiden Fällen wird die Cortex-Datei config.json verwendet, um relevante Variablen wie BigQuery-Datasetnamen und Bereitstellungsoptionen zu ermitteln. Standardmäßig werden beim Bereitstellen des Data Mesh keine vorhandenen Ressourcen oder Anmerkungen entfernt oder überschrieben, um unbeabsichtigte Datenverluste zu vermeiden. Es ist jedoch auch möglich, vorhandene Ressourcen zu überschreiben, wenn das Paket einzeln bereitgestellt wird.

Bereitstellungsoptionen

Die folgenden Bereitstellungsoptionen können je nach den Anforderungen und Ausgabenbeschränkungen des Nutzers unter config.json > DataMesh aktiviert oder deaktiviert werden.

Bereitstellung mit der Data Foundation

Standardmäßig wird mit config.json > deployDataMesh die Bereitstellung der Data Mesh-Asset-Beschreibungen am Ende jedes Schritts zum Erstellen der Arbeitslast aktiviert. Für diese Standardkonfiguration müssen keine zusätzlichen APIs oder Rollen aktiviert werden. Zusätzliche Funktionen des Data Mesh können mit der Datengrundlage bereitgestellt werden, indem die Bereitstellungsoptionen, die erforderlichen APIs und Rollen aktiviert und die zugehörigen Ressourcenspezifikationen geändert werden.

Alleine bereitstellen

Wenn Sie nur das Data Mesh bereitstellen möchten, können Sie die Datei common/data_mesh/deploy_data_mesh.py verwenden. Dieses Dienstprogramm wird während des Build-Prozesses verwendet, um das Data Mesh nacheinander bereitzustellen. Bei direktem Aufruf kann es aber auch zum Bereitstellen mehrerer Arbeitslasten gleichzeitig verwendet werden. Die Arbeitslasten für die zu implementierenden Spezifikationen sollten in der Datei config.json aktiviert sein. Achten Sie beispielsweise darauf, dass deploySAP=true, wenn Sie das Data Mesh für SAP bereitstellen.

Damit Sie die Bereitstellung mit den erforderlichen Paketen und Versionen durchführen können, können Sie das Dienstprogramm mit den folgenden Befehlen über dasselbe Image ausführen, das auch für den Cortex-Bereitstellungsprozess verwendet wird:

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

Informationen zu den verfügbaren Parametern und ihrer Verwendung erhalten Sie mit dem folgenden Befehl:

  python src/common/data_mesh/deploy_data_mesh.py -h

Im Folgenden finden Sie ein Beispiel für die Aufrufabfolge für SAP ECC:

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

Informationen zu Verzeichnisspeicherorten finden Sie im Abschnitt Data Mesh-Verzeichnisse.

Überschreiben

Durch das Bereitstellen von Data Mesh werden standardmäßig keine vorhandenen Ressourcen oder Anmerkungen überschrieben. Das Flag --overwrite kann jedoch aktiviert werden, wenn nur das Data Mesh bereitgestellt wird, um die Bereitstellung auf die folgenden Arten zu ändern.

Wenn Sie Metadatenressourcen wie Datenseen, Katalog-Tag-Vorlagen und Richtlinien-Tags überschreiben, werden alle vorhandenen Ressourcen mit demselben Namen gelöscht. Vorhandene Ressourcen mit anderen Namen werden jedoch nicht geändert. Wenn also eine Ressourcenspezifikation vollständig aus der YAML-Datei entfernt und das Data Mesh dann mit aktiviertem Überschreiben neu bereitgestellt wird, wird diese Ressourcenspezifikation nicht gelöscht, da es keine Namenskollision gibt. So wird verhindert, dass die Bereitstellung von Cortex Data Mesh sich auf vorhandene Ressourcen auswirkt, die möglicherweise bereits verwendet werden.

Bei verschachtelten Ressourcen wie Seen und Zonen werden beim Überschreiben einer Ressource alle untergeordneten Elemente entfernt. Wenn Sie beispielsweise einen See überschreiben, werden auch die vorhandenen Zonen und Asset-Referenzen entfernt. Bei überschriebenen Katalog-Tag-Vorlagen und Richtlinien-Tags werden auch die vorhandenen zugehörigen Anmerkungsverweise aus den Assets entfernt. Wenn Sie Katalog-Tags in einer Asset-Anmerkung überschreiben, werden nur vorhandene Instanzen von Katalog-Tags überschrieben, die dieselbe Vorlage haben.

Überschreibungen von Asset- und Feldbeschreibungen werden nur wirksam, wenn eine gültige, nicht leere neue Beschreibung angegeben wurde, die mit der vorhandenen Beschreibung in Konflikt steht.

ACLs verhalten sich dagegen anders. Wenn ACLs überschrieben werden, werden alle vorhandenen Hauptkonten entfernt (mit Ausnahme der Inhaber auf Asset-Ebene). Das liegt daran, dass die Hauptkonten, die aus den Zugriffsrichtlinien ausgeschlossen werden, für Hauptkonten, denen Zugriff gewährt wird, genauso wichtig sind.

Data Mesh kennenlernen

Nach der Bereitstellung des Data Mesh können Nutzer die Datenassets mit Data Catalog suchen und ansehen. Dazu zählt auch die Möglichkeit, Assets anhand der angewendeten Katalog-Tag-Werte zu finden. Nutzer können bei Bedarf auch Begriffe aus dem Katalogglossar manuell erstellen und anwenden.

Auf der Seite „BigQuery-Schema“ können Sie die bereitgestellten Zugriffsrichtlinien aufrufen, um zu sehen, welche Richtlinien auf ein bestimmtes Asset auf jeder Ebene angewendet werden.

Data Lineage

Nutzer können die Abfolge zwischen BigQuery-Assets aktivieren und visualisieren. Auf die Stammbäume kann auch programmatisch über die API zugegriffen werden. Data Lineage unterstützt nur die Herkunft auf Asset-Ebene. Die Datenableitung ist nicht mit dem Cortex Data Mesh verknüpft. Es können jedoch in Zukunft neue Funktionen eingeführt werden, die die Ableitung nutzen.

Anfragen zu Cortex Data Mesh oder Cortex Framework finden Sie im Abschnitt Support.