Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Revise estos problemas conocidos para ver si AWS Lake Formation.
Temas
Limitación del filtrado de metadatos de las tablas
AWS Lake Formation los permisos a nivel de columna se pueden usar para restringir el acceso a columnas específicas de una tabla. Cuando un usuario recupera metadatos sobre la tabla utilizando la consola o una API como glue:GetTable, la lista de columnas del objeto de tabla contiene solo los campos a los que tiene acceso. Es importante comprender las limitaciones de este filtrado de metadatos.
Aunque Lake Formation pone a disposición de los servicios integrados metadatos sobre los permisos de las columnas, el filtrado real de las columnas en las respuestas a las consultas es responsabilidad del servicio integrado. Los clientes de Lake Formation compatibles con el filtrado a nivel de columna, incluidos Amazon Athena, Amazon Redshift Spectrum y Amazon EMR, filtran los datos en función de los permisos de columna registrados en Lake Formation. Los usuarios no podrán leer datos a los que no deberían tener acceso. En la actualidad, AWS Glue ETL no admite el filtrado de columnas.
nota
Los clústeres de EMR no se administran completamente mediante AWS. Por lo tanto, es responsabilidad de los administradores de los EMR asegurar adecuadamente los clústeres para evitar el acceso no autorizado a los datos.
Algunas aplicaciones o formatos pueden almacenar metadatos adicionales, incluidos los nombres y tipos de las columnas, en el mapa de Parameters como propiedades de la tabla. Estas propiedades se devuelven sin modificar y son accesibles por cualquier usuario con permiso de SELECT sobre cualquier columna.
Por ejemplo, el Avro SerDe almacena una representación en JSON del esquema de la tabla en una propiedad de tabla denominadaavro.schema.literal, que está disponible para todos los usuarios con acceso a la tabla. Le recomendamos que evite almacenar información sensible en las propiedades de las tablas y que sea consciente de que los usuarios pueden conocer el esquema completo de las tablas con formato Avro. Esta limitación es específica de los metadatos sobre una tabla.
AWS Lake Formation elimina cualquier propiedad de la tabla, empezando por spark.sql.sources.schema cuando responde a una solicitud glue:GetTable o similar, si la persona que llama no tiene SELECT permisos en todas las columnas de la tabla. Esto impide a los usuarios acceder a metadatos adicionales sobre tablas creadas con Apache Spark. Cuando se ejecutan en Amazon EMR, las aplicaciones Apache Spark siguen pudiendo leer estas tablas, pero es posible que no se apliquen ciertas optimizaciones y que no se admitan los nombres de columnas que distinguen entre mayúsculas y minúsculas. Si el usuario tiene acceso a todas las columnas de la tabla, Lake Formation devuelve la tabla sin modificar con todas las propiedades de la tabla.
Problema al renombrar una columna excluida
Si utiliza permisos a nivel de columna para excluir una columna y, a continuación, cambia el nombre de la columna, esta dejará de estar excluida de las consultas, como SELECT *.
Problema con la eliminación de columnas en tablas CSV
Si crea una tabla del Catálogo de datos con el formato CSV y luego elimina una columna del esquema, las consultas podrían devolver datos erróneos y es posible que no se respeten los permisos a nivel de columna.
Solución alternativa: cree una tabla nueva en su lugar.
Las particiones de tabla deben añadirse bajo una ruta común
Lake Formation espera que todas las particiones de una tabla estén bajo una ruta común que se establece en el campo de ubicación de la tabla. Cuando utilice el rastreador para añadir particiones a un catálogo, esto funcionará sin problemas. Pero si añade particiones manualmente, y estas particiones no están bajo la ubicación establecida en la tabla principal, el acceso a los datos no funciona.
Problema con la creación de una base de datos durante la creación del flujo de trabajo
Al crear un flujo de trabajo a partir de un esquema utilizando la consola de Lake Formation, puede crear la base de datos de destino si no existe. Al hacerlo, el usuario que ha iniciado sesión obtiene el permiso de CREATE_TABLE sobre la base de datos creada. Sin embargo, el rastreador que genera el flujo de trabajo asume el papel de este cuando intenta crear una tabla. Esto produce un error porque el rol no tiene el permiso CREATE_TABLE en la base de datos.
Solución: si crea la base de datos a través de la consola durante la configuración del flujo de trabajo, antes de ejecutar el flujo de trabajo, debe dar al rol asociado al flujo de trabajo el permiso CREATE_TABLE sobre la base de datos que acaba de crear.
Problema al eliminar un usuario y, a continuación, volver a crearlo
El siguiente escenario da como resultado permisos erróneos de Lake Formation devueltos por lakeformation:ListPermissions:
-
Cree un usuario y conceda permisos a Lake Formation.
-
Elimine el usuario.
-
Vuelva a crear el usuario con el mismo nombre.
ListPermissions devuelve dos entradas, una para el usuario anterior y otra para el usuario nuevo. Si intenta revocar los permisos concedidos al usuario anterior, se revocan los permisos del nuevo usuario.
Las operaciones de la API del Catálogo de datos no actualizan el valor del parámetro IsRegisteredWithLakeFormation
Existe una limitación conocida por la que las operaciones de la API del Catálogo de datos como GetTables y SearchTables no actualizan el valor del parámetro IsRegisteredWithLakeFormation y devuelven el valor predeterminado, que es falso. Se recomienda utilizar la APIGetTable para ver el valor correcto del parámetro IsRegisteredWithLakeFormation.
Las operaciones de Lake Formation no admiten el registro AWS Glue de esquemas
Las operaciones de Lake Formation no admiten AWS Glue tablas que contengan un SchemaReference en el StorageDescriptor para utilizarlas en el Registro de esquemas.
