* substitua pelo nome da função do fluxo de trabalho.
| Tipo de política | Política |
| --- | --- |
| AWS política gerenciada | AWSGlueConsoleFullAccess |
| Política embutida (básica) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
| Política embutida (para operações em tabelas controladas, incluindo operações dentro de transações) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
| Política embutida (para controle de acesso a metadados usando o método de controle de acesso baseado em tags (LF-TBAC) do Lake Formation) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
| Política embutida (política de senha para a função de fluxo de trabalho) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
### Permissões de analista de dados
| Tipo de política | Política |
| --- | --- |
| AWS política gerenciada | AmazonAthenaFullAccess |
| Política embutida (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 embutida (para operações em tabelas controladas, incluindo operações dentro de transações) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
### Permissões da função de fluxo de trabalho
Essa função tem as permissões necessárias para executar um fluxo de trabalho. Você especifica uma função com essas permissões ao criar um fluxo de trabalho.
**Importante**
Nas políticas a seguir, ** substitua por um identificador de AWS região válido (por exemplo`us-east-1`), ** por um número de AWS conta válido, ** pelo nome da função do fluxo de trabalho e ** pelo caminho do Amazon S3 para seus AWS CloudTrail registros.
| Tipo de política | Política |
| --- | --- |
| AWS política gerenciada | AWSGlueServiceRole |
| Política embutida (acesso a dados) | {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Lakeformation",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"lakeformation:GrantPermissions"
],
"Resource": "*"
}
]
} |
| Política embutida (política de senha para a função de fluxo de trabalho) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
| Política embutida (para ingerir dados fora do data lake, por exemplo, AWS CloudTrail registros) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/permissions-reference.html) |
# Alterando as configurações padrão do seu data lake
Para manter a compatibilidade com versões anterioresAWS Glue, AWS Lake Formation tem as seguintes configurações iniciais de segurança:
+ A permissão `Super` é concedida ao grupo `IAMAllowedPrincipals` em todos os recursos existentes do catálogo de dados do AWS Glue.
+ As configurações “Usar somente o controle de acesso ao IAM” estão habilitadas para novos recursos do catálogo de dados.
Essas configurações efetivamente fazem com que o acesso aos recursos do catálogo de dados e aos locais do Amazon S3 seja controlado exclusivamente por políticas AWS Identity and Access Management (IAM). As permissões individuais do Lake Formation não estão em vigor.
O grupo `IAMAllowedPrincipals` inclui todos os usuários e perfis do IAM que possuem permissão para acessar os recursos do seu catálogo de dados por meio de suas políticas do IAM. A permissão `Super` possibilita que uma entidade principal execute todas as operações suportadas do Lake Formation no banco de dados ou na tabela em que ela foi concedida.
Para alterar as configurações de segurança para que o acesso aos recursos do catálogo de dados (bancos de dados e tabelas) seja gerenciado pelas permissões do Lake Formation, faça o seguinte:
1. Altere as configurações de segurança padrão para novos recursos. Para instruções, consulte [Alterar o modelo de permissão padrão ou usar o modo de acesso híbrido](initial-lf-config.md#setup-change-cat-settings).
1. Altere as configurações dos recursos existentes do catálogo de dados. Para instruções, consulte [Atualizando as permissões AWS Glue de dados para o modelo AWS Lake Formation](upgrade-glue-lake-formation.md).
**Alterando as configurações de segurança padrão usando a operação da API do Lake Formation `PutDataLakeSettings`**
Você também pode alterar as configurações de segurança padrão usando a operação da [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)API Lake Formation. Essa ação usa como argumentos um ID de catálogo opcional e uma [DataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DataLakeSettings.html)estrutura.
Para impor metadados e controle de acesso aos dados subjacentes pelo Lake Formation em novos bancos de dados e tabelas, codifique a estrutura `DataLakeSettings` da seguinte forma.
**nota**
**Substitua por um ID de AWS conta válido e ** por um nome de usuário do IAM válido. Você pode especificar mais de um usuário como administrador de data lake.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
],
"CreateDatabaseDefaultPermissions": [],
"CreateTableDefaultPermissions": []
}
}
```
Você também pode codificar a estrutura da seguinte maneira. Omitir o parâmetro `CreateDatabaseDefaultPermissions` ou `CreateTableDefaultPermissions` é equivalente a passar uma lista vazia.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
]
}
}
```
Essa ação revoga efetivamente todas as permissões do grupo `IAMAllowedPrincipals` Lake Formation em novos bancos de dados e tabelas. Ao criar um banco de dados, você pode substituir essa configuração.
Para aplicar metadados e controle de acesso aos dados subjacentes somente pelo IAM em novos bancos de dados e tabelas, codifique a estrutura `DataLakeSettings` da seguinte forma.
```
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "arn:aws:iam:::user/"
}
],
"CreateDatabaseDefaultPermissions": [
{
"Principal": {
"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
},
"Permissions": [
"ALL"
]
}
],
"CreateTableDefaultPermissions": [
{
"Principal": {
"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"
},
"Permissions": [
"ALL"
]
}
]
}
}
```
Isso concede ao Lake Formation `Super` permissão para o grupo `IAMAllowedPrincipals` em novos bancos de dados e tabelas. Ao criar um banco de dados, você pode substituir essa configuração.
**nota**
Na estrutura `DataLakeSettings` anterior, o único valor permitido para `DataLakePrincipalIdentifier` é `IAM_ALLOWED_PRINCIPALS` e o único valor permitido para `Permissions` é `ALL`.
# Permissões implícitas do Lake Formation
AWS Lake Formation concede as seguintes permissões implícitas aos administradores do data lake, criadores de banco de dados e criadores de tabelas.
**Administradores de data lake**
+ Tenha acesso `Describe` a todos os recursos do catálogo de dados, exceto aos recursos compartilhados de outra conta diretamente com uma entidade principal diferente. Esse acesso não pode ser revogado por um administrador.
+ Tenha permissões de localização de dados em todos os lugares no data lake.
+ Pode conceder ou revogar o acesso a quaisquer recursos no catálogo de dados a qualquer entidade principal (inclusive a si mesmo). Esse acesso não pode ser revogado por um administrador.
+ Pode criar bancos de dados no catálogo de dados.
+ Pode conceder permissão para criar um banco de dados para outro usuário.
Os administradores do data lake podem registrar locais do Amazon S3 somente se tiverem permissões do IAM para fazer isso. As políticas de administrador de data lake sugeridas neste guia concedem essas permissões. Além disso, os administradores do data lake não têm permissões implícitas para eliminar bancos de dados ou alter/drop tabelas criados por outras pessoas. No entanto, eles podem conceder a si mesmos permissões para fazer isso.
Para obter mais informações sobre administradores de data lake, consulte [Crie um administrador de data lake](initial-lf-config.md#create-data-lake-admin).
**Criadores de catálogos**
+ Tenha todas as permissões de catálogo nos catálogos que eles criam, tenham permissões nos bancos de dados e tabelas que eles criam no catálogo e possam conceder a outros diretores da mesma AWS conta permissão para criar bancos de dados e tabelas no catálogo. Um criador de catálogo que também tenha a política `AWSLakeFormationCrossAccountManager` AWS gerenciada pode conceder permissões no catálogo a outras AWS contas ou organizações.
Os administradores do data lake podem usar o console ou a API do Lake Formation para designar criadores de catálogos.
**nota**
Os criadores de catálogos não têm permissões implícitas em bancos de dados e tabelas que outras pessoas criam no catálogo.
Para acessar mais informações sobre como criar catálogos, consulte [Trazendo seus dados para o AWS Glue Data Catalog](bring-your-data-overview.md).
**Criadores de banco de dados**
+ Tenha todas as permissões de banco de dados nos bancos de dados que eles criam, tenham permissões nas tabelas que eles criam no banco de dados e possam conceder a outros diretores da mesma AWS conta permissão para criar tabelas no banco de dados. Um criador de banco de dados que também tenha a política `AWSLakeFormationCrossAccountManager` AWS gerenciada pode conceder permissões no banco de dados para outras AWS contas ou organizações.
Os administradores do data lake podem usar o console ou a API do Lake Formation para designar criadores de banco de dados.
**nota**
Os criadores de banco de dados não possui permissões implícitas em tabelas que outras pessoas criam no banco de dados.
Para obter mais informações, consulte [Criação de um banco de dados](creating-database.md).
**Criadores de tabelas**
+ Tenha todas as permissões nas tabelas que eles criam.
+ Podem conceder permissões em todas as tabelas que eles criam para entidades principais na mesma conta da AWS .
+ Podem conceder permissões em todas as tabelas que eles criam para outras AWS contas ou organizações se tiverem a política `AWSLakeFormationCrossAccountManager` AWS gerenciada.
+ Pode visualizar os bancos de dados que contêm as tabelas que eles criam.
# Referência de permissões do Lake Formation
Para realizar AWS Lake Formation operações, os diretores precisam tanto das permissões do Lake Formation quanto das permissões AWS Identity and Access Management (IAM). Normalmente, você concede permissões do IAM usando políticas de controle de acesso de *baixa granularidade*, conforme descrito em [Visão geral das permissões do Lake Formation](lf-permissions-overview.md). Você pode conceder permissões do Lake Formation usando o console, a API ou o AWS Command Line Interface (AWS CLI).
Para saber como conceder ou revogar permissões do Lake Formation, consulte [Conceder permissões nos recursos do Catálogo de Dados](granting-catalog-permissions.md) e [Conceder permissões de localização de dados](granting-location-permissions.md).
**nota**
Os exemplos nesta seção mostram como conceder permissões às entidades principais na mesma conta da AWS . Para obter exemplos de concessões entre contas, consulte [Compartilhamento de dados entre contas no Lake Formation](cross-account-permissions.md).
## Permissões do Lake Formation por tipo de recurso
A seguir estão as permissões válidas do Lake Formation disponíveis para cada tipo de recurso:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/lf-permissions-reference.html)
**Topics**
+ [Permissões do Lake Formation por tipo de recurso](#lf-resource-permissions-summary)
+ [Lake Formation concede e revoga comandos AWS CLI](#perm-command-format)
+ [Permissões do Lake Formation](#lf-permissions)
## Lake Formation concede e revoga comandos AWS CLI
Cada descrição de permissão nesta seção inclui exemplos de como conceder a permissão usando um AWS CLI comando. A seguir estão as sinopses da Lake Formation e dos comandos. **grant-permissions** **revoke-permissions** AWS CLI
```
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 obter descrições detalhadas desses comandos, consulte [grant-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/grant-permissions.html) e [revoke-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/revoke-permissions.html) na *Referência de comandos da AWS CLI *. Esta seção fornece informações adicionais sobre a opção `--principal`.
O valor da opção `--principal` é um dos seguintes:
+ Nome de recurso da Amazon (ARN) para um usuário ou função AWS Identity and Access Management (IAM)
+ ARN para um usuário ou grupo que se autentica por meio de um provedor SAML, como o Microsoft Active Directory Federation Service (AD FS)
+ ARN para um usuário ou grupo do Amazon Quick
+ Para permissões entre contas, uma ID AWS da conta, uma ID da organização ou uma ID da unidade organizacional
+ Para usuário ou grupo do Centro de Identidade do IAM, ARN do usuário ou grupo do Centro de Identidade do IAM.
Veja a seguir a sintaxe e exemplos para todos os tipos `--principal`.
**Entidade principal é um usuário do IAM**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::user/
```
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1
```
**Entidade principal é um perfil do IAM**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::role/
```
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/workflowrole
```
**Entidade principal é um usuário que se autentica por meio de um provedor SAML**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:user/
```
Exemplos:
```
--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
```
**Entidade principal é um grupo que se autentica por meio de um provedor SAML**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:group/
```
Exemplos:
```
--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 é usuário do Amazon Quick Enterprise Edition**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:::user//
```
Para **, você deve especificar `default`.
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:user/default/bi_user1
```
**Principal é um grupo Amazon Quick Enterprise Edition**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:::group//
```
Para **, você deve especificar `default`.
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:group/default/data_scientists
```
**Principal é uma AWS conta**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=
```
Exemplo:
```
--principal DataLakePrincipalIdentifier=111122223333
```
**Entidade principal é uma organização**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations:::organization/
```
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:organization/o-abcdefghijkl
```
**Entidade principal é uma unidade organizacional**
Sintaxe:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations:::ou//
```
Exemplo:
```
--principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:ou/o-abcdefghijkl/ou-ab00-cdefghij
```
**A entidade principal é um usuário ou grupo de identidade do Centro de Identidade do IAM**
Exemplo: user
```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/
```
Exemplo: group
```
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::group/
```
**A entidade principal é um grupo do IAM (`IAMAllowedPrincipals`)**
Por padrão, o Lake Formation define a permissão `Super` em todos os bancos de dados e tabelas no Catálogo de Dados para um grupo chamado `IAMAllowedPrincipals`. Se essa permissão de grupo existir em um banco de dados ou tabela, todas as entidades principais da sua conta terão acesso ao recurso por meio das políticas de entidade principal do IAM para o AWS Glue. A compatibilidade com versões anteriores será fornecida quando você começar a usar as permissões do Lake Formation para proteger os recursos do Catálogo de Dados que antes eram protegidos pelas políticas do IAM para o AWS Glue.
Ao usar o Lake Formation para gerenciar permissões para seus recursos do Catálogo de Dados, primeiro você precisa revogar a permissão `IAMAllowedPrincipals` dos recursos ou optar pelo modo de acesso híbrido às entidades principais e aos recursos para que as permissões do Lake Formation funcionem.
Exemplo:
```
--principal DataLakePrincipalIdentifier=IAM_Allowed_Principals
```
**A entidade principal é um grupo do IAM (`ALLIAMPrincipals`)**
Quando você concede permissões a um grupo de `ALLIAMPrincipals` em um recurso do Catálogo de Dados, cada entidade principal da conta tem acesso ao recurso do Catálogo de Dados usando as permissões do Lake Formation e do IAM.
Exemplo:
```
--principal DataLakePrincipalIdentifier=123456789012:IAMPrincipals
```
## Permissões do Lake Formation
Esta seção contém as permissões disponíveis do Lake Formation que você pode conceder às entidades principais.
### `ALTER`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| ALTER | DATABASE | glue:UpdateDatabase |
| ALTER | TABLE | glue:UpdateTable |
| ALTER | LF-Tag | lakeformation:UpdateLFTag |
Uma entidade principal com essa permissão pode alterar os metadados de um banco de dados ou tabela no catálogo de dados. Para tabelas, você pode alterar o esquema da coluna e adicionar parâmetros da coluna. Você não pode alterar as colunas nos dados subjacentes para os quais uma tabela de metadados aponta.
Se a propriedade que está sendo alterada for um local registrado do Amazon Simple Storage Service (Amazon S3), a entidade principal deverá ter permissões de localização de dados no novo local.
**Example**
O exemplo a seguir concede a `ALTER` permissão ao usuário `datalake_user1` no banco de dados `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Database": {"Name":"retail"}}'
```
**Example**
O exemplo a seguir concede `ALTER` ao usuário `datalake_user1` na tabela `inventory` no banco de dados `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
### `CREATE_DATABASE`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| CREATE\$1DATABASE | catálogo de dados | glue:CreateDatabase |
Uma entidade principal com essa permissão pode criar um banco de dados de metadados ou um link de recurso no catálogo de dados. A entidade principal também pode criar tabelas no banco de dados.
**Example**
O exemplo a seguir concede `CREATE_DATABASE` ao usuário `datalake_user1` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_DATABASE" --resource '{ "Catalog": {}}'
```
Quando uma entidade principal cria um banco de dados no catálogo de dados, nenhuma permissão para os dados subjacentes é concedida. As seguintes permissões adicionais de metadados são concedidas (junto com a capacidade de conceder essas permissões a outras pessoas):
+ `CREATE_TABLE` no banco de dados
+ Banco de dados da `ALTER`
+ Banco de dados da `DROP`
Ao criar um banco de dados, a entidade principal pode opcionalmente especificar um local do Amazon S3. Dependendo se a entidade principal tem permissões de localização de dados, a permissão `CREATE_DATABASE` pode não ser suficiente para criar bancos de dados em todos os casos. É importante ter em mente os três casos a seguir.
| Crie um caso de uso de banco de dados | Permissões necessárias |
| --- | --- |
| A propriedade do local não é especificada. | CREATE\$1DATABASE é suficiente. |
| A propriedade de localização é especificada e a localização não é gerenciada pelo Lake Formation (não está registrada). | CREATE\$1DATABASE é suficiente. |
| A propriedade de localização é especificada e a localização é gerenciada pelo Lake Formation (está registrada). | CREATE\$1DATABASE é obrigatório, além de permissões de localização de dados no local especificado. |
### `CREATE_TABLE`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| CREATE\$1TABLE | DATABASE | glue:CreateTable |
Uma entidade principal com essa permissão pode criar uma tabela de metadados ou um link de recurso no catálogo de dados dentro do banco de dados especificado.
**Example**
O exemplo a seguir concede ao usuário `datalake_user1` permissão para criar tabelas no `retail` banco de dados na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1
--permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}'
```
Quando uma entidade principal cria uma tabela no catálogo de dados, todas as permissões do Lake Formation na tabela são concedidas à entidade principal, com a capacidade de conceder essas permissões a outras pessoas.
**Concessões entre contas**
Se uma conta do proprietário do banco de dados conceder `CREATE_TABLE` a uma conta do destinatário e um usuário na conta do destinatário criar com êxito uma tabela no banco de dados da conta do proprietário, as seguintes regras se aplicam:
+ O usuário e os administradores do data lake na conta do destinatário têm todas as permissões do Lake Formation disponíveis. Eles podem conceder permissões na tabela a outras entidades principais de suas contas. Eles não podem conceder permissões às entidades principais na conta do proprietário ou em qualquer outra conta.
+ Os administradores do data lake na conta do proprietário podem conceder permissões na tabela a outras entidades principais da conta.
**Permissões de localização de dados**
Quando você tenta criar uma tabela que aponta para um local do Amazon S3, dependendo se você tem permissões de localização de dados, a permissão `CREATE_TABLE` pode não ser suficiente para criar uma tabela. É importante ter em mente os três casos a seguir.
| Crie um caso de uso de tabela | Permissões necessárias |
| --- | --- |
| O local especificado não é gerenciado pelo Lake Formation (não está registrado). | CREATE\$1TABLE é suficiente. |
| O local especificado é gerenciado pelo Lake Formation (está registrado), e o banco de dados que o contém não tem propriedade de localização ou tem uma propriedade de localização que não seja um prefixo do Amazon S3 da localização da tabela. | CREATE\$1TABLE é obrigatório, além de permissões de localização de dados no local especificado. |
| O local especificado é gerenciado pelo Lake Formation (está registrado), e o banco de dados que o contém tem uma propriedade de localização que aponta para um local registrado e é um prefixo Amazon S3 da localização da tabela. | CREATE\$1TABLE é suficiente. |
### `DATA_LOCATION_ACCESS`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| DATA\$1LOCATION\$1ACCESS | Local do Amazon S3 | (Permissões do Amazon S3 no local, que devem ser especificadas pela função usada para registrar o local.) |
Essa é a única permissão de localização de dados. Uma entidade principal com essa permissão pode criar um banco de dados ou tabela de metadados que aponte para a localização especificada do Amazon S3. O local deve ser registrado. Uma entidade principal que tem permissões de localização de dados em um local também tem permissões de localização em locais secundários.
**Example**
O exemplo a seguir concede permissões de localização de dados de `s3://products/retail` ao usuário `datalake_user1` na conta 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` não é necessário consultar ou atualizar dados subjacentes. Essa permissão se aplica somente à criação de recursos do catálogo de dados.
Para obter mais informações sobre permissões de local de dados, consulte [Underlying data access control](access-control-underlying-data.md#data-location-permissions).
### `DELETE`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| DELETE | TABLE | (Nenhuma permissão adicional do IAM é necessária se o local estiver registrado.) |
Uma entidade principal com essa permissão pode inserir, atualizar e ler dados subjacentes no local do Amazon S3 especificado pela tabela. A entidade principal também pode visualizar a tabela no console do Lake Formation e recuperar informações sobre a tabela com a API do AWS Glue.
**Example**
O exemplo a seguir concede a `DELETE` permissão ao usuário `datalake_user1` na tabela do banco de dados `inventory` `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DELETE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Essa permissão se aplica somente aos dados no Amazon S3 e não aos dados de outros armazenamentos de dados, como o Amazon Relational Database Service (Amazon RDS).
### `DESCRIBE`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| DESCRIBE | Link de recurso de tabela Link de recurso de banco de dados | `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` |
Uma entidade principal com essa permissão pode visualizar o banco de dados, a tabela ou o link do recurso especificado. Nenhuma outra permissão do catálogo de dados é concedida implicitamente e nenhuma permissão de acesso aos dados é concedida implicitamente. Bancos de dados e tabelas aparecem nos editores de consultas dos serviços integrados, mas nenhuma consulta pode ser feita neles, a menos que outras permissões do Lake Formation (por exemplo, `SELECT`) sejam concedidas.
Por exemplo, um usuário que tem `DESCRIBE` em um banco de dados pode ver o banco de dados e todos os metadados do banco de dados (descrição, localização e assim por diante). No entanto, o usuário não consegue descobrir quais tabelas o banco de dados contém e não pode descartar, alterar ou criar tabelas no banco de dados. Da mesma forma, um usuário que tem `DESCRIBE` em uma tabela pode ver a tabela e os metadados da tabela (descrição, esquema, localização e assim por diante), mas não pode descartar, alterar ou executar consultas na tabela.
A seguir estão algumas regras adicionais para `DESCRIBE`:
+ Se um usuário tiver outras permissões do Lake Formation em um banco de dados, tabela ou link de recurso, `DESCRIBE` será concedida implicitamente.
+ Se um usuário tiver `SELECT` em apenas um subconjunto de colunas para uma tabela (parcial `SELECT`), o usuário estará restrito a ver apenas essas colunas.
+ Você não pode conceder `DESCRIBE` a um usuário que tenha seleção parcial em uma tabela. Por outro lado, você não pode especificar listas de inclusão ou exclusão de colunas para tabelas concedidas a `DESCRIBE`.
**Example**
O exemplo a seguir concede a `DESCRIBE` permissão ao usuário `datalake_user1` no link do recurso de tabela no banco de dados `inventory-link` `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```
### `DROP`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| DROP | DATABASE | glue:DeleteDatabase |
| DROP | TABLE | glue:DeleteTable |
| DROP | LF-Tag | lakeformation:DeleteLFTag |
| DROP | Link de recurso de banco de dados Link de recurso de tabela | `glue:DeleteDatabase` `glue:DeleteTable` |
Uma entidade principal com essa permissão pode colocar um link de banco de dados, tabela ou recurso no catálogo de dados. Você não pode conceder DROP em um banco de dados a uma conta ou organização externa.
**Atenção**
Eliminar um banco de dados elimina todas as tabelas no banco de dados.
**Example**
O exemplo a seguir concede a `DROP` permissão ao usuário no banco de dados `datalake_user1` `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Database": {"Name":"retail"}}'
```
**Example**
O exemplo a seguir concede `DROP` ao usuário `datalake_user1` na tabela `inventory` do banco de dados `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
**Example**
O exemplo a seguir concede `DROP` ao usuário `datalake_user1` na tabela o link do recurso `inventory-link` no banco de dados `retail`.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}'
```
### `INSERT`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| INSERT | TABLE | (Nenhuma permissão adicional do IAM é necessária se o local estiver registrado.) |
Uma entidade principal com essa permissão pode inserir, atualizar e ler dados subjacentes no local do Amazon S3 especificado pela tabela. A entidade principal também pode visualizar a tabela no console do Lake Formation e recuperar informações sobre a tabela com a API do AWS Glue.
**Example**
O exemplo a seguir concede a `INSERT` permissão ao usuário `datalake_user1` na tabela do banco de dados `inventory` `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "INSERT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Essa permissão se aplica somente aos dados no Amazon S3 e não aos dados em outros armazenamentos de dados, como o Amazon RDS.
### `SELECT`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| SELECT | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/lf-permissions-reference.html) | (Nenhuma permissão adicional do IAM é necessária se o local estiver registrado.) |
Uma entidade principal com essa permissão pode visualizar uma tabela no catálogo de dados e consultar os dados subjacentes no Amazon S3 no local especificado pela tabela. A entidade principal pode visualizar a tabela no console do Lake Formation e recuperar informações sobre a tabela com a API do AWS Glue. Se a filtragem de colunas foi aplicada quando essa permissão foi concedida, a entidade principal poderá visualizar os metadados somente das colunas incluídas e poderá consultar dados somente das colunas incluídas.
**nota**
É responsabilidade do serviço de análise integrada aplicar a filtragem de colunas ao processar uma consulta.
**Example**
O exemplo a seguir concede a `SELECT` permissão ao usuário `datalake_user1` na tabela do banco de dados `inventory` `retail` na AWS conta 1111-2222-3333.
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}'
```
Essa permissão se aplica somente aos dados no Amazon S3 e não aos dados em outros armazenamentos de dados, como o Amazon RDS.
Você pode filtrar (restringir o acesso a) colunas específicas com uma lista de inclusão opcional ou uma lista de exclusão. Uma lista de inclusão especifica as colunas que podem ser acessadas. Uma lista de exclusão especifica as colunas que não podem ser acessadas. Na ausência de uma lista de inclusão ou exclusão, todas as colunas da tabela estão acessíveis.
Os resultados de `glue:GetTable` retornam somente as colunas que o autor da chamada tem permissão para visualizar. Serviços integrados, como Amazon Athena e Amazon Redshift, honram as listas de inclusão e exclusão de colunas.
**Example**
O exemplo a seguir concede `SELECT` ao usuário `datalake_user1` na tabela `inventory` usando uma lista de inclusão.
```
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**
O próximo exemplo concede `SELECT` na tabela `inventory` usando uma lista de exclusão.
```
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"]}}}'
```
As seguintes restrições se aplicam à permissão `SELECT`:
+ Ao conceder `SELECT`, você não poderá incluir a opção de concessão se a filtragem de colunas for aplicada.
+ Você não pode restringir o controle de acesso em colunas que são chaves de partição.
+ Uma entidade principal com a permissão `SELECT` em um subconjunto de colunas em uma tabela não pode receber a permissão `ALTER`, `DROP`, `DELETE` ou `INSERT` nessa tabela. Da mesma forma, uma entidade principal com a permissão `ALTER`, `DROP`, `DELETE` ou `INSERT` ou em uma tabela não pode receber a permissão `SELECT` com a filtragem de colunas.
A permissão `SELECT` sempre aparece na página **Permissões de dados** do console do Lake Formation como uma linha separada. A imagem a seguir mostra que `SELECT` é concedida aos usuários `datalake_user2` e `datalake_user3` em todas as colunas da tabela `inventory`.
![\[A página Permissões de dados mostra quatro linhas. A primeira linha lista as permissões Delete e Insert com o tipo de recurso Table, com o recurso exibido como inventory, e a segunda e quarta linhas listam a permissão Select com o tipo de recurso Column e com o recurso exibido como retail.inventory.*.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/data-permissions-dialog-select-cross.png)
### `Super`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| Super | DATABASE | glue:\$1Database\$1 |
| Super | TABLE | glue:\$1Table\$1, glue:\$1Partition\$1 |
Essa permissão permite que uma entidade principal execute todas as operações suportadas do Lake Formation no banco de dados ou na tabela. Você não pode conceder `Super` em um banco de dados para uma conta externa.
Essa permissão pode coexistir com as outras permissões do Lake Formation. Por exemplo, você pode conceder as permissões `Super`, `SELECT` e `INSERT` e em uma tabela de metadados. A entidade principal pode então executar todas as operações suportadas na tabela. Quando você revoga `Super`, as permissões `SELECT` e `INSERT` permanecem, e a entidade principal só pode realizar operações de seleção e inserção.
Em vez de conceder `Super` a uma entidade principal individual, você pode concedê-la ao grupo `IAMAllowedPrincipals`. O grupo `IAMAllowedPrincipals` é criado automaticamente e inclui todos os usuários e perfis do IAM que têm acesso permitido aos recursos do seu catálogo de dados por meio de suas políticas do IAM. Quando `Super` é concedido a `IAMAllowedPrincipals` para um recurso do Catálogo de sados, o acesso ao recurso é efetivamente controlado somente pelas políticas do IAM.
Você pode fazer com que a permissão `Super` seja concedida automaticamente a `IAMAllowedPrincipals` para novos recursos do catálogo aproveitando as opções na página **Configurações** do console do Lake Formation.
![\[A caixa de diálogo de configurações do catálogo de dados tem o subtítulo “Permissões padrão para bancos de dados e tabelas recém-criados” e possui duas caixas de seleção, descritas no texto.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/settings-page.png)
+ Para conceder `Super` a `IAMAllowedPrincipals` para todos os novos bancos de dados, selecione **Usar somente o controle de acesso do IAM para novos bancos de dados**.
+ Para conceder `Super` a `IAMAllowedPrincipals` para todas as novas tabelas em novos bancos de dados, selecione **Usar somente o controle de acesso do IAM para novas tabelas em novos bancos de dados**.
**nota**
Essa opção faz com que a caixa de seleção **Usar somente o controle de acesso do IAM para novas tabelas nesse banco de dados** na caixa de diálogo **Criar banco de dados** seja selecionada por padrão. Não faz nada mais do que isso. É a caixa de seleção na caixa de diálogo **Criar banco de dados** que permite a concessão de `Super` a `IAMAllowedPrincipals`.
Essas opções da página **Configurações** estão habilitadas por padrão. Para saber mais, consulte:
+ [Alterando as configurações padrão do seu data lake](change-settings.md)
+ [Atualizando as permissões AWS Glue de dados para o modelo AWS Lake Formation](upgrade-glue-lake-formation.md)
### `SUPER_USER`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| Super user | Catalog | glue:GetCatalog |
É possível conceder a permissão `Super user` somente a entidades principais específicas, em catálogos dentro do Data Catalog padrão. Não é possível conceder permissão `Super user` no catálogo padrão nem em outros tipos de recurso, como bancos de dados e tabelas, ou para entidades principais em contas externas. A permissão `Super user` autoriza que uma entidade principal execute todas as operações aceitas pelo Lake Formation nos bancos de dados e nas tabelas do catálogo concedido.
Com a permissão `Super user`, a entidade principal (beneficiário) pode realizar as seguintes ações nos recursos (catálogos, bancos de dados e tabelas) do catálogo:
+ Permissões `CREATE_DATABASE`, `DESCRIBE` no catálogo.
+ Permissões `DROP`, `ALTER`, `CREATE_TABLE`, `DESCRIBE` (efetivamente, `SUPER`) em todos os bancos de dados do catálogo.
+ Permissões `DROP`, `ALTER`, `DESCRIBE`, `SELECT`, `INSERT`, `DELETE` (efetivamente, `SUPER`) em todas as tabelas em todos os bancos de dados do catálogo.
+ Permissões `All` (efetivamente, SUPER) em catálogos dentro do catálogo.
+ Permissões que podem ser concedidas (a capacidade de conceder essas permissões a outras entidades principais) em todos os catálogos, bancos de dados e tabelas do catálogo.
Com a permissão `Super user` em um recurso do catálogo, o beneficiário não tem permissão para realizar nem delegar as ações `ALTER` e `DROP` no catálogo.
### `ASSOCIATE`
| Permissão | Concedido neste recurso | O beneficiário também precisa |
| --- | --- | --- |
| ASSOCIATE | LF-Tag | `glue:GetDatabase` `glue:GetTable` `lakeformation:AddLFTagsToResource"` `lakeformation:RemoveLFTagsFromResource"` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` |
Uma entidade principal com essa permissão em uma tag do LF pode atribuir a tag do LF a um recurso do catálogo de dados. Concessão `ASSOCIATE` de concessões `DESCRIBE` implicitamente.
**Example**
Este exemplo concede ao usuário `datalake_user1` a permissão `ASSOCIATE` na tag do LF com a chave `module`. Ele concede permissões para visualizar e atribuir todos os valores dessa chave, conforme indicado pelo asterisco (\$1).
```
aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ASSOCIATE" --resource '{ "LFTag": {"CatalogId":"111122223333","TagKey":"module","TagValues":["*"]}}'
```
# Integrar o Centro de Identidade do IAM
Com Centro de Identidade do AWS IAM, você pode se conectar a provedores de identidade (IdPs) e gerenciar centralmente o acesso de usuários e grupos em todos os serviços de AWS análise. É possível integrar provedores de identidade, como Okta, Ping e Microsoft Entra ID (antigo Azure Active Directory), ao Centro de Identidade do IAM para que os usuários da organização acessem dados usando uma experiência de login único. O Centro de Identidade do IAM também aceita a conexão de outros provedores de identidade terceiros.
Para obter mais informações, consulte [Provedores de identidade compatíveis](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) no Guia Centro de Identidade do AWS IAM do usuário.
Você pode configurar AWS Lake Formation como um aplicativo habilitado no IAM Identity Center, e os administradores do data lake podem conceder permissões refinadas a usuários e grupos autorizados sobre recursos. AWS Glue Data Catalog
Os usuários da organização podem entrar em qualquer aplicação habilitada para o Centro de Identidade usando o provedor de identidade da organização e consultar conjuntos de dados aplicando as permissões do Lake Formation. Com essa integração, você pode gerenciar o acesso aos AWS serviços sem criar várias funções do IAM.
A [propagação de identidade confiável](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) é um Centro de Identidade do AWS IAM recurso que os administradores do Connected Serviços da AWS podem usar para conceder e auditar o acesso aos dados do serviço. O acesso a esses dados é baseado em atributos do usuário, como associações de grupo. Configurar a propagação de identidade confiável requer colaboração entre os administradores do Connected Serviços da AWS e os administradores do IAM Identity Center. Para ter mais informações, consulte [Prerequisites and considerations](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
Para conhecer as limitações, consulte [Limitações da integração com o Centro de Identidade do IAM](identity-center-lf-notes.md).
**Topics**
+ [Pré-requisitos para integrar o Centro de Identidade do IAM ao Lake Formation](prerequisites-identity-center.md)
+ [Conectar o Lake Formation ao Centro de Identidade do IAM](connect-lf-identity-center.md)
+ [Atualizar integração com o Centro de Identidade do IAM Identity](update-lf-identity-center-connection.md)
+ [Excluir uma conexão do Lake Formation com o Centro de Identidade do IAM](delete-lf-identity-center-connection.md)
+ [Conceder permissões a usuários e grupos](grant-permissions-sso.md)
+ [Incluindo o contexto do usuário do IAM Identity Center nos CloudTrail registros](identity-center-ct-logs.md)
# Pré-requisitos para integrar o Centro de Identidade do IAM ao Lake Formation
Veja a seguir os pré-requisitos para integrar o Centro de Identidade do IAM ao Lake Formation.
1. Habilitar o Centro de Identidade do IAM: habilitar o Centro de Identidade do IAM é um pré-requisito para oferecer compatibilidade com a autenticação e a propagação de identidade.
1. Selecionar a fonte de identidade: depois de habilitar o Centro de Identidade do IAM, é necessário ter um provedor de identificação para gerenciar usuários e grupos. É possível usar o diretório incorporado do Centro de Identidade como fonte de identidade ou usar IdP externo, como Microsoft Entra ID ou Okta.
Para obter mais informações, consulte [Gerenciar sua fonte de identidade](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html) e [Conectar-se a um provedor de identidade externo](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) no Guia Centro de Identidade do AWS IAM do usuário.
1. Crie um perfil do IAM: a função que cria a conexão do Centro de Identidade do IAM exige permissões para criar e modificar a configuração da aplicação no Lake Formation e no Centro de Identidade do IAM, conforme a política incorporada a seguir.
É necessário adicionar permissões de acordo com as práticas recomendadas do IAM. As permissões específicas são detalhadas nos procedimentos a seguir. Para obter mais informações, consulte [Getting Started with 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": [
"*"
]
}
]
}
```
------
Se você estiver compartilhando recursos do Catálogo de Dados com organizações externas Contas da AWS ou externas, deverá ter as permissões AWS Resource Access Manager (AWS RAM) para criar compartilhamentos de recursos. Para ter mais informações sobre as permissões necessárias para compartilhar recursos, consulte [Cross-account data sharing prerequisites](cross-account-prereqs.md).
As políticas incorporadas a seguir contêm permissões específicas necessárias para visualizar, atualizar e excluir propriedades da integração do Lake Formation com o Centro de Identidade do IAM.
+ Use a política incorporada a seguir para que um perfil do IAM visualize uma integração do Lake Formation ao Centro de Identidade do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
"sso:DescribeApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Use a política incorporada a seguir para que um perfil do IAM atualize uma integração do Lake Formation ao Centro de Identidade do IAM. A política também inclui permissões opcionais necessárias para compartilhar recursos com contas externas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:UpdateLakeFormationIdentityCenterConfiguration",
"lakeformation:DescribeLakeFormationIdentityCenterConfiguration",
"sso:DescribeApplication",
"sso:UpdateApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Use a política incorporada a seguir para que um perfil do IAM exclua uma integração do Lake Formation ao Centro de Identidade do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lakeformation:DeleteLakeFormationIdentityCenterConfiguration",
"sso:DeleteApplication"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Com relação às permissões do IAM necessárias para conceder ou revogar permissões de data lake para usuários e grupos do Centro de Identidade do IAM, consulte [Permissões do IAM necessárias para conceder ou revogar as permissões do Lake Formation](required-permissions-for-grant.md).
*Descrição das permissões*
+ `lakeformation:CreateLakeFormationIdentityCenterConfiguration`: cria a configuração do Lake Formation IdC.
+ `lakeformation:DescribeLakeFormationIdentityCenterConfiguration`: descreve uma configuração existente do IdC.
+ `lakeformation:DeleteLakeFormationIdentityCenterConfiguration`: permite excluir uma configuração existente do Lake Formation IdC.
+ `lakeformation:UpdateLakeFormationIdentityCenterConfiguration`: usado para alterar uma configuração existente do Lake Formation.
+ `sso:CreateApplication`: usado para criar uma aplicação IAM Identity Center.
+ `sso:DeleteApplication`: usado para excluir uma aplicação IAM Identity Center.
+ `sso:UpdateApplication`: usado para atualizar uma aplicação IAM Identity Center.
+ `sso:PutApplicationGrant`: usado para alterar as informações do emissor de tokens confiáveis.
+ `sso:PutApplicationAuthenticationMethod`: concede acesso para autenticação no Lake Formation.
+ `sso:GetApplicationGrant`: usado para listar as informações do emissor de tokens confiáveis.
+ `sso:DeleteApplicationGrant`: exclui as informações do emissor de tokens confiáveis.
+ `sso:PutApplicationAccessScope`: adiciona ou atualiza a lista de alvos autorizados para um escopo de acesso ao Centro de Identidade do IAM para uma aplicação.
+ `sso:PutApplicationAssignmentConfiguration`: usado para configurar como os usuários obtêm acesso a uma aplicação.
# Conectar o Lake Formation ao Centro de Identidade do IAM
Antes de usar o Centro de Identidade do IAM para gerenciar identidades e conceder acesso aos recursos do catálogo de dados usando o Lake Formation, siga as etapas abaixo. É possível criar a integração do Centro de Identidade do IAM usando o console do Lake Formation ou a AWS CLI.
------
#### [ Console de gerenciamento da AWS ]
**Como conectar o Lake Formation ao Centro de Identidade do IAM**
1. Faça login no Console de gerenciamento da AWS, e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. No painel de navegação esquerdo, selecione **Integração com o Centro de Identidade do IAM**.
![\[Tela de integração do Centro de Identidade do IAM com o ARN do Centro de Identidade.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/identity-center-integ.png)
1. (Opcional) Insira uma ou mais unidades and/or organizacionais válidas Conta da AWS IDs IDs para permitir que contas externas acessem os recursos do Catálogo de Dados. IDs Quando usuários ou grupos do Centro de Identidade do IAM tentam acessar os recursos do Catálogo de Dados gerenciado do Lake Formation, o Lake Formation assume um perfil do IAM para autorizar o acesso aos metadados. Se a função do IAM pertencer a uma conta externa que não tem uma política de AWS Glue recursos e um compartilhamento de AWS RAM recursos, os usuários e grupos do IAM Identity Center não poderão acessar o recurso, mesmo que tenham permissões do Lake Formation.
Lake Formation usa o serviço AWS Resource Access Manager (AWS RAM) para compartilhar o recurso com contas e organizações externas. AWS RAM envia um convite para a conta do beneficiário para aceitar ou rejeitar o compartilhamento de recursos.
Para obter mais informações, consulte [Aceitando um convite de compartilhamento de recursos do AWS RAM](accepting-ram-invite.md).
**nota**
O Lake Formation permite que os perfis do IAM de contas externas atuem como perfis operadores em nome dos usuários e grupos do Centro de Identidade do IAM para acessar os recursos do Catálogo de Dados, mas as permissões só podem ser concedidas em recursos do Catálogo de Dados dentro da conta proprietária. Se você tentar conceder permissões a usuários e grupos do Centro de Identidade do IAM em recursos do Catálogo de Dados em uma conta externa, o Lake Formation vai gerar o seguinte erro: “Cross-account grants are not supported for the principal”.
1. (Opcional) Na tela de **integração do Create Lake Formation**, especifique os aplicativos ARNs de terceiros que podem acessar dados em locais do Amazon S3 registrados no Lake Formation. A Lake Formation vende credenciais temporárias com escopo reduzido na forma de tokens para locais AWS STS registrados do Amazon S3 com base nas permissões efetivas, para que aplicativos autorizados possam acessar dados em nome dos usuários.
1. (Opcional) Na tela de **integração Create Lake Formation**, marque a caixa de seleção Amazon Redshift Connect no Trusted Identity Propagation para permitir a descoberta de permissões federadas do Amazon Redshift via IDC. O Lake Formation propaga a identidade para sistemas downstream com base nas permissões efetivas, de modo que aplicações autorizadas possam acessar os dados em nome dos usuários.
1. Selecione **Submit (Enviar)**.
Depois que o administrador do Lake Formation concluir as etapas e criar a integração, as propriedades do Centro de Identidade do IAM aparecerão no console do Lake Formation. A conclusão dessas tarefas torna o Lake Formation uma aplicação habilitada para o Centro de Identidade do IAM. As propriedades no console incluem o status da integração. O status de integração indica `Success` quando está concluída. Esse status indica se a configuração do Centro de Identidade do IAM foi concluída.
------
#### [ AWS CLI ]
+ O exemplo a seguir mostra como criar a integração do Lake Formation ao Centro de Identidade do IAM. Também é possível especificar o `Status` (`ENABLED`, `DISABLED`) das aplicações.
```
aws lakeformation create-lake-formation-identity-center-configuration \
--catalog-id <123456789012> \
--instance-arn \
--share-recipients '[{"DataLakePrincipalIdentifier": "<123456789012>"},
{"DataLakePrincipalIdentifier": "<555555555555>"}]' \
--external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'
```
+ O exemplo a seguir mostra como visualizar a integração do Lake Formation ao Centro de Identidade do IAM.
```
aws lakeformation describe-lake-formation-identity-center-configuration
--catalog-id <123456789012>
```
+ O exemplo a seguir mostra como habilitar a `Redshift:Connect` Autorização. A autorização pode ser ATIVADA ou DESATIVADA.
```
aws lakeformation create-lake-formation-identity-center-configuration \
--instance-arn \
--service-integrations '[{
"Redshift": [{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}]
}]'
```
+ Use o `describe-lake-formation-identity-center-configuration` comando para descrever o aplicativo do centro de identidade de formação de lagos. `Redshift:Connect`a integração de serviços é essencial para a propagação de identidade de IDC entre serviços e clusters:
```
aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012>
```
Resposta:
```
{
"CatalogId": "CATALOG ID",
"InstanceArn": "INSTANCE ARN",
"ApplicationArn": "APPLICATION ARN",
"ShareRecipients": [],
"ServiceIntegrations": [
{
"Redshift": [
{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}
]
}
]
}
```
------
## Usando o IAM Identity Center em vários Regiões da AWS
O Lake Formation oferece suporte ao IAM Identity Center em vários Regiões da AWS. Você pode estender o IAM Identity Center de suas regiões principais Região da AWS para regiões adicionais para melhorar o desempenho por meio da proximidade com os usuários e da confiabilidade. Quando uma nova região é adicionada ao IAM Identity Center, você pode criar aplicativos do Lake Formation Identity Center na nova região sem replicar identidades da região primária. Para obter mais detalhes sobre como começar a usar o IAM Identity Center em várias regiões, consulte o [Multi-Region IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html) no *Guia do usuário do IAM Identity Center*.
# Atualizar integração com o Centro de Identidade do IAM Identity
Depois de criar a conexão, é possível adicionar aplicações de terceiros para a integração com o Centro de Identidade do IAM a fim de integrá-las ao Lake Formation e obter acesso aos dados do Amazon S3 em nome dos usuários. Também é possível remover aplicações existentes da integração com o Centro de Identidade do IAM. Você pode adicionar ou remover aplicativos usando o console Lake Formation e usando [UpdateLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_UpdateLakeFormationIdentityCenterConfiguration.html)a operação. AWS CLI
**nota**
Depois de criar a integração com o Centro de Identidade do IAM, não é possível atualizar o `ARN` da instância.
------
#### [ Console de gerenciamento da AWS ]
**Como atualizar uma conexão existente do Centro de Identidade do IAM com o Lake Formation**
1. Faça login no Console de gerenciamento da AWS, e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. No painel de navegação esquerdo, selecione **Integração com o Centro de Identidade do IAM**.
1. Selecione **Adicionar** na página **Integração com o Centro de Identidade do IAM**.
1. Insira uma ou mais unidades and/or organizacionais válidas Conta da AWS IDs IDs para permitir que contas externas acessem os recursos do Catálogo de Dados. IDs
1. Na tela **Adicionar aplicativos**, insira o aplicativo IDs dos aplicativos de terceiros que você deseja integrar ao Lake Formation.
1. Selecione **Adicionar**.
1. (Opcionalmente) Na página de **integração do IAM Identity Center, você pode ativar a propagação de identidade** confiável para o Amazon Redshift Connect ou desativá-la. O Lake Formation propaga a identidade para sistemas downstream com base nas permissões efetivas, de modo que aplicações autorizadas possam acessar os dados em nome dos usuários.
------
#### [ AWS CLI ]
Você pode adicionar ou remover aplicativos de terceiros para a integração do IAM Identity Center executando o AWS CLI comando a seguir. Ao definir o status de filtragem externa como `ENABLED`, ele permite que o Centro de Identidade do IAM forneça gerenciamento de identidade para aplicações de terceiros acessarem dados gerenciados pelo Lake Formation. Também é possível habilitar ou desabilitar a integração com o Centro de Identidade do IAM definindo o status da aplicação.
```
aws lakeformation update-lake-formation-identity-center-configuration \
--external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'\
--share-recipients '[{"DataLakePrincipalIdentifier": "<444455556666>"}
{"DataLakePrincipalIdentifier": "<777788889999>"}]' \
--application-status ENABLED
```
Se você tem um aplicativo LF IDC existente, mas deseja adicionar a `Redshift:Connect` autorização, você pode usar o seguinte para atualizar seu aplicativo Lake Formation IDC. A autorização pode ser ATIVADA ou DESATIVADA.
```
aws lakeformation update-lake-formation-identity-center-configuration \
--service-integrations '[{
"Redshift": [{
"RedshiftConnect": {
"Authorization": "ENABLED"
}
}]
}]'
```
------
# Excluir uma conexão do Lake Formation com o Centro de Identidade do IAM
Se quiser excluir uma integração existente do IAM Identity Center, você pode fazer isso usando o console ou a [DeleteLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DeleteLakeFormationIdentityCenterConfiguration.html)operação do Lake Formation. AWS CLI
------
#### [ Console de gerenciamento da AWS ]
**Como excluir uma conexão existente do Centro de Identidade do IAM com o Lake Formation**
1. Faça login no Console de gerenciamento da AWS, e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. No painel de navegação esquerdo, selecione **Integração com o Centro de Identidade do IAM**.
1. Selecione **Excluir** na página **Integração com o Centro de Identidade do IAM**.
1. Na tela **Confirmar integração**, confirme a ação e selecione **Excluir**.
------
#### [ AWS CLI ]
Você pode excluir a integração do IAM Identity Center executando o AWS CLI comando a seguir.
```
aws lakeformation delete-lake-formation-identity-center-configuration \
--catalog-id <123456789012>
```
------
# Conceder permissões a usuários e grupos
O administrador do data lake pode conceder permissões a usuários e grupos do Centro de Identidade do IAM nos recursos do catálogo de dados (bancos de dados, tabelas e visualizações) para facilitar o acesso aos dados. Para conceder ou revogar as permissões do data lake, o concessor exige permissões para as ações a seguir do Centro de Identidade do IAM.
+ [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)
É possível conceder permissões usando o console do Lake Formation, a API ou a AWS CLI.
Para obter mais informações sobre a concessão de permissões, consulte [Conceder permissões nos recursos do Catálogo de Dados](granting-catalog-permissions.md)
**nota**
Só é possível conceder permissões em recursos em sua conta. Para distribuir permissões em cascata para usuários e grupos em recursos compartilhados com você, você deve usar compartilhamentos de AWS RAM recursos.
------
#### [ Console de gerenciamento da AWS ]
**Como conceder permissões a usuários e grupos**
1. Faça login no Console de gerenciamento da AWS, e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Selecione **Permissões do data lake** em **Permissões** no console do Lake Formation.
1. Selecione **Conceder**.
1. Na página **Conceder permissões de data lake**, selecione usuários e grupos do **Centro de Identidade do IAM**.
1. Selecione **Adicionar** para escolher os usuários e os grupos aos quais conceder permissões.
![\[Tela Conceder permissões de data lake com usuários e grupos do Centro de Identidade do IAM selecionados.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/identity-center-grant-perm.png)
1. Na tela **Atribuir usuários e grupos**, escolha os and/or grupos de usuários para conceder permissões.
Selecione **Atribuir**.
![\[Tela Conceder permissões de data lake com usuários e grupos do Centro de Identidade do IAM selecionados.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/identity-center-assign-users-groups.png)
1. Depois, escolha o método para conceder permissões.
Para obter instruções sobre como conceder permissões usando o método de recursos nomeados, consulte [Conceder permissões de dados usando o método de recurso nomeado](granting-cat-perms-named-resource.md).
Para obter instruções sobre como conceder permissão usando tags do LF, consulte [Conceder permissões de data lake usando o método LF-TBAC](granting-catalog-perms-TBAC.md).
1. Selecione os recursos do catálogo de dados nos quais deseja conceder as permissões.
1. Selecione as permissões do catálogo de dados a serem concedidas.
1. Selecione **Conceder**.
------
#### [ AWS CLI ]
O exemplo a seguir mostra como conceder a permissão `SELECT` ao usuário do Centro de Identidade do IAM em uma tabela.
```
aws lakeformation grant-permissions \
--principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ \
--permissions "SELECT" \
--resource '{ "Table": { "DatabaseName": "retail", "TableWildcard": {} } }'
```
Para recuperar `UserId` do IAM Identity Center, consulte a [GetUserId](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html)operação na Referência da API do IAM Identity Center.
------
# Incluindo o contexto do usuário do IAM Identity Center nos CloudTrail registros
O Lake Formation usa a funcionalidade de [fornecimento de credenciais](using-cred-vending.md) para conceder acesso temporário aos dados do Amazon S3. Por padrão, quando um usuário do IAM Identity Center envia uma consulta a um serviço de análise integrado, os CloudTrail registros incluem apenas a função do IAM assumida pelo serviço para fornecer acesso de curto prazo. Se você usar uma função definida pelo usuário para registrar a localização dos dados do Amazon S3 no Lake Formation, poderá optar por incluir o contexto do usuário do IAM Identity Center nos eventos e, em CloudTrail seguida, rastrear os usuários que acessam seus recursos.
**Importante**
Para incluir solicitações de API do Amazon S3 em nível de objeto no, você precisa CloudTrail habilitar CloudTrail o registro de eventos para bucket e objetos do Amazon S3. Para obter mais informações, consulte [Habilitando o registro de CloudTrail eventos para buckets e objetos do Amazon S3 no Guia do usuário](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) do Amazon S3.
**Como habilitar a auditoria do fornecimento de credenciais em localizações de data lake registradas com perfis definidos pelo usuário**
1. Faça login no console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. No painel de navegação à esquerda, expanda **Administração** e selecione **Configurações do Catálogo de Dados**.
1. Em **Auditoria aprimorada**, escolha **Propagar contexto fornecido**.
1. Escolha **Salvar**.
Você também pode ativar a opção de auditoria aprimorada definindo o `Parameters` atributo na [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html)operação. Por padrão, o parâmetro `SET_CONTEXT"` é definido como verdadeiro.
```
{
"DataLakeSettings": {
"Parameters": {"SET_CONTEXT": "true"},
}
}
```
A seguir está um trecho de um CloudTrail evento com a opção de auditoria aprimorada. Esse log inclui o contexto de sessão do usuário do Centro de Identidade do IAM Identity e o perfil do IAM definido pelo usuário assumido pelo Lake Formation para acessar a localização de dados do Amazon S3. Veja o parâmetro `onBehalfOf` no trecho a seguir.
```
{
"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",
....
```
# Adicionar uma localização do Amazon S3 ao seu data lake
Para adicionar um local de dados como armazenamento em seu data lake, você *registra* o local (localização do **data lake**) com AWS Lake Formation. Em seguida, você pode usar as permissões do Lake Formation para um controle de acesso refinado a AWS Glue Data Catalog objetos que apontam para esse local e para os dados subjacentes no local.
O Lake Formation também permite registrar uma localização de dados no modo de acesso híbrido e fornece a flexibilidade de habilitar seletivamente as permissões do Lake Formation para bancos de dados e tabelas em seu catálogo de dados. Com o modo de acesso híbrido, você tem um caminho incremental que permite definir permissões do Lake Formation para um conjunto específico de usuários sem interromper as políticas de permissão de outros usuários ou workloads existentes.
Para obter mais informações sobre como configurar o modo de acesso híbrido, consulte [Modo de acesso híbrido](hybrid-access-mode.md)
Quando você registra um local, esse caminho do Amazon S3 e todas as pastas sob esse caminho são registrados.
Por exemplo, digamos que você tenha uma organização de caminhos do Amazon S3 como a seguinte:
`/mybucket/accounting/sales/`
Se você se registrar `S3://mybucket/accounting`, a pasta `sales` também será registrada e sob o gerenciamento do Lake Formation.
Para obter mais informações sobre o registro de locais, consulte [Underlying data access control](access-control-underlying-data.md#underlying-data-access-control).
**nota**
As permissões do Lake Formation são recomendadas para dados estruturados (organizados em tabelas com linhas e colunas). Se os dados contiverem dados não estruturados baseados em objetos, pense em usar o recurso Concessão de Acesso do Amazon S3 para gerenciar o acesso aos dados.
**Topics**
+ [Requisitos para funções usadas para registrar locais](registration-role.md)
+ [Registrando uma localização do Amazon S3](register-location.md)
+ [Registrando uma localização criptografada do Amazon S3](register-encrypted.md)
+ [Registrando uma localização do Amazon S3 em outra conta AWS](register-cross-account.md)
+ [Registrando uma localização criptografada do Amazon S3 em todas as contas AWS](register-cross-encrypted.md)
+ [Cancelar o registro de uma localização do Amazon S3](unregister-location.md)
# Requisitos para funções usadas para registrar locais
Você deve especificar uma função AWS Identity and Access Management (IAM) ao registrar uma localização do Amazon Simple Storage Service (Amazon S3). AWS Lake Formation assume essa função ao acessar os dados nesse local.
Você pode usar um dos seguintes tipos de perfil para registrar um local:
+ A função vinculada ao serviço do Lake Formation. Esse perfil concede as permissões necessárias no local. O uso desse perfil é a maneira mais simples de registrar o local. Para obter mais informações, consulte [Usar perfis vinculados ao serviço para o Lake Formation](service-linked-roles.md) e [Limitações de perfis vinculadas a serviços](service-linked-role-limitations.md).
+ Um perfil definido pelo usuário. Use um perfil definido pelo usuário quando precisar conceder mais permissões do que o perfil vinculado ao serviço fornece.
Você deve usar um perfil definido pelo usuário nas seguintes circunstâncias:
+ Ao registrar um local em outra conta.
Para obter mais informações, consulte [Registrando uma localização do Amazon S3 em outra conta AWS](register-cross-account.md) e [Registrando uma localização criptografada do Amazon S3 em todas as contas AWS](register-cross-encrypted.md).
+ Se você usou uma CMK AWS gerenciada (`aws/s3`) para criptografar a localização do Amazon S3.
Para obter mais informações, consulte [Registrando uma localização criptografada do Amazon S3](register-encrypted.md).
+ Se você planeja acessar o local usando o Amazon EMR.
Se você já registrou um local com o perfil vinculado ao serviço e deseja começar a acessar o local com o Amazon EMR, você deve cancelar o registro do local e registrá-lo novamente com um perfil definido pelo usuário. Para obter mais informações, consulte [Cancelar o registro de uma localização do Amazon S3](unregister-location.md).
# Usar perfis vinculados ao serviço para o Lake Formation
AWS Lake Formation usa uma função *vinculada ao serviço AWS Identity and Access Management * (IAM). Um perfil vinculado ao serviço é um tipo exclusivo de perfil do IAM vinculado diretamente ao Lake Formation. A função vinculada ao serviço é predefinida pelo Lake Formation e inclui todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
Um perfil vinculado ao serviço facilita a configuração do Lake Formation porque você não precisa criar um perfil e adicionar manualmente as permissões necessárias. O Lake Formation define as permissões de seu perfil vinculado ao serviço e, a menos que definido de outra forma, apenas o Lake Formation pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política de permissões não pode ser anexada a nenhuma outra entidade do IAM.
Este perfil vinculado ao serviço confia nos seguintes serviços para assumir a função:
+ `lakeformation.amazonaws.com`
Quando você usa um perfil vinculado ao serviço na conta A para registrar uma localização do Amazon S3 que é de propriedade da conta B, a política de bucket do Amazon S3 (uma política baseada em recursos) na conta B deve conceder permissões de acesso ao perfil vinculado ao serviço na conta A.
Para acessar informações sobre o uso de perfis vinculados a serviços para registrar um local de dados, consulte [Limitações de perfis vinculadas a serviços](service-linked-role-limitations.md).
**nota**
As políticas de controle de serviço (SCPs) não afetam as funções vinculadas ao serviço.
Para obter mais informações, consulte [Políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *guia AWS Organizations do usuário*.
## Permissões de perfil vinculado ao serviço para o Lake Formation
O Lake Formation usa o perfil vinculado ao serviço chamado `AWSServiceRoleForLakeFormationDataAccess`. Essa função fornece um conjunto de permissões do Amazon Simple Storage Service (Amazon S3) que permitem que o serviço integrado Lake Formation ( Amazon Athena como) acesse locais registrados. Ao registrar um local de data lake, você deve fornecer uma função que tenha as read/write permissões necessárias do Amazon S3 nesse local. Em vez de criar um perfil com as permissões necessárias para o Amazon S3, você pode usar esse perfil vinculado ao serviço.
Na primeira vez que você nomeia o perfil vinculado ao serviço como o perfil com o qual registrar um caminho, o perfil vinculado ao serviço e uma nova política do IAM são criadas em seu nome. O Lake Formation adiciona o caminho à política embutida e o anexa ao perfil vinculado ao serviço. Quando você registra caminhos subsequentes com o perfil vinculado ao serviço, o Lake Formation adiciona o caminho à política existente.
Enquanto estiver conectado como administrador do data lake, registre um local do data lake. Em seguida, no console do IAM, pesquise o perfil `AWSServiceRoleForLakeFormationDataAccess` e visualize as políticas anexadas.
Por exemplo, depois de registrar o local `s3://my-kinesis-test/logs`, o Lake Formation cria a seguinte política embutida e a anexa 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"
]
}
]
}
```
------
## Criar um perfil vinculado a serviços para o Lake Formation
Não é necessário criar manualmente um perfil vinculado ao serviço. Quando você registra um local do Amazon S3 com o Lake Formation na Console de gerenciamento da AWS, na ou na AWS API AWS CLI, o Lake Formation cria a função vinculada ao serviço para você.
**Importante**
Esse perfil vinculado ao serviço pode aparecer em sua conta se você concluiu uma ação em outro serviço que usa os atributos compatíveis com esse perfil. Para saber mais, consulte [Uma nova função apareceu na minha conta do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
Se excluir essa função vinculada ao serviço e precisar criá-la novamente, você pode usar esse mesmo processo para recriar a função na sua conta. Quando você registra uma localização do Amazon S3 com o Lake Formation, o Lake Formation cria o perfil vinculado ao serviço para você outra vez.
Também é possível usar o console do IAM para criar um perfil vinculado ao serviço com o caso de uso do **Lake Formation**. Na AWS CLI ou na AWS API, crie uma função vinculada ao serviço com o nome do `lakeformation.amazonaws.com` serviço. Para saber mais, consulte [Criar um perfil vinculado a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) no *Guia do usuário do IAM*. Se você excluir essa função vinculada ao serviço, será possível usar esse mesmo processo para criar a função novamente.
## Editar um perfil vinculado a serviços para o Lake Formation
O Lake Formation não permite que você edite o perfil vinculado ao serviço `AWSServiceRoleForLakeFormationDataAccess`. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para saber mais, consulte [Editar uma função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*.
## Excluir um perfil vinculado a serviços para o Lake Formation
Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar os recursos de seu perfil vinculado ao serviço antes de excluí-lo manualmente.
**nota**
Se o serviço Lake Formation estiver usando o perfil quando você tentar excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente.
**Para excluir os recursos do Lake Formation usados pelo Lake Formation**
+ Se você usou o perfil vinculado ao serviço para registrar localizações do Amazon S3 com o Lake Formation, antes de excluí-lo, será necessário cancelar o registro da localização e registrá-la novamente usando um perfil personalizado.
**Como excluir manualmente o perfil vinculado ao serviço usando o IAM**
Use o console do IAM AWS CLI, o ou a AWS API para excluir a função `AWSServiceRoleForLakeFormationDataAccess` vinculada ao serviço. Para saber mais, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*.
A seguir estão os requisitos para um perfil definido pelo usuário:
+ Ao criar o novo perfil, na página **Criar perfil** do console do IAM, escolha **Serviço da AWS ** e, em seguida, em **Escolha um caso de uso**, escolha **Lake Formation**.
Se você criar o perfil usando um caminho diferente, certifique-se de que o perfil tenha uma relação de confiança com `lakeformation.amazonaws.com`. Para acessar mais informações, consulte [Modificar uma política de confiança de perfil (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html).
+ A função deve ter uma política em linha que conceda ao Amazon read/write S3 permissões no local. A seguir está uma política típica.
------
#### [ 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"
]
}
]
}
```
------
+ Adicione a política de confiança a seguir ao perfil do IAM para permitir que o serviço Lake Formation assuma o perfil e forneça credenciais temporárias aos mecanismos de analytics integrados.
Para incluir o contexto do usuário do IAM Identity Center nos CloudTrail registros, a política de confiança deve ter a permissão para a `sts:SetContext` ação.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerAssumeRole1",
"Effect": "Allow",
"Principal": {
"Service": [
"lakeformation.amazonaws.com"
]
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
]
}
```
------
+ O administrador do data lake que registra o local deve ter a permissão `iam:PassRole` sobre o perfil.
A seguir está uma política embutida que concede essa permissão. **Substitua por um número de AWS conta válido e ** substitua pelo nome da função.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PassRolePermissions",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/"
]
}
]
}
```
------
+ Para permitir que o Lake Formation adicione CloudWatch registros em Logs e publique métricas, adicione a seguinte política em linha.
**nota**
A gravação no CloudWatch Logs incorre em uma cobrança.
------
#### [ 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:*"
]
}
]
}
```
------
# Registrando uma localização do Amazon S3
Você deve especificar uma função AWS Identity and Access Management (IAM) ao registrar uma localização do Amazon Simple Storage Service (Amazon S3). O Lake Formation assume essa função quando concede credenciais temporárias a AWS serviços integrados que acessam os dados naquele local.
**Importante**
Evite registrar um bucket do Amazon S3 que tenha o **Solicitante paga** ativado. Para buckets registrados no Lake Formation, a função usada para registrar o bucket é sempre vista como solicitante. Se o bucket for acessado por outra AWS conta, o proprietário do bucket será cobrado pelo acesso aos dados se a função pertencer à mesma conta do proprietário do bucket.
Você pode usar o AWS Lake Formation console, a API Lake Formation ou AWS Command Line Interface (AWS CLI) para registrar uma localização no Amazon S3.
**Antes de começar**
Analise os [requisitos da função usada para registrar o local](registration-role.md).
**Para registrar uma localização (console)**
**Importante**
Os procedimentos a seguir pressupõem que a localização do Amazon S3 esteja na mesma AWS conta do Catálogo de Dados e que os dados na localização não estejam criptografados. Outras seções deste capítulo abrangem o registro de várias contas e o registro de locais criptografados.
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com a permissão `lakeformation:RegisterResource` do IAM.
1. No painel de navegação, em **Administração** selecione **Localizações do data lake**.
1. Escolha **Registrar localização** e, em seguida, escolha **Procurar** para selecionar um caminho do Amazon Simple Storage Service (Amazon S3).
1. (Opcional, mas altamente recomendado) Selecione **Revisar permissões de local** para ver uma lista de todos os recursos existentes no local selecionado do Amazon S3 e as permissões.
Registrar o local selecionado pode fazer com que seus usuários do Lake Formation tenham acesso aos dados que já estão nesse local. A visualização dessa lista ajuda a garantir que os dados existentes permaneçam seguros.
1. Para o **perfil do IAM**, escolha a função `AWSServiceRoleForLakeFormationDataAccess` vinculada ao serviço (a padrão) ou um perfil personalizado do IAM que atenda aos requisitos em [Requisitos para funções usadas para registrar locais](registration-role.md).
É possível atualizar um local registrado ou outros detalhes somente ao registrá-lo usando um perfil personalizado do IAM. Para editar um local registrado usando um perfil vinculado ao serviço, é necessário cancelar o registro do local e registrá-lo novamente.
1. Escolha a opção **Ativar Federação do Catálogo de Dados** para permitir que o Lake Formation assuma uma função e forneça credenciais temporárias aos AWS serviços integrados para acessar tabelas em bancos de dados federados. Se um local estiver registrado no Lake Formation e você quiser usar o mesmo local para uma tabela em um banco de dados federado, será necessário registrar o mesmo local com a opção **Habilitar federação do catálogo de dados**.
1. Escolha o **Modo de acesso híbrido** para não ativar as permissões do Lake Formation por padrão. Ao registrar o local do Amazon S3 no modo de acesso híbrido, você pode habilitar as permissões do Lake Formation optando por entidades principais para bancos de dados e tabelas nesse local.
Para obter mais informações sobre como configurar o modo de acesso híbrido, consulte [Modo de acesso híbrido](hybrid-access-mode.md).
1. Selecione **Registrar local**.
**Para registrar um local (AWS CLI)**
1.
**Registrar o novo local no Lake Formation**
Este exemplo usa um perfil vinculado ao serviço para registrar o local. Em vez disso, você pode usar o argumento `--role-arn` para fornecer sua própria função.
**Substitua por um caminho válido do Amazon S3, o número da conta por uma AWS conta válida e ** por uma função do IAM que tenha permissões para registrar um local de dados.
**nota**
Não será possível editar propriedades de um local registrado se ele estiver registrado usando um perfil vinculado ao serviço.
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--use-service-linked-role
```
O exemplo a seguir usa um perfil personalizado para registrar o local.
```
aws lakeformation register-resource \
--resource-arn arn:aws:s3::: \
--role-arn arn:aws:iam::<123456789012>:role/
```
1.
**Como atualizar o local registrado no Lake Formation**
Será possível editar um local registrado somente se ele estiver registrado usando um perfil personalizado do IAM. Para um local registrado com um perfil vinculado ao serviço, é necessário cancelar o registro do local e registrá-lo novamente. Para obter mais informações, consulte [Cancelar o registro de uma localização do 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 um local de dados no modo de acesso híbrido com federação**
```
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 obter mais informações, consulte Operação [RegisterResource](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_RegisterResource.html)da API.
**nota**
Depois de registrar uma localização no Amazon S3, qualquer AWS Glue tabela apontando para a localização (ou qualquer uma de suas localizações secundárias) retornará o valor do `IsRegisteredWithLakeFormation` parâmetro como `true` na `GetTable` chamada. Há uma limitação conhecida de que as operações da API do catálogo de dados, como `GetTables` e `SearchTables`, não atualizam o valor do parâmetro `IsRegisteredWithLakeFormation` e retornam o padrão, que é falso. É recomendável usar a API `GetTable` para visualizar o valor correto do parâmetro `IsRegisteredWithLakeFormation`.
# Registrando uma localização criptografada do Amazon S3
O Lake Formation se integra com [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS) para permitir que você configure com mais facilidade outros serviços integrados para criptografar e descriptografar dados em locais do Amazon Simple Storage Service (Amazon S3).
Tanto o cliente é gerenciado AWS KMS keys Chaves gerenciadas pela AWS quanto o suporte. Atualmente, o lado do cliente encryption/decryption é compatível somente com o Athena.
Você deve especificar uma função AWS Identity and Access Management (IAM) ao registrar uma localização no Amazon S3. Para locais criptografados do Amazon S3, a função deve ter permissão para criptografar e descriptografar dados com o. Ou a política de chaves do AWS KMS key KMS deve conceder permissões sobre a chave da função.
**Importante**
Evite registrar um bucket do Amazon S3 que tenha o **Solicitante paga** ativado. Para buckets registrados no Lake Formation, a função usada para registrar o bucket é sempre vista como solicitante. Se o bucket for acessado por outra AWS conta, o proprietário do bucket será cobrado pelo acesso aos dados se a função pertencer à mesma conta do proprietário do bucket.
O Lake Formation usa um perfil vinculado a serviços para registrar seus locais de dados. No entanto, esse perfil tem várias [limitações](service-linked-role-limitations.md). Devido a essas restrições, recomendamos criar e usar um perfil personalizado do IAM para ter maior flexibilidade e controle. O perfil personalizado que você cria para registrar o local deve atender aos requisitos especificados em [Requisitos para funções usadas para registrar locais](registration-role.md).
**Importante**
Se você usou um Chave gerenciada pela AWS para criptografar a localização do Amazon S3, você não pode usar a função vinculada ao serviço Lake Formation. Você deve usar um papel personalizado e adicionar permissões do IAM na chave do perfil. Os detalhes são fornecidos posteriormente nesta seção.
Os procedimentos a seguir explicam como registrar um local do Amazon S3 criptografado com uma chave gerenciada pelo cliente ou uma Chave gerenciada pela AWS.
+ [Registrar um local criptografado com uma chave gerenciada pelo cliente](#proc-register-cust-cmk)
+ [Registrando um local criptografado com um Chave gerenciada pela AWS](#proc-register-aws-cmk)
**Antes de começar**
Analise os [requisitos da função usada para registrar o local](registration-role.md).
**Para registrar uma localização do Amazon S3 criptografada com uma chave gerenciada pelo cliente**
**nota**
Se a chave KMS ou a localização do Amazon S3 não estiverem na AWS mesma conta do catálogo de dados, siga as instruções [Registrando uma localização criptografada do Amazon S3 em todas as contas AWS](register-cross-encrypted.md) em vez disso.
1. Abra o AWS KMS console em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) e faça login como um usuário administrativo AWS Identity and Access Management (IAM) ou como um usuário que pode modificar a política de chaves da chave KMS usada para criptografar o local.
1. No painel de navegação, selecione **Chaves gerenciadas pelo cliente** e selecione o nome da chave do KMS desejada.
1. Na página de detalhes da chave KMS, escolha a guia **Política de chaves** e, em seguida, faça o seguinte para adicionar sua função personalizada ou a função vinculada ao serviço Lake Formation como usuário da chave KMS:
+ **Se a visualização padrão estiver sendo exibida** (com as seções **Administradores** de **chaves, Exclusão** de **chaves, Usuários** de chaves e **Outras AWS contas**), na seção **Usuários principais**, adicione sua função personalizada ou a função vinculada ao serviço Lake Formation. `AWSServiceRoleForLakeFormationDataAccess`
+ **Se a política de chaves (JSON) estiver sendo exibida** – edite a política para adicionar sua função personalizada ou a função `AWSServiceRoleForLakeFormationDataAccess` vinculada ao serviço Lake Formation ao objeto “Permitir o uso da chave”, conforme mostrado no exemplo a seguir.
**nota**
Se esse objeto estiver ausente, adicione-o com as permissões mostradas no exemplo. O exemplo usa a função vinculada ao serviço.
```
...
{
"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 o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com a permissão `lakeformation:RegisterResource` do IAM.
1. No painel de navegação, em **Administração** em **Locais de data lake**.
1. Escolha **Registrar localização** e, em seguida, escolha **Procurar** para selecionar um caminho do Amazon Simple Storage Service (Amazon S3).
1. (Opcional, mas altamente recomendado) Escolha **Revisar permissões de localização** para ver uma lista de todos os recursos existentes no local selecionado do Amazon S3 e suas permissões.
Registrar o local selecionado pode fazer com que seus usuários do Lake Formation tenham acesso aos dados que já estão nesse local. A visualização dessa lista ajuda a garantir que os dados existentes permaneçam seguros.
1. Para o **perfil do IAM**, escolha a função `AWSServiceRoleForLakeFormationDataAccess` vinculada ao serviço (a padrão) ou sua função personalizada que atenda a [Requisitos para funções usadas para registrar locais](registration-role.md).
1. Escolha **Registrar local**.
Para saber mais sobre a função vinculada ao serviço do , consulte [Permissões de perfil vinculado ao serviço para o Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Para registrar uma localização do Amazon S3 criptografada com um Chave gerenciada pela AWS**
**Importante**
Se a localização do Amazon S3 não estiver na mesma AWS conta do catálogo de dados, siga as instruções em [Registrando uma localização criptografada do Amazon S3 em todas as contas AWS](register-cross-encrypted.md) vez disso.
1. Crie um perfil do IAM para usar para registrar o local. Certifique-se de que ele atenda aos requisitos listados em [Requisitos para funções usadas para registrar locais](registration-role.md).
1. Adicione a seguinte política em linha à função. Ele concede permissões sobre a chave da função. A especificação `Resource` deve designar o nome do recurso da Amazon (ARN) da Chave gerenciada pela AWS. Você pode obter o ARN no AWS KMS console. Para obter o ARN correto, certifique-se de fazer login no AWS KMS console com a mesma AWS conta e região usadas para criptografar o Chave gerenciada pela AWS local.
------
#### [ 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"
}
]
}
```
------
Você pode usar aliases de chave do KMS em vez do ID da chave: `arn:aws:kms:region:account-id:key/alias/your-key-alias`.
Para obter mais informações, consulte [Aliases na AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html) seção do Guia do AWS Key Management Service desenvolvedor.
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com a permissão `lakeformation:RegisterResource` do IAM.
1. No painel de navegação, em **Administração** em **Locais de data lake**.
1. Escolha **Registrar localização** e, em seguida, escolha **Procurar** para selecionar um caminho do Amazon S3.
1. (Opcional, mas altamente recomendado) Escolha **Revisar permissões de localização** para ver uma lista de todos os recursos existentes no local selecionado do Amazon S3 e suas permissões.
Registrar o local selecionado pode fazer com que seus usuários do Lake Formation tenham acesso aos dados que já estão nesse local. A visualização dessa lista ajuda a garantir que os dados existentes permaneçam seguros.
1. Em **Perfil do IAM**, escolha a função que você criou na Etapa 1.
1. Escolha **Registrar local**.
# Registrando uma localização do Amazon S3 em outra conta AWS
AWS Lake Formation permite que você registre localizações do Amazon Simple Storage Service (Amazon S3) em todas as contas. AWS Por exemplo, se AWS Glue Data Catalog estiver na conta A, um usuário na conta A poderá registrar um bucket do Amazon S3 na conta B.
Registrar um bucket do Amazon S3 AWS na conta B usando AWS Identity and Access Management uma função (IAM) AWS na conta A requer as seguintes permissões:
+ O papel na conta A deve conceder permissões no bucket na conta B.
+ A política de bucket na conta B deve conceder permissões de acesso à função na conta A.
**Importante**
Evite registrar um bucket do Amazon S3 que tenha o **Solicitante paga** ativado. Para buckets registrados no Lake Formation, a função usada para registrar o bucket é sempre vista como solicitante. Se o bucket for acessado por outra AWS conta, o proprietário do bucket será cobrado pelo acesso aos dados se a função pertencer à mesma conta do proprietário do bucket.
Você não pode usar a função vinculada ao serviço Lake Formation para registrar um local em outra conta. Em vez disso, é necessário usar uma função definida pelo usuário. A função deve atender aos requisitos do [Requisitos para funções usadas para registrar locais](registration-role.md). Para saber mais sobre a função vinculada ao serviço do , consulte [Permissões de perfil vinculado ao serviço para o Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Antes de começar**
Analise os [requisitos da função usada para registrar o local](registration-role.md).
**Para registrar um local em outra AWS conta**
**nota**
Se o local estiver criptografado, siga as instruções em [Registrando uma localização criptografada do Amazon S3 em todas as contas AWS](register-cross-encrypted.md) vez disso.
O procedimento a seguir pressupõe que uma entidade principal na conta 1111-2222-3333, que contém o catálogo de dados, queira registrar o bucket `awsexamplebucket1` do Amazon S3, que está na conta 1234-5678-9012.
1. Na conta 1111-2222-3333, faça login Console de gerenciamento da AWS e abra o console do IAM em. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Crie uma nova função ou visualize uma função existente que atenda aos requisitos de [Requisitos para funções usadas para registrar locais](registration-role.md). Certifique-se de que a função concede permissões do Amazon S3 em `awsexamplebucket1`.
1. Abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). Faça login com a conta 1234-5678-9012.
1. Na lista **Nome do bucket**, escolha o nome do bucket, `awsexamplebucket1`.
1. Escolha **Permissões**.
1. Na página **Permissões**, escolha **Política de bucket**.
1. No **Editor de políticas do bucket**, cole a política a seguir. Substitua ** pelo nome da sua função.
------
#### [ 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. Escolha **Salvar**.
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login na conta 1111-2222-3333 como administrador do data lake ou como usuário com permissões suficientes para registrar locais.
1. No painel de navegação, em **Administração** em **Locais de data lake**.
1. Na página **Locais de data lake**, selecione **Registrar local**.
1. Na **página Registrar localização**, para o **caminho do Amazon S3**, insira o nome `s3://awsexamplebucket1` do bucket.
**nota**
Você deve digitar o nome do bucket porque os buckets de várias contas não aparecem na lista quando você escolhe **Procurar**.
1. Para o **perfil do IAM**, escolha seu perfil.
1. Escolha **Registrar local**.
# Registrando uma localização criptografada do Amazon S3 em todas as contas AWS
AWS Lake Formation se integra com [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)(AWS KMS) para permitir que você configure com mais facilidade outros serviços integrados para criptografar e descriptografar dados em locais do Amazon Simple Storage Service (Amazon S3).
Tanto as chaves gerenciadas pelo cliente quanto Chaves gerenciadas pela AWS as são suportadas. O lado do cliente não encryption/decryption é suportado.
**Importante**
Evite registrar um bucket do Amazon S3 que tenha o **Solicitante paga** ativado. Para buckets registrados no Lake Formation, a função usada para registrar o bucket é sempre vista como solicitante. Se o bucket for acessado por outra AWS conta, o proprietário do bucket será cobrado pelo acesso aos dados se a função pertencer à mesma conta do proprietário do bucket.
Esta seção explica como registrar uma localização do Amazon S3 nas seguintes circunstâncias:
+ Os dados no local do Amazon S3 são criptografados com uma chave KMS criada no AWS KMS.
+ A localização do Amazon S3 não está na mesma AWS conta do. AWS Glue Data Catalog
+ A chave KMS está ou não na mesma AWS conta do Catálogo de Dados.
O registro de um bucket do Amazon S3 AWS KMS criptografado AWS na conta B usando AWS Identity and Access Management uma função (IAM) AWS na conta A requer as seguintes permissões:
+ O papel na conta A deve conceder permissões no bucket na conta B.
+ A política de bucket na conta B deve conceder permissões de acesso à função na conta A.
+ Se a chave KMS estiver na conta B, a política de chaves deverá conceder acesso à função na conta A, e a função na conta A deverá conceder permissões na chave KMS.
No procedimento a seguir, você cria uma função na AWS conta que contém o Catálogo de Dados (conta A na discussão anterior). Em seguida, você usa essa função para registrar o local. O Lake Formation assume essa função ao acessar dados subjacentes no Amazon S3. A função assumida tem as permissões necessárias na chave do KMS. Como resultado, você não precisa conceder permissões na chave KMS às entidades principais que acessam dados subjacentes com trabalhos de ETL ou com serviços integrados, como o Amazon Athena.
**Importante**
Você não pode usar a função vinculada ao serviço Lake Formation para registrar um local em outra conta. Em vez disso, é necessário usar uma função definida pelo usuário. A função deve atender aos requisitos do [Requisitos para funções usadas para registrar locais](registration-role.md). Para saber mais sobre a função vinculada ao serviço do , consulte [Permissões de perfil vinculado ao serviço para o Lake Formation](service-linked-roles.md#service-linked-role-permissions).
**Antes de começar**
Analise os [requisitos da função usada para registrar o local](registration-role.md).
**Para registrar uma localização criptografada do Amazon S3 em todas as contas AWS**
1. Na mesma AWS conta do Catálogo de dados, faça login Console de gerenciamento da AWS e abra o console do IAM em[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Crie uma nova função ou visualize uma função existente que atenda aos requisitos de [Requisitos para funções usadas para registrar locais](registration-role.md). Certifique-se de que a função inclua uma política que concede permissões do Amazon S3 no local.
1. Se a chave KMS não estiver na mesma conta do Catálogo deDados, adicione à função uma política em linha que conceda as permissões necessárias na chave KMS. Veja abaixo um exemplo de política . Substitua Região e ID da conta pela região e o número da conta da chave do KMS. **Substitua pelo ID da chave.
------
#### [ 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. No console do Amazon S3, adicione uma política de bucket concedendo as permissões do Amazon S3 necessárias para a função. A seguir há um exemplo de política de bucket. Substitua o ID da AWS conta pelo número da conta do Catálogo de Dados, pelo nome da sua função e ** pelo nome do bucket. **
------
#### [ 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. Em AWS KMS, adicione a função como usuário da chave KMS.
1. Abra o AWS KMS console em [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). Em seguida, faça login como usuário administrador ou como usuário que pode modificar a política de chaves da chave KMS usada para criptografar o local.
1. No painel de navegação, selecione **Chaves gerenciadas pelo cliente** e selecione o nome da chave do KMS.
1. Na página de detalhes da chave KMS, na guia **Política de chaves**, se a visualização JSON da política de chaves não estiver sendo exibida, escolha **Alternar para visualização de política**.
1. Na seção **Política de chaves**, escolha **Editar** e adicione o nome do recurso da Amazon (ARN) da função ao objeto `Allow use of the key`, conforme mostrado no exemplo a seguir.
**nota**
Se esse objeto estiver ausente, adicione-o com as permissões mostradas no exemplo.
```
...
{
"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 obter mais informações, consulte [Permitir que usuários de outras contas usem uma chave KMS](https://docs.amazonaws.cn/en_us/kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia do desenvolvedor do AWS Key Management Service *.
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login na conta AWS do catálogo de dados como administrador do data lake.
1. No painel de navegação, em **Administração** em **Locais de data lake**.
1. Escolha **Registrar local**.
1. Na **página Registrar localização**, para **caminho do Amazon S3**, insira o caminho da localização como **s3://**/****. **Substitua pelo nome do bucket e ** pelo resto do caminho do local.
**nota**
Você deve digitar o caminho porque os buckets entre contas não aparecem na lista quando você escolhe **Procurar**.
1. Para o **perfil do IAM**, escolha a função na Etapa 2.
1. Escolha **Registrar local**.
# Cancelar o registro de uma localização do Amazon S3
Você pode cancelar o registro de uma localização do Amazon Simple Storage Service (Amazon S3) se não quiser mais que ela seja gerenciada pelo Lake Formation. O cancelamento do registro de um local não afeta as permissões de localização de dados do Lake Formation concedidas nesse local. Você pode registrar novamente um local que você cancelou e as permissões de localização de dados permanecerão em vigor. Você pode usar uma função diferente para registrar novamente o local.
**Para cancelar o registro de um local (console)**
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com a permissão `lakeformation:RegisterResource` do IAM.
1. No painel de navegação, em **Administração** em **Locais de data lake**.
1. Selecione um local e, no menu **Ações**, escolha **Remover**.
1. Quando solicitada a confirmação, escolha **Remover**.
# Modo de acesso híbrido
AWS Lake Formation o *modo de acesso híbrido* oferece suporte a dois caminhos de permissão para os mesmos AWS Glue Data Catalog objetos.
No primeiro caminho, o Lake Formation permite que você selecione entidades principais específicas e conceda a elas permissões do Lake Formation para acessar catálogos, bancos de dados, tabelas e visualizações, se você optar por isso. O segundo caminho permite que todos os outros diretores acessem esses recursos por meio das políticas principais padrão do IAM para Amazon AWS Glue S3 e ações.
Ao registrar um local do Amazon S3 com o Lake Formation, você tem a opção de aplicar permissões do Lake Formation para todos os recursos desse local ou usar o modo de acesso híbrido. O modo de acesso híbrido impõe somente `CREATE_TABLE`, `CREATE_PARTITION`, `UPDATE_TABLE` permissões por padrão. Quando um local do Amazon S3 está no modo híbrido, você pode habilitar as permissões do Lake Formation optando pelas entidades principais para os objetos do Data Catalog nesse local. Isso significa que tanto as permissões do Lake Formation quanto as permissões do IAM podem controlar o acesso a esses dados. Isso significa que os diretores que optaram por participar exigirão permissões do Lake Formation e do IAM para acessar os dados, enquanto os non-opted-in diretores continuarão acessando os dados usando apenas as permissões do IAM.
Assim, o modo de acesso híbrido oferece a flexibilidade de habilitar seletivamente o Lake Formation para catálogos, bancos de dados e tabelas em seu Data Catalog para um conjunto específico de usuários sem interromper o acesso de outros usuários ou workloads existentes.
![\[Conta da AWS architecture showing data flow between S3, Glue, Lake Formation, Athena, and IAM roles.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/hybrid-access-mode-concept.png)
Para ver as considerações e as limitações, consulte [Considerações e limitações do modo de acesso híbrido](notes-hybrid.md).Termos e definições
Aqui estão as definições dos recursos do catálogo de dados com base em como você configura as permissões de acesso:
Recurso do Lake Formation
Um recurso registrado no Lake Formation. Os usuários precisam de permissões do Lake Formation para acessar o recurso.
AWS Glue recurso
Um recurso registrado no Lake Formation. Os usuários precisam apenas de permissões do IAM para acessar o recurso porque ele tem permissões de grupo `IAMAllowedPrincipals`. As permissões do Lake Formation não são aplicadas.
Para obter mais informações sobre as permissões de grupo `IAMAllowedPrincipals`, consulte [Permissões de metadados](metadata-permissions.md).
Recurso híbrido
Um recurso registrado no modo de acesso híbrido. Com base nos usuários que acessam o recurso, ele alterna dinamicamente entre ser um recurso do Lake Formation ou um recurso do AWS Glue .
## Casos de uso comuns do modo de acesso híbrido
Você pode usar o modo de acesso híbrido para fornecer acesso em cenários de compartilhamento de dados com uma única conta e entre contas:
**Cenários de conta única**
+ **Converter um AWS Glue recurso em um recurso híbrido** — Nesse cenário, você não está usando o Lake Formation no momento, mas deseja adotar as permissões do Lake Formation para objetos do Catálogo de Dados. Ao registrar o local do Amazon S3 no modo de acesso híbrido, você pode conceder permissões do Lake Formation aos usuários que optam por bancos de dados e tabelas específicos que apontam para esse local.
+ **Converter um recurso do Lake Formation em um recurso híbrido**: no momento, você está usando as permissões do Lake Formation para controlar o acesso a um banco de dados do Catálogo de Dados, mas deseja fornecer acesso a novas entidades principais usando permissões do IAM para o Amazon S3 e o AWS Glue sem interromper as permissões existentes do Lake Formation.
Quando você atualiza um registro de localização de dados para o modo de acesso híbrido, novas entidades principais podem acessar o banco de dados do catálogo de dados apontando a localização do Amazon S3 usando políticas de permissões do IAM sem interromper as permissões Lake Formation dos usuários existentes.
Antes de atualizar o registro de localização de dados para ativar o modo de acesso híbrido, você precisa primeiro optar pelas entidades principais que atualmente estão acessando o recurso com as permissões do Lake Formation.
Isso evita possíveis interrupções no fluxo de trabalho atual.
Você também precisa conceder permissão `Super` nas tabelas do banco de dados ao grupo `IAMAllowedPrincipal`.
**Cenários de compartilhamento de dados entre contas**
+ **Compartilhe AWS Glue recursos usando o modo de acesso híbrido** — Nesse cenário, a conta do produtor tem tabelas em um banco de dados que atualmente são compartilhadas com uma conta de consumidor usando políticas de permissões do IAM para Amazon S3 e AWS Glue ações. A localização dos dados do banco de dados não está registrada no Lake Formation.
Antes de registrar a localização dos dados no modo de acesso híbrido, você precisa atualizar as **Configurações da versão entre contas** para a versão 4. A versão 4 fornece as novas políticas de AWS RAM permissão necessárias para o compartilhamento entre contas quando o `IAMAllowedPrincipal` grupo tem `Super` permissão sobre o recurso. Para esses recursos com permissões de grupo `IAMAllowedPrincipal`, você pode conceder permissões do Lake Formation para contas externas e permitir que eles usem as permissões do Lake Formation. O administrador do data lake na conta do destinatário pode conceder permissões do Lake Formation às entidades principais da conta e autorizá-las a aplicar as permissões do Lake Formation.
+ **Compartilhe recursos do Lake Formation usando o modo de acesso híbrido** – Atualmente, a conta de produtor tem tabelas em um banco de dados que são compartilhadas com uma conta de consumidor que impõe as permissões do Lake Formation. A localização dos dados do banco de dados é registrada no Lake Formation.
Nesse caso, você pode atualizar o registro de localização do Amazon S3 para o modo de acesso híbrido e compartilhar os dados do Amazon S3 e os metadados do catálogo de dados usando as políticas de bucket do Amazon S3 e as políticas de recursos do catálogo de dados com as entidades principais na conta do consumidor. Você precisa conceder novamente as permissões existentes do Lake Formation e optar pelas entidades principais antes de atualizar o registro de localização do Amazon S3. Além disso, você precisa conceder permissão `Super` nas tabelas do banco de dados ao grupo `IAMAllowedPrincipals`.
**Topics**
+ [Casos de uso comuns do modo de acesso híbrido](#hybrid-access-mode-use-cases)
+ [Como funciona o modo de acesso híbrido](hybrid-access-workflow.md)
+ [Configurando o modo de acesso híbrido - cenários comuns](hybrid-access-setup.md)
+ [Removendo entidades principais e recursos do modo de acesso híbrido](delete-hybrid-access.md)
+ [Visualizando entidades principais e recursos no modo de acesso híbrido](view-hybrid-access.md)
+ [Recursos adicionais do](additional-resources-hybrid.md)
# Como funciona o modo de acesso híbrido
O diagrama a seguir mostra como a autorização do Lake Formation funciona no modo de acesso híbrido quando você consulta os recursos do catálogo de dados.
![\[AWS Lake Formation authorization process flowchart for hybrid access mode queries.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/hybrid-workflow.png)
Antes de acessar os dados em seu data lake, um administrador de data lake ou um usuário com permissões administrativas configura políticas de usuário individuais da tabela do catálogo de dados para permitir ou negar o acesso às tabelas em seu catálogo de dados. Em seguida, uma entidade principal que tem as permissões para realizar a operação `RegisterResource` registra a localização da tabela no Amazon S3 com o Lake Formation no modo de acesso híbrido. Se um local de dados não estiver registrado no Lake Formation, o administrador vai conceder permissões do Lake Formation a usuários específicos nos bancos de dados e tabelas do Data Catalog e os autorizar a usar as permissões do Lake Formation para esses bancos de dados e tabelas no modo de acesso híbrido.
1. **Envia uma consulta - Um** principal envia uma consulta ou um script de ETL usando um serviço integrado, como Amazon Athena, Amazon EMR ou Amazon Redshift AWS Glue Spectrum.
1. **Solicita dados** - O mecanismo analítico integrado identifica a tabela que está sendo solicitada e envia a solicitação de metadados para o catálogo de dados (`GetTable`, `GetDatabase`).
1. **Verifica as permissões** - O catálogo de dados verifica as permissões de acesso da entidade principal consultora com o Lake Formation.
1. Se a tabela não tiver permissões de grupo `IAMAllowedPrincipals` anexadas, as permissões do Lake Formation serão aplicadas.
1. Se a entidade principal tiver optado por usar as permissões do Lake Formation no modo de acesso híbrido e a tabela tiver permissões do grupo `IAMAllowedPrincipals` anexadas, as permissões do Lake Formation serão aplicadas. O mecanismo de consulta aplica os filtros recebidos do Lake Formation e retorna os dados ao usuário.
1. Se a localização da tabela não estiver registrada no Lake Formation e a entidade principal não tiver optado por usar as permissões do Lake Formation no modo de acesso híbrido, o catálogo de dados verificará se a tabela tem permissões do grupo `IAMAllowedPrincipals` anexadas a ela. Se essa permissão existir na tabela, todas as entidades principais da conta receberão permissões `Super` ou `All` na tabela.
A venda de credenciais do Lake Formation não está disponível, mesmo quando aceita, a menos que o local dos dados esteja registrado no Lake Formation.
1. **Obter credenciais** – O catálogo de dados verifica e informa ao mecanismo se a localização da tabela está registrada no Lake Formation ou não. Se os dados subjacentes estiverem registrados no Lake Formation, o mecanismo analítico solicitará ao Lake Formation credenciais temporárias para acessar os dados no bucket do Amazon S3.
1. **Obter dados** – Se a entidade principal estiver autorizada a acessar os dados da tabela, o Lake Formation fornecerá acesso temporário ao mecanismo analítico integrado. Ao usar o acesso temporário, o mecanismo analítico busca os dados do Amazon S3 e executa a filtragem necessária, como filtragem por coluna, linha ou célula. Quando o mecanismo termina de executar o trabalho, ele retorna os resultados para o usuário. Esse processo chamado de fornecimento de credenciais. Para obter mais informações, consulte [Integração de serviços de terceiros com o Lake Formation](Integrating-with-LakeFormation.md).
1.
Se a localização dos dados da tabela não estiver registrada no Lake Formation, a segunda chamada do mecanismo analítico será feita diretamente para o Amazon S3. A política de bucket do Amazon S3 e a política de usuário do IAM em questão são avaliadas para acesso aos dados. Sempre que você usar as políticas do IAM, siga as práticas recomendadas do IAM. Para obter mais informações, consulte [Práticas recomendadas de segurança no IAM no Guia do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html).
# Configurando o modo de acesso híbrido - cenários comuns
Assim como nas permissões do Lake Formation, você geralmente tem dois tipos de cenários nos quais pode usar o modo de acesso híbrido para gerenciar o acesso aos dados: fornecer acesso aos principais dentro de um Conta da AWS e fornecer acesso a um externo Conta da AWS ou principal.
Esta seção fornece instruções para configurar o modo de acesso híbrido nos seguintes cenários:
**Gerencie permissões no modo de acesso híbrido em um Conta da AWS**
+ [Convertendo um AWS Glue recurso em um recurso híbrido](hybrid-access-mode-new.md)— No momento, você está fornecendo acesso às tabelas em um banco de dados para todos os diretores da sua conta usando as permissões do IAM para o Amazon S3 AWS Glue , mas deseja adotar o Lake Formation para gerenciar as permissões de forma incremental.
+ [Convertendo um recurso do Lake Formation em um recurso híbrido](hybrid-access-mode-update.md): no momento, você está usando o Lake Formation para gerenciar o acesso às tabelas em um banco de dados para todas as entidades principais da sua conta, mas deseja usar o Lake Formation somente para entidades principais específicas. Você deseja fornecer acesso a novos diretores usando as permissões do IAM para o Amazon S3 no mesmo banco de dados AWS Glue e tabelas.
**Gerencie permissões no modo de acesso híbrido entre Conta da AWS s**
+ [Compartilhamento de um AWS Glue recurso usando o modo de acesso híbrido](hybrid-access-mode-cross-account.md): no momento, você não está usando o Lake Formation para gerenciar as permissões de uma tabela, mas deseja aplicar as permissões do Lake Formation para fornecer acesso às entidades principais em outra conta.
+ [Compartilhando um recurso do Lake Formation usando o modo de acesso híbrido](hybrid-access-mode-cross-account-IAM.md)— Você está usando o Lake Formation para gerenciar o acesso a uma tabela, mas deseja fornecer acesso para diretores em outra conta usando permissões do IAM para o Amazon S3 no mesmo banco de dados AWS Glue e tabelas.
**Configurando o modo de acesso híbrido – Etapas de alto nível**
1. Registre a localização dos dados do Amazon S3 com o Lake Formation selecionando o **Modo de acesso híbrido**.
1. As entidades principais devem ter permissão `DATA_LOCATION` em um local de data lake para criar tabelas ou bancos de dados do catálogo de dados que apontem para esse local.
1. Defina a **Configuração da versão entre contas** para a versão 4.
1. Conceda permissões refinadas a usuários ou perfis específicos do IAM em bancos de dados e tabelas. Ao mesmo tempo, certifique-se de definir permissões `Super` ou `All` para o grupo `IAMAllowedPrincipals` no banco de dados e para todas ou para as tabelas selecionadas no banco de dados.
1. Opte pelas entidades principais e recursos. Outros diretores da conta podem continuar acessando os bancos de dados e tabelas usando as políticas de permissão do IAM AWS Glue e as ações do Amazon S3.
1. Opcionalmente, limpe as políticas de permissão do IAM para o Amazon S3 para as entidades principais que optaram por usar as permissões do Lake Formation.
# Pré-requisitos para configurar o modo de acesso híbrido
Estes estão os pré-requisitos para configurar o modo de acesso híbrido:
**nota**
Recomendamos que um administrador do Lake Formation registre a localização do Amazon S3 no modo de acesso híbrido e opte por entidades principais e recursos.
1. Conceda permissão de localização de dados (`DATA_LOCATION_ACCESS`) para criar recursos do catálogo de dados que apontem para os locais do Amazon S3. As permissões de localização de dados controlam a capacidade de criar catálogos, bancos de dados e tabelas do Data Catalog que apontam para os locais específicos do Amazon S3.
1. Para compartilhar recursos do Catálogo de Dados com outra conta no modo de acesso híbrido (sem remover as permissões de `IAMAllowedPrincipals` grupo do recurso), você precisa atualizar **as configurações da versão da conta cruzada** para a versão 4 ou superior. Para atualizar a versão usando o console do Lake Formation, escolha **Versão 4** ou **Versão 5** em **Configurações de versão entre contas** na página de **configurações do Catálogo de Dados**.
Você também pode usar o `put-data-lake-settings` AWS CLI comando para definir o `CROSS_ACCOUNT_VERSION` parâmetro para a versão 4 ou 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 permissões entre contas no modo de acesso híbrido, o concedente deve ter as permissões necessárias do IAM e os AWS Glue serviços. AWS RAM A política AWS gerenciada `AWSLakeFormationCrossAccountManager` concede as permissões necessárias.
Para permitir o compartilhamento de dados entre contas no modo de acesso híbrido, atualizamos a política gerenciada `AWSLakeFormationCrossAccountManager` adicionando duas novas permissões do IAM:
+ RAM: ListResourceSharePermissions
+ RAM: AssociateResourceSharePermission
**nota**
Se você não estiver usando a política AWS gerenciada para a função de concedente, adicione as políticas acima às suas políticas personalizadas.
## Localização do bucket do Amazon S3 e acesso do usuário
Ao criar um catálogo, banco de dados ou tabela no AWS Glue Data Catalog, você pode especificar a localização dos dados subjacentes no bucket do Amazon S3 e registrá-los no Lake Formation. As tabelas abaixo descrevem como as permissões funcionam para usuários (diretores) AWS Glue e usuários do Lake Formation com base na localização dos dados da tabela ou do banco de dados no Amazon S3.
**Localização do Amazon S3 registrada no Lake Formation**
| Localização de um banco de dados no Amazon S3 | AWS Glue usuários | Usuários do Lake Formation |
| --- | --- | --- |
| Registrados no Lake Formation (no modo de acesso híbrido ou no modo do Lake Formation) | Tenha read/write acesso à localização de dados do Amazon S3 herdando permissões do grupo IAMAllowed Principals (superacesso). | Herde as permissões para criar tabelas usando a permissão CREATE TABLE concedida. |
| Nenhuma localização do Amazon S3 associada | Permissão DATA LOCATION explícita necessária para executar as instruções CREATE TABLE e INSERT TABLE. | Permissão DATA LOCATION explícita necessária para executar as instruções CREATE TABLE e INSERT TABLE. |
****IsRegisteredWithLakeFormation**propriedade da tabela**
A propriedade `IsRegisteredWithLakeFormation` de uma tabela indica se a localização dos dados da tabela está registrada no Lake Formation para o solicitante. Se o modo de permissão da localização estiver registrado como Lake Formation, a propriedade `IsRegisteredWithLakeFormation` será `true` para todos os usuários que acessam a localização dos dados, pois considera-se que todos os usuários optaram por essa tabela. Se a localização estiver registrada no modo de acesso híbrido, o valor será definido como `true` somente para usuários que optaram por essa tabela.
**Como a `IsRegisteredWithLakeFormation` funciona**
| Modo de permissão | Usuários/perfis | `IsRegisteredWithLakeFormation` | Description |
| --- | --- | --- | --- |
| Lake Formation | Todos | Verdadeiro | Quando uma localização for registrada no Lake Formation, a propriedade `IsRegisteredWithLakeFormation` será definida como verdadeira para todos os usuários. Isso significa que as permissões definidas no Lake Formation se aplicam à localização registrada. O fornecimento de credenciais será feito pelo Lake Formation. |
| Modo de acesso híbrido | Optou por usar | Verdadeiro | Com relação aos usuários que optaram por usar o Lake Formation para acesso aos dados e governança de uma tabela, a propriedade `IsRegisteredWithLakeFormation` será definida como `true` para essa tabela. Eles estão sujeitos às políticas de permissão definidas no Lake Formation referentes à localização registrada. |
| Modo de acesso híbrido | Optou por não usar | Falso | Quanto aos usuários que optaram por não usar as permissões do Lake Formation, a propriedade `IsRegisteredWithLakeFormation` é definida como `false`. Eles não estão sujeitos às políticas de permissão definidas no Lake Formation referentes à localização registrada. Em vez disso, os usuários seguirão as políticas de permissões do Amazon S3. |
# Convertendo um AWS Glue recurso em um recurso híbrido
Siga estas etapas para registrar uma localização do Amazon S3 no modo de acesso híbrido e integrar novos usuários do Lake Formation sem interromper o acesso aos dados dos usuários existentes do catálogo de dados.
Descrição do cenário - O local dos dados não está registrado no Lake Formation, e o acesso dos usuários ao banco de dados e às tabelas do catálogo de dados é determinado pelas políticas de permissões do IAM para o Amazon S3 e ações do AWS Glue .
Por padrão, o grupo `IAMAllowedPrincipals` tem permissões `Super` em todas as tabelas do banco de dados.
**Para ativar o modo de acesso híbrido para um local de dados que não está registrado no Lake Formation**
1.
**Registre um local do Amazon S3 para ativar o modo de acesso híbrido.**
------
#### [ Console ]
1. Faça login no [console do Lake Formation](https://console.aws.amazon.com/lakeformation/) como administrador do data lake.
1. No painel de navegação, escolha **Localizações do data lake** em **Administração**.
1. Escolha **Registrar localizações**.
![\[Register location form for Amazon S3 data lake with path input, IAM role selection, and permission mode options.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/hybrid-access-register-s3.png)
1. Na janela **Registrar localização**, escolha o caminho do **Amazon S3** que você deseja registrar no Lake Formation.
1. Para o **perfil do IAM**, escolha a função `AWSServiceRoleForLakeFormationDataAccess` vinculada ao serviço (a padrão) ou um perfil personalizado do IAM que atenda aos requisitos em [Requisitos para funções usadas para registrar locais](registration-role.md).
1. Escolha o **Modo de acesso híbrido** para aplicar políticas refinadas de controle de acesso do Lake Formation às entidades principais e bancos de dados e tabelas do catálogo de dados que apontam para a localização registrada.
Escolha Lake Formation para permitir que o Lake Formation autorize solicitações de acesso ao local registrado.
1. Escolha **Registrar local**.
------
#### [ AWS CLI ]
Veja a seguir um exemplo para registrar um local de dados no Lake Formation HybridAccessEnabled com:true/false. O valor padrão do parâmetro `HybridAccessEnabled` é falso. Substitua o caminho, o nome da função e o ID da AWS conta do 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 permissões e opte pelas entidades principais para usar as permissões do Lake Formation para recursos no modo de acesso híbrido**
Antes de aceitar entidades principais e recursos no modo de acesso híbrido, verifique se existem permissões `Super` ou `All` para o grupo `IAMAllowedPrincipals` nos bancos de dados e tabelas que têm localização registrada no Lake Formation no modo de acesso híbrido.
**nota**
Você não pode conceder ao grupo `IAMAllowedPrincipals` permissão para `All tables` em um banco de dados. Você precisa selecionar cada tabela separadamente no menu suspenso e conceder permissões. Além disso, ao criar tabelas no banco de dados, você pode optar por usar `Use only IAM access control for new tables in new databases` em **Configurações do Catálogo de Dados**. Essa opção concede permissão `Super` ao grupo `IAMAllowedPrincipals` automaticamente quando você cria novas tabelas no banco de dados.
------
#### [ Console ]
1. No console do Lake Formation, em **Data Catalog**, escolha **Catálogos**, **Bancos de dados** ou **Tabelas**.
1. Selecione um catálogo, um banco de dados ou uma tabela na lista e escolha **Conceder** no menu **Ações**.
1. Escolha entidades principais para conceder permissões no banco de dados, tabelas e colunas usando o método de recurso nomeado ou tags do LF.
Como alternativa, escolha **Permissões de dados**, selecione as entidades principais para conceder permissões na lista e escolha **Conceder**.
Para obter mais detalhes sobre a concessão de permissões de dados, consulte [Conceder permissões nos recursos do Catálogo de Dados](granting-catalog-permissions.md).
**nota**
Se você estiver concedendo a permissão Criar tabela a uma entidade principal, também precisará conceder permissões de localização de dados (`DATA_LOCATION_ACCESS`) à entidade principal. Essa permissão não é necessária para atualizar tabelas.
Para obter mais informações, consulte [Conceder permissões de localização de dados](granting-location-permissions.md).
1. Quando você usa o **Método de recurso nomeado** para conceder permissões, a opção de optar por entidades principais e recursos está disponível na seção inferior da página **Conceder permissão de dados**.
Escolha **Tornar as permissões do Lake Formation efetivas imediatamente** para habilitar as permissões do Lake Formation para as entidades principais e recursos.
![\[A opção de escolher o modo de acesso híbrido para o recurso do Data Catalog.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/hybrid-access-grant-option.png)
1. Selecione **Conceder**.
Quando você opta pela entidade principal A na tabela A que está apontando para um local de dados, ela permite que a entidade principal A tenha acesso ao local dessa tabela usando as permissões do Lake Formation se o local dos dados estiver registrado no modo híbrido.
------
#### [ AWS CLI ]
A seguir está um exemplo de como optar por uma entidade principal e uma tabela no modo de acesso híbrido. Substitua o nome da função, o ID da conta da AWS , o nome do banco de dados e o nome da tabela por valores válidos.
```
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. Se você escolher tags do LF para conceder permissões, você pode optar por entidades principais para usar as permissões do Lake Formation em uma etapa separada. Você pode fazer isso escolhendo o **Modo de acesso híbrido** em **Permissões** na barra de navegação esquerda.
1. Na seção inferior da página do **Modo de acesso híbrido**, escolha **Adicionar para adicionar** recursos e entidades principais ao modo de acesso híbrido.
1. Na página **Adicionar recursos e entidades principais**, escolha os catálogos, os bancos de dados e as tabelas registrados no modo de acesso híbrido.
Você pode escolher `All tables` em um banco de dados para conceder acesso.
![\[A interface para adicionar catálogos, bancos de dados e tabelas no modo de acesso híbrido.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/hybrid-access-opt-in.png)
1. Escolha entidades principais para aceitarem o uso das permissões do Lake Formation no modo de acesso híbrido.
+ **Entidade principais**: é possível escolher usuários e perfis do IAM na mesma conta ou em outra conta. Você também pode escolher usuários e grupos SAML.
+ **Atributos**: selecione atributos para conceder permissões com base em atributos.
![\[A interface para adicionar entidades principais e recursos com uma expressão de atributo.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/abac-hybrid-access.png)
+ Insira o par de chave-valor para criar uma concessão com base em atributos. Analise a expressão da política Cedar no console. Para acessar mais informações sobre Cedar, consulte [O que é Cedar? \$1 Referência GuideLink de linguagem da Cedar Policy](https://docs.cedarpolicy.com/).
+ Escolha **Adicionar**.
Todos os IAM roles/users com atributos correspondentes recebem acesso.
1. Escolha **Adicionar**.
# Convertendo um recurso do Lake Formation em um recurso híbrido
Nos casos em que você está usando atualmente as permissões do Lake Formation para seus bancos de dados e tabelas do catálogo de dados, você pode editar as propriedades de registro de localização para ativar o modo de acesso híbrido. Isso permite que você forneça aos novos diretores acesso aos mesmos recursos usando políticas de permissão do IAM para o Amazon S3 AWS Glue e ações sem interromper as permissões existentes do Lake Formation.
Descrição do cenário - As etapas a seguir pressupõem que você tenha um local de dados registrado no Lake Formation e tenha configurado permissões para entidades principais em bancos de dados, tabelas ou colunas que apontam para esse local. Se o local foi registrado com uma função vinculada ao serviço, você não poderá atualizar os parâmetros de localização e ativar o modo de acesso híbrido. Por padrão, o grupo `IAMAllowedPrincipals` tem permissões Super no banco de dados e em todas as respectivas tabelas.
**Importante**
Não atualize um registro de localização para o modo de acesso híbrido sem optar pelas entidades principais que estão acessando os dados nesse local.
**Ativando o modo de acesso híbrido para um local de dados registrado no Lake Formation**
1.
**Atenção**
Não recomendamos converter uma localização de dados gerenciada do Lake Formation no modo de acesso híbrido para evitar a interrupção das políticas de permissões de outros usuários ou workloads existentes.
Opte pelas entidades principais existentes que tenham permissões do Lake Formation.
1. Liste e analise as permissões que você concedeu às entidades principais em catálogos, bancos de dados e tabelas. Para obter mais informações, consulte [Visualizar permissões de banco de dados e tabelas no Lake Formation](viewing-permissions.md).
1. Escolha o **Modo de acesso híbrido** em **Permissões** na barra de navegação esquerda e escolha **Adicionar**.
1. Na página **Adicionar entidades principais e recursos**, escolha os catálogos, os bancos de dados e as tabelas do local de dados do Amazon S3 que você deseja usar no modo de acesso híbrido. Escolha as entidades principais que já possuem permissões do Lake Formation.
1. Escolha **Adicionar** para ativar as entidades principais para usar as permissões do Lake Formation no modo de acesso híbrido.
1. Atualize o bucket/prefix registro do Amazon S3 escolhendo a opção de **modo de acesso híbrido**.
------
#### [ Console ]
1. Faça login no console do Lake Formation como administrador do data lake.
1. No painel de navegação, em **Registrar e ingerir**, escolha **Locais do data lake**.
1. Selecione um local e, no menu **Ações**, escolha **Editar**.
1. Escolha o **Modo de acesso híbrido**.
1. Escolha **Salvar**.
1. Em catálogo de dados, selecione o banco de dados ou a tabela e conceda permissões `Super` ou `All` para o grupo virtual chamado `IAMAllowedPrincipals`.
1. Verifique se o acesso dos usuários existentes do Lake Formation não foi interrompido quando você atualizou as propriedades de registro de localização. Faça login no console do Athena como entidade principal do Lake Formation e execute um exemplo de consulta em uma tabela que está apontando para o local atualizado.
Da mesma forma, verifique o acesso dos AWS Glue usuários que estão usando as políticas de permissões do IAM para acessar o banco de dados e as tabelas.
------
#### [ AWS CLI ]
Veja a seguir um exemplo para registrar um local de dados no Lake Formation HybridAccessEnabled com:true/false. O valor padrão do parâmetro `HybridAccessEnabled` é falso. Substitua o caminho, o nome da função e o ID da AWS conta do 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
}
```
------
# Compartilhamento de um AWS Glue recurso usando o modo de acesso híbrido
Compartilhe dados com outra pessoa Conta da AWS ou com um diretor de outra pessoa Conta da AWS aplicando as permissões do Lake Formation sem interromper o acesso baseado em IAM dos usuários existentes do Catálogo de Dados.
Descrição do cenário - A conta do produtor tem um banco de dados do catálogo de dados que tem acesso controlado usando as principais políticas do IAM para Amazon S3 e AWS Glue ações. A localização dos dados do banco de dados não está registrada no Lake Formation. Por padrão, o grupo `IAMAllowedPrincipals` tem permissões `Super` no banco de dados e em todas as respectivas tabelas.
**Conceder permissões entre contas do Lake Formation no modo de acesso híbrido**
1.
**Configuração da conta de produtor**
1. Faça login no console do Lake Formation usando uma função que tenha permissão do IAM `lakeformation:PutDataLakeSettings`.
1. Acesse as **Configurações do catálogo de dados** e escolha `Version 4` para as **Configurações da versão entre contas**.
Se você estiver usando a versão 1 ou 2, consulte as instruções [Como atualizar as configurações da versão de compartilhamento de dados entre contas](optimize-ram.md) sobre como atualizar para a versão 3.
Não são necessárias alterações na política de permissão ao atualizar da versão 3 para a 4.
1. Registre a localização do Amazon S3 do banco de dados ou tabela que você planeja compartilhar no modo de acesso híbrido.
1. Verifique se a permissão `Super` para o grupo `IAMAllowedPrincipals` existe nos bancos de dados e tabelas nos quais você registrou a localização dos dados no modo de acesso híbrido na etapa acima.
1. Conceda permissões do Lake Formation para AWS organizações, unidades organizacionais (OUs) ou diretamente com um diretor do IAM em outra conta.
1. Se você estiver concedendo permissões diretamente a uma entidade principal do IAM, opte pela entidade principal da conta de consumidor para aplicar as permissões do Lake Formation no modo de acesso híbrido, ativando a opção **Tornar as permissões do Lake Formation efetivas imediatamente**.
Se você estiver concedendo permissões entre contas para outra AWS conta, ao optar pela conta, as permissões do Lake Formation serão aplicadas somente para os administradores dessa conta. O administrador do data lake da conta do destinatário precisa reduzir as permissões em cascata e optar pelas entidades principais da conta para aplicar as permissões do Lake Formation aos recursos compartilhados que estão no modo de acesso híbrido.
Se você escolher a opção **Recursos correspondidos por tags do LF** para conceder permissões entre contas, você precisa primeiro concluir a etapa de concessão de permissões. Você pode optar por incluir entidades principais e recursos no modo de acesso híbrido como uma etapa separada, escolhendo o **Modo de acesso híbrido** em Permissões na barra de navegação esquerda do console do Lake Formation. Em seguida, escolha **Adicionar** para adicionar os recursos e as entidades principais aos quais você deseja aplicar as permissões do Lake Formation.
1.
**Configuração de conta de consumidor**
1. Faça login no console do Lake Formation [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)como administrador do data lake.
1. Vá para [https://console.aws.amazon.com/ram/casa](https://console.aws.amazon.com/ram/home) e aceite o convite de compartilhamento de recursos. A guia **Compartilhado comigo** no AWS RAM console exibe o banco de dados e as tabelas compartilhadas com sua conta.
1. Crie um link de recurso para a and/or tabela do banco de dados compartilhado no Lake Formation.
1. Conceda a permissão `Describe` no link do recurso e a permissão `Grant on target` (no recurso compartilhado original) às entidades principais do IAM em sua conta (de consumidor).
1. Conceda permissões do Lake Formation no banco de dados ou na tabela compartilhada com você às entidades principais da sua conta. Opte pelas entidades principais e recursos para aplicar as permissões do Lake Formation no modo de acesso híbrido, ativando a opção **Tornar as permissões do Lake Formation efetivas imediatamente**.
1. Teste as permissões da entidade principal do Lake Formation executando exemplos de consultas do Athena. Teste o acesso existente de seus AWS Glue usuários com as principais políticas do IAM para Amazon S3 e AWS Glue ações.
(Opcional) Remova a política de bucket do Amazon S3 para acesso a dados e políticas de entidades principais do IAM para AWS Glue e acesso a dados do Amazon S3 para as entidades principais que você configurou para usar permissões do Lake Formation.
# Compartilhando um recurso do Lake Formation usando o modo de acesso híbrido
Permita que novos usuários do catálogo de dados em uma conta externa acessem bancos de dados e tabelas do catálogo de dados usando políticas baseadas no IAM sem interromper as permissões de compartilhamento entre contas existentes do Lake Formation.
Descrição do cenário - A conta de produtor tem banco de dados e tabelas gerenciados pelo Lake Formation que são compartilhados com uma conta externa (consumidor) no nível da conta ou no nível de entidade principal do IAM. A localização dos dados do banco de dados é registrada no Lake Formation. O grupo `IAMAllowedPrincipals` não tem permissões `Super` no banco de dados e em suas tabelas.
**Conceder acesso entre contas a novos usuários do catálogo de dados por meio de políticas baseadas em IAM sem interromper as permissões existentes do Lake Formation**
1.
**Configuração da conta de produtor**
1. Faça login no console do Lake Formation usando uma função que `lakeformation:PutDataLakeSettings`.
1. Em **Configurações do catálogo de dados**, escolha `Version 4` para as **Configurações da versão entre contas**.
Se você estiver usando a versão 1 ou 2, consulte as instruções [Como atualizar as configurações da versão de compartilhamento de dados entre contas](optimize-ram.md) sobre como atualizar para a versão 3.
Não são necessárias alterações na política de permissão para atualizar da versão 3 para a 4.
1. Liste as permissões que você concedeu às entidades principais em bancos de dados e tabelas. Para obter mais informações, consulte [Visualizar permissões de banco de dados e tabelas no Lake Formation](viewing-permissions.md).
1. Conceda novamente as permissões existentes entre contas do Lake Formation optando por entidades principais e recursos.
**nota**
Antes de atualizar um registro de localização de dados para o modo de acesso híbrido para conceder permissões entre contas, você precisa conceder novamente pelo menos um compartilhamento de dados entre contas por conta. Essa etapa é necessária para atualizar as permissões AWS RAM gerenciadas anexadas ao compartilhamento AWS RAM de recursos.
Em julho de 2023, o Lake Formation atualizou as permissões AWS RAM gerenciadas usadas para compartilhar bancos de dados e tabelas:
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueAllTablesReadWriteForDatabase` (política de compartilhamento em nível de banco de dados)
`arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueTableReadWrite` (política de compartilhamento em nível de tabela)
As concessões de permissão entre contas feitas antes de julho de 2023 não têm essas AWS RAM permissões atualizadas.
Se você concedeu permissões entre contas diretamente às entidades principais, precisará devolvê-las individualmente às entidades principais. Se você pular essa etapa, as entidades principais que acessam o recurso compartilhado podem receber um erro de combinação ilegal.
1. Vá para [https://console.aws.amazon.com/ram/casa](https://console.aws.amazon.com/ram/home).
1. A guia **Compartilhado por mim** no AWS RAM console exibe os nomes do banco de dados e da tabela que você compartilhou com uma conta externa ou principal.
Certifique-se de que as permissões anexadas ao recurso compartilhado tenham o ARN correto.
1. Verifique se os recursos no AWS RAM compartilhamento estão no `Associated` status. Se o status for exibido como `Associating`, espere até que eles entrem no status `Associated`. Se o status for `Failed`, pare e entre em contato com a equipe de serviço do Lake Formation.
1. Escolha o **Modo de acesso híbrido** em **Permissões** na barra de navegação esquerda e escolha **Adicionar**.
1. A página **Adicionar diretores e recursos** mostra os bancos de dados, and/or as tabelas e os principais que têm acesso. Você pode fazer as atualizações necessárias adicionando ou removendo entidades principais e recursos.
1. Escolha as entidades principais com permissões do Lake Formation para o banco de dados e as tabelas que você deseja alterar para o modo de acesso híbrido. Escolha os bancos de dados e tabelas.
1. Escolha **Adicionar** para optar pelas entidades principais para aplicar as permissões do Lake Formation no modo de acesso híbrido.
1. Conceda a permissão `Super` ao grupo virtual `IAMAllowedPrincipals` em seu banco de dados e nas tabelas selecionadas.
1. Edite o registro Lake Formation da localização do Amazon S3 para o modo de acesso híbrido.
1. Conceda permissões para os AWS Glue usuários na conta externa (consumidor) usando políticas de permissão do IAM para ações do Amazon S3 AWS Glue .
1.
**Configuração de conta de consumidor**
1. Faça login no console do Lake Formation [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)como administrador do data lake.
1. Vá para [https://console.aws.amazon.com/ram/casa](https://console.aws.amazon.com/ram/home) e aceite o convite de compartilhamento de recursos. A guia **Recursos compartilhados comigo** na AWS RAM página exibe os nomes do banco de dados e das tabelas que são compartilhados com sua conta.
Para o AWS RAM compartilhamento, certifique-se de que a permissão anexada tenha o ARN correto do convite compartilhado AWS RAM . Verifique se os recursos no AWS RAM compartilhamento estão no `Associated` status. Se o status for exibido como `Associating`, espere até que eles entrem no status `Associated`. Se o status for `Failed`, pare e entre em contato com a equipe de serviço do Lake Formation.
1. Crie um link de recurso para a and/or tabela do banco de dados compartilhado no Lake Formation.
1. Conceda a permissão `Describe` no link do recurso e a permissão `Grant on target` (no recurso compartilhado original) às entidades principais do IAM em sua conta (de consumidor).
1. Em seguida, configure as permissões do Lake Formation para as entidades principais da sua conta no banco de dados ou na tabela compartilhada.
Na barra de navegação esquerda, em **Permissões**, escolha **Modo de acesso híbrido**.
1. Escolha **Adicionar** na seção inferior da página do **Modo de acesso híbrido** para optar pelas entidades principais e pelo banco de dados ou tabela compartilhados com você na conta de produtor.
1. Conceda permissões para os AWS Glue usuários em sua conta usando políticas de permissão do IAM para ações do Amazon S3 AWS Glue .
1. Teste as permissões e AWS Glue permissões do Lake Formation dos usuários executando exemplos de consultas separadas na tabela usando o Athena
(Opcional) Limpe as políticas de permissão do IAM para o Amazon S3 para as entidades principais que estão no modo de acesso híbrido.
# Removendo entidades principais e recursos do modo de acesso híbrido
Siga estas etapas para remover bancos de dados, tabelas e entidades principais do modo de acesso híbrido.
------
#### [ Console ]
1. Faça login no console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Em **Permissões**, escolha o **Modo de acesso híbrido**.
1. Na página do **Modo de acesso híbrido**, marque a caixa de seleção ao lado do nome do banco de dados ou da tabela e escolha `Remove`.
1. Uma mensagem de aviso solicita que você confirme a ação. Escolha **Remover **.
O Lake Formation não impõe mais permissões para esses recursos, e o acesso a esse recurso será controlado usando IAM e AWS Glue permissões. Isso pode fazer com que o usuário não tenha mais acesso a esse recurso se não tiver as permissões apropriadas do IAM.
------
#### [ AWS CLI ]
O exemplo a seguir mostra como remover um recurso do modo de acesso 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": ""
}
}
}
```
------
# Visualizando entidades principais e recursos no modo de acesso híbrido
Siga estas etapas para visualizar bancos de dados, tabelas e entidades principais no modo de acesso híbrido.
------
#### [ Console ]
1. Faça login no console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Em **Permissões**, escolha o **Modo de acesso híbrido**.
1. A página do **Modo de acesso híbrido** mostra os recursos e entidades principais que estão atualmente no modo de acesso híbrido.
------
#### [ AWS CLI ]
O exemplo a seguir mostra como listar todas as entidades principais e recursos opcionais que estão no modo de acesso híbrido.
```
aws lakeformation list-lake-formation-opt-ins
```
O exemplo a seguir mostra como listar o opt-in para um par específico de entidade principal e 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 adicionais do
Na postagem do blog a seguir, mostraremos as instruções para integrar as permissões do Lake Formation no modo de acesso híbrido para usuários selecionados, enquanto o banco de dados já está acessível a outros usuários por meio das permissões do IAM e do Amazon S3. Analisaremos as instruções para configurar o modo de acesso híbrido em uma AWS conta e entre duas contas.
+ [Apresentando o modo de acesso híbrido AWS Glue Data Catalog para proteger o acesso usando as políticas do Lake Formation e do IAM e do 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/)
# Criação de objetos no AWS Glue Data Catalog
AWS Lake Formation usa o AWS Glue Data Catalog (Catálogo de dados) para armazenar metadados sobre lagos de dados, fontes de dados, transformações e destinos. Metadados são dados sobre os dados subjacentes em seu conjunto de dados. Cada AWS conta tem um catálogo de dados por AWS região.
Os metadados no Data Catalog são organizados em uma hierarquia de dados de três níveis que inclui catálogos, bancos de dados e tabelas. Ele organiza dados de várias fontes em contêineres lógicos chamados catálogos. Cada catálogo representa dados de fontes, como data warehouses do Amazon Redshift, bancos de dados do Amazon DynamoDB e fontes de dados de terceiros, como Snowflake, MySQL, e mais de trinta fontes de dados externas, que são integradas por meio de conectores federados. Você também pode criar catálogos no Data Catalog para armazenar dados em buckets de Tabelas do S3 ou no Redshift Managed Storage (RMS).
As tabelas armazenam informações sobre os dados subjacentes, incluindo informações de esquema, informações de partição e localização dos dados. Bancos de dados são coleções de tabelas. O Data Catalog também contém links de recursos, que são links para catálogos, bancos de dados e tabelas compartilhados em contas externas e são usados para acesso entre contas aos dados no data lake.
O Data Catalog é um objeto de catálogo aninhado que contém catálogos, bancos de dados e tabelas. Ele é referenciado pelo Conta da AWS ID e é o catálogo padrão em uma conta e em uma Região da AWS. O Data Catalog usa uma hierarquia de três níveis (catalog.database.table) para organizar tabelas.
+ Catálogo: o nível mais alto da hierarquia de metadados de três níveis do Data Catalog. Você pode adicionar vários catálogos no Data Catalog por meio da federação.
+ Banco de dados: o segundo nível da hierarquia de metadados, composto por tabelas e visualizações. Um banco de dados também é chamado de esquema em muitos sistemas de dados, como Amazon Redshift e Trino.
+ Tabela e visualização: o terceiro nível da hierarquia de dados de três níveis do Data Catalog.
Todas as tabelas Iceberg no Amazon S3 são armazenadas no catálogo de dados padrão com ID do catálogo = ID Conta da AWS . Você pode criar catálogos federados para armazenar definições de tabelas no AWS Glue Data Catalog Amazon Redshift, no armazenamento de tabelas do Amazon S3 ou em outras fontes de dados de terceiros por meio da federação.
**Topics**
+ [Criar um catálogo](creating-catalog.md)
+ [Criação de um banco de dados](creating-database.md)
+ [Criar tabelas](creating-tables.md)
+ [AWS Glue Data Catalog Vistas do edifício](working-with-views.md)
# Criar um catálogo
Os catálogos representam o nível mais alto ou mais alto na hierarquia de metadados de três níveis do AWS Glue Data Catalog. Você pode usar vários métodos para trazer dados para o Data Catalog e criar catálogos de vários níveis.
Para acessar mais informações sobre a criação de catálogos por meio de fontes de dados externas, consulte [Trazendo seus dados para o AWS Glue Data Catalog](bring-your-data-overview.md).
Para criar um catálogo usando o console do Lake Formation, você deve estar conectado como administrador do data lake ou *criador do catálogo*. Um criador de catálogo é uma entidade principal que recebeu a permissão `CREATE_CATALOG` do Lake Formation. Você pode ver uma lista de criadores de catálogos na página **Perfis e tarefas administrativas** do console do Lake Formation. Para ver essa lista, você precisa ter a permissão `lakeformation:ListPermissions` do IAM e estar conectado como administrador do data lake ou como criador de catálogos com a opção de concessão na permissão `CREATE_CATALOG`.
# Criação de um banco de dados
As tabelas de metadados no catálogo de dados são armazenadas nos bancos de dados. Você pode criar quantos bancos de dados precisar e conceder permissões diferentes do Lake Formation em cada banco de dados.
Os bancos de dados podem ter uma propriedade de localização opcional. Esse local geralmente está dentro de um local do Amazon Simple Storage Service (Amazon S3) registrado no Lake Formation. Quando você especifica um local, as entidades principais não precisam de permissões de localização de dados para criar tabelas do catálogo de dados que apontem para locais dentro do local do banco de dados. Para obter mais informações, consulte [Underlying data access control](access-control-underlying-data.md#data-location-permissions).
Para criar um banco de dados usando o console do Lake Formation, você deve estar conectado como administrador do data lake ou *criador do banco de dados*. Um criador de banco de dados é uma entidade principal que recebeu a permissão `CREATE_DATABASE` do Lake Formation. Você pode ver uma lista de criadores de banco de dados na página **Funções e tarefas administrativas** do console do Lake Formation. Para ver essa lista, você precisa ter a permissão `lakeformation:ListPermissions` do IAM e estar conectado como administrador do data lake ou como criador de banco de dados com a opção de concessão na permissão `CREATE_DATABASE`.
**Para criar um banco de dados**
1. Abra o AWS Lake Formation console em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)e faça login como administrador do data lake ou criador do banco de dados.
1. No painel de navegação, em **catálogo de dados**, escolha **Bancos de dados**.
1. Selecione **Criar banco de dados**.
1. Na caixa de diálogo **Criar banco de dados**, insira o nome do banco de dados, a localização opcional e a descrição opcional.
1. Opcionalmente, selecione **Usar somente controle de acesso do IAM para novas tabelas nesse banco de dados**.
Para obter mais informações sobre esta opção, consulte [Alterando as configurações padrão do seu data lake](change-settings.md).
1. Selecione **Criar banco de dados**.
# Criar tabelas
AWS Lake Formation as tabelas de metadados contêm informações sobre dados no data lake, incluindo informações de esquema, informações de partição e localização dos dados. Essas tabelas são armazenadas no catálogo de dados do AWS Glue. Você os usa para acessar dados subjacentes no data lake e gerenciar esses dados com as permissões do Lake Formation. As tabelas são armazenadas nos bancos de dados no catálogo de dados.
Há várias maneiras de criar tabelas do catálogo de dados:
+ Execute um crawler no AWS Glue. Consulte [Definição de crawlers](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html) no *Guia do desenvolvedor do AWS Glue *.
+ Crie e execute um fluxo de trabalho. Consulte [Importação de dados usando fluxos de trabalho no Lake Formation](workflows.md).
+ Crie uma tabela manualmente usando o console do Lake Formation, a API AWS Glue ou a AWS Command Line Interface (AWS CLI).
+ Crie uma tabela usando Amazon Athena.
+ Crie um link de recurso para uma tabela em uma conta externa. Consulte [Criação de links de recursos](creating-resource-links.md).
# Criar tabelas no Apache Iceberg
AWS Lake Formation suporta a criação de tabelas Apache Iceberg que usam o formato de dados Apache Parquet AWS Glue Data Catalog com dados residentes no Amazon S3. Uma tabela no catálogo de dados é a definição de metadados que representa os dados em um armazenamento de dados. Por padrão, o Lake Formation cria tabelas do Iceberg v2. Para saber a diferença entre as tabelas da v1 e v2, consulte [Alterações de versão do formato](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) na documentação do Apache Iceberg.
[Apache Iceberg](https://iceberg.apache.org/) é um formato de tabela aberta para conjuntos de dados analíticos muito grandes. O Iceberg permite mudanças fáceis em seu esquema, também conhecido como evolução do esquema, o que significa que os usuários podem adicionar, renomear ou remover colunas de uma tabela de dados sem interromper os dados subjacentes. O Iceberg também fornece suporte para controle de versão de dados, o que permite que os usuários acompanhem as alterações nos dados ao longo do tempo. Isso ativa o atributo de viagem no tempo, que permite que os usuários acessem e consultem versões históricas dos dados e analisem as alterações nos dados entre atualizações e exclusões.
Você pode usar o console do Lake Formation ou a `CreateTable` operação na AWS Glue API para criar uma tabela Iceberg no Catálogo de Dados. Para obter mais informações, 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)).
Ao criar uma tabela do Iceberg no catálogo de dados, você deve especificar o formato da tabela e o caminho do arquivo de metadados no Amazon S3 para poder realizar leituras e gravações.
Você pode usar o Lake Formation para proteger sua tabela Iceberg usando permissões de controle de acesso refinadas ao registrar a localização de dados do Amazon S3 com. AWS Lake Formation Para dados de origem no Amazon S3 e metadados que não estão registrados no Lake Formation, o acesso é determinado pelas políticas de permissões do IAM para o Amazon S3 e ações. AWS Glue Para obter mais informações, consulte [Gerenciando permissões do Lake Formation](managing-permissions.md).
**nota**
O catálogo de dados não oferece suporte à criação de partições e à adição de propriedades da tabela do Iceberg.
**Topics**
+ [Pré-requisitos](#iceberg-prerequisites)
+ [Criar uma tabela no Iceberg](#create-iceberg-table)
## Pré-requisitos
Para criar tabelas Iceberg no catálogo de dados e configurar as permissões de acesso aos dados do Lake Formation, você precisa preencher os seguintes requisitos:
1.
**Permissões necessárias para criar tabelas do Iceberg sem os dados registrados no Lake Formation.**
Além das permissões necessárias para criar uma tabela no catálogo de dados, o criador da tabela precisa as seguintes permissões:
+ `s3:PutObject` no recurso arn:aws:s3:::\$1bucketName\$1
+ `s3:GetObject` no recurso arn:aws:s3:::\$1bucketName\$1
+ `s3:DeleteObject` no recurso arn:aws:s3:::\$1bucketName\$1
1.
**Permissões necessárias para criar tabelas do Iceberg com dados registrados no Lake Formation:**
Para usar o Lake Formation para gerenciar e proteger os dados em seu data lake, registre sua localização no Amazon S3 que tenha os dados para tabelas com o Lake Formation. Isso é para que a Lake Formation possa fornecer credenciais para serviços AWS analíticos como Athena, Redshift Spectrum e Amazon EMR para acessar dados. Para obter mais informações sobre como registrar um local do Amazon S3, consulte [Adicionar uma localização do Amazon S3 ao seu data lake](register-data-lake.md).
Uma entidade principal que lê e grava os dados subjacentes registrados no Lake Formation exige as seguintes permissões:
+ `lakeformation:GetDataAccess`
+ `DATA_LOCATION_ACCESS`
Uma entidade principal que tem permissões de localização de dados em um local também tem permissões de localização em todos os locais secundários.
Para obter mais informações sobre permissões de localização de dados, consulte [Controle de acesso a dados subjacente](access-control-underlying-data.md).
Para permitir a compactação, o serviço precisa assumir um perfil do IAM que tenha permissões para atualizar tabelas no catálogo de dados. Para obter detalhes, consulte [Table optimization prerequisites](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
## Criar uma tabela no Iceberg
Você pode criar tabelas Iceberg v1 e v2 usando o console Lake Formation ou AWS Command Line Interface conforme documentado nesta página. Você também pode criar tabelas Iceberg usando o AWS Glue console ou Crawler do AWS Glue. Para obter mais informações, consulte [Catálogo de dados e crawlers](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html) no Guia do desenvolvedor do AWS Glue .
**Para criar uma tabela no Iceberg**
------
#### [ Console ]
1. Faça login no Console de gerenciamento da AWS, e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. Em catálogo de dados, escolha **Tabelas** e use o botão **Criar tabela** para especificar os seguintes atributos:
+ **Nome da tabela**: insira um nome para a tabela. Se você estiver usando o Athena para acessar tabelas, use essas [dicas de nomenclatura](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html) no Guia do usuário do Amazon Athena.
+ **Banco de dados**: escolha um banco de dados existente ou crie um novo.
+ **Descrição**: descrição da tabela. Você pode escrever uma descrição para ajudá-lo a entender o conteúdo da tabela.
+ **Formato da tabela**: para **Formato da tabela**, escolha Apache Iceberg.
![\[Opção de tabela do Apache Iceberg selecionada com as opções de otimização de tabelas.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/table-optimization.png)
+ **Otimização de tabelas**
+ **Compactação**: os arquivos de dados são mesclados e regravados para remover dados obsoletos e consolidar dados fragmentados em arquivos maiores e mais eficientes.
+ **Retenção de snapshots**: os snapshots são versões com carimbo de data e hora de uma tabela do Iceberg. As configurações de retenção de snapshots permitem que os clientes determinem por quanto tempo reter e quantos snapshots devem ser retidos. A configuração de um otimizador de retenção de snapshots pode ajudar a gerenciar a sobrecarga de armazenamento removendo snapshots antigos e desnecessários e seus arquivos subjacentes.
+ **Exclusão de arquivos órfãos**: arquivos órfãos são arquivos que não são mais referidos pelos metadados da tabela do Iceberg. Esses arquivos podem se acumular ao longo do tempo, especialmente após operações como exclusões de tabelas ou trabalhos de ETL com falha. A ativação da exclusão de arquivos órfãos permite identificar e AWS Glue remover periodicamente esses arquivos desnecessários, liberando espaço de armazenamento.
Para obter mais informações, consulte [Como otimizar tabelas do Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html).
+ **Perfil do IAM**: para executar a compactação, o serviço assume um perfil do IAM em seu nome. Você pode escolher um perfil do IAM usando o menu suspenso. Certifique-se de que a função tenha as permissões necessárias para habilitar a compactação.
Para saber mais sobre as permissões necessárias, consulte [Table optimization prerequisites](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html).
+ **Localização**: especifique o caminho para a pasta no Amazon S3 que armazena a tabela de metadados. O Iceberg precisa de um arquivo de metadados e de um local no catálogo de dados para poder realizar leituras e gravações.
+ **Esquema**: escolha **Adicionar colunas** para adicionar colunas e tipos de dados das colunas. Você tem a opção de criar uma tabela vazia e atualizar o esquema posteriormente. O catálogo de dados oferece suporte aos tipos de dados do Hive. Para obter mais informações, consulte [Tipos de dados do Hive](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462).
O Iceberg permite que você evolua o esquema e a partição depois de criar a tabela. Você pode usar as [consultas do Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) para atualizar o esquema da tabela e as consultas do [Spark](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) para atualizar as partições.
------
#### [ 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/"
}
}'
```
------
# Otimizar tabelas Iceberg
O Lake Formation suporta várias opções de otimização de tabelas para aprimorar o gerenciamento e o desempenho das tabelas Apache Iceberg usadas pelos mecanismos AWS analíticos e pelas tarefas de ETL. Esses otimizadores fornecem utilização eficiente do espaço em disco, melhor performance de consultas e gerenciamento de dados. Existem três tipos de otimizador de tabelas disponíveis no Lake Formation:
+ **Compactação**: a compactação de dados compacta pequenos arquivos de dados para reduzir o uso de armazenamento e melhorar a performance de leitura. Os arquivos de dados são mesclados e regravados para remover dados obsoletos e consolidar dados fragmentados em arquivos maiores e mais eficientes. A compactação pode ser configurada para ser executada automaticamente ou acionada manualmente conforme necessário.
+ **Retenção de snapshots**: os snapshots são versões com carimbo de data e hora de uma tabela do Iceberg. As configurações de retenção de snapshots permitem que os clientes determinem por quanto tempo reter e quantos snapshots devem ser retidos. A configuração de um otimizador de retenção de snapshots pode ajudar a gerenciar a sobrecarga de armazenamento removendo snapshots antigos e desnecessários e seus arquivos subjacentes.
+ **Exclusão de arquivos órfãos**: arquivos órfãos são arquivos que não são mais referidos pelos metadados da tabela do Iceberg. Esses arquivos podem se acumular ao longo do tempo, especialmente após operações como exclusões de tabelas ou trabalhos de ETL com falha. A ativação da exclusão de arquivos órfãos permite identificar e AWS Glue remover periodicamente esses arquivos desnecessários, liberando espaço de armazenamento.
Você pode ativar ou desativar os otimizadores de compactação, retenção de instantâneos e exclusão de arquivos órfãos para tabelas individuais do Iceberg no Catálogo de Dados usando o console ou as operações da API. AWS Glue AWS CLI AWS Glue
Para obter mais informações, consulte [Otimizando tabelas Iceberg](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html) no Guia do AWS Glue desenvolvedor.
# Procurando por tabelas
Você pode usar o AWS Lake Formation console para pesquisar tabelas do Catálogo de Dados por nome, localização, banco de dados contendo e muito mais. Os resultados da pesquisa mostram somente as tabelas nas quais você tem permissões do Lake Formation.
**Para procurar tabelas (console)**
1. Faça login Console de gerenciamento da AWS e abra o console do Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/).
1. No painel de navegação, selecione **Tabelas**.
1. Posicione o cursor no campo de pesquisa na parte superior da página. O campo tem o texto do espaço reservado *Localizar tabela por propriedades*.
O menu **Propriedades** é exibido, mostrando as várias propriedades da tabela pelas quais pesquisar.
![\[O menu de propriedades é suspenso do campo de pesquisa e contém as seguintes entradas: Nome, Classificação, Banco de Dados, Localização, ID do Catálogo\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/search-for-tables.png)
1. Execute um destes procedimentos:
+ Pesquise contendo banco de dados.
1. Escolha **Banco de dados** no menu **Propriedades** e, em seguida, escolha um banco de dados no menu **Bancos de dados** exibido ou digite o nome do banco de dados e pressione **Enter**.
As tabelas nas quais você tem permissões no banco de dados são listadas.
1. (Opcional) Para restringir a lista a uma única tabela no banco de dados, posicione o cursor no campo de pesquisa novamente, escolha **Nome** no menu **Propriedades** e escolha um nome de tabela no menu **Tabelas** exibido ou digite um nome de tabela e pressione **Enter**.
A tabela única é listada e tanto o nome do banco de dados quanto o nome da tabela aparecem como blocos sob o campo de pesquisa.
![\[Abaixo do campo de pesquisa, há dois blocos: um rotulado Banco de dados, que inclui o nome do banco de dados selecionado, e um rotulado Tabela, que inclui o nome da tabela selecionada. À direita dos blocos, há um botão Limpar filtro.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/search-for-tables-with-filter.png)
Para ajustar o filtro, feche um dos ladrilhos ou escolha **Limpar filtro**.
+ Pesquise por outras propriedades.
1. Escolha uma propriedade de pesquisa no menu **Propriedades**.
**Para pesquisar por ID da AWS conta, escolha **ID do catálogo** no menu **Propriedades**, insira uma ID de AWS conta válida (por exemplo, 111122223333) e pressione Enter.**
Para pesquisar por localização, escolha **Localização** no menu **Propriedades** e selecione uma localização no menu **Localizações** que aparece. Todas as tabelas na localização raiz da localização selecionada (por exemplo, Amazon S3) são retornadas.
**Pesquisando tabelas usando AWS CLI**
+ O exemplo a seguir mostra como executar uma pesquisa parcial. O parâmetro `--search-text` permite pesquisar tabelas que contenham o texto especificado em seus metadados. Nesse caso, ele exibe todas as tabelas que têm “cliente” no nome, na descrição ou em outros campos de metadados.
```
aws glue search-tables
--search-text "customer"
--region Região da AWS
--max-results 10
--sort-criteria "FieldName=Name,Sort=ASC"
```
# Compartilhamento de tabelas e bancos de dados do catálogo de dados entre AWS contas
Você pode compartilhar recursos do Catálogo de Dados (bancos de dados e tabelas) com AWS contas externas concedendo permissões do Lake Formation sobre os recursos às contas externas. Os usuários podem então executar consultas e trabalhos que unem e consultam tabelas em várias contas. Com algumas restrições, quando você compartilha um recurso do catálogo de dados com outra conta, as entidades principais dessa conta podem operar nesse recurso como se o recurso estivesse em seu catálogo de dados.
Você não compartilha recursos com diretores específicos em AWS contas externas — você compartilha os recursos com uma AWS conta ou organização. Ao compartilhar um recurso com uma organização da AWS , você está compartilhando o recurso com todas as contas em todos os níveis dessa organização. O administrador do data lake em cada conta externa deve então conceder permissões sobre os recursos compartilhados às entidades principais da conta.
Para obter mais informações, consulte [Compartilhamento de dados entre contas no Lake Formation](cross-account-permissions.md) e [Conceder permissões nos recursos do Catálogo de Dados](granting-catalog-permissions.md).
**Consulte também:**
[Acessar e visualizar tabelas e bancos de dados compartilhados do catálogo de dados](viewing-shared-resources.md)
[Pré-requisitos](cross-account-prereqs.md)
# AWS Glue Data Catalog Vistas do edifício
No AWS Glue Data Catalog, uma *exibição* é uma tabela virtual na qual o conteúdo é definido por uma consulta SQL que faz referência a uma ou mais tabelas. Você pode criar uma visualização do catálogo de dados que faça referência a até 10 tabelas usando editores SQL para Amazon Athena, Amazon Redshift ou Apache Spark usando o EMR Serverless ou a versão 5.0. AWS Glue As tabelas de referência subjacentes de uma exibição podem pertencer ao mesmo banco de dados ou a bancos de dados diferentes dentro Conta da AWS do mesmo catálogo de dados.
Você pode referenciar AWS Glue tabelas e tabelas padrão em formatos de tabela aberta (OTF), como [Apache Hudi](https://hudi.incubator.apache.org/), Linux Foundation [Delta Lake](https://delta.io/) e [Apache Iceberg](https://iceberg.apache.org/), com dados subjacentes armazenados em locais do Amazon S3 registrados com. AWS Lake Formation Além disso, você pode criar visualizações de tabelas federadas em unidades de compartilhamento de dados do Amazon Redshift que são compartilhadas com o Lake Formation.
## Diferenciar visualizações do Catálogo de Dados de outros tipos de visualização
As visualizações do Catálogo de Dados diferem das visualizações do Apache Hive, do Apache Spark e do Amazon Athena. A visualização do Catálogo de Dados é um recurso nativo do AWS Glue Data Catalog, e é uma visualização criada pelo definidor de vários dialetos. Você pode criar uma visualização do Catálogo de Dados usando um dos serviços de analytics compatíveis, como o Athena ou o Amazon Redshift Spectrum, e acessar a mesma visualização usando outros serviços de analytics compatíveis. Entretanto, as visualizações do Apache Hive, do Apache Spark e do Athena são criadas de forma independente em cada serviço de analytics, como o Athena e o Amazon Redshift, e são visíveis e acessíveis somente dentro desse serviço.
## O que é uma visualização de programador?
Uma visualização de programador é uma visualização SQL que opera com base nas permissões da entidade principal que a criou. O perfil do programador tem as permissões necessárias para acessar as tabelas referidas e executa a instrução SQL que programa a visualização. O definidor cria a visualização e a compartilha com outros usuários por meio AWS Lake Formation do controle de acesso refinado.
Quando um usuário consulta a visualização do programador, o mecanismo de consulta usa as permissões do perfil do programador para acessar as tabelas de referência subjacentes. Essa abordagem permite que os usuários interajam com a visualização sem precisar de acesso direto às tabelas de origem, aumentando a segurança e simplificando o gerenciamento do acesso aos dados.
Para configurar uma visualização definidora, a função definidora do IAM pode estar na mesma AWS conta das tabelas base ou em uma conta diferente usando funções de definidor entre contas. Para obter mais informações sobre as permissões necessárias para o perfil do programador, consulte [Pré-requisitos para criar visualizações](views-prereqs.md).
## Um framework para visualizações de vários dialetos
O Catálogo de Dados aceita a criação de visualizações usando vários dialetos da linguagem de consulta estruturada (SQL). SQL é uma linguagem usada para armazenar e processar informações em um banco de dados relacional e cada mecanismo AWS analítico usa sua própria variação de SQL ou dialeto SQL.
Você cria uma visualização do Catálogo de Dados em um dialeto SQL usando um dos mecanismos de consulta de analytics compatíveis. Posteriormente, você pode atualizar a visualização usando a instrução `ALTER VIEW` em um dialeto SQL diferente em qualquer outro mecanismo de analytics compatível. No entanto, cada dialeto deve fazer referência ao mesmo conjunto de tabelas, colunas e tipos de dados.
Você pode acessar os vários dialetos disponíveis para a visualização usando a `GetTable` API AWS CLI e AWS o console. Assim, a visualização do Catálogo de Dados fica visível e disponível para consultas em diferentes mecanismos de analytics compatíveis.
Ao definir um esquema de visualização comum e um objeto de metadados que você pode consultar em vários mecanismos, as visualizações do catálogo de dados permitem usar visualizações uniformes em todo o data lake.
Para obter mais detalhes sobre como o esquema é resolvido para cada dialeto, consulte o [link para a referência da API](). Para obter mais detalhes sobre as regras de correspondência para diferentes tipos, consulte o [link para a seção relevante no documento da API]().
## Integrar a permissões do Lake Formation
Você pode usar AWS Lake Formation para centralizar o gerenciamento de permissões nas AWS Glue Data Catalog visualizações dos usuários. Você pode conceder permissões refinadas nas visualizações do Catálogo de Dados usando o método de recurso nomeado ou tags LF e compartilhá-las entre AWS organizações e unidades Contas da AWS organizacionais. Você também pode compartilhar e acessar as visualizações do Catálogo de Dados Regiões da AWS usando links de recursos. Isso permite que os usuários forneçam acesso aos dados sem duplicar a fonte de dados ou compartilhar as tabelas subjacentes.
A declaração `CREATE VIEW` DDL de uma visualização do catálogo de dados pode referenciar AWS Glue as tabelas e tabelas padrão em formatos de tabela aberta (OTF), como Hudi, Delta Lake e Iceberg, com dados subjacentes armazenados em locais do Amazon S3 registrados no Lake Formation, bem como as tabelas federadas do compartilhamento de dados do Amazon Redshift que são compartilhadas com o Lake Formation. As tabelas podem ter qualquer formato de arquivo, desde que o mecanismo usado para consultar a visualização seja compatível com esse formato. Você também pode fazer referência a funções integradas do mecanismo no qual elas são executadas, mas outros recursos específicos do mecanismo podem não ser permitidos. Para obter mais detalhes, consulte [Considerações e limitações das visualizações do catálogo de dados](views-notes.md)
## Casos de uso
Os casos de uso importantes das visualizações do Catálogo de Dados são apresentados abaixo:
+ Criar e gerenciar permissões em um único esquema de visualização. Isso ajuda a evitar o risco de permissões inconsistentes em visualizações duplicadas criadas em vários mecanismos.
+ Conceda permissões aos usuários em uma visualização que faz referência a várias tabelas sem conceder permissões diretamente nas tabelas de referência subjacentes.
+ Obtenha a filtragem no nível de linha em tabelas que usam tags do LF (em que as tags do LF se disseminam em cascata somente até o nível da coluna) aplicando tags do LF nas visualizações e concedendo permissões baseadas em tags do LF aos usuários.
## Serviços de AWS análise compatíveis para visualizações
Os seguintes serviços de AWS análise oferecem suporte à criação de visualizações do Catálogo de Dados:
+ banco de dados de origem
+ Amazon Athena versão 3
+ Apache Spark no EMR Sem Servidor
+ Apache Spark na versão 5.0 AWS Glue
## Recursos adicionais do
É possível saber mais sobre o Catálogo de Dados neste guia do usuário, bem como nos seguintes recursos:
O vídeo a seguir demonstra como criar visualizações e consultá-las no Athena e no Amazon Redshift.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL)
**Topics**
+ [Diferenciar visualizações do Catálogo de Dados de outros tipos de visualização](#diff-views)
+ [O que é uma visualização de programador?](#definer-view)
+ [Um framework para visualizações de vários dialetos](#multi-dialect)
+ [Integrar a permissões do Lake Formation](#lf-view-integ)
+ [Casos de uso](#views-use-cases)
+ [Serviços de AWS análise compatíveis para visualizações](#views-supported-engines)
+ [Recursos adicionais do](#views-addtional-resources)
+ [Pré-requisitos para criar visualizações](views-prereqs.md)
+ [Criar visualizações do Catálogo de Dados usando instruções DDL](create-views.md)
+ [Criando visualizações do Catálogo de Dados usando AWS Glue APIs](views-api-usage.md)
+ [Conceder permissões nas visualizações do catálogo de dados](grant-perms-views.md)
+ [Visões materializadas](materialized-views.md)
# Pré-requisitos para criar visualizações
+ Para criar visualizações no catálogo de dados, é necessário registrar os locais de dados subjacentes do Amazon S3 das tabelas de referência no Lake Formation. Para obter detalhes sobre o registro de dados no Lake Formation, consulte [Adicionar uma localização do Amazon S3 ao seu data lake](register-data-lake.md).
+ Somente perfis do IAM podem criar visualizações do Catálogo de Dados. Outras identidades do IAM não podem criar visualizações do catálogo de dados.
+ O perfil do IAM que define a visualização deve ter as seguintes permissões:
+ Permissão `SELECT` completa do Lake Formation com a opção `Grantable` em todas as tabelas de referência, com todas as colunas incluídas.
+ A permissão `CREATE_TABLE` do Lake Formation no banco de dados de destino em que as visualizações estão sendo criadas.
+ Uma política de confiança para que a Lake Formation e AWS Glue os serviços assumam a função.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DataCatalogViewDefinerAssumeRole1",
"Effect": "Allow",
"Principal": {
"Service": [
"glue.amazonaws.com",
"lakeformation.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
+ O objetivo: PassRole permissão para AWS Glue e 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 e permissões do 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": "*"
}
]
}
```
------
+ Não é possível criar visualizações em um banco de dados que tenha a permissão `Super` ou `ALL` concedida ao grupo `IAMAllowedPrincipals`. Você pode revogar a permissão `Super` para o grupo `IAMAllowedPrincipals` em um banco de dados, consultar [Etapa 4: mude seus armazenamentos de dados para o modelo de permissões do Lake Formation](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4) ou criar um banco de dados com a caixa **Usar somente o controle de acesso do IAM para novas tabelas neste banco de dados** desmarcada em **Permissões padrão para tabelas recém-criadas**.
# Criar visualizações do Catálogo de Dados usando instruções DDL
Você pode criar AWS Glue Data Catalog visualizações usando editores SQL para Athena, Amazon Redshift e usando o/. AWS Glue APIs AWS CLI
Para criar uma visualização do Catálogo de Dados usando editores SQL, escolha Athena ou Redshift Spectrum e crie a visualização usando uma instrução `CREATE VIEW` da linguagem de definição de dados (DDL). Depois de criar uma visualização no dialeto do primeiro mecanismo, você pode usar uma instrução DDL `ALTER VIEW` do segundo mecanismo para adicionar os outros dialetos.
Ao definir as visualizações, é importante considerar o seguinte:
+ **Definir visualizações de vários dialetos**: quando você define uma visualização com vários dialetos, os esquemas dos diferentes dialetos devem corresponder. Cada dialeto SQL terá uma especificação de sintaxe ligeiramente diferente. A sintaxe da consulta que define a visualização do Catálogo de Dados deve ser resolvida exatamente na mesma lista de colunas, incluindo tipos e nomes, em todos os dialetos. Essas informações são armazenadas no `StorageDescriptor` da visualização. Os dialetos também devem fazer referência aos mesmos objetos subjacentes da tabela do Catálogo de Dados.
Para adicionar outro dialeto a uma visualização usando DDL, você pode usar a instrução `ALTER VIEW`. Se uma instrução `ALTER VIEW` tentar atualizar a definição da visualização, como modificar o descritor de armazenamento ou as tabelas subjacentes da visualização, a instrução vai gerar a mensagem de erro: “Input and existing storage descriptor mismatch”. Você pode usar operações de conversão de SQL para garantir que os tipos de coluna de visualização correspondam.
+ **Atualizar uma visualização**: para atualizar a visualização, você pode usar a API `UpdateTable`. Se você atualizar a visualização sem compatibilizar os descritores de armazenamento ou as tabelas de referência, poderá fornecer o sinalizador `FORCE` (consulte a documentação do SQL do mecanismo para obter a sintaxe). Depois de uma atualização forçada, a visualização assumirá a tabela `StorageDescriptor` forçada e a de referência. Qualquer DDL `ALTER VIEW` adicional deve corresponder aos valores modificados. Uma visualização que foi atualizada para ter dialetos incompatíveis terá o status “Obsoleto”. O status da visualização é visível no console do Lake Formation e usa a operação `GetTable`.
+ **Fazer referência a um tipo de coluna varchar como uma string**: não é possível converter um tipo de coluna varchar do Redshift Spectrum em uma string. Se uma visualização for criada no Redshift Spectrum com um tipo de coluna varchar e um dialeto subsequente tentar fazer referência a esse campo como uma string, o Catálogo de Dados a tratará como string sem a necessidade do sinalizador `FORCE`.
+ **Tratamento de campos de tipos complexos**: o Amazon Redshift trata todos os tipos complexos como [tipos SUPER](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html), enquanto o Athena especifica o tipo complexo. Se uma visualização tiver um campo de tipo `SUPER` e outro mecanismo fizer referência a essa coluna como um tipo complexo específico, como struct (`>`), o Catálogo de Dados presumirá que o campo seja do tipo complexo específico e o usará no descritor de armazenamento, sem exigir o sinalizador `Force`.
Para obter mais informações sobre a sintaxe para criar e gerenciar visualizações do catálogo de dados, consulte:
+ [Uso das visualizações do AWS Glue Data Catalog](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html) no Guia do usuário do Amazon Athena.
+ [Glue Data Catalog view query syntax](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html) no Guia do usuário do Amazon Athena.
+ [Creating views in the AWS Glue Data Catalog](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html) no Guia do desenvolvedor do banco de dados do Amazon Redshift.
Para obter mais informações sobre os comandos SQL relacionados a exibições no Data Catalog, 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) e [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html).
Após a criação de uma visualização do Catálogo de Dados, os respectivos detalhes ficam disponíveis no console do Lake Formation.
1. Selecione **Visualizações** no catálogo de dados no console do Lake Formation.
1. Uma lista das visualizações disponíveis é exibida na página de visualizações.
1. Selecione uma visualização na lista e a página de detalhes mostrará os atributos da visualização.
![\[A seção inferior contém cinco guias dispostas horizontalmente, e cada guia inclui as informações correspondentes.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/view-definition.png)
Schema
Selecione uma linha de `Column` e escolha **Editar tags do LF** para atualizar os valores das tags ou atribuir novas tags do LF.
Definições de SQL
É possível ver uma lista das definições de SQL disponíveis. Selecione **Adicionar definição de SQL** e escolha um mecanismo de consulta para adicionar uma definição de SQL. Selecione um mecanismo de consulta (Athena ou Amazon Redshift) na coluna `Edit definition` para atualizar as definições de SQL.
Tags do LF
Selecione **Editar tags do LF** para editar valores para uma tag ou atribuir novas tags. É possível usar tags do LF para conceder permissões nas visualizações.
Acesso entre contas
Você pode ver uma lista de Contas da AWS organizações e unidades organizacionais (OUs) com as quais você compartilhou a visualização do Catálogo de Dados.
Tabelas subjacentes
As tabelas subjacentes referenciadas na definição de SQL usada para criar a exibição são mostradas nessa guia.
# Criando visualizações do Catálogo de Dados usando AWS Glue APIs
Você pode usar AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html)e [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs para criar e atualizar exibições no Catálogo de Dados. As operações `CreateTable` e `UpdateTable` têm uma nova estrutura de `TableInput` para `ViewDefinition`, enquanto as operações `SearchTables`, `GetTable`, `GetTables`, `GetTableVersion` e `GetTableVersions` fornecem a `ViewDefinition` na respectiva sintaxe de saída para as visualizações. Além disso, há um novo campo de `Status` na saída da API `GetTable`.
Duas novas AWS Glue conexões estão disponíveis para validar o dialeto SQL para cada mecanismo de consulta compatível Amazon Athena e para o Amazon Redshift.
Os `CreateTable` e `UpdateTable` APIs são assíncronos quando usados com visualizações. Quando eles APIs são chamados com vários dialetos SQL, a chamada é validada com cada mecanismo para determinar se o dialeto pode ser executado nesse mecanismo e se o esquema resultante da visualização de cada dialeto corresponde. O AWS Glue serviço usa essas conexões para fazer chamadas internas para os mecanismos analíticos. Essas chamadas simulam o que o mecanismo faz para validar se uma instrução DDL SQL `CREATE VIEW` ou `ALTER VIEW` foi executada no mecanismo.
Se o SQL fornecido for válido e os esquemas corresponderem entre os dialetos de visualização, a API do AWS Glue confirmará atomicamente o resultado. A atomicidade permite que visualizações com vários dialetos sejam criadas ou alteradas sem nenhum tempo de inatividade.
**Topics**
+ [Criação de AWS Glue conexões para validar o status](views-api-usage-connection.md)
+ [Validar o status de geração de visualizações](views-api-usage-get-table.md)
+ [Estados e operações assíncronos](views-api-usage-async-states.md)
+ [Cenários de falha na criação de visualizações durante operações assíncronas](views-api-usage-errors.md)
# Criação de AWS Glue conexões para validar o status
Para criar ou atualizar uma AWS Glue Data Catalog visualização usando as `UpdateTable` operações `CreateTable` ou, você deve criar um novo tipo de AWS Glue conexão para validação e fornecê-lo ao mecanismo de análise compatível. Essas conexões são necessárias para usar as visualizações do Catálogo de Dados com o Athena ou o Amazon Redshift. Você pode criar essas conexões somente usando o AWS CLI, AWS SDKs, ou AWS Glue APIs. Você não pode usar o Console de gerenciamento da AWS para criar a AWS Glue conexão.
**nota**
Se o perfil do programador de visualizações e o perfil que chama `CreateTable` ou `UpdateTable` forem diferentes, ambos precisarão da permissão `glue:PassConnection` na declaração de política do IAM.
Para obter mais informações, consulte a documentação de [criação de conexão](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI .
**AWS CLI comando para criar uma conexão**
Veja a seguir um AWS CLI comando para criar uma conexão:
```
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 entrada 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"
}
}
}
```
# Validar o status de geração de visualizações
Quando você executa as operações `CreateTable` ou `UpdateTable`, o campo `Status` da saída da API `GetTable` mostra os detalhes do status de criação da visualização. Para `create` solicitações em que a tabela ainda não existe, AWS Glue cria uma tabela vazia durante o processo assíncrono. Ao chamar `GetTable`, você pode passar um sinalizador booliano `IncludeStatusDetails` opcional, que mostra informações de diagnóstico sobre a solicitação. No caso de uma falha, esse sinalizador mostra uma mensagem de erro com o status individual de cada dialeto.
Erros durante as operações de criação, leitura, atualização e exclusão de visualizações (CRUD) podem ocorrer durante o processamento no serviço AWS Glue/Lake Formation ou durante a validação do SQL de visualização no Amazon Redshift ou no Athena. Quando ocorre um erro durante a validação em um mecanismo, o serviço AWS Glue apresenta a mensagem de erro que o mecanismo exibe.
**Campos de status**
Estes são os campos de status:
+ Status (um status genérico, que se aplica a diferentes tipos de trabalho):
+ QUEUED
+ IN\$1PROGRESS
+ SUCCESS
+ FAILED
+ Action: indica qual ação foi chamada na tabela. No momento, somente as operações `CREATE` ou `UPDATE` estão disponíveis.
Distinguir entre as operações `UPDATE` e `CREATE` é importante ao trabalhar com visualizações. O tipo de operação determina como você deve prosseguir com a consulta das tabelas.
Uma operação `UPDATE` significa que a tabela já existe no Catálogo de Dados. Nesse caso, você pode continuar consultando a tabela criada anteriormente sem problemas. Entretanto, uma operação `CREATE `indica que a tabela nunca foi criada com sucesso. Se uma tabela estiver marcada como `CREATE`, a tentativa de consultá-la falhará porque ela ainda não existe no sistema. Portanto, é essencial identificar o tipo de operação (UPDATE ou CREATE) antes de tentar consultar uma tabela.
+ RequestedBy — O ARN do usuário que solicitou a alteração assíncrona.
+ UpdatedBy — O ARN do usuário que alterou manualmente pela última vez o processo de alteração assíncrona, como solicitar um cancelamento ou modificação.
+ Error: este campo só aparece quando o estado é **FAILED**. Essa é uma mensagem de exceção no nível principal. Pode haver erros diferentes para cada dialeto.
+ ErrorCode — O tipo de exceção.
+ ErrorMessage — uma breve descrição da exceção.
+ RequestTime — uma string de data formatada em ISO 8601 indicando a hora em que a alteração foi iniciada.
+ UpdateTime — uma string de data formatada em ISO 8601 indicando a hora em que o estado foi atualizado pela última vez.
# Estados e operações assíncronos
Quando você executa uma solicitação `glue:CreateTable`, a criação assíncrona da visualização do Catálogo de Dados inicia-se. Nas seções a seguir, este documento descreve `Status` a AWS Glue visão que está disponível em uma `glue:GetTable` resposta. Por motivo de brevidade, esta seção omite a resposta completa.
```
{
"Table": {
...
"Status": {
...
"Action": "CREATE",
"State": "QUEUED",
}
}
}
```
Ambos os atributos acima representam informações importantes de diagnóstico que indicam o estado da operação assíncrona, bem como as ações que podem ser executadas nessa visualização. Abaixo estão os valores possíveis que esses atributos podem assumir.
1. `Status.Action`
1. CREATE
1. UPDATE
1. `Status.State`
1. QUEUED
1. IN\$1PROGRESS
1. SUCCESS
1. FAILED
Também é importante observar que algumas atualizações em uma visualização do Catálogo de Dados não exigem uma operação assíncrona. Por exemplo, para atualizar o atributo `Description` da tabela. Como isso não requer nenhuma operação assíncrona, os metadados da tabela resultante não terão nenhum `Status`, e o atributo será `NULL`.
```
{
"Table": {
...,
"Description": "I changed this attribute!"
}
}
```
A seguir, este tópico explora como as informações de status acima podem afetar as operações que podem ser executadas em uma AWS Glue exibição.
**cola: CreateTable**
Não há alterações nessa API em comparação com a forma como `glue:CreateTable` funciona para qualquer tabela do Glue. É possível chamar `CreateTable` para qualquer nome de tabela que ainda não exista.
**cola: UpdateTable**
Essa operação não pode ser executada em uma AWS Glue exibição que tenha as seguintes informações de status:
1. Action == CREATE e State == QUEUED
1. Action == CREATE e State == IN\$1PROGRESS
1. Action == CREATE e State == FAILED
1. Action == UPDATE e State == QUEUED
1. Action == UPDATE e State == IN\$1PROGRESS
Resumindo, você pode atualizar uma visualização do Catálogo de Dados somente quando ela atender aos requisitos a seguir.
1. Foi criada com sucesso pela primeira vez.
1. Action == CREATE e State == SUCCESS
1. Atingiu um estado final após uma operação de atualização assíncrona.
1. Action == UPDATE e State == SUCCESS
1. Action == UPDATE e State == FAILED
1. Tem um atributo de estado `NULL` em decorrência de uma atualização síncrona.
**cola: DeleteTable**
Não há alterações nessa operação quando comparada à forma como `glue:DeleteTable` funciona em qualquer AWS Glue tabela. Você pode excluir uma visualização do Catálogo de Dados, independentemente do respectivo estado.
**cola: GetTable**
Não há alterações nessa operação quando comparada à forma como `glue:GetTable` funciona em qualquer AWS Glue tabela. No entanto, não é possível consultar uma visualização do Catálogo de Dados nos mecanismos analíticos enquanto ela não for criada com sucesso pela primeira vez. `Action == CREATE and State == SUCCESS`. Depois de criar uma visualização do Catálogo de Dados com sucesso pela primeira vez, você pode consultar a visualização, independentemente do respectivo status.
**nota**
Todas as informações nesta seção se aplicam a todas as tabelas lidas `GetTable``GetTables`, APIs como, `SearchTables` e.
# Cenários de falha na criação de visualizações durante operações assíncronas
Os exemplos a seguir são representativos dos tipos de erro que podem resultar das chamadas de API `CreateTable` ou `UpdateTable` da visualização. Eles não são completos, pois a superfície de erro das falhas de consultas SQL é muito grande.
## Cenário 1: falha na consulta do Amazon Redshift
A consulta fornecida para o Amazon Redshift inclui um nome de tabela com erro de ortografia que não pode ser encontrado no Catálogo de Dados durante a validação. O erro resultante é mostrado no campo `Status` na resposta `GetTable` da visualização.
Solicitação `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"
}
]
}
}
}
```
Resposta `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"
}
}
]
}
}
}
}
```
## Cenário 2: conexão inválida do Amazon Redshift
A conexão do Amazon Redshift no exemplo a seguir está malformada porque se refere a um banco de dados do Amazon Redshift que não existe no endpoint fornecido. cluster/serverless O Amazon Redshift não consegue validar a visualização e o campo `Status` na resposta `GetTable` mostra o erro `"State": "FAILED"` do Amazon Redshift).
Solicitação `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"
}
]
}
}
}
```
Resposta `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"
}
}
]
}
}
}
}
```
## Cenário 3: falha na consulta do Athena
Aqui, o SQL para o Athena é inválido porque a consulta digita incorretamente o nome do banco de dados. A validação da consulta do Athena detecta isso e o erro resultante aparece por meio do objeto `Status` em uma chamada `GetTable`.
Solicitação `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"
}
]
}
}
}
```
Resposta `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"
}
]
}
}
}
}
```
## Cenário 4: descritores de armazenamento incompatíveis
O SQL fornecido para o dialeto do Athena seleciona `col1` e `col2`, enquanto o SQL para o Redshift seleciona somente `col1`. Isso provoca um erro de incompatibilidade do descritor de armazenamento.
Solicitação `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"
}
]
}
}
}
```
Resposta `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"
}
}
]
}
}
}
}
```
# Conceder permissões nas visualizações do catálogo de dados
Depois de criar visualizações no AWS Glue Data Catalog, você pode conceder permissões de data lake em visualizações a diretores de todas Contas da AWS as organizações e unidades organizacionais. É possível conceder permissões usando tags do LF ou o método de recurso nomeado. Para obter mais informações sobre os recursos de tag, consulte [Controle de acesso baseado em tags do Lake Formation](tag-based-access-control.md). Para obter mais informações sobre como conceder permissões a visualizações diretamente, consulte [Conceder permissões em visualizações usando o método de recurso nomeado](granting-view-permissions.md).
# Visões materializadas
**Topics**
+ [Diferenciando visualizações materializadas de outros tipos de visualização](#materialized-views-differentiating)
+ [Casos de uso](#materialized-views-use-cases)
+ [Principais conceitos](#materialized-views-key-concepts)
+ [Permissões para visões materializadas](#materialized-views-permissions)
+ [Criação e gerenciamento de visualizações materializadas](#materialized-views-creating-managing)
+ [Armazenamento e acesso aos dados](#materialized-views-storage-access)
+ [Integração com permissões AWS Lake Formation](#materialized-views-lake-formation)
+ [Monitoramento e depuração](#materialized-views-monitoring-debugging)
+ [Gerenciando trabalhos de atualização](#materialized-views-managing-refresh-jobs)
+ [Monitoramento e solução de problemas](#materialized-views-monitoring-troubleshooting)
+ [Considerações e limitações](#materialized-views-considerations-limitations)
No Catálogo de AWS Glue Dados, uma visualização materializada é uma tabela gerenciada que armazena o resultado pré-computado de uma consulta SQL no formato Apache Iceberg. Diferentemente das visualizações padrão do Catálogo de Dados que executam a consulta sempre que são acessadas, as visualizações materializadas armazenam fisicamente os resultados da consulta e os atualizam à medida que as tabelas de origem subjacentes mudam. Você pode criar visualizações materializadas usando o Apache Spark versão 3.5.6\$1 no Amazon Athena, Amazon EMR ou. AWS Glue
As visualizações materializadas fazem referência às tabelas do Apache Iceberg registradas no catálogo de dados, com AWS Glue dados pré-computados armazenados como tabelas do Apache Iceberg em buckets do Amazon S3 Tables ou buckets de uso geral do Amazon S3, tornando-os acessíveis a partir de vários mecanismos de consulta, incluindo Amazon Athena, Amazon Redshift e mecanismos de terceiros compatíveis com o Iceberg.
## Diferenciando visualizações materializadas de outros tipos de visualização
As visualizações materializadas diferem das visualizações do catálogo de AWS Glue dados, das visualizações do Apache Spark e das visualizações do Amazon Athena de maneiras fundamentais. Embora as visualizações do Catálogo de Dados sejam tabelas virtuais que executam a definição da consulta SQL sempre que são acessadas, as visualizações materializadas armazenam fisicamente os resultados pré-computados da consulta. Isso elimina a computação redundante e melhora significativamente o desempenho da consulta para transformações complexas acessadas com frequência.
As visualizações materializadas também diferem dos pipelines tradicionais de transformação de dados criados com AWS Glue ETL ou tarefas personalizadas do Spark. Em vez de escrever código personalizado para lidar com a detecção de alterações, atualizações incrementais e orquestração do fluxo de trabalho, você define visualizações materializadas usando a sintaxe SQL padrão. O Catálogo AWS Glue de Dados monitora automaticamente as tabelas de origem, detecta alterações e atualiza as visualizações materializadas usando uma infraestrutura computacional totalmente gerenciada.
## Casos de uso
Veja a seguir casos de uso importantes para visualizações materializadas:
+ **Acelere consultas analíticas complexas** — crie visualizações materializadas que pré-computam junções, agregações e funções de janela caras. Os mecanismos do Spark reescrevem automaticamente as consultas subsequentes para usar os resultados pré-computados, reduzindo a latência da consulta e os custos de computação.
+ **Simplifique os pipelines de transformação de dados** — substitua tarefas complexas de ETL que lidam com detecção de alterações, atualizações incrementais e orquestração de fluxo de trabalho por definições simples de visualização materializada baseadas em SQL. O Catálogo AWS Glue de Dados gerencia toda a complexidade operacional automaticamente.
+ **Habilite análises de autoatendimento com acesso controlado aos dados** — Crie visualizações materializadas com curadoria que transformam dados brutos em conjuntos de dados prontos para uso comercial. Conceda aos usuários acesso a visualizações materializadas sem expor as tabelas de origem subjacentes, simplificando o gerenciamento da segurança e fortalecendo a análise de autoatendimento.
+ **Otimize a engenharia de recursos para aprendizado de máquina** — defina visualizações materializadas que implementam transformações de recursos para modelos de ML. O recurso de atualização automática garante que os repositórios de recursos permaneçam atualizados à medida que os dados de origem evoluem, enquanto a atualização incremental minimiza os custos de computação.
+ **Implemente um compartilhamento eficiente de dados** — crie visualizações materializadas que filtram e transformam dados para consumidores específicos. Compartilhe visualizações materializadas entre contas e regiões usando AWS Lake Formation, eliminando a necessidade de duplicação de dados e mantendo a governança centralizada.
## Principais conceitos
### Atualização automática
A atualização automática é um recurso que monitora continuamente suas tabelas de origem e atualiza as visualizações materializadas de acordo com um cronograma definido por você. Ao criar uma visualização materializada, você pode especificar uma frequência de atualização usando uma programação baseada em tempo com intervalos de até uma hora. O Catálogo de AWS Glue Dados usa a infraestrutura computacional gerenciada do Spark para executar operações de atualização em segundo plano, lidando de forma transparente com todos os aspectos da detecção de alterações e atualizações incrementais.
Quando os dados de origem mudam entre os intervalos de atualização, a visualização materializada fica temporariamente obsoleta. As consultas que acessam diretamente a visualização materializada podem retornar resultados desatualizados até que a próxima atualização programada seja concluída. Para cenários que exigem acesso imediato aos dados mais atuais, você pode executar uma atualização manual usando o comando `REFRESH MATERIALIZED VIEW` SQL.
### Atualização incremental
A atualização incremental é uma técnica de otimização que processa somente os dados que foram alterados nas tabelas de origem desde a última atualização, em vez de recomputar toda a visualização materializada. O Catálogo de AWS Glue Dados aproveita a camada de metadados do Apache Iceberg para rastrear com eficiência as alterações nas tabelas de origem e determinar quais partes da visualização materializada precisam de atualizações.
Essa abordagem reduz significativamente os custos de computação e a duração da atualização em comparação com as operações de atualização completa, especialmente para grandes conjuntos de dados em que apenas uma pequena porcentagem dos dados é alterada entre os ciclos de atualização. O mecanismo de atualização incremental opera automaticamente; você não precisa escrever uma lógica personalizada para detectar ou processar dados alterados.
### Reescrita automática de consultas
A reescrita automática de consultas é um recurso de otimização de consultas disponível nos mecanismos do Spark no Amazon Athena, Amazon EMR e. AWS Glue Quando você executa uma consulta em tabelas base, o otimizador do Spark analisa seu plano de consulta e determina automaticamente se as visualizações materializadas disponíveis podem satisfazer a consulta com mais eficiência. Se existir uma visualização materializada adequada, o otimizador reescreve a consulta de forma transparente para usar os resultados pré-computados em vez de processar as tabelas base.
Essa otimização ocorre sem exigir nenhuma alteração no código do aplicativo ou nas instruções de consulta. O otimizador Spark garante que a reescrita automática de consultas só se aplique quando a visualização materializada estiver atualizada e puder produzir resultados precisos. Se uma visualização materializada estiver obsoleta ou não corresponder totalmente aos requisitos de consulta, o otimizador executa o plano de consulta original em relação às tabelas base, priorizando a correção em detrimento do desempenho.
### Exibir função do definidor
Uma visualização materializada opera com base nas permissões da função do IAM que a criou, conhecida como função definidora de visualizações. A função definidora deve ter acesso de leitura a todas as tabelas base referenciadas na definição da visualização materializada e criar permissões de tabela no banco de dados de destino. Quando o Catálogo de AWS Glue Dados atualiza uma exibição materializada, ele assume a função de definidor de acessar tabelas de origem e gravar resultados atualizados.
Esse modelo de segurança permite que você conceda aos usuários acesso às visualizações materializadas sem conceder a eles permissões diretas nas tabelas de origem subjacentes. Se a função do definidor de visualizações perder o acesso a qualquer tabela base, as operações de atualização subsequentes falharão até que as permissões sejam restauradas.
## Permissões para visões materializadas
Para criar e gerenciar visualizações materializadas, você deve configurar AWS Lake Formation as permissões. O perfil do IAM que cria a visão materializada (o perfil definidor) requer permissões específicas nas tabelas de origem e nos bancos de dados de destino.
### Permissões necessárias para o perfil de definidor
O perfil deve ter as seguintes permissões:
+ Nas tabelas de origem: permissões SELECT ou ALL sem filtros de linha, coluna ou célula
+ No banco de dados de destino: permissão CREATE\$1TABLE
+ No catálogo de AWS Glue dados — GetTable e nas permissões CreateTable da API
Quando você cria uma visão materializada, o ARN do perfil definidor é armazenado na definição da visão. O Catálogo AWS Glue de Dados assume essa função ao executar operações de atualização automática. Se o perfil do definidor perder o acesso às tabelas de origem, as operações de atualização falharão até que as permissões sejam restauradas.
### Permissões do IAM para AWS Glue trabalhos
A AWS Glue função do IAM do seu trabalho exige as seguintes permissões:
```
{
"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": "*"
}
]
}
```
A função que você usa para a atualização automática do Materialized View deve ter a PassRole permissão iam: na função.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/materialized-view-role-name"
]
}
]
}
```
Para que o Glue atualize automaticamente a visão materializada para você, o perfil também deve ter a política de confiança a seguir que permite que o serviço assuma o perfil.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "glue.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Se a visão materializada estiver armazenada em buckets do Tabelas do S3, também precisará adicionar a seguinte permissão ao perfil.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3tables:PutTableMaintenanceConfiguration"
],
"Resource": "arn:aws:s3tables:*:123456789012:*"
}
]
}
```
### Conceder acesso às visões materializadas
Para conceder a outros usuários acesso para consultar uma visualização materializada, use AWS Lake Formation para conceder a permissão SELECT na tabela de visualização materializada. Os usuários podem consultar a visão materializada sem precisar de acesso direto às tabelas de origem subjacentes.
Para obter informações detalhadas sobre como configurar as permissões do Lake Formation, consulte Conceder e revogar permissões nos recursos do Catálogo de Dados no Guia do AWS Lake Formation Desenvolvedor.
## Criação e gerenciamento de visualizações materializadas
Você cria visualizações materializadas usando a `CREATE MATERIALIZED VIEW` instrução SQL nos mecanismos do Spark. A definição da exibição especifica a consulta SQL que define a lógica de transformação, o nome do banco de dados e da tabela de destino e a configuração de atualização opcional. Você pode definir transformações complexas, incluindo agregações, junções em várias tabelas, filtros e funções de janela.
```
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 a atualização automática, inclua a agenda de atualização na sua definição de exibição:
```
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;
```
Você pode atualizar manualmente uma visualização materializada a qualquer momento usando o `REFRESH MATERIALIZED VIEW` comando:
```
REFRESH MATERIALIZED VIEW sales_summary;
```
Para modificar o cronograma de atualização de uma visualização materializada existente, use a `ALTER MATERIALIZED VIEW` instrução:
```
ALTER MATERIALIZED VIEW sales_summary
ADD SCHEDULE REFRESH EVERY 2 HOURS;
```
### Visões materializadas aninhadas
Você pode criar visualizações materializadas que referenciem outras visualizações materializadas como tabelas base, permitindo transformações de dados em vários estágios. Quando você cria visualizações materializadas aninhadas, o Catálogo de AWS Glue Dados rastreia dependências e propaga automaticamente as atualizações por meio da hierarquia de visualizações materializadas. Quando uma visualização materializada básica é atualizada, todas as visualizações materializadas posteriores que dependem dela são atualizadas adequadamente.
Esse recurso permite que você decomponha transformações complexas em estágios lógicos, melhorando a capacidade de manutenção e permitindo a atualização seletiva das camadas de transformação com base em seus requisitos de atualização de dados.
## Armazenamento e acesso aos dados
As visualizações materializadas armazenam resultados pré-computados como tabelas Apache Iceberg em buckets S3 Tables ou buckets S3 de uso geral em sua conta. AWS O Catálogo AWS Glue de Dados gerencia todos os aspectos da manutenção da tabela Iceberg, incluindo compactação e retenção de instantâneos, por meio dos recursos de otimização automatizada do S3 Tables.
Como as visualizações materializadas são armazenadas como tabelas do Iceberg, você pode lê-las diretamente de qualquer mecanismo compatível com o Iceberg, incluindo Amazon Athena, Amazon Redshift e plataformas de análise de terceiros. Essa acessibilidade multimecanismo garante que seus dados pré-computados permaneçam acessíveis em todo o seu ecossistema de análise sem duplicação de dados ou conversão de formato.
## Integração com permissões AWS Lake Formation
Você pode usar AWS Lake Formation para gerenciar permissões refinadas em visualizações materializadas. O criador da visualização se torna automaticamente o proprietário da visualização materializada e pode conceder permissões a outros usuários ou funções usando o método AWS Lake Formation de recurso nomeado ou as tags LF.
Quando você concede `SELECT` permissão a um usuário em uma visualização materializada, ele pode consultar os resultados pré-computados sem precisar acessar as tabelas de origem subjacentes. Esse modelo de segurança simplifica o gerenciamento do acesso aos dados e permite que você implemente o princípio do menor privilégio, fornecendo aos usuários acesso somente às transformações de dados específicas de que precisam.
Você pode compartilhar visualizações materializadas entre AWS contas, AWS organizações e unidades organizacionais usando os recursos de compartilhamento entre contas AWS Lake Formation da. Você também pode acessar visualizações materializadas em todas AWS as regiões usando links de recursos, permitindo a governança centralizada de dados com acesso distribuído aos dados.
## Monitoramento e depuração
O Catálogo AWS Glue de Dados publica todas as operações de atualização de visualizações materializadas e métricas associadas na Amazon. CloudWatch Você pode monitorar a hora de início, a hora de término, a duração, o volume de dados processados e o status da atualização por meio CloudWatch de métricas. Quando as operações de atualização falham, as mensagens de erro e as informações de diagnóstico são capturadas nos CloudWatch registros.
Você pode configurar CloudWatch alarmes para receber notificações quando os trabalhos de atualização excederem a duração esperada ou falharem repetidamente. O Catálogo de AWS Glue Dados também publica eventos de alteração para execuções de atualização bem-sucedidas e malsucedidas, permitindo que você integre operações de visualização materializada em uma automação mais ampla do fluxo de trabalho.
Para verificar o status atual de uma visualização materializada, use o comando `DESCRIBE MATERIALIZED VIEW` SQL, que retorna metadados, incluindo status de inatividade, data e hora da última atualização e configuração do cronograma de atualização.
## Gerenciando trabalhos de atualização
### Iniciando uma atualização manual
Acione uma atualização imediata fora do intervalo programado.
Permissão necessária: AWS as credenciais usadas para fazer a chamada à API devem ter `glue:GetTable` permissão para a visualização materializada.
Para o catálogo de tabelas do S3:
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id :s3tablescatalog/ \
--database-name \
--table-name
```
Para o Root Catalog:
```
aws glue start-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
### Verificando o status da atualização
Obtenha o status de um trabalho de atualização específico:
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id
```
### Histórico de atualização da lista
Visualize todas as tarefas de atualização de uma visão materializada:
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name
```
**nota**
Use `:s3tablescatalog/` para tabelas S3 ou `` para catálogo raiz.
### Interrompendo uma atualização em execução
Cancelar um trabalho de atualização em andamento:
```
aws glue stop-materialized-view-refresh-task-run \
--catalog-id \
--database-name \
--table-name
```
## Monitoramento e solução de problemas
Há três maneiras de monitorar as tarefas de atualização de visualizações materializadas:
### CloudWatch Métricas
Visualize métricas agregadas para todas as suas tarefas de atualização de visualização materializada em: CloudWatch
Métricas disponíveis:
+ AWS/Glue namespace com dimensões:
+ CatalogId: Seu identificador de catálogo
+ DatabaseName: Banco de dados contendo a visualização materializada
+ TableName: Nome da visualização materializada
+ TaskType: Defina como "MaterializedViewRefresh”
Visualizando no console:
1. Navegue até CloudWatch Console → Métricas
1. Selecione o AWS namespace /Glue
1. Filtrar por dimensões: CatalogId, DatabaseName, TableName, TaskType
1. Veja métricas de sucesso, fracasso e duração do trabalho
Exemplo de consulta de CloudWatch métricas:
```
{AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh
```
Usando 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
Visualize registros de execução detalhados para execuções individuais de tarefas de atualização:
Grupo de registros: `/aws-glue/materialized-views/`
Onde `` está um UUID (por exemplo, abc12345-def6-7890-ghij-klmnopqrstuv).
Visualizando 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
```
No CloudWatch console:
1. Navegue até CloudWatch → Grupos de registros
1. Pesquise por /aws-glue/materialized-views/
1. Selecione o grupo de registros com seu ID de execução da tarefa
1. Visualize registros detalhados de execução, erros e resultados de tarefas do Spark
### Notificações
Inscreva-se em eventos para receber notificações em tempo real sobre mudanças no estado da tarefa de atualização:
Tipos de eventos disponíveis:
+ Tarefa de atualização do Glue Materialized View iniciada
+ A tarefa de atualização do Glue Materialized View foi bem-sucedida
+ Falha na tarefa de atualização do Glue Materialized View
+ Falha na invocação de atualização automática do Glue Materialized View
Criando uma regra:
```
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
```
Adicionando um alvo (por exemplo, tópico do SNS):
```
aws events put-targets \
--rule materialized-view-refresh-notifications \
--targets "Id"="1","Arn"="arn:aws:sns:::" \
--region
```
### Visualizando o status de atualização
Verifique o status de seus trabalhos de atualização de visualização materializada usando a AWS Glue API:
```
aws glue get-materialized-view-refresh-task-run \
--catalog-id \
--materialized-view-refresh-task-run-id \
--region
```
Ou liste todas as execuções de atualização recentes:
```
aws glue list-materialized-view-refresh-task-runs \
--catalog-id \
--database-name \
--table-name \
--region
```
Isso mostra:
+ Hora da última atualização
+ Status de atualização (BEM-SUCEDIDA, FALHA, EM EXECUÇÃO, PARADA)
+ ID de execução da tarefa
+ Mensagens de erro (se falharem)
Estados comuns de atualização:
+ EM EXECUÇÃO: O trabalho de atualização está sendo executado no momento
+ BEM-SUCEDIDO: Atualização concluída com sucesso
+ FALHA: A atualização encontrou um erro
+ PARADO: a atualização foi cancelada manualmente
Solução de problemas de atualizações com falha:
Se uma atualização falhar, verifique:
1. Permissões do IAM: garanta que a função definidora tenha acesso a todas as tabelas base e ao local da visualização materializada
1. Disponibilidade da tabela base: verifique se todas as tabelas referenciadas existem e estão acessíveis
1. Validade da consulta: confirme se a consulta SQL é válida para o dialeto SQL do Spark
1. Limites de recursos: verifique se você atingiu os limites de atualização simultânea da sua conta
Use a GetMaterializedViewRefreshTaskRun API para recuperar mensagens de erro detalhadas.
## Considerações e limitações
+ As visualizações materializadas só podem referenciar tabelas do Apache Iceberg registradas no Catálogo de AWS Glue Dados como tabelas base.
+ A criação de visualizações e a reescrita automática de consultas estão disponíveis somente nos mecanismos Spark no Apache Spark versão 3.5.6 e superior no Amazon Athena, Amazon EMR e (versão 5.1). AWS Glue
+ Eventualmente, as visualizações materializadas são consistentes com as tabelas base. Durante a janela de atualização, as consultas que acessam diretamente a visualização materializada podem retornar dados desatualizados. Para acesso imediato aos dados atuais, execute uma atualização manual.
+ O intervalo mínimo de atualização automática é uma hora. Para casos de uso que exigem atualizações mais frequentes, execute atualizações manuais programaticamente usando o comando. `REFRESH MATERIALIZED VIEW`
+ A reescrita da consulta prioriza a correção em detrimento do desempenho. Se uma visualização materializada estiver obsoleta ou não puder atender aos requisitos de consulta com precisão, os mecanismos do Spark executam a consulta original nas tabelas base.
# Importação de dados usando fluxos de trabalho no Lake Formation
Com o AWS Lake Formation, você pode importar seus dados usando *fluxos de trabalho*. Um fluxo de trabalho define a fonte de dados e o cronograma para importar dados para o seu data lake. É um contêiner para crawlers do AWS Glue, trabalhos e acionadores usados para orquestrar os processos de carregamento e atualização do data lake.
**Topics**
+ [Esquemas e fluxos de trabalho no Lake Formation](workflows-about.md)
+ [Criação de um fluxo de trabalho](workflows-creating.md)
+ [Executar um fluxo de trabalho](workflows-running.md)
# Esquemas e fluxos de trabalho no Lake Formation
Um fluxo de trabalho encapsula uma atividade complexa de vários trabalhos de extração, transformação e carregamento (ETL). Os fluxos de trabalho geram crawlers do AWS Glue, trabalhos e gatilhos para orquestrar o carregamento e a atualização dos dados. O Lake Formation executa e rastreia um fluxo de trabalho como uma entidade única. Você pode configurar um fluxo de trabalho para ser executado sob demanda ou de acordo com um cronograma.
**nota**
O gravador Parquet do Spark não comporta caracteres especiais nos nomes das colunas. Essa é uma limitação técnica do próprio gravador, não um problema de configuração.
Os fluxos de trabalho que você cria no Lake Formation são visíveis no console do AWS Glue como um gráfico acíclico direcionado (DAG). Cada nó do DAG é uma tarefa, um crawler ou um gatilho. Para monitorar o progresso e solucionar problemas, você pode acompanhar o status de cada nó no fluxo de trabalho.
Quando um fluxo de trabalho do Lake Formation é concluído, o usuário que executou o fluxo de trabalho recebe a permissão `SELECT` do Lake Formation nas tabelas do catálogo de dados que o fluxo de trabalho cria.
Você também pode criar fluxos de trabalho no AWS Glue. No entanto, como o Lake Formation permite que você crie um fluxo de trabalho a partir de um esquema, criar fluxos de trabalho é muito mais simples e automatizado no Lake Formation. Lake Formation fornece os seguintes tipos de esquemas:
+ **Instantâneo do banco de dados**: carrega ou recarrega dados de todas as tabelas no data lake a partir de uma fonte JDBC. Você pode excluir alguns dados da fonte com base em um padrão de exclusão.
+ **Banco de dados incremental**: carrega somente novos dados no data lake a partir de uma fonte JDBC, com base em marcadores previamente definidos. Você especifica as tabelas individuais no banco de dados de origem do JDBC a serem incluídas. Para cada tabela, você escolhe as colunas dos favoritos e a ordem de classificação dos favoritos para acompanhar os dados que foram carregados anteriormente. Na primeira vez que você executa um esquema de banco de dados incremental em um conjunto de tabelas, o fluxo de trabalho carrega todos os dados das tabelas e define marcadores para a próxima execução do esquema de banco de dados incremental. Portanto, você pode usar um esquema de banco de dados incremental em vez do esquema de instantâneo do banco de dados para carregar todos os dados, desde que você especifique cada tabela na fonte de dados como um parâmetro.
+ **Arquivo de log**: carrega dados em massa de fontes de arquivos de log, incluindo AWS CloudTrail e logs do Elastic Load Balancing e do Application Load Balancer.
Use a tabela a seguir para ajudar a decidir se deve usar um snapshot de banco de dados ou um esquema de banco de dados incremental.
| Use o instantâneo do banco de dados quando... | Use o banco de dados incremental quando... |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/workflows-about.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/workflows-about.html) |
**nota**
Os usuários não podem editar plantas e fluxos de trabalho criados pelo Lake Formation.
# Criação de um fluxo de trabalho
Antes de começar, verifique se você concedeu as permissões de dados e as permissões de localização de dados necessárias para a função `LakeFormationWorkflowRole`. Isso é para que o fluxo de trabalho possa criar tabelas de metadados no catálogo de dados e gravar dados em locais de destino no Amazon S3. Para obter mais informações, consulte [(Opcional) Criar um perfil do IAM para fluxos de trabalho](initial-lf-config.md#iam-create-blueprint-role) e [Visão geral das permissões do Lake Formation](lf-permissions-overview.md).
**nota**
O Lake Formation usa as operações `GetTemplateInstance`, `GetTemplateInstances` e `InstantiateTemplate` para criar fluxos de trabalho com base em esquemas. Essas operações não estão disponíveis ao público e são usadas apenas internamente para criar recursos em seu nome. Você recebe eventos do CloudTrail por criar fluxos de trabalho.
**Para criar um fluxo de trabalho a partir de um esquema**
1. Abra o console do AWS Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com permissões de engenheiro de dados. Para obter mais informações, consulte [Referência de personas e permissões do IAM do Lake Formation](permissions-reference.md).
1. No painel de navegação, selecione **esquemas** e escolha **Usar esquema**.
1. Na página **Usar um esquema**, escolha um quadro para selecionar o tipo de esquema.
1. Em **Fonte de importação**, especifique a fonte de dados.
Se você estiver importando de uma fonte JDBC, especifique o seguinte:
+ ****Conexão de banco de dados****: escolha uma conexão na lista. Crie conexões adicionais usando o console do AWS Glue. O nome de usuário JDBC e a senha na conexão determinam os objetos do banco de dados aos quais o fluxo de trabalho tem acesso.
+ ****Caminho dos dados de origem****: insira **/**/** or **/**, dependendo do produto do banco de dados. Oracle Database e MySQL não oferecem suporte a esquema no caminho. Você pode substituir o caractere percentual (%) por ** ou **. Por exemplo, para um banco de dados Oracle com um identificador de sistema (SID) `orcl`, informe `orcl/%` para importar todas as tabelas às quais o usuário nomeado na conexão tem acesso.
**Importante**
Este campo diferencia letras maiúsculas de minúsculas. O fluxo de trabalho falhará se houver uma incompatibilidade de maiúsculas e minúsculas em qualquer um dos componentes.
Se você especificar um banco de dados MySQL, o ETL do AWS Glue usa o driver JDBC Mysql5 por padrão, portanto, o MySQL8 não é suportado nativamente. Você pode editar o script de trabalho ETL para usar um parâmetro `customJdbcDriverS3Path` conforme descrito em [Valores connectionType do JDBC](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-jdbc) no *Guia do desenvolvedor do AWS Glue* para usar um driver JDBC diferente que suporte MySQL8.
Se você estiver importando de um arquivo de log, certifique-se de que a função especificada para o fluxo de trabalho (a “função do fluxo de trabalho”) tenha as permissões necessárias do IAM para acessar a fonte de dados. Por exemplo, para importar logs do AWS CloudTrail, o usuário deve ter as permissões `cloudtrail:DescribeTrails` e `cloudtrail:LookupEvents` para ver a lista de logs do CloudTrail ao criar o fluxo de trabalho, e a função do fluxo de trabalho deve ter permissões na localização do CloudTrail no Amazon S3.
1. Execute um destes procedimentos:
+ Para o tipo de esquema de **instantâneo do banco de dados**, identifique opcionalmente um subconjunto de dados a serem importados especificando um ou mais padrões de exclusão. Esses padrões de exclusão são padrões `glob` no estilo Unix. Elas são armazenadas como uma propriedade das tabelas criadas pelo fluxo de trabalho.
Para obter detalhes sobre os padrões de exclusão disponíveis, consulte [Incluir e excluir padrões](https://docs.aws.amazon.com/glue/latest/dg/define-crawler.html#crawler-data-stores-exclude) no *Guia do desenvolvedor do AWS Glue*.
+ Para o tipo de esquema de **banco de dados incremental**, especifique os seguintes campos. Adicione uma linha para cada tabela a ser importada.
**Nome da tabela**
Tabela a ser importada. Deve estar em letras minúsculas.
**Teclas de marcadores**
Lista delimitada por vírgula dos nomes das colunas que definem as teclas dos favoritos. Se estiver em branco, a chave primária será usada para determinar novos dados. As maiúsculas e minúsculas de cada coluna devem corresponder às maiúsculas e minúsculas, conforme definido na fonte de dados.
A chave primária se qualifica como a chave de bookmark padrão apenas se estiver aumentando ou diminuindo sequencialmente (sem lacunas). Se você quiser usar a chave primária como chave de marcador e ela tiver lacunas, você deverá nomear a coluna da chave primária como chave de marcador.
**Pedido de favoritos**
Quando você escolhe **Ascendente**, as linhas com valores maiores que os marcados são identificadas como novas. Quando você escolhe **Descendente**, as linhas com valores menores que os valores marcados são identificadas como novas.
**Esquema de particionamento**
(Opcional) Lista de colunas-chave de particionamento, delimitada por barras (/). Exemplo: ` year/month/day`.
![\[A seção Dados incrementais do console inclui os seguintes campos: nome da tabela, teclas de favoritos, ordem dos favoritos, esquema de particionamento. Você pode adicionar ou remover linhas, onde cada linha é para uma tabela diferente.\]](http://docs.aws.amazon.com/pt_br/lake-formation/latest/dg/images/incremental-data.png)
Para obter mais informações, consulte [Rastreamento de dados processados usando marcadores de trabalho](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) no *Guia do desenvolvedor do AWS Glue*.
1. Em **Importar destino**, especifique o banco de dados de destino, a localização de destino do Amazon S3 e o formato dos dados.
Certifique-se de que a função do fluxo de trabalho tenha as permissões necessárias do Lake Formation no banco de dados e no local de destino do Amazon S3.
**nota**
Atualmente, os esquemas não oferecem suporte à criptografia de dados no destino.
1. Escolha uma frequência de importação.
Você pode especificar uma expressão `cron` com a opção **Personalizada**.
1. Em **Opções de importação**:
1. Insira um nome de fluxo de trabalho.
1. Para a função, escolha a função `LakeFormationWorkflowRole`, que você criou em [(Opcional) Criar um perfil do IAM para fluxos de trabalho](initial-lf-config.md#iam-create-blueprint-role).
1. Opcionalmente, especifique um prefixo de tabela. O prefixo é anexado aos nomes das tabelas do catálogo de dados que o fluxo de trabalho cria.
1. Selecione **Criar** e aguarde até que o console informe que o fluxo de trabalho foi criado com sucesso.
**dica**
Você recebeu a seguinte mensagem de erro?
`User: arn:aws:iam:::user/ is not authorized to perform: iam:PassRole on resource:arn:aws:iam:::role/...`
Nesse caso, verifique se você substituiu **por um número de conta AWS válido em todas as políticas.
**Consulte também:**
[Esquemas e fluxos de trabalho no Lake Formation](workflows-about.md)
# Executar um fluxo de trabalho
Você pode executar um fluxo de trabalho usando o console do Lake Formation, o console do AWS Glue, a interface de linha de comando (AWS CLI) do AWS Glue ou a API.
**Para executar um fluxo de trabalho (console do Lake Formation)**
1. Abra o console do AWS Lake Formation em [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/). Faça login como administrador do data lake ou como usuário com permissões de engenheiro de dados. Para obter mais informações, consulte [Referência de personas e permissões do IAM do Lake Formation](permissions-reference.md).
1. No painel de navegação, escolha **Esquemas**.
1. Na página **Esquemas**, selecione o fluxo de trabalho. Em seguida, no menu **Ações**, escolha **Iniciar**.
1. À medida que o fluxo de trabalho é executado, você pode ver o progresso na coluna de **Status da última execução**. Escolha o botão de atualização ocasionalmente.
O status vai de **EM EXECUÇÃO** para **Descoberta**, para **Importação** e para **CONCLUÍDO**.
Quando o fluxo de trabalho for concluído:
+ O catálogo de dados tem novas tabelas de metadados.
+ Seus dados são ingeridos no data lake.
Se o fluxo de trabalho falhar, faça o seguinte:
1. Selecione o fluxo de trabalho. Escolha **Ações** e **Exibir gráfico**.
O fluxo de trabalho é aberto no console do AWS Glue.
1. Certifique-se de que o fluxo de trabalho esteja selecionado e acesse a guia **Histórico**.
1. Em **Histórico**, selecione a execução mais recente e selecione **Exibir informações da execução**.
1. Selecione um trabalho ou crawler com falha no gráfico dinâmico (runtime) e revise a mensagem de erro. Os nós com falha são vermelhos ou amarelos.
**Consulte também:**
[Esquemas e fluxos de trabalho no Lake Formation](workflows-about.md)