Vous pouvez diagnostiquer et résoudre les erreurs dans Lakehouse sans frontières et ses ressources associées, y compris les problèmes liés aux requêtes de table de métadonnées, aux limites de taille de fichier metadata.json et aux configurations de catalogue multirégionales.
La résolution de ces problèmes vous aide à restaurer les opérations sur les tables et l'exécution des requêtes dans vos charges de travail Lakehouse.
Impossible d'interroger les tables de métadonnées
Ce problème se produit lorsque vous interrogez des tables de métadonnées, telles que .snapshots ou .files, pour vos tables Apache Iceberg compatibles avec le catalogue d'environnements d'exécution Lakehouse dans BigQuery à l'aide d'un identifiant de nom en cinq parties.
Pour résoudre ce problème, interrogez ces tables à l'aide d'Apache Spark.
Taille maximale du fichier metadata.json
La taille du fichier metadata.json Apache Iceberg est limitée à 1 Mo. Cette limite s'applique au fichier de métadonnées qui suit les instantanés de table, les schémas et les spécifications de partition. Si votre fichier de métadonnées dépasse cette taille, vous risquez de rencontrer des erreurs lors de l'exécution d'opérations sur les tables via le point de terminaison du catalogue REST Apache Iceberg.
Pour résoudre ce problème, demandez une augmentation de la limite en contactant l'équipe chargée de votre compte Google.
Erreurs NOT_FOUND lors de l'interrogation de catalogues multirégionaux
Ce problème se produit lorsque vous créez un catalogue dans le catalogue d'environnements d'exécution Lakehouse à l'aide d'un bucket Cloud Storage multirégional sans spécifier d'emplacement principal, puis que vous tentez d'interroger le catalogue en spécifiant une région virtuelle BigQuery (telle que US ou EU).
Lorsqu'un catalogue est créé avec un bucket multirégional, ses métadonnées sont stockées dans des emplacements régionaux spécifiques au sein de la zone géographique de l'emplacement multirégional, plutôt que dans la région virtuelle BigQuery correspondante. Si vous forcez l'exécution d'une requête dans une région virtuelle où les métadonnées ne sont pas présentes, la requête échoue avec une erreur NOT_FOUND.
Pour résoudre ce problème, spécifiez l'emplacement principal (par exemple, US ou EU) lorsque vous créez le catalogue. Pour en savoir plus, consultez Spécifier des régions principales pour les emplacements multirégionaux aux États-Unis et dans l'UE.
Les jobs d'optimisation du stockage n'apparaissent pas dans INFORMATION_SCHEMA.JOBS
Ce problème se produit lorsque vous activez la gestion des tables sur une table Apache Iceberg et que vous effectuez des mutations de données (telles que des insertions ou des instructions LMD), mais qu'aucun job d'optimisation du stockage (tel que CALL BQ.OPTIMIZE_STORAGE) n'apparaît dans la vue INFORMATION_SCHEMA.JOBS. Pour en savoir plus sur l'interrogation de ces jobs, consultez Obtenir des jobs d'optimisation du stockage Iceberg.
Ce comportement est normal lorsque l'optimisation du stockage est ignorée. La gestion des tables évalue la mise en page des tables après les mutations de données et n'exécute les jobs d'optimisation que lorsque les fichiers de données nécessitent un compactage ou une restructuration. Étant donné que les jobs de gestion des tables en arrière-plan s'exécutent dans votre projet et consomment des ressources de calcul, BigQuery ne réécrit pas les données lorsque la mise en page de la table est déjà optimisée. L'optimisation est ignorée dans les conditions suivantes :
- Les fichiers sont déjà optimaux : les fichiers de données existants sont déjà proches de la taille de fichier cible ou la dépassent (la taille moyenne non compressée est d'au moins 50 % de 256 Mo).
- Les seuils ne sont pas atteints : la table n'a pas accumulé suffisamment de petits fichiers ou n'atteint pas le seuil de taille (par exemple, une taille totale de table supérieure à 1 Go) requis pour le compactage.
Lorsque l'optimisation du stockage est ignorée, aucune tâche en arrière-plan n'est exécutée et aucune entrée n'est consignée dans INFORMATION_SCHEMA.JOBS.
Si les performances des requêtes répondent à vos exigences et que les fichiers sont déjà correctement dimensionnés, aucune action n'est requise. L'optimisation du stockage s'exécute automatiquement lorsque les écritures futures entraînent une fragmentation suffisante des fichiers.
Pour observer les jobs d'optimisation du stockage dans un environnement de test, simulez la fragmentation des fichiers en insérant plusieurs petits lots de données au fil du temps dans une table d'une taille supérieure à 1 Go.