O Crescente uso de Data Lakehouses e a Evolução com Apache Iceberg e Amazon S3 Tables

Por @jessica_andretto e @geoleal

Com o crescimento exponencial da geração e uso de dados, as empresas buscam cada vez mais arquiteturas que aliem escalabilidade, flexibilidade e performance. Nesse cenário, surgem os data lakehouses, uma evolução natural que combina o melhor dos data lakes com as garantias e a confiabilidade dos data warehouses.
Enquanto os data lakes tradicionais se destacam pelo baixo custo e capacidade de armazenamento em larga escala, eles carecem de recursos fundamentais para cargas analíticas mais complexas, como suporte transacional. Isso se torna um entrave quando há a necessidade de atualizar, deletar ou inserir dados de forma eficiente.

Em um data lake tradicional, os dados são armazenados em arquivos imutáveis, sobre um sistemas de armazenamento como o Amazon S3. Isso significa que, para modificar apenas uma única linha, seria necessário:

1. Ler o arquivo inteiro onde está a linha desejada;
2. Fazer a modificação em memória;
3. Reescrever o arquivo completo no storage.

Esse processo é custoso, complexo e difícil de escalar de forma segura. Agora imagine tentar fazer isso em larga escala, com múltiplas atualizações concorrentes e garantia de consistência, algo praticamente inviável em um data lake convencional.
É justamente para resolver essas limitações que surge o conceito de data lake transacional ou lakehouses. Com ele, é possível realizar operações como update, delete e merge e até mesmo consultas retroativas (time travel) com eficiência, sem a necessidade de reprocessar manualmente arquivos ou lidar com orquestrações complexas. Essa evolução transforma o data lake em um ambiente muito mais robusto, confiável e alinhado às necessidades analíticas modernas.

Entre os projetos que viabilizam esse novo paradigma, temos o Apache Iceberg, Delta Lake e Apache Hudi. No ecossistema AWS, o Apache Iceberg tem ganhado protagonismo por sua integração nativa com serviços como Amazon Athena, AWS Glue e Amazon EMR. Com ele, o armazenamento em objetos, como o Amazon S3, passa a ser trabalhado como uma tabela transacional, com suporte a:

• Garantias ACID (Atomicidade, Consistência, Isolamento e Durabilidade)
• Evolução de esquema sem interrupções;
• Versionamento de dados com snapshots;
• Otimizações de leitura e escrita baseadas em metadados.

Esse modelo é reforçado pela nova funcionalidade do Amazon S3 Tables, onde o S3 deixa de ser apenas um repositório de objetos e passa a assumir um papel ativo na estrutura analítica, servindo como base para tabelas transacionais acessíveis por diversas ferramentas analíticas.

Amazon S3 Tables: Uma Nova Abordagem para Tabelas Apache Iceberg

Em 2024, a AWS lançou uma nova funcionalidade chamada Amazon S3 Tables, com o objetivo de simplificar e otimizar ainda mais a experiência com tabelas Apache Iceberg no Amazon S3. Essa novidade promete facilitar a adoção de arquiteturas lakehouse, ao mesmo tempo em que melhora a performance e reduz a complexidade de configuração. Com o Amazon S3 Tables, a AWS oferece uma gestão unificada e integrada das tabelas Iceberg diretamente no ambiente da nuvem, o que traz ganhos operacionais e técnicos.

Essa nova funcionalidade anunciada propõe um desempenho de consulta mais rápido com a otimização contínua das tabelas, incluindo compactação, gerenciamento de snapshots e remoção de arquivos não referenciados, aspectos que costumam ser o calcanhar de Aquiles em ambientes de dados não otimizados. Além disso, permite um volume maior de transações por segundo em comparação com tabelas Iceberg armazenadas em buckets S3 de uso geral.

Comparativo de Performance: Iceberg no Amazon S3 Bucket vs. Amazon S3 Tables

Buscando otimizar custos e melhorar a performance, avaliamos a reestruturação da camada final do Data Lake de um cliente, adotando o conceito de lakehouse. Essa camada era composta por tabelas atualizadas diariamente por fluxos de ETL, mantendo o histórico completo dos dados. Embora o relatório final consumido pelo negócio exigisse apenas a versão mais recente das informações.

Esses dados eram consultados pelo Amazon QuickSight por meio de queries diárias no Amazon Athena, que realizavam uma varredura completa dos registros, filtrando apenas o valor mais recente para cada chave única com base na data de atualização. Com o crescimento do volume de dados históricos, essas consultas passaram a consumir cada vez mais recursos, impactando diretamente o custo no Athena e o tempo de resposta para o usuário final.

Para contornar esse gargalo, avaliamos a adoção do Apache Iceberg, destacando-se por sua capacidade de executar atualizações incrementais de forma eficiente. Diferentemente do data lake tradicional, que exige a regravação completa de arquivos a cada modificação. Essa característica se mostrou essencial para uma das maiores tabelas do ambiente, que passava por alterações frequentes.

