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. # Creación de objetos en el AWS Glue Data Catalog AWS Lake Formation utiliza el AWS Glue Data Catalog (catálogo de datos) para almacenar metadatos sobre lagos de datos, fuentes de datos, transformaciones y destinos. Los metadatos son datos sobre los datos subyacentes del conjunto de datos. Cada AWS cuenta tiene un catálogo de datos por AWS región. Los metadatos del Catálogo de datos se organizan en una jerarquía de datos de tres niveles que incluye catálogos, bases de datos y tablas. Organiza los datos de diversos orígenes en contenedores lógicos denominados catálogos. Cada catálogo representa datos de orígenes como los almacenes de datos de Amazon Redshift, bases de datos Amazon DynamoDB y orígenes de datos de terceros, como Snowflake, MySQL y más de 30 orígenes de datos externos, que se integran mediante conectores federados. También puede crear catálogos nuevos en el Catálogo de datos para almacenar datos en buckets de tablas de S3 o en Redshift Managed Storage (RMS). Las tablas almacenan información sobre los datos subyacentes, incluida la información sobre esquemas, particiones y ubicaciones de datos. Las bases de datos son colecciones de tablas. El Catálogo de datos también contiene enlaces a recursos, que son enlaces a catálogos, bases de datos y tablas compartidas en cuentas externas, y se utilizan para el acceso entre cuentas a los datos del lago de datos. El Catálogo de datos es un objeto de catálogo anidado que contiene catálogos, bases de datos y tablas. Se hace referencia a él mediante el Cuenta de AWS ID y es el catálogo predeterminado de una cuenta y un Región de AWS. El Catálogo de datos utiliza una jerarquía de tres niveles (catalog.database.table) para organizar las tablas. + Catálogo: el nivel más alto de la jerarquía de metadatos de tres niveles del Catálogo de datos. Puede agregar varios catálogos a un Catálogo de datos mediante la federación. + Base de datos: el segundo nivel de la jerarquía de metadatos que consta de tablas y vistas. Una base de datos también se denomina esquema en muchos sistemas de datos, como Amazon Redshift y Trino. + Tabla y vista: el tercer nivel de la jerarquía de datos de tres niveles del Catálogo de datos. Todas las tablas Iceberg de Amazon S3 se almacenan en el catálogo de datos predeterminado con un ID de catálogo = Cuenta de AWS ID. Puede crear catálogos federados AWS Glue Data Catalog que almacenen definiciones de tablas en Amazon Redshift, Amazon S3 Table Storage u otras fuentes de datos de terceros mediante la federación. **Topics** + [Creación de un catálogo](creating-catalog.md) + [Creación de una base de datos](creating-database.md) + [Creación de tablas](creating-tables.md) + [AWS Glue Data Catalog Vistas del edificio](working-with-views.md) # Creación de un catálogo Los catálogos representan el nivel más alto o primer nivel de la jerarquía de metadatos de tres niveles del AWS Glue Data Catalog. Puede utilizar varios métodos para incorporar datos al Catálogo de datos y crear catálogos de varios niveles. Para obtener más información sobre la creación de catálogos a partir de orígenes de datos externos, consulte [Llevar sus datos al AWS Glue Data Catalog](bring-your-data-overview.md). Para crear una base de datos mediante la consola de Lake Formation, debe iniciar sesión como administrador de lago de datos o *creador de catálogo*. Un creador de catálogo es una entidad principal a la que se le ha otorgado el permiso `CREATE_CATALOG` de Lake Formation. Puede ver una lista de los creadores de catálogos en la página **Roles y tareas administrativas** de la consola de Lake Formation. Para ver esta lista, debe tener el permiso `lakeformation:ListPermissions` de IAM e iniciar sesión como administrador de lago de datos o como creador de catálogo con la opción de conceder el permiso `CREATE_CATALOG`. # Creación de una base de datos Las tablas de metadatos del Catálogo de datos se almacenan en una base de datos. Puede crear tantas bases de datos como necesite, y conceder diferentes permisos de Lake Formation en cada base de datos. Las bases de datos pueden tener una propiedad de ubicación opcional. Esta ubicación suele estar dentro de una ubicación de Amazon Simple Storage Service (Amazon S3) registrada en Lake Formation. Cuando se especifica una ubicación, las entidades principales no necesitan permisos de ubicación de datos para crear tablas del Catálogo de datos que apunten a ubicaciones dentro de la ubicación de la base de datos. Para obtener más información, consulte [Underlying data access control](access-control-underlying-data.md#data-location-permissions). Para crear una base de datos mediante la consola de Lake Formation, debe iniciar sesión como administrador del lago de datos o *creador de la base de datos*. El creador de una base de datos es una entidad principal a la que se le ha otorgado el permiso de `CREATE_DATABASE` de Lake Formation. Puede ver una lista de los creadores de bases de datos en la página **Roles y tareas administrativas** de la consola de Lake Formation. Para ver esta lista, debe tener el permiso de `lakeformation:ListPermissions` IAM e iniciar sesión como administrador de un lago de datos o como creador de bases de datos con la opción de conceder el permiso `CREATE_DATABASE`. **Para crear una base de datos** 1. Abra la AWS Lake Formation consola en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)e inicie sesión como administrador de un lago de datos o creador de bases de datos. 1. En el panel de navegación, bajo **Catálogo de datos**, elija **Bases de datos**. 1. Elija **Creación de base de datos**. 1. En el cuadro de diálogo **Crear base de datos**, introduzca un nombre de base de datos, una ubicación opcional y una descripción opcional. 1. Seleccione de forma opcional **Utilizar solo el control de acceso IAM para las nuevas tablas de esta base de datos**. Para obtener más información acerca de esta opción, consulte [Cambiar la configuración predeterminada de su lago de datos](change-settings.md). 1. Elija **Creación de base de datos**. # Creación de tablas AWS Lake Formation las tablas de metadatos contienen información sobre los datos del lago de datos, incluida la información del esquema, la información de particiones y la ubicación de los datos. Estas tablas se almacenan en el Catálogo de datos de AWS Glue. Se utilizan para acceder a los datos subyacentes del lago de datos y administrarlos con los permisos de Lake Formation. Las tablas se almacenan dentro de bases de datos en el Catálogo de datos. Hay varias formas de crear tablas del Catálogo de datos: + Ejecutar un rastreador en AWS Glue. Consulte [Definición de rastreadores](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html) en la *Guía para desarrolladores de AWS Glue *. + Crear y ejecutar un flujo de trabajo. Consulte [Importación de datos mediante flujos de trabajo en Lake Formation](workflows.md). + Cree una tabla manualmente utilizando la consola de Lake Formation, la API de AWS Glue o la AWS Command Line Interface (AWS CLI). + Cree una tabla con Amazon Athena. + Crea un enlace de recurso a una tabla en una cuenta externa. Consulte [Creación de enlaces de recursos](creating-resource-links.md). # Creación de tablas de Apache Iceberg AWS Lake Formation admite la creación de tablas Apache Iceberg que utilizan el formato de datos Apache Parquet AWS Glue Data Catalog con datos que residen en Amazon S3. Una tabla en el Catálogo de datos es la definición de metadatos que representa los datos en un almacén de datos. De forma predeterminada, Lake Formation crea tablas Iceberg v2. Para ver la diferencia entre las tablas v1 y v2, consulte [Cambios de versión de formato](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) en la documentación de Apache Iceberg. [Apache Iceberg](https://iceberg.apache.org/) es un formato de tabla abierto para conjuntos de datos analíticos muy grandes. Iceberg permite modificar fácilmente su esquema, o evolución del esquema, de manera que los usuarios pueden añadir, renombrar o eliminar columnas de una tabla de datos sin alterar los datos subyacentes. Iceberg también ofrece compatibilidad con el control de versiones de datos, que permite a los usuarios hacer un seguimiento de los cambios en los datos a lo largo del tiempo. Esto habilita la característica de viaje en el tiempo, con la que los usuarios pueden acceder a versiones históricas de los datos y consultarlas, así como analizar los cambios en los datos entre actualizaciones y eliminaciones. Puede usar la consola de Lake Formation o la `CreateTable` operación de la AWS Glue API para crear una tabla Iceberg en el catálogo de datos. Para obtener más información, consulte [CreateTable action (Python: create\$1table](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)). Cuando cree una tabla de Iceberg en el Catálogo de datos, deberá especificar el formato de la tabla y la ruta del archivo de metadatos en Amazon S3 para poder hacer lecturas y escrituras. Puede usar Lake Formation para proteger su mesa de iceberg mediante permisos de control de acceso detallados al registrar la ubicación de datos de Amazon S3. AWS Lake Formation En el caso de los datos fuente de Amazon S3 y los metadatos que no estén registrados en Lake Formation, el acceso viene determinado por las políticas de permisos y AWS Glue acciones de IAM para Amazon S3. Para obtener más información, consulte [Administrar los permisos de Lake Formation](managing-permissions.md). **nota** El Catálogo de datos no admite la creación de particiones ni la adición de propiedades de tablas de iceberg. **Topics** + [Requisitos previos](#iceberg-prerequisites) + [Creación de tablas de Iceberg](#create-iceberg-table) ## Requisitos previos Para crear tablas de Iceberg en el Catálogo de datos y configurar los permisos de acceso a los datos de Lake Formation, debe cumplir los siguientes requisitos: 1. **Se requieren permisos para crear tablas de Iceberg sin datos registrados en Lake Formation.** Además de los permisos necesarios para crear una tabla en el Catálogo de datos, el creador de la tabla requiere los siguientes permisos: + `s3:PutObject` en el recurso arn:aws:s3:::\$1bucketName\$1 + `s3:GetObject` en el recurso arn:aws:s3:::\$1bucketName\$1 + `s3:DeleteObject` en el recurso arn:aws:s3:::\$1bucketName\$1 1. **Se requieren permisos para crear tablas de Iceberg con datos registrados en Lake Formation:** Para utilizar Lake Formation para administrar y asegurar los datos de su lago de datos, registre su ubicación de Amazon S3 que tiene los datos de las tablas con Lake Formation. Esto es para que Lake Formation pueda vender credenciales a servicios AWS analíticos como Athena, Redshift Spectrum y Amazon EMR para acceder a los datos. Para obtener más información sobre el registro de una ubicación de Amazon S3, consulte [Añadir una ubicación de Amazon S3 a su lago de datos](register-data-lake.md). Una entidad principal que lee y escribe los datos subyacentes que están registrados en Lake Formation requiere los siguientes permisos: + `lakeformation:GetDataAccess` + `DATA_LOCATION_ACCESS` Una entidad principal que tiene permisos de localización de datos en una localización también tiene permisos de localización en todas las ubicaciones secundarias. Para obtener más información sobre permisos de ubicación de datos, consulte [Control de acceso a los datos subyacentes](access-control-underlying-data.md). Para habilitar la compactación, el servicio debe asumir un rol de IAM que tenga permisos para actualizar las tablas del Catálogo de datos. Para obtener más información, consulte [Requisitos previos para la optimización de tablas](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html). ## Creación de tablas de Iceberg Puede crear tablas Iceberg v1 y v2 con la consola Lake Formation o AWS Command Line Interface tal como se documenta en esta página. También puede crear tablas Iceberg utilizando la AWS Glue consola o. Rastreador de AWS Glue Para más información, consulte [Catálogo de datos y rastreadores](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html) en la Guía para desarrolladores de AWS Glue . **Creación de una tabla de Iceberg** ------ #### [ Console ] 1. Inicie sesión en y abra la Consola de administración de AWS consola de Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). 1. En Catálogo de datos, seleccione **Tablas** y utilice el botón **Crear tabla** para especificar los siguientes atributos: + **Nombre de tabla.** Escriba un nombre para la tabla. Si utiliza Athena para acceder a las tablas, utilice los [consejos para nombres](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html) recogidos en la Guía del usuario de Amazon Athena. + **Base de datos.** Elija una base de datos existente o cree una nueva. + **Descripción.** Descripción de la tabla. Puede escribir una descripción para ayudarle a entender el contenido de la tabla. + **Formato de tabla.** Para el **formato de la tabla**, elija Apache Iceberg. ![\[Opción de tabla de Apache Iceberg y opciones de optimización de tablas seleccionadas\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/table-optimization.png) + **Optimización de tablas** + **Compactación**: los archivos de datos se combinan y se reescriben para eliminar los datos obsoletos y consolidar los datos fragmentados en archivos más grandes y eficientes. + **Retención de instantáneas**: las instantáneas son versiones con fecha y hora de una tabla de Iceberg. Las configuraciones de retención de instantáneas permiten a los clientes determinar cuánto tiempo se deben retener las instantáneas y cuántas instantáneas retener. La configuración de un optimizador de retención de instantáneas puede ayudar a administrar la sobrecarga de almacenamiento mediante la eliminación de las instantáneas antiguas e innecesarias y sus correspondientes archivos subyacentes. + **Eliminación de archivos huérfanos**: los archivos huérfanos son archivos a los que los metadatos de la tabla de Iceberg ya no hacen referencia. Con el tiempo, estos archivos se pueden acumular, sobre todo después de operaciones como la eliminación de tablas o los errores en los trabajos de ETL. Habilitar la eliminación de archivos huérfanos AWS Glue permite identificar y eliminar periódicamente estos archivos innecesarios, liberando espacio de almacenamiento. Para obtener más información, consulte [Optimización de las tablas de Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html). + **Rol de IAM.** Para ejecutar la compactación, el servicio asume un rol de IAM en su nombre. Puede elegir un rol de IAM mediante el menú desplegable. Asegúrese de que el rol tenga los permisos necesarios para habilitar la compactación. Para obtener más información sobre los permisos necesarios, consulte [Requisitos previos para la optimización de tablas](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html). + **Ubicación.** Especifique la ruta a la carpeta de Amazon S3 que almacena la tabla de metadatos. Iceberg necesita un archivo de metadatos y una ubicación en el Catálogo de datos para poder hacer lecturas y escrituras. + **Esquema.** Seleccione **Agregar columnas** para añadir columnas y tipos de datos de las columnas. Tiene la opción de crear una tabla vacía y actualizar el esquema más adelante. El Catálogo de datos admite los tipos de datos de Hive. Para obtener más información, consulte [Tipos de datos de Hive](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462). Con Iceberg podrá desarrollar el esquema y la partición después de crear la tabla. Puede utilizar [consultas de Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) para actualizar el esquema de la tabla y [consultas de Spark](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) para actualizar las particiones. ------ #### [ AWS CLI ] ``` aws glue create-table \ --database-name iceberg-db \ --region us-west-2 \ --open-table-format-input '{ "IcebergInput": { "MetadataOperation": "CREATE", "Version": "2" } }' \ --table-input '{"Name":"test-iceberg-input-demo", "TableType": "EXTERNAL_TABLE", "StorageDescriptor":{ "Columns":[ {"Name":"col1", "Type":"int"}, {"Name":"col2", "Type":"int"}, {"Name":"col3", "Type":"string"} ], "Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/" } }' ``` ------ # Optimización de las tablas de Iceberg Lake Formation admite múltiples opciones de optimización de tablas para mejorar la administración y el rendimiento de las tablas Apache Iceberg utilizadas por los motores AWS analíticos y los trabajos de ETL. Estos optimizadores ofrecen un uso eficiente del almacenamiento, un rendimiento mejorado de las consultas y la administración efectiva de los datos. Existen tres tipos de optimizadores de tablas disponibles en Lake Formation: + **Compactación**: la compactación de datos compacta archivos de datos pequeños para reducir el uso de almacenamiento y mejorar el rendimiento de lectura. Los archivos de datos se combinan y se reescriben para eliminar los datos obsoletos y consolidar los datos fragmentados en archivos más grandes y eficientes. La compactación se puede configurar para que se ejecute de forma automática o manual según sea necesario. + **Retención de instantáneas**: las instantáneas son versiones con fecha y hora de una tabla de Iceberg. Las configuraciones de retención de instantáneas permiten a los clientes determinar cuánto tiempo se deben retener las instantáneas y cuántas instantáneas retener. La configuración de un optimizador de retención de instantáneas puede ayudar a administrar la sobrecarga de almacenamiento mediante la eliminación de las instantáneas antiguas e innecesarias y sus correspondientes archivos subyacentes. + **Eliminación de archivos huérfanos**: los archivos huérfanos son archivos a los que los metadatos de la tabla de Iceberg ya no hacen referencia. Con el tiempo, estos archivos se pueden acumular, sobre todo después de operaciones como la eliminación de tablas o los errores en los trabajos de ETL. Habilitar la eliminación de archivos huérfanos AWS Glue permite identificar y eliminar periódicamente estos archivos innecesarios, liberando espacio de almacenamiento. Puede activar o desactivar los optimizadores de compactación, retención de instantáneas y eliminación de archivos huérfanos para tablas Iceberg individuales del catálogo de datos mediante la AWS Glue consola o las operaciones de la API. AWS CLI AWS Glue Para obtener más información, consulte [Optimización de las tablas Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html) en la Guía para desarrolladores. AWS Glue # Búsqueda de tablas Puede usar la AWS Lake Formation consola para buscar tablas del catálogo de datos por nombre, ubicación, base de datos contenedora, etc. Los resultados de la búsqueda muestran solo las tablas en las que tiene permisos de Lake Formation. **Para buscar tablas (consola)** 1. Inicie sesión en la consola de Lake Formation Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). 1. En el panel de navegación, elija **Tablas**. 1. Coloque el cursor en el campo de búsqueda en la parte superior de la página. El campo tiene el texto marcador de posición *Buscar tabla por propiedades*. Aparece el menú **Propiedades**, que muestra las distintas propiedades de la tabla por las que buscar. ![\[El menú de propiedades se despliega desde el campo de búsqueda y contiene las siguientes entradas: nombre, clasificación, base de datos, ubicación e identificador de catálogo\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/search-for-tables.png) 1. Realice una de las siguientes acciones: + Buscar por base de datos contenedora. 1. Seleccione **Base de datos** en el menú **Propiedades** y, a continuación, elija una base de datos en el menú **Bases** de datos que aparece o escriba un nombre de base de datos y pulse **Intro**. Se muestran las tablas sobre las que tiene permisos en la base de datos. 1. (Opcional) Para reducir la lista a una sola tabla de la base de datos, vuelva a colocar el cursor en el campo de búsqueda, elija **Nombre** en el menú **Propiedades** y elija un nombre de tabla en el menú **Tablas** que aparece o escriba un nombre de tabla y pulse **Intro**. Aparece la tabla individual y tanto el nombre de la base de datos como el nombre de la tabla aparecen como mosaicos debajo del campo de búsqueda. ![\[Debajo del campo de búsqueda hay dos mosaicos, Base de datos, que muestra el nombre de la base de datos seleccionada, y otro denominado Tabla, con el nombre de la tabla seleccionada. A la derecha de los mosaicos hay un botón para borrar el filtro.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/search-for-tables-with-filter.png) Para ajustar el filtro, cierre cualquiera de los mosaicos o seleccione **Borrar filtro**. + Busque por otras propiedades. 1. Seleccione una propiedad de búsqueda en el menú **Propiedades**. **Para buscar por ID de AWS cuenta, elija **ID de catálogo** en el menú **Propiedades**, introduzca un ID de AWS cuenta válido (por ejemplo, 111122223333) y pulse Entrar.** Para buscar por ubicación, elija **Ubicación** en el menú **Propiedades** y seleccione una en el menú **Ubicaciones** que aparece. Se devuelven todas las tablas de la ubicación raíz de la ubicación seleccionada (por ejemplo, Amazon S3). **Para buscar tablas, utilice AWS CLI** + En el siguiente ejemplo, se muestra cómo ejecutar una búsqueda parcial. El parámetro `--search-text` permite buscar tablas que contengan el texto especificado en sus metadatos. En este caso, devuelve todas las tablas que tienen la palabra “customer” en el nombre, la descripción u otros campos de metadatos. ``` aws glue search-tables --search-text "customer" --region Región de AWS --max-results 10 --sort-criteria "FieldName=Name,Sort=ASC" ``` # Compartir tablas y bases de datos del catálogo de datos entre AWS cuentas Puede compartir los recursos del catálogo de datos (bases de datos y tablas) con AWS cuentas externas concediendo permisos de Lake Formation sobre los recursos a las cuentas externas. A continuación, los usuarios pueden ejecutar consultas y trabajos para unir y consultar tablas en varias cuentas. Con algunas restricciones, cuando comparte un recurso del Catálogo de datos con otra cuenta, las entidades principales de esa cuenta pueden operar con ese recurso como si estuviera en su Catálogo de datos. No comparte los recursos con directores específicos en AWS cuentas externas, sino que comparte los recursos con una AWS cuenta u organización. Cuando comparte un recurso con una organización AWS , está compartiendo el recurso con todas las cuentas de todos los niveles de esa organización. A continuación, el administrador del lago de datos de cada cuenta externa debe conceder permisos sobre los recursos compartidos a las entidades principales de su cuenta. Para obtener más información, consulte [Compartir datos entre cuentas en Lake Formation](cross-account-permissions.md) y [Concesión de permisos sobre los recursos del Catálogo de datos](granting-catalog-permissions.md). **Consulte también:** [Acceso y visualización de tablas y bases de datos compartidas del Catálogo de datos](viewing-shared-resources.md) [Requisitos previos](cross-account-prereqs.md) # AWS Glue Data Catalog Vistas del edificio En el AWS Glue Data Catalog, una *vista* es una tabla virtual en la que el contenido se define mediante una consulta SQL que hace referencia a una o más tablas. Puede crear una vista de catálogo de datos que haga referencia a un máximo de 10 tablas mediante editores de SQL para Amazon Athena, Amazon Redshift o Apache Spark mediante EMR Serverless o la versión 5.0. AWS Glue Las tablas de referencia subyacentes de una vista pueden pertenecer a la misma base de datos o a bases de datos diferentes dentro del mismo Cuenta de AWS catálogo de datos. Puede hacer referencia a AWS Glue tablas estándar y tablas en formatos de tabla abierta (OTF), como [Apache Hudi](https://hudi.incubator.apache.org/), Linux Foundation [Delta Lake](https://delta.io/) y [Apache Iceberg](https://iceberg.apache.org/), con los datos subyacentes almacenados en las ubicaciones de Amazon S3 registradas en. AWS Lake Formation Además, puede crear vistas a partir de tablas federadas desde recursos compartidos de datos de Amazon Redshift que se compartan con Lake Formation. ## Diferenciación de las vistas del Catálogo de datos de otros tipos de vistas Las vistas del Catálogo de datos difieren de las vistas de Apache Hive, Apache Spark y Amazon Athena. La vista del catálogo de datos es una característica nativa de y es una vista AWS Glue Data Catalog creada por un definidor multidialecto. Puede crear una vista del Catálogo de datos utilizando uno de los servicios de análisis compatibles, como Athena o Amazon Redshift Spectrum, y acceder a la misma vista mediante otros servicios de análisis compatibles. Por otro lado, las vistas Apache Hive, Apache Spark y Athena se crean de forma independiente en cada servicio de análisis, como Athena y Amazon Redshift, y solo están visibles y accesibles dentro de dicho servicio. ## ¿Qué es una vista de definidor? Una vista de definidor es una vista SQL que opera en función de los permisos de la entidad principal que la creó. El rol de definidor tiene los permisos necesarios para obtener acceso a las tablas a las que se hace referencia y ejecuta la instrucción SQL que define la vista. El definidor crea la vista y la comparte con otros usuarios mediante AWS Lake Formation un control de acceso detallado. Cuando un usuario consulta la vista de definidor, el motor de consultas utiliza los permisos del rol de definidor para acceder a las tablas de referencia subyacentes. Este enfoque permite a los usuarios interactuar con la vista sin necesidad de acceder directamente a las tablas de origen, lo que mejora la seguridad y simplifica la administración del acceso a los datos. Para configurar una vista de definición, la función de IAM de definición puede estar en la misma AWS cuenta que las tablas base, o en una cuenta diferente mediante funciones de definición multicuenta. Para obtener más información sobre los permisos necesarios para el rol de definidor, consulte [Requisitos previos para crear vistas](views-prereqs.md). ## Un marco para vistas multidialectales El Catálogo de datos admite la creación de vistas utilizando varios dialectos de lenguaje de consultas estructurado (SQL). SQL es un lenguaje que se utiliza para almacenar y procesar información en una base de datos relacional, y cada motor de AWS análisis utiliza su propia variante de SQL, o dialecto de SQL. Puede crear una vista del Catálogo de datos en un dialecto SQL mediante uno de los motores de consulta de análisis compatibles. A continuación, puede actualizar la vista utilizando la instrucción `ALTER VIEW` en un dialecto SQL diferente en cualquier otro motor de análisis compatible. Sin embargo, cada dialecto debe hacer referencia al mismo conjunto de tablas, columnas y tipos de datos. Puede acceder a los distintos dialectos disponibles para la vista mediante la `GetTable` API y la consola. AWS CLI AWS Por lo tanto, la vista del Catálogo de datos está visible y disponible para realizar consultas en los diferentes motores de análisis compatibles. Al definir un esquema de vista y un objeto de metadatos comunes que puede consultar desde varios motores, las vistas del catálogo de datos le permiten utilizar vistas uniformes de todo el lago de datos. Para obtener más información sobre cómo se resuelve el esquema para cada dialecto, consulte el [enlace a la referencia de la API](). Para obtener más información sobre las reglas de coincidencia para los distintos tipos, consulte el [enlace a la sección correspondiente del documento de la API](). ## Integración con permisos de Lake Formation Se puede utilizar AWS Lake Formation para centralizar la administración de permisos en las AWS Glue Data Catalog vistas de los usuarios. Puede conceder permisos detallados en las vistas del catálogo de datos mediante el método de recurso indicado o las etiquetas LF y compartirlos entre organizaciones y unidades organizativas Cuentas de AWS. AWS También puede compartir las vistas del catálogo de datos y acceder a ellas mediante enlaces a recursos. Regiones de AWS Esto permite a los usuarios proporcionar acceso a los datos sin duplicar el origen de datos y compartiendo las tablas subyacentes. La declaración `CREATE VIEW` DDL de una vista de catálogo de datos puede hacer referencia a AWS Glue las tablas estándar y a las tablas en formatos de tabla abierta (OTF), como Hudi, Delta Lake e Iceberg, con datos subyacentes almacenados en ubicaciones de Amazon S3 registradas en Lake Formation, así como a las tablas federadas del datashare de Amazon Redshift que se comparten con Lake Formation. Las tablas pueden tener cualquier formato de archivo siempre que el motor utilizado para consultar la vista admita dicho formato. También puede hacer referencia a funciones integradas del motor en el que se ejecuta, aunque es posible que no se permitan otros recursos específicos del motor. Para obtener más información, consulte [Vistas, consideraciones y limitaciones del catálogo de datos](views-notes.md) ## Casos de uso A continuación se detallan los casos de uso importantes de las vistas del Catálogo de datos: + Crear y administrar permisos en un esquema de vista única. Esto le ayuda a evitar el riesgo de que se existan permisos incoherentes en vistas duplicadas creadas en varios motores. + Conceda permisos a los usuarios en una vista que haga referencia a varias tablas sin conceder permisos directamente en las tablas de referencia subyacentes. + Para filtrar las tablas a nivel de fila, utilice etiquetas LF (donde las etiquetas LF se apliquen en cascada solo en la columna) aplicando etiquetas LF en las vistas y concediendo a los usuarios permisos basados en etiquetas LF. ## AWS Servicios de análisis compatibles para las vistas Los siguientes servicios de AWS análisis admiten la creación de vistas del catálogo de datos: + Amazon Redshift + Amazon Athena versión 3 + Apache Spark en EMR sin servidor + Apache Spark en la AWS Glue versión 5.0 ## Recursos adicionales Puede obtener más información sobre el Catálogo de datos en esta guía del usuario, así como en los siguientes recursos: En el siguiente vídeo se muestra cómo crear vistas y consultarlas desde Athena y Amazon Redshift. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL) **Topics** + [Diferenciación de las vistas del Catálogo de datos de otros tipos de vistas](#diff-views) + [¿Qué es una vista de definidor?](#definer-view) + [Un marco para vistas multidialectales](#multi-dialect) + [Integración con permisos de Lake Formation](#lf-view-integ) + [Casos de uso](#views-use-cases) + [AWS Servicios de análisis compatibles para las vistas](#views-supported-engines) + [Recursos adicionales](#views-addtional-resources) + [Requisitos previos para crear vistas](views-prereqs.md) + [Creación de vistas del Catálogo de datos mediante instrucciones DDL](create-views.md) + [Creación de vistas del catálogo de datos mediante AWS Glue APIs](views-api-usage.md) + [Concesión de permisos del vistas del catálogo de datos](grant-perms-views.md) + [Vistas materializadas](materialized-views.md) # Requisitos previos para crear vistas + Para crear vistas en el catálogo de datos, debe registrar las ubicaciones de datos subyacentes de Amazon S3 de las tablas de referencia en Lake Formation. Para obtener más información sobre el registro de datos con Lake Formation, consulte[Añadir una ubicación de Amazon S3 a su lago de datos](register-data-lake.md). + Solo los roles de IAM pueden crear vistas del Catálogo de datos. Otras identidades de IAM no pueden crear vistas del catálogo de datos. + El rol de IAM que defina la vista debe tener los siguientes permisos: + Permiso `SELECT` de Lake Formation con la opción `Grantable` en todas las tablas de referencia, incluidas todas las columnas. + Permiso `CREATE_TABLE` de Lake Formation en la base de datos de destino donde se crean las vistas. + Una política de confianza para que Lake Formation y AWS Glue sus servicios asuman el cargo. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerAssumeRole1", "Effect": "Allow", "Principal": { "Service": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ + El objetivo: PassRole permiso para AWS Glue y Lake Formation. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerPassRole1", "Action": [ "iam:PassRole" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] } } } ] } ``` ------ + AWS Glue y permisos de Lake Formation. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "Glue:GetDatabase", "Glue:GetDatabases", "Glue:CreateTable", "Glue:GetTable", "Glue:GetTables", "Glue:BatchGetPartition", "Glue:GetPartitions", "Glue:GetPartition", "Glue:GetTableVersion", "Glue:GetTableVersions", "Glue:PassConnection", "lakeFormation:GetDataAccess" ], "Resource": "*" } ] } ``` ------ + No puede crear vistas en una base de datos que tenga los permisos `Super` o `ALL` concedidos al grupo `IAMAllowedPrincipals`. Puede revocar el permiso `Super` del grupo `IAMAllowedPrincipals` en una base de datos, ver [Paso 4: Cambiar sus almacenes de datos al modelo de permisos de Lake Formation](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4) o crear una nueva base de datos con la casilla **Usar solo el control de acceso de IAM para las nuevas tablas de esta base de datos** sin marcar en la sección **Permisos predeterminados para bases de datos y tablas recién creadas**. # Creación de vistas del Catálogo de datos mediante instrucciones DDL Puede crear AWS Glue Data Catalog vistas con editores de SQL para Athena, Amazon Redshift y con/. AWS Glue APIs AWS CLI Para crear una vista del Catálogo de datos mediante editores de SQL, elija Athena o Redshift Spectrum y cree la vista utilizando una instrucción de lenguaje de definición de datos (DDL) de tipo `CREATE VIEW`. Tras crear una vista en el dialecto del primer motor, puede utilizar una instrucción DDL de tipo `ALTER VIEW` desde el segundo motor para agregar dialectos adicionales. Al definir las vistas, es importante que tenga en cuenta lo siguiente: + **Definición de vistas multidialectales**: a la hora de definir una vista con varios dialectos, los esquemas de los distintos dialectos deben coincidir. Cada dialecto SQL tendrá una especificación de sintaxis ligeramente distinta. La sintaxis de la consulta que define la vista del Catálogo de datos debe apuntar exactamente a la misma lista de columnas, incluidos los tipos y los nombres, en todos los dialectos. Esta información se almacena en el `StorageDescriptor` de la vista. Los dialectos también deben hacer referencia a los mismos objetos de tabla subyacentes del Catálogo de datos. Para agregar otro dialecto a una vista mediante DDL, puede utilizar la instrucción `ALTER VIEW`. Si una instrucción `ALTER VIEW` intenta actualizar la definición de la vista, por ejemplo, modificando el descriptor de almacenamiento o las tablas subyacentes de la vista, la instrucción devuelve un error que indica que la entrada y el descriptor de almacenamiento existente no coinciden. Puede utilizar operaciones de conversión de SQL para asegurarse de que los tipos de columnas de la vista coincidan. + **Actualización de una vista**: para actualizar la vista, puede usar la API `UpdateTable`. Si actualiza la vista sin hacer coincidir los descriptores de almacenamiento o las tablas de referencia, puede proporcionar el indicador `FORCE` (consulte la documentación de SQL del motor para conocer la sintaxis). Tras una actualización forzada, la vista incluirá el `StorageDescriptor` forzado y las tablas de referencia. Cualquier otro DDL `ALTER VIEW` debería coincidir con los valores modificados. Una vista que se haya actualizado para incluir dialectos incompatibles pasará a tener el estado “Obsoleto”. El estado de la vista está visible en la consola de Lake Formation y mediante la operación `GetTable`. + **Referencia a un tipo de columna varchar como cadena**: no es posible convertir un tipo de columna varchar de Redshift Spectrum en una cadena. Si se crea una vista en Redshift Spectrum con un tipo de columna varchar y un dialecto posterior intenta hacer referencia a dicho campo como cadena, el Catálogo de datos lo tratará como una cadena sin necesidad del indicador `FORCE`. + **Tratamiento de campos de tipos complejos**: Amazon Redshift trata todos los tipos complejos como [tipos SUPER](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html), mientras que Athena especifica el tipo complejo. Si una vista tiene un campo de tipo `SUPER` y otro motor hace referencia a esa columna como un tipo complejo concreto, como struct (`>`), el Catálogo de datos asume que el campo es de un tipo complejo específico y lo utiliza en el descriptor de almacenamiento, sin necesidad de utilizar el indicador `Force`. Para obtener más información sobre la sintaxis para crear y administrar vistas del catálogo de datos, consulte: + [Uso de las vistas de AWS Glue Data Catalog](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html) de la Guía del usuario de Amazon Athena. + [Sintaxis de vista del Catálogo de datos de Glue](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html) en la Guía del usuario de Amazon Athena. + [Creación de vistas en AWS Glue Data Catalog](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html) en la Guía para desarrolladores de bases de datos de Amazon Redshift. Para obtener más información sobre los comandos SQL relacionados con las vistas del catálogo de datos, consulte [CREATE EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html), [ALTER EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html) y [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html). Tras crear una vista del Catálogo de datos, los detalles de la vista están disponibles en la consola de Lake Formation. 1. Seleccione **Vistas** en el catálogo de datos en la consola de Lake Formation. 1. Aparece una lista de las vistas disponibles en la página de vistas. 1. Seleccione una vista de la lista y la página de detalles mostrará los atributos de la vista. ![\[La sección inferior contiene cinco pestañas dispuestas horizontalmente, donde cada pestaña incluye la información correspondiente.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/view-definition.png) Esquema Elija una fila `Column` y seleccione **Editar etiquetas LF** para actualizar los valores de las etiquetas o asignar nuevas etiquetas LF. Definiciones de SQL Puede ver una lista completa de las definiciones de SQL disponibles. Seleccione **Añadir definición de SQL** y elija un motor de consultas para añadir una definición de SQL. Elija un motor de consulta (Athena o Amazon Redshift) en la columna `Edit definition` para actualizar una definición de SQL. Etiquetas LF Seleccione **Editar etiquetas LF** para editar los valores de una etiqueta o asignar etiquetas nuevas. Puede utilizar etiquetas LF para conceder permisos sobre las vistas. Acceso entre cuentas Puede ver una lista de Cuentas de AWS las organizaciones y unidades organizativas (OUs) con las que ha compartido la vista del catálogo de datos. Tablas subyacentes Las tablas subyacentes a las que se hace referencia en la definición de SQL utilizadas para crear la vista se muestran en esta pestaña. # Creación de vistas del catálogo de datos mediante AWS Glue APIs Puede usar AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html), y [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs para crear y actualizar vistas en el catálogo de datos. Las operaciones `CreateTable` y `UpdateTable` tienen una nueva estructura `TableInput` para `ViewDefinition`, mientras que las operaciones `SearchTables`, `GetTable`, `GetTables`, `GetTableVersion` y `GetTableVersions` proporcionan la `ViewDefinition` en su sintaxis de salida para las vistas. Además, hay un nuevo campo `Status` en la salida de la API `GetTable`. Hay dos nuevas AWS Glue conexiones disponibles para validar el dialecto SQL para cada motor de consultas compatible Amazon Athena y Amazon Redshift. Los `CreateTable` y `UpdateTable` APIs son asíncronos cuando se utilizan con vistas. Cuando APIs se invocan con varios dialectos de SQL, la llamada se valida con cada motor para determinar si el dialecto se puede ejecutar en ese motor y si el esquema resultante de la vista de cada dialecto coincide. El AWS Glue servicio utiliza estas conexiones para realizar llamadas internas a los motores de análisis. Estas llamadas simulan lo que hace el motor para validar si se ejecutó un DDL `CREATE VIEW` o un DDL `ALTER VIEW` de SQL en el motor. Si el SQL proporcionado es válido y los esquemas de los dialectos de las vistas coinciden, la API de AWS Glue confirma el resultado de forma atómica. La atomicidad permite crear o modificar vistas con varios dialectos sin ningún tiempo de inactividad. **Topics** + [Crear AWS Glue conexiones para validar el estado](views-api-usage-connection.md) + [Validación del estado de generación de vistas](views-api-usage-get-table.md) + [Estados y operaciones asíncronos](views-api-usage-async-states.md) + [Visualización de los escenarios de errores de creación durante las operaciones asincrónicas](views-api-usage-errors.md) # Crear AWS Glue conexiones para validar el estado Para crear o actualizar una AWS Glue Data Catalog vista mediante las `UpdateTable` operaciones `CreateTable` o, debe crear un nuevo tipo de AWS Glue conexión para la validación y proporcionarlo al motor de análisis compatible. Estas conexiones son necesarias para utilizar las vistas del Catálogo de datos con Athena o Amazon Redshift. Puede crear estas conexiones únicamente con AWS CLI AWS SDKs, o AWS Glue APIs. No puede usar el Consola de administración de AWS para crear la AWS Glue conexión. **nota** Si el rol de definidor de la vista y el rol que realiza la llamada a `CreateTable` o `UpdateTable` no coinciden, ambos necesitarán un permiso `glue:PassConnection` en la declaración de su política de IAM. Para obtener más información, consulta la documentación de [creación de conexión](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI . **AWS CLI comando para crear una conexión** El siguiente es un AWS CLI comando para crear una conexión: ``` aws glue create-connection --region us-east-1 --endpoint-url https://glue.us-east-1.amazonaws.com --cli-input-json file:///root/path/to/create-connection.json ``` **AWS CLI introduzca JSON** Para Amazon Redshift: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_REDSHIFT", "Name": "views-preview-cluster-connection-2", "Description": "My first Amazon Redshift validation connection", "ConnectionProperties": { "DATABASE": "dev", "CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster" } } } ``` Para Amazon Athena: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_ATHENA", "Name": "views-preview-cluster-connection-3", "Description": "My first Amazon Athena validation connection", "ConnectionProperties": { "WORKGROUP_NAME": "workgroup-name" } } } ``` # Validación del estado de generación de vistas Al ejecutar las operaciones `CreateTable` o `UpdateTable`, el campo `Status` del resultado de la API `GetTable` muestra los detalles del estado de creación de la vista. Para `create` las solicitudes en las que la tabla aún no existe, AWS Glue crea una tabla vacía durante el proceso asíncrono. Al llamar a `GetTable`, puede incluir un indicador booleano opcional `IncludeStatusDetails`, que muestra información de diagnóstico sobre la solicitud. En caso de error, este indicador muestra un mensaje de error con los estados individuales de cada dialecto. Los errores durante las operaciones de creación, lectura, actualización y eliminación (CRUD) pueden producirse durante el procesamiento en el servicio AWS Glue/Lake Formation o durante la validación de View SQL en Amazon Redshift o Athena. Cuando se produce un error durante la validación en un motor, el servicio de AWS Glue proporciona el mensaje de error que devuelve el motor. **Campos de estado** Los campos de estado son los siguientes: + Estado: un estado genérico, independiente de los diferentes tipos de trabajos: + QUEUED + IN\$1PROGRESS + SUCCESS + ERROR + Acción: indica a qué acción de la tabla se ha llamado; actualmente solo están disponibles las operaciones `CREATE` o `UPDATE`. Cuando se trabaja con vistas, es importante distinguir entre operaciones `UPDATE` y `CREATE`. El tipo de operación determina cómo se debe proceder con la consulta de las tablas. Una operación `UPDATE` significa que la tabla ya existe en el Catálogo de datos. En este caso, puede seguir consultando la tabla creada anteriormente sin ningún problema. Por otro lado, una operación `CREATE ` indica que la tabla no se ha creado correctamente con anterioridad. Si una tabla está marcada como `CREATE`, se producirá un error al intentar consultarla porque la tabla aún no existe en el sistema. Por lo tanto, es imprescindible identificar el tipo de operación (UPDATE o CREATE) antes de intentar consultar una tabla. + RequestedBy — El ARN del usuario que solicitó el cambio asincrónico. + UpdatedBy — El ARN del usuario que modificó manualmente por última vez el proceso de cambio asincrónico, por ejemplo, al solicitar una cancelación o modificación. + Error: este campo solo aparece cuando el estado es **FAILED**. Este es un mensaje de excepción de nivel principal. Puede haber errores diferentes para cada dialecto. + ErrorCode — El tipo de excepción. + ErrorMessage — una breve descripción de la excepción. + RequestTime — una cadena de fecha con formato ISO 8601 que indica la hora en que se inició el cambio. + UpdateTime — una cadena de fecha con formato ISO 8601 que indica la hora a la que se actualizó el estado por última vez. # Estados y operaciones asíncronos Al ejecutar una solicitud `glue:CreateTable`, comienza la creación asincrónica de la vista del Catálogo de datos. En las siguientes secciones, este documento describe `Status` la AWS Glue vista que está disponible en una respuesta. `glue:GetTable` Por motivos de brevedad, en esta sección se omite la respuesta completa. ``` { "Table": { ... "Status": { ... "Action": "CREATE", "State": "QUEUED", } } } ``` Los dos atributos anteriores constituyen información de diagnóstico importante que indica el estado de la operación asíncrona, así como las acciones que se pueden realizar en esta vista. A continuación se muestran los posibles valores que pueden adoptar estos atributos. 1. `Status.Action` 1. CREATE 1. UPDATE 1. `Status.State` 1. QUEUED 1. IN\$1PROGRESS 1. SUCCESS 1. ERROR También es importante tener en cuenta que algunas actualizaciones de una vista del Catálogo de datos no requieren una operación asíncrona. Por ejemplo, es posible que desee actualizar el atributo de `Description` de la tabla. Como esto no requiere ninguna operación asíncrona, los metadatos de la tabla resultante no tendrán ningún `Status`, y el atributo será `NULL`. ``` { "Table": { ..., "Description": "I changed this attribute!" } } ``` A continuación, en este tema se analiza cómo la información de estado anterior puede afectar a las operaciones que se pueden realizar en una AWS Glue vista. **pegamento: CreateTable** No hay cambios en esta API en comparación con el funcionamiento de `glue:CreateTable` en cualquier tabla de Glue. `CreateTable` acepta llamadas para cualquier nombre de tabla que aún no exista. **pegamento: UpdateTable** Esta operación no se puede realizar en una AWS Glue vista que tenga la siguiente información de estado: 1. Acción == CREATE y Estado == QUEUED 1. Acción == CREATE y Estado == IN\$1PROGRESS 1. Acción == CREATE y Estado == FAILED 1. Acción == UPDATE y Estado == QUEUED 1. Acción == UPDATE y Estado == IN\$1PROGRESS En resumen, puede actualizar una vista del Catálogo de datos solo cuando esta cumpla los siguientes requisitos. 1. Se ha creado con éxito por primera vez. 1. Acción == CREATE y Estado == SUCCESS 1. Ha alcanzado un estado terminal tras una operación de actualización asíncrona. 1. Acción == UPDATE y Estado == SUCCESS 1. Acción == UPDATE y Estado == FAILED 1. Tiene un atributo de estado `NULL` como resultado de una actualización sincrónica. **pegamento: DeleteTable** No hay cambios en esta operación en comparación con el `glue:DeleteTable` funcionamiento de cualquier AWS Glue tabla. Puede eliminar una vista del Catálogo de datos independientemente de su estado. **pegamento: GetTable** No hay cambios en esta operación en comparación con el `glue:GetTable` funcionamiento de cualquier AWS Glue tabla. Sin embargo, no puede consultar una vista del Catálogo de datos desde los motores de análisis hasta que se haya creado correctamente por primera vez. `Action == CREATE and State == SUCCESS`. Tras crear correctamente una vista del Catálogo de datos por primera vez, puede consultar la vista con independencia del estado en que se encuentre. **nota** Toda la información de esta sección se aplica a todas las lecturas de tablas`GetTable`, APIs como`GetTables`, y`SearchTables`. # Visualización de los escenarios de errores de creación durante las operaciones asincrónicas Los siguientes ejemplos son representativos de los tipos de errores que pueden resultar de las llamadas a la API de las vistas `CreateTable` o `UpdateTable`. No son exhaustivos, ya que la superficie de error de los errores en las consultas SQL es bastante amplia. ## Escenario 1: Error de consulta en Amazon Redshift La consulta proporcionada para Amazon Redshift incluye un nombre de tabla mal escrito que no se encuentra en el Catálogo de datos durante la validación. El error resultante se muestra en el campo `Status` de la respuesta de `GetTable` de la vista. Solicitud de `GetTable`: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-72", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` Respuesta de `GetTable`: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:40:06-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "UpdateTime": "2024-07-11T11:39:37-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" } } ] } } } } ``` ## Escenario 2: Conexión a Amazon Redshift no válida La conexión de Amazon Redshift del siguiente ejemplo tiene un formato incorrecto porque hace referencia a una base de datos de Amazon Redshift que no existe en el punto de conexión proporcionado. cluster/serverless Amazon Redshift no puede validar la vista y el campo `Status` de la respuesta de `GetTable` muestra el error (`"State": "FAILED"` desde Amazon Redshift). Solicitud de `GetTable`: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-73", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection-malformed" } ] } } } ``` Respuesta de `GetTable`: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:43:40-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:43:38-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" } } ] } } } } ``` ## Escenario 3: Error de consulta en Athena El SQL de Athena no es válido porque la consulta tiene mal escrito el nombre de la base de datos. La validación de consultas de Athena detecta esto y el error resultante aparece en el objeto `Status` de una llamada `GetTable`. Solicitud de `GetTable`: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-70", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` Respuesta de `GetTable`: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10: 41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "SUCCESS" } ] } } } } ``` ## Escenario 4: Los descriptores de almacenamiento no coinciden El SQL proporcionado para el dialecto de Athena selecciona `col1` y `col2`, mientras que el SQL para Redshift selecciona solo `col1`. Esto provoca un error de correspondencia en el descriptor de almacenamiento. Solicitud de `GetTable`: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-71", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` Respuesta de `GetTable`: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:23:19-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:22:49-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } } ] } } } } ``` # Concesión de permisos del vistas del catálogo de datos Tras crear vistas en el AWS Glue Data Catalog, puede conceder permisos de lago de datos sobre las vistas a los directores de todas las organizaciones y unidades Cuentas de AWS organizativas. Puede conceder permisos utilizando etiquetas LF o el método de recurso con nombre. Para obtener más información sobre cómo etiquetar recursos, consulte [Control de acceso basado en etiquetas de Lake Formation](tag-based-access-control.md). Para obtener más información sobre cómo conceder permisos directamente sobre vistas, consulte [Concesión de permisos para vistas mediante el método de recursos con nombre](granting-view-permissions.md). # Vistas materializadas **Topics** + [Diferenciar las vistas materializadas de otros tipos de vistas](#materialized-views-differentiating) + [Casos de uso](#materialized-views-use-cases) + [Conceptos clave](#materialized-views-key-concepts) + [Permisos para vistas materializadas](#materialized-views-permissions) + [Creación y administración de vistas materializadas](#materialized-views-creating-managing) + [Almacenamiento y acceso a los datos](#materialized-views-storage-access) + [Integración con permisos AWS Lake Formation](#materialized-views-lake-formation) + [Monitoreo y depuración](#materialized-views-monitoring-debugging) + [Administrar los trabajos de actualización](#materialized-views-managing-refresh-jobs) + [Supervisión y solución de problemas](#materialized-views-monitoring-troubleshooting) + [Consideraciones y limitaciones](#materialized-views-considerations-limitations) En el catálogo de AWS Glue datos, una vista materializada es una tabla gestionada que almacena el resultado precalculado de una consulta SQL en formato Apache Iceberg. A diferencia de las vistas del catálogo de datos estándar que ejecutan la consulta cada vez que se accede a ellas, las vistas materializadas almacenan físicamente los resultados de la consulta y los actualizan a medida que cambian las tablas de origen subyacentes. Puede crear vistas materializadas con Apache Spark versión 3.5.6 o superior en Amazon Athena, Amazon EMR o. AWS Glue Las vistas materializadas hacen referencia a las tablas de Apache Iceberg registradas en el catálogo de AWS Glue datos, y los datos precalculados se almacenan como tablas de Apache Iceberg en los buckets de Amazon S3 Tables o en los buckets de uso general de Amazon S3, lo que permite acceder a ellos desde varios motores de consultas, incluidos Amazon Athena, Amazon Redshift y motores de terceros compatibles con Iceberg. ## Diferenciar las vistas materializadas de otros tipos de vistas Las vistas materializadas difieren de las vistas del catálogo de AWS Glue datos, las vistas de Apache Spark y las vistas de Amazon Athena en aspectos fundamentales. Si bien las vistas del catálogo de datos son tablas virtuales que ejecutan la definición de la consulta SQL cada vez que se accede a ellas, las vistas materializadas almacenan físicamente los resultados de las consultas precalculadas. Esto elimina los cálculos redundantes y mejora considerablemente el rendimiento de las consultas en las transformaciones complejas a las que se accede con frecuencia. Las vistas materializadas también difieren de los procesos de transformación de datos tradicionales creados con AWS Glue ETL o con trabajos personalizados de Spark. En lugar de escribir código personalizado para gestionar la detección de cambios, las actualizaciones incrementales y la organización del flujo de trabajo, las vistas materializadas se definen mediante la sintaxis SQL estándar. El catálogo AWS Glue de datos supervisa automáticamente las tablas de origen, detecta los cambios y actualiza las vistas materializadas mediante una infraestructura informática totalmente gestionada. ## Casos de uso Los siguientes son casos de uso importantes de las vistas materializadas: + **Acelere las consultas analíticas complejas**: cree vistas materializadas que precalculen las costosas funciones de unión, agregación y ventana. Los motores Spark reescriben automáticamente las consultas posteriores para utilizar los resultados precalculados, lo que reduce la latencia de las consultas y los costes de cálculo. + **Simplifique los procesos de transformación de datos:** sustituya los complejos trabajos de ETL que gestionan la detección de cambios, las actualizaciones incrementales y la organización del flujo de trabajo por definiciones sencillas de vistas materializadas basadas en SQL. El catálogo de AWS Glue datos gestiona toda la complejidad operativa de forma automática. + **Habilite el análisis de autoservicio con un acceso a los datos gobernado**: cree vistas materializadas seleccionadas que transformen los datos sin procesar en conjuntos de datos listos para la empresa. Conceda a los usuarios acceso a vistas materializadas sin exponer las tablas fuente subyacentes, lo que simplifica la gestión de la seguridad y, al mismo tiempo, potencia el análisis de autoservicio. + **Optimice la ingeniería de funciones para el aprendizaje automático**: defina vistas materializadas que implementen transformaciones de funciones para los modelos de aprendizaje automático. La capacidad de actualización automática garantiza que los almacenes de funciones se mantengan actualizados a medida que evolucionan los datos de origen, mientras que la actualización incremental minimiza los costos de procesamiento. + **Implemente un intercambio de datos eficiente**: cree vistas materializadas que filtren y transformen los datos para consumidores específicos. Comparta vistas materializadas entre cuentas y regiones utilizando AWS Lake Formation, eliminando la necesidad de duplicar los datos y, al mismo tiempo, manteniendo un gobierno centralizado. ## Conceptos clave ### Actualización automática La actualización automática es una capacidad que supervisa continuamente las tablas de origen y actualiza las vistas materializadas de acuerdo con un cronograma que usted defina. Al crear una vista materializada, puede especificar una frecuencia de actualización mediante una programación basada en el tiempo con intervalos de hasta una hora. El catálogo de AWS Glue datos utiliza la infraestructura informática gestionada de Spark para ejecutar las operaciones de actualización en segundo plano, gestionando de forma transparente todos los aspectos de la detección de cambios y las actualizaciones incrementales. Cuando los datos de origen cambian entre los intervalos de actualización, la vista materializada queda temporalmente obsoleta. Las consultas que acceden directamente a la vista materializada pueden devolver resultados desactualizados hasta que se complete la siguiente actualización programada. En los escenarios que requieren acceso inmediato a los datos más actuales, puede ejecutar una actualización manual mediante el comando `REFRESH MATERIALIZED VIEW` SQL. ### Actualización incremental La actualización incremental es una técnica de optimización que procesa solo los datos que han cambiado en las tablas de origen desde la última actualización, en lugar de volver a calcular toda la vista materializada. El catálogo de AWS Glue datos aprovecha la capa de metadatos de Apache Iceberg para realizar un seguimiento eficiente de los cambios en las tablas de origen y determinar qué partes de la vista materializada requieren actualizaciones. Este enfoque reduce significativamente los costos de procesamiento y la duración de la actualización en comparación con las operaciones de actualización completa, especialmente en el caso de conjuntos de datos grandes en los que solo un pequeño porcentaje de los datos cambia entre los ciclos de actualización. El mecanismo de actualización incremental funciona automáticamente; no es necesario escribir una lógica personalizada para detectar o procesar los datos modificados. ### Reescritura automática de consultas La reescritura automática de consultas es una capacidad de optimización de consultas disponible en los motores Spark de Amazon Athena, Amazon EMR y. AWS Glue Cuando ejecutas una consulta con tablas base, el optimizador de Spark analiza tu plan de consultas y determina automáticamente si las vistas materializadas disponibles pueden satisfacer la consulta de manera más eficiente. Si existe una vista materializada adecuada, el optimizador reescribe la consulta de forma transparente para utilizar los resultados precalculados en lugar de procesar las tablas base. Esta optimización se produce sin necesidad de realizar ningún cambio en el código de la aplicación ni en las instrucciones de consulta. El optimizador Spark garantiza que la reescritura automática de consultas solo se aplique cuando la vista materializada sea actual y pueda producir resultados precisos. Si una vista materializada está obsoleta o no cumple completamente con los requisitos de la consulta, el optimizador ejecuta el plan de consultas original utilizando las tablas base y prioriza la corrección por encima del rendimiento. ### Función de definición de vistas Una vista materializada funciona en función de los permisos del rol de IAM que la creó, conocido como rol de definidor de vistas. La función de definición debe tener acceso de lectura a todas las tablas base a las que se hace referencia en la definición de la vista materializada y debe tener permisos de creación de tablas en la base de datos de destino. Cuando el catálogo de AWS Glue datos actualiza una vista materializada, asume la función de definidor para acceder a las tablas de origen y escribir los resultados actualizados. Este modelo de seguridad permite conceder a los usuarios acceso a las vistas materializadas sin concederles permisos directos sobre las tablas de origen subyacentes. Si la función de definición de vistas pierde el acceso a alguna tabla base, las operaciones de actualización posteriores fallarán hasta que se restablezcan los permisos. ## Permisos para vistas materializadas Para crear y gestionar vistas materializadas, debe configurar AWS Lake Formation los permisos. El rol de IAM que crea la vista materializada (la función de definición) requiere permisos específicos en las tablas de origen y las bases de datos de destino. ### Permisos requeridos para el rol definidor El rol definidor debe contar con los siguientes permisos de Lake Formation: + En las tablas de origen: permisos SELECT o ALL, sin filtros de filas, columnas ni celdas. + En la base de datos de destino: permiso CREATE\$1TABLE + En el catálogo de AWS Glue datos GetTable y en los permisos de la CreateTable API Cuando crea una vista materializada, el ARN del rol definidor se almacena en la definición de la vista. El catálogo AWS Glue de datos asume esta función al ejecutar operaciones de actualización automática. Si el rol definidor pierde el acceso a las tablas de origen, las operaciones de actualización fallarán hasta que se restablezcan los permisos. ### Permisos de IAM para trabajos AWS Glue La AWS Glue función de IAM de su trabajo requiere los siguientes permisos: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetDatabase", "glue:GetDatabases", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:*:/aws-glue/*" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" } ] } ``` El rol que utilice para la actualización automática de Materialized View debe tener el PassRole permiso iam: en el rol. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Para permitir que Glue actualice automáticamente la vista materializada, el rol también debe contar con la siguiente política de confianza, que habilita al servicio a asumir dicho rol. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Si la vista materializada se almacena en buckets de tablas de S3, también debe añadir el siguiente permiso al rol. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3tables:PutTableMaintenanceConfiguration" ], "Resource": "arn:aws:s3tables:*:123456789012:*" } ] } ``` ### Concesión de acceso a vistas materializadas Para conceder a otros usuarios acceso a consultar una vista materializada, utilice AWS Lake Formation el permiso SELECT en la tabla de vistas materializadas. Los usuarios pueden consultar la vista materializada sin necesidad de tener acceso directo a las tablas de origen subyacentes. Para obtener información detallada sobre la configuración de los permisos de Lake Formation, consulte Concesión y revocación de permisos en los recursos del catálogo de datos en la Guía para AWS Lake Formation desarrolladores. ## Creación y administración de vistas materializadas Las vistas materializadas se crean mediante la `CREATE MATERIALIZED VIEW` sentencia SQL en los motores Spark. La definición de la vista especifica la consulta SQL que define la lógica de transformación, la base de datos y el nombre de la tabla de destino, y la configuración de actualización opcional. Puede definir transformaciones complejas, incluidas las agregaciones, las uniones de varias tablas, los filtros y las funciones de ventana. ``` CREATE MATERIALIZED VIEW sales_summary AS SELECT region, product_category, SUM(sales_amount) as total_sales, COUNT(DISTINCT customer_id) as unique_customers FROM sales_transactions WHERE transaction_date >= current_date - interval '90' day GROUP BY region, product_category; ``` Para configurar la actualización automática, incluya el programa de actualización en la definición de la vista: ``` CREATE MATERIALIZED VIEW sales_summary SCHEDULE REFRESH EVERY 1 HOUR AS SELECT region, product_category, SUM(sales_amount) as total_sales FROM sales_transactions GROUP BY region, product_category; ``` Puede refrescar manualmente una vista materializada en cualquier momento mediante el `REFRESH MATERIALIZED VIEW` comando: ``` REFRESH MATERIALIZED VIEW sales_summary; ``` Para modificar el programa de actualización de una vista materializada existente, utilice la `ALTER MATERIALIZED VIEW` siguiente instrucción: ``` ALTER MATERIALIZED VIEW sales_summary ADD SCHEDULE REFRESH EVERY 2 HOURS; ``` ### Vistas materializadas anidadas Puede crear vistas materializadas que hagan referencia a otras vistas materializadas como tablas base, lo que permite la transformación de datos en varias etapas. Al crear vistas materializadas anidadas, el catálogo de AWS Glue datos rastrea las dependencias y propaga automáticamente las actualizaciones por la jerarquía de vistas materializadas. Cuando se actualiza una vista materializada base, todas las vistas materializadas posteriores que dependen de ella se actualizan en consecuencia. Esta capacidad le permite descomponer las transformaciones complejas en etapas lógicas, lo que mejora la capacidad de mantenimiento y permite la actualización selectiva de las capas de transformación en función de sus requisitos de actualización de los datos. ## Almacenamiento y acceso a los datos Las vistas materializadas almacenan los resultados precalculados como tablas de Apache Iceberg en los cubos de S3 Tables o en los cubos S3 de uso general de su cuenta. AWS El catálogo de AWS Glue datos gestiona todos los aspectos del mantenimiento de las tablas Iceberg, incluidas la compactación y la retención de instantáneas, mediante las capacidades de optimización automatizada de S3 Tables. Como las vistas materializadas se almacenan como tablas de Iceberg, puede leerlas directamente desde cualquier motor compatible con Iceberg, incluidos Amazon Athena, Amazon Redshift y plataformas de análisis de terceros. Esta accesibilidad multimotor garantiza que sus datos precalculados permanezcan accesibles en todo su ecosistema de análisis sin duplicar los datos ni convertir el formato. ## Integración con permisos AWS Lake Formation Se puede utilizar AWS Lake Formation para gestionar permisos detallados en vistas materializadas. El creador de la vista se convierte automáticamente en el propietario de la vista materializada y puede conceder permisos a otros usuarios o roles mediante el método de recurso designado o las etiquetas AWS Lake Formation LF. Al conceder un `SELECT` permiso a un usuario para acceder a una vista materializada, este puede consultar los resultados precalculados sin necesidad de acceder a las tablas de origen subyacentes. Este modelo de seguridad simplifica la administración del acceso a los datos y permite implementar el principio del privilegio mínimo, proporcionando a los usuarios acceso únicamente a las transformaciones de datos específicas que necesitan. Puede compartir vistas materializadas entre AWS cuentas, AWS organizaciones y unidades organizativas mediante las funciones AWS Lake Formation de uso compartido entre cuentas. También puede acceder a las vistas materializadas de todas AWS las regiones mediante enlaces a recursos, lo que permite una gobernanza centralizada de los datos con un acceso distribuido a los datos. ## Monitoreo y depuración El catálogo AWS Glue de datos publica en Amazon CloudWatch todas las operaciones de actualización de vistas materializadas y las métricas asociadas. Puede monitorizar la hora de inicio y finalización de la actualización, la duración, el volumen de datos procesados y el estado de la actualización mediante CloudWatch métricas. Cuando las operaciones de actualización fallan, los mensajes de error y la información de diagnóstico se capturan en CloudWatch los registros. Puede configurar CloudWatch alarmas para recibir notificaciones cuando los trabajos de actualización superen la duración prevista o fallen repetidamente. El catálogo de AWS Glue datos también publica los eventos de cambio para las ejecuciones de actualización correctas y fallidas, lo que le permite integrar las operaciones de visualización materializada en una automatización más amplia del flujo de trabajo. Para comprobar el estado actual de una vista materializada, utilice el comando `DESCRIBE MATERIALIZED VIEW` SQL, que devuelve los metadatos, incluido el estado de inactividad, la fecha de la última actualización y la configuración del programa de actualización. ## Administrar los trabajos de actualización ### Iniciar una actualización manual Active una actualización inmediata fuera del intervalo programado. Permiso obligatorio: las AWS credenciales utilizadas para realizar la llamada a la API deben tener `glue:GetTable` permiso para la vista materializada. Para el catálogo de tablas S3: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id :s3tablescatalog/ \ --database-name \ --table-name ``` Para el catálogo raíz: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ### Comprobando el estado de actualización Obtenga el estado de un trabajo de actualización específico: ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id ``` ### Historial de actualizaciones del listado Vea todos los trabajos de actualización para obtener una vista materializada: ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name ``` **nota** Se utiliza `:s3tablescatalog/` para las tablas S3 o `` para el catálogo raíz. ### Detener una actualización en ejecución Cancelar un trabajo de actualización en curso: ``` aws glue stop-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ## Supervisión y solución de problemas Hay tres formas de supervisar los trabajos de actualización de vistas materializadas: ### CloudWatch Métricas Consulte las métricas agregadas de todos sus trabajos de actualización de vistas materializadas en CloudWatch: Métricas disponibles: + AWS/Pegue el espacio de nombres con dimensiones: + CatalogId: Su identificador de catálogo + DatabaseName: Base de datos que contiene la vista materializada + TableName: nombre de la vista materializada + TaskType: Definido en "» MaterializedViewRefresh Visualización en la consola: 1. Vaya a la CloudWatch consola → Métricas 1. Seleccione el espacio de AWS nombres /Glue 1. Filtrar por dimensiones: CatalogId,,, DatabaseName TableName TaskType 1. Vea las métricas del éxito, el fracaso y la duración del trabajo Ejemplo de consulta de CloudWatch métricas: ``` {AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh ``` Uso de AWS CLI: ``` aws cloudwatch get-metric-statistics \ --namespace AWS/Glue \ --metric-name \ --dimensions Name=CatalogId,Value= \ Name=DatabaseName,Value= \ Name=TableName,Value= \ Name=TaskType,Value=MaterializedViewRefresh \ --start-time \ --end-time \ --period 3600 \ --statistics Sum \ --region ``` ### CloudWatch Registros Vea los registros de ejecución detallados de las ejecuciones individuales de las tareas de actualización: Grupo de registros: `/aws-glue/materialized-views/` Dónde `` está un UUID (por ejemplo, abc12345-def6-7890-ghij-klmnopqrstuv). Visualización de registros: ``` # List log streams for a task run aws logs describe-log-streams \ --log-group-name /aws-glue/materialized-views/ \ --region # Get log events aws logs get-log-events \ --log-group-name /aws-glue/materialized-views/ \ --log-stream-name \ --region ``` En CloudWatch la consola: 1. Vaya a CloudWatch → Registrar grupos 1. Busque /aws-glue/materialized-views/ 1. Seleccione el grupo de registros con su ID de ejecución de la tarea 1. Consulta los registros de ejecución detallados, los errores y el resultado de los trabajos de Spark ### Notificaciones Suscríbete a los eventos para recibir notificaciones en tiempo real sobre los cambios en el estado de los trabajos de actualización: Tipos de eventos disponibles: + Se inició la tarea de actualización de Glue Materialized View + La tarea de actualización de Glue Materialized View se realizó correctamente + Error en la tarea de actualización de Glue Materialized View + Fallo al invocar la vista materializada automáticamente de Glue Materialized Creación de una regla: ``` aws events put-rule \ --name materialized-view-refresh-notifications \ --event-pattern '{ "source": ["aws.glue"], "detail-type": [ "Glue Materialized View Refresh Task Started", "Glue Materialized View Refresh Task Succeeded", "Glue Materialized View Refresh Task Failed", "Glue Materialized View Auto-Refresh Invocation Failure" ] }' \ --region ``` Añadir un objetivo (por ejemplo, un tema de SNS): ``` aws events put-targets \ --rule materialized-view-refresh-notifications \ --targets "Id"="1","Arn"="arn:aws:sns:::" \ --region ``` ### Visualización del estado de actualización Compruebe el estado de sus trabajos de actualización de vistas materializadas mediante la AWS Glue API: ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id \ --region ``` O bien, enumere todas las ejecuciones de actualización recientes: ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name \ --region ``` Esto muestra lo siguiente: + Hora de la última actualización + Estado de actualización (CORRECTO, FALLIDO, EN EJECUCIÓN, DETENIDO) + ID de ejecución de la tarea + Mensajes de error (si falló) Estados de actualización comunes: + EN EJECUCIÓN: el trabajo de actualización se está ejecutando actualmente + CORRECTO: La actualización se completó correctamente + ERROR: la actualización ha detectado un error + DETENIDA: la actualización se canceló manualmente Solución de problemas de actualizaciones fallidas: Si se produce un error en la actualización, compruebe lo siguiente: 1. Permisos de IAM: asegúrese de que la función de definición tenga acceso a todas las tablas base y a la ubicación de la vista materializada 1. Disponibilidad de la tabla base: compruebe que todas las tablas a las que se hace referencia existan y estén accesibles 1. Validez de la consulta: confirma que la consulta SQL es válida para el dialecto SQL de Spark 1. Límites de recursos: comprueba si has alcanzado los límites de actualización simultánea de tu cuenta Usa la GetMaterializedViewRefreshTaskRun API para recuperar mensajes de error detallados. ## Consideraciones y limitaciones + Las vistas materializadas solo pueden hacer referencia a las tablas de Apache Iceberg registradas en el catálogo de AWS Glue datos como tablas base. + La creación de vistas y la reescritura automática de consultas solo están disponibles en los motores de Spark en Apache Spark versión 3.5.6 y versiones posteriores en Amazon Athena AWS Glue , Amazon EMR y (versión 5.1). + En última instancia, las vistas materializadas son coherentes con las tablas base. Durante la ventana de actualización, las consultas que acceden directamente a la vista materializada pueden devolver datos desactualizados. Para acceder inmediatamente a los datos actuales, ejecute una actualización manual. + El intervalo mínimo de actualización automática es de una hora. Para los casos de uso que requieran actualizaciones más frecuentes, ejecute las actualizaciones manuales mediante programación mediante el comando. `REFRESH MATERIALIZED VIEW` + La reescritura de consultas prioriza la corrección por encima del rendimiento. Si una vista materializada está obsoleta o no puede satisfacer los requisitos de consulta con precisión, los motores de Spark ejecutan la consulta original en las tablas base.