Pesquisar linhagem multirregional usando distribuição de dados do lado do cliente

O fan-out do lado do cliente no Knowledge Catalog (antigo Dataplex Universal Catalog) permite usar a API Data Lineage para recuperar e agregar links de linhagem de dados em várias regiões do Google Cloud . Consultar endpoints regionais em paralelo ajuda a criar uma visualização de linhagem unificada quando os recursos de dados abrangem locais diferentes.

Por que usar o fan-out do lado do cliente?

A abordagem de fan-out do lado do cliente é útil quando os recursos de dados estão distribuídos em diferentes locais e você quer orquestrar consultas regionais no cliente. É possível usar essa abordagem para buscar e agregar dados de linhagem de todas as regiões disponíveis ao rastrear a linhagem de salto único em um conjunto conhecido de regiões ou manter a compatibilidade com os fluxos de trabalho projects.locations.searchLinks existentes.

Para mais informações, consulte Sobre a pesquisa de linhagem multirregional.

Pseudocódigo detalhado

O procedimento faz solicitações paralelas ao endpoint projects.locations.searchLinks em cada região. Você coleta resultados, lida com a paginação entre regiões e agrega os links encontrados. Para garantir uma paginação consistente nas chamadas seguintes, gerencie um regionalPageToken. Isso é importante para regiões inacessíveis.

O pseudocódigo a seguir descreve um procedimento que pode ser seguido usando a API Data Lineage para buscar links de linhagem de dados de todas as regiões disponíveis.

  1. Configuração de entrada:
    • linksToFetch = 5 (número de links a serem buscados em todas as regiões)
    • regionalPageToken = "" (último token de página regional recebido usado para paginação)
  2. Criar:
    1. lista de todas as regiões para fan-out chamada regions.
    2. lista de regiões inacessíveis chamada unreachable.
    3. uma lista vazia de links encontrados chamada foundLinks.
    4. uma variável vazia nextPageToken e nextRegionalPageToken.
    5. uma variável vazia lastRegion.
    6. uma variável vazia lastRegionLinksCount.
  3. Classificar regions em ordem alfabética.
  4. Analisar regionalPageToken
    1. Se estiver vazio, prossiga para a etapa 5.
    2. Se não estiver vazio,
      1. analisar regionalPageToken dividindo-o pelo primeiro ponto em dois segmentos
      2. filtrar as regiões usando apenas aquelas que estão depois (em ordem alfabética) do primeiro segmento do regionalPageToken analisado.
      3. armazene o segundo segmento para usá-lo em todas as chamadas projects.locations.searchLinks.
  5. Faça uma chamada para projects.locations.searchLinks em cada região na lista regions em paralelo.
  6. Aguarde a conclusão de todas as solicitações.
  7. Filtre as respostas bem-sucedidas e armazene os nomes das regiões com falha na lista unreachable.
  8. Para cada uma das respostas (começando com a primeira região em ordem alfabética)
    1. se nenhum link foi retornado com um token de página não vazio
      1. Armazene o nome da região em lastRegion.
      2. salve o pageToken recebido em nextPageToken.
      3. ignore as respostas restantes.
    2. caso contrário,
      1. Armazene o nome da região em lastRegion.
      2. salvar os links recebidos em foundLinks (até linksToFetch).
      3. salve o pageToken recebido em nextPageToken.
      4. armazene o número de links extraídos da resposta em lastRegionLinksCount.
      5. se foundLinks for menor que linksToFetch
        1. continue o pseudocódigo com a próxima resposta recebida em ordem alfabética.
      6. se foundLinks for igual a linksToFetch
        1. faça outra solicitação ao endpoint projects.locations.searchLinks na mesma região, mas defina o parâmetro pageSize como o valor de lastRegionLinksCount.
        2. armazene o pageToken recebido em nextPageToken.
        3. continue para a etapa 9
  9. Adicione nextPageToken antes de lastRegion (ou seja, [region].[receivedNextPageToken]) para criar nextRegionalPageToken e processar a paginação em chamadas consecutivas.

A seguir