Data Mesh-Nutzerhandbuch

Data Mesh for Cortex Framework erweitert die Datenbasis, um Datenverwaltung, Auffindbarkeit und Zugriffssteuerung über BigQuery-Metadaten und Dataplex Universal Catalog zu ermöglichen. Dies wird durch die Bereitstellung einer grundlegenden Gruppe von Metadatenressourcen und BigQuery-Asset-Anmerkungen implementiert, die angepasst und optional zusammen mit der Data Foundation bereitgestellt werden können. Diese Basisspezifikationen bieten eine benutzerdefinierte Konfiguration, die die Metadatengrundlage zur Ergänzung der Data Foundation von Cortex Framework bildet. Lesen Sie sich die Data Mesh-Konzepte durch, bevor Sie mit diesem Leitfaden fortfahren.

Die auf dieser Seite beschriebenen Schritte sind speziell für die Konfiguration von Data Mesh für Cortex Framework vorgesehen. Die Data Mesh-Konfigurationsdateien finden Sie in den Ordnern, die für die einzelnen Arbeitslasten im Abschnitt „Data Mesh-Verzeichnisse“ angegeben sind.

Achtung :Diese Data Mesh-Anleitung kann sich im Laufe der Zeit ändern. Wenden Sie sich bei Feedback oder Problemen an das Cortex-Team.

Abbildung 1. Data-Mesh-Architektur für das Cortex Framework.

Design

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

1. Aktualisierung der Spezifikationen der Basisressourcen: Mit jeder Version aktualisiert Cortex die Spezifikationen der Basisressourcen 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. Data Mesh-Bereitstellung und ‑Aktualisierungen:Nutzer können Data Mesh in der Cortex-Konfigurationsdatei aktivieren. Sie wird nach den Datenassets während der Cortex-Bereitstellung bereitgestellt. Außerdem können Nutzer das Data Mesh unabhängig bereitstellen, um weitere Aktualisierungen vorzunehmen.

Abbildung 2: Data Mesh-Design für Cortex Framework

Data Mesh-Verzeichnisse

Die Data Mesh-Basiskonfigurationsdateien für die einzelnen Arbeitslasten und Datenquellen finden Sie an den folgenden Speicherorten. Die Verzeichnisse enthalten unterschiedliche Dateistrukturen, aber alle Spezifikationen befinden sich im Ordner config.

Arbeitslast	Datenquelle	Verzeichnispfad
Operativ	SAP ECC	src/SAP/SAP_REPORTING/config/ecc
	SAP S/4 HANA	src/SAP/SAP_REPORTING/config/s4
	Salesforce Sales Cloud (SFDC)	src/SFDC/config
	Oracle EBS	src/OracleEBS/config
Marketing	CM360	src/marketing/src/CM360/config
	Google Ads	src/marketing/src/GoogleAds/config
	Meta	src/marketing/src/Meta/config
	Salesforce Marketing Cloud (SFMC)	src/marketing/src/SFMC/config
	TikTok	src/marketing/src/TikTok/config
	YouTube (mit DV360)	src/marketing/src/DV360/config
	Google Analytics 4	src/marketing/src/GA4/config

Hinweis :Data Mesh unterstützt keine Daten von LiveRamp oder Dun & Bradstreet (ESG).

Metadatenressourcen werden auf Datenquellebene 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-Anmerkungen 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 Standardwerte für Data Mesh ändern, können Sie Funktionen implementieren, die über Beschreibungen hinausgehen. Wenn Sie Standardwerte für Data Mesh in config.json ändern müssen, um Funktionen über Beschreibungen hinaus zu implementieren, müssen die erforderlichen APIs und Berechtigungen wie in der folgenden Tabelle beschrieben festgelegt werden. Wenn Sie Data Mesh mit der Data Foundation bereitstellen, gewähren Sie dem bereitstellenden Nutzer oder dem Cloud Build-Konto Berechtigungen. Wenn für die Bereitstellung verschiedene Quell- und Zielprojekte verwendet werden, müssen diese APIs und Berechtigungen in beiden Projekten aktiviert sein, sofern die entsprechenden Funktionen verwendet werden.

