Résoudre les problèmes de découverte de données Knowledge Catalog

Ce guide vous aide à résoudre les problèmes courants liés aux analyses de découverte de données Knowledge Catalog (également appelées découverte autonome), y compris les échecs de publication de tables et les erreurs d'incompatibilité de schéma.

Échec de publication de table BigQuery (FAILED_BIGQUERY_TABLE_PUBLISH)

Lorsqu'une analyse de découverte s'exécute, elle peut échouer à publier des tables dans BigQuery. Dans ce cas, l'analyse enregistre une action FAILED_BIGQUERY_TABLE_PUBLISH dans Cloud Logging.

Ce problème se produit en raison des conditions suivantes :

  • Autorisations IAM insuffisantes : le compte de service Knowledge Catalog ou le compte de service de connexion BigQuery ne dispose pas des rôles requis pour déléguer des connexions, accéder à Cloud Storage ou écrire dans l'ensemble de données de destination.
  • Incompatibilité de connexion ou d'ensemble de données BigQuery : l'ID de connexion spécifié n'est pas valide, ou la connexion et l'ensemble de données de destination se trouvent dans des régions différentes.
  • Erreurs de configuration de table : la création ou la modification de table applique des paramètres incorrects ou non compatibles.

Pour résoudre ce problème, effectuez les vérifications suivantes :

  • Vérifiez les rôles du compte de service: Vérifiez que le compte de service Knowledge Catalog service-PROJECT_NUMBER@gcp-sa-dataplex.iam.gserviceaccount.com dispose du rôle Agent de service de publication BigLake Dataplex Discovery (roles/dataplex.discoveryBigLakePublishingServiceAgent) .
  • Vérifiez les autorisations de connexion : si vous créez des tables BigLake, vérifiez que le compte de service de connexion BigQuery dispose d'un accès en lecture au bucket Cloud Storage (à l'aide de roles/storage.objectViewer ou roles/dataplex.discoveryServiceAgent).
  • Vérifiez l'emplacement de la connexion et de l'ensemble de données: assurez-vous que la connexion BigQuery et l'ensemble de données BigQuery existent dans la même région et qu'ils sont compatibles avec l'emplacement du bucket Cloud Storage.
  • Inspectez les journaux pour obtenir des détails: explorez les journaux de votre tâche DataScan dans Cloud Logging. Si l'erreur contient BigQuery: Permission denied, vérifiez les autorisations du compte de service. Si elle contient TABLE_CONFIG, vérifiez que les fichiers de données sont conformes aux exigences de BigQuery.

Échec de la création de tables BigLake pour les grands buckets Cloud Storage

Lorsqu'une analyse de découverte traite des buckets Cloud Storage contenant un grand volume de données ou des fichiers individuels volumineux (par exemple, des fichiers Avro de plus de 30 Mo), elle peut créer l'ensemble de données BigQuery, mais échouer à publier les tables BigLake.

Dans ce cas, les erreurs suivantes peuvent s'afficher dans Cloud Logging :

  • FAILED_BIGQUERY_TABLE_PUBLISH
  • com.google.cloud.bigquery.BigQueryException: Read timed out

Ce problème est une limite de scalabilité connue. Si vous avez besoin d'un provisionnement immédiat des tables, configurez votre analyse de découverte pour inclure un sous-ensemble plus petit et filtré des données de votre bucket.

Incompatibilités de schéma de dossier Cloud Storage

Une analyse de découverte de données ne parvient pas à enregistrer des tables externes ou ne détecte pas les fichiers dans certains dossiers.

Ce problème se produit si vos dossiers Cloud Storage contiennent des fichiers avec des schémas incompatibles ou des formats différents. L'analyse de découverte regroupe les fichiers dans une seule table uniquement s'ils se trouvent dans le même dossier et ont un schéma compatible.

