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.

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 similaireglue: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.

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 stocke une représentation JSON du schéma de table dans une propriété de table nomméeavro.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'SELECTautorisations 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_TABLEautorisation 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_TABLEautorisation 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_TABLEautorisation 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 :

ListPermissionsrenvoie 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.

GetTableset SearchTables les API 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 la mise à jour GetTables et SearchTables la non-mise à jour de la valeur deIsRegisteredWithLakeFormation parameter, renvoient la valeur par défaut, qui est fausse. Il est recommandé d'utiliser l'GetTableAPI pour afficher la valeur correcte pourIsRegisteredWithLakeFormation parameter.

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'GetTableAPI 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.