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
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.
Também é possível modificar dados existentes usando os comandos DELETE, UPDATE e MERGE. Todas as demais instruções SQL, como ALTER TABLE, ainda não são compatíveis com tabelas do Iceberg.
É possível gravar em uma tabela Iceberg que não foi 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).
As seções a seguir demonstram a sintaxe SQL para criar, inserir, modificar e gerenciar tabelas do Iceberg no Amazon Redshift.
CRIAR TABELA
CREATE TABLE [IF NOT EXISTS]<external_schema>.<table_name>( column_name data_type [, ...] ) USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='<compression_value>')]
Você também pode usar a notação em três partes para buckets de tabelas do S3:
CREATE TABLE "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>( column_name data_type [, ...] ) USING ICEBERG [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='<compression_value>')]
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 na documentação do Amazon Redshift.<external_schema>
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.
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
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<external_schema>.<table_name>[( column_name[, ...] )] USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='<compression-value>')] 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 "<catalog_name>".<database_name>.<table_name>[( column_name[, ...] )] USING ICEBERG [LOCATION 's3://your-bucket-name/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='<compression-value>')] 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<external_schema>.<table_name>
Também é possível usar notação em três partes com catálogos montados automaticamente:
SHOW TABLE "<catalog_name>".<database_name>.<table_name>
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<external_schema>.<table_name>[(column_name [, ...])] VALUES (...) INSERT INTO<external_schema>.<table_name>[(column_name [, ...])] (SELECT query) -- Using three-part notation for S3 table buckets: INSERT INTO "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>[(column_name [, ...])] VALUES (...) INSERT INTO "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>[(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.
DELETE
A consulta DELETE para a tabela Iceberg usa a sintaxe DELETE existente na tabela do RMS.
[ WITH [RECURSIVE]common_table_expression[,common_table_expression, ...] ] DELETE [ FROM ]iceberg_table[ { USING }table_name, ...] [ WHEREcondition]
Você também pode usar a notação em três partes para buckets de tabelas do S3:
[ WITH [RECURSIVE]common_table_expression[,common_table_expression, ...] ] DELETE [ FROM ] "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>[ { USING }table_name, ...] [ WHEREcondition]
O pode ser referenciado usando o formato iceberg_table, ou utilizando a notação de três partes para catálogo montado automaticamente. Consulte Referencing Iceberg tables in Amazon Redshift.<external_schema>.<external_table_name>
O na cláusula table_nameUSING será usado para realizar junção com a tabela de destino para excluir linhas que atendam à condição WHERE. O pode ser uma tabela Iceberg ou uma tabela RMS do Amazon Redshift.table_name
Como o Iceberg usa um esquema de particionamento oculto, é possível usar a consulta DELETE para remover partições, obtendo o mesmo efeito de ALTER TABLE ... DROP
PARTITION ... para tabelas Hive.
Por exemplo, quando há uma tabela Iceberg particionada como abaixo:
CREATE TABLE my_external_schema.lineitem (l_item_id int, l_ship_date varchar, ... ) USING ICEBERG LOCATION ... PARTITIONED BY l_ship_date;
Em seguida, é possível remover facilmente uma partição usando uma consulta como esta:
DELETE FROM my_external_schema.lineitem WHERE l_ship_date = '20251231';
Para uma consulta como esta, o Amazon Redshift otimiza a execução para realizar apenas uma operação de metadados e encerrar a execução antecipadamente. Assim, diferentemente de uma consulta DELETE normal, a consulta de exclusão apenas de metadados não exibe etapas de execução em EXPLAIN:
explain DELETE FROM my_external_schema.lineitem WHERE l_ship_date = '20251231'; QUERY PLAN ------------ "XN Seq Scan Metadata of my_external_schema.lineitem location: "s3://s3-path//table-location" format:ICEBERG (cost=0.00..0.01 rows=0 width=0)" (0 rows)
UPDATE
A sintaxe da consulta UPDATE para tabela Iceberg é muito semelhante à sintaxe existente de UPDATE para tabela RMS:
[ WITH [RECURSIVE]common_table_expression[,common_table_expression, ...] ] UPDATEiceberg_table[ [ AS ] alias ] SET column = {expression} [,...] [ FROMfromlist] [ WHEREcondition]
Você também pode usar a notação em três partes para buckets de tabelas do S3:
[ WITH [RECURSIVE]common_table_expression[,common_table_expression, ...] ] UPDATE "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>[ [ AS ] alias ] SET column = {expression} [,...] [ FROMfromlist] [ WHEREcondition]
O pode ser referenciado usando o formato iceberg_table, ou utilizando a notação de três partes para catálogo montado automaticamente. Consulte Referencing Iceberg tables in Amazon Redshift.<external_schema>.<external_table_name>
Você pode atualizar uma tabela fazendo referência às informações em outras tabelas. Liste essas outras tabelas na cláusula FROM ou use uma subconsulta como parte da condição WHERE. As tabelas de origem podem ser tabelas Iceberg ou tabelas RMS do Amazon Redshift.
O UPDATE também pode ser executado em tabela particionada. Quando UPDATE altera valores de colunas que pertencem à especificação de partição atual, a nova linha atualizada será inserida na nova partição com base no valor atualizado.
Por exemplo, quando há uma tabela Iceberg particionada como abaixo:
CREATE TABLE my_external_schema.lineitem (l_item_id int, l_ship_date varchar, ... ) USING ICEBERG LOCATION ... PARTITIONED BY l_ship_date; INSERT INTO my_external_schema.lineitem VALUES (10099, '20251231', ...);
E ao executar a seguinte consulta de atualização:
UPDATE my_external_schema.lineitem SET l_ship_date = '20260101' WHERE l_item_id = 10099;
essa linha com l_item_id 10099 será movida da partição 20251231 para a nova partição 20260101.
Também é importante observar que é possível que UPDATE tenha múltiplos valores candidatos. Considere a consulta abaixo:
CREATE TABLE my_ext_schema.t1(x1 int, y1 int) USING ICEBERG LOCATION ...; CREATE TABLE my_ext_schema.t2(x2 int, y2 int) USING ICEBERG LOCATION ...; INSERT INTO my_ext_schema.t1 VALUES (1,10), (2,20), (3,30); INSERT INTO my_ext_schema.t2 VALUES (2,40), (2,50); UPDATE my_ext_schema.t1 SET y1=y2 FROM my_ext_schema.t2 WHERE x1=x2;
Nesse caso, y1 pode ser 40 ou 50. O resultado é não determinístico. É possível definir o parâmetro de configuração error_on_nondeterministic_update como true para forçar erro na consulta quando esse caso ocorrer. Isso é consistente com o comportamento UPDATE existente de em tabelas RMS. Consulte mais informações em error_on_nondeterministic_update.
MERGE
A consulta MERGE mescla condicionalmente linhas de uma tabela de origem em uma tabela de destino. Ela compartilha a mesma sintaxe de consulta MERGE que a tabela RMS existente:
MERGE INTOtarget_iceberg_tableUSINGsource_table[ [ AS ]alias] ONmatch_condition[ WHEN MATCHED THEN { UPDATE SETcol_name= {expr} [,...] | DELETE } WHEN NOT MATCHED THEN INSERT [ (col_name[,...] ) ] VALUES ( {expr} [, ...] ) | REMOVE DUPLICATES ]
Você também pode usar a notação em três partes para buckets de tabelas do S3:
MERGE INTO "<table_bucket_name>@s3tablescatalog".<database_name>.<table_name>USINGsource_table[ [ AS ]alias] ONmatch_condition[ WHEN MATCHED THEN { UPDATE SETcol_name= {expr} [,...] | DELETE } WHEN NOT MATCHED THEN INSERT [ (col_name[,...] ) ] VALUES ( {expr} [, ...] ) | REMOVE DUPLICATES ]
O pode ser referenciado usando o formato target_iceberg_table, ou utilizando a notação de três partes para catálogo montado automaticamente. Consulte Referencing Iceberg tables in Amazon Redshift.<external_schema>.<external_table_name>
O pode ser uma tabela Iceberg ou uma tabela RMS do Amazon Redshift.source_table
Quando REMOVE DUPLICATES é utilizado, o comando MERGE usa o modo simplificado. Consulte mais detalhes sobre o modo simplificado na documentação original do comando MERGE.
Ao executar a consulta MERGE, o Amazon Redshift gera e armazena arquivos de dados intermediários no local da tabela de destino. Esses arquivos serão coletados ao final da consulta. Por esse motivo, a consulta MERGE requer a permissão DELETE no bucket do Amazon S3 para funcionar corretamente. Um erro de permissão insuficiente será gerado caso a operação de coleta de resíduos não seja concluída com sucesso. Para tabelas do Amazon S3, a coleta de resíduos é gerenciada pelo serviço Tabelas do Amazon S3. Portanto, a permissão DELETE não é necessária para executar a consulta MERGE.
DESCARTAR TABELA
Para remover uma tabela do Iceberg do catálogo, use o comando DROP TABLE:
DROP TABLE<external_schema>.<table_name>
Também é possível usar notação em três partes com catálogos montados automaticamente:
DROP TABLE "<catalog_name>".<database_name>.<table_name>
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. Para tabelas do Amazon S3, consulte Manutenção de tabelas.