# Usar transações ACID do Athena
O termo “transações ACID” se refere a um conjunto de propriedades ([atomicidade](https://en.wikipedia.org/wiki/Atomicity_(database_systems)), [consistência](https://en.wikipedia.org/wiki/Consistency_(database_systems)), [isolamento](https://en.wikipedia.org/wiki/Isolation_(database_systems)) e [durabilidade](https://en.wikipedia.org/wiki/Durability_(database_systems))) que garantem a integridade dos dados nas transações de banco de dados. As transações ACID permitem que vários usuários adicionem e excluam objetos do Amazon S3 de maneira atômica, simultaneamente e com confiabilidade, ao mesmo tempo que isolam as consultas existentes mantendo a consistência de leitura para consultas no data lake. As transações ACID do Athena adicionam operações de inserção, exclusão, atualização e viagem no tempo à linguagem de manipulação de dados (DML) SQL do Athena. Você e vários usuários podem usar as transações ACID do Athena simultaneamente para fazer modificações confiáveis nos dados do Amazon S3 no nível da linha. As transações do Athena gerenciam automaticamente a semântica e a coordenação dos bloqueios e não requerem uma solução personalizada de bloqueio de registros.
As transações do ACID do Athena e a sintaxe SQL familiar simplificam as atualizações de dados empresariais e regulamentares. Por exemplo, para responder a uma solicitação de eliminação de dados, você pode executar uma operação `DELETE` em SQL. Para fazer correções manuais em registros, você pode usar uma única instrução `UPDATE`. Para recuperar dados que foram excluídos recentemente, você pode emitir consultas de viagem no tempo usando uma instrução `SELECT`.
Como elas são montadas em formatos de tabela compartilhada, as transações ACID do Athena são compatíveis com outros serviços e mecanismos, como o [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) e o [Apache Spark](https://spark.apache.org/) que também suportam formatos de tabela compartilhada.
As transações do Athena estão disponíveis por meio do console do Athena, de operações de API e dos drivers ODBC e JDBC.
**Topics**
+ [Consultar tabelas do Linux Foundation Delta Lake](delta-lake-tables.md)
+ [Consultar conjuntos de dados do Apache Hudi](querying-hudi.md)
+ [Consultar tabelas do Apache Iceberg](querying-iceberg.md)
# Consultar tabelas do Linux Foundation Delta Lake
O Linux Foundation [Delta Lake](https://delta.io/) é um formato de tabela para análise de big data. É possível usar o Amazon Athena para ler tabelas Delta Lake armazenadas no Amazon S3 de forma direta, sem a necessidade de gerar arquivos de manifesto ou executar a instrução `MSCK REPAIR`.
O formato Delta Lake armazena os valores mínimo e máximo de cada arquivo de dados por coluna. A implementação do Athena usa essas informações para habilitar o salto de arquivos em predicados com a finalidade de eliminar arquivos indesejados da consideração.
## Considerações e limitações
O suporte para o Delta Lake no Athena tem as limitações e considerações a seguir:
+ **Somente tabelas com catálogo do AWS Glue**: o suporte nativo do Delta Lake é compatível somente por meio de tabelas registradas no AWS Glue. Se você tiver uma tabela Delta Lake registrada em outro metastore, ainda poderá mantê-la e tratá-la como metastore principal. Como os metadados do Delta Lake são armazenados no sistema de arquivos (por exemplo, no Amazon S3) e não no metastore, o Athena requer somente a propriedade “location” no AWS Glue para ler as tabelas Delta Lake.
+ **Somente versão 3 do mecanismo**: as consultas do Delta Lake tem suporte somente na versão 3 do mecanismo do Athena. Você deve garantir que o grupo de trabalho criado esteja configurado para usar a versão 3 do mecanismo do Athena.
+ **Nenhum suporte para passagem de tempo**: não há suporte para consultas que usam as funcionalidades de passagem de tempo do Delta Lake.
+ **Somente leitura**: não há suporte para gravar instruções DML, como `UPDATE`, `INSERT` ou `DELETE`.
+ **Compatibilidade com o Lake Formation**: a integração com o Lake Formation está disponível para tabelas do Delta Lake com seu esquema sincronizado com o AWS Glue. Para obter mais informações, consulte [Usar o AWS Lake Formation com o Amazon Athena](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html) e [Configurar permissões para uma tabela do Delta Lake](https://docs.aws.amazon.com/lake-formation/latest/dg/set-up-delta-table.html) no *Guia de desenvolvedor do AWS Lake Formation*.
+ **Suporte DDL limitado**: as instruções DDL a seguir são compatíveis: `CREATE EXTERNAL TABLE`, `SHOW COLUMNS`, `SHOW TBLPROPERTIES`, `SHOW PARTITIONS`, `SHOW CREATE TABLE` e `DESCRIBE`. Para obter informações sobre como usar a instrução `CREATE EXTERNAL TABLE`, consulte a seção [Introdução às tabelas do Delta Lake](delta-lake-tables-getting-started.md).
+ **Não é possível ignorar os objetos do Amazon Glacier**: se os objetos na tabela do Linux Foundation Delta Lake estiverem em uma classe de armazenamento do Amazon Glacier, definir a propriedade da tabela `read_restored_glacier_objects` como `false` não surtirá efeito.
Por exemplo, suponhamos que você emita o seguinte comando:
```
ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
```
Para tabelas do Iceberg e do Delta Lake, o comando gera o erro Chave de propriedade da tabela não compatível: read\$1restored\$1glacier\$1objects. Para as tabelas do Hudi, o comando `ALTER TABLE` não gera erro, mas mesmo assim os objetos do Amazon Glacier não são ignorados. A execução de consultas `SELECT` após o comando `ALTER TABLE` continua a retornar todos os objetos.
+ **Tabelas criptografadas**: o Athena não é compatível com a leitura nativa de tabelas do Delta Lake criptografadas pelo CSE-KMS. Isso inclui as instruções SELECT e as instruções DDL.
### Versionamento do Delta Lake e do Athena
O Athena não usa o [versionamento](https://docs.delta.io/latest/releases.html) listado na documentação do Delta Lake. Para determinar se as tabelas do Delta Lake são compatíveis com o Athena, considere estas duas características:
+ **Versão do leitor**: cada tabela do Delta Lake tem uma versão de leitor. Atualmente, a versão é um número de 1 a 3. Consultas que incluírem uma tabela com uma versão de leitor não compatível com o Athena apresentarão falhas.
+ **Características da tabela**: cada tabela do Delta Lake também pode declarar um conjunto de atributos de leitor/gravador. Como o Athena é compatível com o Delta Lake apenas para leitura, a compatibilidade do atributo de gravação de tabelas não se aplica. Porém, consultas em tabelas com atributos de leitura de tabela não compatíveis apresentarão falhas.
A tabela a seguir mostra as versões e os atributos do leitor de tabela do Delta Lake que são compatíveis com o Athena.
****
| Tipo da consulta | Versões de leitor compatíveis | Atributos de leitor compatíveis |
| --- | --- | --- |
| DQL (instruções SELECT) | <= 3 | [Mapeamento de colunas](https://docs.delta.io/latest/delta-column-mapping.html), [timestampNtz](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#timestamp-without-timezone-timestampntz), [vetores de exclusão](https://docs.delta.io/latest/delta-deletion-vectors.html) |
| DDL | <= 1 | Não aplicável. Os atributos de leitor só podem ser declarados em tabelas com um leitor versão 2 ou superior. |
+ Para obter uma lista dos recursos de tabela do Delta Lake, consulte [Valid feature names in table features](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#valid-feature-names-in-table-features) no GitHub.com
+ Para ver uma lista dos atributos do Delta Lake por versão de protocolo, consulte [Features by protocol version](https://docs.delta.io/latest/versioning.html#features-by-protocol-version) no GitHub.com.
Para criar uma tabela do Delta Lake no Athena com uma versão de leitor acima de 1, consulte [Sincronizar metadados do Delta Lake](delta-lake-tables-syncing-metadata.md).
**Topics**
+ [Considerações e limitações](#delta-lake-tables-considerations-and-limitations)
+ [Tipos de dados de colunas com suporte](delta-lake-tables-supported-data-types-columns.md)
+ [Introdução às tabelas do Delta Lake](delta-lake-tables-getting-started.md)
+ [Consultar tabelas do Delta Lake com SQL](delta-lake-tables-querying.md)
+ [Sincronizar metadados do Delta Lake](delta-lake-tables-syncing-metadata.md)
+ [Recursos adicionais](delta-lake-tables-additional-resources.md)
# Tipos de dados de colunas com suporte
Esta seção descreve os tipos de dados com suporte para colunas sem partições e com partições.
## Tipos de dados compatíveis para colunas sem partições
Para colunas sem partições, há suporte para todos os tipos de dados compatíveis com o Athena, exceto `CHAR`. Não há suporte para `CHAR` no próprio protocolo do Delta Lake). Os tipos de dados compatíveis incluem:
```
boolean
tinyint
smallint
integer
bigint
double
float
decimal
varchar
string
binary
date
timestamp
array
map
struct
```
## Tipos de dados compatíveis para colunas com partições
Para colunas com partições, o Athena é compatível com tabelas com os tipos de dados a seguir:
```
boolean
integer
smallint
tinyint
bigint
decimal
float
double
date
timestamp
varchar
```
Para obter mais informações sobre os tipos de dados no Athena, consulte [Tipos de dados no Amazon Athena](data-types.md).
# Introdução às tabelas do Delta Lake
Para ser consultável, a tabela Delta Lake deve existir no AWS Glue. Se a tabela estiver no Amazon S3, mas não estiver no AWS Glue, execute uma instrução `CREATE EXTERNAL TABLE` usando a sintaxe a seguir. Se a tabela já existe no AWS Glue (por exemplo, porque você está usando o Apache Spark ou outro mecanismo com o AWS Glue), você pode ignorar esta etapa. Observe a omissão das definições das colunas, da biblioteca SerDe e de outras propriedades da tabela. Ao contrário das tabelas Hive tradicionais, os metadados da tabela Delta Lake são inferidos do log de transações do Delta Lake e sincronizados diretamente com o AWS Glue.
```
CREATE EXTERNAL TABLE
[db_name.]table_name
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ('table_type' = 'DELTA')
```
**nota**
Essa instrução não é compatível com buckets do S3 que têm pagamentos por solicitante habilitados. Se você quiser criar uma tabela do Delta Lake em um bucket do S3 com pagamentos por solicitante habilitados, siga as orientações e a instrução DDL em [Sincronizar metadados do Delta Lake](delta-lake-tables-syncing-metadata.md).
Para tabelas Delta Lake, as instruções `CREATE TABLE` que incluem mais do que as propriedades `LOCATION` e `table_type` não são permitidas.
# Consultar tabelas do Delta Lake com SQL
Para consultar uma tabela Delta Lake, use a sintaxe SQL padrão `SELECT`:
```
[ WITH with_query [, ...] ]SELECT [ ALL | DISTINCT ] select_expression [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ]
[ HAVING condition ]
[ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ]
[ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ]
[ OFFSET count [ ROW | ROWS ] ]
[ LIMIT [ count | ALL ] ]
```
Para obter mais informações sobre a sintaxe `SELECT`, consulte [SELECT](select.md) na documentação do Athena.
O formato Delta Lake armazena os valores mínimo e máximo de cada arquivo de dados por coluna. O Athena usa essas informações para habilitar o salto de arquivo em predicados com a finalidade de eliminar arquivos desnecessários da consideração.
# Sincronizar metadados do Delta Lake
O Athena sincroniza os metadados da tabela, incluindo o esquema, as colunas com partições e as propriedades da tabela, para o AWS Glue se você usar o Athena para criar a tabela Delta Lake. Com o passar do tempo, esses metadados podem perder a sincronização com os metadados da tabela subjacente no log de transações. Para manter a tabela atualizada, escolha uma das seguintes opções:
+ Use o crawler do AWS Glue para tabelas Delta Lake. Para obter mais informações, consulte [Introducing native Delta Lake table support with AWS Glue crawlers](https://aws.amazon.com/blogs/big-data/introducing-native-delta-lake-table-support-with-aws-glue-crawlers/) no *Blog do AWS Big Data* e [Programar um crawler do AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/schedule-crawler.html) no Guia do desenvolvedor do AWS Glue.
+ Solte e recrie a tabela no Athena.
+ Use o SDK, a CLI ou o console do AWS Glue para atualizar manualmente o esquema no AWS Glue.
Observe que os recursos a seguir exigem que seu esquema do AWS Glue sempre tenha o mesmo esquema do log de transações:
+ Lake Formation
+ Visualizações
+ Filtros de linha e coluna
Se o seu fluxo de trabalho não exigir nenhuma dessas funcionalidades e você preferir não manter essa compatibilidade, pode usar o DDL `CREATE TABLE` no Athena e depois adicionar o caminho do Amazon S3 como um parâmetro SerDe no AWS Glue.
## Criar uma tabela do Delta Lake usando os consoles do Athena e do AWS Glue
Você pode usar o procedimento a seguir para criar uma tabela do Delta Lake com os consoles do Athena e do AWS Glue.
**Para criar uma tabela Delta Lake usando o Athena e consoles do AWS Glue**
1. Abra o console do Athena em [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).
1. No editor de consultas do Athena, use o seguinte DDL para criar sua tabela Delta Lake. Observe que, ao usar esse método, o valor de `TBLPROPERTIES` deve ser `'spark.sql.sources.provider' = 'delta'`, e não`'table_type' = 'delta'`.
Observe que esse mesmo esquema (com uma única coluna chamada `col` de tipo `array`) é inserido quando você usa o Apache Spark (Athena para Apache Spark) ou a maioria dos outros mecanismos para criar sua tabela.
```
CREATE EXTERNAL TABLE
[db_name.]table_name(col array)
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ('spark.sql.sources.provider' = 'delta')
```
1. Abra o console do AWS Glue em [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. No painel de navegação, escolha **Catálogo de dados**, **Tabelas**.
1. Na lista de tabelas, escolha o link da sua tabela.
1. Na página da tabela, escolha **Ações**, **Editar tabela**.
1. Na seção **Parâmetros do Serde**, adicione a chave **path** com o valor **s3://amzn-s3-demo-bucket/*your-folder*/**.
1. Escolha **Salvar**.
## Criar uma tabela do Delta Lake usando a AWS CLI
Para criar uma tabela do Delta Lake usando a AWS CLI, insira um comando como o que se segue.
```
aws glue create-table --database-name dbname \
--table-input '{"Name" : "tablename", "StorageDescriptor":{
"Columns" : [
{
"Name": "col",
"Type": "array"
}
],
"Location" : "s3://amzn-s3-demo-bucket//",
"SerdeInfo" : {
"Parameters" : {
"serialization.format" : "1",
"path" : "s3://amzn-s3-demo-bucket//"
}
}
},
"PartitionKeys": [],
"TableType": "EXTERNAL_TABLE",
"Parameters": {
"EXTERNAL": "TRUE",
"spark.sql.sources.provider": "delta"
}
}'
```
# Recursos adicionais
Para uma discussão sobre o uso de tabelas do Delta Lake com AWS Glue e fazendo consultas com o Athena, consulte [Gerencie as operações de dados do UPSERT usando o Delta Lake de código aberto e AWS Glue](https://aws.amazon.com/blogs/big-data/handle-upsert-data-operations-using-open-source-delta-lake-and-aws-glue/) no *Blog de Big Data da AWS*.
# Consultar conjuntos de dados do Apache Hudi
O [https://hudi.incubator.apache.org/](https://hudi.incubator.apache.org/) é um framework de gerenciamento de dados de código aberto que simplifica o processamento incremental de dados. As ações de inserção, atualização, upsert e exclusão no nível do registro são processadas de forma muito mais granular, reduzindo a sobrecarga. `Upsert` refere-se à capacidade de inserir registros em um conjunto de dados existente, se eles ainda não existirem, ou atualizá-los, se já existirem.
O Hudi processa os eventos de inserção e atualização de dados sem criar muitos arquivos pequenos que podem causar problemas de performance em analytics. O Apache Hudi monitora automaticamente as alterações e mescla os arquivos para que mantenham o dimensionamento ideal. Isso evita a necessidade de criar soluções personalizadas que monitoram e regravam muitos arquivos pequenos em menos arquivos grandes.
Os conjuntos de dados do Hudi são adequados para os seguintes casos de uso:
+ Cumprir os regulamentos de privacidade, como o [Regulamento geral de proteção de dados](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) (RGPD) e o [California Consumer Privacy Act](https://en.wikipedia.org/wiki/California_Consumer_Privacy_Act) (CCPA), que determinam o direito das pessoas de remover informações pessoais ou alterar o modo como os dados são utilizados.
+ Trabalhar com dados de streaming de sensores e outros dispositivos da Internet das Coisas (IoT) que exigem eventos específicos de inserção e atualização de dados.
+ Implementar o [sistema de Change Data Capture (CDC – Captura de dados de alteração)](https://en.wikipedia.org/wiki/Change_data_capture).
O tipo de conjunto de dados do Hudi pode ser um destes:
+ **Copy on Write (CoW – Copiar na gravação)**: os dados são armazenados em um formato colunar (Parquet), e cada atualização cria uma nova versão dos arquivos durante uma gravação.
+ **Merge on Read (MoR – Mesclar na leitura)**: os dados são armazenados usando uma combinação de formatos colunares (Parquet) e baseados em linha (Avro). As atualizações são registradas em arquivos `delta` baseados em linha e compactadas conforme necessário para criar novas versões dos arquivos colunares.
Com conjuntos de dados CoW, sempre que há uma atualização para um registro, o arquivo que contém o registro é regravado com os valores atualizados. Com um conjunto de dados MoR, sempre que há uma atualização, o Hudi grava apenas a linha do registro alterado. MoR é mais adequado para cargas de trabalho com maior volume de gravações ou alterações e menor volume de leituras. O tipo CoW é mais adequado para workloads com maior volume de leituras em dados que mudam com menos frequência.
O Hudi oferece três tipos de consulta para acessar os dados:
+ **Consultas de snapshot**: consultas que veem o snapshot mais recente da tabela a partir de uma determinada ação de confirmação ou compactação. Para tabelas MoR, as consultas de snapshot expõem o estado mais recente da tabela mesclando os arquivos base e delta da fatia de arquivo mais recente no momento da consulta.
+ **Consultas incrementais**: as consultas veem somente os novos dados gravados na tabela, a partir de uma determinada confirmação/compactação. Desse modo, os streams de alteração são fornecidos para habilitar pipelines de dados incrementais.
+ **Ler consultas otimizadas**: para tabelas MoR, as consultas veem os dados mais recentes compactados. Para tabelas CoW, as consultas veem os dados mais recentes confirmados.
A tabela a seguir mostra os possíveis tipos de consulta do Hudi para cada tipo de tabela.
| Tipo de tabela | Possíveis tipos de consulta do Hudi |
| --- | --- |
| Copiar na gravação | snapshot, incremental |
| Mesclar na leitura | snapshot, incremental, otimizado para leitura |
Para obter mais informações sobre as vantagens e desvantagens dos tipos de tabela e consulta, acesse [Table & Queries Types](https://hudi.apache.org/docs/table_types/) na documentação do Apache Hudi.
## Alteração de terminologia do Hudi: as visualizações agora são consultas
A partir da versão 0.5.1 do Apache Hudi, o que antes era chamado de visualizações agora é chamado de consultas. A tabela a seguir resume as alterações entre os termos antigos e novos.
| Termo antigo | Termo novo |
| --- | --- |
| CoW: visualização otimizada para leitura MoR: visualização em tempo real | Consultas de snapshot |
| Visualização incremental | Consulta incremental |
| MoR: visualização otimizada para leitura | Consulta otimizada para leitura |
**Topics**
+ [Alteração de terminologia do Hudi: as visualizações agora são consultas](#querying-hudi-hudi-dataset-table-types-terminology)
+ [Considerações e limitações](querying-hudi-in-athena-considerations-and-limitations.md)
+ [Exemplos de criação de tabelas do tipo Copiar na gravação (CoW)](querying-hudi-copy-on-write-create-table-examples.md)
+ [Exemplos de criação de tabelas do tipo Mesclar na leitura (MoR)](querying-hudi-merge-on-read-create-table-examples.md)
+ [Usar de metadados Hudi para aprimorar a performance](querying-hudi-metadata-table.md)
+ [Recursos adicionais](querying-hudi-additional-resources.md)
# Considerações e limitações
Ao usar o Athena para ler tabelas do Apache Hudi, considere os pontos apresentados a seguir.
+ **Operações de leitura e gravação**: o Athena pode ler conjuntos de dados compactados do Hudi, mas não pode gravar dados do Hudi.
+ **Versões do Hudi**: o Athena é compatível com a versão 0.14.0 (padrão) e a 0.15.0 do Hudi. O Athena não pode garantir a compatibilidade de leitura com tabelas criadas com versões posteriores do Hudi. Para obter mais informações sobre os recursos e o versionamento do Hudi, consulte a [documentação do Hudi](https://hudi.apache.org/) no site do Apache. Observe que a versão 0.15.0 do conector Hudi no Athena não oferece suporte a tabelas inicializadas. Para usar a versão 0.15.0 do conector Hudi, defina a seguinte propriedade da tabela:
```
ALTER TABLE table_name SET TBLPROPERTIES ('athena_enable_native_hudi_connector_implementation' = 'true')
```
+ **Consultas entre contas**: a versão 0.15.0 do conector Hudi não é compatível com consultas entre contas.
+ **Tipos de consulta**: atualmente, o Athena permite consultas de snapshots e consultas otimizadas para leitura, mas não permite consultas incrementais. Nas tabelas MoR, todos os dados expostos a consultas otimizadas para leitura são compactados. Isso permite uma boa performance, mas não inclui as confirmações delta mais recentes. As consultas de snapshot contêm os dados mais recentes, mas geram um pouco de sobrecarga computacional, o que reduz a performance dessas consultas. Para obter mais informações sobre as vantagens e desvantagens dos tipos de tabela e consulta, acesse [Table & Queries Types](https://hudi.apache.org/docs/table_types/) na documentação do Apache Hudi.
+ **Consultas incrementais** — O Athena não aceita consultas incrementais.
+ **CTAS** — O Athena não aceita [CTAS](ctas.md) nem [INSERT INTO](insert-into.md) em dados do Hudi. Se você quiser ajuda do Athena para escrever conjuntos de dados do Hudi, envie feedback para athena-feedback@amazon.com.
Para obter mais informações sobre como escrever dados do Hudi, consulte os seguintes recursos:
+ [Working with a Hudi dataset](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hudi-work-with-dataset.html) (Trabalhar com um conjunto de dados do Hudi) no [Guia de apresentação do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/).
+ [Writing Data](https://hudi.apache.org/docs/0.8.0/writing_data.html) (Gravar dados) na documentação do Apache Hudi.
+ **MSCK REPAIR TABLE** — Não é permitido usar MSCK REPAIR TABLE em tabelas do Hudi no Athena. Se você precisar carregar uma tabela do Hudi que não foi criada no AWS Glue, use [ALTER TABLE ADD PARTITION](alter-table-add-partition.md).
+ **Não é possível ignorar os objetos do Amazon Glacier**: se os objetos na tabela do Apache Hudi estiverem em uma classe de armazenamento do Amazon Glacier, definir a propriedade da tabela `read_restored_glacier_objects` como `false` não surtirá efeito.
Por exemplo, suponhamos que você emita o seguinte comando:
```
ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
```
Para tabelas do Iceberg e do Delta Lake, o comando gera o erro Chave de propriedade da tabela não compatível: read\$1restored\$1glacier\$1objects. Para as tabelas do Hudi, o comando `ALTER TABLE` não gera erro, mas mesmo assim os objetos do Amazon Glacier não são ignorados. A execução de consultas `SELECT` após o comando `ALTER TABLE` continua a retornar todos os objetos.
+ **Consultas de timestamp** — Atualmente, as consultas que tentam ler colunas de timestamp nas tabelas de tempo real do Hudi falham ou produzem resultados vazios. Essa limitação se aplica somente às consultas que leem uma coluna de timestamp. As consultas que incluem somente colunas sem timestamp da mesma tabela são bem-sucedidas.
Consultas com falha retornam uma mensagem semelhante à seguinte:
GENERIC\$1INTERNAL\$1ERROR: class org.apache.hadoop.io.ArrayWritable cannot be cast to class org.apache.hadoop.hive.serde2.io.TimestampWritableV2 (org.apache.hadoop.io.ArrayWritable and org.apache.hadoop.hive.serde2.io.TimestampWritableV2 are in unnamed module of loader io.trino.server.PluginClassLoader @75c67992)
+ **Permissões de Lake Formation no conector Hudi 0.15.0**: esta limitação se aplica somente quando você opta por usar o conector Hudi nativo (versão 0.15.0) definindo a propriedade da tabela `athena_enable_native_hudi_connector_implementation` como `true`. Por padrão, o Athena usa o conector Hudi versão 0.14.0, que não exige essa permissão adicional. Para consultar uma tabela protegida do Lake Formation, você deve conceder permissões ao Lake Formation tanto para a localização dos dados da tabela quanto para o diretório de metadados `.hoodie`. Por exemplo, se sua tabela Hudi estiver localizada em `s3://bucket/hudi-table/`, você deve se registrar e conceder permissões tanto para `s3://bucket/hudi-table/` quanto para `s3://bucket/hudi-table/.hoodie/` no Lake Formation. O diretório `.hoodie` contém arquivos de metadados (como `hoodie.properties`) que o Athena precisa ler durante o planejamento da consulta. Sem permissões para o diretório `.hoodie`, as consultas falharão com erros de permissão negada.
# Exemplos de criação de tabelas do tipo Copiar na gravação (CoW)
Se você já tem tabelas do Hudi criadas no AWS Glue, pode consultá-las diretamente no Athena. Ao criar tabelas do Hudi particionadas no Athena, você deve executar `ALTER TABLE ADD PARTITION` para carregar os dados do Hudi antes de poder consultá-los.
## Tabela CoW não particionada
O exemplo a seguir cria uma tabela CoW não particionada no Athena.
```
CREATE EXTERNAL TABLE `non_partition_cow`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int,
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.HoodieParquetInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/non_partition_cow/'
```
## Tabela CoW particionada
O exemplo a seguir cria uma tabela CoW particionada no Athena.
```
CREATE EXTERNAL TABLE `partition_cow`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int)
PARTITIONED BY (
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.HoodieParquetInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/partition_cow/'
```
O exemplo `ALTER TABLE ADD PARTITION` a seguir adiciona duas partições à tabela `partition_cow` de exemplo.
```
ALTER TABLE partition_cow ADD
PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/one/'
PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/two/'
```
# Exemplos de criação de tabelas do tipo Mesclar na leitura (MoR)
O Hudi cria duas tabelas no metastore para MoR: uma tabela para consultas de snapshot e uma tabela para consultas otimizadas para leitura. As duas tabelas podem ser consultadas. Nas versões do Hudi anteriores à 0.5.1, a tabela de consultas otimizadas para leitura tinha o nome que você especificava ao criá-la. A partir do Hudi versão 0.5.1, o nome da tabela recebe o sufixo `_ro` por padrão. O nome da tabela de consultas de snapshot é aquele que você especifica com acrescentado `_rt`.
## Tabela MoR não particionada
O exemplo a seguir cria uma tabela MoR não particionada no Athena para consultas otimizadas para leitura. Observe que as consultas otimizadas para leitura usam o formato de entrada `HoodieParquetInputFormat`.
```
CREATE EXTERNAL TABLE `nonpartition_mor`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int,
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.HoodieParquetInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/nonpartition_mor/'
```
O exemplo a seguir cria uma tabela MoR não particionada no Athena para consultas de snapshot. Para consultas de snapshot, use o formato de entrada `HoodieParquetRealtimeInputFormat`.
```
CREATE EXTERNAL TABLE `nonpartition_mor_rt`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int,
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/nonpartition_mor/'
```
## Tabela MoR particionada
O exemplo a seguir cria uma tabela MoR particionada no Athena para consultas otimizadas para leitura.
```
CREATE EXTERNAL TABLE `partition_mor`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int)
PARTITIONED BY (
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.HoodieParquetInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/partition_mor/'
```
O exemplo `ALTER TABLE ADD PARTITION` a seguir adiciona duas partições à tabela `partition_mor` de exemplo.
```
ALTER TABLE partition_mor ADD
PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/'
PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/'
```
O exemplo a seguir cria uma tabela MoR particionada no Athena para consultas de snapshot.
```
CREATE EXTERNAL TABLE `partition_mor_rt`(
`_hoodie_commit_time` string,
`_hoodie_commit_seqno` string,
`_hoodie_record_key` string,
`_hoodie_partition_path` string,
`_hoodie_file_name` string,
`event_id` string,
`event_time` string,
`event_name` string,
`event_guests` int)
PARTITIONED BY (
`event_type` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT
'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
's3://amzn-s3-demo-bucket/folder/partition_mor/'
```
Da mesma forma, o exemplo `ALTER TABLE ADD PARTITION` a seguir adiciona duas partições à tabela `partition_mor_rt` de exemplo.
```
ALTER TABLE partition_mor_rt ADD
PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/'
PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/'
```
# Usar de metadados Hudi para aprimorar a performance
O Apache Hudi tem uma [tabela de metadados](https://hudi.apache.org/docs/next/metadata/) que contém recursos de indexação para melhorar a performance, como listagem de arquivos, possibilidade de ignorar dados usando estatísticas de coluna e um índice baseado em filtro de Bloom.
Desses recursos, o Athena atualmente só é compatível com o índice de listagem de arquivos. O índice de listagem de arquivos elimina chamadas do sistema de arquivos, como "listar arquivos", ao buscar as informações de um índice que mantém uma partição para mapeamento de arquivos. Isso elimina a necessidade de listar recursivamente todas as partições no caminho da tabela para obter uma visão do sistema de arquivos. Quando você trabalha com grandes conjuntos de dados, essa indexação reduz muito a latência que, de outra forma, ocorreria ao obter arquivos durante gravações e consultas. Também evita gargalos, como controle de utilização de solicitações nas chamadas `LIST` do Amazon S3.
**nota**
No momento, o Athena não é compatível com a possibilidade de ignorar dados nem com a indexação com filtro de Bloom.
## Habilitar tabela de metadados do Hudi
A listagem de arquivos baseada em tabela de metadados é desabilitada por padrão. Para habilitar a tabela de metadados do Hudi e a correspondente funcionalidade de listagem de arquivos, defina a propriedade da tabela `hudi.metadata-listing-enabled` como `TRUE`.
**Exemplo**
O exemplo de `ALTER TABLE SET TBLPROPERTIES` a seguir habilita a tabela de metadados `partition_cow` no exemplo.
```
ALTER TABLE partition_cow SET TBLPROPERTIES('hudi.metadata-listing-enabled'='TRUE')
```
## Usar metadados gerados por bootstrap
A partir do Apache Hudi versão 0.6.0, o recurso de operação de bootstrap oferece melhor performance com conjuntos de dados do Parquet existentes. Em vez de reescrever o conjunto de dados, uma operação de bootstrap pode gerar apenas os metadados, sem alterar o conjunto de dados.
Você pode usar o Athena para consultar tabelas de uma operação de bootstrap, assim como as outras tabelas baseadas em dados no Amazon S3. Na instrução `CREATE TABLE`, especifique o caminho da tabela do Hudi na cláusula `LOCATION`.
Para obter mais informações sobre como criar tabelas do Hudi usando a operação de bootstrap no Amazon EMR, consulte o artigo [New features from Apache Hudi available in Amazon EMR](https://aws.amazon.com/blogs/big-data/new-features-from-apache-hudi-available-in-amazon-emr/) (Novos recursos do Apache Hudi disponíveis no Amazon EMR) no blog da AWS sobre big data.
# Recursos adicionais
Para obter mais recursos sobre como usar o Apache Hudi com Athena, veja os recursos a seguir.
## Vídeo
O vídeo a seguir mostra como você pode usar o Amazon Athena para consultar um conjunto de dados do Apache Hudi otimizado para leitura em seu data lake baseado no Amazon S3.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/TVcreqxBaGA)
## Publicações no blog
As postagens do blog de AWS Big Data a seguir incluem descrições de como você pode usar o Apache Hudi com o Athena.
+ [Use o AWS Data Exchange para compartilhar facilmente conjuntos de dados do Apache Hudi](https://aws.amazon.com/blogs/big-data/use-aws-data-exchange-to-seamlessly-share-apache-hudi-datasets/)
+ [Criar um data lake transacional quase em tempo real baseado em Apache HUDI usando o AWS DMS, o Amazon Kinesis, o ETL de streaming do AWS Glue e visualização de dados usando o Quick](https://aws.amazon.com/blogs/big-data/create-an-apache-hudi-based-near-real-time-transactional-data-lake-using-aws-dms-amazon-kinesis-aws-glue-streaming-etl-and-data-visualization-using-amazon-quicksight/)
+ Para obter informações sobre o uso de conectores personalizados do AWS Glue e trabalhos do AWS Glue 2.0 para a criação de uma tabela do Apache Hudi que você possa consultar com o Athena, consulte [Gravar em tabelas do Apache Hudi com o uso do conector personalizado do AWS Glue](https://aws.amazon.com/blogs/big-data/writing-to-apache-hudi-tables-using-aws-glue-connector/).
+ Para acessar um artigo sobre o uso do Apache Hudi, do AWS Glue e do Amazon Athena para a criação de uma estrutura de processamento de dados para um data lake, consulte [Simplificar o processamento operacional de dados em data lakes com o uso do AWS Glue e do Apache Hudi](https://aws.amazon.com/blogs/big-data/simplify-operational-data-processing-in-data-lakes-using-aws-glue-and-apache-hudi/).
# Consultar tabelas do Apache Iceberg
É possível usar o Athena para realizar consultas de leitura, viagem no tempo, gravação e DDL em tabelas do Apache Iceberg.
[Apache Iceberg](https://iceberg.apache.org/) é um formato de tabela aberta para conjuntos de dados analíticos muito grandes. O Iceberg gerencia grandes coleções de arquivos como tabelas e suporta modernas operações de data lake analítico, como inserção, atualização, exclusão no nível do registro e consultas de viagem no tempo. A especificação do Iceberg permite uma evolução contínua da tabela, como uma evolução de esquema e partição, e é concebida para otimizar o uso no Amazon S3. O Iceberg também ajuda a garantir a correção dos dados em cenários de gravação simultâneos.
Para obter mais informações sobre o Apache Iceberg, consulte [https://iceberg.apache.org/](https://iceberg.apache.org/).
## Considerações e limitações
O suporte do Athena para tabelas Iceberg tem as seguintes considerações e limitações:
+ **Suporte à versão Iceberg** — O Athena é compatível com o Apache Iceberg versão 1.4.2.
+ **Tabelas registradas no Lake Formation**: o Athena atualmente não é compatível com operações DDL em tabelas Iceberg registradas no Lake Formation.
+ **Consultas do esquema de informações**: ao consultar o esquema de informações de tabelas Iceberg, o Athena usa metadados do S3 como fonte confiável para metadados de colunas. Isso significa que as informações das colunas são derivadas dos arquivos do S3 subjacentes, não de metadados do catálogo. Esse comportamento é diferente do de outros formatos de tabelas, em que os metadados do catálogo podem ser a principal fonte de informações das colunas.
+ **Tabelas somente com catálogo do AWS Glue**: apenas tabelas Iceberg criadas com base no catálogo do AWS Glue de acordo com as especificações definidas pela [implementação de código aberto do catálogo do Glue](https://iceberg.apache.org/docs/latest/aws/#glue-catalog) são compatíveis com o Athena.
+ **Suporte de bloqueio de tabela apenas pelo AWS Glue**: ao contrário da implementação de código aberto do catálogo do Glue, que oferece suporte ao bloqueio personalizado de plug-in, o Athena oferece suporte apenas ao bloqueio otimista do AWS Glue. Usar o Athena para modificar uma tabela do Iceberg com qualquer outra implementação de bloqueio causará perda de dados e quebra de transações.
+ **Formatos de arquivo compatíveis**: a versão 3 do mecanismo Athena oferece suporte aos formatos de arquivo do Iceberg apresentados a seguir.
+ Parquet
+ ORC
+ Avro
+ **Metadados restritos do Iceberg**: o Lake Formation não avalia as tabelas de metadados do Iceberg. Portanto, as tabelas de metadados do Iceberg serão restritas se houver algum filtro de linha ou célula do Lake Formation presente na tabela base ou se você não tiver permissões para visualizar todas as colunas na tabela base. Nesses casos, quando você consulta as tabelas de metadados do Iceberg `$partitions`, `$files`, `$manifests` e `$snapshots`, a consulta falha e você recebe um erro `AccessDeniedException`. Além disso, a coluna de metadados `$path` tem as mesmas restrições do Lake Formation e falha quando selecionada pela consulta. Todas as outras tabelas de metadados podem ser consultadas independentemente dos filtros do Lake Formation. Para obter mais informações, consulte [Tabelas de metadados](https://trino.io/docs/current/connector/iceberg.html#metadata-tables).
+ **Tabelas Iceberg v2**: o Athena só cria e opera tabelas 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.
+ **Exibição de tipos de hora sem fuso horário**: a hora e o timestamp sem tipos de fuso horário são exibidos no UTC. Se o fuso horário não for especificado em uma expressão de filtro em uma coluna de hora, o UTC será usado.
+ **Precisão dos dados relacionados ao timestamp**: embora o Iceberg seja compatível com uma precisão de microssegundos para o tipo de dados de timestamp, o Athena é compatível apenas com a precisão de milissegundos para timestamps em leituras e gravações. Para dados em colunas relacionadas a horas gravadas durante operações de compactação manual, o Athena retém somente uma precisão de milissegundos.
+ **Operações sem suporte**: as seguintes operações do Athena não são compatíveis com tabelas Iceberg.
+ [ALTER TABLE SET LOCATION](alter-table-set-location.md)
+ **Visualizações**: use `CREATE VIEW` para criar visualizações do Athena, conforme descrito em [Trabalhar com visualizações](views.md). Se você tiver interesse em usar a [especificação de visualização do Iceberg](https://github.com/apache/iceberg/blob/master/format/view-spec.md) para criar visualizações, entre em contato com [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
+ **Comandos de gerenciamento de TTF não compatíveis com o AWS Lake Formation**: embora seja possível usar o Lake Formation para gerenciar permissões de acesso de leitura para TransactionTable Formats (TTFs), como Apache Iceberg, Apache Hudi e Linux Foundation Delta Lake, não é possível usar o Lake Formation para gerenciar permissões para operações como `VACUUM`, `MERGE`, `UPDATE` ou `OPTIMIZE` com esses formatos de tabela. Para obter mais informações sobre a integração do Lake Formation com o Athena, consulte [Usar o AWS Lake Formation com o Amazon Athena](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html) no *Guia do desenvolvedor do AWS Lake Formation*.
+ **Particionar por campos aninhados** - A partição por campos aninhados não é suportada. A tentativa de fazer isso produz a mensagem NÃO SUPORTADO: *particionar por campo aninhado não é suportado: column\$1name.nested\$1field\$1name*.**
+ **Não é possível ignorar os objetos do Amazon Glacier**: se os objetos da tabela do Apache Iceberg estiverem em uma classe de armazenamento do Amazon Glacier, definir a propriedade da tabela `read_restored_glacier_objects` como `false` não surtirá efeito.
Por exemplo, suponhamos que você emita o seguinte comando:
```
ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false')
```
Para tabelas do Iceberg e do Delta Lake, o comando gera o erro Chave de propriedade da tabela não compatível: read\$1restored\$1glacier\$1objects. Para as tabelas do Hudi, o comando `ALTER TABLE` não gera erro, mas mesmo assim os objetos do Amazon Glacier não são ignorados. A execução de consultas `SELECT` após o comando `ALTER TABLE` continua a retornar todos os objetos.
Se quiser que o Athena ofereça suporte a recurso específico, envie comentários para [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
**Topics**
+ [Considerações e limitações](#querying-iceberg-considerations-and-limitations)
+ [Criar tabelas do Iceberg](querying-iceberg-creating-tables.md)
+ [Consultar dados de tabelas do Iceberg](querying-iceberg-table-data.md)
+ [Executar consultas de viagem no tempo e viagem nas versões](querying-iceberg-time-travel-and-version-travel-queries.md)
+ [Atualizar dados nas tabelas do Iceberg](querying-iceberg-updating-iceberg-table-data.md)
+ [Gerenciar tabelas do Iceberg](querying-iceberg-managing-tables.md)
+ [Evoluir o esquema de tabelas do Iceberg](querying-iceberg-evolving-table-schema.md)
+ [Executar outras operações de DDL em tabelas do Iceberg](querying-iceberg-additional-operations.md)
+ [Otimizar tabelas do Iceberg](querying-iceberg-data-optimization.md)
+ [Consultar as visões materializadas do Catálogo de Dados do AWS Glue](querying-iceberg-gdc-mv.md)
+ [Tipos de dados suportados para tabelas Iceberg no Athena](querying-iceberg-supported-data-types.md)
+ [Recursos adicionais](querying-iceberg-additional-resources.md)
# Criar tabelas do Iceberg
Para criar uma tabela Iceberg para uso no Athena, você pode usar uma instrução `CREATE TABLE` conforme documentada nesta página, ou pode usar um crawler do AWS Glue.
## Usar uma instrução CREATE TABLE
O Athena 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.
A cláusula `CREATE TABLE` do Athena cria uma tabela Iceberg sem dados. Você poderá consultar uma tabela diretamente de sistemas externos, como o Apache Spark, se a tabela usar o [catálogo do Glue de código aberto do Iceberg](https://iceberg.apache.org/docs/latest/aws/#glue-catalog). Você não precisa criar uma tabela externa.
**Atenção**
Executar `CREATE EXTERNAL TABLE` resulta na mensagem de erro External keyword not supported for table type ICEBERG (Palavra-chave externa não compatível com o tipo de tabela ICEBERG).
Para criar uma tabela Iceberg no Athena, defina a propriedade `'table_type'` da tabela como `'ICEBERG'` na cláusula `TBLPROPERTIES`, como no resumo da sintaxe a seguir.
```
CREATE TABLE
[db_name.]table_name (col_name data_type [COMMENT col_comment] [, ...] )
[PARTITIONED BY (col_name | transform, ... )]
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ( 'table_type' ='ICEBERG' [, property_name=property_value] )
```
Para obter informações sobre os tipos de dados que você pode consultar em tabelas Iceberg, consulte [Tipos de dados suportados para tabelas Iceberg no Athena](querying-iceberg-supported-data-types.md).
### Usar partições
Para criar tabelas Iceberg com partições, use a sintaxe `PARTITIONED BY`. As colunas usadas para particionamento devem ser especificadas primeiro nas declarações de colunas. O tipo de coluna não deve ser incluído dentro da cláusula `PARTITIONED BY`. Você também pode definir [transformações de partição](https://iceberg.apache.org/spec/#partition-transforms) na sintaxe `CREATE TABLE`. Para especificar várias colunas para particionamento, separe as colunas por vírgula (`,`), como no exemplo a seguir.
```
CREATE TABLE iceberg_table (id bigint, data string, category string)
PARTITIONED BY (category, bucket(16, id))
LOCATION 's3://amzn-s3-demo-bucket/your-folder/'
TBLPROPERTIES ( 'table_type' = 'ICEBERG' )
```
A tabela a seguir mostra as funções de transformação de partição disponíveis.
****
| Função | Descrição | Tipos compatíveis |
| --- | --- | --- |
| year(ts) | Partição por ano | date, timestamp |
| month(ts) | Partição por mês | date, timestamp |
| day(ts) | Partição por dia | date, timestamp |
| hour(ts) | Partição por hora | timestamp |
| bucket(N, col) | Partição por buckets N de mod de valor por hash. Esse conceito é semelhante ao bucket por hash para tabelas do Hive. | int, long, decimal, date, timestamp, string, binary |
| truncate(L, col) | Partição por valor truncada para L | int, long, decimal, string |
O Athena suporta o particionamento oculto do Iceberg. Para obter mais informações, consulte [Particionamento oculto do Iceberg](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning) na documentação do Apache Iceberg.
### Especificar propriedades das tabelas
Esta seção descreve as propriedades de tabela que você pode especificar como pares de valores-chave na cláusula `TBLPROPERTIES` da instrução `CREATE TABLE`. O Athena permite apenas uma lista predefinida de pares de valores-chave nas propriedades da tabela para criar ou alterar tabelas Iceberg. As tabelas a seguir mostram as propriedades de tabela que você pode especificar. Para obter mais informações sobre essas opções de compactação, consulte [Otimizar tabelas do Iceberg](querying-iceberg-data-optimization.md) mais adiante neste documento. Se você quiser que o Athena suporte uma propriedade específica de configuração de tabela de código aberto, envie comentários para [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
***formato***
****
| | |
| --- |--- |
| Descrição | Formato de dados do arquivo |
| Valores de propriedade permitidos | O formato de arquivo compatível e as combinações de compactação variam conforme a versão do mecanismo Athena. Para obter mais informações, consulte [Usar compactação de tabelas do Iceberg](compression-support-iceberg.md). |
| Valor padrão | parquet |
***write\$1compression***
****
| | |
| --- |--- |
| Descrição | Codec de compactação de arquivo |
| Valores de propriedade permitidos | O formato de arquivo compatível e as combinações de compactação variam conforme a versão do mecanismo Athena. Para obter mais informações, consulte [Usar compactação de tabelas do Iceberg](compression-support-iceberg.md). |
| Valor padrão | A compactação de gravação padrão varia conforme a versão do mecanismo Athena. Para obter mais informações, consulte [Usar compactação de tabelas do Iceberg](compression-support-iceberg.md). |
***optimize\$1rewrite\$1data\$1file\$1threshold***
****
| | |
| --- |--- |
| Descrição | Configuração específica de otimização de dados. Se houver menos arquivos de dados que exigem otimização do que o limite fornecido, os arquivos não serão regravados. Isso permite acumular mais arquivos de dados para produzir arquivos mais próximos do tamanho de destino e ignorar computação desnecessária para economizar custos. |
| Valores de propriedade permitidos | Um número positivo. Deve ser menor que 50. |
| Valor padrão | 5 |
***optimize\$1rewrite\$1delete\$1file\$1threshold***
****
| | |
| --- |--- |
| Descrição | Configuração específica de otimização de dados. Se houver menos arquivos de exclusão associados a um arquivo de dados do que o limite, o arquivo de dados não será regravado. Isso permite acumular mais arquivos de exclusão para cada arquivo de dados para economizar custos. |
| Valores de propriedade permitidos | Um número positivo. Deve ser menor que 50. |
| Valor padrão | 2 |
***vacuum\$1min\$1snapshots\$1to\$1keep***
****
| | |
| --- |--- |
| Descrição | Número mínimo de snapshots a serem retidos na ramificação principal de uma tabela. Esse valor tem precedência sobre a propriedade `vacuum_max_snapshot_age_seconds`. Se o mínimo restante de snapshots for mais antigo do que a idade especificada por `vacuum_max_snapshot_age_seconds`, os snapshots serão mantidos e o valor de `vacuum_max_snapshot_age_seconds` será ignorado. |
| Valores de propriedade permitidos | Um número positivo. |
| Valor padrão | 1 |
***vacuum\$1max\$1snapshot\$1age\$1seconds***
****
| | |
| --- |--- |
| Descrição | Período máximo para reter os snapshots na ramificação principal. Esse valor será ignorado se o mínimo restante de snapshots especificado por vacuum\$1min\$1snapshots\$1to\$1keep for maior que a idade especificada. Essa propriedade de comportamento da tabela corresponde à propriedade history.expire.max-snapshot-age-ms na configuração do Apache Iceberg. |
| Valores de propriedade permitidos | Um número positivo. |
| Valor padrão | 432 mil segundos (cinco dias) |
***vacuum\$1max\$1metadata\$1files\$1to\$1keep***
****
| | |
| --- |--- |
| Descrição | O número máximo de arquivos de metadados anteriores a serem retidos na ramificação principal da tabela. |
| Valores de propriedade permitidos | Um número positivo. |
| Valor padrão | 100 |
***write\$1data\$1path\$1enabled***
****
| | |
| --- |--- |
| Descrição | Quando definida como true, a tabela Iceberg é criada com a propriedade write.data.path em vez da propriedade obsoleta write.object-storage.path. Use essa opção para garantir a compatibilidade com o Iceberg 1.9.0 e versões posteriores, que não oferecem mais suporte à propriedade obsoleta. |
| Valores de propriedade permitidos | true, false |
| Valor padrão | false |
### Exemplo de instrução CREATE TABLE
O exemplo a seguir cria uma tabela do Iceberg com três colunas.
```
CREATE TABLE iceberg_table (
id int,
data string,
category string)
PARTITIONED BY (category, bucket(16,id))
LOCATION 's3://amzn-s3-demo-bucket/iceberg-folder'
TBLPROPERTIES (
'table_type'='ICEBERG',
'format'='parquet',
'write_compression'='snappy',
'optimize_rewrite_delete_file_threshold'='10'
)
```
## Usar CREATE TABLE AS SELECT (CTAS)
Para obter informações sobre a criação de uma tabela do Iceberg usando a instrução `CREATE TABLE AS`, consulte [CREATE TABLE AS](create-table-as.md), com atenção especial à seção [Propriedades da tabela CTAS](create-table-as.md#ctas-table-properties).
## Usar um crawler do AWS Glue
Você pode usar um crawler do AWS Glue para registrar automaticamente suas tabelas Iceberg no AWS Glue Data Catalog. Se quiser migrar de outro catálogo do Iceberg, você pode criar e agendar um crawler do AWS Glue e fornecer os caminhos do Amazon S3 onde as tabelas do Iceberg estão localizadas. Você pode especificar a profundidade máxima dos caminhos do Amazon S3 que o crawler do AWS Glue pode percorrer. Depois de agendar um crawler do AWS Glue, ele extrairá as informações do esquema e atualizará o AWS Glue Data Catalog com as alterações do esquema toda vez que for executado. O crawler do AWS Glue é compatível com a mesclagem de esquemas nos snapshots e atualiza o local mais recente do arquivo de metadados no AWS Glue Data Catalog. Para obter mais informações, consulte [Data Catalog and crawlers in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html).
# Consultar dados de tabelas do Iceberg
Para consultar um conjunto de dados Iceberg, use a instrução `SELECT` padrão, como a que se segue. As consultas atendem à [especificação de formato v2](https://iceberg.apache.org/spec/#format-versioning) do Apache Iceberg e realizam a mesclagem na leitura das exclusões de posição e igualdade.
```
SELECT * FROM [db_name.]table_name [WHERE predicate]
```
Para otimizar os tempos de consulta, todos os predicados são enviados para onde os dados residem.
Para obter informações sobre consultas de viagem no tempo e viagem nas versões, consulte [Executar consultas de viagem no tempo e viagem nas versões](querying-iceberg-time-travel-and-version-travel-queries.md).
## Criar e consultar visualizações com tabelas do Iceberg
Para criar e consultar visualizações do Athena em tabelas do Iceberg, use visualizações `CREATE VIEW` conforme descrito em [Trabalhar com visualizações](views.md).
Exemplo:
```
CREATE VIEW view1 AS SELECT * FROM iceberg_table
```
```
SELECT * FROM view1
```
Se você tiver interesse em usar a [especificação de visualização do Iceberg](https://github.com/apache/iceberg/blob/master/format/view-spec.md) para criar visualizações, entre em contato com [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
## Consultar metadados de tabelas do Iceberg
Em uma consulta `SELECT`, é possível usar as seguintes propriedades após *table\$1name* para consultar metadados de tabela do Iceberg:
+ **\$1files**: mostra os arquivos de dados atuais de uma tabela.
+ **\$1manifests**: mostra os manifestos do arquivo atual de uma tabela.
+ **\$1history**: mostra o histórico de uma tabela.
+ **\$1partitions**: mostra as partições atuais de uma tabela.
+ **\$1snapshots**: mostra os snapshots de uma tabela.
+ **\$1refs**: mostra as referências de uma tabela.
### Exemplos
A instrução a seguir lista os arquivos de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$files"
```
A instrução a seguir lista os manifestos de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$manifests"
```
A instrução a seguir mostra o histórico de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$history"
```
O exemplo a seguir mostra as partições de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$partitions"
```
O exemplo a seguir lista os snapshots de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$snapshots"
```
O exemplo a seguir mostra as referências de uma tabela do Iceberg.
```
SELECT * FROM "dbname"."tablename$refs"
```
## Usar o controle de acesso detalhado do Lake Formation
A versão 3 do mecanismo do Athena é compatível com o controle de acesso detalhado do Lake Formation com tabelas do Iceberg, incluindo o controle de acesso de segurança em nível de coluna e de linha. Esse controle de acesso funciona com consultas de passagem de tempo e com tabelas que realizaram a evolução do esquema. Para obter mais informações, consulte [Controle de acesso detalhado do Lake Formation e grupos de trabalho do Athena](lf-athena-limitations.md#lf-athena-limitations-fine-grained-access-control).
Se a criação da sua tabela do Iceberg ocorreu exterior ao Athena, use o [SDK do Apache Iceberg](https://iceberg.apache.org/releases/), versão 0.13.0 ou superior, para que as informações da coluna da tabela do Iceberg sejam preenchidas no AWS Glue Data Catalog. Se a tabela do Iceberg não contiver informações de coluna no AWS Glue, você poderá usar a instrução [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) do Athena ou o SDK do Iceberg mais recente para corrigir a tabela e atualizar as informações da coluna no AWS Glue.
# Executar consultas de viagem no tempo e viagem nas versões
Toda tabela Apache Iceberg mantém um manifesto versionado dos objetos do Amazon S3 que contém. Versões anteriores do manifesto podem ser usadas para consultas de viagem no tempo e de viagem nas versões.
As consultas de viagem no tempo no Athena consultam o Amazon S3 para obter dados históricos usando um snapshot consistente a partir de uma data e hora especificadas. As consultas de viagem nas versões do Athena consultam o Amazon S3 para obter dados históricos a partir de um ID de snapshot especificado.
## Consultas de viagem no tempo
Para executar uma consulta de viagem no tempo, use `FOR TIMESTAMP AS OF timestamp` após o nome da tabela na instrução `SELECT`, como no exemplo a seguir.
```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF timestamp
```
O horário do sistema a ser especificado para a viagem é um carimbo de data/hora ou uma carimbo de data/hora com um fuso horário. Se não for especificado, o Athena considera o valor como um carimbo de data/hora no horário UTC.
O exemplo a seguir de consultas de viagem no tempo selecionam dados do CloudTrail para a data e hora especificadas.
```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF TIMESTAMP '2020-01-01 10:00:00 UTC'
```
```
SELECT * FROM iceberg_table FOR TIMESTAMP AS OF (current_timestamp - interval '1' day)
```
## Consultas de viagem nas versões
Para executar uma consulta de viagem nas versões (ou seja, exibir um snapshot consistente a partir de uma versão especificada), use `FOR VERSION AS OF version` após o nome da tabela na instrução `SELECT`, como no exemplo a seguir.
```
SELECT * FROM [db_name.]table_name FOR VERSION AS OF version
```
O parâmetro *versão* é o ID do snapshot `bigint` associado a uma versão da tabela Iceberg.
O exemplo de consulta de viagem nas versões a seguir seleciona dados para a versão especificada.
```
SELECT * FROM iceberg_table FOR VERSION AS OF 949530903748831860
```
**nota**
As cláusulas `FOR SYSTEM_TIME AS OF` e `FOR SYSTEM_VERSION AS OF` na versão 2 do mecanismo do Athena foram substituídas pelas cláusulas `FOR TIMESTAMP AS OF` e `FOR VERSION AS OF` na versão 3 do mecanismo do Athena.
### Recuperar ID do snapshot
Você pode usar a classe Java [SnapshotUtil](https://iceberg.apache.org/javadoc/1.6.0/org/apache/iceberg/util/SnapshotUtil.html) fornecida pelo Iceberg para recuperar o ID do snapshot do Iceberg, como no exemplo a seguir.
```
import org.apache.iceberg.Table;
import org.apache.iceberg.aws.glue.GlueCatalog;
import org.apache.iceberg.catalog.TableIdentifier;
import org.apache.iceberg.util.SnapshotUtil;
import java.text.SimpleDateFormat;
import java.util.Date;
Catalog catalog = new GlueCatalog();
Map properties = new HashMap();
properties.put("warehouse", "s3://amzn-s3-demo-bucket/my-folder");
catalog.initialize("my_catalog", properties);
Date date = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").parse("2022/01/01 00:00:00");
long millis = date.getTime();
TableIdentifier name = TableIdentifier.of("db", "table");
Table table = catalog.loadTable(name);
long oldestSnapshotIdAfter2022 = SnapshotUtil.oldestAncestorAfter(table, millis);
```
## Combinar viagens no tempo e viagens nas versões
Você pode usar a sintaxe de viagem no tempo e viagem nas versões na mesma consulta para especificar condições diferentes de temporização e versionamento, como no exemplo a seguir.
```
SELECT table1.*, table2.* FROM
[db_name.]table_name FOR TIMESTAMP AS OF (current_timestamp - interval '1' day) AS table1
FULL JOIN
[db_name.]table_name FOR VERSION AS OF 5487432386996890161 AS table2
ON table1.ts = table2.ts
WHERE (table1.id IS NULL OR table2.id IS NULL)
```
# Atualizar dados nas tabelas do Iceberg
Os dados da tabela do Iceberg podem ser gerenciados diretamente no Athena usando as consultas `INSERT`, `UPDATE` e `DELETE`. Cada transação de gerenciamento de dados produz um novo snapshot, que pode ser consultado usando a viagem no tempo. As instruções `UPDATE` e `DELETE` seguem a especificação de [exclusão de posição](https://iceberg.apache.org/spec/#position-delete-files) no nível de linha do formato v2 do Iceberg e aplicam o isolamento do snapshot.
**nota**
No momento, o Athena SQL não oferece suporte à abordagem copy-on-write. As operações `UPDATE`, `MERGE INTO` e `DELETE FROM` sempre usam a abordagem de mesclagem na leitura com exclusões posicionais, independentemente das propriedades da tabela especificada. Caso você tenha configurado propriedades da tabela como `write.update.mode`, `write.merge.mode` e/ou `write.delete.mode` para usar copy-on-write, suas consultas não falharão, pois o Athena as ignorará e continuará usando merge-on-read.
Use os comandos a seguir para executar operações de gerenciamento de dados em tabelas Iceberg.
**Topics**
+ [INSERT INTO](querying-iceberg-insert-into.md)
+ [DELETE](querying-iceberg-delete.md)
+ [UPDATE](querying-iceberg-update.md)
+ [MERGE INTO](querying-iceberg-merge-into.md)
# INSERT INTO
Insere dados em uma tabela Iceberg. O `INSERT INTO` do Athena Iceberg, da mesma forma que as consultas `INSERT INTO` atuais em tabelas externas do Hive, é cobrado pela quantidade de dados verificados. Para inserir dados em uma tabela Iceberg, use a sintaxe a seguir, na qual *query* pode ser `VALUES (val1, val2, ...)` ou `SELECT (col1, col2, …) FROM [db_name.]table_name WHERE predicate`. Para obter detalhes de sintaxe e semântica do SQL, consulte [INSERT INTO](insert-into.md).
```
INSERT INTO [db_name.]table_name [(col1, col2, …)] query
```
Os exemplos a seguir inserem valores na tabela `iceberg_table`.
```
INSERT INTO iceberg_table VALUES (1,'a','c1')
```
```
INSERT INTO iceberg_table (col1, col2, ...) VALUES (val1, val2, ...)
```
```
INSERT INTO iceberg_table SELECT * FROM another_table
```
# DELETE
O `DELETE` do Athena Iceberg grava arquivos de exclusão da posição do Iceberg em uma tabela. Essa operação é conhecida como uma exclusão mesclar na leitura. Em contraste com uma exclusão copiar na gravação, a exclusão mesclar na leitura é mais eficiente porque não grava os dados do arquivo novamente. Ao ler dados do Iceberg, o Athena mescla os arquivos de exclusão da posição do Iceberg com arquivos de dados para produzir a visualização mais recente de uma tabela. Para remover esses arquivos de exclusão de posição, você pode executar a [ação de compactação REWRITE DATA](querying-iceberg-data-optimization.md#querying-iceberg-data-optimization-rewrite-data-action). As operações `DELETE` são cobradas pela quantidade de dados verificados. Para ver a sintaxe, consulte [DELETE](delete-statement.md).
O exemplo a seguir exclui as linhas de `iceberg_table` que têm `c3` como o valor para `category`.
```
DELETE FROM iceberg_table WHERE category='c3'
```
# UPDATE
O `UPDATE` do Athena Iceberg grava arquivos de exclusão da posição do Iceberg e linhas recém-atualizadas como arquivos de dados na mesma transação. O `UPDATE` pode ser considerado como uma combinação de `INSERT INTO` e `DELETE`. As operações `UPDATE` são cobradas pela quantidade de dados verificados. Para ver a sintaxe, consulte [UPDATE](update-statement.md).
O exemplo a seguir atualiza os valores especificados na tabela `iceberg_table`.
```
UPDATE iceberg_table SET category='c2' WHERE category='c1'
```
# MERGE INTO
Atualiza, exclui ou insere linhas de forma condicional em uma tabela do Iceberg. Uma única instrução pode combinar ações de atualização, exclusão e inserção. Para ver a sintaxe, consulte [MERGE INTO](merge-into-statement.md).
**nota**
`MERGE INTO` é transacional e é compatível somente com tabelas do Apache Iceberg na versão 3 do mecanismo do Athena.
O exemplo a seguir exclui todos os clientes da tabela `t` que estão na tabela de origem `s`.
```
MERGE INTO accounts t USING monthly_accounts_update s
ON t.customer = s.customer
WHEN MATCHED
THEN DELETE
```
O exemplo a seguir atualiza a tabela de destino `t` com as informações do cliente presentes na tabela de origem `s`. Para linhas de clientes na tabela `t` que têm linhas de clientes correspondentes na tabela `s`, o exemplo incrementa as aquisições na tabela t. Se a tabela `t` não corresponder a uma linha de cliente na tabela `s`, o exemplo irá inserir a linha de cliente da tabela `s` na tabela`t` .
```
MERGE INTO accounts t USING monthly_accounts_update s
ON (t.customer = s.customer)
WHEN MATCHED
THEN UPDATE SET purchases = s.purchases + t.purchases
WHEN NOT MATCHED
THEN INSERT (customer, purchases, address)
VALUES(s.customer, s.purchases, s.address)
```
O exemplo a seguir atualiza condicionalmente a tabela de destino `t` com informações presentes na tabela de origem `s`. O exemplo exclui qualquer linha de destino correspondente cujo endereço de origem seja “Centreville”. Para todas as outras linhas correspondentes, o exemplo adiciona as aquisições da origem e define o endereço de destino como o endereço da origem. Se não houver correspondência na tabela de destino, o exemplo irá inserir a linha da tabela de origem.
```
MERGE INTO accounts t USING monthly_accounts_update s
ON (t.customer = s.customer)
WHEN MATCHED AND s.address = 'Centreville'
THEN DELETE
WHEN MATCHED
THEN UPDATE
SET purchases = s.purchases + t.purchases, address = s.address
WHEN NOT MATCHED
THEN INSERT (customer, purchases, address)
VALUES(s.customer, s.purchases, s.address)
```
# Gerenciar tabelas do Iceberg
O Athena oferece suporte às operações DDL a seguir para tabelas Iceberg.
**Topics**
+ [ALTER TABLE RENAME](querying-iceberg-alter-table-rename.md)
+ [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md)
+ [ALTER TABLE UNSET TBLPROPERTIES](querying-iceberg-alter-table-unset-properties.md)
+ [DESCRIBE](querying-iceberg-describe-table.md)
+ [DESCARTAR TABELA](querying-iceberg-drop-table.md)
+ [SHOW CREATE TABLE](querying-iceberg-show-create-table.md)
+ [SHOW TBLPROPERTIES](querying-iceberg-show-table-properties.md)
# ALTER TABLE RENAME
Renomeia uma tabela.
Como os metadados de uma tabela Iceberg são armazenados no Amazon S3, você pode atualizar o banco de dados e o nome da tabela de uma tabela Iceberg gerenciada sem afetar as informações de tabela subjacentes.
## Resumo
```
ALTER TABLE [db_name.]table_name RENAME TO [new_db_name.]new_table_name
```
## Exemplo
```
ALTER TABLE my_db.my_table RENAME TO my_db2.my_table2
```
# ALTER TABLE SET TBLPROPERTIES
Adiciona propriedades a uma tabela Iceberg e define os valores atribuídos a elas.
De acordo com as [especificações do Iceberg](https://iceberg.apache.org/#spec/#table-metadata-fields), as propriedades de tabela são armazenadas no arquivo de metadados da tabela Iceberg, e não em AWS Glue. O Athena não aceita propriedades de tabela personalizadas. Consulte a seção [Especificar propriedades das tabelas](querying-iceberg-creating-tables.md#querying-iceberg-table-properties) para ver os pares de chave-valor permitidos. Você também pode usar `ALTER TABLE SET TBLPROPERTIES` e `ALTER TABLE UNSET TBLPROPERTIES` para definir ou remover as propriedades da tabela `write.data.path` e `write.object-storage.path` do Iceberg. Se você quiser que o Athena suporte uma propriedade específica de configuração de tabela de código aberto, envie comentários para [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
## Resumo
```
ALTER TABLE [db_name.]table_name SET TBLPROPERTIES ('property_name' = 'property_value' [ , ... ])
```
## Exemplo
```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
'format'='parquet',
'write_compression'='snappy',
'optimize_rewrite_delete_file_threshold'='10'
)
```
O exemplo a seguir define a propriedade `write.data.path` em uma tabela Iceberg existente.
```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
'write.data.path'='s3://amzn-s3-demo-bucket/your-folder/data'
)
```
# ALTER TABLE UNSET TBLPROPERTIES
Descarta as propriedades existentes de uma tabela Iceberg.
## Resumo
```
ALTER TABLE [db_name.]table_name UNSET TBLPROPERTIES ('property_name' [ , ... ])
```
## Exemplo
```
ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write_compression')
```
O exemplo a seguir remove a propriedade `write.data.path` de uma tabela Iceberg.
```
ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write.data.path')
```
# DESCRIBE
Descreve informações da tabela.
## Resumo
```
DESCRIBE [FORMATTED] [db_name.]table_name
```
Quando a opção `FORMATTED` é especificada, a saída exibe informações adicionais, como localização e propriedades da tabela.
## Exemplo
```
DESCRIBE iceberg_table
```
# DESCARTAR TABELA
Descarta uma tabela Iceberg.
**Atenção**
Como as tabelas Iceberg são consideradas tabelas gerenciadas no Athena, descartar uma tabela Iceberg remove todos os dados na tabela.
## Resumo
```
DROP TABLE [IF EXISTS] [db_name.]table_name
```
## Exemplo
```
DROP TABLE iceberg_table
```
# SHOW CREATE TABLE
Exibe uma declaração DDL `CREATE TABLE` que pode ser usada para recriar a tabela Iceberg no Athena. Se o Athena não puder reproduzir a estrutura da tabela (por exemplo, quando a tabela tiver propriedades personalizadas especificadas), um erro UNSUPPORTED (NÃO SUPORTADO) será gerado.
## Resumo
```
SHOW CREATE TABLE [db_name.]table_name
```
## Exemplo
```
SHOW CREATE TABLE iceberg_table
```
# SHOW TBLPROPERTIES
Mostra uma ou mais propriedades de uma tabela Iceberg. Somente as propriedades de tabela compatíveis com o Athena são mostradas.
## Resumo
```
SHOW TBLPROPERTIES [db_name.]table_name [('property_name')]
```
## Exemplo
```
SHOW TBLPROPERTIES iceberg_table
```
# Evoluir o esquema de tabelas do Iceberg
As atualizações de esquema do Iceberg são alterações somente de metadados. Nenhum arquivo de dados é alterado quando você executa uma atualização de esquema.
O formato Iceberg suporta as seguintes alterações na evolução do esquema:
+ **Adicionar**: adiciona uma nova coluna a uma tabela ou a uma `struct` aninhada.
+ **Descartar**: remove uma coluna existente de uma tabela ou `struct` aninhada.
+ **Renomear**: renomeia uma coluna ou campo existente em uma `struct` aninhada.
+ **Reordenar**: altera a ordem das colunas.
+ **Promoção de tipo**: amplia o tipo de uma coluna, um campo `struct`, uma chave `map`, um valor `map` ou um elemento `list`. Atualmente, há suporte para os seguintes casos nas tabelas Iceberg:
+ inteiro para grande inteiro
+ float para double
+ aumento da precisão de um tipo decimal
É possível usar instruções do DDL nesta seção para modificar o esquema de tabelas do Iceberg.
**Topics**
+ [ALTER TABLE ADD COLUMNS](querying-iceberg-alter-table-add-columns.md)
+ [ALTER TABLE DROP COLUMN](querying-iceberg-alter-table-drop-column.md)
+ [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md)
+ [SHOW COLUMNS](querying-iceberg-show-columns.md)
# ALTER TABLE ADD COLUMNS
Adiciona uma ou mais colunas a uma tabela Iceberg existente.
## Resumo
```
ALTER TABLE [db_name.]table_name ADD COLUMNS (col_name data_type [,...])
```
## Exemplos
O exemplo a seguir adiciona uma coluna `comment` do tipo `string` em uma tabela Iceberg.
```
ALTER TABLE iceberg_table ADD COLUMNS (comment string)
```
O exemplo a seguir adiciona uma coluna `point` do tipo `struct` em uma tabela Iceberg.
```
ALTER TABLE iceberg_table
ADD COLUMNS (point struct)
```
O exemplo a seguir adiciona uma coluna `points`, que é uma matriz de structs , em uma tabela Iceberg.
```
ALTER TABLE iceberg_table
ADD COLUMNS (points array>)
```
# ALTER TABLE DROP COLUMN
Descarta uma coluna de uma tabela Iceberg existente.
## Resumo
```
ALTER TABLE [db_name.]table_name DROP COLUMN col_name
```
## Exemplo
```
ALTER TABLE iceberg_table DROP COLUMN userid
```
# ALTER TABLE CHANGE COLUMN
Altera o nome, tipo, ordem ou comentário de uma coluna em uma tabela do Iceberg.
**nota**
`ALTER TABLE REPLACE COLUMNS`Não há suporte ao . Como `REPLACE COLUMNS` remove todas as colunas e, em seguida, adiciona colunas novas, ele não é compatível no Iceberg. `CHANGE COLUMN` é a sintaxe preferida para a evolução do esquema.
## Resumo
```
ALTER TABLE [db_name.]table_name
CHANGE [COLUMN] col_old_name col_new_name column_type
[COMMENT col_comment] [FIRST|AFTER column_name]
```
## Exemplo
```
ALTER TABLE iceberg_table CHANGE comment blog_comment string AFTER id
```
# SHOW COLUMNS
Mostra as colunas em uma tabela.
## Resumo
```
SHOW COLUMNS (FROM|IN) [db_name.]table_name
```
## Exemplo
```
SHOW COLUMNS FROM iceberg_table
```
# Executar outras operações de DDL em tabelas do Iceberg
Além das operações de evolução de esquema descritas em [Evoluir o esquema de tabelas do Iceberg](querying-iceberg-evolving-table-schema.md), você também pode realizar as operações de DDL a seguir nas tabelas do Apache Iceberg no Athena.
## Operações no banco de dados
Quando você usa [DROP DATABASE](drop-database.md) com a opção `CASCADE`, todos os dados da tabela Iceberg também são removidos. As operações DDL a seguir não têm efeito nas tabelas Iceberg.
+ [CREATE DATABASE](create-database.md)
+ [ALTER DATABASE SET DBPROPERTIES](alter-database-set-dbproperties.md)
+ [SHOW DATABASES](show-databases.md)
+ [SHOW TABLES](show-tables.md)
+ [SHOW VIEWS](show-views.md)
## Operações relacionadas à partição
Como as tabelas Iceberg usam o [particionamento oculto](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning), você não precisa trabalhar diretamente com partições físicas. Por isso, as tabelas Iceberg no Athena não são compatíveis com as seguintes operações DDL relacionadas à partição:
+ [SHOW PARTITIONS](show-partitions.md)
+ [ALTER TABLE ADD PARTITION](alter-table-add-partition.md)
+ [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md)
+ [ALTER TABLE RENAME PARTITION](alter-table-rename-partition.md)
Se quiser ver a [evolução da partição](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution) no Athena, envie comentários para [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com).
## Descarregar tabelas do Iceberg
As tabelas Iceberg podem ser descarregadas em arquivos em uma pasta no Amazon S3. Para mais informações, consulte [UNLOAD](unload.md).
## MSCK REPAIR
Como as tabelas Iceberg acompanham as informações de layout da tabela, executar [MSCK REPAIR TABLE](msck-repair-table.md), como se faz com tabelas do Hive, não é necessário nem compatível.
# Otimizar tabelas do Iceberg
O Athena fornece vários recursos de otimização para melhorar a performance das consultas nas tabelas do Apache Iceberg. À medida que os dados se acumulam, as consultas podem se tornar menos eficientes devido ao aumento da sobrecarga de processamento de arquivos e ao custo computacional de aplicar exclusões no nível de linha armazenadas nos arquivos de exclusão do Iceberg. Para enfrentar esses desafios, o Athena é compatível com os operadores manuais de compactação e vacuum para otimizar a estrutura da tabela. O Athena também trabalha com estatísticas do Iceberg para permitir a otimização de consultas com base em custos e a indexação de colunas do Parquet para o descarte preciso dos dados durante a execução da consulta. Esses recursos trabalham juntos para reduzir o tempo de execução da consulta, minimizar a verificação de dados e reduzir os custos. Este tópico descreve como usar esses recursos de otimização para manter consultas de alta performance em suas tabelas do Iceberg.
## OPTIMIZE
A ação de compactação `OPTIMIZE table REWRITE DATA` regrava os arquivos de dados em um layout mais otimizado com base no tamanho e no número de delete files associados. Para obter detalhes sobre a sintaxe e as propriedades da tabela, consulte [OPTIMIZE](optimize-statement.md).
### Exemplo
O exemplo a seguir mescla delete files em arquivos de dados e produz arquivos próximos ao tamanho do arquivo de destino, em que o valor de `category` é `c1`.
```
OPTIMIZE iceberg_table REWRITE DATA USING BIN_PACK
WHERE category = 'c1'
```
## VACUUM
`VACUUM` executa a [expiração do snapshot](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) e a [remoção de arquivos órfãos](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files). Essas ações reduzem o tamanho dos metadados e removem os arquivos que não estão no estado atual da tabela e que também são mais antigos do que o período de retenção especificado para a tabela. Para obter detalhes sobre a sintaxe, consulte [VACUUM](vacuum-statement.md).
### Exemplo
O exemplo a seguir usa uma propriedade de tabela para configurar a tabela `iceberg_table` para reter os últimos três dias de dados e, em seguida, usa `VACUUM` para expirar os snapshots antigos e remover os arquivos órfãos da tabela.
```
ALTER TABLE iceberg_table SET TBLPROPERTIES (
'vacuum_max_snapshot_age_seconds'='259200'
)
VACUUM iceberg_table
```
## Usar estatísticas de tabelas do Iceberg
O otimizador baseado em custos do Athena usa estatísticas do Iceberg para produzir planos de consulta ideais. Quando as estatísticas são geradas para suas tabelas do Iceberg, o Athena usa automaticamente essas informações para tomar decisões inteligentes sobre a ordenação de junções, os filtros e o comportamento de agregação, geralmente melhorando a performance das consultas e reduzindo custos.
As estatísticas do Iceberg são ativadas por padrão quando você usa as Tabelas do S3. Para outras tabelas do Iceberg, o Athena usa a propriedade `use_iceberg_statistics` da tabela para determinar se as estatísticas devem ser usadas para a otimização baseada em custos. Para começar, consulte [Otimizar a performance da consulta usando estatísticas de coluna](https://docs.aws.amazon.com//glue/latest/dg/column-statistics.html) no *Guia do usuário do AWS Glue*, ou use o [console do Athena](https://docs.aws.amazon.com/athena/latest/ug/cost-based-optimizer.html) para gerar estatísticas sob demanda em suas tabelas do Iceberg.
## Usar indexação de colunas do Parquet
A indexação de colunas do Parquet possibilita que o Athena realize um descarte de dados mais preciso durante a execução da consulta, aproveitando as estatísticas mínimo/máximo no nível da página, além das estatísticas no nível do grupo de linhas. Isso permite que o Athena pule páginas desnecessárias em grupos de linhas, reduzindo significativamente a quantidade de dados verificados e melhorando a performance das consultas. Ele funciona melhor para consultas com predicados de filtro seletivo em colunas classificadas, melhorando o tempo de execução e a eficiência da verificação de dados, ao mesmo tempo em que reduz a quantidade de dados que a Athena precisa ler no Amazon S3.
O Athena usará índices de coluna do Parquet por padrão com Tabelas do S3 se os índices de coluna estiverem presentes nos arquivos Parquet subjacentes. Para outras tabelas do Iceberg, o Athena usa a propriedade `use_iceberg_parquet_column_index` para determinar se deve utilizar os índices das colunas no arquivo Parquet. Defina essa propriedade da tabela usando o console do AWS Glue ou a API `UpdateTable`.
# Consultar as visões materializadas do Catálogo de Dados do AWS Glue
O Athena permite que você consulte as visões materializadas do Catálogo de Dados do AWS Glue. As visões materializadas do Catálogo de Dados do Glue armazenam resultados pré-processados de consultas SQL como tabelas do Apache Iceberg.
Quando você cria visões materializadas do Catálogo de Dados do Glue usando o Apache Spark no Amazon EMR ou AWS Glue, as definições da visão e os metadados são armazenados no Catálogo de Dados do AWS Glue. Os resultados pré-processados são armazenados como tabelas do Apache Iceberg no Amazon S3. Você pode consultar essas visões materializadas do Athena usando instruções `SELECT` de SQL padrão, da mesma forma que consultaria tabelas normais do Iceberg.
## Pré-requisitos
Antes de consultar visões materializadas no Athena, verifique o seguinte:
+ A visão materializada existe no Catálogo de Dados do AWS Glue e foi criada usando o Apache Spark (versão 7.12.0 do Amazon EMR ou posterior, ou versão 5.1 do AWS Glue ou posterior)
+ Para consultar visões materializadas no Athena, você precisa das seguintes permissões do AWS Lake Formation:
+ Permissão `SELECT` na visão materializada
+ Permissão `DESCRIBE` na visão materializada
+ Acesso ao local subjacente do Amazon S3 em que os dados da visão materializada são armazenados
+ Os dados subjacentes da visão materializada são armazenados em buckets da Tabela do Amazon S3 ou em buckets de uso geral do Amazon S3
+ Você tem acesso ao banco de dados do Catálogo de Dados do AWS Glue contendo a visão materializada
+ Para visões materializadas armazenadas em buckets das Tabelas do Amazon S3, certifique-se de que seu perfil do IAM tenha as permissões necessárias para acessar o catálogo das Tabelas do S3.
## Considerações e limitações
+ O Athena não é compatível com as seguintes operações para visões materializadas: `ALTER`, `CREATE MATERIALIZED VIEW`, `REFRESH MATERIALIZED VIEW`, `DROP`, `INSERT`, `UPDATE`, `MERGE`, `DELETE`, `OPTIMIZE`, `VACUUM`. Para criar visões materializadas, use o Apache Spark no Amazon EMR ou o AWS Glue. As operações de atualização devem ser realizadas por meio da API do Catálogo de Dados do AWS Glue ou do Apache Spark. Modifique as visões materializadas usando o Apache Spark.
## Consultar visões materializadas
O Athena trata as visões materializadas como tabelas padrão do Iceberg para operações de leitura, permitindo que você acesse os dados pré-processados sem exigir alterações especiais na sintaxe ou na configuração.
Para consultar uma visão materializada no Athena, use as instruções `SELECT` padrão:
```
SELECT * FROM my_database.sales_summary_mv;
```
Você pode aplicar filtros, agregações e junções da mesma forma que faria com tabelas normais:
```
SELECT
region,
SUM(total_sales) as sales_total
FROM my_database.sales_summary_mv
WHERE year = 2025
GROUP BY region
ORDER BY sales_total DESC;
```
## Operações compatíveis
O Athena é compatível com as seguintes operações nas visões materializadas:
+ Consultas `SELECT`: leia dados de visões materializadas usando instruções `SELECT` de SQL padrão
+ `DESCRIBE`: visualize o esquema e os metadados das visões materializadas
+ `SHOW TABLES`: liste as visões materializadas junto com outras tabelas em um banco de dados
+ Operações `JOIN`: junte as visões materializadas com outras tabelas ou visões
+ Filtragem e agregação - aplique cláusulas `WHERE`, `GROUP BY` e funções de agregação
# Tipos de dados suportados para tabelas Iceberg no Athena
O Athena pode consultar tabelas Iceberg que contêm os seguintes tipos de dados:
```
binary
boolean
date
decimal
double
float
int
list
long
map
string
struct
timestamp without time zone
```
Para obter mais informações sobre tipos de tabela Iceberg, consulte a [página de esquemas para Iceberg](https://iceberg.apache.org/docs/latest/schemas/) na documentação do Apache.
A tabela a seguir mostra a relação entre tipos de dados do Athena e tipos de dados de tabela Iceberg.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/athena/latest/ug/querying-iceberg-supported-data-types.html)
Para obter mais informações sobre tipos de dados no Athena, consulte [Tipos de dados no Amazon Athena](data-types.md).
# Recursos adicionais
O artigo a seguir está na documentação de Recomendações da AWS.
+ [Trabalhar com tabelas do Apache Iceberg usando o SQL do Amazon Athena](https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/iceberg-athena.html)
Para artigos detalhados sobre como usar o Athena com tabelas do Apache Iceberg, consulte as seguintes postagens no *AWSBlog de Big Data*.
+ [Implemente um processo CDC sem servidor com o Apache Iceberg usando o Amazon DynamoDB e o Amazon Athena](https://aws.amazon.com/blogs/big-data/implement-a-serverless-cdc-process-with-apache-iceberg-using-amazon-dynamodb-and-amazon-athena/)
+ [Acelere a engenharia de atributos de ciência de dados em lagos de dados transacionais usando o Amazon Athena com o Apache Iceberg](https://aws.amazon.com/blogs/big-data/accelerate-data-science-feature-engineering-on-transactional-data-lakes-using-amazon-athena-with-apache-iceberg/)
+ [Crie um data lake no Apache Iceberg usando o Amazon Athena, o Amazon EMR e AWS Glue](https://aws.amazon.com/blogs/big-data/build-an-apache-iceberg-data-lake-using-amazon-athena-amazon-emr-and-aws-glue/)
+ [Execute inserções em um data lake usando o Amazon Athena e o Apache Iceberg](https://aws.amazon.com/blogs/big-data/perform-upserts-in-a-data-lake-using-amazon-athena-and-apache-iceberg/)
+ [Crie um data lake transacional usando o Apache Iceberg, AWS Glue e compartilhamentos de dados entre contas usando o AWS Lake Formation e o Amazon Athena](https://aws.amazon.com/blogs/big-data/build-a-transactional-data-lake-using-apache-iceberg-aws-glue-and-cross-account-data-shares-using-aws-lake-formation-and-amazon-athena/)
+ [Use o Apache Iceberg em um data lake para oferecer suporte ao processamento incremental de dados](https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/)
+ [Crie um data lake Apache Iceberg em tempo real alinhado ao GDPR](https://aws.amazon.com/blogs/big-data/build-a-real-time-gdpr-aligned-apache-iceberg-data-lake/)
+ [Automatize a replicação de fontes relacionais em um data lake transacional com o Apache Iceberg e AWS Glue](https://aws.amazon.com/blogs/big-data/automate-replication-of-relational-sources-into-a-transactional-data-lake-with-apache-iceberg-and-aws-glue/)
+ [Interaja com tabelas do Apache Iceberg usando o Amazon Athena e permissões refinadas entre contas usando AWS Lake Formation](https://aws.amazon.com/blogs/big-data/interact-with-apache-iceberg-tables-using-amazon-athena-and-cross-account-fine-grained-permissions-using-aws-lake-formation/)
+ [Crie um data lake transacional na tecnologia sem servidor com o Apache Iceberg, o Amazon EMR Sem Servidor e o Amazon Athena](https://aws.amazon.com/blogs/big-data/build-a-serverless-transactional-data-lake-with-apache-iceberg-amazon-emr-serverless-and-amazon-athena/)