Para gerenciar custos e políticas de governança, ative ou desative a ingestão de linhagem de dados para serviços Google Cloud específicos. Por exemplo, é possível desativar a coleta de linhagem para projetos de desenvolvimento ou cargas de trabalho de alto volume que não exigem o rastreamento de linhagem.
Integrações de serviços com suporte
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 | 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évia) | Ativado | Linhagem de dados do Looker Core |
| Cloud Data Fusion | Não | Ativado | Ver a linhagem no Knowledge Catalog |
| Dataflow | Não | Desativado no 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 de linhagem de dados
É possível controlar a ingestão de dados nos níveis da organização, da pasta e do projeto, além de combinar essas configurações com configurações 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 com um projeto, depois pastas e, por fim, a 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 a usará.
- Se nenhuma configuração for definida no nível do projeto, o Knowledge Catalog usará a configuração da pasta mãe 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 usará a configuração da organização.
- Se nenhuma configuração for definida em nenhum desses níveis, o Knowledge Catalog 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árquico. Depois que a API Data Lineage for ativada, controle a ingestão de linhagem de dados por integração de serviço para uma organização, projetos ou pastas individuais.
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
- Projeto
- Pasta
folder-b: ativada- Projeto
project-b: desativado
- Projeto
- Pasta
Nesse cenário, as seguintes configurações são aplicadas:
- Para
project-a, a ingestão de linhagem está desativada. O Knowledge Catalog começa a avaliação emproject-a, não encontra nenhuma configuração, passa parafolder-a, e aplica a desativada configuração defolder-a. - Para
project-b, a ingestão de linhagem está desativada. O Knowledge Catalog começa a avaliação emproject-be aplica a configuração desativada dele, substituindo as configurações emfolder-betest-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 nenhuma configuração para o Serviço Gerenciado para Apache Spark, passa parafolder-a(nenhuma configuração definida) e aplica a configuração ativada detest-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.
- A ingestão de linhagem do Serviço Gerenciado para Apache Spark está ativada.
O Knowledge Catalog começa a avaliação em
- 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 nenhum nível da hierarquia.
- A ingestão de linhagem do Serviço Gerenciado para Apache Spark está ativada (herdada
de