Lorsqu'une analyse de découverte de données analyse un chemin Cloud Storage, elle s'attend à ce que les fichiers d'un dossier et la structure de partition entre les dossiers soient cohérents. L'analyse signale une action si elle détecte l'un des éléments suivants :

  • Format de données non valide (INVALID_DATA_FORMAT) : des formats de données incohérents sont détectés dans le même dossier ou entre les partitions (par exemple, en mélangeant des fichiers .csv et .parquet dans le même répertoire).
  • Définition de partition non valide (INVALID_PARTITION_DEFINITION) : les clés de partition sont incohérentes ou manquantes. Par exemple, en utilisant Year=2023/Mon=Jan dans un chemin et Year=2023/Dept=Sales dans un autre.
  • Schéma de données incompatible (INCOMPATIBLE_DATA_SCHEMA) : des schémas incohérents ou incompatibles sont détectés dans les fichiers d'un même dossier ou d'une même table.

Pour les formats fortement typés comme Avro et Parquet, les incompatibilités de schéma se produisent en raison des éléments suivants :

  • Types de données incompatibles : une colonne est de type string dans un fichier et de type int ou boolean dans un autre.
  • Valeurs par défaut manquantes : de nouveaux champs sont ajoutés ou supprimés dans des fichiers plus récents sans que des valeurs par défaut ne soient spécifiées dans la définition du schéma, ce qui empêche l'évolution correcte du schéma.
  • Format de fichier corrompu : un ou plusieurs fichiers sont mal formés ou corrompus, ce qui empêche l’analyse de lire et d’extraire le schéma.

Pour résoudre ce problème, vérifiez la structure de vos fichiers et les définitions de schéma :

  • Organisez les fichiers par schéma et par format: Vérifiez que tous les fichiers d'un même dossier partagent le même format et la même structure de schéma. Déplacez les fichiers avec des colonnes, des types primitifs ou des formats différents vers des dossiers ou des préfixes distincts afin qu'ils puissent être enregistrés en tant que tables distinctes.
  • Utilisez des définitions de partition cohérentes : assurez-vous que les clés et les structures de partition sont cohérentes dans tous les dossiers de partition (par exemple, en utilisant systématiquement Year=YYYY/Month=MM/).
  • Suivez les règles d'évolution du schéma: lorsque vous mettez à jour des schémas (par exemple, en ajoutant ou en supprimant des champs dans des fichiers Avro), définissez toujours des valeurs par défaut afin que le service de découverte puisse fusionner correctement les variantes de schéma.
  • Identifiez les fichiers corrompus: Vérifiez le résultat ou les journaux de l'analyse pour déterminer si un fichier particulier ne parvient pas à être décodé. Déplacez temporairement les fichiers pour déterminer si un fichier spécifique est à l'origine de l'échec de l'analyse.

Les tables découvertes ne sont pas mises à jour avec les modifications de schéma

Après avoir modifié des fichiers dans Cloud Storage ou exécuté une nouvelle analyse, le schéma mis à jour n'est pas reflété dans les tables BigQuery publiées.

Ce problème se produit si le libellé metadata-managed-mode de la table publiée est défini sur user_managed. Par défaut, la découverte publie les tables en tant que discovery_managed. Si vous ou un autre utilisateur modifiez manuellement les propriétés du schéma de table, vous devez remplacer le libellé par user_managed pour bloquer les mises à jour automatiques.

Pour résoudre ce problème, vérifiez les libellés de la table dans BigQuery :

  1. Dans la Google Cloud console, accédez à la page BigQuery.
  2. Dans le volet Explorateur, développez votre projet, sélectionnez l'ensemble de données, puis cliquez sur la table concernée.
  3. Cliquez sur l'onglet Détails.
  4. Dans la section Libellés, vérifiez la valeur de la clé metadata-managed-mode.

  5. Si vous souhaitez que l'analyse de découverte reprenne la gestion et la mise à jour du schéma, cliquez sur Modifier les détails, puis remplacez la valeur par discovery_managed.

Obtenir de l'aide

Si vous avez besoin d'aide pour résoudre un problème qui n'est pas abordé dans ce document, contactez l'assistance client Cloud.