Datenverwaltungs- und Analyseplattform für Unternehmen bereitstellen

Last reviewed 2025-04-04 UTC

Eine Plattform für die Datenverwaltung und ‑analyse auf Unternehmensebene bietet eine Enklave, in der Sie vertrauliche Informationen speichern, analysieren und bearbeiten können, während Sicherheitskontrollen beibehalten werden. Mit der Enterprise Data Mesh-Architektur können Sie eine Plattform auf Google Cloud für Datenmanagement und ‑analyse bereitstellen. Die Architektur ist für den Einsatz in einer Hybridumgebung konzipiert, in der Google Cloud Komponenten mit Ihren vorhandenen lokalen Komponenten und Betriebsprozessen interagieren.

Die Enterprise Data Mesh-Architektur umfasst Folgendes:

• Ein GitHub-Repository, das eine Reihe von Terraform-Konfigurationen, Skripts und Code zum Erstellen der folgenden Elemente enthält:
  • Ein Governance-Projekt, mit dem Sie die Implementierung des CDMC Key Controls Framework (Cloud Data Management Capabilities) von Google nutzen können.
  • Ein Beispiel für eine Datenplattform, die interaktive Workflows und Produktionsworkflows unterstützt.
  • Eine Producer-Umgebung innerhalb der Datenplattform, die mehrere Datenbereiche unterstützt. Datendomänen sind logische Gruppierungen von Datenelementen.
  • Eine Nutzerumgebung innerhalb der Datenplattform, die mehrere Nutzerprojekte unterstützt.
  • Ein Dienst für die Datenübertragung, der die Identitätsföderation von Arbeitslasten und die Tink-Verschlüsselungsbibliothek verwendet, um Ihnen zu helfen, Daten sicher in Google Cloud zu übertragen.
  • Ein Beispiel für eine Datendomäne, die Aufnahme-, nicht vertrauliche und vertrauliche Projekte enthält.
  • Ein Beispiel für ein Datenzugriffssystem, mit dem Datenverbraucher Zugriff auf Datasets anfordern und Dateninhaber Zugriff auf diese Datasets gewähren können. Das Beispiel enthält auch einen Workflow-Manager, der die IAM-Berechtigungen dieser Datasets entsprechend ändert.
• Einer Anleitung zu den Architektur-, Design-, Sicherheitskontrollen und Betriebsprozessen, die Sie mit dieser Architektur implementieren (dieses Dokument).

Die Data-Mesh-Architektur für Unternehmen ist mit dem Blueprint für Unternehmensgrundlagen kompatibel. Der Blueprint zu den Unternehmensgrundlagen bietet eine Reihe von Diensten auf Basisebene, auf die diese Architektur basiert, z. B. VPC-Netzwerke und Logging. Sie können diese Architektur bereitstellen, ohne den Blueprint für Unternehmensgrundlagen bereitzustellen, wenn IhreGoogle Cloud -Umgebung die erforderlichen Funktionen bietet.

Dieses Dokument richtet sich an Cloud-Architekten, Data Scientists, Data Engineers und Sicherheitsarchitekten, die die Architektur verwenden können, um umfassende Datendienste auf Google Cloudzu erstellen und bereitzustellen. In diesem Dokument wird davon ausgegangen,dass Sie mit den Konzepten von Data Meshes, Google CloudDatendiensten und der Google Cloud Implementierung des CDMC-Frameworks vertraut sind.

Architektur

Die Data-Mesh-Architektur für Unternehmen bietet eine mehrschichtige Lösung für die Datenaufnahme, ‑verarbeitung und ‑verwaltung. Die Architektur soll über einen CI/CD-Workflow bereitgestellt und gesteuert werden. Das folgende Diagramm zeigt, wie sich die von dieser Architektur bereitgestellte Datenschicht auf andere Ebenen in Ihrer Umgebung bezieht.

Dieses Diagramm enthält Folgendes:

• Die Google Cloud -Infrastruktur bietet Sicherheitsfunktionen wie Verschlüsselung inaktiver Daten und Verschlüsselung während der Übertragung sowie Grundbausteine wie Computing und Speicher.
• Die Unternehmensgrundlage bietet eine Baseline von Ressourcen wie Identität, Netzwerk, Logging, Monitoring und Bereitstellungssystemen, mit denen Sie Google Cloud für Ihre Datenarbeitslasten einführen können.
• Die Datenschicht bietet verschiedene Funktionen wie Datenaufnahme, Datenspeicherung, Datenzugriffssteuerung und Data Governance, Datenmonitoring und Datenfreigabe.
• Die Anwendungsebene repräsentiert verschiedene Anwendungen, die die Assets der Datenschicht verwenden.
• CI/CD bietet die Tools, um die Bereitstellung, Konfiguration, Verwaltung und Bereitstellung von Infrastruktur, Workflows und Softwarekomponenten zu automatisieren. Mit diesen Komponenten sorgen Sie für konsistente, zuverlässige und überprüfbare Bereitstellungen und können manuelle Fehler minimieren und den gesamten Entwicklungszyklus beschleunigen.

Um zu zeigen, wie die Datenumgebung verwendet wird, enthält die Architektur einen Beispiel-Datenworkflow. Der Workflow für Beispieldaten umfasst die folgenden Prozesse: Data Governance, Datenaufnahme, Datenverarbeitung, Datenfreigabe und Datennutzung.

Wichtige Architekturentscheidungen

In der folgenden Tabelle sind die wichtigsten Entscheidungen zur Architektur zusammengefasst.