Feature	Berechtigungsrollen	Dokumentation
BigQuery-Asset- und ‑Zeilenzugriff	BigQuery-Dateninhaber	Weitere Informationen finden Sie unter Erforderliche Rollen für die Asset-Rollen und Erforderliche Berechtigungen für die Zeilenrollen.
BigQuery-Spaltenzugriff	Richtlinien-Tag-Administrator	Weitere Informationen finden Sie in der Dokumentation unter Rollen, die mit Zugriffssteuerung auf Spaltenebene verwendet werden und Zugriff mit Zugriffssteuerung auf Spaltenebene beschränken.
Katalog-Tags	Data Catalog-Tag-Vorlagen-Inhaber	Weitere Informationen finden Sie in der Dokumentation zu BigQuery-Tabelle mithilfe von Data Catalog taggen und Data Catalog IAM.
Dataplex Universal Catalog-Lakes	Dataplex Universal Catalog Editor	Weitere Informationen finden Sie in der Dokumentation unter Lake erstellen.

Hinweis :Für Cortex Data Mesh ist keine Integration der Dataproc- und Dataproc Metastore-APIs erforderlich.

Grundlegende Ressourcenspezifikationen

Die primäre Schnittstelle zum Konfigurieren des Data Mesh für Cortex sind die Basisspezifikationen für Ressourcen. Dabei handelt es sich um eine Reihe von YAML-Dateien, die standardmäßig bereitgestellt werden und die Metadatenressourcen und Anmerkungen definieren, die bereitgestellt werden. Die Basisspezifikationen enthalten erste Empfehlungen und Syntaxbeispiele, sollen aber an die Bedürfnisse der Nutzer angepasst werden. Diese Spezifikationen lassen sich in zwei Kategorien unterteilen:

• Metadatenressourcen, die auf verschiedene Daten-Assets angewendet werden können. Zum Beispiel Katalog-Tag-Vorlagen, die definieren, wie Assets mit geschäftlichen Domains getaggt werden können.
• Annotationen, die angeben, wie die Metadatenressourcen auf ein bestimmtes Daten-Asset angewendet werden. Beispiel: Ein Katalog-Tag, mit dem eine bestimmte Tabelle der Domain „Sales“ (Vertrieb) zugeordnet wird.

In den folgenden Abschnitten finden Sie grundlegende Beispiele für jeden Spezifikationstyp und eine Anleitung zum Anpassen der Spezifikationen. Die Basisspezifikationen sind mit ## CORTEX-CUSTOMER gekennzeichnet, wenn sie für eine Bereitstellung geändert werden müssen, falls die zugehörige Bereitstellungsoption aktiviert ist. Für erweiterte Anwendungsfälle finden Sie die kanonische Definition dieser Spezifikationsschemas in src/common/data_mesh/src/data_mesh_types.py.

Metadaten-Ressourcen

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

• Darf nur Unicode-Buchstaben, Ziffern (0–9), Unterstriche (_), Bindestriche (-) und Leerzeichen ( ) enthalten.
• Darf nicht mit 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 in der Bereitstellung auf Metadatenressourcen in verschiedenen Quell- und Zielprojekten verwiesen wird, muss für jedes Projekt eine Spezifikation definiert sein. Cortex Salesforce (SFDC) enthält beispielsweise zwei Lake-Spezifikationen. Eine für die Rohdaten- und CDC-Zonen und eine für Berichte.

Dataplex Universal Catalog-Lakes

Dataplex Universal Catalog-Lakes, ‑Zonen und ‑Assets werden verwendet, um die Daten aus technischer Sicht zu organisieren. Lakes haben eine region und Zonen eine location_type. Beide beziehen sich auf den Cortex-Standort (config.json > location). Der Cortex-Standort definiert, wo die BigQuery-Datasets gespeichert werden. Er kann eine einzelne Region oder mehrere Regionen umfassen. Die Zone location_type sollte auf SINGLE_REGION | MULTI_REGION festgelegt werden, damit sie übereinstimmt. Lake-Regionen müssen jedoch immer eine einzelne Region sein. Wenn sich der Cortex-Standort und die Zone location_type in mehreren Regionen befinden, wählen Sie für die Lake-Region eine einzelne Region innerhalb dieser Gruppe aus.

• Voraussetzungen
  • Der Lake 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.
  • Lake-Spezifikationen müssen einer einzelnen Region zugeordnet sein.
  • Die asset_name sollte mit der ID des BigQuery-Datasets übereinstimmen, die display_name kann jedoch ein benutzerfreundlicheres Label sein.
