O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Uso de tabelas do Apache Iceberg com o Amazon Redshift **nota** Para obter o melhor desempenho ao usar tabelas do Apache Iceberg com o Amazon Redshift, você deve gerar estatísticas de colunas para as tabelas que estão usando o AWS Glue. Para ter mais informações, consulte [Gerar estatísticas de colunas para tabelas Iceberg](https://docs.aws.amazon.com/glue/latest/dg/iceberg-generate-column-stats.html) no *Guia do desenvolvedor do AWS Glue*. Este tópico descreve como utilizar tabelas no formato Apache Iceberg com o Redshift Spectrum ou o Redshift sem servidor. O Apache Iceberg é um formato de alta performance para grandes tabelas analíticas. É possível usar o Redshift Spectrum ou o Redshift sem servidor para consultar tabelas do Apache Iceberg catalogadas no AWS Glue Data Catalog. O Apache Iceberg é um formato de tabela de código aberto para data lakes. Para obter mais informações, consulte [Apache Iceberg](https://iceberg.apache.org/) na documentação do Apache Iceberg. O Amazon Redshift fornece consistência transacional para consultar tabelas do Apache Iceberg. É possível manipular os dados nas tabelas usando serviços compatíveis com ACID (atomicidade, consistência, isolamento, durabilidade), como Amazon Athena e Amazon EMR, enquanto executa consultas usando o Amazon Redshift. O Amazon Redshift pode usar as estatísticas da tabela armazenadas nos metadados do Apache Iceberg para otimizar os planos de consulta e reduzir a verificação de arquivos durante o processamento da consulta. Com o Amazon Redshift SQL, é possível unir tabelas do Redshift com tabelas de data lake. Como começar a usar tabelas do Iceberg com o Amazon Redshift: 1. Crie uma tabela do Apache Iceberg em um banco de dados do AWS Glue Data Catalog usando um serviço compatível, como Amazon Athena ou Amazon EMR. Para criar uma tabela do Iceberg usando o Athena, consulte [Usar tabelas do Apache Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html) no *Guia do usuário do Amazon Athena*. 1. Crie um cluster do Amazon Redshift ou um grupo de trabalho do Redshift sem servidor com um perfil do IAM associado que permita o acesso ao data lake. Consulte informações sobre como criar clusters ou grupos de trabalho em [Clusters provisionados do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) e em [Criar um data warehouse com o Amazon Redshift sem servidor](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html) no *Guia de conceitos básicos do Amazon Redshift*. 1. Conecte-se ao cluster ou grupo de trabalho usando o editor de consultas v2 ou um cliente SQL de terceiros. Para ter informações sobre como se conectar usando o Editor de Consultas v2, consulte [Conectar-se a um data warehouse do Amazon Redshift usando ferramentas de cliente SQL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html) no *Guia de gerenciamento do Amazon Redshift*. 1. Crie um esquema externo no banco de dados do Amazon Redshift para um banco de dados específico do Catálogo de Dados que inclui as tabelas do Iceberg. Para obter mais informações sobre como criar um esquema externo, consulte [Esquemas externos no Amazon Redshift Spectrum](c-spectrum-external-schemas.md). 1. Execute consultas SQL para acessar as tabelas do Iceberg no esquema externo que você criou. ## Considerações ao usar tabelas do Apache Iceberg com o Amazon Redshift Considere o seguinte ao usar o Amazon Redshift com tabelas do Iceberg: + **Suporte à versão do Iceberg**: o Amazon Redshift é compatível com a execução de consultas nas seguintes versões das tabelas do Iceberg: + A versão 1, que define como tabelas analíticas grandes são gerenciadas usando arquivos de dados imutáveis. + A versão 2 adiciona a capacidade de dar suporte a atualizações e exclusões no nível da linha, ao mesmo tempo em que mantém os arquivos de dados existentes inalterados e processa alterações de dados da tabela usando arquivos de exclusão. Para saber a diferença entre as tabelas da versão 1 e da versão 2, consulte [Format version changes](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) na documentação do Apache Iceberg. + **Adicionar partições**: você não precisa adicionar partições manualmente a tabelas do Apache Iceberg. Novas partições nas tabelas do Apache Iceberg são detectadas automaticamente pelo Amazon Redshift e nenhuma operação manual é necessária para atualizar as partições na definição da tabela. As alterações na especificação da partição também são aplicadas automaticamente às consultas sem nenhuma intervenção do usuário. + **Ingestão de dados do Iceberg no Amazon Redshift**: é possível usar os comandos INSERT INTO ou CREATE TABLE AS para importar dados da tabela do Iceberg para uma tabela local do Amazon Redshift. No momento, é possível usar o comando COPY para ingerir o conteúdo de uma tabela do Apache Iceberg em uma tabela local do Amazon Redshift. + **Visões materializadas**: você pode criar visões materializadas em tabelas do Apache Iceberg como qualquer outra tabela externa no Amazon Redshift. As mesmas considerações para outros formatos de tabela de data lake se aplicam às tabelas do Apache Iceberg. No momento, não é possível usar regravação automática de consultas e visões materializadas automáticas em tabelas de data lake. + **Controle de acesso detalhado do AWS Lake Formation**: o Amazon Redshift permite um controle de acesso detalhado do AWS Lake Formation em tabelas do Apache Iceberg. + **Parâmetros de tratamento de dados definidos pelo usuário**: o Amazon Redshift permite parâmetros de tratamento de dados definidos pelo usuário nas tabelas do Apache Iceberg. Você usa parâmetros de tratamento de dados definidos pelo usuário em arquivos existentes para personalizar os dados que estão sendo consultados em tabelas externas e evitar erros de verificação. Esses parâmetros fornecem recursos para lidar com incompatibilidades entre o esquema da tabela e os dados reais nos arquivos. Você também pode usar parâmetros de tratamento de dados definidos pelo usuário nas tabelas do Apache Iceberg. + **Perguntas sobre viagens no tempo**: no momento, as consultas de viagem no tempo não são compatível com tabelas do Apache Iceberg. + **Preços**: ao acessar tabelas do Iceberg por meio de um cluster, você recebe a cobrança segundo os preços do Redshift Spectrum. Ao acessar as tabelas do Iceberg por meio de um grupo de trabalho, você recebe a cobrança segundo os preços do Redshift com tecnologia sem servidor. Para obter informações sobre o preço do Redshift Spectrum e do Redshift sem servidor, consulte [Preço do Amazon Redshift](https://aws.amazon.com/redshift/pricing/). + **Armazenamento em cache de metadados**: esse armazenamento pressupõe que os arquivos de metadados são imutáveis com base na [especificação do Iceberg](https://iceberg.apache.org/spec/#file-system-operations). A imutabilidade do arquivo de metadados é um requisito para a integridade dos dados no Amazon Redshift. + **Identidade federada**: a identidade federada não é aceita ao gravar em tabelas do Apache Iceberg. Isso inclui o uso da palavra-chave SESSION para o parâmetro IAM\$1ROLE ao criar esquemas externos. Para acessar mais informações sobre os parâmetros IAM\$1ROLE, consulte [CREATE EXTERNAL SCHEMA](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html). # Tipos de dados compatíveis com tabelas do Apache Iceberg Este tópico descreve os tipos de dados compatíveis que o Redshift Spectrum pode ler em tabelas no formato Apache Iceberg. O Amazon Redshift pode consultar tabelas do 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 ``` Ao criar e definir uma tabela do Iceberg, use os nomes dos tipos de dados do Amazon Redshift na instrução SQL. O Redshift os associa automaticamente aos tipos do iceberg correspondentes. Para obter mais informações sobre tipos de dados do Iceberg, consulte [Esquemas para o Iceberg](https://iceberg.apache.org/docs/latest/schemas/) na documentação do Apache Iceberg. Ao ler as tabelas do Iceberg, os tipos de dados do Iceberg são associados nos tipos de dados do Redshift, conforme mostrado na tabela abaixo: **** | Tipo do Iceberg | Tipo do Amazon Redshift | Observações | | --- | --- | --- | | boolean | boolean | - | | - | tinyint | Não é aceito em tabelas do Iceberg. | | - | smallint | Não é aceito em tabelas do Iceberg. | | int | int | - | | long | bigint | - | | double | double precision | - | | float | real | - | | decimal(P, S) | decimal(P, S) | P é precisão, S é escala. | | - | char | Não é aceito em tabelas do Iceberg. | | string | varchar(16384) | Strings maiores do que 16384 estão truncadas para 16384. | | binary | varbyte(64000) | - | | date | date | - | | time | - | - | | timestamp | timestamp | - | | timestamptz | timestampz | - | | list | SUPER | - | | map | SUPER | - | | struct<...> | SUPER | - | | fixed(L) | - | No momento, o tipo fixed(L) não é aceito no Redshift Spectrum. | | uuid | - | No momento, o tipo uuid não é aceito no Redshift Spectrum. | | variant | - | O Amazon Redshift não comporta o Iceberg V3. | | geometry | - | O Amazon Redshift não comporta o Iceberg V3. | | geography | - | O Amazon Redshift não comporta o Iceberg V3. | | timestamp\$1ns | - | O Amazon Redshift não comporta o Iceberg V3. | | timestamptz\$1ns | - | O Amazon Redshift não comporta o Iceberg V3. | | Unknown | - | O Amazon Redshift não comporta o Iceberg V3. | Os tipos de dados a seguir são aceitos ao criar tabelas do Iceberg a partir do Redshift. Os tipos de dados do Redshift são associados em tipos de dados do Iceberg, conforme mostrado na tabela a seguir. **** | Tipo do Amazon Redshift | Alias do Amazon Redshift | Tipo do Iceberg | Observações | | --- | --- | --- | --- | | integer | int, int4 | int | - | | bigint | int8 | long | - | | decimal | numeric | decimal(p,S) | - | | real | float4 | float | - | | double precision | float8, float | double | - | | varchar | charactter varying,nvarchar, text | string | O tipo de dados varchar(n) não é aceito ao criar uma tabela do Iceberg. | | date | - | date | - | | timestamp | - | timestamp | - | | timestamptz | - | timestamptz | - | | boolean | - | boolean | - | Ao gravar em tabelas do Iceberg, além dos tipos de dados mencionados na tabela anterior, alguns tipos de dados de origem são promovidos para seus tipos do Iceberg aceitos, conforme mostrado na tabela a seguir. | Tipo do Amazon Redshift | Tipo do Iceberg | | --- | --- | | `tinyint` | `int` | | `smallint` | `int` | | `varchar(n)` | `string` | A tentativa de usar tipos de dados não aceitos vai gerar erros de sintaxe. Ao criar uma tabela do Iceberg com uma cláusula `CREATE TABLE AS SELECT`, você pode adicionar conversão explícita para contornar a diferença de tipo. Por exemplo, digamos que você tenha uma tabela do Redshift RMS com o seguinte esquema: ``` CREATE TABLE rms_t (c1 int, c2 char(20)); ``` Se você quiser criar uma tabela do Iceberg usando `rms_t` como fonte, precisará de uma conversão explícita para a coluna `c2`, porque o tipo `varchar(n)` não é aceito: ``` CREATE TABLE ext_schema.iceberg_t AS SELECT c1, c2::varchar FROM rms_t; ``` Para obter mais informações sobre tipos de dados no Amazon Redshift, consulte [Tipos de dados](c_Supported_data_types.md). # Fazer referência a tabelas do Iceberg no Amazon Redshift O Amazon Redshift fornece várias maneiras de fazer referência a tabelas do Apache Iceberg armazenadas em seu data lake. Você pode usar esquemas externos para criar referências aos bancos de dados do Catálogo de Dados contendo tabelas do Iceberg ou usar a notação em três partes para acesso direto aos catálogos montados automaticamente. ## Usar esquemas externos para fazer referência a tabelas do Iceberg Os esquemas externos oferecem uma forma de fazer referência a tabelas em seu Catálogo de Dados a partir do Amazon Redshift. Ao criar um esquema externo, você deve estabelecer conexão entre o banco de dados do Amazon Redshift e um banco de dados específico do Catálogo de Dados que inclua as tabelas do Iceberg. Para criar um esquema externo para tabelas do Iceberg: ``` CREATE EXTERNAL SCHEMA schema_name FROM DATA CATALOG DATABASE 'glue_database_name' IAM_ROLE 'arn:aws:iam::account-id:role/role-name'; ``` Depois de criar o esquema externo, você pode consultar as tabelas do Iceberg usando a notação em duas partes: ``` SELECT * FROM schema_name.iceberg_table_name; ``` Você também pode unir tabelas do Iceberg com tabelas locais do Amazon Redshift: ``` SELECT r.customer_id, i.order_date, r.customer_name FROM local_customers r JOIN schema_name.iceberg_orders i ON r.customer_id = i.customer_id; ``` ## Usando notação em três partes com catálogos montados automaticamente. A notação em três partes permite que você faça referência direta a tabelas em catálogos montados automaticamente sem criar esquemas externos. Esse método é particularmente útil quando você trabalha com buckets de tabelas do Amazon S3 federados com o AWS Lake Formation. Para acessar informações sobre como configurar a montagem automática do Catálogo de Dados, consulte [Simplificar o acesso a objetos externos no Amazon Redshift usando a montagem automática do AWS Glue Data Catalog](https://aws.amazon.com/blogs/big-data/simplify-external-object-access-in-amazon-redshift-using-automatic-mounting-of-the-aws-glue-data-catalog/). A sintaxe da notação em três partes é: ``` "catalog_name".database_name.table_name ``` Por exemplo, para consultar uma tabela do Iceberg em um catálogo de tabelas do Amazon S3 montado automaticamente: ``` SELECT * FROM "my_table_bucket@s3tablescatalog".my_database.my_iceberg_table; ``` Para acessar mais informações sobre a integração de buckets de tabelas do Amazon S3 com o Amazon Redshift, consulte [Integrar tabelas do S3 com o Amazon Redshift](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-redshift.html) no *Guia do usuário do Amazon S3*. Você também pode usar a instrução `USE` para definir um catálogo e um banco de dados padrão: ``` USE "my_table_bucket@s3tablescatalog".my_database; SELECT * FROM my_iceberg_table; ``` Para definir um caminho de pesquisa para resolução de esquema: ``` USE "my_table_bucket@s3tablescatalog"; SET search_path TO my_database; SELECT * FROM my_iceberg_table; ``` ## Práticas recomendadas para fazer referência a tabelas do Iceberg Pense nas seguintes práticas recomendadas ao fazer referência a tabelas do Iceberg no Amazon Redshift. + **Use nomes de esquemas descritivos**: ao criar esquemas externos, use nomes que indiquem claramente a origem e a finalidade dos dados, como `sales_data_lake` ou `customer_analytics`. + **Utilize as estatísticas da tabela**: garanta que as estatísticas das colunas sejam geradas para suas tabelas do Iceberg, usando AWS Glue para otimizar a performance da consulta. O Amazon Redshift usa essas estatísticas para planejamento e otimização de consultas. + **Pense na atualização dos dados**: as tabelas do Iceberg podem ser atualizadas por outros serviços enquanto você as consulta. O Amazon Redshift oferece consistência transacional, garantindo que você veja um snapshot consistente dos dados durante a execução da consulta. + **Use as permissões apropriadas do IAM**: garanta que seu cluster ou grupo de trabalho do Amazon Redshift tenha as permissões do IAM necessárias para acessar os locais do Amazon S3 onde suas tabelas do Iceberg estão armazenadas, bem como os metadados do Catálogo de Dados. + **Monitore a performance das consultas**: use os recursos de monitoramento de consultas do Amazon Redshift para acompanhar a performance das consultas em relação às tabelas do Iceberg e otimizá-las conforme necessário. ## Padrões de referência comuns Os exemplos a seguir demonstram os padrões comuns para fazer referência a tabelas do Iceberg: **Agregar dados em várias tabelas do Iceberg:** ``` SELECT region, SUM(sales_amount) as total_sales, COUNT(*) as transaction_count FROM data_lake.sales_transactions WHERE transaction_date >= '2024-01-01' GROUP BY region ORDER BY total_sales DESC; ``` **Unir tabelas do Iceberg com tabelas locais do Amazon Redshift:** ``` SELECT c.customer_name, c.customer_tier, SUM(o.order_amount) as total_orders FROM customers c JOIN data_lake.order_history o ON c.customer_id = o.customer_id WHERE o.order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY c.customer_name, c.customer_tier; ``` **Usar a notação em três partes com consultas complexas:** ``` WITH recent_orders AS ( SELECT customer_id, order_date, order_amount FROM "analytics_bucket@s3tablescatalog".ecommerce.orders WHERE order_date >= CURRENT_DATE - INTERVAL '7 days' ) SELECT customer_id, COUNT(*) as order_count, AVG(order_amount) as avg_order_value FROM recent_orders GROUP BY customer_id HAVING COUNT(*) > 1; ``` # Gravar em tabelas do Apache Iceberg Com o Amazon Redshift, é possível criar e gravar em tabelas do Apache Iceberg armazenadas no Amazon S3 e nos buckets de tabelas do Amazon S3. Gravar dados do Iceberg diretamente do Amazon Redshift simplifica seu gerenciamento de dados ao eliminar ferramentas extras. As tabelas do Iceberg devem ser registradas no AWS Glue Data Catalog. É possível usar a arquitetura de lakehouse com tabelas do Apache Iceberg e, ao mesmo tempo, aproveitar a poderosa analytics SQL do Amazon Redshift em warehouses e lakes. Você também recebe acesso imediato aos recursos avançados do Amazon Redshift, como visões materializadas em suas tabelas do Iceberg, aprimorando significativamente seus recursos analíticos sem aumentar a complexidade. As gravações do Iceberg são aceitas em clusters provisionados do Amazon Redshift e em instâncias do Amazon Redshift sem servidor. **Topics** + [Comandos SQL](iceberg-writes-sql-syntax.md) + [Semântica de transação](iceberg-writes-transaction-semantics.md) + [Práticas recomendadas](iceberg-writes-best-practices.md) # Comandos SQL As tabelas do Apache Iceberg no Amazon Redshift oferecem uma forma poderosa de gerenciar grandes conjuntos de dados analíticos em seu data lake. Essas tabelas aceitam transações ACID, evolução de esquemas e recursos de viagem no tempo, mantendo a alta performance das workloads de analytics. Usando tabelas do Apache Iceberg, você pode organizar e particionar seus dados com eficiência, controlar formatos de arquivo e compactação e integrar-se perfeitamente a outros serviços da AWS. É possível criar tabelas do Iceberg particionadas e não particionadas usando comandos `CREATE TABLE ... USING ICEBERG` e `CREATE TABLE ... USING ICEBERG AS SELECT`. Você pode fazer referência a tabelas do Iceberg usando a notação de esquema externo (`external_schema.table_name`) ou a notação em três partes (`"catalog_name".database_name.table_name`). Os exemplos nesta seção demonstram os dois métodos. Depois de criar uma tabela, você pode adicionar dados usando os comandos `INSERT` padrão. Lembre-se de que, embora o Amazon Redshift funcione com muitos tipos de dados do Iceberg, talvez seja necessário converter alguns formatos de dados ao inserir informações. Você pode visualizar as tabelas do Iceberg usando o comando `SHOW TABLES`. Se quiser remover uma tabela do AWS Glue Data Catalog, você poderá usar o comando `DROP TABLE`. Observe que isso só remove o registro da tabela. Os dados reais permanecerão armazenados até que você os exclua separadamente. Todas as outras instruções SQL, como `DELETE`, `UPDATE`, `MERGE` e `ALTER TABLE`, ainda não são aceitas nas tabelas do Iceberg. As seções a seguir demonstram a sintaxe SQL para criar, inserir e gerenciar tabelas do Iceberg no Amazon Redshift. **Contents** + [CRIAR TABELA](#iceberg-writes-create-table) + [CRIAR TABELA COMO SELEÇÃO](#iceberg-writes-create-table-as-select) + [SHOW TABLE](#iceberg-writes-show-table) + [INSERT INTO](#iceberg-writes-insert-into) + [DESCARTAR TABELA](#iceberg-writes-drop-table) ## CRIAR TABELA ``` CREATE TABLE [IF NOT EXISTS] . ( column_name data_type [, ...] ) USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] ``` Você também pode usar a notação em três partes para buckets de tabelas do S3: ``` CREATE TABLE "@s3tablescatalog".. ( column_name data_type [, ...] ) USING ICEBERG [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] ``` Observe que `` deve ser um nome de esquema externo existente no qual a tabela externa será criada. Para acessar mais informações sobre como criar e gerenciar esquemas externos, consulte [CREATE EXTERNAL SCHEMA](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html) na documentação do Amazon Redshift. A cláusula `LOCATION` define a localização da tabela do Iceberg recém-criada. Para tabelas do Amazon S3, `LOCATION` não pode ser especificado, pois a localização da tabela é determinada pelo catálogo de tabelas do Amazon S3 (`s3tablescatalog`). Em todos os outros casos, `LOCATION` é obrigatório e deve ser um local vazio, o que significa que não há objetos existentes do Amazon S3 compartilhando esse mesmo bucket e prefixo. Observe que a região do bucket do Amazon S3 deve estar na mesma região que o cluster do Amazon Redshift. No entanto, AWS fornece um método para replicar dados de tabelas do Iceberg armazenadas em um AWS Glue Data Catalog em uma Região da AWS para outra Região da AWS, o que permite replicar a gravação em uma região diferente. Para acessar mais informações, consulte [Replicar seus dados entre Regiões da AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/best-practices-workloads.html#workloads-replication). `PARTITIONED BY` define a partição de tabelas do Iceberg. O Amazon Redshift comporta todas as transformações de partição do Iceberg v2, exceto `void`. Veja a lista de transformações aceitas: + **identity** + **bucket[N]** + **truncate[W]** + **ano** + **mês** + **dia** + **hora** Para acessar as definições completas dessas transformações e os tipos de dados compatíveis, consulte [Transformações de partição](https://iceberg.apache.org/spec/#partition-transforms) na documentação do Apache Iceberg. `PARTITIONED BY` aceita particionamento em vários níveis. Por exemplo, é possível executar o seguinte comando: ``` CREATE TABLE ... USING ICEBERG LOCATION ... PARTITIONED BY (bucket(16, id), year(ship_date)); ``` No entanto, o Amazon Redshift não aceita o uso de uma única coluna em mais de uma transformação. Por exemplo, a seguinte sintaxe não é aceita: ``` CREATE TABLE ... USING ICEBERG LOCATION ... PARTITIONED BY (bucket(16, ship_date), year(ship_date)); ``` A cláusula `TABLE PROPERTIES` define as propriedades extras da tabela do Iceberg. A única propriedade de tabela que comportamos é `compression_type` que define a compactação padrão de arquivos de dados do Parquet. Se isso não for especificado, `snappy` será usado como codec de compactação. Os valores possíveis para `compression_type` são `zstd`, `brotli`, `gzip`, `snappy` e `uncompressed`. **nota** `CREATE TABLE ... LIKE ...` não é aceito em tabelas do Iceberg. As tabelas do Iceberg também não aceitam restrições de coluna e atributos de coluna, como a tabela RMS. Como alternativa, você pode criar e preencher uma tabela do Iceberg em uma única operação usando `CREATE TABLE AS SELECT`: ## CRIAR TABELA COMO SELEÇÃO ``` CREATE TABLE . [( column_name[, ...] )] USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] AS SELECT query ``` Você também pode usar a notação em três partes para criar tabelas em catálogos montados automaticamente: ``` CREATE TABLE "".. [( column_name[, ...] )] USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] AS SELECT query ``` Isso é semelhante à instrução `CREATE TABLE`, exceto que `CREATE` é seguida por uma instrução `SELECT` para preencher a tabela com os resultados da consulta `SELECT`. A cláusula `CREATE TABLE` aqui não permite mais que você especifique os tipos de dados, pois os tipos de dados da coluna serão decididos pela consulta `SELECT`. Se a consulta `SELECT` falhar por algum motivo, essa consulta falhará, e a tabela do Iceberg não será criada. Você pode visualizar a estrutura de suas tabelas do Iceberg usando `SHOW TABLE`: ## SHOW TABLE ``` SHOW TABLE . ``` Também é possível usar notação em três partes com catálogos montados automaticamente: ``` SHOW TABLE "".. ``` `SHOW TABLE` exibe a instrução `CREATE TABLE` para a tabela do Iceberg. O comando mostrará os resultados apropriados com base no tipo da tabela. Veja um exemplo da saída `SHOW TABLE` da tabela do Iceberg: ``` CREATE TABLE my_schema.items (id int, price decimal(5, 2)) USING ICEBERG LOCATION 's3://my_s3_bucket/items/' PARTITIONED BY (bucket(16, id)) TABLE PROPERTIES ('compression_type'='snappy') ``` **nota** Para tabelas do Amazon S3, como a localização da tabela é gerenciada pelo catálogo de tabelas do Amazon S3, a cláusula `LOCATION` será omitida nos resultados de `SHOW TABLE`. Depois de criar tabelas, é possível adicionar dados usando `INSERT INTO`: ## INSERT INTO ``` INSERT INTO . [(column_name [, ...])] VALUES (...) INSERT INTO . [(column_name [, ...])] (SELECT query) -- Using three-part notation for S3 table buckets: INSERT INTO "@s3tablescatalog".. [(column_name [, ...])] VALUES (...) INSERT INTO "@s3tablescatalog".. [(column_name [, ...])] (SELECT query) ``` Você pode `INSERT INTO` a tabela do Iceberg existente usando a sintaxe acima. Se a cláusula `VALUES` for usada, você fornecerá os valores das colunas listadas por `column_name`, ou de todas as colunas, se a parte `column_name` for omitida. Quando os dados são inseridos na tabela particionada, novas linhas são distribuídas de acordo com a especificação de partição predefinida. Se, por algum motivo, a consulta `SELECT` falhar, a consulta falhará, e nenhum dado será inserido na tabela do Iceberg. É possível `INSERT INTO` uma tabela do Iceberg que não tenha sido criada pelo Amazon Redshift. No entanto, existem algumas limitações: + A tabela deve ser uma tabela do Iceberg v2. + A tabela deve usar o Parquet como formato de dados padrão. + A tabela não deve ter a compactação de metadados definida como True. + A tabela não deve habilitar Write-Audit-Publish (WAP). Para remover uma tabela do Iceberg do catálogo, use o comando `DROP TABLE`: ## DESCARTAR TABELA ``` DROP TABLE . ``` Também é possível usar notação em três partes com catálogos montados automaticamente: ``` DROP TABLE ".. ``` Eliminar uma tabela do Iceberg é uma operação somente para metadados. É removida a entrada da tabela do AWS Glue Data Catalog e um catálogo de tabelas do Amazon S3, se for uma tabela do Amazon S3. O Amazon Redshift não limpa nem exclui nenhum arquivo de dados ou arquivos de metadados existentes na localização da tabela. Você pode usar recursos no AWS Glue e em tabelas do Amazon S3 para remover arquivos órfãos. Para AWS Glue, consulte [Excluir arquivos órfãos](https://docs.aws.amazon.com/glue/latest/dg/orphan-file-deletion.html). Para tabelas do Amazon S3, consulte [Manutenção de tabelas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-maintenance.html). # Semântica de transação As consultas de gravação do Redshift Iceberg comportam ACID e isolamento de snapshot. As transações de gravação têm atomicidade garantida e não produzem atualizações parciais quando uma consulta falha inesperadamente. Várias transações do Iceberg podem ser executadas simultaneamente e, se duas transações tentarem modificar a mesma tabela ou partição simultaneamente, a confirmação da transação falhará. Isso garante a integridade dos dados. Quando isso acontece, você deve resolver os conflitos manualmente e executar novamente as consultas com falha. O Amazon Redshift não tenta resolver automaticamente os conflitos novamente. Uma única consulta de gravação do Iceberg é sempre tratada como uma única transação de confirmação automática. Quando uma consulta de gravação do Iceberg, como a consulta CREATE ou INSERT, é incluída em um bloco de transação explícito, nenhuma outra consulta pode ser executada no mesmo bloco de transação. A transação falhará. Veja a seguir alguns exemplos: O primeiro exemplo demonstra que uma única consulta de instrução sempre é confirmada automaticamente após o término da consulta. Neste cenário, você está criando uma tabela de pedidos de venda: ``` CREATE TABLE sales_schema.orders ( order_id int, customer_id int, order_date date, total_amount decimal(10,2) ) USING ICEBERG LOCATION 's3://my-data-lake/sales/orders/'; ``` Este exemplo é um bloco de transação explícito para inserir um pedido de cliente usando a notação em três partes para um bucket de tabelas do S3. A transação não é confirmada automaticamente após a consulta INSERT, mas confirma e insere os dados do pedido com o comando COMMIT: ``` BEGIN; INSERT INTO "analytics_bucket@s3tablescatalog".sales_db.orders VALUES (12345, 9876, '2024-10-30', 299.99); COMMIT; ``` Este exemplo é um cenário explícito de reversão do bloco de transações em que você está testando a inserção de um pedido, mas decide cancelá-la. A transação não é confirmada automaticamente após a consulta INSERT, mas é revertida com o comando ROLLBACK sem inserir o pedido de teste. ``` BEGIN; INSERT INTO sales_schema.orders VALUES (12346, 5432, '2024-10-30', 150.75); ROLLBACK; ``` Este exemplo final demonstra como, quando você tenta executar outra instrução dentro do mesmo bloco de transação da consulta INSERT, a transação falha sem inserir os dados do pedido. Neste cenário, você está tentando inserir um pedido e consultar imediatamente a tabela: ``` BEGIN; INSERT INTO sales_schema.orders VALUES (12347, 7890, '2024-10-30', 425.50); SELECT * FROM sales_schema.orders WHERE order_id = 12347; ``` A única exceção a isso é a instrução `DROP TABLE`, que sempre se comporta como uma instrução de confirmação automática e não pode ser executada em um bloco de transação explícito. O objetivo disso é manter o mesmo comportamento que `DROP TABLE` em uma tabela externa. Consulte mais informações em [DROP TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_TABLE.html). **nota** Os SQLs de gravação do Iceberg não podem ser executados a partir do procedimento armazenado. # Práticas recomendadas Pense nas seguintes práticas recomendadas ao gravar em uma tabela do Apache Iceberg: + Para workloads de gravação ou streaming pequenas e frequentes, pense em usar os recursos de compactação fornecidos pelo AWS Glue Data Catalog ou pelas tabelas do Amazon S3 para otimizar o tamanho dos arquivos para leituras. + O comando `DROP TABLE` cancela o registro da tabela do AWS Glue Data Catalog ou do catálogo de tabelas do Amazon S3, mas seus arquivos ainda permanecem. Você pode usar recursos no AWS Glue e em tabelas do Amazon S3 para remover arquivos órfãos. Para AWS Glue, consulte [Excluir arquivos órfãos](https://docs.aws.amazon.com/glue/latest/dg/orphan-file-deletion.html). Para tabelas do Amazon S3, consulte [Manutenção de tabelas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-maintenance.html).