Entscheidungsbereich	Entscheidung
Google Cloud architecture
Ressourcenhierarchie	Die Architektur verwendet die Ressourcenhierarchie aus dem Blueprint für Unternehmensgrundlagen.
Netzwerk	Die Architektur umfasst einen Beispiel-Datenübertragungsdienst, der die Identitätsföderation von Arbeitslasten und eine Tink-Bibliothek verwendet.
Rollen und IAM-Berechtigungen	Die Architektur umfasst segmentierte Rollen für Datenersteller, Datennutzer, Data Governance und Datenplattform.
Allgemeine Datendienste
Metadaten	Die Architektur verwendet Data Catalog, um Datenmetadaten zu verwalten.
Zentrale Richtlinienverwaltung	Zum Verwalten von Richtlinien wird die Implementierung des CDMC-Frameworks von Google Cloudverwendet.
Verwaltung des Datenzugriffs	Zur Kontrolle des Zugriffs auf Daten umfasst die Architektur einen unabhängigen Prozess, bei dem Datennutzer den Zugriff auf Daten-Assets vom Dateninhaber anfordern müssen.
Datenqualität	Die Architektur verwendet die Cloud Data Quality Engine, um Datenqualitätsregeln für angegebene Tabellenspalten zu definieren und auszuführen. Die Datenqualität wird anhand von Messwerten wie Richtigkeit und Vollständigkeit gemessen.
Datensicherheit	Die Architektur verwendet Tagging, Verschlüsselung, Maskierung, Tokenisierung und IAM-Steuerelemente, um Datensicherheit zu gewährleisten.
Datendomäne
Datenumgebungen	Die Architektur umfasst drei Umgebungen. Zwei Umgebungen (Nicht-Produktion und Produktion) sind operative Umgebungen, die von Pipelines gesteuert werden. Eine Umgebung (Entwicklung) ist eine interaktive Umgebung.
Dateninhaber	Dateninhaber nehmen Daten-Assets auf, verarbeiten sie, stellen sie zur Verfügung und gewähren Zugriff darauf.
Datenkonsumenten	Datennutzer fordern Zugriff auf Datenassets an.
Onboarding und Vorgänge
Pipelines	Die Architektur verwendet die folgenden Pipelines zum Bereitstellen von Ressourcen: Fundament-Pipeline Infrastrukturpipeline Artefakt-Pipelines Service Catalog-Pipeline
Repositories	Für jede Pipeline wird ein separates Repository verwendet, um die Verantwortlichkeiten zu trennen.
Prozessablauf	Für Änderungen an der Produktionsumgebung sind ein Absender und ein Genehmiger erforderlich.
Cloud Operations
Übersichten für Datenprodukte	Die Berichts-Engine generiert Übersichten für Datenprodukte.
Cloud Logging	Die Architektur verwendet die Logging-Infrastruktur aus dem Blueprint für Unternehmensgrundlagen.
Cloud Monitoring	Die Architektur verwendet die Monitoring-Infrastruktur aus dem Blueprint für Unternehmensgrundlagen.

Identität: Rollen Gruppen zuordnen

Das Data Mesh nutzt die vorhandene Architektur für die Verwaltung des Identitätslebenszyklus, die Autorisierung und die Authentifizierung des Enterprise Foundations-Blueprints. Nutzern werden Rollen nicht direkt zugewiesen. Stattdessen sind Gruppen die primäre Methode zum Zuweisen von Rollen und Berechtigungen in IAM. IAM-Rollen und -Berechtigungen werden während der Projekterstellung über die Foundation-Pipeline zugewiesen.

Im Data Mesh werden Gruppen einem von vier Schlüsselbereichen zugeordnet: Infrastruktur, Daten-Governance, domänenbasierte Datenproduzenten und domänenbasierte Nutzer.

Die Berechtigungsbereiche für diese Gruppen sind die folgenden:

• Der Berechtigungsbereich der Infrastrukturgruppe ist das gesamte Data Mesh.
• Der Berechtigungsbereich der Data-Governance-Gruppen ist das Data-Governance-Projekt.
• Die Berechtigungen von domainbasierten Produzenten und Nutzern sind auf ihre Datendomäne beschränkt.

In den folgenden Tabellen sind die verschiedenen Rollen aufgeführt, die in dieser Data Mesh-Implementierung verwendet werden, sowie die zugehörigen Berechtigungen.

Infrastruktur

Gruppe	Beschreibung	Rollen
[e-mail]	Allgemeine Administratoren des Data Mesh	roles/owner (Datenplattform)

Data Governance

Gruppe	Beschreibung	Rollen
[e-mail]	Administratoren des Data Governance-Projekts	roles/owner für das Data Governance-Projekt
[e-mail]	Entwickler, die die Data Governance-Komponenten erstellen und verwalten	Mehrere Rollen für das Data Governance-Projekt, darunter roles/viewer, BigQuery-Rollen und Data Catalog-Rollen
[e-mail]	Leser von Data Governance-Informationen	roles/viewer
[e-mail]	Sicherheitsadministratoren des Governance-Projekts	roles/orgpolicy.policyAdmin und roles/iam.securityReviewer
[e-mail]	Gruppe mit der Berechtigung, Tag-Vorlagen zu verwenden	roles/datacatalog.tagTemplateUser
[e-mail]	Gruppe mit der Berechtigung, Tag-Vorlagen zu verwenden und Tags hinzuzufügen	roles/datacatalog.tagTemplateUser und roles/datacatalog.tagEditor
[e-mail]	Dienstkontogruppe für Security Command Center-Benachrichtigungen	Keine. Dies ist eine Gruppe für die Mitgliedschaft. Es wird ein Dienstkonto mit diesem Namen erstellt, das die erforderlichen Berechtigungen hat.

Domainbasierte Daten-Ersteller

Gruppe	Beschreibung	Rollen
gcp-dm-{data_domain_name}[e-mail]	Administratoren einer bestimmten Datendomäne	roles/owner für das Projekt der Datendomäne
gcp-dm-{data_domain_name}[e-mail]	Entwickler, die Datenprodukte in einer Datendomäne erstellen und verwalten	Mehrere Rollen für das Projekt der Datendomäne, darunter roles/viewer, BigQuery-Rollen und Cloud Storage-Rollen
gcp-dm-{data_domain_name}[e-mail]	Leser der Informationen zur Datendomain	roles/viewer
gcp-dm-{data_domain_name}-metadata-editors@{var.domain}	Bearbeiter von Data Catalog-Einträgen	Rollen zum Bearbeiten von Data Catalog-Einträgen
gcp-dm-{data_domain_name}[e-mail]	Data Stewards für die Datendomäne	Rollen zum Verwalten von Metadaten und Data Governance-Aspekten

Domainbasierte Datenkonsumenten

Gruppe	Beschreibung	Rollen
gcp-dm-consumer-{project_name}[e-mail]	Administratoren eines bestimmten Nutzerprojekts	roles/owner für das Nutzerprojekt
gcp-dm-consumer-{project_name}[e-mail]	Entwickler, die an einem Nutzerprojekt arbeiten	Mehrere Rollen im Kundenprojekt, einschließlich roles/viewer und BigQuery-Rollen
gcp-dm-consumer-{project_name}[e-mail]	Leser der Nutzerprojektinformationen	roles/viewer