• Einschränkungen
  • Dataplex Universal Catalog unterstützt nur die Registrierung von BigQuery-Datasets und nicht von einzelnen Tabellen als Dataplex Universal Catalog-Assets.
  • Ein Asset kann nur in einer Zone registriert werden.
  • Dataplex Universal Catalog wird nur an bestimmten Standorten unterstützt. Weitere Informationen finden Sie unter Dataplex Universal Catalog-Standorte.

lakes.yaml – siehe folgendes Beispiel.

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

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. Die Suche ist in Dataplex Universal Catalog integriert. Sie definieren die spezifischen Felder, die Sie zum Labeln Ihrer Daten verwenden können, und den Typ von Informationen, die in den einzelnen Feldern enthalten sein können (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 als öffentlich lesbar erstellt. Außerdem wird das zusätzliche Konzept level für Tag-Vorlagenspezifikationen eingeführt. Damit wird definiert, 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. Derzeit wird dies nicht streng durchgesetzt, aber bei zukünftigen Validierungsprüfungen wird möglicherweise darauf geachtet, dass Tags während der Bereitstellung auf der entsprechenden Ebene angewendet werden.

Hier finden Sie ein Beispiel.

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

Katalog-Tags sind Instanzen der Vorlagen und werden unten im Abschnitt „Asset-Anmerkungen“ beschrieben.

Zugriffssteuerung auf Asset- und Spaltenebene mit Tag-Vorlagen

Das Cortex Framework bietet die Möglichkeit, die Zugriffssteuerung auf Asset- oder Spaltenebene für alle Artefakte zu 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 erstellen, wobei für jede Geschäftsdomain unterschiedliche Principals angegeben werden. Für jede Richtlinie werden filters akzeptiert, mit denen nur Tags mit bestimmten Werten abgeglichen werden können. In diesem Fall konnten wir die domain-Werte abgleichen. Beachten Sie, dass diese filters nur den Abgleich auf Gleichheit 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ültige Gruppe von Asset-Richtlinien ist die Vereinigung der Richtlinien, die direkt in den Anmerkungen definiert sind, und der Richtlinien aus den Vorlagenrichtlinien.

Die Zugriffssteuerung auf Spaltenebene mit Katalog-Tags funktioniert ähnlich, indem Richtlinien-Tags auf übereinstimmende Felder angewendet werden. 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 übereinstimmende Tag-Vorlagen: Andernfalls wird der Zugriff durch die erste übereinstimmende Richtlinie 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 (Access Control Lists, ACLs) gemeinsam zu aktivieren oder zu deaktivieren. So wird sichergestellt, dass die ACLs ordnungsgemäß bereitgestellt werden.

Die Spezifikationen für dieses erweiterte Feature finden Sie in den Definitionen der Parameter asset_policies und field_policies in data_mesh_types.CatalogTagTemplate.

Glossar für Kataloge

Das Glossar ist ein Tool, mit dem Sie ein Wörterbuch mit Begriffen erstellen können, die in bestimmten Spalten von Daten-Assets verwendet werden und möglicherweise nicht allgemein verständlich sind. Nutzer können Begriffe manuell in der Console hinzufügen, aber die Ressourcenspezifikationen bieten keine Unterstützung.

Richtlinientaxonomien und ‑tags

Mit Richtlinientaxonomien und ‑tags lässt sich die Zugriffssteuerung auf Spaltenebene für vertrauliche Datenressourcen auf standardisierte Weise implementieren. Es könnte beispielsweise eine Taxonomie für Tags geben, mit der personenbezogene Daten in einer bestimmten Branche gesteuert werden. Nur bestimmte Gruppen können maskierte oder nicht maskierte Daten lesen oder haben überhaupt keinen Lesezugriff.

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

• Rollen interagieren
• Übernahme von Autorisierungen
• Maskierungsregeln und Hierarchie
• Best Practices für Richtlinientags

Das Cortex Framework bietet Beispiel-Richtlinien-Tags, um zu veranschaulichen, wie sie angegeben werden und welche potenziellen Anwendungsfälle es gibt. Ressourcen, die sich auf die Zugriffssteuerung auswirken, sind jedoch in der Data Mesh-Bereitstellung standardmäßig nicht aktiviert.

Hier finden Sie ein Beispiel.

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

Asset-Anmerkungen

Annotationen geben Metadaten an, die für ein bestimmtes Asset gelten, und können auf die definierten gemeinsamen Metadatenressourcen verweisen. Zu den Anmerkungen gehören:

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

Hinweis :Wenn Sie eine Anmerkungsdatei ändern, werden in der Console nur neue Zeilen in Beschreibungen als Leerzeichen gerendert.

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

• SAP ECC (Rohdaten, CDC und Berichterstellung)
• SAP S4 HANA (Rohdaten, CDC und Berichterstellung)
• 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 Berichterstellung)
• Google Analytics 4 (nur Berichte)

