Best Practices für mehrmandantenfähige Arbeitslasten in BigQuery

Dieses Dokument enthält Verfahren und Best Practices für gängige Muster, die auf mehrmandantenfähigen Datenplattformen und Unternehmens-Data-Marts verwendet werden.

Kommerzielle Unternehmen, SaaS-Anbieter (Software as a Service) und Behörden müssen häufig sowohl interne als auch Drittanbieterdaten über geografische und administrative Grenzen hinweg hosten. BigQuery ist ein leistungsfähiges Tool, das die Anforderungen von mehrmandantenfähigen Plattformen für Exabyte von Daten und Hunderttausende von Datennutzern über verschiedene Geschäftseinheiten hinweg konsistent erfüllt. Dieses Dokument richtet sich an Organisationen, die mehrmandantenfähige Plattformen auf BigQuery bereitstellen und die verfügbaren Zugriffssteuerungen und Funktionen zur Leistungsverwaltung verstehen möchten.

Ersteller von mehrmandantenfähigen Plattformen müssen häufig Folgendes berücksichtigen:

• Datenisolation: Implementieren Sie strenge Kontrollen, um Datenverluste über Mandanten hinweg zu verhindern.
• Konsistente Leistung: Konfigurieren und verteilen Sie BigQuery-Reservierungen, um eine konsistente Leistung für alle Mandanten zu gewährleisten.
• Ressourcenverwaltung: Planen Sie die Auswirkungen von Kontingenten und Limits.
• Geografische Verteilung: Suchen Sie Daten an festgelegten und erforderlichen geografischen Standorten. Informationen zu Compliance-Problemen finden Sie in den Compliance-Angeboten von Google Cloud.
• Auditing und Sicherheit: Schützen Sie Mandantendaten vor unangemessenen Zugriffen und Exfiltration.
• Kostenverwaltung: Achten Sie darauf, dass die BigQuery-Hosting-Kosten für jeden Mandanten in konsistent sind.
• Operative Komplexität: Minimieren Sie die Systemvariabilität, die zum Hosten neuer Mandanten erforderlich ist.

SaaS-Anbieter mit gemeinsam genutzter Mandanteninfrastruktur

SaaS-Anbieter, die Daten von Drittanbietern hosten, müssen deren Zuverlässigkeit und Isolation in ihrem gesamten Kundenpool gewährleisten. Es können Zehntausende von Kunden sein und Kundendaten können über eine gemeinsam genutzte Dienstinfrastruktur abgerufen werden. Einige SaaS-Anbieter verwalten auch einen bereinigten, zentralen Datenspeicher, um Analysen für alle ihre Mandanten durchzuführen.

Ein Dataset-pro-Mandant-Design hilft, die folgenden Probleme zu minimieren, die eine Organisation bei einer Skalierung auf Tausende von Mandanten haben kann:

• Administrative Komplexität: Gesamtzahl der neuen Projekte und Cloud-Ressourcen pro Kunde
• End-to-End-Latenz: Gibt an, wie aktuell der Datenspeicher für die Mandanten und kundenübergreifenden Analyselösungen ist
• Leistungserwartungen: Gewährleisten, dass die Leistung von Mandanten innerhalb akzeptabler Grenzen bleibt

Datasets für jeden Mandanten konfigurieren

In einem Projekt, in dem Kundendaten gespeichert werden, werden die Daten jedes Kunden durch BigQuery-Datasets getrennt. In der Hostorganisation verwenden Sie ein zweites Projekt, um Analysen und maschinelles Lernen für kombinierte Kundendaten bereitzustellen. Sie können dann das Datenverarbeitungsmodul Dataflow konfigurieren, um eingehende Daten sowohl in die internen als auch in die mandantenspezifischen Tabellen zu schreiben. Die Dataflow-Konfiguration verwendet vollständig geschriebene Tabellen anstelle von autorisierten Ansichten. Die Verwendung von vollständig geschriebenen Tabellen ermöglicht eine einheitliche Durchführung der geografischen Verteilung. So vermeiden Sie, dass die Limits für autorisierte Ansichten erreicht werden, wenn die Anzahl der Mandanten skaliert wird.

Die Trennung von Speicherung und Computing in BigQuery ermöglicht Ihnen, weniger Projekte im Vergleich zu clusterbasierten Warehouses zu konfigurieren, um Probleme wie Dienststufen und Datenisolation zu bewältigen. Wenn Sie Mandanten nicht mit zusätzlichen dedizierten Cloudressourcen konfigurieren müssen, empfehlen wir die Verwendung der Standardkonfiguration eines dedizierten Datasets für jeden Mandanten. Das folgende Diagramm zeigt ein Beispiel für eine Projektkonfiguration, die auf diesem empfohlenen Design basiert:

Abbildung 1. Eine konstante Anzahl von Projekten verarbeitet Daten und verwaltet Verarbeitungsanforderungen, wenn die Anzahl der Mandanten zunimmt.

Die Projektkonfiguration in Abbildung 1 umfasst die folgenden Projekte:

