Ubicaciones de Knowledge Catalog

Cuando creas un recurso de Knowledge Catalog (antes Dataplex Universal Catalog), como un grupo de entradas, tipo de entrada, tipo de aspecto o un análisis de datos, seleccionas la ubicación en la que se almacenan y a la que se accede a sus metadatos. Elegir la ubicación correcta es fundamental para el cumplimiento de la residencia de datos, el rendimiento y la reutilización de recursos.

Por qué es importante la ubicación

Elegir la ubicación adecuada para tus recursos de Knowledge Catalog es importante por los siguientes motivos:

  • Residencia y cumplimiento de datos: Si tu organización está sujeta a regulaciones estrictas de residencia de datos (DRZ), debes almacenar metadatos y definiciones de recursos en dominios o regiones geográficas específicas para cumplir con las políticas localizadas.

  • Latencia y disponibilidad: Seleccionar una región cercana a tus fuentes de datos principales (como conjuntos de datos de BigQuery o buckets de Cloud Storage) y a tus usuarios finales reduce la latencia de búsqueda y mejora la confiabilidad de la ingesta de metadatos.

  • Reutilización de recursos: Decidir si un recurso es local para una región o se comparte de forma global afecta la forma en que puedes reutilizar las plantillas de metadatos en diferentes ubicaciones.

Lineamientos para elegir ubicaciones

Los recursos de Knowledge Catalog se pueden crear en una ubicación regional (como us-central1 o europe-west3), una ubicación multirregional (como us o eu) o la ubicación global.

Ubicaciones regionales

Una ubicación regional restringe la definición de recursos y su almacenamiento de metadatos a esa región específica:

  • Beneficios: Proporciona un cumplimiento estricto de la residencia de datos (DRZ). Los metadatos técnicos para las fuentes regionales (como BigQuery o Cloud Storage) se recopilan y almacenan automáticamente dentro de la misma región física. Google Cloud

  • Limitaciones: Los tipos regionales (como los tipos de entrada o de aspecto personalizados) solo se pueden aplicar a los grupos de entradas y a las entradas dentro de la misma región. No se pueden compartir ni reutilizar en varias regiones.

Ubicaciones multirregionales

Una ubicación multirregional abarca varias regiones físicas dentro de un área geográfica (como us o eu):

  • Beneficios: Permite que los metadatos de los grupos de entradas y las entradas abarquen varias regiones físicas dentro del dominio geográfico.

  • Limitaciones: Los DataScans (como los análisis de calidad de los datos y los análisis del perfil de datos) no son compatibles con las ubicaciones multirregionales. Debes crear DataScans en una ubicación regional.

Ubicación global

La ubicación global es una ubicación virtual en la que las definiciones de metadatos se replican en todas las Google Cloud regiones del mundo:

  • Beneficios: Promueve la máxima reutilización. Se puede aplicar un tipo de aspecto o de entrada global a las entradas ubicadas en cualquier región. Es ideal para definir estándares unificados de metadatos corporativos sin duplicar plantillas en regiones separadas.

  • Limitaciones: No garantiza que los metadatos permanezcan en una sola jurisdicción geográfica, lo que podría infringir los requisitos estrictos de cumplimiento de la residencia de datos.

Restricciones y limitaciones

Cuando organices tus metadatos, ten en cuenta las siguientes restricciones:

  • Ubicación inmutable: No puedes modificar la ubicación de un recurso (como un grupo de entradas, un tipo de entrada o un tipo de aspecto) después de crearlo.

  • Verificaciones de compatibilidad de ubicación: Para obtener más detalles sobre la compatibilidad, consulta Restricciones de proyectos y ubicaciones.

    • La ubicación de una entrada debe coincidir con la ubicación de su grupo de entradas y tipo de entrada asociados, o el tipo de entrada debe ser global.

    • Un aspecto agregado a una entrada o un vínculo de entrada debe basarse en un tipo de aspecto en la misma ubicación, o el tipo de aspecto debe ser global.

    • Un tipo de entrada o un tipo de vínculo de entrada debe estar compuesto por tipos de aspecto almacenados en la misma ubicación que el tipo de entrada, o los tipos de aspecto deben ser global.

Regiones

En la siguiente tabla, se enumeran las regiones en las que está disponible Knowledge Catalog. Las regiones se agregan con regularidad. Para obtener actualizaciones, consulta las notas de la versión de Knowledge Catalog.

Nombre de la región Descripción de la región Linaje de datos disponible
asia-east1 Taiwán Sí
asia-east2 Hong Kong Sí
asia-northeast1 Tokio Sí
asia-northeast2 Osaka Sí
asia-northeast3 Seúl Sí
asia-south1 Bombay Sí
asia-south2 Delhi Sí
asia-southeast1 Singapur Sí
asia-southeast2 Yakarta Sí
africa-south1 Johannesburgo Sí
australia-southeast1 Sídney Sí
australia-southeast2 Melbourne Sí
eu Varias regiones de la Unión Europea Sí
europe-central2 Varsovia Sí
europe-north1 Finlandia Sí
europe-north2 Estocolmo Sí
europe-southwest1 Madrid Sí
europe-west1 Bélgica Sí
europe-west2 Londres Sí
europe-west3 Fráncfort Sí
europe-west4 Países Bajos Sí
europe-west6 Zúrich Sí
europe-west8 Milán Sí
europe-west9 París Sí
europe-west10 Berlín Sí
europe-west12 Turín Sí
me-central1 Doha Sí
me-central2 Dammam Sí
me-west1 Tel Aviv Sí
northamerica-northeast1 Montreal Sí
northamerica-northeast2 Toronto Sí
northamerica-south1 México Sí
southamerica-east1 São Paulo Sí
southamerica-west1 Santiago Sí
us Varias regiones de Estados Unidos Sí
us-central1 Iowa Sí
us-east1 Carolina del Sur Sí
us-east4 Virginia del Norte Sí
us-east5 Columbus Sí
us-south1 Dallas Sí
us-west1 Oregón Sí
us-west2 Los Ángeles Sí
us-west3 Salt Lake City Sí
us-west4 Las Vegas Sí

Regiones de BigQuery Omni para el linaje de datos

El linaje de datos está disponible en las siguientes regiones de BigQuery Omni:

Nombre de la región Descripción de la región
aws-ap-northeast-2 AWS: Asia-Pacífico (Seúl)
aws-ap-southeast-2 AWS - Asia-Pacífico (Sídney)
aws-eu-central-1 AWS - Europa (Fráncfort)
aws-eu-west-1 AWS: Europa (Irlanda)
aws-us-east-1 AWS - US East (N. Norte)
aws-us-west-2 AWS: Oeste de EE.UU. (Oregón)
azure-eastus2 Azure - East US 2

¿Qué sigue?