Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Problèmes connus pour AWS Lake Formation
Passez en revue ces problèmes connus pour AWS Lake Formation.
**Topics**
+ [Limitation du filtrage des métadonnées des tables](#issue-table-metadata-avro)
+ [Problème lié au changement de nom d'une colonne exclue](#issue-rename-column)
+ [Problème lié à la suppression de colonnes dans les tableaux CSV](#issue-csv-schema)
+ [Les partitions de table doivent être ajoutées sous un chemin commun](#issue-table-partitions)
+ [Problème lié à la création d'une base de données pendant la création du flux de travail](#issue-create-table-permission)
+ [Problème lié à la suppression puis à la recréation d'un utilisateur](#issue-recreate-user)
+ [Les opérations de l'API Data Catalog ne mettent pas à jour la valeur du `IsRegisteredWithLakeFormation` paramètre](#issue-get-tables-parameter)
+ [Les opérations de Lake Formation ne prennent pas en charge AWS Glue le registre des schémas](#not-support-GlueSchemaRegistry.title)
## Limitation du filtrage des métadonnées des tables
AWS Lake Formation les autorisations au niveau des colonnes peuvent être utilisées pour restreindre l'accès à des colonnes spécifiques d'un tableau. Lorsqu'un utilisateur extrait des métadonnées relatives à la table à l'aide de la console ou d'une API similaire`glue:GetTable`, la liste des colonnes de l'objet de table contient uniquement les champs auxquels il a accès. Il est important de comprendre les limites de ce filtrage des métadonnées.
Bien que Lake Formation mette à disposition des métadonnées relatives aux autorisations des colonnes pour les services intégrés, le filtrage des colonnes dans les réponses aux requêtes relève de la responsabilité du service intégré. Les clients de Lake Formation qui prennent en charge le filtrage au niveau des colonnes, notamment Amazon Athena, Amazon Redshift Spectrum et Amazon EMR, filtrent les données en fonction des autorisations de colonne enregistrées auprès de Lake Formation. Les utilisateurs ne pourront pas lire les données auxquelles ils ne devraient pas avoir accès. Actuellement, l'AWS GlueETL ne prend pas en charge le filtrage des colonnes.
**Note**
Les clusters EMR ne sont pas entièrement gérés par. AWS Il est donc de la responsabilité des administrateurs EMR de sécuriser correctement les clusters afin d'éviter tout accès non autorisé aux données.
Certaines applications ou certains formats peuvent stocker des métadonnées supplémentaires, notamment des noms et des types de colonnes, dans la `Parameters` carte sous forme de propriétés de table. Ces propriétés sont renvoyées telles quelles et sont accessibles à tous les utilisateurs `SELECT` autorisés sur n'importe quelle colonne.
Par exemple, l'[Avro SerDe](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html) stocke une représentation JSON du schéma de table dans une propriété de table nommée`avro.schema.literal`, qui est accessible à tous les utilisateurs ayant accès à la table. Nous vous recommandons d'éviter de stocker des informations sensibles dans les propriétés des tables et de savoir que les utilisateurs peuvent apprendre le schéma complet des tables au format Avro. Cette limitation est spécifique aux métadonnées relatives à une table.
AWS Lake Formation supprime toute propriété de table en commençant par « `spark.sql.sources.schema` lors de la réponse à une demande `glue:GetTable` ou à une demande similaire » si l'appelant n'a pas d'`SELECT`autorisations sur toutes les colonnes de la table. Cela empêche les utilisateurs d'accéder à des métadonnées supplémentaires concernant les tables créées avec Apache Spark. Lorsqu'elles sont exécutées sur Amazon EMR, les applications Apache Spark peuvent toujours lire ces tables, mais certaines optimisations risquent de ne pas être appliquées et les noms de colonnes distinguant majuscules et minuscules ne sont pas pris en charge. Si l'utilisateur a accès à toutes les colonnes de la table, Lake Formation renvoie la table non modifiée avec toutes les propriétés de la table.
## Problème lié au changement de nom d'une colonne exclue
Si vous utilisez des autorisations au niveau des colonnes pour exclure une colonne puis renommer la colonne, celle-ci n'est plus exclue des requêtes, telles que. `SELECT *`
## Problème lié à la suppression de colonnes dans les tableaux CSV
Si vous créez une table de catalogue de données au format CSV, puis que vous supprimez une colonne du schéma, les requêtes peuvent renvoyer des données erronées et les autorisations au niveau des colonnes risquent de ne pas être respectées.
Solution : créez plutôt une nouvelle table.
## Les partitions de table doivent être ajoutées sous un chemin commun
Lake Formation s'attend à ce que toutes les partitions d'une table suivent un chemin commun défini dans le champ d'emplacement de la table. Lorsque vous utilisez le robot pour ajouter des partitions à un catalogue, cela fonctionne parfaitement. Mais si vous ajoutez des partitions manuellement et que ces partitions ne se trouvent pas à l'emplacement défini dans la table parent, l'accès aux données ne fonctionne pas.
## Problème lié à la création d'une base de données pendant la création du flux de travail
Lorsque vous créez un flux de travail à partir d'un plan à l'aide de la console Lake Formation, vous pouvez créer la base de données cible si elle n'existe pas. Dans ce cas, l'utilisateur connecté obtient l'`CREATE_TABLE`autorisation d'accéder à la base de données créée. Cependant, le robot généré par le flux de travail assume le rôle du flux de travail lorsqu'il tente de créer une table. Cela échoue car le rôle n'a pas l'`CREATE_TABLE`autorisation d'accéder à la base de données.
Solution : Si vous créez la base de données via la console lors de la configuration du flux de travail, avant d'exécuter le flux de travail, vous devez accorder au rôle associé au flux de travail l'`CREATE_TABLE`autorisation sur la base de données que vous venez de créer.
## Problème lié à la suppression puis à la recréation d'un utilisateur
Le scénario suivant se traduit par des autorisations erronées de Lake Formation renvoyées par `lakeformation:ListPermissions` :
1. Créez un utilisateur et accordez les autorisations de Lake Formation.
1. Supprimez l’utilisateur.
1. Recréez l'utilisateur portant le même nom.
`ListPermissions`renvoie deux entrées, une pour l'ancien utilisateur et une pour le nouvel utilisateur. Si vous essayez de révoquer les autorisations accordées à l'ancien utilisateur, les autorisations sont révoquées pour le nouvel utilisateur.
## Les opérations de l'API Data Catalog ne mettent pas à jour la valeur du `IsRegisteredWithLakeFormation` paramètre
Il existe une limite connue selon laquelle les opérations de l'API du catalogue de données, telles que `GetTables` la mise à jour ou non de la valeur du `IsRegisteredWithLakeFormation` paramètre, renvoient la valeur par défaut, qui est fausse. `SearchTables` Il est recommandé d'utiliser l'`GetTable`API pour afficher la valeur correcte du `IsRegisteredWithLakeFormation` paramètre.
## Les opérations de Lake Formation ne prennent pas en charge AWS Glue le registre des schémas
Les opérations de Lake Formation ne prennent pas en charge AWS Glue les tables contenant un `SchemaReference` dans le `StorageDescriptor` à utiliser dans le [registre des schémas.](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)