Organisationsstruktur

Um zwischen Produktionsvorgängen und Produktionsdaten zu unterscheiden, werden in der Architektur verschiedene Umgebungen zum Entwickeln und Freigeben von Arbeitsabläufen verwendet. Zu den Produktionsvorgängen gehören die Governance, die Nachvollziehbarkeit und die Wiederholbarkeit eines Workflows sowie die Prüfbarkeit der Ergebnisse des Workflows. Produktionsdaten sind möglicherweise sensible Daten, die Sie für die Führung Ihrer Organisation benötigen. Alle Umgebungen sind so konzipiert, dass Sie Ihre Daten mit Sicherheitskontrollen aufnehmen und verarbeiten können.

Um Data Scientists und Data Engineers zu unterstützen, umfasst die Architektur eine interaktive Umgebung, in der Entwickler direkt mit der Umgebung arbeiten und Dienste über einen kuratierten Katalog von Lösungen hinzufügen können. Betriebsumgebungen werden über Pipelines gesteuert, die eine codierte Architektur und Konfiguration haben.

Diese Architektur verwendet die Organisationsstruktur des Unternehmensgrundlagen-Blueprints als Grundlage für die Bereitstellung von Datenarbeitslasten. Das folgende Diagramm zeigt die Ordner und Projekte der obersten Ebene, die in der Enterprise Data Mesh-Architektur verwendet werden.

In der folgenden Tabelle werden die Ordner und Projekte der obersten Ebene beschrieben, die Teil der Architektur sind.

Ordner	Komponente	Beschreibung
common	prj-c-artifact-pipeline	Enthält die Bereitstellungspipeline, mit der die Code-Artefakte der Architektur erstellt werden.
	prj-c-service-catalog	Enthält die Infrastruktur, die vom Service Catalog zum Bereitstellen von Ressourcen in der interaktiven Umgebung verwendet wird.
	prj-c-datagovernance	Enthält alle Ressourcen, die von der Implementierung des CDMC-Frameworks durch Google Cloudverwendet werden.
development	fldr-d-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform für die Entwicklung von Anwendungsfällen im interaktiven Modus.
non-production	fldr-n-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform zum Testen von Anwendungsfällen, die Sie in einer Betriebsumgebung bereitstellen möchten.
production	fldr-p-dataplatform	Enthält die Projekte und Ressourcen der Datenplattform für die Bereitstellung in der Produktion.

Ordner für Datenplattform

Der Datenplattformordner enthält alle Komponenten der Datenebene und einige der CDMC-Ressourcen. Außerdem enthalten der Datenplattformordner und das Data-Governance-Projekt die CDMC-Ressourcen. Das folgende Diagramm zeigt die Ordner und Projekte, die im Ordner der Datenplattform bereitgestellt werden.

Jeder Datenplattformordner enthält einen Umgebungsordner (Produktion, Nicht-Produktion und Entwicklung). In der folgenden Tabelle werden die Ordner in den einzelnen Datenplattformordnern beschrieben.

Ordner	Beschreibung
Produzenten	Enthält die Datenbereiche.
Nutzer	Enthält die Nutzerprojekte.
Datendomain	Enthält die Projekte, die mit einer bestimmten Domain verknüpft sind.

Ordner „Producers“

Jeder Ordner für Produzenten enthält eine oder mehrere Datendomänen. Eine Datendomäne bezieht sich auf eine logische Gruppierung von Datenelementen, die eine gemeinsame Bedeutung, einen gemeinsamen Zweck oder einen gemeinsamen geschäftlichen Kontext haben. Mit Datendomains können Sie Daten-Assets innerhalb einer Organisation kategorisieren und organisieren. Das folgende Diagramm zeigt die Struktur einer Datendomäne. Bei der Architektur werden Projekte für jede Umgebung im Ordner „data platform“ bereitgestellt.

In der folgenden Tabelle werden die Projekte beschrieben, die für jede Umgebung im Ordner „Datenplattform“ bereitgestellt werden.

Projekt	Beschreibung
Aufnahme	Im Aufnahmeprojekt werden Daten in die Datendomäne aufgenommen. Die Architektur enthält Beispiele dafür, wie Sie Daten in BigQuery, Cloud Storage und Pub/Sub streamen können. Das Aufnahmeprojekt enthält auch Beispiele für Dataflow und Managed Service for Apache Airflow, mit denen Sie die Transformation und Übertragung aufgenommener Daten orchestrieren können.
Nicht vertraulich	Das nicht vertrauliche Projekt enthält anonymisierte Daten. Sie können Daten maskieren, in Containern speichern, verschlüsseln, tokenisieren oder verschleiern. Mit Richtlinientags können Sie festlegen, wie die Daten präsentiert werden.
Vertraulich	Das Projekt für vertrauliche Daten enthält Klartextdaten. Sie können den Zugriff über IAM-Berechtigungen steuern.

Verbraucherordner

Der Nutzerordner enthält Nutzerprojekte. Mit Verbraucherprojekten können Sie Datennutzer basierend auf ihrer erforderlichen Vertrauensgrenze segmentieren. Jedes Projekt wird einer separaten Nutzergruppe zugewiesen und der Gruppe wird projektbezogen Zugriff auf die erforderlichen Daten-Assets gewährt. Sie können das Verbraucherprojekt verwenden, um die Daten für die Gruppe zu erheben, zu analysieren und zu erweitern.

Allgemeiner Ordner

Der Ordner „common“ enthält die Dienste, die von verschiedenen Umgebungen und Projekten verwendet werden. In diesem Abschnitt werden die Funktionen beschrieben, die dem gemeinsamen Ordner hinzugefügt werden, um das Enterprise Data Mesh zu ermöglichen.

CDMC-Architektur

Die Architektur verwendet die CDMC-Architektur für Data Governance. Die Data Governance-Funktionen befinden sich im Data Governance-Projekt im Common-Ordner. Das folgende Diagramm zeigt die Komponenten der CDMC-Architektur. Die Zahlen im Diagramm stellen die Schlüsselkontrollen dar, die mit Google Cloud-Diensten behandelt werden.

In der folgenden Tabelle werden die Komponenten der CDMC-Architektur beschrieben, die in der Enterprise Data Mesh-Architektur verwendet werden.

