À propos du contrôle de l'ingestion de la traçabilité des données

Pour gérer les coûts et les règles de gouvernance, vous pouvez activer ou désactiver l'ingestion de la traçabilité des données pour des services Google Cloud spécifiques. Par exemple, vous pouvez désactiver la collecte de la traçabilité pour les projets de développement ou les charges de travail à fort volume qui ne nécessitent pas de suivi de la traçabilité.

Intégrations de services compatibles

Le tableau suivant liste les intégrations compatibles avec le contrôle de l'ingestion de la traçabilité des données :

Nom de l'intégration Assistance pour le contrôle de l'ingestion Valeur par défaut Détails de l'intégration
Managed Service pour Apache Spark : clusters Apache Spark Oui Activé Utiliser la traçabilité des données Spark
Managed Service pour Apache Spark : clusters Apache Hive Oui Activé Activer la traçabilité des données Hive
Managed Service pour Apache Spark : déploiement sans serveur Oui Activé Utiliser la traçabilité des données avec Managed Service pour Apache Spark
BigQuery Oui Activé Suivre la traçabilité d'une table BigQuery
Service géré pour Apache Airflow Oui Activé Traçabilité des données avec Knowledge Catalog
Looker (Google Cloud Core) Oui (Aperçu) Activé Traçabilité des données Looker Core
Cloud Data Fusion Non Activé Afficher la traçabilité dans Knowledge Catalog
Dataflow Non Désactivé côté Dataflow Utiliser la traçabilité des données dans Dataflow
Vertex AI Pipelines Non Activé Suivre la traçabilité des artefacts de pipeline

Fonctionnement du contrôle de l'ingestion de la traçabilité des données

Vous pouvez contrôler l'ingestion de données au niveau de l'organisation, du dossier et du projet, et combiner ces paramètres avec des configurations spécifiques aux services pour contrôler précisément l'ingestion de la traçabilité des données.

Le catalogue de connaissances évalue la hiérarchie des ressources en commençant par un projet, puis par les dossiers, puis par l'organisation pour déterminer la configuration effective. La première configuration explicitement définie à un niveau quelconque de cette traversée ascendante prend effet.

  • Si vous définissez une configuration au niveau du projet, Knowledge Catalog l'utilise.
  • Si aucune configuration n'est définie au niveau du projet, le catalogue de connaissances utilise la configuration du dossier parent le plus proche avec une configuration explicite.
  • Si aucune configuration n'est définie au niveau du projet ou du dossier, Knowledge Catalog utilise la configuration au niveau de l'organisation.
  • Si aucune configuration n'est définie à l'un de ces niveaux, Knowledge Catalog utilise le paramètre système par défaut pour l'intégration.

Pour gérer le contrôle de l'ingestion de manière groupée, activez l'API Data Lineage pour tous les projets d'un dossier ou d'une organisation en suivant les règles d'activation hiérarchique des services. Une fois l'API Data Lineage activée, vous pouvez contrôler précisément l'ingestion de la traçabilité des données par intégration de service pour une organisation, des projets ou des dossiers individuels.

Fonctionnement de la configuration de l'ingestion de données pour les intégrations à un seul service

Le scénario suivant illustre la façon dont Knowledge Catalog résout la configuration d'ingestion de la traçabilité pour un seul service dans la hiérarchie des ressources.

Prenons l'exemple d'une organisation test-org avec les configurations de traçabilité Managed Service pour Apache Spark suivantes :

  • Organisation test-org : Activé
    • Dossier folder-a : Désactivé
      • Projet project-a : aucune configuration définie
    • Dossier folder-b : Activé
      • Projet project-b : désactivé

Dans ce scénario, les paramètres suivants s'appliquent :

  • Pour project-a, l'ingestion de la traçabilité est désactivée. Knowledge Catalog commence l'évaluation à partir de project-a, ne trouve aucune configuration, passe à folder-a et applique la configuration Désactivé à partir de folder-a.
  • Pour project-b, l'ingestion de la traçabilité est désactivée. Knowledge Catalog commence l'évaluation à partir de project-b et applique sa configuration Désactivé, en remplaçant les paramètres de folder-b et test-org.

Fonctionnement de la configuration de l'ingestion de données pour les intégrations multiservices

Le scénario suivant illustre la façon dont Knowledge Catalog résout indépendamment les configurations pour plusieurs services dans la hiérarchie des ressources.

Prenons l'exemple d'une organisation test-org avec les configurations de traçabilité suivantes pour plusieurs intégrations de services :

  • Organisation test-org
    • Managed Service pour Apache Spark : Activé
    • Dossier folder-a
      • BigQuery : Activé
      • Projet project-a
        • BigQuery : Désactivé
        • Managed Service pour Apache Airflow : Activé
      • Projet project-b : aucune configuration définie

Dans ce scénario, Knowledge Catalog évalue chaque intégration de service de manière indépendante dans la hiérarchie des ressources :

  • Pour project-a :
    • L'ingestion de la traçabilité Managed Service pour Apache Spark est activée. Knowledge Catalog commence l'évaluation à partir de project-a, ne trouve aucune configuration pour Managed Service pour Apache Spark, passe à folder-a (aucune configuration définie) et applique la configuration Activé à partir de test-org.
    • L'ingestion du lineage BigQuery est désactivée. Knowledge Catalog applique la configuration explicite au niveau du projet, qui remplace la configuration Activé définie sur folder-a.
    • L'ingestion de la traçabilité Managed Service pour Apache Airflow est activée. Knowledge Catalog applique la configuration explicite au niveau du projet.
  • Pour project-b :
    • L'ingestion du lineage Managed Service pour Apache Spark est activée (héritée de test-org).
    • L'ingestion de la traçabilité BigQuery est activée (héritée de folder-a).
    • L'ingestion de la traçabilité Managed Service pour Apache Airflow utilise la valeur par défaut du système (Activé par défaut lorsque l'API Data Lineage est active), car aucune configuration explicite n'est définie à aucun niveau de la hiérarchie.

Étapes suivantes