Com a experiência já consolidada em Apache Iceberg sobre o Amazon S3, aproveitamos para explorar também a nova funcionalidade do Amazon S3 Tables, que prometia ganhos adicionais de performance e gerenciamento simplificado. Para isso, replicamos dois ambientes equivalentes: um utilizando tabelas Iceberg sobre um bucket S3 de uso geral, e outro com o Amazon S3 Tables. Ambos foram configurados no AWS Glue, com os mesmos recursos computacionais e lógicas de carga, garantindo um cenário justo de comparação.

Nosso objetivo foi avaliar ganhos reais de performance, redução no custo das consultas e a facilidade operacional oferecida por cada abordagem, especialmente no contexto de cargas com atualizações frequentes. Dessa forma, detalhamos abaixo os aspectos técnicos de cada abordagem avaliada: desde a implementação do Apache Iceberg sobre um bucket S3 de uso geral até o uso da nova funcionalidade do Amazon S3 Tables, com foco nas configurações adotadas, desafios enfrentados e os ganhos observados em um ambiente real.

Apache Iceberg no Amazon S3 Bucket

Para trabalhar com tabelas Apache Iceberg armazenadas em um bucket S3 de uso geral, é necessário configurar corretamente o AWS Glue Job, garantindo que ele reconheça e interprete adequadamente os metadados e o formato das tabelas Apache Iceberg. O Amazon S3, por si só, apenas armazena os arquivos, a inteligência sobre como ler e manipular os dados cabe às ferramentas de processamento e catalogação.

• O AWS Glue 3.0 e versões posteriores são compatíveis com a estrutura de tabelas Apache Iceberg
• Permissões necessárias na role do Glue:
  • Acesso ao Amazon S3
  • Acesso ao Glue Data Catalog
• Definição de um parâmetro:
  • datalake-formats : iceberg
• Definição da seguinte configuração usando SparkConf no script:

spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions 
--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog 
--conf spark.sql.catalog.glue_catalog.warehouse=s3:/// 
--conf spark.sql.catalog.glue_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog 
--conf spark.sql.catalog.glue_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO

Observação: a documentação apresenta algumas particularidades de ambientes que podem exigir o uso de diferentes configurações.

Para termos de exploração, foi desenvolvido um código com os requisitos básicos de configuração, criação de tabela, tratamento de duplicação dos dados e operação de merge.

def create_table_iceberg(spark: SparkSession, df: DataFrame, database: str, table: str, s3_path_destination: str):
    try:
        # Constrói a definição do esquema a partir do DataFrame, transformando cada coluna em "NOME TIPO"
        schema = ", ".join([f"{field.name} {field.dataType.simpleString().upper()}" for field in df.schema])        
        # Criação da tabela com local especificado em um bucket de s3 e no Glue Data Catalog
        spark.sql(
            f"""
            CREATE TABLE IF NOT EXISTS glue_catalog.{database}.{table} (
                {schema}
            )
            PARTITIONED BY (years({partition_column}))
            LOCATION '{s3_path_destination}/{table}/'
            """
        )        
    except Exception as e:
        raise

def upsert_data_in_iceberg(spark: SparkSession, df: DataFrame, database: str, table: str, unique_key: list):
    try:
        # Define uma janela de partição baseada no identificador único e ordenada pela data de atualização
        window_spec = Window.partitionBy("unique_id").orderBy(col("updated_date").desc())
        # Mantém apenas a linha mais recente por "unique_id"
        df = df.withColumn("row_num", row_number().over(window_spec)).filter(col("row_num") == 1).drop("row_num")        
        # Cria uma visão temporária para a operação de merge
        df.createOrReplaceTempView(f"temp_{table}")        
        # Executa o MERGE para atualizar ou inserir os dados na tabela Iceberg    
        spark.sql(
            f"""
            MERGE INTO glue_catalog.{database}.{table} AS target
            USING temp_{table} AS source
            ON target.{unique_id} = source.{unique_id}
            WHEN MATCHED THEN
                UPDATE SET *
            WHEN NOT MATCHED THEN
                INSERT *
            """)     
    except Exception as e:
        raise 

Como resultado final, alcançamos um tempo de execução de aproximadamente 6 minutos ao processar uma base com 12 milhões de registros. Além disso, observamos uma redução de 50% no volume de dados escaneados na integração com o Amazon QuickSight, já que cerca da metade dos registros correspondia a dados históricos.

Apache Iceberg no Amazon S3 Tables

De forma semelhante, a utilização do Amazon S3 Tables em um AWS Glue Job também requer configurações específicas para que o job reconheça e interaja corretamente com essa funcionalidade. As configurações não são exigências do Amazon S3 em si, mas sim do Glue para operar com os metadados e a estrutura transacional gerenciada pelas S3 Tables.

