AWS Data Lake Architecture: S3, Glue e Analytics Modernos

A distinção entre data lake e data warehouse começa no esquema. Um data warehouse exige que os dados estejam moldados a uma estrutura antes da carga (schema-on-write): colunas tipadas, transformações feitas antes do armazenamento, tudo organizado para consultas previsíveis. Um data lake inverte isso: os dados chegam no formato original, sejam CSVs de sistemas legados, JSON de APIs, logs brutos ou arquivos Parquet, e o esquema só é definido no momento da leitura (schema-on-read). Isso permite armazenar praticamente qualquer coisa sem decidir antecipadamente como o dado vai ser consumido.

Na AWS, o S3 é o núcleo dessa arquitetura: barato, durável, desacoplado de computação. O problema é que um bucket S3 sem estrutura é só um repositório de arquivos. A arquitetura vem de como você organiza esse conteúdo e quais serviços operam sobre ele.

A arquitetura medallion: raw, refined e curated

A divisão mais difundida para estruturar um data lake é a arquitetura medallion, com três camadas: bronze (ou raw), silver (ou refined) e gold (ou curated). Cada camada tem uma responsabilidade diferente e fica em prefixos ou buckets separados no S3.

A camada bronze recebe os dados exatamente como chegaram da fonte, sem transformação. Um arquivo JSON exportado por um sistema ERP, um CSV com colunas inconsistentes, um log de acesso em texto plano: tudo vai para cá intacto. A ideia é manter o dado original como fonte de verdade, permitindo reprocessar a partir do zero se uma transformação downstream precisar ser corrigida.

A camada silver contém os mesmos dados depois de limpos e padronizados: tipos convertidos, registros duplicados removidos, valores nulos tratados, esquema consistente. O formato típico aqui é Parquet, por razões práticas que veremos adiante. Nessa camada, os dados já podem ser consultados com alguma confiança, mas ainda não estão modelados para um caso de uso específico.

A camada gold é a mais refinada: tabelas agregadas, joins pré-computados, métricas calculadas, dados prontos para consumo por ferramentas de BI, APIs ou times de negócio. É aqui que vivem os modelos dimensionais ou os dados que alimentam dashboards no QuickSight.

Na prática, a separação é feita em prefixos do S3, por exemplo s3://my-datalake/bronze/, s3://my-datalake/silver/ e s3://my-datalake/gold/, com políticas de acesso distintas para cada camada.

S3: armazenamento, particionamento e custo

Dentro de cada camada, a organização dos dados em prefixos de partição é uma das decisões com maior impacto no custo e na performance. O padrão mais comum usa data como chave: s3://my-datalake/silver/orders/year=2025/month=04/day=15/. Quando uma query no Athena filtra por período, o engine consegue pular as partições irrelevantes e varrer só os arquivos necessários, o que reduz tanto o tempo de resposta quanto o custo (Athena cobra por volume de dados lido).

O formato do arquivo importa tanto quanto a partição. Formatos colunares como Parquet e ORC armazenam os dados por coluna, não por linha, o que permite ao engine ler só as colunas necessárias para uma query. Comparado a um CSV equivalente, um arquivo Parquet comprimido com Snappy é tipicamente muito menor e mais rápido de consultar. Para uma camada silver ou gold, não há razão prática para armazenar em CSV.

O custo de armazenamento é administrado com S3 Lifecycle Policies. Dados na camada bronze que raramente serão relidos podem migrar automaticamente para S3 Infrequent Access após 30 dias, e para S3 Glacier para arquivamento depois de alguns meses. A configuração é declarativa e não exige código.

AWS Glue: catálogo, crawlers e ETL

O AWS Glue tem três funções distintas na arquitetura de um data lake. A primeira é o Data Catalog, um repositório centralizado de metadados onde ficam definidos os esquemas das tabelas apontando para prefixos do S3. O Athena, o Redshift Spectrum e o próprio Glue usam esse catálogo para saber como interpretar os arquivos. Sem catálogo, um bucket S3 não tem tabelas, tem arquivos.

A segunda função são os crawlers: processos que inspecionam o conteúdo de um prefixo S3, inferem o esquema e criam ou atualizam as definições de tabela no Data Catalog automaticamente. São úteis quando a fonte de dados muda com frequência ou quando há muitas tabelas para registrar manualmente.