CDMC-Komponente	Google Cloud -Dienst	Beschreibung
Zugriffs- und Lebenszykluskomponenten
Schlüsselverwaltung	Cloud KMS	Ein Dienst, der Verschlüsselungsschlüssel zum Schutz sensibler Daten sicher verwaltet.
Record Manager	Cloud Run	Eine Anwendung, die umfassende Logs und Aufzeichnungen von Datenverarbeitungsaktivitäten führt, damit Organisationen die Datennutzung nachverfolgen und prüfen können.
Richtlinie zur Archivierung	BigQuery	Eine BigQuery-Tabelle, die die Speicherrichtlinie für Daten enthält.
Berechtigungen	BigQuery	Eine BigQuery-Tabelle, in der Informationen dazu gespeichert werden, wer auf vertrauliche Daten zugreifen kann. Diese Tabelle sorgt dafür, dass nur autorisierte Nutzer basierend auf ihren Rollen und Berechtigungen auf bestimmte Daten zugreifen können.
Komponenten scannen
Datenverlust	Sensitive Data Protection	Dienst, der zum Prüfen von Assets auf sensible Daten verwendet wird.
DLP-Ergebnisse	BigQuery	Eine BigQuery-Tabelle, in der Datenklassifizierungen innerhalb der Datenplattform katalogisiert werden.
Richtlinien	BigQuery	Eine BigQuery-Tabelle, die konsistente Data Governance-Praktiken enthält (z. B. Datenzugriffstypen).
Abrechnungsexport	BigQuery	Eine Tabelle, in der Kosteninformationen gespeichert werden, die aus Cloud Billing exportiert werden, um die Analyse von Kostenmesswerten zu ermöglichen, die mit Daten-Assets verknüpft sind.
Cloud Data Quality Engine	Cloud Run	Eine Anwendung, mit der Datenqualitätsprüfungen für Tabellen und Spalten ausgeführt werden.
Ergebnisse zur Datenqualität	BigQuery	Eine BigQuery-Tabelle, in der erkannte Abweichungen zwischen den definierten Datenqualitätsregeln und der tatsächlichen Qualität der Daten-Assets aufgezeichnet werden.
Berichtskomponenten
Planer	Cloud Scheduler	Ein Dienst, der steuert, wann die Cloud Data Quality Engine ausgeführt wird und wann die Prüfung durch Sensitive Data Protection erfolgt.
Report Engine	Cloud Run	Eine Anwendung, mit der Berichte erstellt werden, mit denen die Einhaltung der Steuerelemente des CDMC-Frameworks nachvollzogen und gemessen werden kann.
Ergebnisse und Assets	BigQuery und Pub/Sub	Ein BigQuery-Bericht zu Abweichungen oder Inkonsistenzen bei den Datenverwaltungsfunktionen, z. B. fehlende Tags, falsche Klassifizierungen oder nicht konforme Speicherorte.
Tags exportieren	BigQuery	Eine BigQuery-Tabelle, die aus Data Catalog extrahierte Tag-Informationen enthält.
Andere Komponenten
Richtlinienverwaltung	Organisationsrichtliniendienst	Ein Dienst, der Einschränkungen für den geografischen Speicherort von Daten definiert und erzwingt.
Attributbasierte Zugriffsrichtlinien	Access Context Manager	Ein Dienst, der detaillierte, attributbasierte Zugriffsrichtlinien definiert und erzwingt, damit nur autorisierte Nutzer von zulässigen Standorten und Geräten auf vertrauliche Informationen zugreifen können.
Metadaten	Data Catalog	Ein Dienst, in dem Metadaten zu den Tabellen gespeichert werden, die im Data Mesh verwendet werden.
Tag Engine	Cloud Run	Eine Anwendung, die Daten in BigQuery-Tabellen Tags hinzufügt.
CDMC-Berichte	Data Studio	Dashboards, mit denen Ihre Analysten Berichte ansehen können, die von den CDMC-Architektur-Engines generiert wurden.

CDMC-Implementierung

In der folgenden Tabelle wird beschrieben, wie die Architektur die Schlüsselkontrollen im CDMC-Framework implementiert.