Hier finden Sie ein Beispiel.

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

Katalog-Tags

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

TIMESTAMP-Werte sollten eines der folgenden Formate haben:

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

Hier finden Sie ein Beispiel.

Die Spezifikationsdefinition finden Sie in data_mesh_types.CatalogTag.

Leser und Hauptkonten für Zugriffsrichtlinien angeben

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

Zugriff auf Asset-Ebene

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

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

Diese Berechtigungen entsprechen der GRANT DCL-Anweisung in SQL.

Anders als bei den meisten Ressourcen und Anmerkungen werden mit dem overwrite-Flag keine vorhandenen Hauptkonten mit der Rolle OWNERS entfernt. Wenn Sie neue Inhaber hinzufügen und die Überschreibungsfunktion aktiviert ist, werden sie nur an die vorhandenen Inhaber angehängt. So soll ein unbeabsichtigter Verlust des Zugriffs verhindert werden. Wenn du Asset-Inhaber entfernen möchtest, musst du die Console verwenden. Beim Überschreiben werden vorhandene Hauptkonten mit der Rolle READER oder WRITER entfernt.

Hier finden Sie ein Beispiel.

Die Spezifikationsdefinition finden Sie in data_mesh_types.BqAssetPolicy.

Zugriff auf Zeilenebene

Sie können den Zugriff auf Gruppen von Zeilen basierend auf bestimmten Filtern für Spaltenwerte gewähren. 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, haben alle Nutzer, die nicht in diesen Richtlinien angegeben sind, keinen Zugriff auf Zeilen.
• Zeilenrichtlinien funktionieren nur mit Tabellen, nicht mit Ansichten.
• Vermeiden Sie die Verwendung partitionierter Spalten in den Filtern Ihrer Zugriffsrichtlinie 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.

Hier finden Sie ein Beispiel.

Die Spezifikationsdefinition finden Sie in data_mesh_types.BqRowPolicy.

Zugriff auf Spaltenebene

Um den Zugriff auf Spaltenebene zu aktivieren, versehen Sie einzelne Felder mit einem Richtlinien-Tag, das durch den Namen des Richtlinien-Tags und den Namen der Taxonomie identifiziert wird. Aktualisieren Sie die Metadatenressource des Richtlinien-Tags, um die Zugriffssteuerung zu konfigurieren.

Hier finden Sie ein Beispiel.

Die Spezifikationsdefinition finden Sie in data_mesh_types.PolicyTagId.

Data Mesh bereitstellen

Das Data Mesh kann entweder als Teil der Bereitstellung der Datengrundlage oder separat bereitgestellt werden. In beiden Fällen wird die Cortex-Datei config.json verwendet, um relevante Variablen wie BigQuery-Dataset-Namen und Bereitstellungsoptionen zu ermitteln. Standardmäßig werden beim Bereitstellen des Data Mesh keine vorhandenen Ressourcen oder Anmerkungen entfernt oder überschrieben, um unbeabsichtigte Verluste zu vermeiden. Es besteht jedoch auch die Möglichkeit, vorhandene Ressourcen zu überschreiben, wenn sie separat bereitgestellt werden.

Bereitstellungsoptionen

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

Hinweis :Wenn deployACLs aktiviert ist, empfehlen wir dringend, die Zugriffssteuerung ausschließlich über diese Ressourcenspezifikationen vorzunehmen. So wird verhindert, dass der Zugriff versehentlich hinzugefügt oder entfernt wird.

Option	Hinweise
deployDescriptions	Dies ist die einzige Option, die standardmäßig aktiviert ist. Sie stellt BigQuery-Annotationen mit Asset- und Spaltenbeschreibungen bereit. Es ist nicht erforderlich, zusätzliche APIs oder Berechtigungen zu aktivieren.
deployLakes	Stellt Lakes und Zonen bereit.
deployCatalog	Stellt Catalog Template-Ressourcen und die zugehörigen Tags in Asset-Anmerkungen bereit.
deployACLs	Stellt Richtlinientaxonomieressourcen sowie Zugriffssteuerungsrichtlinien auf Asset-, Zeilen- und Spaltenebene über Asset-Anmerkungen bereit. Die Logs enthalten Meldungen, die angeben, wie sich die Zugriffsrichtlinien geändert haben.

