# Redshift e Iceberg v3: notas de campo para lakes mutáveis

O suporte do Amazon Redshift a Apache Iceberg v3, anunciado em 31 de agosto de 2026, muda a conversa sobre data lakes mutáveis. Eu trataria default values, row lineage e deletion vectors como primitivas operacionais, não apenas como recursos de formato.

- URL: https://fernando.moretes.com/blog/redshift-e-iceberg-v3-notas-de-campo-para-lakes-mutaveis-amazon-redsh

- Markdown: https://fernando.moretes.com/blog/redshift-e-iceberg-v3-notas-de-campo-para-lakes-mutaveis-amazon-redsh/article.md?lang=pt

- Published: 2026-09-01T20:36:01.041Z

- Category: Segurança & Resiliência

- Tags: redshift, iceberg, data-lake, cdc, governance, aws

- Reading time: 8 min

- Source: [Amazon Redshift now supports Apache Iceberg v3 tables](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-apache-iceberg-v3)

---

Quando eu olho para o suporte do Amazon Redshift a tabelas Apache Iceberg v3, a parte interessante não é apenas "agora lê e escreve v3". O ponto arquitetural é que três dores antigas de lakes analíticos começam a virar contrato de tabela: evolução de schema com default explícito, identificação estável de linha para pipelines incrementais e exclusões compactas para workloads com update/delete frequente. Em ambientes financeiros, isso toca diretamente reconciliação, direito ao esquecimento, trilha de auditoria, custo de varredura e acoplamento entre engines.

## A situação: o lake deixou de ser apenas append-only

Durante anos, uma parte relevante dos data lakes corporativos funcionou bem porque o contrato implícito era simples: arquivos Parquet imutáveis, partições previsíveis, jobs de compactação e consumo majoritariamente append-only. Esse modelo continua válido para eventos brutos, logs e snapshots regulatórios. Ele começa a ranger quando a plataforma vira produto de dados compartilhado entre risco, antifraude, atendimento, Open Finance, BI, modelos de crédito e auditoria.

Nesses cenários, a pergunta operacional não é "consigo consultar S3 com SQL?". A pergunta é se eu consigo modificar uma linha sem destruir performance, adicionar uma coluna sem reprocessar terabytes, propagar somente mudanças para consumidores downstream e provar o que mudou entre snapshots. O anúncio do Redshift em 31 de agosto de 2026 importa porque leva recursos do Iceberg v3 para dentro de um motor SQL que muitas empresas já usam como camada de consumo, transformação e governança.

Eu não leria isso como autorização para transformar todo lake em banco OLTP. Iceberg continua sendo formato analítico. O ganho está em reduzir remendos: tabelas espelho para CDC, colunas técnicas inconsistentes, delete files acumulados e pipelines que varrem tudo porque não há marcador confiável de alteração.

## O que mudou de verdade

- O Redshift agora pode criar ou atualizar tabelas Iceberg v3 com a propriedade 'format-version' = '3', mantendo a sintaxe SQL de DML semelhante à usada com v2.
- Default column values reduzem reprocessamento em evolução de schema, mas exigem governança sobre o significado histórico do default.
- Row lineage expõe _row_id e _last_updated_sequence_number para incrementalidade, auditoria e reconciliação, desde que os consumidores entendam o contrato.
- Deletion vectors substituem novos positional delete files em v3 e ajudam em workloads com muitos deletes, updates e MERGEs, especialmente quando a manutenção da tabela é disciplinada.
- A compatibilidade não é universal: tipos complexos e alguns tipos do Iceberg v3 não são suportados pelo Redshift no momento, e downgrade de v3 para v2 não é suportado.

## Default values: evolução de schema sem reescrever o passado

O uso mais pragmático de default values aparece quando uma tabela grande precisa ganhar uma coluna operacional: `source_system`, `risk_bucket`, `consent_status`, `schema_version`, `retention_class` ou algo parecido. Em Iceberg v2, muitas equipes resolviam isso com backfill caro, views com `coalesce`, ou regras diferentes por consumidor. Em Iceberg v3 no Redshift, uma coluna adicionada com default pode retornar o valor inicial para arquivos antigos sem reescrever os dados, e novos INSERTs podem gravar o default quando a coluna é omitida.

A armadilha é semântica. Um default não significa que o dado histórico realmente tinha aquele atributo no momento original. Em ambientes regulados, eu separo defaults técnicos de afirmações de negócio. `schema_version DEFAULT 3` é relativamente seguro. `customer_consent DEFAULT true` é perigoso se não houver base histórica para isso. Também vale notar que defaults são literais, não expressões dinâmicas; eu não contaria com eles para timestamps de processamento ou regras contextuais.