CDMC-Kontrollanforderung	Implementierung
Compliance mit Datenkontrollen	Die Report Engine erkennt nicht konforme Datenassets und veröffentlicht Ergebnisse in einem Pub/Sub-Thema. Diese Ergebnisse werden auch in BigQuery geladen, um Berichte mit Data Studio zu erstellen.
Dateninhaberschaft wird sowohl für migrierte als auch für in der Cloud generierte Daten eingerichtet	Data Catalog erfasst automatisch technische Metadaten aus BigQuery. Tag Engine wendet Tags für Geschäftsmetadaten wie den Namen des Inhabers und die Vertraulichkeitsstufe aus einer Referenztabelle an. So wird sichergestellt, dass alle sensiblen Daten zur Einhaltung der Compliance-Vorschriften mit Inhaberinformationen getaggt werden. Dieser automatisierte Tagging-Prozess trägt zur Data Governance und Compliance bei, indem er sensible Daten identifiziert und mit den entsprechenden Eigentümerinformationen kennzeichnet.
Datenbeschaffung und -nutzung werden durch Automatisierung gesteuert und unterstützt	Data Catalog klassifiziert Datenassets, indem sie mit dem Flag is_authoritative getaggt werden, wenn sie eine autoritative Quelle sind. Data Catalog speichert die Informationen zusammen mit den technischen Metadaten automatisch in einem Datenregister. Die Report Engine und die Tag Engine können das Datenregister autoritativer Quellen mithilfe von Pub/Sub validieren und Berichte dazu erstellen.
Datenhoheit und grenzüberschreitende Datenübertragungen werden verwaltet	Der Organization Policy Service definiert zulässige Speicherregionen für Daten-Assets und Access Context Manager schränkt den Zugriff basierend auf dem Nutzerstandort ein. Data Catalog speichert die genehmigten Speicherorte als Metadaten-Tags. Die Report Engine vergleicht diese Tags mit dem tatsächlichen Speicherort der Daten-Assets in BigQuery und veröffentlicht alle Abweichungen als Ergebnisse über Pub/Sub. Security Command Center bietet eine zusätzliche Monitoring-Ebene, indem Sicherheitslückenergebnisse generiert werden, wenn Daten außerhalb der definierten Richtlinien gespeichert oder darauf zugegriffen wird.
Datenkataloge werden implementiert und verwendet und sind interoperabel	Data Catalog speichert und aktualisiert die technischen Metadaten für alle BigQuery-Daten-Assets und erstellt so einen kontinuierlich synchronisierten Data Catalog. Data Catalog sorgt dafür, dass alle neuen oder geänderten Tabellen und Ansichten sofort dem Katalog hinzugefügt werden. So wird ein aktuelles Inventar der Daten-Assets aufrechterhalten.
Datenklassifizierungen werden definiert und verwendet	Sensitive Data Protection untersucht BigQuery-Daten und identifiziert Typen sensibler Informationen. Diese Ergebnisse werden dann anhand einer Klassifizierungsreferenztabelle eingestuft und die höchste Vertraulichkeitsstufe wird als Tag in Data Catalog auf Spalten- und Tabellenebene zugewiesen. Tag Engine verwaltet diesen Prozess, indem der Data Catalog mit Vertraulichkeitstags aktualisiert wird, wenn neue Daten-Assets hinzugefügt oder vorhandene geändert werden. So wird eine ständig aktualisierte Klassifizierung von Daten nach Vertraulichkeit sichergestellt, die Sie mit Pub/Sub und integrierten Berichtstools überwachen und für die Sie Berichte erstellen können.
Datenberechtigungen werden verwaltet, erzwungen und nachverfolgt	Mit Richtlinien-Tags in BigQuery wird der Zugriff auf sensible Daten auf Spaltenebene gesteuert. So können nur autorisierte Nutzer auf bestimmte Daten zugreifen, die auf Grundlage des zugewiesenen Richtlinien-Tags festgelegt werden. IAM verwaltet den allgemeinen Zugriff auf das Data Warehouse, während in Data Catalog Vertraulichkeitseinstufungen gespeichert werden. Es werden regelmäßige Prüfungen durchgeführt, um sicherzustellen, dass alle vertraulichen Daten entsprechende Richtlinien-Tags haben. Alle Abweichungen werden über Pub/Sub zur Behebung gemeldet.
Zugriff, Verwendung und Ergebnisse von Daten nach ethischen Maßstäben werden verwaltet	Vereinbarungen zur Datenfreigabe für Anbieter und Nutzer werden in einem dedizierten BigQuery-Data-Warehouse gespeichert, um die Verwendungszwecke zu kontrollieren. Data Catalog kennzeichnet Daten-Assets mit den Informationen der Anbietervereinbarung, während Nutzervereinbarungen für die Zugriffssteuerung mit IAM-Bindungen verknüpft werden. Mit Abfragelabels werden Nutzungszwecke erzwungen. Nutzer müssen einen gültigen Zweck angeben, wenn sie vertrauliche Daten abfragen. Dieser wird anhand ihrer Berechtigungen in BigQuery validiert. Ein Audit-Trail in BigQuery erfasst alle Datenzugriffe und sorgt für die Einhaltung der Datenfreigabevereinbarungen.
Daten werden gesichert und Kontrollen werden nachgewiesen	Die Standardverschlüsselung ruhender Daten von Google schützt Daten, die auf der Festplatte gespeichert sind. Cloud KMS unterstützt kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für eine verbesserte Schlüsselverwaltung. BigQuery implementiert die dynamische Datenmaskierung auf Spaltenebene zur Anonymisierung und unterstützt die Anonymisierung auf Anwendungsebene während der Datenaufnahme. Data Catalog speichert Metadatentags für Verschlüsselungs- und De-Identifikationstechniken, die auf Datenassets angewendet werden. Automatisierte Prüfungen sorgen dafür, dass die Verschlüsselungs- und Anonymisierungsmethoden mit vordefinierten Sicherheitsrichtlinien übereinstimmen. Alle Abweichungen werden als Ergebnisse über Pub/Sub gemeldet.
Ein Datenschutz-Framework ist definiert und betriebsbereit	Data Catalog kennzeichnet vertrauliche Datenassets mit relevanten Informationen für die Folgenabschätzung, z. B. den Standort des Subjekts und Links zu Berichten zur Folgenabschätzung. Tag Engine wendet diese Tags basierend auf der Vertraulichkeit der Daten und einer Richtlinientabelle in BigQuery an, in der die Bewertungsanforderungen basierend auf dem Daten- und dem Personenstandort definiert sind. Dieser automatisierte Tagging-Prozess ermöglicht die kontinuierliche Überwachung und Berichterstellung zur Einhaltung der Anforderungen für Folgenabschätzungen. So wird sichergestellt, dass Datenschutz-Folgenabschätzungen (DSFAs) oder Folgenabschätzungen zum Schutz (Protection Impact Assessments, PIAs) durchgeführt werden, wenn dies erforderlich ist.
Der Datenlebenszyklus wird geplant und verwaltet	In Data Catalog werden Datenassets mit Aufbewahrungsrichtlinien versehen, in denen Aufbewahrungszeiträume und Ablaufaktionen (z. B. Archivieren oder Löschen) angegeben werden. Record Manager automatisiert die Durchsetzung dieser Richtlinien, indem BigQuery-Tabellen anhand der definierten Tags dauerhaft gelöscht oder archiviert werden. Durch diese Durchsetzung wird die Einhaltung der Datenlebenszyklus-Richtlinien sichergestellt und die Einhaltung der Anforderungen an die Datenaufbewahrung aufrechterhalten. Alle erkannten Abweichungen werden über Pub/Sub gemeldet.
Datenqualität wird verwaltet	Mit der Cloud Data Quality Engine werden Datenqualitätsregeln für angegebene Tabellenspalten definiert und ausgeführt. Die Datenqualität wird anhand von Messwerten wie Richtigkeit und Vollständigkeit gemessen. Die Ergebnisse dieser Prüfungen, einschließlich Erfolgsraten und ‑schwellenwerten, werden als Tags in Data Catalog gespeichert. Durch das Speichern dieser Ergebnisse können Sie die Datenqualität kontinuierlich überwachen und Berichte erstellen. Alle Probleme oder Abweichungen von akzeptablen Grenzwerten werden als Ergebnisse über Pub/Sub veröffentlicht.
Grundsätze des Kostenmanagements werden festgelegt und angewendet	Data Catalog speichert kostenbezogene Messwerte für Daten-Assets, z. B. Abfragekosten, Speicherkosten und Kosten für den Daten-Egress. Diese werden anhand von Abrechnungsinformationen berechnet, die aus Cloud Billing nach BigQuery exportiert werden. Durch das Speichern kostenbezogener Messwerte können Kosten umfassend nachverfolgt und analysiert werden. So wird die Einhaltung von Kostenrichtlinien und eine effiziente Ressourcennutzung gewährleistet. Alle Anomalien werden über Pub/Sub gemeldet.
Datenherkunft wird verstanden	Die integrierten Data Lineage-Funktionen von Data Catalog verfolgen die Herkunft und den Ursprung von Daten-Assets und stellen den Datenfluss visuell dar. Außerdem identifizieren und taggen Datenaufnahmeskripts die ursprüngliche Datenquelle in Data Catalog, wodurch die Rückverfolgbarkeit von Daten zu ihrem Ursprung verbessert wird.