• Datenpipeline-Projekt: Die zentralen Infrastrukturkomponenten, die Mandantendaten empfangen, verarbeiten und verteilen, werden alle in einem einzigen Projekt verpackt.
• Kombiniertes Mandantendaten-Projekt: Das Kerndatenprojekt, das ein Dataset pro Kunde verwaltet. Es wird davon ausgegangen, dass Mandantendaten über Computing-Stufenprojekte zugänglich sind.
• Interne Entwicklungsprojekte: Projekte für die selbstverwalteten Ressourcen, mit denen Analyseteams Mandantendaten auswerten und neue Features erstellen.
• Endnutzer-Anwendungsprojekte: Projekte mit Ressourcen, die für die Interaktion mit Endnutzern entwickelt wurden. Wir empfehlen, mandantenfähige Dienstkonten für den Zugriff auf Mandanten-Datasets und eine robuste und sichere Build-Pipeline zum Bereitstellen von Anwendungen zu verwenden.
• Reservierungs-Computing-Stufenprojekte: Projekte, in denen die Mandantenabfrageaktivität BigQuery-Reservierungen zugeordnet wird.

Reservierungen teilen

Reservierungen bei diesem Ansatz basieren auf dem Algorithmus für faire Planung, der in BigQuery-Reservierungen integriert ist. Jede Reservierung auf der Computing-Stufe wird einem einzelnen Projekt zugewiesen. Mandantenabfragen verwenden Slots der fairen Planung, die für jedes Computing-Stufenprojekt verfügbar sind, und nicht genutzte Slots aus einer beliebigen Stufe werden automatisch in einer anderen Stufe wiederverwendet. Wenn ein Mandant spezielle Timing-Anforderungen hat, können Sie ein Projekt-Reservierungspaar verwenden, das eine genaue Anzahl von Slots bereitstellt.

VPC Service Controls-Perimeter konfigurieren

In dieser Konfiguration empfehlen wir VPC Service Controls-Perimeter, um eine versehentliche Offenlegung von Mandanten-Datasets außerhalb Ihrer Google Cloud-Organisation und eine nicht autorisierte Datenverknüpfung innerhalb der Organisation zu verhindern.

Perimeter

In dieser Konfiguration empfehlen wir, die folgenden Dienstperimeter zu erstellen:

• Datenpipeline: Ein Perimeter um die Datenpipeline-Projekte sollte alle Dienste erzwingen, die keine Mandantendaten benötigen.
• Mandantendaten: Ein Perimeter um das Mandanten-Dataset-Projekt und um die BigQuery-Computing-Projekte des Mandanten. Alle Dienste erzwingen, um den Zugriff von außerhalb der Organisation zu verhindern.
• Interne Anwendungen: Erzwingen Sie alle Dienste und verwenden Sie Zugriffsebenen, um Abteilungsteams den Ressourcenzugriff zu gewähren.
• Externe Anwendungen: Ein Perimeter um Ihre SaaS-Anwendungen. Sie können alle Dienste erzwingen, die für die Funktion der Anwendungen nicht erforderlich sind.

Perimeter-Bridges

In dieser Konfiguration empfehlen wir, die folgenden Perimeter-Bridges zu erstellen:

• Datenpipeline und Mandantendaten: Ermöglicht der Pipeline das Schreiben von Daten in Mandanten-Datasets.
• Datenpipeline und interne Anwendungen: Ermöglicht der Pipeline, Daten in das kundenübergreifende Dataset zu schreiben.
• Externe Anwendungen und Mandantendaten: Ermöglicht externen Anwendungen die Abfrage von Mandantendaten.
• Externe Anwendungen und interne Anwendungen: Ermöglicht es von außen erreichbaren Anwendungen, Daten mit Modellen zu verarbeiten, die von den internen Anwendungen entwickelt und bereitgestellt werden.

SaaS-Anbieter mit dedizierter Mandanteninfrastruktur

In komplexeren Szenarien bieten SaaS-Anbieter möglicherweise dedizierte Computing-Infrastruktur für jeden Mandanten an. In diesem Szenario ist die dedizierte Infrastruktur für die Bereitstellung von Anfragen für Mandantendaten in BigQuery zuständig.

Beim Design einer dedizierten Mandanteninfrastruktur werden die folgenden Probleme im Zusammenhang mit der Bereitstellung der Infrastruktur für jeden Mandanten zusammen mit BigQuery behandelt:

• Verantwortung für Abrechnung: Erfassen der Infrastrukturkosten, die mit jedem aufgenommenen Mandanten verbunden sind.
• End-to-End-Latenz: Dieser Wert gibt an, wie aktuell der Datenspeicher für die Mandanten und kundenübergreifende Analyselösungen ist.
• Leistungserwartungen: Gewährleisten, dass die Leistung von Mandanten innerhalb akzeptabler Grenzen bleibt.

Datasets mit dedizierten Ressourcen am selben Ort platzieren

Wenn Sie eine dedizierte Mandanteninfrastruktur bereitstellen, empfehlen wir Ihnen, einen übergeordneten Ordner für die mandantenspezifischen Projekte zu erstellen. Platzieren Sie dann die BigQuery-Datasets des Mandanten gemeinsam in Projekten mit den dedizierten Ressourcen, die im Namen des Mandanten auf diese Daten zugreifen. Dataflow-Pipelines fügen Daten direkt in die Mandanten-Datasets ein, um die End-to-End-Latenz von Mandantendaten zu minimieren.

Dieses Design übernimmt die vorgelagerte Datenverarbeitung und -verteilung, ähnlich wie beim vorhergehenden Design einer gemeinsam genutzten Infrastruktur. Mandantendaten und Anwendungen, die auf Mandantendaten zugreifen, sind jedoch unter mandantenspezifischen Projekten organisiert (und optional unter für Mandanten vorgesehenen Ordnern), um die Abrechnung und Ressourcenverwaltung zu vereinfachen. Das folgende Diagramm zeigt ein Beispiel für eine Projektkonfiguration, die auf diesem empfohlenen Design basiert:

Abbildung 2. Ein Datenpipeline-Projekt verarbeitet Daten für einen einzelnen Mandanten aus mehreren anderen Projekten.

Die Projektkonfiguration in Abbildung 2 umfasst die folgenden Projekte:

• Datenpipeline-Projekt: Die zentralen Infrastrukturkomponenten, die Mandantendaten empfangen, verarbeiten und verteilen, sind alle in einem einzigen Projekt verpackt.
• Dedizierte Mandantenprojekte: Projekte mit allen Cloud-Ressourcen, die einem einzelnen Mandanten zugeordnet sind, einschließlich BigQuery-Datasets. Wir empfehlen die Verwendung von Identity and Access Management (IAM), um den Umfang der Konten und Dienstkonten, die auf die Kunden-Datasets zugreifen können, deutlich einzuschränken.
• Interne Analyseprojekte: Projekte, die die selbstverwalteten Ressourcen darstellen, die von Analyseteams verwendet werden, um Mandantendaten zu bewerten und neue Features zu erstellen.
• Externes Netzwerkprojekt: Projekt, das Mandantenanfragen verarbeitet und an die zugehörigen Back-Ends weiterleitet.

Reservierungen teilen

Reservierungen bei diesem Ansatz basieren auf dem Algorithmus für faire Planung, der in BigQuery-Reservierungen integriert ist. In dieser Konfiguration werden jedem Mandantenprojekt, das diese Stufe verwendet, Computing-Stufenreservierungen zugewiesen. Wenn ein Mandanten bestimmte Timing-Anforderungen hat, können Sie eine dedizierte Reservierung erstellen, um einem Mandantenprojekt eine genaue Anzahl an Slots bereitzustellen.

IAM-Steuerelemente verwenden und Schlüsselerstellung deaktivieren

VPC Service Controls-Perimeter sind für dieses Szenario möglicherweise nicht geeignet. Projektbezogene Limits verhindern, dass eine Organisation Perimetergrenzen bei Projekten verwendet, die mit den Mandantenprojekten interagieren. Stattdessen sollten Sie strikte IAM-Steuerelemente verwenden und die Schlüsselerstellung deaktivieren, um unbefugten externen Zugriff zu verhindern.

Data-Mart mit zentraler Autorität

Data-Marts sind ein häufiges Designkonzept, bei dem Kernanalysedaten in einem zentralen Repository gespeichert und Teilmengen von Geschäftsbereichen gemeinsam genutzt werden. Data-Marts haben häufig Dutzende oder Hunderte Mandanten, die als Geschäftsbereiche betrachtet werden.

Ein Data-Mart-Design in BigQuery erfüllt folgende Anforderungen:

• Sichere Datenzusammenarbeit: Die Freigabe von Daten mit technischen Kontrollen, um den unangemessenen Zugriff über Teams hinweg zu minimieren.
• Zentrale Data Governance: Kerndatenassets für kritische Geschäftsberichte werden standardisiert und validiert.
• Kostenzuordnung für Geschäftseinheiten: Erfassen und passen Sie die Berechnung nach Geschäftseinheiten an.

Zentral verwaltetes Repository verwenden

Bei diesem Design werden Kerndaten in einem zentral verwalteten Repository erfasst. Autorisierte Ansichten, autorisierte benutzerdefinierte Funktionen (User-Defined Functions, UDFs) und Spaltenrichtlinien werden häufig verwendet, um Daten mit Geschäftsbereichen zu teilen und eine versehentliche Verteilung vertraulicher Daten zu vermeiden.

Teams in Mandantenprojekten können auf der Grundlage ihrer Kontoberechtigungen auf zentralisierte Datasets zugreifen. Teams verwenden Slots, die ihren eigenen Projekten zugewiesen sind, um Berichte und abgeleitete Datasets zu erstellen. Das Kerndatenteam verwendet autorisierte Ansichten, um die vollständige Kontrolle über die Zugriffssteuerung auf die Assets des Data-Marts zu behalten. Bei dieser Konfiguration sollten Sie nicht mehrere Ebenen von Ansichten zusätzlich zu den Objekten erstellen, die im Kerndatenprojekt dargestellt sind. Das folgende Diagramm zeigt ein Beispiel für eine Projektkonfiguration, die auf diesem empfohlenen Design basiert:

Abbildung 3. Ein Kerndatenprojekt verwaltet einen zentralen Data-Mart, auf den von der Organisation aus zugegriffen werden kann.

Die Projektkonfiguration in Abbildung 3 umfasst die folgenden Projekte:

• Kerndatenprojekt: Der Governance-Perimeter zur Verwaltung des Zugriffs auf die Kerndaten und die Data-Mart-Ansichten. Sie verwalten autorisierte Ansichten in Datasets innerhalb dieses Projekts und gewähren Ihren Analyseteams anhand der Gruppenmitgliedschaft autorisierte Ansichten.
• ETL-Infrastruktur (Extract, Transform, Load): Infrastruktur zum Verarbeiten von vorgelagerten Datenquellen in die Kerndaten. Je nach Anforderungen der administrativen Trennung können Sie die ETL-Infrastruktur als eigenes Projekt oder als Teil des Kerndatenprojekts bereitstellen.
• Analyseteamprojekte: Nutzer dieses Data-Marts verwenden diese Projekte und nutzen ihren eigenen bereitgestellten Infrastrukturzugriff, um Daten innerhalb des Data-Marts zu verarbeiten. Es wird erwartet, dass die Analyseteamprojekte abgeleitete Datasets für die lokale Verwendung erstellen können.