Na prática, eu registraria cada mudança em ADR curta, com data efetiva, motivo, owner do domínio e impacto nos consumidores. Se o default altera interpretação de métrica, a publicação precisa incluir versão de contrato e janela de convivência.

## Row lineage: CDC analítico com menos adivinhação

O recurso que eu mais observaria é row lineage. O Redshift expõe pseudo-colunas `_row_id` e `_last_updated_sequence_number`, que precisam ser selecionadas explicitamente e não aparecem em `SELECT *`. Isso é uma decisão boa: evita vazamento acidental em dashboards, mas permite que pipelines técnicos criem checkpoints por sequência. Para uma esteira incremental, o contrato básico fica simples: persistir o último sequence number processado, ler linhas com sequência maior ou igual ao watermark planejado, gravar resultados de forma idempotente e só avançar o checkpoint após commit downstream.

Eu ainda não substituiria todos os mecanismos de CDC por isso. Em integrações com sistemas transacionais, continuo querendo logs de origem, ordering por partição e evento de negócio. Row lineage é mais forte dentro do lakehouse: derivar tabelas silver/gold, recalcular agregados afetados, alimentar feature stores, reconstruir índices de busca e montar trilhas de auditoria analítica.

Um detalhe operacional importa no upgrade de v2 para v3: dados pré-upgrade não recebem lineage útil imediatamente; a documentação do Redshift indica que os valores retornam nulos até a primeira escrita após o upgrade, quando valores são gerados para a tabela. Portanto, a migração precisa ter uma linha de corte explícita. Eu trataria essa linha como um evento de plataforma, não como detalhe invisível.

## Padrão de tabela Iceberg v3 para mutações controladas

O desenho mostra como eu isolaria ingestão, contrato de tabela, consultas incrementais e governança ao adotar Iceberg v3 com Redshift.

### 🟦 Domínios produtores

- Eventos de negócio Kafka/MSK ou batch (messaging)
- Glue/EMR jobs validação e merge (compute)

### 🟧 Contrato lakehouse

- AWS Glue Data Catalog metadados Iceberg (data)
- Tabela Iceberg v3 format-version=3 (storage)
- Deletion vectors Puffin + bitmap (storage)
- Row lineage _row_id + sequence (data)

### 🟥 Governança

- Lake Formation FGAC e grants (security)
- KMS + S3 policies criptografia e perímetro (security)

### 🟩 Consumo e operação

- Amazon Redshift Graviton provisioned/serverless (compute)
- Checkpoint incremental última sequência processada (data)
- CloudWatch/SLOs scan, latency, failures (compute)

### Fluxos

- events -> etl: normaliza e valida
- etl -> table: INSERT/UPDATE/MERGE
- catalog -> table: schema e snapshots
- table -> dv: marca linhas removidas
- table -> lineage: identifica mudanças
- lf -> catalog: autoriza tabelas/colunas/linhas
- kms -> table: protege objetos S3
- redshift -> catalog: descobre tabela
- redshift -> lineage: consulta por sequence
- redshift -> checkpoint: avança após commit
- redshift -> obs: emite sinais operacionais

## Deletion vectors: menos arquivos de delete, mas não zero manutenção

Deletion vectors atacam um problema conhecido: updates e deletes em arquivos imutáveis tendem a gerar estruturas auxiliares que pioram leitura, planejamento e compactação. No Iceberg v3, o Redshift registra posições removidas em bitmaps compactos armazenados em arquivos Puffin, com no máximo um deletion vector por data file em um snapshot. Isso reduz a proliferação de positional delete files e torna workloads de exclusão regulatória, correção cadastral e MERGE de CDC menos custosos em leitura e escrita.

Mas eu não venderia isso internamente como manutenção gratuita. Se uma tabela recebe deletes aleatórios o dia inteiro, os arquivos de dados continuam fisicamente contendo registros invalidados. A leitura fica melhor que um monte de delete files pequenos, mas ainda há trabalho adicional. Para tabelas com alto churn, eu manteria políticas explícitas de compactação, reescrita de arquivos e expiração de snapshots, separando janelas de baixa demanda para manutenção.

