* sustitúyalo por el nombre del rol del flujo de trabajo.
| Tipo de política | Política |
| --- | --- |
| AWS política gestionada | AWSGlueConsoleFullAccess |
| Política insertada (básica) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
| Política insertada (para las operaciones en tablas gobernadas, incluidas las operaciones dentro de las transacciones) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
| Política insertada (para el control de acceso a metadatos mediante el método de control de acceso basado en etiquetas de Lake Formation (LF-TBAC)) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
| Política insertada (política de passrole para el rol de flujo de trabajo) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
### Permisos de analista de datos
| Tipo de política | Política |
| --- | --- |
| AWS política gestionada | AmazonAthenaFullAccess |
| Política insertada (básica) | {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"glue:GetTable",
"glue:GetTables",
"glue:SearchTables",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:GetPartitions",
"lakeformation:GetResourceLFTags",
"lakeformation:ListLFTags",
"lakeformation:GetLFTag",
"lakeformation:SearchTablesByLFTags",
"lakeformation:SearchDatabasesByLFTags"
],
"Resource": "*"
}
]
} |
| (Opcional) Política insertada (para las operaciones en tablas gobernadas, incluidas las operaciones dentro de las transacciones) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
### Permisos del rol de flujo de trabajo
Este rol cuenta con los permisos necesarios para ejecutar un flujo de trabajo. Se especifica un rol con estos permisos cuando se crea un flujo de trabajo.
**importante**
En las siguientes políticas, ** sustitúyalo por un identificador de AWS región válido (por ejemplo`us-east-1`), ** por un número de AWS cuenta válido, ** por el nombre del rol del flujo de trabajo y ** por la ruta de Amazon S3 a tus AWS CloudTrail registros.
| Tipo de política | Política |
| --- | --- |
| AWS política gestionada | AWSGlueServiceRole |
| Política insertada (acceso a datos) | {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Lakeformation",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"lakeformation:GrantPermissions"
],
"Resource": "*"
}
]
} |
| Política insertada (política de passrole para el rol de flujo de trabajo) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
| Política en línea (para ingerir datos fuera del lago de datos, por ejemplo, AWS CloudTrail registros) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/permissions-reference.html) |
# Cambiar la configuración predeterminada de su lago de datos
Para mantener la compatibilidad con versiones anterioresAWS Glue, AWS Lake Formation tiene la siguiente configuración de seguridad inicial:
+ El permiso `Super` se concede al grupo `IAMAllowedPrincipals` sobre todos los recursos existentes del Catálogo de datos de AWS Glue.
+ La configuración "Usar solo control de acceso de IAM" está activada para los nuevos recursos del Catálogo de datos.
De hecho, esta configuración hace que el acceso a los recursos del catálogo de datos y a las ubicaciones de Amazon S3 se controle únicamente mediante políticas AWS Identity and Access Management (IAM). Los permisos individuales de Lake Formation no están en vigor.
El grupo `IAMAllowedPrincipals` incluye a todos los usuarios y roles de IAM a los que sus políticas de IAM permiten el acceso a los recursos de su Catálogo de datos. El permiso `Super` permite a una entidad principal efectuar todas las operaciones compatibles con Lake Formation en la base de datos o tabla sobre la que se ha concedido.
Para cambiar la configuración de seguridad de modo que el acceso a los recursos del Catálogo de datos (bases de datos y tablas) sea administrado por los permisos de Lake Formation, haga lo siguiente:
1. Cambie la configuración de seguridad predeterminada para los nuevos recursos. Para obtener instrucciones, consulte [Cambio del modelo de permisos predeterminado o uso del modo de acceso híbrido](initial-lf-config.md#setup-change-cat-settings).
1. Cambiar la configuración de los recursos existentes del Catálogo de datos. Para obtener instrucciones, consulte [Actualización AWS Glue de los permisos de datos al AWS Lake Formation modelo](upgrade-glue-lake-formation.md).
**Cambiar la configuración de seguridad predeterminada mediante la operación de la API `PutDataLakeSettings` de Lake Formation**
También puede cambiar la configuración de seguridad predeterminada mediante la operación de la [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)API Lake Formation. Esta acción toma como argumentos un identificador de catálogo opcional y una [DataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DataLakeSettings.html)estructura.
Para imponer el control de acceso a los metadatos y a los datos subyacentes por parte de Lake Formation en las nuevas bases de datos y tablas, codifique la estructura `DataLakeSettings` de la manera siguiente.
**nota**
**Sustitúyalo por un identificador de AWS cuenta válido y ** por un nombre de usuario de IAM válido. Puede especificar más de un usuario como administrador del lago de datos.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
],
"CreateDatabaseDefaultPermissions": [],
"CreateTableDefaultPermissions": []
}
}
```
También puede codificar la estructura de la siguiente manera. Omitir el parámetro `CreateDatabaseDefaultPermissions` o `CreateTableDefaultPermissions` equivale a pasar una lista vacía.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
]
}
}
```
Esta acción revoca efectivamente todos los permisos de Lake Formation del grupo `IAMAllowedPrincipals` en las nuevas bases de datos y tablas. Cuando cree una base de datos, puede anular esta configuración.
Para imponer el control de acceso a los metadatos y a los datos subyacentes solo mediante IAM en las nuevas bases de datos y tablas, codifique la estructura de `DataLakeSettings` de la manera siguiente.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
],
"CreateDatabaseDefaultPermissions": [
{
"Principal": {
"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
},
"Permissions": [
"ALL"
]
}
],
"CreateTableDefaultPermissions": [
{
"Principal": {
"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
},
"Permissions": [
"ALL"
]
}
]
}
}
```
Esto concede al grupo `IAMAllowedPrincipals` el permiso `Super` de Lake Formation sobre nuevas bases de datos y tablas. Cuando cree una base de datos, puede anular esta configuración.
**nota**
En la estructura `DataLakeSettings` anterior, el único valor permitido para `DataLakePrincipalIdentifier` es `IAM_ALLOWED_PRINCIPALS`, y el único valor permitido para `Permissions` es `ALL`.
# Permisos implícitos de Lake Formation
AWS Lake Formation concede los siguientes permisos implícitos a los administradores de lagos de datos, a los creadores de bases de datos y a los creadores de tablas.
**Administrador de lago de datos**
+ Tener acceso de `Describe` a todos los recursos del Catálogo de datos excepto a los recursos compartidos desde otra cuenta directamente a otra entidad principal. Este acceso no puede ser revocado por un administrador.
+ Disponga de permisos de ubicación de datos en todas las partes del lago de datos.
+ Puede conceder o revocar el acceso a cualquier recurso del Catálogo de datos a cualquier entidad principal (incluida la propia). Este acceso no puede ser revocado por un administrador.
+ Puede crear bases de datos en el Catálogo de datos.
+ Puede conceder el permiso para crear una base de datos a otro usuario.
Los administradores del lago de datos pueden registrar ubicaciones de Amazon S3 solo si disponen de permisos de IAM para hacerlo. Las políticas del administrador del lago de datos sugeridas en esta guía conceden esos permisos. Además, los administradores de los lagos de datos no tienen permisos implícitos para eliminar bases de datos o alter/drop tablas creadas por otros. Sin embargo, pueden concederse a sí mismos permisos para hacerlo.
Para obtener más información sobre los administradores del lago de datos, consulte [Crear un administrador de lago de datos](initial-lf-config.md#create-data-lake-admin).
**Creadores de catálogos**
+ Tienen todos los permisos de catálogo en los catálogos que crean, tienen permisos en las bases de datos y tablas que crean en el catálogo y pueden conceder permisos a otros directores de la misma AWS cuenta para crear bases de datos y tablas en el catálogo. Un creador de catálogos que también tenga la política `AWSLakeFormationCrossAccountManager` AWS administrada puede conceder permisos sobre el catálogo a otras AWS cuentas u organizaciones.
Los administradores del lago de datos pueden utilizar la consola o la API de Lake Formation para designar a los creadores de catálogos.
**nota**
Los creadores de catálogos no tienen permisos implícitos en las bases de datos y tablas que otros crean en el catálogo.
Para obtener más información sobre la creación de catálogos, consulte [Llevar sus datos al AWS Glue Data Catalog](bring-your-data-overview.md).
**Creadores de bases de datos**
+ Tienen todos los permisos de base de datos en las bases de datos que crean, tienen permisos en las tablas que crean en la base de datos y pueden conceder permisos a otros directores de la misma AWS cuenta para crear tablas en la base de datos. Un creador de bases de datos que también tenga la política `AWSLakeFormationCrossAccountManager` AWS administrada puede conceder permisos sobre la base de datos a otras AWS cuentas u organizaciones.
Los administradores del lago de datos pueden utilizar la consola de Lake Formation o la API para designar a los creadores de las bases de datos.
**nota**
Los creadores de bases de datos no tienen permisos implícitos sobre las tablas que otros crean en la base de datos.
Para obtener más información, consulte [Creación de una base de datos](creating-database.md).
**Creadores de tablas**
+ Tienen todos los permisos sobre las tablas que crean.
+ Pueden conceder permisos sobre todas las tablas que creen a las entidades principales de la misma cuenta AWS .
+ Puede conceder permisos en todas las tablas que cree a otras AWS cuentas u organizaciones si disponen de la política `AWSLakeFormationCrossAccountManager` AWS gestionada.
+ Pueden ver las bases de datos que contienen las tablas que crean.
# Referencia de permisos de Lake Formation
Para realizar AWS Lake Formation las operaciones, los directores necesitan tanto los permisos de Lake Formation como los permisos AWS Identity and Access Management (IAM). En general, los permisos IAM se conceden *mediante políticas de control de acceso poco específicas*, como se describe en [Descripción general de los permisos de Lake Formation](lf-permissions-overview.md). Puede conceder permisos a Lake Formation mediante la consola, la API o AWS Command Line Interface (AWS CLI).
Para saber cómo conceder o revocar permisos de Lake Formation, consulte [Concesión de permisos sobre los recursos del Catálogo de datos](granting-catalog-permissions.md) y [Conceder permisos de ubicación de datos](granting-location-permissions.md).
**nota**
Los ejemplos de esta sección muestran cómo conceder permisos a entidades principales en la misma cuenta AWS . Para ver ejemplos de concesiones entre cuentas, consulte [Compartir datos entre cuentas en Lake Formation](cross-account-permissions.md).
## Permisos de Lake Formation por tipo de recurso
A continuación se indican los permisos válidos de Lake Formation disponibles para cada tipo de recurso:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/lf-permissions-reference.html)
**Topics**
+ [Permisos de Lake Formation por tipo de recurso](#lf-resource-permissions-summary)
+ [Lake Formation otorga y revoca órdenes AWS CLI](#perm-command-format)
+ [Permisos de Lake Formation](#lf-permissions)
## Lake Formation otorga y revoca órdenes AWS CLI
Cada descripción de permisos de esta sección incluye ejemplos de cómo se concede el permiso mediante un AWS CLI comando. Las siguientes son las sinopsis de Lake Formation **grant-permissions** y **revoke-permissions** AWS CLI sus comandos.
```
grant-permissions
[--catalog-id ]
--principal
--resource
--permissions
[--permissions-with-grant-option ]
[--cli-input-json ]
[--generate-cli-skeleton ]
```
```
revoke-permissions
[--catalog-id ]
--principal
--resource
--permissions
[--permissions-with-grant-option ]
[--cli-input-json ]
[--generate-cli-skeleton ]
```
Para obtener descripciones detalladas de estos comandos, consulte [grant-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/grant-permissions.html) y [revoke-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/revoke-permissions.html) en la *Referencia de comandos de AWS CLI *. En esta sección se proporciona información adicional sobre la opción `--principal`.
El valor de la opción `--principal` es uno de los siguientes:
+ Nombre de recurso de Amazon (ARN) para un usuario o AWS Identity and Access Management rol (IAM)
+ ARN para un usuario o grupo que se autentica a través de un proveedor SAML, como Microsoft Active Directory Federation Service (AD FS)
+ ARN de un usuario o grupo de Amazon Quick
+ Para los permisos entre cuentas, un identificador de AWS cuenta, un identificador de organización o un identificador de unidad organizativa
+ Para un usuario o grupo de IAM Identity Center, ARN de usuario o grupo de IAM Identity Center.
A continuación encontrará la sintaxis y ejemplos para todos los tipos de `--principal`.
**La entidad principal es un usuario de IAM**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::user/
```
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1
```
**La entidad principal es un rol de IAM**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::role/
```
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/workflowrole
```
**La entidad principal es un usuario que se autentica a través de un proveedor SAML**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:user/
```
Ejemplos:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:user/datalake_user1
```
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:user/athena-user@example.com
```
**La entidad principal es un grupo que se autentica a través de un proveedor SAML**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:group/
```
Ejemplos:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:group/data-scientists
```
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:group/my-group
```
**Principal es usuario de Amazon Quick Enterprise Edition**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:::user//
```
Para **, debe especificar `default`.
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:user/default/bi_user1
```
**Principal es un grupo de Amazon Quick Enterprise Edition**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:::group//
```
Para **, debe especificar `default`.
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:group/default/data_scientists
```
**Principal es una AWS cuenta**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=
```
Ejemplo:
```
--principal DataLakePrincipalIdentifier=111122223333
```
**La entidad principal es una organización**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations:::organization/
```
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:organization/o-abcdefghijkl
```
**La entidad principal es una unidad organizativa**
Sintaxis:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations:::ou//
```
Ejemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:ou/o-abcdefghijkl/ou-ab00-cdefghij
```
**Entidad principal es un usuario o grupo de identidades de IAM Identity Center**
Ejemplo:Usuario
```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/
```
Ejemplo:Grupo:
```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::group/
```
**Entidad principal es un grupo de IAM: `IAMAllowedPrincipals`**
Lake Formation concede el permiso `Super` sobre todas las bases de datos y tablas del Catálogo de datos a un grupo llamado `IAMAllowedPrincipals` de forma predeterminada. Si este permiso de grupo existe en una base de datos o una tabla, todas las entidades principales de la cuenta tendrán acceso al recurso a través de políticas de entidad principal de IAM para AWS Glue. Proporciona compatibilidad retroactiva cuando se empiezan a utilizar permisos de Lake Formation para proteger recursos del Catálogo de datos que anteriormente estaban protegidos mediante políticas de IAM para AWS Glue.
Cuando se usa Lake Formation para administrar los permisos sobre los recursos del Catálogo de datos, primero es necesario revocar el permiso `IAMAllowedPrincipals` de los recursos, o bien inscribir las entidades principales y los recursos en el modo de acceso híbrido para que los permisos de Lake Formation funcionen.
Ejemplo:
```
--principal DataLakePrincipalIdentifier=IAM_Allowed_Principals
```
**Entidad principal es un grupo de IAM: `ALLIAMPrincipals`**
Al conceder permisos al grupo `ALLIAMPrincipals` en un recurso del Catálogo de datos, todas las entidades principales de la cuenta obtienen acceso al recurso del Catálogo de datos mediante permisos de Lake Formation y permisos de IAM.
Ejemplo:
```
--principal DataLakePrincipalIdentifier=123456789012:IAMPrincipals
```
## Permisos de Lake Formation
Esta sección contiene los permisos disponibles de Lake Formation que puede conceder a las entidades principales.
### `ALTER`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| ALTER | DATABASE | glue:UpdateDatabase |
| ALTER | TABLE | glue:UpdateTable |
| ALTER | LF-Tag | lakeformation:UpdateLFTag |
Una entidad principal con este permiso puede alterar los metadatos de una base de datos o tabla del Catálogo de datos. Para las tablas, puede cambiar el esquema de columnas y añadir parámetros de columna. No puede alterar las columnas de los datos subyacentes a los que apunta una tabla de metadatos.
Si la propiedad que se está modificando es una ubicación registrada de Amazon Simple Storage Service (Amazon S3), la entidad principal debe tener permisos de ubicación de datos en la nueva ubicación.
**Example**
El siguiente ejemplo concede el `ALTER` permiso al usuario `datalake_user1` de la base `retail` de datos de la AWS cuenta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Database": {"Name":"retail"}}'
```
**Example**
El siguiente ejemplo concede `ALTER` al usuario `datalake_user1` en la tabla `inventory` de la base de datos `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
### `CREATE_DATABASE`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| CREATE\$1DATABASE | Data Catalog | glue:CreateDatabase |
Una entidad principal con este permiso puede crear una base de metadatos o un enlace de recursos en el Catálogo de datos. La entidad principal también puede crear tablas en la base de datos.
**Example**
En el siguiente ejemplo, se concede `CREATE_DATABASE` al usuario `datalake_user1` de la cuenta 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_DATABASE" --resource '{ "Catalog": {}}'
```
Cuando una entidad principal crea una base de datos en el Catálogo de datos, no se conceden permisos a los datos subyacentes. Se conceden los siguientes permisos adicionales para metadatos (junto con la posibilidad de conceder estos permisos a otros):
+ `CREATE_TABLE` en la base de datos
+ Base de datos de `ALTER`
+ Base de datos de `DROP`
Al crear una base de datos, la entidad principal puede especificar de forma opcional una ubicación de Amazon S3. Dependiendo de si la entidad principal tiene permisos de localización de datos, el permiso `CREATE_DATABASE` podría no ser suficiente para crear bases de datos en todos los casos. Es importante tener en cuenta los siguientes puntos.
| Caso práctico de creación de una base de datos | Permisos necesarios |
| --- | --- |
| La propiedad de ubicación no está especificada. | CREATE\$1DATABASE es suficiente. |
| Se especifica la propiedad de ubicación, y la ubicación no está administrada por Lake Formation (no está registrada). | CREATE\$1DATABASE es suficiente. |
| Se especifica la propiedad de ubicación, y la ubicación es administrada por Lake Formation (está registrada). | Se requiere CREATE\$1DATABASE, además de permisos de localización de datos en la ubicación especificada. |
### `CREATE_TABLE`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| CREATE\$1TABLE | DATABASE | glue:CreateTable |
Una entidad principal con este permiso puede crear una tabla de metadatos o un enlace de recursos en el Catálogo de datos dentro de la base de datos especificada.
**Example**
El siguiente ejemplo concede al usuario `datalake_user1` permiso para crear tablas en la `retail` base de datos de la cuenta 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1
--permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}'
```
Cuando una entidad principal crea una tabla en el Catálogo de datos, se le conceden todos los permisos de Lake Formation sobre la tabla, con la posibilidad de conceder estos permisos sobre otros.
**Concesiones entre cuentas**
Si una cuenta propietaria de una base de datos concede `CREATE_TABLE` a una cuenta de destinatario, y un usuario de la cuenta de destinatario crea con éxito una tabla en la base de datos de la cuenta propietaria, se aplican las siguientes reglas:
+ El usuario y los administradores del lago de datos de la cuenta de destinatario tienen todos los permisos de Lake Formation sobre la tabla. Pueden conceder permisos sobre la tabla a otras entidades principales de su cuenta. No pueden conceder permisos a entidades principales en la cuenta del propietario ni en ninguna otra cuenta.
+ Los administradores del lago de datos de la cuenta del propietario pueden conceder permisos sobre la tabla a otras entidades principales de su cuenta.
**Permisos de ubicación de datos**
Cuando intente crear una tabla que apunte a una ubicación de Amazon S3, dependiendo de si dispone de permisos de ubicación de datos, es posible que el permiso `CREATE_TABLE` no sea suficiente para crear una tabla. Es importante tener en cuenta los tres casos siguientes.
| Caso práctico de creación de tablas | Permisos necesarios |
| --- | --- |
| Lake Formation no administra la ubicación especificada (no está registrada). | CREATE\$1TABLE es suficiente. |
| Lake Formation administra la ubicación especificada (está registrada), y la base de datos que la contiene no tiene propiedad de ubicación o tiene una propiedad de ubicación que no es un prefijo de Amazon S3 de la ubicación de la tabla. | Se requiere CREATE\$1TABLE, además de permisos de localización de datos en la ubicación especificada. |
| Lake Formation administra la ubicación especificada (está registrada), y la base de datos contenedora tiene una propiedad de ubicación que apunta a una ubicación que está registrada y es un prefijo de Amazon S3 de la ubicación de la tabla. | CREATE\$1TABLE es suficiente. |
### `DATA_LOCATION_ACCESS`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| DATA\$1LOCATION\$1ACCESS | Ubicación de Amazon S3 | (Permisos de Amazon S3 en la ubicación, que deben especificarse en el rol utilizado para registrar la ubicación). |
Este es el único permiso de ubicación de datos. Una entidad principal con este permiso puede crear una base de datos o tabla de metadatos que apunte a la ubicación de Amazon S3 especificada. La ubicación debe estar registrada. Una entidad principal que tiene permisos de localización de datos en una localización también tiene permisos de localización en las localizaciones secundarias.
**Example**
El siguiente ejemplo concede permisos de ubicación de datos en `s3://products/retail` al usuario `datalake_user1` en la cuenta de AWS 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DATA_LOCATION_ACCESS" --resource '{ "DataLocation": {"ResourceArn":"arn:aws:s3:::products/retail"}}'
```
`DATA_LOCATION_ACCESS` no es necesario para consultar o actualizar los datos subyacentes. Este permiso se aplica únicamente a la creación de recursos del Catálogo de datos.
Para obtener más información sobre permisos de ubicación de datos, consulte [Underlying data access control](access-control-underlying-data.md#data-location-permissions).
### `DELETE`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| DELETE | TABLE | (No se necesitan permisos de IAM adicionales si la ubicación está registrada). |
Una entidad principal con este permiso puede insertar, actualizar y leer datos subyacentes en la ubicación de Amazon S3 especificada por la tabla. La entidad principal también puede ver la tabla en la consola de Lake Formation y recuperar información sobre la tabla con la API AWS Glue.
**Example**
El siguiente ejemplo concede el `DELETE` permiso al usuario `datalake_user1` sobre la tabla de la base `retail` de datos de la cuenta `inventory` 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DELETE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Este permiso se aplica solo a los datos de Amazon S3 y no a los de otros almacenes de datos como Amazon Relational Database Service (Amazon RDS).
### `DESCRIBE`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| DESCRIBE | Enlace de recurso a tabla Enlace de recurso a base de datos | `glue:GetTable` `glue:GetDatabase` |
| DESCRIBE | DATABASE | glue:GetDatabase |
| DESCRIBE | TABLE | glue:GetTable |
| DESCRIBE | LF-Tag | `glue:GetTable` `glue:GetDatabase` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` |
Una entidad principal con este permiso puede ver la base de datos, tabla o enlace de recursos especificados. No se concede implícitamente ningún otro permiso del Catálogo de datos ni ningún permiso de acceso a los datos. Las bases de datos y las tablas aparecen en los editores de consultas de los servicios integrados, pero no se puede consultar en ellas salvo que se concedan otros permisos de Lake Formation (por ejemplo, `SELECT`).
Por ejemplo, un usuario que tiene `DESCRIBE` en una base de datos puede ver la base de datos y todos los metadatos de la base de datos (descripción, ubicación, etc.). Sin embargo, el usuario no puede averiguar qué tablas contiene la base de datos y no puede eliminar, modificar o crear tablas en la base de datos. Del mismo modo, un usuario que tiene `DESCRIBE` en una tabla puede ver la tabla y los metadatos de la tabla (descripción, esquema, ubicación, etc.), pero no puede soltar, alterar o ejecutar consultas contra la tabla.
A continuación se detallan algunas normas adicionales para `DESCRIBE`:
+ Si un usuario tiene otros permisos de Lake Formation sobre una base de datos, tabla o enlace de recursos, `DESCRIBE` se le concede implícitamente.
+ Si un usuario tiene `SELECT` solo en un subconjunto de columnas de una tabla (`SELECT` parcial), el usuario estará restringido a ver solo esas columnas.
+ No puede conceder `DESCRIBE` a un usuario que tiene selección parcial en una tabla. Por el contrario, no puede especificar listas de inclusión o exclusión de columnas para las tablas sobre las que se concede `DESCRIBE`.
**Example**
En el siguiente ejemplo, se concede el `DESCRIBE` permiso al usuario `datalake_user1` en el enlace de recursos de la tabla de la base `retail` de datos de la cuenta `inventory-link` 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```
### `DROP`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| DROP | DATABASE | glue:DeleteDatabase |
| DROP | TABLE | glue:DeleteTable |
| DROP | LF-Tag | lakeformation:DeleteLFTag |
| DROP | Enlace de recurso a base de datos Enlace de recurso a tabla | `glue:DeleteDatabase` `glue:DeleteTable` |
Una entidad principal con este permiso puede borrar una base de datos, tabla o enlace de recurso en el Catálogo de datos. No puede conceder el permiso DROP en una base de datos a una cuenta u organización externa.
**aviso**
Al eliminar una base de datos se eliminan todas sus tablas.
**Example**
En el siguiente ejemplo, se concede el `DROP` permiso al usuario de la base de datos de la cuenta `datalake_user1` 1111-2222-3333`retail`. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Database": {"Name":"retail"}}'
```
**Example**
El siguiente ejemplo concede `DROP` al usuario `datalake_user1` sobre la tabla `inventory` en la base de datos `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
**Example**
El siguiente ejemplo concede `DROP` al usuario `datalake_user1` sobre el enlace de recursos de tabla `inventory-link` en la base de datos `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```
### `INSERT`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| INSERT | TABLE | (No se necesitan permisos de IAM adicionales si la ubicación está registrada). |
Una entidad principal con este permiso puede insertar, actualizar y leer datos subyacentes en la ubicación de Amazon S3 especificada por la tabla. La entidad principal también puede ver la tabla en la consola de Lake Formation y recuperar información sobre la tabla con la API AWS Glue.
**Example**
El siguiente ejemplo concede el `INSERT` permiso al usuario `datalake_user1` de la tabla de la base `retail` de datos de la cuenta `inventory` 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "INSERT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Este permiso se aplica únicamente a los datos de Amazon S3 y no a los datos de otros almacenes de datos, como Amazon RDS.
### `SELECT`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| SELECT | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/lf-permissions-reference.html) | (No se necesitan permisos de IAM adicionales si la ubicación está registrada). |
Una entidad principal con este permiso puede ver una tabla en el Catálogo de datos y consultar los datos subyacentes en Amazon S3 en la ubicación especificada por la tabla. La entidad principal puede ver la tabla en la consola de Lake Formation y recuperar información sobre la tabla con la API AWS Glue. Si se aplicó el filtrado por columnas cuando se concedió este permiso, la entidad principal puede ver los metadatos solo de las columnas incluidas y consultar los datos solo de las columnas incluidas.
**nota**
Es responsabilidad del servicio de análisis integrado aplicar el filtrado de columnas al procesar una consulta.
**Example**
En el siguiente ejemplo, se concede el `SELECT` permiso al usuario `datalake_user1` de la tabla de la base `retail` de datos de la cuenta `inventory` 1111-2222-3333. AWS
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Este permiso se aplica únicamente a los datos de Amazon S3 y no a los datos de otros almacenes de datos, como Amazon RDS.
Puede filtrar (restringir el acceso a) columnas específicas con una lista de inclusión opcional o una lista de exclusión. Una lista de inclusión especifica las columnas a las que se puede acceder. Una lista de exclusión especifica las columnas a las que no se puede acceder. En ausencia de una lista de inclusión o exclusión, todas las columnas de la tabla son accesibles.
Los resultados de `glue:GetTable` devuelven solo las columnas que la persona que llama tiene permiso para ver. Los servicios integrados como Amazon Athena y Amazon Redshift respetan las listas de inclusión y exclusión de columnas.
**Example**
El ejemplo siguiente concede `SELECT` al usuario `datalake_user1` sobre la tabla `inventory` utilizando una lista de inclusión.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnNames": ["prodcode","location","period","withdrawals"]}}'
```
**Example**
El ejemplo siguiente concede `SELECT` en la tabla `inventory` utilizando una lista de exclusión.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnWildcard": {"ExcludedColumnNames": ["intkey", "prodcode"]}}}'
```
Se aplican las siguientes restricciones al permiso `SELECT`:
+ Al conceder `SELECT`, no puede incluir la opción de concesión si se aplica el filtrado por columnas.
+ No puede restringir el control de acceso en columnas que son claves de partición.
+ A una entidad principal con el permiso `SELECT` sobre un subconjunto de columnas de una tabla no se le puede conceder el permiso `ALTER`, `DROP`, `DELETE` o `INSERT` sobre esa tabla. Del mismo modo, a una entidad principal con el permiso `ALTER`, `DROP`, `DELETE`, o `INSERT` en una tabla no se le puede conceder el permiso `SELECT` con el filtrado de columnas.
El permiso `SELECT` siempre aparece en la página **Permisos de datos** de la consola de Lake Formation como una fila separada. En la imagen siguiente se muestra que `SELECT` se concede a los usuarios `datalake_user2` y `datalake_user3` en todas las columnas de la tabla `inventory`.
![\[La página de permisos de datos muestra cuatro filas. La primera fila contiene los permisos Eliminar e Insertar con el tipo de recurso Tabla con el recurso mostrado como inventory, y la segunda y cuarta filas muestran el permiso Seleccionar con el tipo de recurso Columna, y con el recurso mostrado como retail.inventory.*.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/data-permissions-dialog-select-cross.png)
### `Super`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| Super | DATABASE | glue:\$1Database\$1 |
| Super | TABLE | glue:\$1Table\$1, glue:\$1Partition\$1 |
Este permiso permite a una entidad principal efectuar todas las operaciones compatibles con Lake Formation en la base de datos o en la tabla. No puede conceder `Super` en una base de datos a una cuenta externa.
Este permiso puede coexistir con los demás permisos de Lake Formation. Por ejemplo, puede conceder los permisos `Super`, `SELECT` y `INSERT` sobre una tabla de metadatos. La entidad principal puede entonces efectuar todas las operaciones admitidas en la tabla. Cuando revoca `Super`, los permisos `SELECT` y `INSERT` permanecen, y la entidad principal solo puede efectuar las operaciones de selección e inserción.
En lugar de conceder `Super` a una entidad principal individual, puede concederla al grupo `IAMAllowedPrincipals`. El grupo `IAMAllowedPrincipals` se crea automáticamente e incluye a todos los usuarios y roles de IAM a los que sus políticas de IAM permiten el acceso a los recursos de su Catálogo de datos. Cuando se concede `Super` a `IAMAllowedPrincipals` para un recurso del Catálogo de datos, el acceso al recurso queda efectivamente controlado únicamente por las políticas de IAM.
Puede hacer que se conceda automáticamente el permiso `Super` a `IAMAllowedPrincipals` para los nuevos recursos del catálogo aprovechando las opciones de la página **Configuración** de la consola de Lake Formation.
![\[El cuadro de diálogo Configuración del Catálogo de datos tiene el subtítulo "Permisos predeterminados para bases de datos y tablas recién creadas" y cuenta con dos casillas de verificación, que se describen en el texto.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/settings-page.png)
+ Para conceder `Super` a `IAMAllowedPrincipals` para todas las bases de datos nuevas, seleccione **Usar solo control de acceso IAM para bases de datos nuevas**.
+ Para conceder `Super` a `IAMAllowedPrincipals` para todas las tablas nuevas en bases de datos nuevas, seleccione **Usar solo control de acceso IAM para tablas nuevas en bases de datos nuevas**.
**nota**
Esta opción hace que se marque de manera predeterminada la casilla **Utilizar sólo el control de acceso IAM para las nuevas tablas de esta base de datos** en el cuadro de diálogo **Crear base de datos**. No hace nada más que eso. Es la casilla de verificación del cuadro de diálogo **Crear base de datos** que permite la concesión de `Super` a `IAMAllowedPrincipals`.
Estas opciones de la página **Configuración** están habilitadas de forma predeterminada. Para obtener más información, consulte los siguientes temas:
+ [Cambiar la configuración predeterminada de su lago de datos](change-settings.md)
+ [Actualización AWS Glue de los permisos de datos al AWS Lake Formation modelo](upgrade-glue-lake-formation.md)
### `SUPER_USER`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| Super user | Catalog | glue:GetCatalog |
Puede conceder el permiso `Super user` solo a entidades principales específicas sobre los catálogos del Catálogo de datos predeterminado. No puede conceder permisos `Super user` sobre el catálogo predeterminado ni sobre otros tipos de recursos, como bases de datos y tablas, ni a entidades principales de cuentas externas. El permiso `Super user` permite a una entidad principal efectuar todas las operaciones compatibles con Lake Formation en las bases de datos y tablas incluidas en el catálogo concedido.
Con el permiso `Super user`, la entidad principal (beneficiario) puede realizar las siguientes acciones en los recursos (catálogos, bases de datos y tablas) del catálogo:
+ Permisos `CREATE_DATABASE` y `DESCRIBE` en el catálogo.
+ Permisos `DROP`, `ALTER`, `CREATE_TABLE` y `DESCRIBE` (en efecto, `SUPER`) en todas las bases de datos del catálogo.
+ Permisos `DROP`, `ALTER`, `DESCRIBE`, `SELECT`, `INSERT` y `DELETE` (en efecto, `SUPER`) en todas las tablas de todas las bases de datos del catálogo.
+ Permisos `All` (en efecto, SUPER) en los catálogos incluidos en el catálogo.
+ Permisos concesibles (la posibilidad de conceder estos permisos a otras entidades principales) en todos los catálogos, bases de datos y tablas del catálogo.
Con el permiso `Super user` en un recurso del catálogo, el beneficiario no puede realizar ni delegar las acciones `ALTER` y `DROP` en el catálogo.
### `ASSOCIATE`
| Permiso | Concedido sobre este recurso | El beneficiario también necesita |
| --- | --- | --- |
| ASSOCIATE | LF-Tag | `glue:GetDatabase` `glue:GetTable` `lakeformation:AddLFTagsToResource"` `lakeformation:RemoveLFTagsFromResource"` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` |
Una entidad principal con este permiso en una etiqueta LF puede asignar esta a un recurso del Catálogo de datos. Al conceder `ASSOCIATE` está otorgando `DESCRIBE` de manera implícita.
**Example**
En este ejemplo se concede al usuario `datalake_user1` el permiso `ASSOCIATE` sobre las etiquetas LF con la clave `module`. Concede permisos para ver y asignar todos los valores de esa clave, como indica el asterisco (\$1).
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ASSOCIATE" --resource '{ "LFTag": {"CatalogId":"111122223333","TagKey":"module","TagValues":["*"]}}'
```
# Integración de IAM Identity Center
Con él AWS IAM Identity Center, puede conectarse a los proveedores de identidad (IdPs) y administrar de forma centralizada el acceso de los usuarios y grupos a todos los servicios de AWS análisis. Puede integrar proveedores de identidad como Okta, Ping y Microsoft Entra ID (anteriormente Azure Active Directory) con IAM Identity Center para que los usuarios de su organización accedan a los datos mediante una experiencia de inicio de sesión único. IAM Identity Center también permite conectar otros proveedores de identidad de terceros.
Para obtener más información, consulte la sección [Proveedores de identidad compatibles](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) en la Guía del AWS IAM Identity Center usuario.
Puede configurarlo AWS Lake Formation como una aplicación habilitada en el Centro de identidades de IAM, y los administradores del lago de datos pueden conceder permisos detallados a los usuarios y grupos autorizados sobre los recursos. AWS Glue Data Catalog
Los usuarios de la organización pueden iniciar sesión en cualquier aplicación habilitada para Identity Center mediante el proveedor de identidad de su organización y consultar conjuntos de datos aplicando los permisos de Lake Formation. Con esta integración, puede gestionar el acceso a los AWS servicios sin necesidad de crear varias funciones de IAM.
[La propagación fiable de la identidad](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) es una AWS IAM Identity Center función que los administradores de Connected Servicios de AWS pueden utilizar para conceder y auditar el acceso a los datos del servicio. El acceso a estos datos se basa en los atributos del usuario, como las asociaciones de grupo. La configuración de una propagación de identidad fiable requiere la colaboración entre los administradores de Connected Servicios de AWS y los administradores del IAM Identity Center. Para obtener más información, consulte [Requisitos previos y consideraciones](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
Para conocer las limitaciones, consulte [Limitaciones de la integración de IAM Identity Center](identity-center-lf-notes.md).
**Topics**
+ [Requisitos previos para la integración de IAM Identity Center con Lake Formation](prerequisites-identity-center.md)
+ [Conexión de Lake Formation con IAM Identity Center](connect-lf-identity-center.md)
+ [Actualización de la integración de IAM Identity Center](update-lf-identity-center-connection.md)
+ [Eliminación de una conexión de Lake Formation con IAM Identity Center](delete-lf-identity-center-connection.md)
+ [Concesión de permisos a usuarios y grupos](grant-permissions-sso.md)
+ [Incluir el contexto de usuario del IAM Identity Center en los registros CloudTrail](identity-center-ct-logs.md)
# Requisitos previos para la integración de IAM Identity Center con Lake Formation
A continuación, se indican los requisitos previos para integrar IAM Identity Center con Lake Formation.
1. Habilitar IAM Identity Center: la habilitación de IAM Identity Center es un requisito previo para permitir la autenticación y la propagación de identidades.
1. Elegir su origen de identidades: después de habilitar IAM Identity Center, debe tener un proveedor de identidades para administrar los usuarios y grupos. Puede usar el directorio integrado del Identity Center como origen de identidad o usar un IdP externo, como Microsoft Entra ID u Okta.
Para obtener más información, [consulte Administrar la fuente de identidad](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html) y [Conectarse a un proveedor de identidad externo](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) en la Guía del AWS IAM Identity Center usuario.
1. Crear un rol de IAM: el rol que crea la conexión a IAM Identity Center requiere permisos para crear y modificar la configuración de la aplicación en Lake Formation e IAM Identity Center, como se indica en la siguiente política en línea.
Debe añadir permisos según las prácticas recomendadas de IAM. Los permisos específicos se detallan en los siguientes procedimientos. Para obtener más información, consulte [Primeros pasos con IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:CreateLakeFormationIdentityCenterConfiguration",
"sso:CreateApplication",
"sso:PutApplicationAssignmentConfiguration",
"sso:PutApplicationAuthenticationMethod",
"sso:PutApplicationGrant",
"sso:PutApplicationAccessScope"
],
"Resource": [
"*"
]
}
]
}
```
------
Si comparte los recursos del catálogo de datos con organizaciones Cuentas de AWS o entidades externas, debe tener los permisos AWS Resource Access Manager (AWS RAM) para crear recursos compartidos. Para obtener más información sobre los permisos necesarios para compartir recursos, consulte [Cross-account data sharing prerequisites](cross-account-prereqs.md).
Las siguientes políticas en línea contienen los permisos específicos necesarios para ver, actualizar y eliminar las propiedades de la integración de Lake Formation con IAM Identity Center.
+ Utilice la siguiente política en línea para permitir que un rol de IAM vea una integración de Lake Formation con IAM Identity Center.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
"sso:DescribeApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Utilice la siguiente política en línea para permitir que un rol de IAM actualice una integración de Lake Formation con IAM Identity Center. La política también incluye los permisos opcionales necesarios para compartir recursos con cuentas externas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:UpdateLakeFormationIdentityCenterConfiguration",
"lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
"sso:DescribeApplication",
"sso:UpdateApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Utilice la siguiente política en línea para permitir que un rol de IAM elimine una integración de Lake Formation con IAM Identity Center.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:DeleteLakeFormationIdentityCenterConfiguration",
"sso:DeleteApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Para saber qué permisos de IAM son necesarios para conceder o revocar permisos de lago de datos a usuarios y grupos de IAM Identity Center, consulte [Permisos de IAM necesarios para conceder o revocar permisos de Lake Formation](required-permissions-for-grant.md).
*Descripción de los permisos*
+ `lakeformation:CreateLakeFormationIdentityCenterConfiguration` – Crea la configuración IdC de Lake Formation.
+ `lakeformation:DescribeLakeFormationIdentityCenterConfiguration` – Describe una configuración de IdC existente.
+ `lakeformation:DeleteLakeFormationIdentityCenterConfiguration` – Ofrece la posibilidad de eliminar una configuración de IdC de Lake Formation existente.
+ `lakeformation:UpdateLakeFormationIdentityCenterConfiguration` – Se usa para cambiar una configuración existente de Lake Formation.
+ `sso:CreateApplication` – Se utiliza para crear una aplicación de IAM Identity Center.
+ `sso:DeleteApplication`: se utiliza para eliminar una aplicación IAM Identity Center.
+ `sso:UpdateApplication`: se utiliza para actualizar una aplicación IAM Identity Center.
+ `sso:PutApplicationGrant` – Se utiliza para cambiar la información del emisor de tokens de confianza.
+ `sso:PutApplicationAuthenticationMethod` – Otorga acceso de autenticación a Lake Formation.
+ `sso:GetApplicationGrant` – Se utiliza para enumerar la información del emisor de tokens de confianza.
+ `sso:DeleteApplicationGrant` – Elimina la información del emisor de tokens de confianza.
+ `sso:PutApplicationAccessScope` – Añade o actualiza la lista de objetivos autorizados para el ámbito de acceso de una aplicación a IAM Identity Center.
+ `sso:PutApplicationAssignmentConfiguration` – Se utiliza para configurar cómo acceden los usuarios a una aplicación.
# Conexión de Lake Formation con IAM Identity Center
Antes de poder usar IAM Identity Center para administrar identidades y conceder acceso a los recursos del catálogo de datos mediante Lake Formation, debe realizar los siguientes pasos. Puede crear la integración de IAM Identity Center mediante la consola o AWS CLI de Lake Formation.
------
#### [ Consola de administración de AWS ]
**Para conectar Lake Formation con IAM Identity Center**
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 el panel de navegación izquierdo, seleccione **Integración de IAM Identity Center**.
![\[Pantalla de integración de IAM Identity Center con ARN de Identity Center.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/identity-center-integ.png)
1. (Opcional) Introduzca una o más organizaciones IDs o unidades and/or organizativas válidas Cuenta de AWS IDs IDs para permitir que las cuentas externas accedan a los recursos del catálogo de datos. Cuando los usuarios o grupos de IAM Identity Center intentan acceder a los recursos del Catálogo de datos administrados por Lake Formation, Lake Formation asume un rol de IAM para autorizar el acceso a los metadatos. Si la función de IAM pertenece a una cuenta externa que no tiene una política de AWS Glue recursos ni un AWS RAM recurso compartido, los usuarios y grupos del IAM Identity Center no podrán acceder al recurso aunque tengan permisos de Lake Formation.
Lake Formation utiliza el servicio AWS Resource Access Manager (AWS RAM) para compartir el recurso con cuentas y organizaciones externas. AWS RAM envía una invitación a la cuenta del concesionario para que acepte o rechace el recurso compartido.
Para obtener más información, consulte [Aceptar una invitación para compartir recursos de AWS RAM](accepting-ram-invite.md).
**nota**
Lake Formation permite que los roles de IAM de cuentas externas actúen como roles de operador en nombre de los usuarios y grupos de IAM Identity Center para acceder a los recursos del Catálogo de datos, pero solo se pueden conceder permisos a recursos del Catálogo de datos de la cuenta propietaria. Si intenta conceder permisos a usuarios y grupos de IAM Identity Center sobre recursos del Catálogo de datos de una cuenta externa, Lake Formation devuelve el siguiente error: “Cross-account grants are not supported for the principal”.
1. (Opcional) En la pantalla de **integración de Create Lake Formation**, especifique las aplicaciones ARNs de terceros que pueden acceder a los datos de las ubicaciones de Amazon S3 registradas en Lake Formation. Lake Formation vende credenciales temporales limitadas en forma de AWS STS tokens a las ubicaciones registradas de Amazon S3 en función de los permisos vigentes, de modo que las aplicaciones autorizadas puedan acceder a los datos en nombre de los usuarios.
1. (Opcional) En la pantalla de **integración Create Lake Formation**, active la casilla Amazon Redshift Connect en Trusted Identity Propagation para permitir la detección de los permisos federados de Amazon Redshift mediante IDC. Lake Formation propaga identidad a posteriores en función de los permisos efectivos, por lo que las aplicaciones autorizadas pueden acceder a los datos en nombre de los usuarios.
1. Seleccione **Enviar**.
Una vez que el administrador de Lake Formation finalice los pasos y cree la integración, las propiedades de IAM Identity Center aparecen en la consola de Lake Formation. Al realizar estas tareas, Lake Formation se convierte en una aplicación habilitada para IAM Identity Center. Las propiedades de la consola incluyen el estado de la integración. Cuando se completa, el estado de la integración muestra `Success`. Este estado indica si la configuración de IAM Identity Center se ha completado.
------
#### [ AWS CLI ]
+ En el siguiente ejemplo se muestra cómo crear la integración de Lake Formation con IAM Identity Center. También puede especificar el `Status` (`ENABLED`, `DISABLED`) de las aplicaciones.
```
aws lakeformation create-lake-formation-identity-center-configuration \
--catalog-id <123456789012> \
--instance-arn \
--share-recipients '[{"DataLakePrincipalIdentifier": "<123456789012>"},
{"DataLakePrincipalIdentifier": "<555555555555>"}]' \
--external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'
```
+ En el siguiente ejemplo se muestra cómo ver una integración de Lake Formation con IAM Identity Center.
```
aws lakeformation describe-lake-formation-identity-center-configuration
--catalog-id <123456789012>
```
+ En el siguiente ejemplo, se muestra cómo habilitar la autorización. `Redshift:Connect` La autorización se puede HABILITAR o DESHABILITAR.
```
aws lakeformation create-lake-formation-identity-center-configuration \
--instance-arn \
--service-integrations '[{
"Redshift": [{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}]
}]'
```
+ Utilice el `describe-lake-formation-identity-center-configuration` comando para describir la aplicación del centro de identidad de Lake Formation. `Redshift:Connect`la integración de los servicios es esencial para la propagación de la identidad de iDC entre servicios y clústeres:
```
aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012>
```
Respuesta:
```
{
"CatalogId": "CATALOG ID",
"InstanceArn": "INSTANCE ARN",
"ApplicationArn": "APPLICATION ARN",
"ShareRecipients": [],
"ServiceIntegrations": [
{
"Redshift": [
{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}
]
}
]
}
```
------
## Uso del IAM Identity Center en múltiples Regiones de AWS
Lake Formation es compatible con IAM Identity Center en múltiples Regiones de AWS ocasiones. Puede ampliar el centro de identidad de IAM de su región principal Región de AWS a otras regiones para mejorar el rendimiento gracias a la proximidad a los usuarios y a la fiabilidad. Cuando se añade una nueva región al IAM Identity Center, puede crear aplicaciones de Lake Formation Identity Center en la nueva región sin replicar las identidades de la región principal. Para obtener más información sobre cómo empezar a utilizar el Centro de identidades de IAM en varias regiones, consulte el Centro de identidades de [IAM multirregional en la Guía del usuario del Centro de identidades](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html) de *IAM*.
# Actualización de la integración de IAM Identity Center
Tras crear la conexión, puede añadir aplicaciones de terceros para que la integración de IAM Identity Center se integre con Lake Formation y obtener acceso a los datos de Amazon S3 en nombre de los usuarios. También puede eliminar las aplicaciones existentes de la integración de IAM Identity Center. Puede agregar o eliminar aplicaciones mediante la consola Lake Formation y mediante la [UpdateLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_UpdateLakeFormationIdentityCenterConfiguration.html)operación. AWS CLI
**nota**
Tras crear la integración de IAM Identity Center, no podrá actualizar el `ARN` de la instancia.
------
#### [ Consola de administración de AWS ]
**Para actualizar una conexión existente de IAM Identity Center con Lake Formation**
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 el panel de navegación izquierdo, seleccione **Integración de IAM Identity Center**.
1. Seleccione **Añadir** en la página **Integración de IAM Identity Center**.
1. Introduzca una o más organizaciones IDs o unidades and/or organizativas válidas Cuenta de AWS IDs IDs para permitir que las cuentas externas accedan a los recursos del catálogo de datos.
1. En la pantalla **Añadir aplicaciones**, introduzca la aplicación IDs de las aplicaciones de terceros que desee integrar con Lake Formation.
1. Seleccione **Añadir**.
1. (Opcionalmente) En la página de **integración del Centro de identidades de IAM**, puede activar o desactivar la propagación de identidades de confianza para Amazon Redshift connect. Lake Formation propaga identidad a posteriores en función de los permisos efectivos, por lo que las aplicaciones autorizadas pueden acceder a los datos en nombre de los usuarios.
------
#### [ AWS CLI ]
Puede añadir o eliminar aplicaciones de terceros para la integración del Centro de Identidad de IAM ejecutando el siguiente comando. AWS CLI Cuando se establece el estado de filtrado externo en `ENABLED`, IAM Identity Center puede proporcionar administración de identidades para que las aplicaciones de terceros accedan a los datos administrados por Lake Formation. También puede activar o desactivar la integración de IAM Identity Center configurando el estado de la aplicación.
```
aws lakeformation update-lake-formation-identity-center-configuration \
--external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'\
--share-recipients '[{"DataLakePrincipalIdentifier": "<444455556666>"}
{"DataLakePrincipalIdentifier": "<777788889999>"}]' \
--application-status ENABLED
```
Si ya tiene una solicitud de IDC de LF, pero desea añadir la `Redshift:Connect` autorización, puede utilizar lo siguiente para actualizar su solicitud de IDC de Lake Formation. La autorización puede activarse o desactivarse.
```
aws lakeformation update-lake-formation-identity-center-configuration \
--service-integrations '[{
"Redshift": [{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}]
}]'
```
------
# Eliminación de una conexión de Lake Formation con IAM Identity Center
Si desea eliminar una integración existente de IAM Identity Center, puede hacerlo mediante la consola o la [DeleteLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DeleteLakeFormationIdentityCenterConfiguration.html)operación de Lake Formation. AWS CLI
------
#### [ Consola de administración de AWS ]
**Para eliminar una conexión existente de IAM Identity Center con Lake Formation**
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 el panel de navegación izquierdo, seleccione **Integración de IAM Identity Center**.
1. Seleccione **Eliminar** en la página **Integración de IAM Identity Center**.
1. En la pantalla **Confirmar integración**, confirme la acción y seleccione **Eliminar**.
------
#### [ AWS CLI ]
Puede eliminar la integración de IAM Identity Center ejecutando el siguiente AWS CLI comando.
```
aws lakeformation delete-lake-formation-identity-center-configuration \
--catalog-id <123456789012>
```
------
# Concesión de permisos a usuarios y grupos
El administrador del lago de datos puede conceder permisos a los usuarios y grupos de IAM Identity Center sobre los recursos del catálogo de datos (bases de datos, tablas y vistas) para permitir un fácil acceso a los datos. Para conceder o revocar los permisos del lago de datos, el otorgante necesita permisos para las siguientes acciones de IAM Identity Center.
+ [DescribeUser](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeUser.html)
+ [DescribeGroup](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeGroup.html)
+ [DescribeInstance](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_DescribeInstance.html)
Puede conceder permisos utilizando la consola de Lake Formation, la API o la AWS CLI.
Para obtener más información sobre cómo conceder permisos, consulte [Concesión de permisos sobre los recursos del Catálogo de datos](granting-catalog-permissions.md).
**nota**
Solo puede conceder permisos a los recursos de su cuenta. Para transferir los permisos en cascada a los usuarios y grupos sobre los recursos que ha compartido con usted, debe utilizar AWS RAM los recursos compartidos.
------
#### [ Consola de administración de AWS ]
**Para conceder permisos a usuarios y grupos**
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. Seleccione **Permisos de lago de datos** bajo **Permisos** in en la consola de Lake Formation.
1. Seleccione **Conceder**.
1. En la página **Conceder permisos de lagos de datos**, elija usuarios y grupos de **IAM Identity Center**.
1. Seleccione **Añadir** para elegir los usuarios y grupos a los que va a conceder permisos.
![\[Pantalla Conceder permisos de lago de datos con usuarios y grupos de IAM Identity Center seleccionados.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/identity-center-grant-perm.png)
1. En la pantalla **Asignar usuarios y grupos**, elija los and/or grupos de usuarios a los que va a conceder los permisos.
Seleccione **Asignar**.
![\[Pantalla Conceder permisos de lago de datos con usuarios y grupos de IAM Identity Center seleccionados.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/identity-center-assign-users-groups.png)
1. A continuación, elija el método para conceder los permisos.
Para obtener instrucciones sobre cómo conceder permisos mediante el método de recursos con nombre, consulte [Concesión de permisos de datos mediante el método de recurso con nombre](granting-cat-perms-named-resource.md).
Para obtener instrucciones sobre cómo conceder permisos mediante etiquetas LF, consulte [Conceder permisos de lago de datos mediante el método LF-TBAC](granting-catalog-perms-TBAC.md).
1. Elija los recursos del catálogo de datos de los que desea conceder permisos.
1. Elija los permisos del catálogo de datos que desee conceder.
1. Seleccione **Conceder**.
------
#### [ AWS CLI ]
En el siguiente ejemplo, se muestra cómo conceder el permiso `SELECT` de usuario de IAM Identity Center en una tabla.
```
aws lakeformation grant-permissions \
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ \
--permissions "SELECT" \
--resource '{ "Table": { "DatabaseName": "retail", "TableWildcard": {} } }'
```
Para recuperarlos `UserId` desde el Centro de Identidad de IAM, consulte la [GetUserId](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html)operación en la Referencia de la API del Centro de Identidad de IAM.
------
# Incluir el contexto de usuario del IAM Identity Center en los registros CloudTrail
Lake Formation utiliza la funcionalidad de [expendición de credenciales](using-cred-vending.md) para proporcionar acceso temporal a los datos de Amazon S3. De forma predeterminada, cuando un usuario del Centro de Identidad de IAM envía una consulta a un servicio de análisis integrado, los CloudTrail registros solo incluyen la función de IAM que asume el servicio para proporcionar acceso a corto plazo. Si utiliza un rol definido por el usuario para registrar la ubicación de datos de Amazon S3 en Lake Formation, puede optar por incluir el contexto del usuario del IAM Identity Center en los CloudTrail eventos y, a continuación, realizar un seguimiento de los usuarios que acceden a sus recursos.
**importante**
Para incluir solicitudes de API de Amazon S3 a nivel de objeto en el CloudTrail, debe habilitar el registro de CloudTrail eventos para el bucket y los objetos de Amazon S3. Para obtener más información, consulte [Habilitar el registro de CloudTrail eventos para buckets y objetos de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) en la Guía del usuario de Amazon S3.
**Para habilitar la auditoría de la expedición de credenciales en ubicaciones de lagos de datos registradas con roles definidos por el usuario**
1. Inicie sesión en la consola de Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. En el panel de navegación de la izquierda, expanda **Administración** y elija **Configuración del Catálogo de datos**.
1. En **Auditoría mejorada**, elija **Propagar el contexto proporcionado**.
1. Seleccione **Save**.
También puede activar la opción de auditoría mejorada configurando el `Parameters` atributo en la [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)operación. De forma predeterminada, el valor del parámetro `SET_CONTEXT"` se establece en “verdadero”.
```
{
"DataLakeSettings": {
"Parameters": {"SET_CONTEXT": "true"},
}
}
```
El siguiente es un extracto de un CloudTrail evento con la opción de auditoría mejorada. Este registro incluye tanto el contexto de sesión del usuario de IAM Identity Center como el rol de IAM definido por el usuario que asume Lake Formation para acceder a la ubicación de datos de Amazon S3. Consulte el parámetro `onBehalfOf` en el siguiente extracto.
```
{
"eventVersion":"1.09",
"userIdentity":{
"type":"AssumedRole",
"principalId":"AROAW7F7MOX4OYE6FLIFN:access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab",
"arn":"arn:aws:sts::123456789012:assumed-role/accessGrantsTestRole/access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab",
"accountId":"123456789012",
"accessKeyId":"ASIAW7F7MOX4CQLD4JIZN",
"sessionContext":{
"sessionIssuer":{
"type":"Role",
"principalId":"AROAW7F7MOX4OYE6FLIFN",
"arn":"arn:aws:iam::123456789012:role/accessGrantsTestRole",
"accountId":"123456789012",
"userName":"accessGrantsTestRole"
},
"attributes":{
"creationDate":"2023-08-09T17:24:02Z",
"mfaAuthenticated":"false"
}
},
"onBehalfOf":{
"userId": "",
"identityStoreArn": "arn:aws:identitystore::"
}
},
"eventTime":"2023-08-09T17:25:43Z",
"eventSource":"s3.amazonaws.com",
"eventName":"GetObject",
....
```
# Añadir una ubicación de Amazon S3 a su lago de datos
Para añadir una ubicación de datos como almacenamiento en su lago de datos, *registre* la ubicación (ubicación del **lago de datos**) con AWS Lake Formation. Luego, puede usar los permisos de Lake Formation para un control de acceso detallado a AWS Glue Data Catalog los objetos que apuntan a esta ubicación y a los datos subyacentes de la ubicación.
Lake Formation también permite registrar una ubicación de datos en modo de acceso híbrido y le proporciona la flexibilidad de habilitar selectivamente los permisos de Lake Formation para bases de datos y tablas en su Catálogo de datos. Con el modo de acceso híbrido, dispone de una ruta incremental que le permite establecer los permisos de Lake Formation para un conjunto específico de usuarios sin interrumpir las políticas de permisos de otros usuarios o cargas de trabajo existentes.
Para más información sobre la configuración del modo de acceso híbrido, consulte [Modo de acceso híbrido](hybrid-access-mode.md)
Al registrar una ubicación, se registran esa ruta de Amazon S3 y todas las carpetas incluidas en esa ruta.
Por ejemplo, supongamos que tiene una organización de rutas de Amazon S3 como la siguiente:
`/mybucket/accounting/sales/`
Si registra `S3://mybucket/accounting`, la carpeta `sales` también estará registrada y bajo la administración de Lake Formation.
Para obtener más información sobre cómo registrar ubicaciones, consulte [Underlying data access control](access-control-underlying-data.md#underlying-data-access-control).
**nota**
Se recomiendan los permisos de Lake Formation para los datos estructurados (organizados en tablas con filas y columnas). Si sus datos contienen datos no estructurados basados en objetos, plantéese la posibilidad de utilizar concesiones de acceso a Amazon S3 para administrar el acceso a los datos.
**Topics**
+ [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md)
+ [Registro de una ubicación de Amazon S3](register-location.md)
+ [Registro de una ubicación cifrada de Amazon S3](register-encrypted.md)
+ [Registrar una ubicación de Amazon S3 en otra AWS cuenta](register-cross-account.md)
+ [Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas](register-cross-encrypted.md)
+ [Dar de baja el registro de una ubicación de Amazon S3](unregister-location.md)
# Requisitos de los roles utilizados para registrar ubicaciones
Debe especificar un rol AWS Identity and Access Management (IAM) al registrar una ubicación de Amazon Simple Storage Service (Amazon S3). AWS Lake Formation asume esa función al acceder a los datos en esa ubicación.
Para registrar una ubicación, puede utilizar uno de los siguientes tipos de rol:
+ El rol vinculado al servicio de Lake Formation. Este rol concede los permisos necesarios sobre la ubicación. Utilizar este rol es la forma más sencilla de registrar la ubicación. Para obtener más información, consulte [Uso de roles vinculados a servicios para Lake Formation](service-linked-roles.md) y [Limitaciones de los roles vinculados a servicios](service-linked-role-limitations.md).
+ Un rol definido por el usuario. Utilice un rol definido por el usuario cuando necesite conceder más permisos de los que proporciona el rol vinculado al servicio.
Debe utilizar un rol definido por el usuario en las circunstancias siguientes:
+ Al registrar una ubicación en otra cuenta.
Para obtener más información, consulte [Registrar una ubicación de Amazon S3 en otra AWS cuenta](register-cross-account.md) y [Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas](register-cross-encrypted.md).
+ Si utilizó una CMK (`aws/s3`) AWS administrada para cifrar la ubicación de Amazon S3.
Para obtener más información, consulte [Registro de una ubicación cifrada de Amazon S3](register-encrypted.md).
+ Si tiene previsto acceder a la ubicación mediante Amazon EMR.
Si ya ha registrado una ubicación con el rol vinculado al servicio y desea comenzar a acceder a la ubicación con Amazon EMR, deberá anular el registro de la ubicación y volver a registrarla con un rol definido por el usuario. Para obtener más información, consulte [Dar de baja el registro de una ubicación de Amazon S3](unregister-location.md).
# Uso de roles vinculados a servicios para Lake Formation
AWS Lake Formation *utiliza un rol vinculado a un servicio AWS Identity and Access Management (IAM).* Un rol vinculado a un servicio es un tipo único de rol de IAM que está vinculado directamente a Lake Formation. Lake Formation predefine la función vinculada al servicio e incluye todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre.
Un rol vinculado a un servicio simplifica la configuración de Lake Formation porque ya no tendrá que agregar manualmente los permisos necesarios. Lake Formation define los permisos de su rol vinculado al servicio y, a menos que se defina lo contrario, solo Lake Formation puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se puede asociar a ninguna otra entidad de IAM.
Este rol vinculado a servicios confía en los siguientes servicios para asumir el rol:
+ `lakeformation.amazonaws.com`
Cuando se utiliza un rol vinculado a un servicio en la cuenta A para registrar una ubicación de Amazon S3 propiedad de la cuenta B, la política de bucket de Amazon S3 (una política basada en recursos) de la cuenta B debe conceder permisos de acceso al rol vinculado al servicio de la cuenta A.
Para obtener información sobre el uso del rol vinculado a un servicio para registrar una ubicación de datos, consulte [Limitaciones de los roles vinculados a servicios](service-linked-role-limitations.md).
**nota**
Las políticas de control de servicios (SCPs) no afectan a las funciones vinculadas al servicio.
Para obtener más información, consulte [las políticas de control de servicios (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la guía del *AWS Organizations usuario*.
## Permisos de rol vinculados al servicio para Lake Formation
Lake Formation utiliza el rol vinculado al servicio denominado `AWSServiceRoleForLakeFormationDataAccess`. Esta función proporciona un conjunto de permisos de Amazon Simple Storage Service (Amazon S3) que permiten al servicio integrado de Lake Formation (por ejemplo) acceder a Amazon Athena las ubicaciones registradas. Al registrar una ubicación de lago de datos, debe proporcionar un rol que tenga los read/write permisos de Amazon S3 necesarios en esa ubicación. En lugar de crear un rol con los permisos de Amazon S3 que se requieren, puede utilizar este rol vinculado con un servicio.
La primera vez que nombre el rol vinculado al servicio como rol con el que registrar una ruta, el rol vinculado al servicio y una nueva política de IAM se crearán en su nombre. Lake Formation añade la ruta a la política insertada y la adjunta al rol vinculado al servicio. Cuando registre rutas posteriores con el rol vinculado al servicio, Lake Formation añade la ruta a la política existente.
Inicie sesión como administrador del lago de datos y registre una ubicación del lago de datos. A continuación, en la consola de IAM, busque el rol `AWSServiceRoleForLakeFormationDataAccess` y vea sus políticas adjuntas.
Por ejemplo, después de registrar la ubicación `s3://my-kinesis-test/logs`, Lake Formation crea la siguiente política en línea y la adjunta a `AWSServiceRoleForLakeFormationDataAccess`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LakeFormationDataAccessPermissionsForS3",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": [
"arn:aws:s3:::my-kinesis-test/logs/*"
]
},
{
"Sid": "LakeFormationDataAccessPermissionsForS3ListBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": [
"arn:aws:s3:::my-kinesis-test"
]
}
]
}
```
------
## Creación de un rol vinculado a servicio para Lake Formation
No necesita crear manualmente un rol vinculado a servicios. Cuando registra una ubicación de Amazon S3 con Lake Formation en la Consola de administración de AWS, la AWS CLI o la AWS API, Lake Formation crea el rol vinculado al servicio para usted.
**importante**
Este rol vinculado a servicios puede aparecer en su cuenta si se ha completado una acción en otro servicio que utilice las características compatibles con este rol. Para obtener más información, consulte [Un nuevo rol ha aparecido en mi cuenta de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al registrar una ubicación de Amazon S3 en Lake Formation, Lake Formation crea automáticamente el rol vinculado al servicio.
También puede utilizar la consola de IAM para crear un rol vinculado a servicio con el caso de uso de **Lake Formation**. En la AWS CLI o en la AWS API, cree una función vinculada al servicio con el nombre del servicio. `lakeformation.amazonaws.com` Para obtener más información, consulte [Crear un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) en la *Guía del usuario de IAM*. Si elimina este rol vinculado al servicio, puede utilizar este mismo proceso para volver a crear el rol.
## Edición de un rol vinculado a servicio para Lake Formation
Lake Formation no le permite editar el rol vinculado a servicio `AWSServiceRoleForLakeFormationDataAccess`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Edición de un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminación de un rol vinculado a servicio para Lake Formation
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. Así no tendrá una entidad no utilizada que no se supervise ni mantenga de forma activa. Sin embargo, debe limpiar los recursos de su rol vinculado al servicio antes de eliminarlo manualmente.
**nota**
Si el servicio de Lake Formation está utilizando el rol cuando intente eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
**Para eliminar los recursos de Lake Formation utilizados por Lake Formation**
+ Si ha utilizado el rol vinculado al servicio para registrar las ubicaciones de Amazon S3 en Lake Formation, antes de eliminar el rol vinculado al servicio, debe anular el registro de la ubicación y volver a registrarla con un rol personalizado.
**Para eliminar manualmente el rol vinculado a servicios mediante IAM**
Utilice la consola de IAM AWS CLI, la o la AWS API para eliminar la función vinculada al `AWSServiceRoleForLakeFormationDataAccess` servicio. Para obtener más información, consulte [Eliminación de un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
Los siguientes son los requisitos para un rol definido por el usuario:
+ Al crear el nuevo rol, en la página **Crear rol** de la consola de IAM, elija el **Servicio de AWS ** y, a continuación, en **Elija un caso de uso**, seleccione **Lake Formation**.
Si crea el rol utilizando una ruta diferente, asegúrese de que el rol tenga una relación de confianza con `lakeformation.amazonaws.com`. Para obtener más información, consulte [Modificación de una política de confianza de rol (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html).
+ El rol debe tener una política en línea que conceda read/write permisos a Amazon S3 en la ubicación. La siguiente es una política característica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::awsexamplebucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::awsexamplebucket"
]
}
]
}
```
------
+ Agregue la siguiente política de confianza al rol de IAM para permitir que el servicio de Lake Formation asuma el rol y dispense credenciales temporales a los motores de análisis integrados.
Para incluir el contexto de usuario del IAM Identity Center en los CloudTrail registros, la política de confianza debe tener el permiso para realizar la `sts:SetContext` acción.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerAssumeRole1",
"Effect": "Allow",
"Principal": {
"Service": [
"lakeformation.amazonaws.com"
]
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
]
}
```
------
+ El administrador del lago de datos que registra la ubicación debe tener el permiso `iam:PassRole` para el rol.
La siguiente es una política insertada que concede este permiso. **Sustitúyalo por un número de AWS cuenta válido y ** sustitúyalo por el nombre del rol.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PassRolePermissions",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/"
]
}
]
}
```
------
+ Para permitir que Lake Formation añada CloudWatch registros en Logs y publique métricas, añada la siguiente política en línea.
**nota**
Escribir en CloudWatch Logs conlleva un cargo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Sid1",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*",
"arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*:log-stream:*"
]
}
]
}
```
------
# Registro de una ubicación de Amazon S3
Debe especificar un rol AWS Identity and Access Management (IAM) al registrar una ubicación de Amazon Simple Storage Service (Amazon S3). Lake Formation asume esa función cuando otorga credenciales temporales a los AWS servicios integrados que acceden a los datos en esa ubicación.
**importante**
Evite registrar un bucket de Amazon S3 que tenga activada la opción **El solicitante paga**. Para los buckets registrados en Lake Formation, el rol utilizado para registrar el bucket se considera siempre como el solicitante. Si otra AWS cuenta accede al depósito, se le cobrará al propietario del depósito por el acceso a los datos si el rol pertenece a la misma cuenta que el propietario del depósito.
Puede usar la AWS Lake Formation consola, la API de Lake Formation o AWS Command Line Interface (AWS CLI) para registrar una ubicación de Amazon S3.
**Antes de empezar**
Revise los [requisitos del rol utilizado para registrar la ubicación](registration-role.md).
**Para registrar una ubicación (consola)**
**importante**
En los siguientes procedimientos se supone que la ubicación de Amazon S3 se encuentra en la misma AWS cuenta que el catálogo de datos y que los datos de la ubicación no están cifrados. Otras secciones de este capítulo tratan sobre el registro entre cuentas y el registro de ubicaciones cifradas.
1. Abra la AWS Lake Formation consola en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Inicie sesión como administrador del lago de datos o como usuario con el permiso de `lakeformation:RegisterResource` IAM.
1. En el panel de navegación, en **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. Elija **Registrar ubicación** y, a continuación, seleccione **Examinar** para seleccionar una ruta de Amazon Simple Storage Service (Amazon S3).
1. (Opcional, pero muy recomendable) Seleccione **Revisar permisos de ubicación** para ver una lista de todos los recursos existentes en la ubicación de Amazon S3 seleccionada y sus permisos.
El registro de la ubicación seleccionada podría dar lugar a que sus usuarios de Lake Formation accedan a los datos que ya se encuentran en esa ubicación. Revisar esta lista ayuda a garantizar que los datos existentes permanecen seguros.
1. Para el **rol de IAM**, elija el rol vinculado al servicio `AWSServiceRoleForLakeFormationDataAccess` (valor predeterminado) o un rol de IAM personalizado que cumpla los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md).
Puede actualizar una ubicación registrada u otros detalles solo si la registra con un rol de IAM personalizado. Para editar una ubicación registrada con un rol vinculado a un servicio, debe anular el registro de la ubicación y volver a registrarla.
1. Elija la opción **Habilitar la federación de catálogos de datos** para permitir que Lake Formation asuma un rol y venda credenciales temporales a AWS servicios integrados para acceder a las tablas de bases de datos federadas. Si una ubicación está registrada en Lake Formation y desea utilizar la misma ubicación para una tabla en una base de datos federada, deberá registrar la misma ubicación con la opción **Habilitar federación del Catálogo de datos**.
1. Seleccione el **modo de acceso híbrido** para no habilitar los permisos de Lake Formation de forma predeterminada. Cuando registre la ubicación de Amazon S3 en modo de acceso híbrido, puede habilitar los permisos de Lake Formation optando por entidades principales para las bases de datos y las tablas bajo esa ubicación.
Para más información sobre la configuración del modo de acceso híbrido, consulte [Modo de acceso híbrido](hybrid-access-mode.md).
1. Seleccione **Registrar ubicación.**
**Para registrar una ubicación (AWS CLI)**
1.
**Registro de una nueva ubicación en Lake Formation**
Este ejemplo usa el rol vinculado a un servicio para registrar la ubicación. En su lugar, puede utilizar el argumento `--role-arn` para proporcionar su propio rol.
**Sustitúyalo por una ruta de Amazon S3 válida, el número de AWS cuenta por una cuenta válida y ** por un rol de IAM que tenga permisos para registrar una ubicación de datos.
**nota**
No puede editar las propiedades de una ubicación registrada si está registrada con un rol vinculado a un servicio.
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--use-service-linked-role
```
En el siguiente ejemplo, se utiliza un rol personalizado para registrar la ubicación.
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--role-arn arn:aws:iam::<123456789012>:role/
```
1.
**Para actualizar una ubicación registrada con Lake Formation**
Puede editar una ubicación registrada solo si está registrada con un rol de IAM personalizado. en el caso de una ubicación registrada con un rol vinculado a un servicio, debe anular el registro de la ubicación y volver a registrarla. Para obtener más información, consulte [Dar de baja el registro de una ubicación de Amazon S3](unregister-location.md).
```
aws lakeformation update-resource \
--role-arn arn:aws:iam::<123456789012>:role/\
--resource-arn arn:aws:s3:::
```
```
aws lakeformation update-resource \
--resource-arn arn:aws:s3::: \
--use-service-linked-role
```
1.
**Registrar una ubicación de datos en modo de acceso híbrido con federación**
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--role-arn arn:aws:iam::<123456789012>:role/ \
--hybrid-access-enabled
```
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--role-arn arn:aws:iam::<123456789012>:role/ \
--with-federation
```
```
aws lakeformation update-resource \
--resource-arn arn:aws:s3::: \
--role-arn arn:aws:iam::<123456789012>:role/ \
--hybrid-access-enabled
```
Para obtener más información, consulte Funcionamiento de [RegisterResource](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_RegisterResource.html)la API.
**nota**
Una vez que registre una ubicación de Amazon S3, cualquier AWS Glue tabla que apunte a la ubicación (o a cualquiera de sus ubicaciones secundarias) devolverá el valor del `IsRegisteredWithLakeFormation` parámetro tal y como `true` aparece en la `GetTable` llamada. Existe una limitación conocida por la que las operaciones de la API del Catálogo de datos como `GetTables` y `SearchTables` no actualizan el valor del parámetro `IsRegisteredWithLakeFormation` y devuelven el valor predeterminado, que es falso. Se recomienda utilizar la API`GetTable` para ver el valor correcto del parámetro `IsRegisteredWithLakeFormation`.
# Registro de una ubicación cifrada de Amazon S3
Lake Formation se integra con [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS) para permitirle configurar más fácilmente otros servicios integrados para cifrar y descifrar datos en ubicaciones de Amazon Simple Storage Service (Amazon S3).
Tanto las gestionadas por AWS KMS keys el cliente como Claves administradas por AWS las compatibles. Actualmente, el lado del cliente solo encryption/decryption es compatible con Athena.
Debe especificar un rol AWS Identity and Access Management (de IAM) al registrar una ubicación de Amazon S3. En el caso de las ubicaciones cifradas de Amazon S3, el rol debe tener permiso para cifrar y descifrar datos con el AWS KMS key, o bien la política de claves de KMS debe conceder permisos sobre la clave del rol.
**importante**
Evite registrar un bucket de Amazon S3 que tenga activada la opción **El solicitante paga**. Para los buckets registrados en Lake Formation, el rol utilizado para registrar el bucket se considera siempre como el solicitante. Si otra AWS cuenta accede al bucket, se le cobrará al propietario del bucket por el acceso a los datos si el rol pertenece a la misma cuenta que el propietario del bucket.
Lake Formation usa un rol vinculado a servicio para registrar las ubicaciones de los datos. Sin embargo, este rol tiene varias [limitaciones](service-linked-role-limitations.md). Debido a estas limitaciones, recomendamos crear y usar un rol de IAM personalizado en su lugar, para mayor flexibilidad y control. El rol personalizado que cree para registrar la ubicación debe cumplir los requisitos especificados en [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md).
**importante**
Si ha utilizado una Clave administrada de AWS para cifrar la ubicación de Amazon S3, no puede utilizar la función vinculada al servicio Lake Formation. Debe usar un rol personalizado y añadir permisos de IAM a la clave del rol. Los detalles se proporcionan más adelante en esta sección.
Los siguientes procedimientos explican cómo registrar una ubicación de Amazon S3 cifrada con una clave administrada por el cliente o una Clave administrada de AWS.
+ [Registrar una ubicación cifrada con una clave administrada por el cliente](#proc-register-cust-cmk)
+ [Registrar una ubicación cifrada con un Clave administrada de AWS](#proc-register-aws-cmk)
**Antes de empezar**
Revise los [requisitos del rol utilizado para registrar la ubicación](registration-role.md).
**Para registrar una ubicación de Amazon S3 cifrada con una clave administrada por el cliente**
**nota**
Si la clave de KMS o la ubicación de Amazon S3 no están en la misma AWS cuenta que el catálogo de datos, siga las instrucciones que se indican en [Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas](register-cross-encrypted.md) su lugar.
1. Abra la AWS KMS consola en [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) e inicie sesión como usuario administrativo AWS Identity and Access Management (IAM) o como usuario que puede modificar la política de claves de la clave de KMS utilizada para cifrar la ubicación.
1. En el panel de navegación, elija **Claves administradas por el cliente** y, a continuación, el nombre de la clave de KMS deseada.
1. En la página de detalles de la clave KMS, elija la pestaña **Política de claves** y, a continuación, siga una de las instrucciones siguientes para añadir su rol personalizado o el rol vinculado al servicio de Lake Formation como usuario de la clave KMS:
+ **Si se muestra la vista predeterminada** (con las secciones **Administradores clave****, Eliminación** de claves, **Usuarios clave** y **Otras AWS cuentas**), en la sección **Usuarios clave**, agregue su rol personalizado o el rol vinculado al servicio Lake Formation. `AWSServiceRoleForLakeFormationDataAccess`
+ **Si se muestra la política de claves (JSON)**. Edite la política para añadir su rol personalizado o el rol `AWSServiceRoleForLakeFormationDataAccess` vinculado al servicio de Lake Formation al objeto "Permitir el uso de la clave", como se muestra en el siguiente ejemplo.
**nota**
Si falta ese objeto, agréguelo con los permisos que se muestran en el ejemplo. El ejemplo utiliza el rol vinculado al servicio.
```
...
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess",
"arn:aws:iam::111122223333:user/keyuser"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
...
```
1. Abra la AWS Lake Formation consola en. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Inicie sesión como administrador del lago de datos o como usuario con el permiso de `lakeformation:RegisterResource` IAM.
1. En el panel de navegación, bajo **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. Elija **Registrar ubicación** y, a continuación, seleccione **Examinar** para seleccionar una ruta de Amazon Simple Storage Service (Amazon S3).
1. (Opcional, pero muy recomendable) Seleccione **Revisar permisos de ubicación** para ver una lista de todos los recursos existentes en la ubicación de Amazon S3 seleccionada y sus permisos.
El registro de la ubicación seleccionada podría dar lugar a que sus usuarios de Lake Formation accedan a los datos que ya se encuentran en esa ubicación. Revisar esta lista ayuda a garantizar que los datos existentes permanecen seguros.
1. Para el **rol de IAM**, elija el rol vinculado al servicio `AWSServiceRoleForLakeFormationDataAccess` (el predeterminado) o su rol personalizado que cumpla con el [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md).
1. Seleccione **Registrar ubicación**.
Para obtener más información sobre el rol vinculado a servicios, consulte [Permisos de rol vinculados al servicio para Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Para registrar una ubicación de Amazon S3 cifrada con un Clave administrada de AWS**
**importante**
Si la ubicación de Amazon S3 no está en la misma AWS cuenta que el catálogo de datos, siga las instrucciones que se indican en [Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas](register-cross-encrypted.md) su lugar.
1. Cree un rol de IAM que se utilizará para registrar la ubicación. Asegúrese de que cumple los requisitos que figuran en [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md).
1. Añada la siguiente política insertada al rol. Concede permisos sobre la clave al rol. La especificación `Resource` debe designar el nombre de recurso de Amazon (ARN) del Clave administrada de AWS. Puede obtener el ARN desde la AWS KMS consola. Para obtener el ARN correcto, asegúrese de iniciar sesión en la AWS KMS consola con la misma AWS cuenta y región Clave administrada de AWS que utilizó para cifrar la ubicación.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
]
}
```
------
Puede utilizar los alias de clave de KMS en lugar del ID de clave (`arn:aws:kms:region:account-id:key/alias/your-key-alias`).
Para obtener más información, consulte la AWS KMS sección [Alias de la](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html) Guía para desarrolladores. AWS Key Management Service
1. Abra la AWS Lake Formation consola en. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Inicie sesión como administrador del lago de datos o como usuario con el permiso de `lakeformation:RegisterResource` IAM.
1. En el panel de navegación, bajo **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. Elija **Registrar ubicación** y, a continuación, seleccione **Examinar** para seleccionar una ruta de Amazon S3.
1. (Opcional, pero muy recomendable) Seleccione **Revisar permisos de ubicación** para ver una lista de todos los recursos existentes en la ubicación de Amazon S3 seleccionada y sus permisos.
El registro de la ubicación seleccionada podría dar lugar a que sus usuarios de Lake Formation accedan a los datos que ya se encuentran en esa ubicación. Revisar esta lista ayuda a garantizar que los datos existentes permanecen seguros.
1. Para **Rol de IAM**, elija el rol que ha creado en el Paso 1.
1. Seleccione **Registrar ubicación**.
# Registrar una ubicación de Amazon S3 en otra AWS cuenta
AWS Lake Formation le permite registrar las ubicaciones AWS de Amazon Simple Storage Service (Amazon S3) en todas las cuentas. Por ejemplo, si AWS Glue Data Catalog está en la cuenta A, un usuario de la cuenta A puede registrar un bucket de Amazon S3 en la cuenta B.
Para registrar un bucket de Amazon S3 en la AWS cuenta B con un rol AWS Identity and Access Management (IAM) en la AWS cuenta A se requieren los siguientes permisos:
+ El rol de la cuenta A debe conceder permisos sobre el bucket de la cuenta B.
+ La política de bucket de la cuenta B debe conceder permisos de acceso al rol de la cuenta A.
**importante**
Evite registrar un bucket de Amazon S3 que tenga activada la opción **El solicitante paga**. Para los buckets registrados en Lake Formation, el rol utilizado para registrar el bucket se considera siempre como el solicitante. Si otra AWS cuenta accede al bucket, se le cobrará al propietario del bucket por el acceso a los datos si el rol pertenece a la misma cuenta que el propietario del bucket.
No puede utilizar el rol vinculado al servicio Lake Formation para registrar una ubicación en otra cuenta. En su lugar, debe utilizar un rol definido por el usuario. El rol debe cumplir los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md). Para obtener más información sobre el rol vinculado a servicios, consulte [Permisos de rol vinculados al servicio para Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Antes de empezar**
Revise los [requisitos del rol utilizado para registrar la ubicación](registration-role.md).
**Para registrar una ubicación en otra AWS cuenta**
**nota**
Si la ubicación está cifrada, siga en su lugar las instrucciones de [Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas](register-cross-encrypted.md).
El siguiente procedimiento supone que una entidad principal de la cuenta 1111-2222-3333, que contiene el Catálogo de datos, desea registrar el bucket `awsexamplebucket1` de Amazon S3, que se encuentra en la cuenta 1234-5678-9012.
1. En la cuenta 1111-2222-3333, inicie sesión en Consola de administración de AWS y abra la consola de IAM en. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Cree un nuevo rol o consulte uno existente que cumpla con los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md). Asegúrese de que el rol concede permisos de Amazon S3 a`awsexamplebucket1`.
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). Inicie sesión con la cuenta 1234-5678-9012.
1. En la lista **Nombre del bucket**, seleccione el nombre del bucket, `awsexamplebucket1`.
1. Elija **Permisos**.
1. En la página **Permisos**, elija **Política de bucket**.
1. En el **editor de políticas de bucket**, pegue la política siguiente. Sustituya ** por el nombre de su rol.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Principal": {
"AWS":"arn:aws:iam::111122223333:role/"
},
"Action":"s3:ListBucket",
"Resource":"arn:aws:s3:::awsexamplebucket1"
},
{
"Effect":"Allow",
"Principal": {
"AWS":"arn:aws:iam::111122223333:role/"
},
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject"
],
"Resource":"arn:aws:s3:::awsexamplebucket1/*"
}
]
}
```
------
1. Seleccione **Save**.
1. Abre la consola en. AWS Lake Formation [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Inicie sesión en la cuenta 1111-2222-3333 como administrador del lago de datos o como usuario con permisos suficientes para registrar ubicaciones.
1. En el panel de navegación, bajo **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. En la página de **Ubicaciones de los lagos de datos**, seleccione **Registrar ubicación**.
1. En la página **Registrar ubicación**, para la **ruta de Amazon S3**, introduzca el nombre del bucket `s3://awsexamplebucket1`.
**nota**
Debe escribir el nombre del bucket porque los buckets entre cuentas no aparecen en la lista cuando selecciona **Examinar**.
1. En **Rol de IAM**, seleccione su rol.
1. Seleccione **Registrar ubicación**.
# Registro de una ubicación de Amazon S3 cifrada en todas AWS las cuentas
AWS Lake Formation se integra con [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)(AWS KMS) para permitirle configurar más fácilmente otros servicios integrados para cifrar y descifrar datos en las ubicaciones de Amazon Simple Storage Service (Amazon S3).
Ambas son claves administradas por el cliente y Claves administradas por AWS son compatibles. No se admite el lado del cliente encryption/decryption .
**importante**
Evite registrar un bucket de Amazon S3 que tenga activada la opción **El solicitante paga**. Para los buckets registrados en Lake Formation, el rol utilizado para registrar el bucket se considera siempre como el solicitante. Si otra AWS cuenta accede al depósito, se le cobrará al propietario del depósito por el acceso a los datos si el rol pertenece a la misma cuenta que el propietario del depósito.
En esta sección se explica cómo registrar una ubicación de Amazon S3 en las siguientes circunstancias:
+ Los datos de la ubicación de Amazon S3 se cifran con una clave KMS creada en AWS KMS.
+ La ubicación de Amazon S3 no está en la misma AWS cuenta que la AWS Glue Data Catalog.
+ La clave de KMS está o no en la misma AWS cuenta que el catálogo de datos.
Para registrar un bucket de Amazon S3 AWS KMS cifrado en la AWS cuenta B con un rol AWS Identity and Access Management (IAM) en la AWS cuenta A se requieren los siguientes permisos:
+ El rol de la cuenta A debe conceder permisos sobre el bucket de la cuenta B.
+ La política de bucket de la cuenta B debe conceder permisos de acceso al rol de la cuenta A.
+ Si la clave de KMS está en la cuenta B, la política de claves debe conceder el acceso al rol de la cuenta A y el rol de la cuenta A debe conceder permisos sobre la clave de KMS.
En el siguiente procedimiento, se crea un rol en la AWS cuenta que contiene el catálogo de datos (la cuenta A en el análisis anterior). A continuación, utilice este rol para registrar la ubicación. Lake Formation asume este rol al acceder a los datos subyacentes en Amazon S3. El rol asumido tiene los permisos necesarios en la clave de KMS. Como resultado, no tendrá que conceder permisos sobre la clave KMS a las entidades principales que accedan a los datos subyacentes con trabajos ETL o con servicios integrados como Amazon Athena.
**importante**
No puede utilizar el rol vinculado al servicio Lake Formation para registrar una ubicación en otra cuenta. En su lugar, debe utilizar un rol definido por el usuario. El rol debe cumplir los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md). Para obtener más información sobre el rol vinculado a servicios, consulte [Permisos de rol vinculados al servicio para Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Antes de empezar**
Revise los [requisitos del rol utilizado para registrar la ubicación](registration-role.md).
**Para registrar una ubicación de Amazon S3 cifrada en todas AWS las cuentas**
1. En la misma AWS cuenta que el catálogo de datos, inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Cree un nuevo rol o consulte uno existente que cumpla con los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md). Asegúrese de que el rol incluye una política que concede permisos de Amazon S3 en la ubicación.
1. Si la clave de KMS no está en la misma cuenta que el Catálogo de datos, añada al rol una política integrada que conceda los permisos necesarios para la clave de KMS. A continuación, se muestra una política de ejemplo. Sustituya Región e ID de cuenta por la región y el número de cuenta de la clave de KMS. **Sustitúyala por el identificador de clave.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/"
}
]
}
```
------
1. En la consola de Amazon S3, agregue una política de bucket que conceda los permisos de Amazon S3 necesarios para el rol. A continuación se muestra un ejemplo de política de bucket. Sustituya el ID de AWS cuenta por el número de cuenta del catálogo ** de datos, por el nombre de su función y ** por el nombre del depósito.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Principal": {
"AWS":"arn:aws:iam::111122223333:role/"
},
"Action":"s3:ListBucket",
"Resource":"arn:aws:s3:::"
},
{
"Effect":"Allow",
"Principal": {
"AWS":"arn:aws:iam::111122223333:role/"
},
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject"
],
"Resource":"arn:aws:s3:::/*"
}
]
}
```
------
1. En AWS KMS, agregue el rol como usuario de la clave KMS.
1. Abra la AWS KMS consola en [https://console.aws.amazon.com/kms.](https://console.aws.amazon.com/kms) A continuación, inicie sesión como usuario administrador o como usuario que puede modificar la política de claves de la clave de KMS utilizada para cifrar la ubicación.
1. En el panel de navegación, seleccione **Claves administradas por el cliente** y, a continuación, elija el nombre de la clave KMS.
1. En la página de detalles de la clave KMS, en la pestaña **Política de claves**, si no se muestra la vista JSON de la política de claves, seleccione **Cambiar a la vista de políticas**.
1. En la sección **Política de claves**, seleccione **Editar** y añada el Nombre de recurso de Amazon (ARN) del rol al objeto `Allow use of the key`, como se muestra en el siguiente ejemplo.
**nota**
Si falta ese objeto, agréguelo con los permisos que se muestran en el ejemplo.
```
...
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam:::role/"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
...
```
Para más información, consulte [Permitir a los usuarios de otras cuentas utilizar una clave KMS](https://docs.amazonaws.cn/en_us/kms/latest/developerguide/key-policy-modifying-external-accounts.html) en la *Guía para desarrolladores de AWS Key Management Service *.
1. Abra la AWS Lake Formation consola en. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Inicie sesión en la cuenta AWS del Catálogo de datos como administrador del lago de datos.
1. En el panel de navegación, bajo **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. Seleccione **Registrar ubicación**.
1. En la página **Registrar ubicación**, para la **ruta de Amazon S3**, introduzca el nombre del bucket como **s3://**/****. **Sustitúyalo por el nombre del depósito y ** por el resto de la ruta de la ubicación.
**nota**
Debe escribir la ruta porque los buckets entre cuentas no aparecen en la lista cuando selecciona **Examinar**.
1. Para el **rol de IAM**, elija el rol del paso 2.
1. Seleccione **Registrar ubicación**.
# Dar de baja el registro de una ubicación de Amazon S3
Puede anular el registro de una ubicación de Amazon Simple Storage Service (Amazon S3) si desea que Lake Formation deje de administrarla. Dar de baja una ubicación no afecta a los permisos de ubicación de datos de Lake Formation que se conceden sobre esa ubicación. Puede volver a registrar una ubicación que haya dado de baja y los permisos de ubicación de datos seguirán vigentes. Puede utilizar un rol diferente para volver a registrar la ubicación.
**Para dar de baja una ubicación (consola)**
1. Abra la AWS Lake Formation consola en. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Inicie sesión como administrador del lago de datos o como usuario con el permiso de `lakeformation:RegisterResource` IAM.
1. En el panel de navegación, bajo **Administración**, seleccione **Ubicaciones de los lagos de datos**.
1. Seleccione una ubicación y, en el menú **Acciones**, seleccione **Editar**.
1. Cuando se le indique que confirme, elija **Quitar**.
# Modo de acceso híbrido
AWS Lake Formation el *modo de acceso híbrido* admite dos vías de permiso para los mismos AWS Glue Data Catalog objetos.
En la primera, Lake Formation permite seleccionar entidades principales específicas y concederles permisos de Lake Formation para acceder a catálogos, bases de datos, tablas y vistas mediante inscripción. La segunda vía permite a todos los demás responsables acceder a estos recursos a través de las políticas principales de IAM predeterminadas para Amazon S3 y AWS Glue sus acciones.
Al registrar una ubicación de Amazon S3 en Lake Formation, tiene la opción de aplicar los permisos de Lake Formation para todos los recursos de esta ubicación o utilizar el modo de acceso híbrido. El modo de acceso híbrido solo aplica los permisos `CREATE_TABLE`, `CREATE_PARTITION` y `UPDATE_TABLE` de forma predeterminada. Cuando una ubicación de Amazon S3 se encuentra en el modo híbrido, puede habilitar los permisos de Lake Formation inscribiendo entidades principales para los objetos del Catálogo de datos de esa ubicación. Esto significa que tanto los permisos de Lake Formation como los permisos de IAM pueden controlar el acceso a esos datos. Esto significa que los directores inscritos necesitarán tanto los permisos de Lake Formation como los permisos de IAM para acceder a los datos, mientras que los non-opted-in directores seguirán accediendo a los datos únicamente con los permisos de IAM.
Así, el modo de acceso híbrido proporciona la flexibilidad necesaria para habilitar de forma selectiva Lake Formation para catálogos, bases de datos y tablas de su Catálogo de datos para un conjunto específico de usuarios sin interrumpir el acceso para otros usuarios o cargas de trabajo existentes.
![\[Cuenta de AWS architecture showing data flow between S3, Glue, Lake Formation, Athena, and IAM roles.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/hybrid-access-mode-concept.png)
Para ver las consideraciones y limitaciones, consulte [Consideraciones y limitaciones del modo de acceso híbrido](notes-hybrid.md).Términos y definiciones
A continuación se detallan las definiciones de los recursos del Catálogo de datos según la configuración de los permisos de acceso:
Recurso de Lake Formation
Un recurso registrado con Lake Formation. Los usuarios necesitan permisos de Lake Formation para acceder al recurso.
AWS Glue recurso
Un recurso que no está registrado con Lake Formation. Los usuarios solo necesitan permisos de IAM para acceder al recurso porque tiene permisos de grupo `IAMAllowedPrincipals`. Los permisos de Lake Formation no se aplican.
Para obtener más información sobre los permisos de grupo de `IAMAllowedPrincipals`, consulte [Permisos de metadatos](metadata-permissions.md).
Recursos híbridos
Recursos registrados en modo de acceso híbrido. En función de los usuarios que accedan al recurso, este cambia dinámicamente entre ser un recurso de Lake Formation o un recurso de AWS Glue .
## Casos de uso comunes del modo de acceso híbrido
Puede utilizar el modo de acceso híbrido para proporcionar acceso en escenarios de uso compartido de datos de una sola cuenta y entre cuentas:
**Escenarios de una sola cuenta**
+ **Convertir un AWS Glue recurso en un recurso híbrido**: en este escenario, actualmente no está utilizando Lake Formation, pero desea adoptar los permisos de Lake Formation para los objetos del catálogo de datos. Al registrar la ubicación de Amazon S3 en modo de acceso híbrido, puede conceder permisos de Lake Formation a los usuarios que opten por acceder a bases de datos y tablas específicas que apunten a esa ubicación.
+ **Convertir un recurso de Lake Formation en un recurso híbrido**: actualmente, utiliza los permisos de Lake Formation para controlar el acceso a una base de datos del Catálogo de datos, pero desea proporcionar acceso a nuevas entidades principales mediante los permisos de IAM para Amazon S3 y AWS Glue sin interrumpir los permisos de Lake Formation existentes.
Al actualizar el registro de una ubicación de datos al modo de acceso híbrido, las nuevas entidades principales pueden acceder a la base de datos del Catálogo de datos que apunta a la ubicación de Amazon S3 mediante las políticas de permisos de IAM sin interrumpir los permisos de Lake Formation de los usuarios existentes.
Antes de actualizar el registro de ubicación de datos para habilitar el modo de acceso híbrido, primero debe seleccionar las entidades principales que acceden ahora al recurso con permisos de Lake Formation.
Esto tiene como objetivo evitar una posible interrupción del flujo de trabajo actual.
También debe conceder permiso de `Super` sobre las tablas de la base de datos al grupo `IAMAllowedPrincipal`.
**Escenarios de uso compartido de datos entre cuentas**
+ **Comparta AWS Glue recursos mediante el modo de acceso híbrido**: en este escenario, la cuenta del productor tiene tablas en una base de datos que actualmente se comparten con una cuenta de consumidor mediante políticas de permisos de IAM para Amazon S3 y AWS Glue acciones. La ubicación de los datos de la base de datos no está registrada en Lake Formation.
Antes de registrar la ubicación de los datos en el modo de acceso híbrido, debe actualizar la **configuración de la versión entre cuentas** a la versión 4. La versión 4 proporciona las nuevas políticas de AWS RAM permisos necesarias para compartir entre cuentas cuando el `IAMAllowedPrincipal` grupo tiene `Super` permiso sobre el recurso. Para los recursos con permisos de grupo `IAMAllowedPrincipal`, puede conceder permisos de Lake Formation a cuentas externas y optar por que utilicen los permisos de Lake Formation. El administrador del lago de datos de la cuenta receptora puede conceder permisos de Lake Formation a entidades principales de la cuenta y optar por ellos para aplicar los permisos de Lake Formation.
+ **Compartir recursos de Lake Formation utilizando el modo de acceso híbrido**: en la actualidad, la cuenta de productor tiene tablas en una base de datos que se comparten con una cuenta de consumidor que aplica los permisos de Lake Formation. La ubicación de los datos de la base de datos no está registrada en Lake Formation.
En este caso, puede actualizar el registro de ubicación de Amazon S3 al modo de acceso híbrido y compartir los datos de Amazon S3 y los metadatos del Catálogo de datos mediante las políticas de bucket de Amazon S3 y las políticas de recursos del Catálogo de datos con las entidades principales de la cuenta del consumidor. Debe volver a conceder los permisos existentes de Lake Formation y optar por las entidades principales antes de actualizar el registro de la ubicación de Amazon S3. También debe conceder permiso de `Super` sobre las tablas de la base de datos al grupo `IAMAllowedPrincipals`.
**Topics**
+ [Casos de uso comunes del modo de acceso híbrido](#hybrid-access-mode-use-cases)
+ [Cómo funciona el modo de acceso híbrido](hybrid-access-workflow.md)
+ [Configuración del modo de acceso híbrido: escenarios comunes](hybrid-access-setup.md)
+ [Eliminación de entidades principales y recursos del modo de acceso híbrido](delete-hybrid-access.md)
+ [Eliminación de entidades principales y recursos del modo de acceso híbrido](view-hybrid-access.md)
+ [Recursos adicionales](additional-resources-hybrid.md)
# Cómo funciona el modo de acceso híbrido
El diagrama siguiente muestra cómo funciona la autorización de Lake Formation en el modo de acceso híbrido al consultar los recursos del Catálogo de datos.
![\[AWS Lake Formation authorization process flowchart for hybrid access mode queries.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/hybrid-workflow.png)
Antes de acceder a los datos del lago de datos, un administrador de este o un usuario con permisos administrativos configura políticas de usuario individuales de las tablas del Catálogo de datos para permitir o denegar el acceso a las tablas del Catálogo de datos. Luego, una entidad principal con permisos para la operación de `RegisterResource` registra en Lake Formation la ubicación de Amazon S3 de la tabla en modo de acceso híbrido. Si una ubicación de datos no está registrada con Lake Formation, el administrador concede permisos de Lake Formation a usuarios específicos sobre las bases de datos y tablas del Catálogo de datos y los inscribe para utilizar los permisos de Lake Formation para esas bases de datos y tablas en modo de acceso híbrido.
1. **Envía una consulta**: un director envía una consulta o un script de ETL mediante un servicio integrado como Amazon Athena, Amazon EMR o AWS Glue Amazon Redshift Spectrum.
1. **Solicita datos**: el motor analítico integrado identifica la tabla solicitada y envía la solicitud de metadatos al Catálogo de datos (`GetTable`, `GetDatabase`)
1. **Comprueba los permisos**: el Catálogo de datos verifica los permisos de acceso de la entidad principal que hace la consulta con Lake Formation.
1. Si la tabla no tiene permisos de grupo `IAMAllowedPrincipals` adjuntos, se aplican los permisos de Lake Formation.
1. Si la entidad principal ha optado por utilizar los permisos de Lake Formation en el modo de acceso híbrido y la tabla tiene adjuntos permisos de grupo `IAMAllowedPrincipals`, se aplicarán los permisos de Lake Formation. El motor de consulta aplica los filtros que recibió de Lake Formation y devuelve los datos al usuario.
1. Si la ubicación de la tabla no está registrada en Lake Formation y la entidad principal no ha optado por utilizar los permisos de Lake Formation en el modo de acceso híbrido, el Catálogo de datos comprueba si la tabla tiene permisos de grupo `IAMAllowedPrincipals` adjuntos. Si existe este permiso sobre la tabla, todas las entidades principales de la cuenta obtienen los permisos `Super` o `All` sobre la tabla.
La venta de credenciales de Lake Formation no está disponible, incluso si se han inscrito, a menos que la ubicación de los datos esté registrada en Lake Formation.
1. **Obtener credenciales**: el Catálogo de datos comprueba y permite al motor saber si la ubicación de la tabla está registrada en Lake Formation o no. Si los datos subyacentes están registrados en Lake Formation, el motor analítico solicita a Lake Formation credenciales temporales para acceder a los datos del bucket de Amazon S3.
1. **Obtener datos**: si la entidad principal está autorizada para acceder a los datos de la tabla, Lake Formation proporciona acceso temporal al motor analítico integrado. Mediante el acceso temporal, el motor analítico obtiene los datos de Amazon S3 y aplica el filtrado necesario, como el de columnas, filas o celdas. Cuando el motor termina de ejecutar el trabajo, devuelve los resultados al usuario. Este proceso se denomina “expedición de credenciales”. Para obtener más información, consulte [Integración de servicios de terceros con Lake Formation](Integrating-with-LakeFormation.md).
1.
Si la ubicación de los datos de la tabla no está registrada en Lake Formation, la segunda llamada desde el motor analítico se hace directamente a Amazon S3. Para el acceso a los datos se evalúan la política de buckets de Amazon S3 y la política de usuarios de IAM correspondientes. Siempre que utilice políticas de IAM, compruebe que sigue las mejores prácticas IAM. Para obtener más información, consulte la sección [Prácticas recomendadas de IAM en la Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html).
# Configuración del modo de acceso híbrido: escenarios comunes
Al igual que con los permisos de Lake Formation, generalmente hay dos tipos de escenarios en los que puede usar el modo de acceso híbrido para administrar el acceso a los datos: proporcionar acceso a los directores dentro de uno Cuenta de AWS y proporcionar acceso a uno externo Cuenta de AWS o principal.
En esta sección se proporcionan instrucciones para configurar el modo de acceso híbrido en los escenarios siguientes:
**Administre los permisos en el modo de acceso híbrido desde un solo lugar Cuenta de AWS**
+ [Convertir un AWS Glue recurso en un recurso híbrido](hybrid-access-mode-new.md)— Actualmente proporciona acceso a las tablas de una base de datos a todos los directores de su cuenta mediante permisos de IAM para Amazon S3, AWS Glue pero desea adoptar Lake Formation para administrar los permisos de forma incremental.
+ [Convertir un recurso de Lake Formation en un recurso híbrido](hybrid-access-mode-update.md): actualmente utiliza Lake Formation para administrar el acceso a las tablas de una base de datos para todas las entidades principales de su cuenta, pero desea utilizar Lake Formation solo para determinadas entidades principales. Desea proporcionar acceso a los nuevos directores mediante el uso de permisos de IAM para AWS Glue Amazon S3 en la misma base de datos y tablas.
**Administre los permisos en modo de acceso híbrido en s Cuenta de AWS**
+ [Compartir un AWS Glue recurso mediante el modo de acceso híbrido](hybrid-access-mode-cross-account.md): actualmente no utiliza Lake Formation para gestionar los permisos de una tabla, pero desea aplicar los permisos de Lake Formation para proporcionar acceso a las entidades principales de otra cuenta.
+ [Compartir un recurso de Lake Formation mediante el modo de acceso híbrido](hybrid-access-mode-cross-account-IAM.md)— Utiliza Lake Formation para administrar el acceso a una tabla, pero desea proporcionar acceso a los directores de otra cuenta mediante permisos de IAM para Amazon S3 AWS Glue y en la misma base de datos y tablas.
**Configuración del modo de acceso híbrido: pasos generales**
1. Registre la ubicación de datos de Amazon S3 en Lake Formation seleccionando el **modo de acceso híbrido**.
1. Las entidades principales deben tener permisos de `DATA_LOCATION` en una ubicación de lago de datos para crear tablas o bases de datos del Catálogo de datos que apunten a esa ubicación.
1. Establezca la **configuración de la versión entre cuentas** en la Versión 4.
1. Conceda permisos específicos a roles o usuarios de IAM concretos en bases de datos y tablas. Al mismo tiempo, asegúrese de establecer permisos de `Super` o `All` para el grupo `IAMAllowedPrincipals` de la base de datos y para todas las tablas de la base de datos o para algunas de ellas.
1. Elija las entidades principales y los recursos. Los demás responsables de la cuenta pueden seguir accediendo a las bases de datos y tablas mediante las políticas de permisos de IAM AWS Glue y las acciones de Amazon S3.
1. También puede limpie las políticas de permisos de IAM para Amazon S3 para las entidades principales que hayan optado por usar los permisos de Lake Formation.
# Requisitos previos para configurar el modo de acceso híbrido
A continuación se detallan los requisitos previos para configurar el modo de acceso híbrido:
**nota**
Recomendamos que un administrador de Lake Formation registre la ubicación de Amazon S3 en modo de acceso híbrido y opte por entidades principales y recursos.
1. Otorgue el permiso de ubicación de datos (`DATA_LOCATION_ACCESS`) para crear recursos del Catálogo de datos que apunten a las ubicaciones de Amazon S3. Los permisos de ubicación de datos controlan la capacidad de crear catálogos, bases de datos y tablas del Catálogo de datos que apuntan a ubicaciones concretas de Amazon S3.
1. Para compartir los recursos del catálogo de datos con otra cuenta en modo de acceso híbrido (sin eliminar los permisos de `IAMAllowedPrincipals` grupo del recurso), debe actualizar la **configuración de la versión multicuenta** a la versión 4 o superior. Para actualizar la versión mediante la consola Lake Formation, elija la **versión 4** o la **versión 5** en la **configuración de la versión entre cuentas** en la página de **configuración del catálogo de datos**.
También puede usar el `put-data-lake-settings` AWS CLI comando para establecer el `CROSS_ACCOUNT_VERSION` parámetro en la versión 4 o 5:
```
aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings
{
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam::<111122223333>:user/"
}
],
"CreateDatabaseDefaultPermissions": [],
"CreateTableDefaultPermissions": [],
"Parameters": {
"CROSS_ACCOUNT_VERSION": "5"
}
}
```
1.
Para conceder permisos entre cuentas en el modo de acceso híbrido, el otorgante debe tener los permisos de IAM y los servicios necesarios. AWS Glue AWS RAM La política AWS gestionada `AWSLakeFormationCrossAccountManager` concede los permisos necesarios.
Para permitir el intercambio de datos entre cuentas en el modo de acceso híbrido, hemos actualizado la política administrada `AWSLakeFormationCrossAccountManager` añadiendo dos nuevos permisos de IAM:
+ RAM: ListResourceSharePermissions
+ RAM: AssociateResourceSharePermission
**nota**
Si no utilizas la política AWS gestionada para el rol de otorgante, añade las políticas anteriores a tus políticas personalizadas.
## Ubicación del bucket de Amazon S3 y acceso de los usuarios
Al crear un catálogo, una base de datos o una tabla en AWS Glue Data Catalog, puede especificar la ubicación del depósito de Amazon S3 de los datos subyacentes y registrarlos en Lake Formation. En las tablas siguientes se describe cómo funcionan los permisos para AWS Glue los usuarios (principales) de Lake Formation en función de la ubicación de datos de Amazon S3 de la tabla o base de datos.
**Ubicación de Amazon S3 registrada con Lake Formation**
| Ubicación de Amazon S3 de una base de datos | AWS Glue usuarios | Usuarios de Lake Formation |
| --- | --- | --- |
| Registro en Lake Formation (en modo de acceso híbrido o en modo Lake Formation) | Tenga read/write acceso a la ubicación de datos de Amazon S3 heredando los permisos del grupo IAMAllowed Principals (superacceso). | Herede permisos para crear tablas a partir del permiso CREATE TABLE concedido. |
| Ninguna ubicación de Amazon S3 asociada | Se requiere un permiso DATA LOCATION explícito para ejecutar las instrucciones CREATE TABLE e INSERT TABLE. | Se requiere un permiso DATA LOCATION explícito para ejecutar las instrucciones CREATE TABLE e INSERT TABLE. |
****IsRegisteredWithLakeFormation**propiedad de la tabla**
La propiedad `IsRegisteredWithLakeFormation` de una tabla indica si la ubicación de los datos de la tabla está registrada en Lake Formation para el solicitante. Si el modo de permiso de la ubicación está registrado como Lake Formation, la propiedad `IsRegisteredWithLakeFormation` es `true` para todos los usuarios que accedan a la ubicación de datos, ya que se considera que todos los usuarios han optado por participar en esa tabla. Si la ubicación está registrada en modo de acceso híbrido, el valor se establece en `true` solo para los usuarios que hayan optado por esa tabla.
**Cómo funciona `IsRegisteredWithLakeFormation`**
| Modo de permisos | Usuarios/roles | `IsRegisteredWithLakeFormation` | Description (Descripción) |
| --- | --- | --- | --- |
| Lake Formation | Todos | True | Cuando se registre una ubicación en Lake Formation, la propiedad `IsRegisteredWithLakeFormation` se establecerá como verdadera para todos los usuarios. Esto significa que los permisos definidos en Lake Formation se aplican a la ubicación registrada. Lake Formation se encargará de la dispensación de credenciales. |
| Modo de acceso híbrido | Inscrito | True | En el caso de los usuarios que se hayan inscrito para usar Lake Formation para el acceso a los datos y la gobernanza de una tabla, la propiedad `IsRegisteredWithLakeFormation` se establecerá en `true` para dicha tabla. Están sujetos a las políticas de permisos definidas en Lake Formation para la ubicación registrada. |
| Modo de acceso híbrido | No inscrito | False | En el caso de los usuarios que no se hayan inscrito para utilizar los permisos de Lake Formation, la propiedad `IsRegisteredWithLakeFormation` se establece en `false`. No están sujetos a las políticas de permisos definidas en Lake Formation para la ubicación registrada. En su lugar, los usuarios seguirán las políticas de permisos de Amazon S3. |
# Convertir un AWS Glue recurso en un recurso híbrido
Siga estos pasos para registrar una ubicación de Amazon S3 en modo de acceso híbrido e incorporar nuevos usuarios de Lake Formation sin interrumpir el acceso a los datos de los usuarios actuales del Catálogo de datos.
Descripción del escenario: la ubicación de los datos no está registrada en Lake Formation y el acceso de los usuarios a la base de datos y las tablas del Catálogo de datos se determina mediante las políticas de permisos de IAM para acciones de AWS Glue y Amazon S3.
De forma predeterminada, el grupo `IAMAllowedPrincipals` tiene permisos de `Super` en todas las tablas de la base de datos.
**Para habilitar el modo de acceso híbrido para una ubicación de datos no registrada en Lake Formation**
1.
**Registre una ubicación de Amazon S3 que habilite el modo de acceso híbrido.**
------
#### [ Console ]
1. Inicie sesión en la [consola de Lake Formation](https://console.aws.amazon.com/lakeformation/) como administrador del lago de datos.
1. En **Administración** del panel de navegación, seleccione las **Ubicaciones de los lagos de datos**.
1. Seleccione **Registrar ubicación**.
![\[Register location form for Amazon S3 data lake with path input, IAM role selection, and permission mode options.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/hybrid-access-register-s3.png)
1. En la ventana **Registrar ubicación**, elija la ruta de **Amazon S3** que desee registrar en Lake Formation.
1. Para el **rol de IAM**, elija el rol vinculado al servicio `AWSServiceRoleForLakeFormationDataAccess` (valor predeterminado) o un rol de IAM personalizado que cumpla los requisitos de [Requisitos de los roles utilizados para registrar ubicaciones](registration-role.md).
1. Elija el **modo de acceso híbrido** para aplicar políticas específicas de control de acceso de Lake Formation a las entidades principales y a las bases de datos y tablas del Catálogo de datos que apuntan a la ubicación registrada.
Seleccione Lake Formation para permitir que Lake Formation autorice las solicitudes de acceso a la ubicación registrada.
1. Seleccione **Registrar ubicación**.
------
#### [ AWS CLI ]
El siguiente es un ejemplo para registrar una ubicación de datos con Lake Formation HybridAccessEnabled con:true/false. El valor predeterminado para el parámetro `HybridAccessEnabled` es false. Sustituya la ruta, el nombre del rol y el identificador de AWS cuenta de Amazon S3 por valores válidos.
```
aws lakeformation register-resource --cli-input-json file:file path
json:
{
"ResourceArn": "arn:aws:s3:::s3-path",
"UseServiceLinkedRole": false,
"RoleArn": "arn:aws:iam::<123456789012>:role/",
"HybridAccessEnabled": true
}
```
------
1.
**Conceda permisos y seleccione entidades principales para utilizar los permisos de Lake Formation para los recursos en modo de acceso híbrido.**
Antes de inscribir entidades principales y recursos en el modo de acceso híbrido, verifique que la concesión de los permisos `Super` o `All` al grupo `IAMAllowedPrincipals` existe en las bases de datos y tablas que tienen la ubicación registrada con Lake Formation en el modo de acceso híbrido.
**nota**
No puede conceder al grupo `IAMAllowedPrincipals` permiso sobre `All tables` dentro de una base de datos. Debe seleccionar cada tabla por separado en el menú desplegable y conceder los permisos. Además, al crear nuevas tablas en la base de datos, puede optar por usar `Use only IAM access control for new tables in new databases` en la **configuración del Catálogo de datos**. Esta opción concede el permiso de `Super` al grupo `IAMAllowedPrincipals` automáticamente al crear nuevas tablas en la base de datos.
------
#### [ Console ]
1. En la consola de Lake Formation, en **Catálogo de datos**, elija **Catálogos**, **Bases de datos** o **Tablas**.
1. Seleccione un catálogo, base de datos o tabla de la lista y elija **Conceder** en el menú **Acciones**.
1. Elija entidades principales a las que conceder permisos sobre la base de datos, las tablas y las columnas utilizando el método de recursos con nombre o las etiquetas LF.
Como alternativa, elija **Permisos de datos**, seleccione las entidades principales a las que conceder permisos de la lista y elija **Conceder**.
Para obtener más información sobre la concesión de permisos de datos, consulte [Concesión de permisos sobre los recursos del Catálogo de datos](granting-catalog-permissions.md).
**nota**
Si concede a una entidad principal el permiso para crear una tablas, también deberá concederle permisos de ubicación de datos (`DATA_LOCATION_ACCESS`). Este permiso no es necesario para actualizar las tablas.
Para obtener más información, consulte [Conceder permisos de ubicación de datos](granting-location-permissions.md).
1. Si utiliza el **método de recurso con nombre** para conceder permisos, la opción de incluir entidades principales y recursos está disponible en la sección inferior de la página de **concesión de permisos de datos**.
Seleccione **Hacer efectivos inmediatamente los permisos de Lake Formation** para habilitar los permisos de Lake Formation para las entidades principales y los recursos.
![\[Opción para elegir un modo de acceso híbrido para el recurso del Catálogo de datos\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/hybrid-access-grant-option.png)
1. Elija **Conceder**.
Al optar por la entidad principal A en la tabla A que apunta a una ubicación de datos, permite que la entidad principal A tenga acceso a la ubicación de esta tabla utilizando los permisos de Lake Formation si la ubicación de datos está registrada en modo híbrido.
------
#### [ AWS CLI ]
A continuación se muestra un ejemplo para optar por una entidad principal y una tabla en modo de acceso híbrido. Sustituya el nombre del rol, el id de la cuenta de AWS , el nombre de la base de datos y el nombre de la tabla por valores aceptables.
```
aws lakeformation create-lake-formation-opt-in --cli-input-json file://file path
json:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/"
},
"Resource": {
"Table": {
"CatalogId": "<123456789012>",
"DatabaseName": "",
"Name": ""
}
}
}
```
------
1. Si elige las etiquetas LF para la concesión de permisos, puede optar por que las entidades principales utilicen los permisos de Lake Formation en un paso aparte. Para ello, elija el **modo de acceso Híbrido** en **Permisos** de la barra de navegación izquierda.
1. En la sección inferior de la página **Modo de acceso híbrido**, seleccione **Añadir** para añadir recursos y entidades principales al modo de acceso híbrido.
1. En la página **Agregar recursos y entidades principales**, elija los catálogos, bases de datos y tablas registrados en el modo de acceso híbrido.
Puede elegir `All tables` bajo una base de datos a la que conceder acceso.
![\[Interfaz para agregar catálogos, bases de datos y tablas en modo de acceso híbrido\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/hybrid-access-opt-in.png)
1. Elija la inscripción de entidades principales para utilizar los permisos de Lake Formation en el modo de acceso híbrido.
+ **Entidades principales**: puede elegir los usuarios y roles de IAM en la misma cuenta o en otra cuenta. También puede elegir usuarios y grupos de SAML.
+ **Atributos**: seleccione los atributos para conceder permisos en función de los atributos.
![\[Interfaz para agregar entidades principales y recursos con una expresión de atributo\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/abac-hybrid-access.png)
+ Especifique el par clave-valor para crear una concesión basada en atributos. Revise la expresión de política de Cedar resultante en la consola. Para obtener más información acerca de Cedar, consulte [¿Qué es Cedar? \$1 Referencia del lenguaje de políticas de Cedar GuideLink](https://docs.cedarpolicy.com/).
+ Elija **Añadir**.
Se concede acceso a todos los IAM roles/users con atributos coincidentes.
1. Elija **Añadir**.
# Convertir un recurso de Lake Formation en un recurso híbrido
En los casos en los que esté utilizando permisos de Lake Formation para sus bases de datos y tablas del Catálogo de datos, puede editar las propiedades de registro de la ubicación para activar el modo de acceso híbrido. Esto le permite proporcionar a los nuevos directores acceso a los mismos recursos mediante las políticas de permisos y AWS Glue acciones de IAM para Amazon S3 sin interrumpir los permisos existentes de Lake Formation.
Descripción del escenario: en los siguientes pasos se asume que tiene una ubicación de datos registrada en Lake Formation y que ha configurado permisos para entidades principales en bases de datos, tablas o columnas que apuntan a esa ubicación. Si la ubicación se registró con un rol vinculado a un servicio, no podrá actualizar los parámetros de ubicación ni habilitar el modo de acceso híbrido. De forma predeterminada, el grupo `IAMAllowedPrincipals` tiene permisos Super sobre la base de datos y todas sus tablas.
**importante**
No actualice un registro de ubicación al modo híbrido sin inscribirse en las entidades principales que acceden a los datos de esta ubicación.
**Activación del modo de acceso híbrido para una ubicación de datos registrada en Lake Formation**
1.
**aviso**
No recomendamos convertir una ubicación de datos administrada de Lake Formation en un modo de acceso híbrido para evitar interrumpir las políticas de permisos de otros usuarios o cargas de trabajo existentes.
Opte por las entidades principales existentes que tengan permisos de Lake Formation.
1. Recopile y revise los permisos que ha concedido a las entidades principales sobre los catálogos, bases de datos y tablas. Para obtener más información, consulte [Consulta de los permisos de bases de datos y tablas en Lake Formation](viewing-permissions.md).
1. Elija el **modo de acceso Híbrido** en **Permisos** de la barra de navegación izquierda y seleccione **Añadir**.
1. En la página **Agregar entidades principales y recursos**, elija los catálogos, bases de datos y tablas de la ubicación de datos de Amazon S3 que desee utilizar en el modo de acceso híbrido. Elija las entidades principales que ya tienen permisos de Lake Formation.
1. Elija **Añadir** para optar a que las entidades principales utilicen los permisos de Lake Formation en el modo de acceso híbrido.
1. Actualice el bucket/prefix registro de Amazon S3 seleccionando la opción de **modo de acceso híbrido**.
------
#### [ Console ]
1. Inicie sesión en la consola de Lake Formation como administrador del lago de datos.
1. En el panel de navegación, vaya a **Registrar e ingerir** y seleccione las **ubicaciones de los lagos de datos**.
1. Seleccione una ubicación y, en el menú **Acciones**, seleccione **Editar**.
1. Elija **Modo de acceso híbrido**.
1. Seleccione **Save**.
1. En el Catálogo de datos, seleccione la base de datos o tabla y conceda permisos `Super` o `All` al grupo virtual denominado `IAMAllowedPrincipals`.
1. Compruebe que el acceso de sus usuarios actuales de Lake Formation no se interrumpa al actualizar las propiedades de registro de la ubicación. Inicie sesión en la consola de Athena como entidad principal de Lake Formation y ejecute una consulta de ejemplo en una tabla que apunte a la ubicación actualizada.
Del mismo modo, compruebe el acceso de AWS Glue los usuarios que utilizan las políticas de permisos de IAM para acceder a la base de datos y a las tablas.
------
#### [ AWS CLI ]
El siguiente es un ejemplo para registrar una ubicación de datos con Lake Formation HybridAccessEnabled con:true/false. El valor predeterminado para el parámetro `HybridAccessEnabled` es false. Sustituya la ruta, el nombre del rol y el identificador de AWS cuenta de Amazon S3 por valores válidos.
```
aws lakeformation update-resource --cli-input-json file://file path
json:
{
"ResourceArn": "arn:aws:s3:::",
"RoleArn": "arn:aws:iam::<123456789012>:role/",
"HybridAccessEnabled": true
}
```
------
# Compartir un AWS Glue recurso mediante el modo de acceso híbrido
Comparta datos con otra persona Cuenta de AWS o con un director en otra persona Cuenta de AWS haciendo cumplir los permisos de Lake Formation sin interrumpir el acceso basado en IAM de los usuarios existentes del Catálogo de Datos.
Descripción del escenario: la cuenta del productor tiene una base de datos del catálogo de datos cuyo acceso está controlado mediante las principales políticas y AWS Glue acciones de IAM para Amazon S3. La ubicación de los datos de la base de datos no está registrada en Lake Formation. De forma predeterminada, el grupo `IAMAllowedPrincipals` tiene permisos `Super` sobre la base de datos y todas sus tablas.
**Conceder permisos entre cuentas de Lake Formation en modo de acceso híbrido**
1.
**Configuración de una cuenta de productor**
1. Inicie sesión en la consola de Lake Formation con un rol que tenga permiso `lakeformation:PutDataLakeSettings` de IAM.
1. Vaya a la **configuración del Catálogo de datos** y seleccione `Version 4` para la **configuración de la versión entre cuentas**.
Si utiliza la versión 1 o 2, consulte las instrucciones de [Actualización de los ajustes de la versión entre cuentas para compartir datos](optimize-ram.md) para actualizar a la versión 3.
No es necesario hacer cambios en la política de permisos para actualizar de la versión 3 a la 4.
1. Registre la ubicación en Amazon S3 de la base de datos o tabla que planea compartir en el modo de acceso híbrido.
1. Compruebe que existe permiso `Super` para el grupo `IAMAllowedPrincipals` en las bases de datos y tablas en las que registró la ubicación de datos en modo de acceso híbrido en el paso anterior.
1. Otorgue permisos de Lake Formation a AWS organizaciones, unidades organizativas (OUs) o directamente con un director de IAM en otra cuenta.
1. Si concede los permisos directamente a una entidad principal de IAM, opte por que la entidad principal de la cuenta de consumidor aplique los permisos de Lake Formation en el modo de acceso híbrido activando la opción **Hacer efectivos inmediatamente los permisos de Lake Formation**.
Si vas a conceder permisos multicuenta a otra AWS cuenta, al activar la cuenta, los permisos de Lake Formation solo se aplican a los administradores de esa cuenta. El administrador del lago de datos de la cuenta de destinatario tiene que aplicar en cascada los permisos y optar por las entidades principales de la cuenta para hacer cumplir los permisos de Lake Formation para los recursos compartidos que están en modo de acceso híbrido.
Si elige la opción **Recursos emparejados por etiquetas LF** para conceder permisos entre cuentas, deberá completar primero el paso de concesión de permisos. Puede optar por el modo de acceso híbrido para entidades principales y recursos como un paso separado, seleccionando el **modo de acceso híbrido** en Permisos en la barra de navegación izquierda de la consola de Lake Formation. Luego, seleccione **Agregar** para agregar los recursos y las entidades principales a los que desea aplicar los permisos de Lake Formation.
1.
**Configuración de una cuenta de consumidor**
1. Inicie sesión en la consola de Lake Formation [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)como administrador de un lago de datos.
1. Ve a [https://console.aws.amazon.com/ram/casa](https://console.aws.amazon.com/ram/home) y acepta la invitación para compartir recursos. La pestaña **Compartido conmigo** de la AWS RAM consola muestra la base de datos y las tablas que se comparten con su cuenta.
1. Cree un enlace de recursos a la and/or tabla de base de datos compartida en Lake Formation.
1. Conceda permiso `Describe` en el enlace de recursos y permiso `Grant on target` (para el recurso compartido original) a las entidades principales de IAM de su cuenta (de consumidor).
1. Conceda a las entidades principales de su cuenta permisos de Lake Formation en la base de datos o tabla compartida. Indique a las entidades principales y a los recursos que apliquen los permisos de Lake Formation en el modo de acceso híbrido activando la opción **Hacer efectivos inmediatamente los permisos de Lake Formation**.
1. Pruebe los permisos de Lake Formation de la entidad principal ejecutando consultas Athena de ejemplo. Pruebe el acceso actual de sus AWS Glue usuarios con las políticas principales de IAM para Amazon S3 y AWS Glue sus acciones.
(Opcional) Elimine la política de bucket de Amazon S3 para el acceso a los datos y las políticas principales de IAM para AWS Glue y el acceso a los datos de Amazon S3 para las entidades principales que configuró para usar los permisos de Lake Formation.
# Compartir un recurso de Lake Formation mediante el modo de acceso híbrido
Autorice a los nuevos usuarios del Catálogo de datos de una cuenta externa a acceder a las bases de datos y tablas del Catálogo de datos mediante políticas basadas en IAM sin interrumpir los permisos existentes de uso compartido entre cuentas de Lake Formation.
Descripción del escenario. La cuenta del productor tiene una base de datos y tablas administradas por Lake Formation que se comparten con una cuenta externa (de consumidor) a nivel de cuenta o a nivel de entidad principal de IAM. La ubicación de los datos de la base de datos está registrada en Lake Formation. El grupo `IAMAllowedPrincipals` no tiene permisos `Super` en la base de datos ni en sus tablas.
**Conceder acceso entre cuentas a nuevos usuarios del Catálogo de datos mediante políticas basadas en IAM sin interrumpir el permiso existente de Lake Formation.**
1.
**Configuración de una cuenta de productor**
1. Inicie sesión en la consola de Lake Formation con un rol que `lakeformation:PutDataLakeSettings`.
1. Vaya a la **configuración del Catálogo de datos** y seleccione `Version 4` para la **configuración de la versión entre cuentas**.
Si utiliza la versión 1 o 2, consulte las instrucciones de [Actualización de los ajustes de la versión entre cuentas para compartir datos](optimize-ram.md) para actualizar a la versión 3.
No es necesario hacer cambios en la política de permisos para actualizar de la versión 3 a la 4.
1. Recopile y revise los permisos que ha concedido a las entidades principales sobre las bases de datos y las tablas. Para obtener más información, consulte [Consulta de los permisos de bases de datos y tablas en Lake Formation](viewing-permissions.md).
1. Vuelva a conceder los permisos entre cuentas existentes de Lake Formation optando por entidades principales y recursos.
**nota**
Antes de actualizar el registro de una ubicación de datos al modo de acceso híbrido para conceder permisos entre cuentas, debe volver a conceder al menos un recurso compartido de datos entre cuentas por cuenta. Este paso es necesario para actualizar los permisos AWS RAM administrados adjuntos al AWS RAM recurso compartido.
En julio de 2023, Lake Formation actualizó los permisos AWS RAM gestionados que se utilizan para compartir bases de datos y tablas:
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueAllTablesReadWriteForDatabase` (política de uso compartido a nivel de base de datos)
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueTableReadWrite` (política de uso compartido a nivel de tabla)
Las concesiones de permisos multicuenta realizadas antes de julio de 2023 no tienen estos AWS RAM permisos actualizados.
Si ha concedido permisos para varias cuentas directamente a las entidades principales, tendrá que volver a concederlos individualmente. Si omite este paso, las entidades principales que accedan al recurso compartido podrían obtener un error de combinación ilegal.
1. Ve a [https://console.aws.amazon.com/ram/casa.](https://console.aws.amazon.com/ram/home)
1. La pestaña **Compartidos por mí** de la AWS RAM consola muestra los nombres de bases de datos y tablas que has compartido con una cuenta o entidad principal externa.
Asegúrese de que los permisos adjuntos al recurso compartido tengan el ARN correcto.
1. Comprueba que los recursos del AWS RAM recurso compartido estén en `Associated` estado. Si el estado es `Associating`, espere a que pasen al estado `Associated`. Si el estado pasa a ser `Failed`, deténgase y póngase en contacto con el equipo de servicio de Lake Formation.
1. Elija el **modo de acceso Híbrido** en **Permisos** de la barra de navegación izquierda y seleccione **Añadir**.
1. La página **Agregar entidades principales y recursos** muestra las bases de datos, and/or las tablas y las entidades principales a las que se puede acceder. Para efectuar las actualizaciones necesarias, añada o quite entidades principales y recursos.
1. Elija las entidades principales con permisos de Lake Formation para la base de datos y las tablas que desea cambiar al modo de acceso híbrido. Elija las bases de datos y tablas.
1. Elija **Añadir** para que las entidades principales puedan utilizar los permisos de Lake Formation en el modo de acceso híbrido.
1. Conceda permiso `Super` al grupo virtual `IAMAllowedPrincipals` de su base de datos y de las tablas seleccionadas.
1. Edite el registro de Lake Formation de la ubicación de Amazon S3 en modo de acceso híbrido.
1. Otorgue permisos a los AWS Glue usuarios de la cuenta externa (de consumidor) mediante las políticas de permisos de IAM para las AWS Glue acciones de Amazon S3.
1.
**Configuración de una cuenta de consumidor**
1. Inicie sesión en la consola de Lake Formation [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)como administrador de un lago de datos.
1. Ve a [https://console.aws.amazon.com/ram/casa](https://console.aws.amazon.com/ram/home) y acepta la invitación para compartir recursos. La pestaña **Recursos compartidos conmigo** de la AWS RAM página muestra los nombres de las bases de datos y las tablas que se comparten con su cuenta.
Para AWS RAM compartir, asegúrate de que el permiso adjunto tenga el ARN correcto de la invitación compartida AWS RAM . Comprueba si los recursos del recurso AWS RAM compartido están en `Associated` estado. Si el estado es `Associating`, espere a que pasen al estado `Associated`. Si el estado pasa a ser `Failed`, deténgase y póngase en contacto con el equipo de servicio de Lake Formation.
1. Cree un enlace de recursos a la and/or tabla de base de datos compartida en Lake Formation.
1. Conceda permiso `Describe` en el enlace de recursos y permiso `Grant on target` (para el recurso compartido original) a las entidades principales de IAM de su cuenta (de consumidor).
1. A continuación, configure los permisos de Lake Formation para las entidades principales de su cuenta en la base de datos o tabla compartida.
En la barra de navegación de la izquierda, en **Permisos**, elija el **modo de acceso Híbrido**.
1. Seleccione **Añadir** en la sección inferior de la página del **modo de acceso híbrido** para optar por las entidades principales y la base de datos o tabla compartida de la cuenta de productor.
1. Conceda permisos a los AWS Glue usuarios de su cuenta mediante las políticas de permisos de IAM para las AWS Glue acciones de Amazon S3.
1. Pruebe los permisos y AWS Glue permisos de Lake Formation de los usuarios ejecutando consultas de ejemplo independientes en la tabla con Athena
(Opcional) Limpie las políticas de permisos de IAM para Amazon S3 para las entidades principales que se encuentran en el modo de acceso híbrido.
# Eliminación de entidades principales y recursos del modo de acceso híbrido
Siga estos pasos para eliminar bases de datos, tablas y entidades principales del modo de acceso híbrido.
------
#### [ Console ]
1. Inicie sesión en la consola de Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. En **Permisos**, seleccione el **modo de acceso híbrido**.
1. En la página **Modo de acceso híbrido**, marque la casilla situada junto al nombre de la base de datos o tabla y elija `Remove`.
1. Un mensaje de advertencia le solicitará que confirme la acción. Elija **Eliminar **.
Lake Formation ya no exige permisos para esos recursos, y el acceso a este recurso se controlará mediante IAM y AWS Glue permisos. Esto puede provocar que el usuario deje de tener acceso a este recurso si no tiene los permisos de IAM adecuados.
------
#### [ AWS CLI ]
En el siguiente ejemplo, se muestra cómo eliminar recursos del modo de acceso híbrido.
```
aws lakeformation delete-lake-formation-opt-in --cli-input-json file://file path
json:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/role name"
},
"Resource": {
"Table": {
"CatalogId": "<123456789012>",
"DatabaseName": "",
"Name": ""
}
}
}
```
------
# Eliminación de entidades principales y recursos del modo de acceso híbrido
Siga estos pasos para eliminar bases de datos, tablas y entidades principales del modo de acceso híbrido.
------
#### [ Console ]
1. Inicie sesión en la consola de Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. En **Permisos**, seleccione el **modo de acceso híbrido**.
1. La página **Modo de acceso híbrido** muestra los recursos y entidades principales presentes en el modo de acceso híbrido.
------
#### [ AWS CLI ]
En el ejemplo siguiente, se muestra cómo enumerar todas las entidades principales y recursos que están en el modo de acceso híbrido.
```
aws lakeformation list-lake-formation-opt-ins
```
El siguiente ejemplo muestra cómo enumerar un par específico de entidad principal-recurso.
```
aws lakeformation list-lake-formation-opt-ins --cli-input-json file://file path
json:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:iam:::role/"
},
"Resource": {
"Table": {
"CatalogId": "",
"DatabaseName": "",
"Name": ""
}
}
}
```
------
# Recursos adicionales
En la siguiente entrada del blog, le guiaremos a través de las instrucciones para incorporar los permisos de Lake Formation en modo de acceso híbrido para los usuarios seleccionados, mientras que la base de datos ya es accesible para otros usuarios a través de los permisos de IAM y Amazon S3. Revisaremos las instrucciones para configurar el modo de acceso híbrido dentro de una AWS cuenta y entre dos cuentas.
+ [Presentamos el modo de acceso híbrido AWS Glue Data Catalog para proteger el acceso mediante Lake Formation y las políticas de IAM y Amazon S3.](https://aws.amazon.com/blogs/big-data/introducing-hybrid-access-mode-for-aws-glue-data-catalog-to-secure-access-using-aws-lake-formation-and-iam-and-amazon-s3-policies/)
# 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.
[](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.
# Importación de datos mediante flujos de trabajo en Lake Formation
Con AWS Lake Formation, puede importar sus datos mediante *flujos de trabajo*. Un flujo de trabajo define el origen de datos y la programación para importar los datos a su lago de datos. Es un contenedor para rastreadores AWS Glue, trabajos y desencadenadores que se utilizan para orquestar los procesos de carga y actualización del lago de datos.
**Topics**
+ [Esquemas y flujos de trabajo en Lake Formation](workflows-about.md)
+ [Creación de un flujo de trabajo](workflows-creating.md)
+ [Ejecución de un flujo de trabajo](workflows-running.md)
# Esquemas y flujos de trabajo en Lake Formation
Un flujo de trabajo encapsula una actividad compleja de extracción, transformación y carga (ETL) de múltiples tareas. Los flujos de trabajo generan rastreadores de AWS Glue, trabajos y desencadenadores para orquestar la carga y actualización de datos. Lake Formation ejecuta y rastrea un flujo de trabajo como una única entidad. Puede configurar un flujo de trabajo para que se ejecute bajo demanda o de forma programada.
**nota**
El escritor de archivos Parquet de Spark no admite caracteres especiales en los nombres de las columnas. Se trata de una limitación técnica del propio escritor, no de un problema de configuración.
Los flujos de trabajo que cree en Lake Formation son visibles en la consola de AWS Glue como un gráfico acíclico dirigido (DAG). Cada nodo del DAG es una tarea, un rastreador o un disparador. Para supervisar el progreso y solucionar problemas, puede hacer un seguimiento del estado de cada nodo del flujo de trabajo.
Cuando se completa un flujo de trabajo de Lake Formation, el usuario que lo ejecutó recibe el permiso `SELECT` de Lake Formation en las tablas del Catálogo de datos que crea el flujo de trabajo.
También puede crear flujos de trabajo en AWS Glue. Sin embargo, como Lake Formation le permite crear un flujo de trabajo a partir de un esquema, la creación de flujos de trabajo es mucho más sencilla y automatizada en Lake Formation. Lake Formation proporciona los siguientes tipos de esquemas:
+ **Instantánea de la base de datos.** Carga o recarga los datos de todas las tablas en el lago de datos desde una fuente JDBC. Puede excluir algunos datos de la fuente en función de un patrón de exclusión.
+ **Base de datos incremental.** Carga solo los datos nuevos en el lago de datos desde una fuente JDBC, en función de los marcadores establecidos anteriormente. El usuario especifica las tablas individuales de la base de datos de origen de JDBC que desee incluir. Para cada tabla, elige las columnas de marcadores y el orden de clasificación de los marcadores para hacer un seguimiento de los datos que se han cargado previamente. La primera vez que ejecuta un esquema incremental de base de datos sobre un conjunto de tablas, el flujo de trabajo carga todos los datos de las tablas y establece los marcadores para la siguiente ejecución del esquema incremental de base de datos. Por lo tanto, puede utilizar un esquema de base de datos incremental en lugar del esquema de instantánea de base de datos para cargar todos los datos, siempre que especifique cada tabla de los orígenes de datos como parámetro.
+ **Archivo de registro.** Carga de forma masiva datos de fuentes de archivos de registro, incluidos AWS CloudTrail, registros de Equilibrador de carga elástico y registros de Equilibrador de carga de aplicación
Utilice la siguiente tabla como ayuda para decidir si debe utilizar una instantánea de base de datos o un esquema incremental de base de datos.
| Utilice la instantánea de la base de datos cuando... | Utilice la base de datos incremental cuando... |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/workflows-about.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/workflows-about.html) |
**nota**
Los usuarios no pueden editar los esquemas y flujos de trabajo creados por Lake Formation.
# Creación de un flujo de trabajo
Antes de empezar, asegúrese de que ha concedido los permisos de datos y de ubicación de datos necesarios al rol `LakeFormationWorkflowRole`. Esto es para que el flujo de trabajo pueda crear tablas de metadatos en el Catálogo de datos y escribir datos en ubicaciones de destino en Amazon S3. Para obtener más información, consulte [(Opcional) Crear un rol de IAM para flujos de trabajo](initial-lf-config.md#iam-create-blueprint-role) y [Descripción general de los permisos de Lake Formation](lf-permissions-overview.md).
**nota**
Lake Formation usa las operaciones `GetTemplateInstance`, `GetTemplateInstances` e `InstantiateTemplate` para crear flujos de trabajo a partir de esquemas. Estas operaciones no son de ámbito público, y solo se utilizan internamente para crear recursos en su nombre. El usuario recibe eventos de CloudTrail para crear flujos de trabajo.
**Para crear un flujo de trabajo a partir de un esquema**
1. Abra la consola de AWS Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Inicie sesión como administrador del lago de datos o como usuario con permisos de ingeniero de datos. Para obtener más información, consulte [Personas de Lake Formation y referencia de permisos IAM](permissions-reference.md).
1. En el panel de navegación, seleccione **Esquemas** y, a continuación, seleccione **Utilizar esquema**.
1. En la página **Usar un esquema,** elija un mosaico para seleccionar el tipo de esquema.
1. En **Origen de importación**, especifique el origen de datos.
Si está importando desde un origen JDBC, especifique lo siguiente:
+ ****Conexión a la base de datos.**** Elija una conexión de la lista. Cree conexiones adicionales utilizando la consola de AWS Glue. El nombre de usuario JDBC y la contraseña de la conexión determinan los objetos de la base de datos a los que tiene acceso el flujo de trabajo.
+ ****Ruta de origen de los datos.**** Introduzca **/**/** o **/**, en función del producto de base de datos. Oracle Database y MySQL no permiten utilizar un esquema en la ruta. Puede sustituir ** o ** por el carácter de porcentaje (%). Por ejemplo, para una base de datos Oracle con un identificador del sistema (SID) de `orcl`, introduzca `orcl/%` para importar todas las tablas a las que tenga acceso el usuario nombrado en la conexión.
**importante**
Este campo distingue entre mayúsculas y minúsculas. El flujo de trabajo fallará si no coincide entre mayúsculas y minúsculas en alguno de los componentes.
Si especifica una base de datos MySQL, AWS Glue ETL utiliza el controlador JDBC Mysql5 de forma predeterminada, por lo que MySQL8 no es compatible de forma nativa. Puede editar el script del trabajo ETL para utilizar un parámetro `customJdbcDriverS3Path` como el descrito en [Valores de tipo de conexión JDBC](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-jdbc) en la *Guía para desarrolladores de AWS Glue* para utilizar un controlador JDBC diferente que sea compatible con MySQL8.
Si está importando desde un archivo de registro, asegúrese de que el rol que especifique para el flujo de trabajo (el "rol del flujo de trabajo") tenga los permisos IAM necesarios para acceder a los orígenes de datos. Por ejemplo, para importar registros de AWS CloudTrail, el usuario debe tener los permisos `cloudtrail:DescribeTrails` y `cloudtrail:LookupEvents` para ver la lista de registros de CloudTrail al crear el flujo de trabajo, y el rol del flujo de trabajo debe tener permisos sobre la ubicación de CloudTrail en Amazon S3.
1. Realice una de las siguientes acciones:
+ Para el tipo de esquema **Instantánea de base de datos**, identifique de forma opcional un subconjunto de datos a importar especificando uno o varios patrones de exclusión. Estos patrones de exclusión son patrones `glob` de estilo Unix. Se almacenan como una propiedad de las tablas creadas por el flujo de trabajo.
Para obtener más información sobre los patrones de exclusión disponibles, consulte [Incluir y excluir patrones](https://docs.aws.amazon.com/glue/latest/dg/define-crawler.html#crawler-data-stores-exclude) en la *Guía para desarrolladores de AWS Glue*.
+ Para el tipo de esquema de **base de datos incremental**, especifique los siguientes campos. Agregue una fila para cada tabla que desee importar.
**Nombre de la tabla**
Tabla que se va a importar. Debe estar en minúscula.
**Claves de marcadores**
Lista de nombres de columnas delimitados por comas que definen las claves de los marcadores. Si está en blanco, la clave principal se utiliza para determinar los datos nuevos. Las mayúsculas y minúsculas de cada columna deben coincidir con las definidas en los orígenes de datos.
La clave principal se califica como clave marcadora predeterminada solo si es secuencialmente creciente o decreciente (sin huecos). Si desea utilizar la clave principal como clave de marcador y tiene huecos, debe nombrar la columna de clave principal como clave de marcador.
**Orden de los marcadores**
Si elige **Ascendente**, las filas con valores superiores a los marcados se identifican como nuevas filas. Si elige **Descendente**, las filas con valores inferiores a los marcados se identifican como nuevas filas.
**Esquema de partición**
(Opcional) Lista de columnas de claves de partición, delimitadas por barras (/). Ejemplo:` year/month/day`.
![\[La sección Datos incrementales de la consola incluye estos campos: Nombre de la tabla, Claves de marcadores, Orden de marcadores, Esquema de partición. Puede añadir o eliminar filas, donde cada fila corresponde a una tabla diferente.\]](http://docs.aws.amazon.com/es_es/lake-formation/latest/dg/images/incremental-data.png)
Para más información, consulte [Seguimiento de los datos procesados mediante marcadores de trabajo](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) en la *Guía para desarrolladores de AWS Glue*.
1. En **Importar destino**, especifique la base de datos de destino, la ubicación de Amazon S3 de destino y el formato de datos.
Asegúrese de que el rol de flujo de trabajo tenga los permisos de Lake Formation necesarios en la base de datos y en la ubicación de destino de Amazon S3.
**nota**
Actualmente, los esquemas no admiten el cifrado de datos en el destino.
1. Elija una frecuencia de importación.
Puede especificar una expresión `cron` con la opción **Personalizada**.
1. En **Opciones de importación**:
1. Introduzca un nombre de flujo de trabajo.
1. Para el rol, elija el rol `LakeFormationWorkflowRole`, que creó en [(Opcional) Crear un rol de IAM para flujos de trabajo](initial-lf-config.md#iam-create-blueprint-role).
1. Si lo desea, especifique un prefijo de tabla. El prefijo se antepone a los nombres de las tablas del Catálogo de datos que crea el flujo de trabajo.
1. Seleccione **Crear** y espere a que la consola informe de que el flujo de trabajo se ha creado correctamente.
**sugerencia**
¿Ha recibido este mensaje de error?
`User: arn:aws:iam:::user/ is not authorized to perform: iam:PassRole on resource:arn:aws:iam:::role/...`
En caso afirmativo, compruebe que ha sustituido ** por un número de cuenta AWS válido en todas las pólizas.
**Véase también:**
[Esquemas y flujos de trabajo en Lake Formation](workflows-about.md)
# Ejecución de un flujo de trabajo
Puede ejecutar un flujo de trabajo desde la consola de Lake Formation, la consola de AWS Glue, la interfaz de línea de comandos de AWS Glue (AWS CLI) o la API.
**Para ejecutar un flujo de trabajo (consola de Lake Formation)**
1. Abra la consola de AWS Lake Formation en [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Inicie sesión como administrador del lago de datos o como usuario con permisos de ingeniero de datos. Para obtener más información, consulte [Personas de Lake Formation y referencia de permisos IAM](permissions-reference.md).
1. En el panel de navegación, elija **Esquemas**.
1. En la página **Esquemas**, seleccione el flujo de trabajo. Después, en el menú **Acciones**, seleccione **Comenzar**.
1. Conforme se ejecuta el flujo de trabajo, puede ver su progreso en la columna **Estado de la última ejecución**. Pulse el botón de actualización de vez en cuando.
El estado pasa de **EN EJECUCIÓN** a **Detectando**, **Importando** y **FINALIZADO**.
Cuando finalice el flujo de trabajo:
+ El Catálogo de datos tendrá nuevas tablas de metadatos.
+ Sus datos se incorporan al lago de datos.
Si el flujo de trabajo falla, haga lo siguiente:
1. Seleccione el flujo de trabajo. Elija **Acciones** y, a continuación, elija **Ver gráfico**.
El flujo de trabajo se abre en la consola de AWS Glue.
1. Asegúrese de que se seleccione el flujo de trabajo y elija la pestaña **Historial**.
1. En **Historial**, seleccione la ejecución más reciente y seleccione **Ver detalles de la ejecución**.
1. Seleccione un trabajo o un rastreador fallidos en el gráfico dinámico (tiempo de ejecución) y revise el mensaje de error. Los nodos con errores aparecen en rojo o amarillo.
**Véase también:**
[Esquemas y flujos de trabajo en Lake Formation](workflows-about.md)