A terceira função são os jobs de ETL. O Glue roda Spark gerenciado: você escreve o script em Python ou Scala, ou usa o Glue Studio para montar visualmente o pipeline, e a AWS cuida do cluster. Os jobs transformam dados da camada bronze para silver, aplicam as limpezas necessárias e escrevem o resultado em Parquet particionado. Para volumes menores ou transformações mais simples, o Glue oferece também o modo Serverless com faturamento por segundo de execução.

Consulta e analytics: Athena, Redshift Spectrum e QuickSight

O Amazon Athena é SQL serverless sobre o S3. Você define a tabela no Data Catalog, aponta para o prefixo com os arquivos Parquet e escreve uma query SQL padrão. O Athena executa usando Presto, cobra por terabyte de dados escaneado e não exige nenhuma infraestrutura para provisionar. Para exploração de dados e relatórios ad hoc, é o caminho mais direto.

O Redshift Spectrum estende essa ideia para quem já usa Redshift como data warehouse. Com Spectrum, uma query no Redshift pode fazer join entre tabelas do warehouse e tabelas externas no S3 sem mover os dados. É útil para casos onde parte dos dados precisa de performance de warehouse e o histórico frio pode ficar no data lake.

Para visualização, o QuickSight se conecta diretamente ao Athena (e por consequência ao Data Catalog), permitindo criar dashboards sem ETL adicional. A configuração exige atenção nas permissões do bucket S3 e do catálogo, mas o fluxo é direto.

Governança com AWS Lake Formation

O Lake Formation é a camada de governança centralizada. Em vez de gerenciar políticas de acesso a cada bucket individualmente, o Lake Formation permite definir permissões no nível de tabela e coluna, usando o Data Catalog como ponto de referência. Um time de dados pode ter acesso de leitura à camada gold sem enxergar os dados brutos da camada bronze, e isso é configurado em um lugar só.

O Lake Formation também suporta row-level security e column-level masking para cenários com dados sensíveis. É um componente que vale adicionar desde o início, porque retroativamente centralizar a governança de um data lake que cresceu sem ela é trabalhoso.

Apache Iceberg e transações ACID no data lake

Um data lake clássico sobre S3 tem uma limitação: não há transações. Se um job falha no meio de uma escrita, os dados parciais ficam no prefixo. Se você quiser apagar registros específicos (por exemplo, para cumprir uma solicitação de exclusão de dados), precisa reescrever o arquivo inteiro. O Apache Iceberg resolve isso.

Iceberg é um table format aberto que adiciona uma camada de metadados sobre os arquivos Parquet no S3, permitindo operações ACID, atualizações e deleções por linha, e time travel (consultar o estado da tabela em um ponto anterior no tempo). O AWS Glue, o Athena e o EMR têm suporte nativo a tabelas Iceberg. Para novos projetos que precisam de mutabilidade nos dados, Iceberg é a escolha padrão na AWS hoje.

Boas práticas e armadilhas

O risco mais comum em data lakes é o data swamp: um bucket cheio de arquivos sem catálogo atualizado, sem particionamento consistente e sem documentação sobre o que cada prefixo contém. Dados chegam, ninguém sabe onde estão, a confiança no repositório cai e ele vira um arquivo morto caro. A solução é estrutural: defina as camadas antes de ingerir, registre cada tabela no Data Catalog desde o primeiro load e estabeleça owners por domínio de dado.

No Athena, varreduras sem filtro em prefixos grandes podem gerar custos relevantes. A mitigação é dupla: particionamento correto (para que o engine pule arquivos desnecessários) e formato colunar (para que leia só as colunas da query). Um scan de 1 TB em CSV pode virar poucos gigabytes em Parquet particionado com o mesmo resultado.

Arquivos muito pequenos também degradam performance. Um diretório com milhares de arquivos de kilobytes cada é mais lento de consultar do que um conjunto de arquivos de 128 a 512 MB. Jobs de compaction periódicos (disponíveis nativamente no Iceberg ou implementados manualmente) resolvem esse problema.

Como começar

Para um primeiro data lake funcional na AWS, o ponto de partida razoável é: criar três prefixos no S3 (bronze, silver, gold), registrar um crawler no Glue apontando para o prefixo silver, rodar uma query de validação no Athena e configurar uma policy de ciclo de vida no bucket bronze para objetos com mais de 90 dias. Esse ciclo curto já entrega valor sem precisar provisionar infraestrutura extra.

Governança e Lake Formation podem vir numa segunda fase, depois que o volume e os casos de uso estiverem mais claros. Iceberg faz sentido introduzir quando aparecer o primeiro requisito de deleção ou atualização de registros individuais. O data lake cresce bem em incrementos, desde que camadas e catálogo estejam definidos desde o início.