Sobre o controle de ingestão da linhagem de dados

Para gerenciar custos e políticas de governança, é possível ativar ou desativar a ingestão de linhagem de dados para serviços específicos do Google Cloud . Por exemplo, é possível desativar a coleta de linhagem para projetos de desenvolvimento ou cargas de trabalho de alto volume que não exigem rastreamento de linhagem.

Integrações de serviço compatíveis

A tabela a seguir lista as integrações que oferecem suporte ao controle de ingestão de linhagem de dados:

Nome da integração Suporte ao controle de ingestão Valor padrão Detalhes da integração
Serviço Gerenciado para Apache Spark: clusters do Apache Spark Sim Ativado Como usar a linhagem de dados do Spark
Serviço gerenciado para Apache Spark: clusters do Apache Hive Sim Ativado Ativar a linhagem de dados do Hive
Serviço Gerenciado para Apache Spark: implantação sem servidor Sim Ativado Usar a linhagem de dados com o Serviço Gerenciado para Apache Spark
BigQuery Sim Ativado Rastrear a linhagem de uma tabela do BigQuery
Serviço gerenciado para Apache Airflow Sim Ativado Linhagem de dados com o Knowledge Catalog
Looker (Google Cloud Core) Sim (pré-lançamento) Ativado Linhagem de dados do Looker Core
Cloud Data Fusion Não Ativado Ver a linhagem no Knowledge Catalog
Dataflow Não Desativado do lado do Dataflow Usar a linhagem de dados no Dataflow
Vertex AI Pipelines Não Ativado Rastrear a linhagem de artefatos de pipeline

Como funciona o controle de ingestão da linhagem de dados

É possível controlar a ingestão de dados nos níveis de organização, pasta e projeto e combinar essas configurações com as específicas do serviço para ter um controle granular sobre a ingestão de linhagem de dados.

O Knowledge Catalog avalia a hierarquia de recursos começando por um projeto, depois pelas pastas e, em seguida, pela organização para determinar a configuração efetiva. A primeira configuração definida explicitamente em qualquer nível nessa travessia ascendente entra em vigor.

  • Se você definir uma configuração no nível do projeto, o Knowledge Catalog vai usá-la.
  • Se nenhuma configuração for definida no nível do projeto, o Knowledge Catalog vai usar a configuração da pasta pai mais próxima com uma configuração explícita.
  • Se nenhuma configuração for definida no nível do projeto ou da pasta, o Knowledge Catalog vai usar a configuração no nível da organização.
  • Se nenhuma configuração for definida em nenhum desses níveis, o Knowledge Catalog vai usar o padrão do sistema para a integração.

Para gerenciar o controle de ingestão em massa, ative a API Data Lineage para todos os projetos em uma pasta ou organização seguindo as regras de ativação de serviço hierárquica. Depois de ativar a API Data Lineage, é possível controlar de maneira granular a ingestão de linhagem de dados por integração de serviço para uma organização, pasta ou projeto.

Como funciona a configuração de ingestão de dados para integrações de serviço único

O cenário a seguir ilustra como o Knowledge Catalog resolve a configuração de ingestão de linhagem para um único serviço na hierarquia de recursos.

Considere uma organização test-org com as seguintes configurações de linhagem do Serviço Gerenciado para Apache Spark:

  • Organização test-org: ativada
    • Pasta folder-a: Desativada
      • Projeto project-a: nenhuma configuração definida
    • Pasta folder-b: Ativada
      • Projeto project-b: desativado

Nesse cenário, as seguintes configurações se aplicam:

  • Para project-a, a ingestão de linhagem está Desativada. O Knowledge Catalog começa a avaliação em project-a, não encontra nenhuma configuração, passa para folder-a e aplica a configuração Desativado de folder-a.
  • Para project-b, a ingestão de linhagem está Desativada. O Knowledge Catalog começa a avaliar a partir de project-b e aplica a configuração Desativado, substituindo as configurações em folder-b e test-org.

Como funciona a configuração de ingestão de dados para integrações de vários serviços

O cenário a seguir ilustra como o Knowledge Catalog resolve de forma independente as configurações de vários serviços na hierarquia de recursos.

Considere uma organização test-org com as seguintes configurações de linhagem em várias integrações de serviço:

  • Organização test-org
    • Serviço Gerenciado para Apache Spark: ativado
    • Pasta folder-a
      • BigQuery: ativado
      • Projeto project-a
        • BigQuery: desativado
        • Serviço gerenciado para Apache Airflow: ativado
      • Projeto project-b: nenhuma configuração definida

Nesse cenário, o Knowledge Catalog avalia cada integração de serviço de forma independente na hierarquia de recursos:

  • Para project-a:
    • A ingestão de linhagem do Serviço Gerenciado para Apache Spark está Ativada. O Knowledge Catalog começa a avaliação em project-a, não encontra configuração para o Serviço Gerenciado para Apache Spark, passa para folder-a (sem configuração definida) e aplica a configuração Ativado de test-org.
    • A ingestão de linhagem do BigQuery está desativada. O Knowledge Catalog aplica a configuração explícita no nível do projeto, que substitui a configuração Ativada definida em folder-a.
    • A ingestão de linhagem do Serviço gerenciado para Apache Airflow está Ativada. O Knowledge Catalog aplica a configuração explícita para envolvidos no projeto.
  • Para project-b:
    • A ingestão de linhagem do Serviço Gerenciado para Apache Spark está Ativada (herdada de test-org).
    • A ingestão de linhagem do BigQuery está Ativada (herdada de folder-a).
    • A ingestão de linhagem do Serviço Gerenciado para Apache Airflow usa o padrão do sistema (Ativado por padrão quando a API Data Lineage está ativa), porque nenhuma configuração explícita é definida em qualquer nível da hierarquia.

A seguir