Locais do Catálogo de Conhecimento

Ao criar um recurso do Knowledge Catalog (antigo Dataplex Universal Catalog), como um grupo de entrada, tipo de entrada, tipo de aspecto ou verificação de dados, você seleciona o local em que os metadados são armazenados e acessados. Escolher o local certo é fundamental para a conformidade com a residência de dados, o desempenho e a reutilização de recursos.

Por que o local é importante

Escolher o local apropriado para os recursos do Knowledge Catalog é importante pelos seguintes motivos:

  • Residência e conformidade de dados:se sua organização estiver sujeita a regulamentações rigorosas de residência de dados (DRZ, na sigla em inglês), você precisará armazenar metadados e definições de recursos em domínios ou regiões geográficas específicas para obedecer às políticas localizadas.

  • Latência e disponibilidade:selecionar uma região próxima às suas principais fontes de dados (como conjuntos de dados do BigQuery ou buckets do Cloud Storage) e aos usuários finais reduz a latência de pesquisa e melhora a confiabilidade da ingestão de metadados.

  • Reutilização de recursos:decidir se um recurso é local para uma região ou compartilhado globalmente afeta a forma como você pode reutilizar modelos de metadados em diferentes locais.

Diretrizes para escolher locais

Os recursos do Knowledge Catalog podem ser criados em um local regional (como us-central1 ou europe-west3), um local multirregional (como us ou eu) ou o local global.

Locais regionais

Um local regional restringe a definição de recursos e o armazenamento de metadados a essa região específica:

  • Benefícios:oferece conformidade rigorosa com a residência de dados (DRZ). Os metadados técnicos para fontes regionais Google Cloud (como BigQuery ou Cloud Storage) são coletados automaticamente e armazenados na mesma região física.

  • Limitações:os tipos regionais (como tipos de entrada ou de aspecto personalizados) só podem ser aplicados a grupos e entradas na mesma região. Eles não podem ser compartilhados ou reutilizados em várias regiões.

Locais multirregionais

Um local multirregional abrange várias regiões físicas em uma área geográfica (como us ou eu):

  • Benefícios:permite que os metadados de grupos e entradas abranjam várias regiões físicas no domínio geográfico.

  • Limitações:as verificações de dados (como qualidade de dados e perfilamento de dados) não são compatíveis com locais multirregionais. É necessário criar verificações de dados em um local regional.

Local global

O local global é um local virtual em que as definições de metadados são replicadas em Google Cloud regiões globalmente:

  • Benefícios:promove a máxima reutilização. Um tipo de aspecto ou de entrada global pode ser aplicado a entradas localizadas em qualquer região. É ideal para definir padrões unificados de metadados corporativos sem duplicar modelos em regiões separadas.

  • Limitações:não garante que os metadados permaneçam em uma única jurisdição geográfica, o que pode violar requisitos rigorosos de conformidade com a residência de dados.

Restrições e limitações

Ao organizar seus metadados, tenha em mente as seguintes restrições:

  • Local imutável:não é possível modificar o local de um recurso (como um grupo de entrada, um tipo de entrada ou um tipo de aspecto) depois que ele é criado.

  • Verificações de compatibilidade de local:para mais detalhes sobre compatibilidade, consulte Restrições de projeto e local.

    • O local de uma entrada precisa corresponder ao local do grupo de entrada e do tipo de entrada associados ou o tipo de entrada precisa ser global.

    • Um aspecto adicionado a uma entrada ou link de entrada precisa ser baseado em um tipo de aspecto no mesmo local, ou o tipo de aspecto precisa ser global.

    • Um tipo de entrada ou de link de entrada precisa ser composto de tipos de aspecto armazenados no mesmo local que o tipo de entrada, ou os tipos de aspecto precisam ser global.

Regiões

A tabela a seguir lista as regiões em que o Knowledge Catalog está disponível. As regiões são adicionadas regularmente. Para atualizações, consulte as notas de lançamento do Knowledge Catalog.

Nome da região Descrição da região Linhagem de dados disponível
asia-east1 Taiwan Sim
asia-east2 Hong Kong Sim
asia-northeast1 Tóquio Sim
asia-northeast2 Osaka Sim
asia-northeast3 Seul Sim
asia-south1 Mumbai Sim
asia-south2 Délhi Sim
asia-southeast1 Singapura Sim
asia-southeast2 Jacarta Sim
africa-south1 Johannesburgo Sim
australia-southeast1 Sydney Sim
australia-southeast2 Melbourne Sim
eu Várias regiões na União Europeia Sim
europe-central2 Varsóvia Sim
europe-north1 Finlândia Sim
europe-north2 Estocolmo Sim
europe-southwest1 Madri Sim
europe-west1 Bélgica Sim
europe-west2 Londres Sim
europe-west3 Frankfurt Sim
europe-west4 Holanda Sim
europe-west6 Zurique Sim
europe-west8 Milão Sim
europe-west9 Paris Sim
europe-west10 Berlim Sim
europe-west12 Turim Sim
me-central1 Doha Sim
me-central2 Dammam Sim
me-west1 Tel Aviv Sim
northamerica-northeast1 Montreal Sim
northamerica-northeast2 Toronto Sim
northamerica-south1 México Sim
southamerica-east1 São Paulo Sim
southamerica-west1 Santiago Sim
us Várias regiões nos Estados Unidos Sim
us-central1 Iowa Sim
us-east1 Carolina do Sul Sim
us-east4 Virgínia do Norte Sim
us-east5 Columbus Sim
us-south1 Dallas Sim
us-west1 Oregon Sim
us-west2 Los Angeles Sim
us-west3 Salt Lake City Sim
us-west4 Las Vegas Sim

Regiões do BigQuery Omni para linhagem de dados

A linhagem de dados está disponível nas seguintes regiões do BigQuery Omni:

Nome da região Descrição da região
aws-ap-northeast-2 AWS – Ásia-Pacífico (Seul)
aws-ap-southeast-2 AWS: Ásia-Pacífico (Sydney)
aws-eu-central-1 AWS: Europa (Frankfurt)
aws-eu-west-1 AWS - Europa (Irlanda)
aws-us-east-1 AWS - US East (N. Virginia)
aws-us-west-2 AWS - Oeste dos EUA (Oregon)
azure-eastus2 Azure - East US 2

A seguir