Verwaltung des Datenzugriffs

Der Zugriff der Architektur auf Daten wird über einen unabhängigen Prozess gesteuert, der die Betriebssteuerung (z. B. das Ausführen von Dataflow-Jobs) von der Datenzugriffssteuerung trennt. Der Zugriff eines Nutzers auf einen Google Cloud Dienst wird durch eine Umwelt- oder Betriebsanforderung definiert und von einer Cloud-Engineering-Gruppe bereitgestellt und genehmigt. Der Zugriff eines Nutzers auf Google Cloud -Datenassets (z. B. eine BigQuery-Tabelle) ist ein Problem in Bezug auf Datenschutz, behördliche Auflagen oder Governance und unterliegt einer Zugriffsvereinbarung zwischen den erstellenden und nutzenden Parteien. Der Zugriff wird durch die folgenden Prozesse gesteuert. Das folgende Diagramm zeigt, wie der Datenzugriff durch die Interaktion verschiedener Softwarekomponenten bereitgestellt wird.

Wie im vorherigen Diagramm dargestellt, wird das Onboarding von Datenzugriffen durch die folgenden Prozesse abgewickelt:

• Cloud-Datenassets werden von Data Catalog erfasst und inventarisiert.
• Der Workflow-Manager ruft die Daten-Assets aus Data Catalog ab.
• Dateninhaber werden in Workflow Manager eingebunden.

So funktioniert die Datenzugriffsverwaltung:

1. Ein Datenempfänger stellt eine Anfrage für ein bestimmtes Asset.
2. Der Dateninhaber des Assets wird über die Anfrage benachrichtigt.
3. Der Dateninhaber genehmigt die Anfrage oder lehnt sie ab.
4. Wenn die Anfrage genehmigt wird, übergibt der Workflow-Manager die Gruppe, das Asset und das zugehörige Tag an den IAM-Mapper.
5. Der IAM-Mapper übersetzt die Workflow Manager-Tags in IAM-Berechtigungen und weist der angegebenen Gruppe IAM-Berechtigungen für das Daten-Asset zu.
6. Wenn ein Nutzer auf das Daten-Asset zugreifen möchte, wird der Zugriff auf das Google Cloud -Asset anhand der Berechtigungen der Gruppe ausgewertet.
7. Wenn dies zulässig ist, greift der Nutzer auf das Daten-Asset zu.

Netzwerk

Der Prozess zur Datensicherheit beginnt bei der Quellanwendung, die sich möglicherweise lokal oder in einer anderen Umgebung außerhalb desGoogle Cloud -Zielprojekts befindet. Bevor eine Netzwerkübertragung erfolgt, authentifiziert sich diese Anwendung mit der Identitätsförderung von Arbeitslasten sicher bei Google Cloud APIs. Mithilfe dieser Anmeldedaten interagiert sie mit Cloud KMS, um die erforderlichen Schlüssel abzurufen oder zu umschließen. Anschließend wird die Tink-Bibliothek verwendet, um die erste Verschlüsselung und De-Identifikation der vertraulichen Daten-Payload gemäß vordefinierten Vorlagen durchzuführen.

Nachdem die Daten-Payload geschützt wurde, muss sie sicher in das Google Cloud -Aufnahmeprojekt übertragen werden. Für lokale Anwendungen können Sie Cloud Interconnect oder möglicherweise Cloud VPN verwenden. Verwenden Sie in diesemGoogle Cloud -Netzwerk Private Service Connect, um die Daten an den Erfassungs-Endpunkt im VPC-Netzwerk des Zielprojekts weiterzuleiten. Mit Private Service Connect kann die Quellanwendung über private IP-Adressen eine Verbindung zu Google APIs herstellen. So wird sichergestellt, dass der Traffic nicht über das Internet geleitet wird.

Der gesamte Netzwerkpfad und die Zielaufnahmedienste (Cloud Storage, BigQuery und Pub/Sub) im Aufnahmeprojekt sind durch einen VPC Service Controls-Perimeter gesichert. Dieser Perimeter erzwingt eine Sicherheitsgrenze und sorgt dafür, dass die geschützten Daten aus der Quelle nur in die autorisiertenGoogle Cloud -Dienste innerhalb dieses bestimmten Projekts aufgenommen werden können.

Logging

In dieser Architektur werden die Cloud Logging-Funktionen verwendet, die vom Unternehmensgrundlagen-Blueprint bereitgestellt werden.

Pipelines

Die Data-Mesh-Architektur für Unternehmen verwendet eine Reihe von Pipelines, um die Infrastruktur, Orchestrierung, Datasets, Datenpipelines und Anwendungskomponenten bereitzustellen. In den Pipelines für die Ressourcenbereitstellung der Architektur wird Terraform als Infrastruktur-als-Code-(IaC-)Tool und Cloud Build als CI/CD-Dienst verwendet, um die Terraform-Konfigurationen in der Architekturumgebung bereitzustellen. Das folgende Diagramm zeigt die Beziehung zwischen den Pipelines.

Die Grundlagenpipeline und die Infrastrukturpipeline sind Teil des Blueprints für Unternehmensgrundlagen. In der folgenden Tabelle wird der Zweck der Pipelines und der Ressourcen beschrieben, die sie bereitstellen.