Zweistufiges Reservierungsdesign verwenden

Bei der Arbeit mit Data-Marts empfehlen wir ein zweistufiges Design. In einem zweistufigen Design weisen Sie der Organisationsressource eine Reservierung mit einer kleinen Anzahl von Slots zu, die die allgemeine Nutzung abdecken. Bei Teams mit größerem Bedarf können Sie Reservierungen auf Projekt- oder Ordnerebene zuweisen.

VPC Service Controls-Perimeter konfigurieren

In dieser Konfiguration empfehlen wir VPC Service Controls-Perimeter, um eine versehentliche Offenlegung von BigQuery-Datasets außerhalb Ihrer Google Cloud-Organisation zu verhindern.

Perimeter

In dieser Konfiguration empfehlen wir, die folgenden Dienstperimeter zu erstellen:

• Kerndaten: Ein Perimeter zum Schutz des Data Warehouse und der Data-Mart-Datasets.
• Datenpipelines: Ein Perimeter für das ETL-Infrastrukturprojekt. Wenn die Datenpipelines außerhalb Ihrer Google Cloud-Organisation Anfragen senden müssen, empfehlen wir Ihnen, diesen Perimeter vom Kerndatenperimeter zu trennen.
• Analysen: Perimeter zum Erstellen und Bereitstellen von Analyseassets innerhalb Ihrer Organisation. Der Perimeter hat vermutlich eine weniger strenge Zugriffsrichtlinie als der Kerndatenperimeter, mit dem er sich in einer Bridge befindet.

Perimeter-Bridges

In dieser Konfiguration empfehlen wir, die folgenden Perimeter-Bridges zu erstellen:

• Datenpipelines und Kerndaten: Datenpipelines können in das Kerndatenprojekt schreiben.
• Kerndaten und Analysen: Nutzern in den Analyseprojekten gestatten, die autorisierten Ansichten abzufragen.

Datasets für multiregionale Konfigurationen kopieren

Da BigQuery keine regionenübergreifenden Abfragen zulässt, können Sie die Daten nicht mit autorisierten Ansichten segmentieren, wenn Data-Marts in mehreren Regionen vorhanden sein müssen. Stattdessen können Sie mit BigQuery Data Transfer Service relevante Datasets in eine andere Region kopieren. In diesem Szenario erstellen Sie im Datenkatalog Spaltenrichtlinien für jede weitere Region, in der sich die Daten befinden. Das folgende Diagramm zeigt eine multiregionale Konfiguration:

Abbildung 4. Eine multiregionale Konfiguration verwendet BigQuery Data Transfer Service, um Datasets regionenübergreifend zu kopieren.

Die Projektkonfiguration in Abbildung 4 enthält die folgenden Projekte.

• Kerndatenprojekt: Der Governance-Perimeter zur Verwaltung des Zugriffs auf die Kerndaten und die Data-Mart-Ansichten. Daten werden kopiert und in regionalen Datasets gespeichert, die für Teams auf der ganzen Welt bereitgestellt werden können.
• ETL-Infrastruktur: Infrastruktur zur Verarbeitung von vorgelagerten Datenquellen in die Kerndaten. Je nach Anforderungen der administrativen Trennung können Sie die ETL-Infrastruktur als eigenes Projekt oder als Teil des Kerndatenprojekts bereitstellen.
• Analyseteamprojekte: Nutzer dieses Data-Marts verwenden diese Projekte und nutzen ihre eigene bereitgestellte Infrastruktur, um Daten in regionalen Datasets des Data-Marts zu verarbeiten. Es wird erwartet, dass die Analyseteamprojekte abgeleitete Datasets für die lokale Verwendung erstellen können.

BigQuery Data Transfer Service ist eine zusätzliche geplante Komponente mit einigen Einschränkungen. Der integrierte Dienstplaner ist auf eine Mindestintervallzeit von 15 Minuten beschränkt und muss alle Tabellen aus dem Quell-Dataset kopieren. Es gibt keine Möglichkeit, zusätzliche Skripts einzubetten, um regionenspezifische Teilmengen von Daten in den BigQuery Data Transfer Service-Planer zu integrieren.

Wenn Ihre Organisation mehr Flexibilität benötigt, sind die folgenden Optionen verfügbar:

• Cloud Composer-Jobs: Sie können Cloud Composer-Jobs so planen, dass ETL-Jobs ausgeführt werden, die regionale Teilmengen erstellen, bevor BigQuery Data Transfer Service über seine Client API ausgelöst wird. Wenn Ihre Organisation zusätzliche Latenz unterstützt, empfehlen wir diese Option.
• ETL-Infrastruktur: Die ETL-Infrastruktur (z. B. Dataflow) kann regionale Teilmengen doppelt in Zielregionen schreiben. Wenn Ihre Organisation eine minimale Datenlatenz zwischen Regionen erfordert, empfehlen wir diese Option.

Data-Marts mit dezentralisierter Autorität

Verwenden Sie die dezentralisierte Autorität, wenn Sie eine administrative Trennung nach Systemeigentümer, Geschäftsbereichen oder geografischen Aspekten benötigen.

