Knowledge Catalog-Standorte

Wenn Sie eine Knowledge Catalog-Ressource (ehemals Dataplex Universal Catalog) wie eine Eintragsgruppe, Eintragstyp, Aspekttyp oder einen Datenscan erstellen, wählen Sie den Standort aus, an dem die Metadaten gespeichert und aufgerufen werden. Die Auswahl des richtigen Standorts ist entscheidend für die Einhaltung der Vorschriften zum Datenstandort, die Leistung und die Wiederverwendung von Ressourcen.

Warum der Standort wichtig ist

Die Auswahl des geeigneten Standorts für Ihre Knowledge Catalog-Ressourcen ist aus folgenden Gründen wichtig:

  • Datenstandort und Compliance:Wenn Ihre Organisation strengen Vorschriften zur Datenstandort unterliegt, müssen Sie Metadaten und Ressourcendefinitionen in bestimmten geografischen Domains oder Regionen speichern, um lokale Richtlinien einzuhalten.

  • Latenz und Verfügbarkeit:Wenn Sie eine Region in der Nähe Ihrer primären Datenquellen (z. B. BigQuery-Datasets oder Cloud Storage-Buckets) und Ihrer Endnutzer auswählen, wird die Suchlatenz reduziert und die Zuverlässigkeit der Metadatenerfassung verbessert.

  • Wiederverwendung von Ressourcen:Die Entscheidung, ob eine Ressource lokal für eine Region oder global freigegeben ist, wirkt sich darauf aus, wie Sie Metadatenvorlagen an verschiedenen Standorten wiederverwenden können.

Richtlinien für die Auswahl von Standorten

Ressourcen in Knowledge Catalog können an einem regionalen Standort (z. B. us-central1 oder europe-west3), einem multiregionalen Standort (z. B. us oder eu) oder am globalen Standort erstellt werden.

Regionale Standorte

An einem regionalen Standort wird die Ressourcendefinition und der Metadatenspeicher auf diese bestimmte Region beschränkt:

  • Vorteile:Bietet strenge Compliance mit den Vorschriften zum Datenstandort. Technische Metadaten für regionale Google Cloud Quellen (z. B. BigQuery oder Cloud Storage) werden automatisch erfasst und in derselben physischen Region gespeichert.

  • Einschränkungen:Regionale Typen (z. B. benutzerdefinierte Eintragstypen oder Aspekttypen) können nur auf Eintragsgruppen und Einträge in derselben Region angewendet werden. Sie können nicht über mehrere Regionen hinweg freigegeben oder wiederverwendet werden.

Multiregionale Standorte

Ein multiregionaler Standort umfasst mehrere physische Regionen innerhalb eines geografischen Gebiets (z. B. us oder eu):

  • Vorteile:Metadaten für Eintragsgruppen und Einträge können mehrere physische Regionen innerhalb der geografischen Domain umfassen.

  • Einschränkungen:DataScans (z. B. Scans zur Datenqualität und zur Datenprofilerstellung) werden an multiregionalen Standorten nicht unterstützt. Sie müssen DataScans an einem regionalen Standort erstellen.

Globaler Standort

Der Standort global ist ein virtueller Standort, an dem Metadatendefinitionen weltweit über Google Cloud Regionen hinweg repliziert werden:

  • Vorteile:Fördert maximale Wiederverwendbarkeit. Ein global Aspekt- oder Eintragstyp kann auf Einträge in jeder Region angewendet werden. Er eignet sich ideal zum Definieren einheitlicher Metadatenstandards für Unternehmen, ohne Vorlagen in separaten Regionen zu duplizieren.

  • Einschränkungen:Es wird nicht garantiert, dass Metadaten in einem einzigen geografischen Datenstandort verbleiben, was möglicherweise gegen strenge Anforderungen an die Datenresidenz verstößt.

Einschränkungen und Grenzwerte

Beachten Sie beim Organisieren Ihrer Metadaten die folgenden Einschränkungen:

  • Unveränderlicher Standort:Der Standort einer Ressource (z. B. einer Eintragsgruppe, eines Eintragstyps oder eines Aspekttyps) kann nach der Erstellung nicht mehr geändert werden.

  • Prüfungen der Standortkompatibilität:Weitere Informationen zur Kompatibilität finden Sie unter Einschränkungen für Projekte und Standorte.

    • Der Standort eines Eintrags muss mit dem Standort der zugehörigen Eintragsgruppe und des Eintragstyps übereinstimmen. Alternativ muss der Eintragstyp global sein.

    • Ein Aspekt, der einem Eintrag oder einer Eintragsverknüpfung hinzugefügt wird, muss auf einem Aspekttyp am selben Standort basieren. Alternativ muss der Aspekttyp global sein.

    • Ein Eintragstyp oder ein Eintragstyp für Verknüpfungen muss aus Aspekttypen bestehen, die am selben Standort wie der Eintragstyp gespeichert sind. Alternativ müssen die Aspekttypen global sein.

Regionen

In der folgenden Tabelle sind die Regionen aufgeführt, in denen Knowledge Catalog verfügbar ist. Es werden regelmäßig Regionen hinzugefügt. Aktuelle Informationen finden Sie in den Versionshinweisen zu Knowledge Catalog.

Name der Region Beschreibung der Region Data Lineage verfügbar
asia-east1 Taiwan Ja
asia-east2 Hongkong Ja
asia-northeast1 Tokio Ja
asia-northeast2 Osaka Ja
asia-northeast3 Seoul Ja
asia-south1 Mumbai Ja
asia-south2 Delhi Ja
asia-southeast1 Singapur Ja
asia-southeast2 Jakarta Ja
africa-south1 Johannesburg Ja
australia-southeast1 Sydney Ja
australia-southeast2 Melbourne Ja
eu Mehrere Regionen in der Europäischen Union Ja
europe-central2 Warschau Ja
europe-north1 Finnland Ja
europe-north2 Stockholm Ja
europe-southwest1 Madrid Ja
europe-west1 Belgien Ja
europe-west2 London Ja
europe-west3 Frankfurt Ja
europe-west4 Niederlande Ja
europe-west6 Zürich Ja
europe-west8 Mailand Ja
europe-west9 Paris Ja
europe-west10 Berlin Ja
europe-west12 Turin Ja
me-central1 Doha Ja
me-central2 Dammam Ja
me-west1 Tel Aviv Ja
northamerica-northeast1 Montreal Ja
northamerica-northeast2 Toronto Ja
northamerica-south1 Mexiko Ja
southamerica-east1 São Paulo Ja
southamerica-west1 Santiago Ja
us Mehrere Regionen in den Vereinigten Staaten Ja
us-central1 Iowa Ja
us-east1 South Carolina Ja
us-east4 Northern Virginia Ja
us-east5 Columbus Ja
us-south1 Dallas Ja
us-west1 Oregon Ja
us-west2 Los Angeles Ja
us-west3 Salt Lake City Ja
us-west4 Las Vegas Ja

BigQuery Omni-Regionen für Data Lineage

Data Lineage ist in den folgenden BigQuery Omni-Regionen verfügbar:

Name der Region Beschreibung der Region
aws-ap-northeast-2 AWS – Asiatisch-pazifischer Raum (Seoul)
aws-ap-southeast-2 AWS – Asiatisch-pazifischer Raum (Sydney)
aws-eu-central-1 AWS – Europa (Frankfurt)
aws-eu-west-1 AWS – Europa (Irland)
aws-us-east-1 AWS – US East (N. Virginia)
aws-us-west-2 AWS – US West (Oregon)
azure-eastus2 Azure – East US 2

Nächste Schritte