S3 Tables passa a suportar todos os tipos de dado do Apache Iceberg V3

O recurso gerenciado da AWS para tabelas Iceberg ganha suporte completo à especificação V3: deletion vectors, row lineage e tipos nativos para dado semiestruturado, geoespacial e timestamp em nanossegundos.

Nota da redação: este artigo contém três detalhes técnicos que não conseguimos confirmar na fonte oficial (AWS News Blog) e que podem não ser precisos: (1) a afirmação de que deletion vectors geram um único arquivo 'por partição afetada' (a fonte só diz que o delete gera um único arquivo de deletion vector, sem especificar o escopo); (2) a descrição de que coordenadas geoespaciais são hoje comumente codificadas como 'par de double ou string WKT' (a fonte menciona apenas 'strings ou inteiros'); e (3) a composição exata da fatura padrão do S3 Tables como cobrindo 'armazenamento, requisições e compactação automática' (a fonte não detalha os itens da cobrança). Leia esses trechos como interpretação técnica da redação, não como citação direta do anúncio da AWS.

A AWS anunciou, no AWS News Blog, que o Amazon S3 Tables passa a suportar todos os tipos de dado da especificação Apache Iceberg V3. Na prática, isso significa que quem administra um bucket de tabelas no S3 pode criar tabelas V3 do zero ou fazer upgrade de tabelas V2 existentes para usar deletion vectors, row lineage e cinco tipos de dado novos: variant, geometry, geography, unknown e timestamp com precisão de nanossegundo.

O anúncio, assinado por Daniel Abib, resolve um problema concreto de quem opera Iceberg em produção. Uma tabela V2 com 2 bilhões de linhas que precisa apagar 50 mil registros por pedido de compliance acumula positional delete files que seguram a performance de leitura até a próxima compactação. Eventos semiestruturados viram string JSON que toda query precisa fazer parse. Coordenada geoespacial e timestamp de alta precisão acabam codificados como string ou inteiro, porque o V2 não tem tipo nativo para eles. Cada workaround desses custa armazenamento, latência de consulta e código extra no pipeline.

Deletion vectors: apagar sem reescrever a tabela

No Iceberg V2, um DELETE em modo merge-on-read gera arquivos de delete posicional, um por arquivo de dado afetado. Em uma tabela grande, um delete de compliance pode gerar milhares desses arquivos pequenos, e a compactação subsequente fica mais lenta para absorver todos eles.

O V3 substitui esse mecanismo por deletion vectors: um formato binário compacto que concentra as posições deletadas em um único arquivo por partição afetada, em vez de um arquivo por data file. Para habilitar o comportamento em uma tabela existente, a configuração é via TBLPROPERTIES:

ALTER TABLE my_catalog.namespace.clickstream
SET TBLPROPERTIES (
 'write.delete.mode' = 'merge-on-read',
 'write.update.mode' = 'merge-on-read',
 'write.merge.mode' = 'merge-on-read'
)

Com isso configurado, um DELETE FROM ... WHERE user_id = 'user-42' grava um deletion vector só, e o S3 Tables cuida da compactação desses arquivos no próximo ciclo de manutenção automático, sem o operador precisar agendar nada.

Row lineage: achar o que mudou sem varrer a tabela inteira

Tabelas V3 ganham automaticamente duas colunas ocultas: _row_id e _last_updated_sequence_number. Quem constrói pipeline incremental pode usar esse segundo campo como checkpoint:

SELECT *, _row_id, _last_updated_sequence_number
FROM my_catalog.namespace.clickstream
WHERE _last_updated_sequence_number > 42

Isso retorna só as linhas modificadas depois do número de sequência 42. Antes do V3, fazer isso dependia de manter uma coluna de timestamp de atualização manualmente. Agora o dado de linhagem vem do próprio formato de tabela.

O tipo variant e o fim do PARSE_JSON em toda query

Para quem guarda eventos de clickstream, log de aplicação ou payload de API num data lake, o tipo variant é a mudança mais visível do pacote V3. Uma tabela de eventos de e-commerce, por exemplo, tem formatos de payload diferentes por tipo de ação: visualização de página, compra, busca. Em vez de forçar um schema único ou guardar tudo como string, dá para declarar a coluna como variant:

CREATE TABLE my_catalog.namespace.clickstream (
 event_id bigint,
 event_time timestamp,
 user_id string,
 payload variant
)
USING iceberg
TBLPROPERTIES ('format-version' = '3')