Um número prático que costumo usar como gatilho inicial não é absoluto: quando a proporção de linhas logicamente deletadas em partições quentes passa de 5% a 10%, ou quando a latência P95 de consultas sobre essas partições cresce de forma sustentada, eu reviso compactação. Não estou citando isso como limite AWS; é heurística operacional para começar a medir antes do usuário perceber.

## O ponto de arquitetura: interoperabilidade com fronteiras claras

O valor de Iceberg é permitir que múltiplos engines compartilhem uma tabela sem transformar o lake em um acoplamento acidental. Redshift, Athena, EMR, Glue e outras ferramentas podem participar, mas eu só deixaria múltiplos writers quando há ownership explícito. Para tabelas críticas, escolho um writer primário por domínio e trato os demais como leitores ou transformadores com permissões muito específicas.

No Redshift, há detalhes que entram no desenho. A documentação informa suporte a Lake Formation fine-grained access control para tabelas Iceberg, uso de estatísticas de coluna geradas pelo Glue para melhor performance e diferenças de custo conforme o tipo de compute: RG e Serverless usam compute próprio para consultas em S3, enquanto DC2 ou RA3 usam Redshift Spectrum. A página de preços confirma que Spectrum cobra por bytes escaneados, com arredondamento para o próximo megabyte e mínimo de 10 MB por consulta; no Serverless, consultas externas entram no consumo de RPU-hour do workgroup.

Eu configuraria isso como produto de plataforma: bucket S3 com SSE-KMS, políticas condicionadas por `aws:PrincipalArn` e `aws:SecureTransport`, Lake Formation como plano de autorização, roles estáticas para escrita, tags de sensibilidade e orçamento separado por workload. O erro comum é tratar o formato aberto como ausência de governança. É o oposto: quanto mais aberto o formato, mais claro deve ser o contrato.

## Playbook de adoção que eu usaria

1. **Escolha uma tabela com mutação real, não a mais crítica** — Procure uma tabela com MERGE ou DELETE frequente, consumidores conhecidos e rollback operacional possível. Evite começar por ledger contábil, risco intradiário ou tabelas com múltiplos writers sem dono claro.

2. **Audite engines e tipos antes do upgrade** — Confirme que todos os leitores e writers relevantes entendem Iceberg v3. No Redshift, não planeje v3 para tabelas que dependem de struct, list, map, variant, geometry, geography, binary, uuid, time ou timestamps de nanossegundos, pois a documentação lista essas limitações.

3. **Defina o contrato de incrementalidade** — Padronize checkpoint por `_last_updated_sequence_number`, janela de releitura para tolerar retries, idempotency key no destino e métrica de diferença entre linhas lidas e linhas efetivamente aplicadas.

4. **Faça upgrade como mudança de plataforma** — O ALTER de formato é metadata-only, mas a consequência não é trivial: não há downgrade para v2, dados pré-upgrade têm comportamento específico de lineage e positional deletes antigos continuam válidos até serem incorporados em deletion vectors por escritas posteriores.

5. **Meça antes e depois com o mesmo conjunto de consultas** — Colete P50/P95/P99, bytes escaneados, número de arquivos, duração de MERGE, falhas por permissão Lake Formation, tempo de planejamento e custo por domínio. Sem baseline, qualquer ganho vira narrativa.

> **Comece pelo contrato, não pelo ALTER TABLE:** Antes de executar `ALTER TABLE ... SET TABLE PROPERTIES ('format-version' = '3')`, escreva três coisas: quem pode escrever, como consumidores incrementais avançam checkpoint e qual métrica decide compactação. O comando é curto; a governança ao redor dele é a parte que evita incidentes.

## Anti-padrões que eu evitaria

- Atualizar para v3 porque é novo, sem inventário dos engines que leem a tabela. Em lakehouse, incompatibilidade silenciosa entre ferramentas custa mais do que o upgrade.
- Usar default values para esconder ausência de governança de dados. Default técnico ajuda evolução; default de negócio mal definido cria erro histórico com aparência de dado completo.
- Tratar `_last_updated_sequence_number` como substituto universal de evento de domínio. Ele é excelente para mudança analítica, mas não carrega sozinho causalidade de negócio.
- Permitir múltiplos writers sem protocolo de ownership, retries e idempotência. O formato suporta interoperabilidade; ele não resolve disputa organizacional.
- Ignorar estatísticas de coluna e manutenção de arquivos. O Redshift pode otimizar melhor quando as estatísticas existem; deletion vectors reduzem dor, mas não dispensam higiene de tabela.

## Observabilidade, segurança e custo em produção