Pipeline	Bereitgestellt von	Ressourcen
Fundament-Pipeline	Bootstrap	Ordner und Unterordner der Datenplattform Häufige Projekte Dienstkonto für Infrastrukturpipeline Cloud Build-Trigger für die Infrastrukturpipeline Freigegebene VPC VPC Service Control-Perimeter
Infrastrukturpipeline	Fundament-Pipeline	Nutzerprojekte Service Catalog-Dienstkonto Der Cloud Build-Trigger für die Service Catalog-Pipeline Dienstkonto für Artifact-Pipeline Der Cloud Build-Trigger für die Artefakt-Pipeline
Service Catalog-Pipeline	Infrastrukturpipeline	Ressourcen, die im Service Catalog-Bucket bereitgestellt werden
Artefakt-Pipelines	Infrastrukturpipeline	In Artefakt-Pipelines werden die verschiedenen Container und anderen Komponenten der Codebasis erstellt, die vom Data Mesh verwendet werden.

Jede Pipeline hat eigene Repositories, aus denen Code und Konfigurationsdateien abgerufen werden. In jedem Repository gibt es eine Aufgabentrennung, bei der die Einreichung und Genehmigung von Bereitstellungen von Betriebscode in der Verantwortung verschiedener Gruppen liegt.

Interaktive Bereitstellung über Service Catalog

Interaktive Umgebungen sind die Entwicklungsumgebung innerhalb der Architektur und befinden sich im Entwicklungsordner. Die Hauptschnittstelle für die interaktive Umgebung ist der Service Catalog, in dem Entwickler vorkonfigurierte Vorlagen zum Instanziieren von Google-Diensten verwenden können. Diese vorkonfigurierten Vorlagen werden als Dienstvorlagen bezeichnet. Mit Dienstvorlagen können Sie Ihre Sicherheitsrichtlinien durchsetzen, z. B. die CMEK-Verschlüsselung vorschreiben. Außerdem wird verhindert, dass Ihre Nutzer direkten Zugriff auf Google-APIs haben.

Das folgende Diagramm zeigt die Komponenten der interaktiven Umgebung und wie Data Scientists Ressourcen bereitstellen.

So stellen Sie Ressourcen über den Service Catalog bereit:

1. Der MLOps-Entwickler legt eine Terraform-Ressourcenvorlage für Google Cloudin ein Git-Repository.
2. Der Git-Commit-Befehl löst eine Cloud Build-Pipeline aus.
3. Cloud Build kopiert die Vorlage und alle zugehörigen Konfigurationsdateien in Cloud Storage.
4. Der MLOps-Engineer richtet die Service Catalog-Lösungen und Service Catalog manuell ein. Der Engineer gibt den Service Catalog dann für ein Dienstprojekt in der interaktiven Umgebung frei.
5. Der Data Scientist wählt eine Ressource aus dem Service Catalog aus.
6. Service Catalog stellt die Vorlage in der interaktiven Umgebung bereit.
7. Die Ressource ruft alle erforderlichen Konfigurationsskripts ab.
8. Der Data Scientist interagiert mit den Ressourcen.

Artefakt-Pipelines

Beim Prozess zur Datenaufnahme werden Managed Airflow und Dataflow verwendet, um die Übertragung und Transformation von Daten innerhalb der Datendomäne zu orchestrieren. In der Artefaktpipeline werden alle erforderlichen Ressourcen für die Datenaufnahme erstellt und an den entsprechenden Speicherort verschoben, damit die Dienste darauf zugreifen können. In der Artefakt-Pipeline werden die Containerartefakte erstellt, die vom Orchestrator verwendet werden.

Sicherheitskontrollen

Die Enterprise Data Mesh-Architektur verwendet ein mehrschichtiges Defense-in-Depth-Sicherheitsmodell, das Standardfunktionen, Google Cloud Google CloudDienste und Sicherheitsfunktionen umfasst, die über den Enterprise Foundations-Blueprint konfiguriert werden. Das folgende Diagramm zeigt die verschiedenen Sicherheitsebenen für die Architektur.

In der folgenden Tabelle werden die Sicherheitskontrollen beschrieben, die mit den Ressourcen in den einzelnen Ebenen verknüpft sind.

Ebene	Ressource	Sicherheitskontrollen
CDMC-Framework	Google Cloud CDMC-Implementierung	Bietet ein Governance-Framework, mit dem Sie Ihre Daten-Assets schützen, verwalten und kontrollieren können. Weitere Informationen finden Sie im CDMC Key Controls Framework.
Bereitstellung	Infrastrukturpipeline	Bietet eine Reihe von Pipelines, mit denen Infrastruktur bereitgestellt, Container erstellt und Datenpipelines erstellt werden. Die Verwendung von Pipelines ermöglicht Prüfbarkeit, Rückverfolgbarkeit und Wiederholbarkeit.
	Artefakt-Pipeline	Stellt verschiedene Komponenten bereit, die nicht von der Infrastrukturpipeline bereitgestellt werden.
	Terraform-Vorlagen	Baut die Systeminfrastruktur aus.
	Open Policy Agent	So wird sichergestellt, dass die Plattform den ausgewählten Richtlinien entspricht.
Netzwerk	Private Service Connect	Bietet Schutz vor Daten-Exfiltration für die Architekturressourcen auf der API-Ebene und der IP-Ebene. Ermöglicht die Kommunikation mit Google Cloud APIs über private IP-Adressen, sodass Sie keinen Traffic gegenüber dem Internet exponieren.
	VPC-Netzwerk mit privaten IP-Adressen	Sie hilft, die Gefährdung durch Bedrohungen im Internet zu verringern.
	VPC Service Controls	Schützt sensible Ressourcen vor Daten-Exfiltration.
	Firewall	Schützt das VPC-Netzwerk vor unbefugtem Zugriff.
Zugriffsverwaltung	Access Context Manager	Steuert, wer auf welche Ressourcen zugreifen kann, und verhindert den nicht autorisierten Zugriff auf Ihre Ressourcen.
	Workload Identity-Föderation	Es sind keine externen Anmeldedaten mehr erforderlich, um Daten aus lokalen Umgebungen auf die Plattform zu übertragen.
	Data Catalog	Bietet einen Index der für Nutzer verfügbaren Assets.
	IAM	Ermöglicht präzisen Zugriff.
Verschlüsselung	Cloud KMS	Sie können Ihre Verschlüsselungsschlüssel und ‑geheimnisse verwalten und Ihre Daten durch Verschlüsselung inaktiver Daten und Verschlüsselung während der Übertragung schützen.
	Secret Manager	Bietet einen Secret-Speicher für Pipelines, die von IAM gesteuert werden.
	Verschlüsselung inaktiver Daten	Standardmäßig verschlüsselt Google Cloud ruhende Daten.
	Verschlüsselung während der Übertragung	Standardmäßig verschlüsselt Google Cloud Daten während der Übertragung.