• A funcionalidade é compatível com o AWS Glue versão do Glue 5.0 - Supports spark 3.5, Scala 2, Python 3
• Inclusão o do JAR do Amazon S3 Tables Catalog para Apache Iceberg como uma dependência adicional.
• Habilitação da integração do S3Tables com os serviços de analytics (Integration with AWS analytics services)
• Permissões necessárias na role do Glue:
  • Acesso ao Amazon S3 Tables

Assim como no cenário anterior, também foi desenvolvido um código com os requisitos básicos de configuração, criação de tabela, tratamento de duplicação e operação de merge, mantendo a consistência entre os testes.

def create_table_iceberg(spark: SparkSession, df: DataFrame, namespace: str, table: str, s3_path_destination: str):
    try:
        # Constrói a definição do esquema a partir do DataFrame, transformando cada coluna em "NOME TIPO"
        schema = ", ".join([f"{field.name} {field.dataType.simpleString().upper()}" for field in df.schema])
        # Criação da tabela no table bucket conforme definido no spark config
        spark.sql(
            f"""
            CREATE TABLE IF NOT EXISTS s3tablesbucket.{namespace}.{table} (
                {schema}
            )
            USING ICEBERG
            PARTITIONED BY (years({partition_column}))
            """
        )        
    except Exception as e:
        raise

def upsert_data_in_iceberg(spark: SparkSession, df: DataFrame, namespace: str, table: str, unique_key: list):
    try:
        # Define uma janela de partição baseada no identificador único e ordenada pela data de atualização
        window_spec = Window.partitionBy("unique_id").orderBy(col("updated_date").desc())
        # Mantém apenas a linha mais recente por "unique_id"
        df = df.withColumn("row_num", row_number().over(window_spec)).filter(col("row_num") == 1).drop("row_num")        
        # Cria uma visão temporária para a operação de merge
        df.createOrReplaceTempView(f"temp_{table}")        
        # Executa o MERGE para atualizar ou inserir os dados na tabela Iceberg
        spark.sql(
            f"""
            MERGE INTO s3tablesbucket.{namespace}.{table} AS target
            USING temp_{table} AS source
            ON target.{unique_id} = source.{unique_id}
            WHEN MATCHED THEN
                UPDATE SET *
            WHEN NOT MATCHED THEN
                INSERT *
            """)
    except Exception as e:
        raise

Como resultado final, o tempo de execução foi reduzido para cerca de 3 minutos, representando 50% do tempo anterior. Além disso, a redução de 50% no volume de dados escaneados na integração com o Amazon QuickSight foi mantida, uma vez que essa redução não está relacionada ao processo específico, mas sim ao uso de tabelas Iceberg em geral.

Considerações finais

A adoção de tabelas Apache Iceberg no ambiente AWS já demonstrava ganhos significativos em termos de eficiência e otimização de consultas. No entanto, com a chegada do Amazon S3 Tables, observamos um avanço ainda maior na simplificação da aplicação e no ganho de performance.

Os testes realizados mostraram que o Amazon S3 Tables reduziu significativamente o tempo de execução das cargas de dados, diminuindo cerca de 50% o tempo de processamento em comparação com a abordagem tradicional de Apache Iceberg no Amazon S3 Bucket de uso geral. Além disso, a utilização de tabelas Iceberg, independente da abordagem, impactou diretamente a eficiência operacional e a redução de custos com consultas no Amazon Athena, especialmente em cenários que exigem atualizações frequentes dos dados.

Outro benefício importante foi a eliminação de parte da complexidade de configuração e gerenciamento das tabelas Iceberg, um fator crítico em ambientes de dados não gerenciados. Isso torna a adoção do Amazon S3 Tables mais acessível e prática para equipes de engenharia de dados.

Por fim, esse primeiro contato com a funcionalidade demonstrou não apenas ganhos concretos de performance, mas também um potencial estratégico relevante, especialmente para ambientes que priorizam simplicidade e eficiência operacional.

Acompanhe nosso trabalho no LinkedIn!

Geovana Leal Gouvea
Jéssica Andretto

Referências e recomendações de leitura

Amazon S3 Tables: https://aws.amazon.com/pt/s3/features/tables/

New Amazon S3 Tables: Storage optimized for analytics workloads: https://aws.amazon.com/blogs/aws/new-amazon-s3-tables-storage-optimized-for-analytics-workloads/

How Amazon S3 Tables use compaction to improve query performance by up to 3 times: https://aws.amazon.com/blogs/storage/how-amazon-s3-tables-use-compaction-to-improve-query-performance-by-up-to-3-times/

Running ETL jobs on Amazon S3 tables with AWS Glue: https://docs.aws.amazon.com/pt_br/AmazonS3/latest/userguide/s3-tables-integrating-glue.html