Eu colocaria Iceberg v3 no mesmo nível de observabilidade de qualquer serviço crítico. Para cada tabela candidata, mantenho um painel com volume escrito por hora, linhas atualizadas/deletadas, idade do último snapshot, contagem de arquivos pequenos, tempo de MERGE, P95 de leitura por query class e variação de bytes escaneados. Em Redshift Serverless, eu também usaria limites de uso de RPU-hour por dia, semana ou mês; a documentação permite ações como log, alerta ou desligar consultas quando o limite é atingido.

Na segurança, eu evito depender apenas de IAM no bucket. Lake Formation deve expressar permissões por tabela, coluna e, quando aplicável, linha/célula; S3 e KMS devem reforçar perímetro, criptografia e acesso por roles esperadas. Escrita em Iceberg via Redshift não deve usar identidade federada com `SESSION`, conforme a consideração documentada; eu prefiro role estática de plataforma, com permissão mínima para paths específicos da tabela e chaves KMS correspondentes.

Para liderança de engenharia, a métrica mais importante talvez seja tempo de recuperação. Se um MERGE incorreto aplicar deletion vectors ou defaults ruins, como volto a um snapshot anterior, quem aprova, quanto tempo demora e quais consumidores precisam ser reprocessados? Sem essa resposta, a adoção ainda não está pronta.

## Perguntas que eu faria em um design review

### Devo converter todas as tabelas Iceberg v2 para v3?

Não. Eu priorizaria tabelas com evolução frequente de schema, MERGE/DELETE recorrente ou consumidores incrementais. Tabelas append-only estáveis podem continuar em v2 até haver benefício claro e compatibilidade validada.

### Row lineage substitui auditoria regulatória?

Não sozinho. Ele melhora rastreabilidade analítica e incrementalidade, mas auditoria regulatória ainda precisa de trilha de decisões, identidade do ator, aprovação, evidência de origem e retenção controlada.

### Deletion vectors eliminam compactação?

Não. Eles reduzem o custo operacional de deletes em relação a muitos positional delete files, mas tabelas com alta mutação ainda precisam de política de manutenção, reescrita de arquivos e expiração de snapshots.

### Qual é o maior risco no upgrade?

Compatibilidade entre engines e semântica de dados. O Redshift não suporta downgrade de v3 para v2, e há limitações documentadas de tipos. Eu validaria leitores, writers, grants Lake Formation e queries críticas em uma cópia antes da mudança.

> **Minha nota de curadoria:** Eu adotaria Iceberg v3 no Redshift primeiro onde existe dor mensurável: CDC analítico, exclusões regulatórias e evolução de contrato com tabelas grandes. A lição prática é que formatos abertos não reduzem a necessidade de arquitetura; eles deslocam a disciplina para metadados, ownership e operação. Se eu não consigo explicar quem escreve, quem compacta, quem autoriza e quem reprocessa, ainda não tenho um desenho de produção.

## Referências

- [AWS What's New: Amazon Redshift now supports Apache Iceberg v3 tables](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-apache-iceberg-v3/)
- [Documentação do Amazon Redshift: Apache Iceberg v3 features](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-v3-features.html)
- [Documentação do Amazon Redshift: Using Apache Iceberg tables](https://docs.aws.amazon.com/redshift/latest/dg/querying-iceberg.html)
- [Documentação do Amazon Redshift: Apache Iceberg compatibility](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html)
- [Preços do Amazon Redshift](https://aws.amazon.com/redshift/pricing/)
- [AWS Big Data Blog: Iceberg v3 deletion vectors and row lineage](https://aws.amazon.com/blogs/big-data/accelerate-data-lake-operations-with-apache-iceberg-v3-deletion-vectors-and-row-lineage/)
- [Especificação Apache Iceberg](https://iceberg.apache.org/spec/)

## Veredito

Minha recomendação é adotar Redshift com Iceberg v3 de forma seletiva e disciplinada: use em tabelas analíticas mutáveis onde default values, row lineage e deletion vectors resolvem um problema operacional real. Não faça upgrade em massa. Faça inventário de engines, valide tipos suportados, defina ownership de escrita, monitore custo e performance, e trate a migração como mudança de contrato de dados. Para plataformas financeiras, esse lançamento é importante porque aproxima o lakehouse de um modelo auditável e incremental sem abandonar S3, Glue Catalog, Lake Formation e SQL; o valor vem quando a equipe combina o recurso técnico com governança de produção.

**Rating:** adopt selectively