Na escrita, o engine quebra ("shreds") o variant em colunas ocultas e coleta estatísticas por coluna shredded. Isso é o que diferencia variant de só guardar uma string JSON: na hora da leitura, essas estatísticas permitem pruning de arquivo, ou seja, o engine descarta arquivos inteiros sem abri-los quando sabe que não têm o valor procurado. Uma consulta como esta já lê o campo sem fazer parse manual:

SELECT event_id, user_id,
 variant_get(payload, '$.action', 'string') AS action,
 variant_get(payload, '$.amount', 'double') AS amount
FROM my_catalog.namespace.clickstream
WHERE variant_get(payload, '$.action', 'string') = 'purchase'
 AND variant_get(payload, '$.amount', 'double') > 50.00

Os outros quatro tipos novos resolvem lacunas mais específicas: geometry e geography guardam coordenada geoespacial nativamente (hoje comum em tabela codificada como par de double ou string WKT); nanosecond timestamp atende cenário de trading ou telemetria industrial onde microssegundo já não é precisão suficiente; e unknown serve para coluna cujo tipo ainda não foi determinado no momento da ingestão.

Como migrar uma tabela V2 sem reescrever dados

O upgrade de uma tabela existente é uma operação atômica de metadado, sem reescrita de arquivo Parquet:

ALTER TABLE my_catalog.namespace.existing_table
SET TBLPROPERTIES ('format-version' = '3')

Depois do upgrade, o próximo ciclo de compactação do S3 Tables remove os delete files antigos do V2, e as modificações seguintes já usam deletion vector automaticamente. Os campos de row lineage só são inicializados na primeira modificação de dado feita após o upgrade, não retroativamente.

Um ponto que pede atenção de quem decide migrar: o upgrade de V2 para V3 é uma via de mão única. A especificação Iceberg não define downgrade de V3 para V2, então antes de rodar o ALTER TABLE vale confirmar que todo engine que acessa aquela tabela já suporta V3, inclusive ferramenta de BI ou job batch que ninguém lembrava que lia daquele bucket.

Quem ainda não pode usar os tipos novos

A compatibilidade de engine é a restrição prática mais relevante do anúncio. Os cinco tipos novos (variant, geometry, geography, unknown e nanosecond timestamp) exigem engine construído sobre Apache Spark 4.0 ou mais recente, na prática, AWS Glue 6.0 ou superior, ou Amazon EMR a partir da versão 8.1. Quem ainda roda Glue 5.x ou EMR mais antigo precisa atualizar o cluster antes de usar os tipos novos.

Três outras restrições valem a pena anotar antes de planejar a migração:

• Os tipos novos funcionam só em tabela no formato Parquet; ORC e Avro ficam de fora.
• Coluna do tipo variant, geometry, geography ou nanosecond timestamp não pode entrar na ordenação (sort order) usada pela compactação; a tabela ainda compacta normalmente sob estratégia de sort ou Z-order desde que a ordenação use só colunas de outros tipos.
• Tabela V2 e V3 convivem no mesmo catálogo: leitor V2 continua funcionando numa tabela já atualizada, o que dá margem para migrar engine por engine em vez de trocar tudo de uma vez.

Tanto S3 Tables quanto AWS Glue Data Catalog expõem a Iceberg REST Catalog API, então a interoperabilidade entre engine não depende de qual serviço guarda o catálogo.

Custo

O suporte a Iceberg V3 não tem cobrança adicional: aplica-se o preço padrão do S3 Tables, que já cobre armazenamento, requisições e a compactação automática que o serviço roda em segundo plano. Para quem já paga por S3 Tables, o upgrade de tabela V2 para V3 não muda a fatura por si só, o que pode mudar é o volume de storage de delete files, que tende a cair com deletion vectors mais compactos.

Para quem decide se migra agora: tabela pequena ou com baixo volume de delete/update ganha pouco com deletion vectors, e o tipo variant só compensa se o payload semiestruturado for consultado com frequência (senão o ganho de pruning não aparece). Já quem sofre com compactação lenta por delete de compliance, ou mantém campo geoespacial e timestamp de alta precisão hoje codificado como string, tem motivo concreto para testar o upgrade assim que o engine de leitura suportar Spark 4.0.

Fonte

1. AWS News Blog: Amazon S3 Tables now support all Apache Iceberg V3 data types, por Daniel Abib.

Fonte: AWS News Blog