Erkennung	Security Command Center	Unterstützt Sie bei der Erkennung von Fehlkonfigurationen und schädlichen Aktivitäten in Ihrer Google Cloud-Organisation.
	Kontinuierliche Architektur	Prüft Ihre Google Cloud -Organisation kontinuierlich anhand einer Reihe von OPA-Richtlinien (Open Policy Agent), die Sie definiert haben.
	IAM Recommender	Analysiert Nutzerberechtigungen und gibt Vorschläge zur Reduzierung von Berechtigungen, um das Prinzip der geringsten Berechtigung durchzusetzen.
	Firewall Insights	Analysiert Firewallregeln, identifiziert übermäßig freizügige Firewallregeln und schlägt restriktivere Firewalls vor, um Ihre allgemeine Sicherheitslage zu verbessern.
	Cloud Logging	Bietet Einblick in die Systemaktivität und trägt zur Erkennung von Anomalien und schädlichen Aktivitäten bei.
	Cloud Monitoring	Erfasst wichtige Signale und Ereignisse, die dabei helfen können, verdächtige Aktivitäten zu erkennen.
Prävention	Unternehmensrichtlinien	Damit können Sie Aktionen in Ihrer Google Cloud-Organisation steuern und einschränken.

Workflows

In den folgenden Abschnitten werden der Workflow für Datenproduzenten und der Workflow für Datennutzer beschrieben. So werden angemessene Zugriffssteuerungen basierend auf der Datensensibilität und den Nutzerrollen sichergestellt.

Workflow für Datenproduzenten

Das folgende Diagramm zeigt, wie Daten beim Übertragen zu BigQuery geschützt werden.

Der Workflow für die Datenübertragung sieht so aus:

1. Eine Anwendung, die in die Identitätsföderation von Arbeitslasten eingebunden ist, verwendet Cloud KMS, um einen verpackten Verschlüsselungsschlüssel zu entschlüsseln.
2. Die Anwendung verwendet die Tink-Bibliothek, um die Daten mithilfe einer Vorlage zu anonymisieren oder zu verschlüsseln.
3. Die Anwendung überträgt Daten in das Aufnahmeprojekt in Google Cloud.
4. Die Daten werden in Cloud Storage, BigQuery oder Pub/Sub bereitgestellt.
5. Im Aufnahmeprojekt werden die Daten mithilfe einer Vorlage entschlüsselt oder re-identifiziert.
6. Die entschlüsselten Daten werden anhand einer anderen Vorlage zur De-Identifizierung verschlüsselt oder maskiert und dann in das nicht vertrauliche Projekt eingefügt. Tags werden von der Tagging-Engine nach Bedarf angewendet.
7. Daten aus dem nicht vertraulichen Projekt werden in das vertrauliche Projekt übertragen und re-identifiziert.

Der folgende Datenzugriff ist zulässig:

• Nutzer, die Zugriff auf das vertrauliche Projekt haben, können auf alle unverschlüsselten Rohdaten zugreifen.
• Nutzer mit Zugriff auf das nicht vertrauliche Projekt können auf maskierte, tokenisierte oder verschlüsselte Daten zugreifen, je nach den mit den Daten verknüpften Tags und ihren Berechtigungen.

Workflow des Datenkonsumenten

In den folgenden Schritten wird beschrieben, wie ein Nutzer auf Daten zugreifen kann, die in BigQuery gespeichert sind.

1. Der Datenkonsument sucht mit Data Catalog nach Daten-Assets.
2. Nachdem der Nutzer die gewünschten Assets gefunden hat, fordert er Zugriff auf die Datenassets an.
3. Der Dateninhaber entscheidet, ob er Zugriff auf die Assets gewährt.
4. Wenn der Kunde Zugriff erhält, kann er ein Notebook und den Lösungskatalog verwenden, um eine Umgebung zu erstellen, in der er die Datenassets analysieren und transformieren kann.

Zusammenfassung

Das GitHub-Repository enthält eine detaillierte Anleitung zum Bereitstellen des Data Mesh inGoogle Cloud , nachdem Sie die Unternehmensgrundlage bereitgestellt haben. Für die Bereitstellung der Architektur müssen Sie Ihre vorhandenen Infrastruktur-Repositories ändern und neue datenmesh-spezifische Komponenten bereitstellen.

Führen Sie Folgendes aus:

1. Erfüllen Sie alle Voraussetzungen, einschließlich der folgenden:
   1. Installieren Sie die Google Cloud CLI, Terraform, Tink, Java und Go.
   2. Stellen Sie den Blueprint für Unternehmensgrundlagen (Version 4.1) bereit.
   3. Verwalten Sie die folgenden lokalen Repositories:
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. Ändern Sie den vorhandenen Foundation-Blueprint und stellen Sie dann die Data Mesh-Anwendungen bereit. Führen Sie für jedes Element die folgenden Schritte aus:
   1. Rufen Sie in Ihrem Ziel-Repository den Branch Plan auf.
   2. Wenn Sie Data Mesh-Komponenten hinzufügen möchten, kopieren Sie die entsprechenden Dateien und Verzeichnisse aus gcp-data-mesh-foundations in das entsprechende Fundamentverzeichnis. Überschreiben Sie Dateien bei Bedarf.
   3. Aktualisieren Sie die Variablen, Rollen und Einstellungen für das Data Mesh in den Terraform-Dateien (z. B. *.tfvars und *.tf). Legen Sie die GitHub-Tokens als Umgebungsvariablen fest.
   4. Führen Sie die Terraform-Vorgänge „initialize“, „plan“ und „apply“ für jedes Repository aus.
   5. Führen Sie einen Commit für Ihre Änderungen durch, übertragen Sie den Code per Push in Ihr Remote-Repository, erstellen Sie Pull-Anfragen und führen Sie die Änderungen in Ihren Entwicklungs-, Nichtproduktions- und Produktionsumgebungen zusammen.

Nächste Schritte

• Architektur und Funktionen in einem Data Mesh
• Daten aus Google Cloud in ein gesichertes BigQuery-Data Warehouse importieren.
• CDMC Key Controls Framework in einem BigQuery-Data-Warehouse implementieren
• Blueprint für Unternehmensgrundlagen