Ein dezentraler Data-Mart hat im Vergleich zu einem standardmäßigen Data-Mart die folgenden Aspekte:

• Sichere Datenzusammenarbeit: Die Freigabe von Daten mit technischen Kontrollen, um den unangemessenen Zugriff über Teams hinweg zu minimieren.
• Datensichtbarkeit: Teams müssen Datasets finden und Zugriff darauf anfordern können.
• Datenherkunft: Ohne zentrales Auswahlteam müssen Teams in der Lage sein, den Ursprung von Daten in ihre Analyseprodukte zu vertrauen.

Kerndatenverwaltung delegieren

Dieses Design unterscheidet sich vom konventionellen Data-Mart-Ansatz, da die dezentralisierte Autorität die Entscheidungen zur Kerndatenverwaltung an Teilgruppen der Organisation delegiert. Wenn Sie eine dezentralisierte Autorität verwenden, behalten Sie die zentrale Kontrolle über die Sicherheit und die BigQuery-Kapazität mithilfe von Cloud Key Management Service (Cloud KMS), Spaltenrichtlinien, VPC Service Controls und Reservierungen. Auf diese Weise vermeiden Sie die Multiplikation von Daten, die für selbstverwaltete Warehouses üblich ist. Das folgende Diagramm zeigt eine Architektur mit dezentralisierter Autorität:

Abbildung 5. Ein zentrales Governance-Projekt trägt dazu bei, für konsistente Sicherheit zu sorgen, während einzelne Gruppen ihre Datenvorgänge verwalten.

Die Projektkonfiguration in Abbildung 5 enthält die folgenden Projekte:

• Zentrales Governance-Projekt: Das Projekt, das für die organisationsübergreifende Verwaltung zuständig ist. In diesem Projekt erstellen Sie Sicherheitsressourcen wie Cloud KMS-Schlüsselbunde und Spaltenrichtlinien für Datenkataloge. Dieses Projekt fungiert als BigQuery-Reservierungsverwaltungsprojekt und ermöglicht die organisationsweite Freigabe von Slots.
• Datenprojekte von Organisationseinheiten: Die Inhaber von selbstverwalteten Data-Marts innerhalb der umfassenderen Organisation. Das zentrale Governance-Projekt verwaltet einen eingeschränkten Bereich für die Datenprojekte der Organisationseinheiten.
• Analyseteamprojekte: Die Projekte, die von Nutzern der Data-Marts verwendet werden. Diese Projekte nutzen ihre eigene bereitgestellte Infrastruktur und Slots, um auf Daten im Data-Mart zuzugreifen und sie zu verarbeiten.

Zweistufiges Reservierungsdesign verwenden

Wir empfehlen, dass Ihre dezentralisierten Data-Marts das gleiche zweistufige Design wie Standard-Data-Marts verwenden. In dieser Konfiguration weisen Sie der Organisationsressource eine Reservierung zu, die eine kleine Anzahl von Slots umfasst, um die allgemeine Nutzung abzudecken. Bei Teams mit größerem Bedarf können Sie Reservierungen auf Projekt- oder Ordnerebene zuweisen.

Datenkatalog verwenden

Ein Datenkatalog bietet organisationsweite Erkennung, Metadaten-Tagging und Konfiguration von Spaltenrichtlinien. Die Erkennung von Dataplex erstellt automatisch Metadateneinträge für alle neuen BigQuery-Tabellen in Ihrer Organisation. Die Funktionen von Dataplex helfen außerdem Data-Governance-Administratoren, neue Daten-Assets schnell zu identifizieren und entsprechende Kontrollen anzuwenden.

VPC Service Controls-Perimeter konfigurieren

In dieser Konfiguration empfehlen wir VPC Service Controls-Perimeter, um eine versehentliche Offenlegung von BigQuery-Datasets außerhalb Ihrer Google Cloud-Organisation zu verhindern.

Perimeter

In dieser Konfiguration empfehlen wir, die folgenden Dienstperimeter zu erstellen:

• Kerndaten: Ein Perimeter zum Schutz des Data Warehouse und der Data-Mart-Datasets. Dieser Perimeter sollte alle Projekte von Organisationseinheiten und das Data-Governance-Project enthalten.
• Analyse: Perimeter zum Erstellen und Bereitstellen von Analyseassets innerhalb der Organisation. Der Perimeter hat vermutlich eine weniger strenge Zugriffsrichtlinie als der Kerndatenperimeter, mit dem er sich in einer Bridge befindet.

Perimeter-Bridges

In dieser Konfiguration empfehlen wir, die folgenden Perimeter-Bridges zu erstellen:

• Kerndaten und Analysen: Nutzern in den Analyseprojekten gestatten, die autorisierten Ansichten abzufragen.

Datenfreigabe für mehrere Organisationen

Die Freigabe für mehrere Organisationen ist ein besonderer Designaspekt für das Data-Mart-Design. Dieses Design der Datenfreigabe ist für Unternehmen gedacht, die ihre Datasets sicher mit einer anderen Entität teilen möchten, die über eine eigene Google-Organisation verfügt.

Die Datenfreigabe für mehrere Organisationen berücksichtigt die folgenden Probleme für den Freigebenden:

• Vertraulichkeit bei der Freigabe: Nur die beabsichtigte Partei kann auf freigegebene Daten zugreifen.
• Schutz vor unangemessenem Zugriff: Nur Ressourcen, auf die zugegriffen werden soll, sind extern zugänglich.
• Computing-Trennung: Externen Parteien werden Abfragen in Rechnung gestellt, die von ihnen gestartet werden.

Hinweis: In einigen Fällen können Abfragen von außerhalb der Organisation unerwartet fehlschlagen. Mit Cloud Customer Care können Sie eine Konfigurationsänderung einleiten, um das Problem zu beheben.

Interne Projekte vor Projekten mit freigegebenen Daten schützen

Beim Design für die organisationsübergreifende Datenfreigabe geht es hauptsächlich darum, die internen Projekte der Organisation vor Aktivitäten in gemeinsam genutzten Datenprojekten zu schützen. Das Projekt für freigegebene Datasets fungiert als Zwischenspeicher, um den Zugriff auf vertrauliche interne Datenverarbeitung zu verhindern, und bietet die Möglichkeit, Daten extern freizugeben.

Abfragen, die von einem externen Projekt initiiert werden, verwenden die Rechenressourcen des aufrufenden Projekts. Wenn alle abgefragten Datasets dieselbe Google Cloud-Region haben, können diese Abfragen Daten organisationsübergreifend verknüpfen. Das folgende Diagramm zeigt, wie Datasets in einer Projektkonfiguration für mehrere Organisationen freigegeben werden:

Abbildung 6. Eine externe Organisation fragt Daten aus mehreren Datasets in freigegebenen Projekten ab.

Die Projektkonfiguration in Abbildung 6 umfasst die folgenden Projekte:

• Internes Projekt der Organisation: Das Projekt, das vertrauliche interne Daten enthält. Das interne Projekt kann Daten extern freigeben, indem bereinigte Daten in die Datasets des freigegebenen Datenprojekts kopiert werden. Das interne Projekt sollte das Dienstkonto besitzen, das für die Aktualisierung der freigegebenen Daten verantwortlich ist.
• Freigegebenes Datenprojekt: Das Projekt mit den bereinigten Informationen, die aus dem internen Projekt kopiert werden. Verwenden Sie Gruppen für externe Nutzer, um den Zugriff durch externe Dritte zu verwalten. In diesem Szenario verwalten Sie die Gruppenmitgliedschaft als Administratorfunktion und erteilen externen Konten die Berechtigung "Betrachter", damit sie über diese Gruppen auf das Dataset zugreifen können.

VPC Service Controls-Perimeter konfigurieren

In dieser Konfiguration empfehlen wir VPC Service Controls-Perimeter, um Daten extern freizugeben und zu verhindern, dass BigQuery-Datasets unbeabsichtigt außerhalb Ihrer internen Projekte aufgerufen werden können.

Perimeter

In dieser Konfiguration empfehlen wir, die folgenden Dienstperimeter zu erstellen:

• Interne Daten: Ein Perimeter zum Schutz von Kerndatenassets. VPC Service Controls erzwingt den Zugriff auf BigQuery.
• Extern freigegebene Daten: Ein Perimeter zum Hosten von Datasets, die für externe Organisationen freigegeben werden können. Dieser Perimeter deaktiviert die Erzwingung des Zugriffs auf BigQuery.

Perimeter-Bridges

In dieser Konfiguration empfehlen wir, die folgende Perimeter-Bridge zu erstellen:

• Intern bis zu externen Daten: Eine Perimeter-Bridge ermöglicht geschützteren internen Datenprojekten Daten an externe Datenfreigabeprojekte auszugeben.

Zusätzliche Überlegungen bei Mehrmandantensystemen

In diesem Abschnitt werden einige Sonderfälle genauer behandelt, die Sie zusätzlich zu den vorherigen Best Practices berücksichtigen können.

Google Cloud-Ressourcenlimits und -kontingente

• Dienstkonten sind auf ein weiches Kontingent von 100 Dienstkonten pro Projekt beschränkt. Sie können Kontingente über die Google Cloud Console für Projekte mit Mandantendienstkonten anfordern.
• Die BigQuery-Gleichzeitigkeit hat eine Standard-Gleichzeitigkeit von 100 Abfragen für jedes Projekt, das Abfragen ausführt (Projekte, die Datasets enthalten, haben keine solchen Limits). Kontaktieren Sie Ihren Vertriebsmitarbeiter, um dieses weiche Kontingent zu erhöhen.
• Für VPC Service Controls gilt ein organisationsweites Limit von 10.000 Projekten innerhalb von Dienstperimetern. Wenn Ihre Projekt-pro-Mandant-Designs stark hochskaliert werden, empfehlen wir die Verwendung eines Dataset-pro-Mandant-Designs.
• Für VPC Service Controls gilt ein Limit von 100 Perimetern, einschließlich Bridges, pro Organisation.

Autorisierte Ansichten oder materialisierte Teilmengentabellen verwenden

Zur Verwaltung des Mandantenzugriffs auf Teilmengen großer Faktentabellen können Sie mandantenspezifische autorisierte Ansichten verwenden oder mandantenspezifische Teilmengentabellen erstellen. Die folgende Tabelle enthält einen Vergleich dieser Ansätze:

Feature	Autorisierte Ansichten	Teilmengentabellen
Anzahl der unterstützten Mandanten	Es besteht ein hartes Limit von 2500 autorisierten Ressourcen pro Dataset.	Autorisierte Ressourcen umfassen autorisierte Ansichten, autorisierte Datasets und autorisierte Funktionen. Für die Anzahl der Datasets in einem Projekt oder für Tabellen in einem Dataset gibt es keine Begrenzung.
Partitionierung und Clustering	Autorisierte Ansichten müssen das gemeinsame Partitionierungs- und Clusterschema der Basistabelle verwenden. Um die Leistung der Mandantensegmentierung zu verbessern, empfehlen wir, die übergeordnete Tabelle nach der Mandanten-ID zu gruppieren.	Sie können die Teilmengentabelle partitionieren und entsprechend den Anforderungen des Mandanten gruppieren.
Regionalisierung	Autorisierte Ansichten können nicht regionenübergreifend sein und müssen sich in der Google Cloud-Region der Basistabelle befinden. Die Regionalisierung wirkt sich auf geografisch entfernte Mandanten aus.	Teilmengentabellen können sich in der Region befinden, die für den Mandanten am besten geeignet ist. Möglicherweise fallen zusätzliche Kosten an.
Durchsetzung der Spaltenrichtlinien	Spaltenrichtlinien, die auf eine Basistabelle angewendet werden, werden unabhängig von den Berechtigungen für diese Ansichten auf alle autorisierten Ansichten angewendet.	Die Spaltenrichtlinie muss auf jede Teilmengentabelle angewendet werden, damit sie wirksam wird.
Logging des Datenzugriffs	Datenzugriffslogs werden im Logging der Basistabelle widergespiegelt.	Der Zugriff auf die einzelnen Teilmengentabellen wird separat protokolliert.
Flexibilität der Transformation	Autorisierte Ansichten ermöglichen eine sofortige Neugestaltung des Objekts, auf das Mandanten zugreifen.	Bei Änderungen an Teilmengentabellen sind komplexe Schemaänderungen erforderlich.

Vertrauliche Daten schützen

BigQuery bietet neben Standard-IAM-Berechtigungen mehrere zusätzliche Funktionen, um unbefugten Zugriff auf Daten zu verhindern.

Vom Client bereitgestellte Verschlüsselung

Die Verschlüsselung von Clientdaten gilt für Fälle, in denen eine Hosting-Organisation Daten speichert und im Namen eines Mandanten verarbeitet, aber auf einige der Dateninhalte nicht zugreifen kann. Es wird beispielsweise verhindert, dass die Hosting-Organisation auf personenbezogene Daten oder Gerätedaten zugreift, die als vertraulich eingestuft werden.

Wir empfehlen, dass der Sender der Daten AEAD-Verschlüsselungsschlüssel aus der Open-Source-Tink-Bibliothek zum Verschlüsseln vertraulicher Daten verwendet. Die AEAD-Verschlüsselungsschlüssel für die Tink-Bibliothek sind mit den BigQuery-AEAD-Funktionen kompatibel. Der Mandant kann die Daten dann entweder entschlüsseln, indem er auf das Schlüsselmaterial in einer autorisierten UDF zugreift oder das Schlüsselmaterial als Abfrageparameter an BigQuery übergibt, wo die Hostorganisation den Schlüssel nicht protokollieren kann.

Spaltenzugriffsrichtlinien

In mehrmandantenfähigen Data-Marts werden häufig Spaltenrichtlinien verwendet, um zu verhindern, dass vertrauliche Inhalte versehentlich zwischen Teams ausgetauscht werden. Autorisierte Ansichten sind die bevorzugte Methode, um Daten zwischen Teams in einem Data-Mart-Szenario freizugeben. Autorisierte Ansichten können keinen Zugriff auf eine geschützte Spalte gewähren.

Wenn Sie die Richtlinie erzwingen, um die Zugriffssteuerung zu erzwingen, verhindern Sie den Zugriff durch Nutzer, die nicht die Rolle Detaillierter Lesezugriff für die Richtlinie erhalten haben. Selbst wenn die Richtlinie nicht erzwungen wird, protokolliert die Richtlinie den gesamten Nutzerzugriff auf die kategorisierte Spalte.

Schutz sensibler Daten

Der Schutz sensibler Daten stellt APIs und Scanprogramme bereit, mit denen Sie vertrauliche Inhalte in BigQuery- oder Cloud Storage-Datasets identifizieren und sichern können. Organisationen in Mehrmandantenszenarien verwenden die DLP API (Teil des Schutzes sensibler Daten) häufig, um vertrauliche Daten zu identifizieren und optional zu tokenisieren, bevor sie gespeichert werden.

Slot-Reservierungsverwaltung

Die Reservierungsverwaltung in mehrmandantenfähigen Systemen hilft bei der Kostenkontrolle, wenn Mandanten hochskaliert werden, und sorgt für Leistungsgarantien für jeden Mandanten.

Zum Verwalten von Reservierungen empfehlen wir die Erstellung eines einzelnen Reservierungsverwaltungsprojekts. Slot-Zusicherungen, die innerhalb desselben administrativen Projekts erworben werden, sind für alle Reservierungen aus dem Verwaltungsprojekt gemeinsam nutzbar. Ein Projekt, das Slot-Zusicherungen verwendet, kann nur jeweils einer Reservierung zugewiesen werden. Alle Abfragen, die aus einem Projekt stammen, teilen sich Slots anhand der verfügbaren Ressourcen.

