Sobre a pesquisa de linhagem multirregional

Este documento descreve os conceitos, métodos e casos de uso para pesquisar a linhagem de dados em várias regiões geográficas no Knowledge Catalog (antigo Dataplex Universal Catalog).

A linhagem de dados no Knowledge Catalog é um serviço regionalizado. Os dados de linhagem, incluindo links, processos e eventos, são registrados e armazenados no local geográfico específico em que ocorreu a transformação ou movimentação de dados.

No entanto, os pipelines de dados empresariais geralmente abrangem vários projetos e regiões do Google Cloud. Por exemplo, uma tabela do BigQuery em us-central1 que copia dados para um bucket de armazenamento em europe-west1. Para rastrear recursos de dados de forma abrangente nessas fronteiras, é necessário realizar uma pesquisa de linhagem multirregional.

O Knowledge Catalog oferece dois métodos para descobrir e agregar gráficos de linhagem entre regiões:

  • O método de automação do lado do servidor que usa a API searchLineageStreaming (prévia)—recomendado
  • O método de distribuição de dados do lado do cliente que usa a API searchLinks.

Principais conceitos

Para entender a descoberta de linhagem multirregional, é útil saber como o sistema processa a travessia de gráficos:

  • Critérios principais: o ponto de partida da pesquisa de linhagem, definido por um ou mais nomes de recursos (como uma tabela do BigQuery ou um tópico do Pub/Sub) ou campos de coluna detalhados.

  • Direção: a orientação da travessia de gráficos em relação aos critérios raiz. Você pode pesquisar upstream (para ver de onde vieram seus dados) ou downstream (para ver para onde eles estão indo).

  • Pesquisa em largura: o mecanismo arquitetônico usado para encontrar nós conectados. A pesquisa percorre o gráfico de linhagem camada por camada, calculando com precisão a profundidade de execução de cada recurso conectado em todas as fronteiras regionais.

Comparação de métodos de pesquisa

Embora os dois métodos permitam juntar uma visão entre regiões dos seus dados, eles lidam com o trabalho pesado de maneira diferente:

Recurso Automação do lado do servidor
API searchLineageStreaming		 Distribuição de dados do lado do cliente
API searchLinks
Modelo de execução Automação do lado do servidor: o mecanismo de roteamento Google Cloud percorre várias regiões de forma nativa. Orquestração do lado do cliente: o script do aplicativo precisa fazer um loop e gerenciar solicitações manualmente.
Sobrecarga de solicitação Solicitação de API única: uma única chamada HTTP POST inicia a pesquisa em várias regiões. Várias solicitações de API: exigem uma chamada HTTP separada para cada região e cada camada de gráfico.
Processamento de respostas Stream em tempo real: os resultados são enviados ao cliente à medida que são encontrados, evitando tempos limite. Payloads estáticos: matrizes JSON individuais precisam ser recebidas, coletadas e mescladas manualmente.
Grafos profundos (mais de duas camadas) Processa automaticamente gráficos de linhagem profundos e aninhados até 100 níveis. Sofre com o problema de consulta N+1 e exige viagens de ida e volta iterativas e lentas do cliente.

Escolha o método certo para seu caso de uso

Analise os cenários a seguir para determinar qual método de pesquisa multirregional se adapta à sua carga de trabalho.

Escolha o método da API de streaming para os seguintes casos de uso:

  • Rastrear gráficos complexos ou detalhados: seus dados passam por várias tabelas, buckets ou pipelines intermediários em diferentes regiões, exigindo travessia multinível (maxDepth maior que 2).

  • Acompanhar a linhagem no nível da coluna: você quer acompanhar campos em várias regiões ou usar pesquisas com caracteres curinga (*) para extrair todas as dependências de coluna de uma só vez.

  • Manter um código leve: você prefere fazer uma única chamada de API e deixar o Google Cloud cuidar do roteamento, da remoção de duplicação e da montagem do gráfico.

  • Exigir metadados do pipeline: você quer recuperar opcionalmente detalhes estruturais sobre os processos que executam seus pipelines na mesma carga útil da solicitação.

Escolha o método de distribuição de dados do lado do cliente para os seguintes cenários:

  • Você só rastreia linhagem rasa e de salto único: seu gráfico de linhagem não é complexo, e você só precisa pesquisar links diretos de pai ou filho (maxDepth igual a 1) em um pequeno número fixo de regiões conhecidas.

  • Você está trabalhando em sistemas legados restritos: você tem um aplicativo de governança de dados criado principalmente com base no endpoint padrão SearchLinks e quer manter a compatibilidade estrutural com versões anteriores sem implementar consumidores de respostas de streaming.

A seguir