Bereitstellung mit der Data Foundation

Standardmäßig wird durch config.json > deployDataMesh die Bereitstellung der Asset-Beschreibungen für das Data Mesh am Ende jedes Build-Schritts für Arbeitslasten ermöglicht. Für diese Standardkonfiguration müssen keine zusätzlichen APIs oder Rollen aktiviert werden. Zusätzliche Funktionen des Data Mesh können mit der Data Foundation bereitgestellt werden, indem Sie die Bereitstellungsoptionen, die erforderlichen APIs und Rollen aktivieren und die zugehörigen Ressourcenspezifikationen ändern.

Allein bereitstellen

Wenn Nutzer 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 der Build-Prozesse verwendet, um das Data Mesh jeweils für eine Arbeitslast bereitzustellen. Wenn es direkt aufgerufen wird, kann es aber auch verwendet werden, um mehrere Arbeitslasten gleichzeitig bereitzustellen. Die Arbeitslasten für die bereitzustellenden Spezifikationen müssen in der Datei config.json aktiviert sein. Achten Sie beispielsweise darauf, dass deploySAP=true bei der Bereitstellung von Data Mesh für SAP.

Damit Sie sicher sein können, dass Sie mit den erforderlichen Paketen und Versionen bereitstellen, können Sie das Dienstprogramm mit den folgenden Befehlen über dasselbe Image ausführen, das vom 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

Wenn Sie Hilfe zu den verfügbaren Parametern und ihrer Verwendung benötigen, führen Sie den folgenden Befehl aus:

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

Hier ist ein Beispiel für den Aufruf 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 Verzeichnispfaden finden Sie im Abschnitt Data Mesh-Verzeichnisse.

Überschreiben

Warnung :Lesen Sie diesen Abschnitt sorgfältig, bevor Sie die Überschreibungsoption verwenden.

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

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

Wenn Sie eine verschachtelte Ressource wie Lakes und Zonen überschreiben, werden alle untergeordneten Elemente entfernt. Wenn Sie beispielsweise einen Lake überschreiben, werden auch die vorhandenen Zonen und Asset-Verweise entfernt. Bei Katalog-Tag-Vorlagen und Richtlinien-Tags, die überschrieben werden, werden auch die vorhandenen zugehörigen Anmerkungsreferenzen aus den Assets entfernt. Wenn Sie Katalog-Tags in einer Asset-Anmerkung überschreiben, werden nur vorhandene Instanzen von Katalog-Tags überschrieben, die dieselbe Vorlage verwenden.

Das Überschreiben von Asset- und Feldbeschreibungen erfolgt nur, wenn eine gültige, nicht leere neue Beschreibung angegeben wird, die mit der vorhandenen Beschreibung in Konflikt steht.

Andererseits verhalten sich ACLs anders. Durch das Überschreiben von ACLs werden alle vorhandenen Hauptkonten entfernt (mit Ausnahme von Inhabern auf Asset-Ebene). Das liegt daran, dass die Hauptkonten, die aus Zugriffsrichtlinien ausgeschlossen werden, genauso wichtig sind wie die Hauptkonten, denen Zugriff gewährt wird.

Data Mesh erkunden

Nach der Bereitstellung des Data Mesh können Nutzer mit Data Catalog nach den Datenassets suchen und sie ansehen. Dazu gehört auch die Möglichkeit, Assets anhand der angewendeten Katalog-Tag-Werte zu ermitteln. Bei Bedarf können Nutzer auch manuell Katalogglossarbegriffe erstellen und anwenden.

Zugriffsrichtlinien, die bereitgestellt wurden, können auf der Seite „BigQuery-Schema“ aufgerufen werden, um die auf ein bestimmtes Asset auf jeder Ebene angewendeten Richtlinien zu sehen.

Data Lineage

Es kann für Nutzer hilfreich sein, die Herkunft von BigQuery-Assets zu aktivieren und zu visualisieren. Der Datenursprung kann auch programmatisch über die API aufgerufen werden. Data Lineage unterstützt nur die Lineage auf Asset-Ebene. Die Datenherkunft ist nicht mit dem Cortex Data Mesh verknüpft. Es können jedoch in Zukunft neue Funktionen eingeführt werden, die die Datenherkunft nutzen.

Bei Anfragen zu Cortex Data Mesh oder Cortex Framework wenden Sie sich bitte an den Support.