Um sicherzustellen, dass die Service Level Objectives (SLOs) des Mandanten erfüllt sind, können Sie Folgendes tun: Überwachen von Reservierungen über Cloud Logging und das BigQuery-Informationsschema. Organisationen, bei denen es geschäftige Zeiten wegen Analystenaktivitäten oder Prioritätsjobs gibt, können mit Flex-Slots zusätzliche Kapazitäten zuweisen.

Reservierungen als Mandanten-Computing-Stufen

SaaS-Anbieter, die Dutzende bis zu Tausende von Mandanten haben, konfigurieren in der Regel eine begrenzte Anzahl von BigQuery-Reservierungen als freigegebene Ressourcen.

Wenn Sie ein SaaS-Anbieter sind, der eine mandantenfähige Infrastruktur gemeinsam genutzt hat, empfehlen wir, jede Reservierung einem einzelnen Projekt und mehreren Mandanten zuzuweisen, um dieses Projekt für das BigQuery-Computing freigeben zu können. Dieses Design verringert den Verwaltungsaufwand, da es Tausende von zusätzlichen Projekten und Reservierungen gibt. Gleichzeitig kann Ihre Organisation eine Mindest-Slot-Kapazität zuweisen, die für die erwarteten Leistungsanforderungen der Reservierung erforderlich ist.

Wenn die zügige ELT-Datenverarbeitung Zeitachsen eine sehr hohe Priorität hat, empfehlen wir Ihnen, eine Reservierung für die Verarbeitung zuzuweisen. Wenn Sie die Verwendung von zusätzlichen Slots für Ad-hoc-Arbeitslasten vermeiden möchten, legen Sie für die Reservierung die Option Inaktive Slots ignorieren fest.

Im Folgenden finden Sie ein Beispiel zum Konfigurieren von Reservierungen als Mandanten-Computing-Stufen:

• Datenverarbeitung: 2.000 Slots; inaktive ignorieren. Diese Reservierung ist für die Erfüllung der SLOs für die Datenverarbeitung konfiguriert.
• Interne Projekte: 1.000 Slots; inaktive zulassen. Diese Reservierung wird auf Projekte angewendet, die für interne Analysen verwendet werden. Slots werden wiederverwendet, wenn sie von der Datenverarbeitung oder von Computing-Stufen übrig gelassen werden.
• Niedrige Computing-Stufe: 2.000 Slots; inaktive ignorieren. Diese Reservierung wird bei Mandanten mit niedrigen Ressourcen angewendet. Im Gegensatz zur hohen Stufe ignoriert diese Reservierung inaktive Slots.
• Hohe Computing-Stufe: 3.000 Slots; inaktive zulassen. Diese Reservierung wird bei Mandanten mit hohen Ressourcen angewendet. Inaktive Slots aus anderen Reservierungen werden automatisch angewendet, um Abfragen zu beschleunigen.

Wenn Ihre Mandanten auf einer dedizierten Infrastruktur arbeiten, empfehlen wir Ihnen, den designierten Ordner oder das designierte Projekt der entsprechenden freigegebenen Reservierung zuzuweisen.

Reservierungen pro Team

Wenn Sie in einem Data-Mart-Szenario mit Teams arbeiten, empfiehlt es sich, für jedes Team eine Reservierung zu erstellen, die zusätzliche Rechenleistung erfordert. Weisen Sie diese Reservierung dann dem übergeordneten Ordner zu, der die Projekte des Teams enthält. Alle neuen Projekte für dieses Team verwenden Slots für faire Planung aus derselben Zuweisung von Ressourcen.

Im Folgenden finden Sie ein Beispiel zum Konfigurieren von Reservierungen pro Team:

• Reservierung auf Organisationsebene: 500 Slots; inaktive zulassen. Diese Reservierung wird der obersten Organisation zugewiesen und gibt Slots jedem BigQuery-Nutzer, der kein Projekt mit dedizierter Reservierung verwendet.
• Datenverarbeitung: 1.000 Slots; inaktive ignorieren. Diese Reservierung ist dafür konfiguriert, die Mindest-SLOs für die Datenverarbeitung zu erfüllen.
• Kerndatenverwaltung: 500 Slots; inaktive zulassen. Diese Reservierung wird auf die Projekte angewendet, die für die interne Verwaltung verwendet werden. Slots werden wiederverwendet, wenn sie von der Datenverarbeitung oder von Computing-Stufen übrig gelassen werden.
• Analyseverarbeitungsreservierungen: 500 Slots; inaktive zulassen. Dies ist eine dedizierte Reservierung, die einem Analyseteam erteilt wird.

Multiregionale Hosting-Anforderungen

Multiregionale Hosting-Anforderungen sind in der Regel darauf zurückzuführen, dass entweder die Latenz der Daten für Nutzer reduziert werden muss oder behördliche Anforderungen erfüllt werden müssen.

Projekte in Google Cloud gelten als global und können Ressourcen in jeder Region bereitstellen. BigQuery betrachtet Datasets, Spaltenrichtlinien und Slot-Zusicherungen als regionale Ressourcen. Slots können nur auf Datasets in der lokalen Region zugreifen. Spaltenrichtlinien können nur auf Tabellen innerhalb lokaler Datasets angewendet werden. Damit Sie kapazitätsbasierte Preise verwenden können, müssen Sie Slots in jeder Region erwerben, die Datasets enthält.

Informationen zur Einhaltung behördlicher Anforderungen erhalten Sie bei Ihrem Vertriebsmitarbeiter.

Nächste Schritte

• Informationen zu Best Practices für IAM