Data Lake na AWS: S3, Glue e Athena para Análise de Dados sem Servidor

Uma consulta SQL sobre terabytes de dados brutos, sem provisionar um único servidor, sem cluster para dimensionar e sem software de banco de dados para licenciar — pagando apenas pelos dados que a consulta efetivamente leu. É essa a proposta prática do data lake na AWS: Amazon S3 guardando os dados em qualquer formato, AWS Glue descobrindo e catalogando o que existe ali dentro, e Amazon Athena respondendo perguntas em SQL padrão, cobrando por TB escaneado. Para uma empresa que já tem dados espalhados entre ERP, planilhas, logs de aplicação e exports de CRM, essa combinação costuma custar uma fração de um data warehouse tradicional para o mesmo volume de análise exploratória. Este guia explica como a arquitetura funciona, quando ela vence — e quando perde — para um data warehouse, e o que decide se a conta no fim do mês fica em dezenas de reais ou em milhares.

O Que É um Data Lake e Por Que a Arquitetura Serverless da AWS Virou Referência

Um data lake é um repositório central que armazena dados em seu formato bruto — estruturado, semiestruturado ou não estruturado — sem exigir que o esquema seja definido antes da ingestão. É o oposto do data warehouse tradicional, que exige modelagem prévia (schema-on-write) antes de qualquer linha entrar na tabela. No data lake, o esquema é aplicado no momento da leitura (schema-on-read): você joga o CSV, o JSON, o log ou o Parquet no armazenamento, e decide a estrutura quando for consultar.

Na AWS, essa arquitetura se apoia em três serviços que, juntos, cobrem as três camadas necessárias — armazenamento, metadados e consulta — sem que nenhuma delas exija infraestrutura provisionada:

• Amazon S3 guarda os objetos de dados, com durabilidade de 99,999999999% e sem limite prático de volume.
• AWS Glue Data Catalog mantém o inventário de tabelas, colunas e localizações — o "de onde vêm os dados" que qualquer motor de consulta precisa para funcionar.
• Amazon Athena executa SQL padrão diretamente sobre os arquivos no S3, usando o catálogo do Glue para saber onde procurar.

Nenhum dos três exige que alguém dimensione um cluster ou pague por capacidade ociosa. É essa característica — pagar pelo que se usa, escalar automaticamente, sem nó para reiniciar às 3h da manhã — que faz esse conjunto ser chamado de data lake serverless, e é o motivo pelo qual empresas de 30 a 700 funcionários conseguem montar uma camada analítica real sem contratar um time de dados dedicado.

Como Funciona a Arquitetura: S3, Glue e Athena Trabalhando Juntos

O fluxo típico segue uma sequência previsível, e entender cada etapa ajuda a diagnosticar onde o custo e a lentidão normalmente aparecem.

Ingestão e armazenamento no S3. Os dados chegam de fontes variadas — exportações de banco relacional, eventos de aplicação, arquivos de parceiros — e pousam em buckets S3 organizados por camadas: uma zona bruta (raw) com os dados como chegaram, uma zona processada (com limpeza e padronização) e, opcionalmente, uma zona curada (pronta para consumo por BI). Essa separação em camadas é a prática mais comum de organização de data lake na AWS, e evita que uma consulta de negócio precise lidar com a sujeira dos dados de origem.

Catalogação com o Glue. Segundo a documentação do AWS Glue, o Glue Data Catalog é "seu repositório persistente de metadados técnicos na nuvem da AWS" — um catálogo por conta por região, organizado em bancos de dados e tabelas. Um crawler do Glue varre o S3, infere o esquema (tipos de coluna, formato do arquivo, estrutura de partição) e grava essa metadata no catálogo automaticamente, sem que alguém precise declarar manualmente a estrutura de cada tabela. O Data Catalog funciona como substituto direto do Hive Metastore, o que significa que outras ferramentas do ecossistema — Amazon Redshift Spectrum, Amazon EMR e engines de terceiros compatíveis com Hive — também conseguem ler o mesmo catálogo.

Consulta com o Athena. O Athena é um motor de consulta SQL, baseado em Presto/Trino, que lê diretamente os arquivos no S3 usando as definições de tabela do Glue Data Catalog. Não existe um "banco de dados Athena" com dados próprios: o Athena consulta o que já está no S3, na estrutura que o Glue catalogou. Isso significa que o mesmo conjunto de dados pode ser consultado pelo Athena, processado por um job Glue ETL e usado como fonte externa pelo Redshift Spectrum — tudo apontando para os mesmos arquivos no S3, sem duplicação.

Para quem já opera cargas orientadas a eventos, essa combinação se encaixa bem ao lado de uma arquitetura serverless com Lambda, Step Functions e API Gateway: a mesma lógica de "pagar só pelo que roda" se estende da aplicação até a camada analítica.

Data Lake vs. Data Warehouse: Quando Cada Um Faz Sentido

Essa é a pergunta que decide o projeto antes de qualquer linha de código. Os dois modelos não competem pelo mesmo caso de uso — eles resolvem problemas diferentes, e a maioria das empresas de porte médio acaba precisando dos dois, para finalidades distintas.

Na prática, o padrão mais comum em empresas de 30 a 700 funcionários é usar o data lake como camada de ingestão e exploração — onde tudo chega primeiro, inclusive dado que ninguém sabe ainda se vai usar — e alimentar um data warehouse ou um BI a partir dos dados já limpos e agregados do lake. É o modelo que a AWS chama de lakehouse, e ele existe justamente porque forçar todo dado bruto para dentro de um data warehouse relacional, só para descobrir depois que 80% dele nunca foi consultado, é como a maioria dos projetos de "big data" desperdiça orçamento nos primeiros dois anos.

Governança e Controle de Acesso com AWS Lake Formation

O ponto fraco histórico do data lake — qualquer um com acesso ao bucket vê tudo — tem solução nativa na AWS. Segundo a documentação do AWS Lake Formation, o serviço "ajuda a governar, proteger e compartilhar dados centralmente para analytics e machine learning", com controle de acesso granular sobre os dados no S3 e sua metadata no Glue Data Catalog.

Na prática, o Lake Formation acrescenta um modelo de permissões próprio, que funciona em conjunto com o IAM — não no lugar dele — e permite:

• Controle em nível de coluna, linha e célula. Um analista pode enxergar a tabela de clientes sem ver a coluna de CPF; outro pode ver só as linhas da própria filial. Essa granularidade é aplicada de forma consistente pelo Athena, pelo Redshift Spectrum, pelo Glue ETL e pelo EMR — o mesmo dado, as mesmas regras, qualquer que seja a ferramenta de consulta.
• Controle por tags (LF-Tags). Em vez de conceder permissão tabela por tabela — inviável quando o catálogo cresce para centenas de tabelas —, é possível marcar databases, tabelas e colunas com tags de classificação e conceder acesso por tag. Substitui milhares de políticas individuais por um punhado de rótulos lógicos.
• Auditoria via CloudTrail. Todo acesso aos dados governados pelo Lake Formation gera registro de auditoria, mostrando quem acessou o quê, com qual serviço e quando — o tipo de rastreabilidade que auditoria de compliance costuma exigir.

Vale registrar: o Lake Formation não é obrigatório para um data lake funcionar. É perfeitamente possível rodar S3 + Glue + Athena controlando acesso só via políticas do IAM em buckets e tabelas. O Lake Formation entra quando o número de usuários, tabelas e níveis de sensibilidade de dado cresce a ponto de políticas IAM manuais virarem um risco de erro humano — normalmente o mesmo ponto de maturidade em que vale revisar a arquitetura à luz do AWS Well-Architected Framework, cujo pilar de segurança cobre exatamente esse tipo de decisão.

Modelos de Implementação: Formatos, Particionamento e Catalogação

Três decisões técnicas, tomadas na hora de estruturar o data lake, determinam se ele vai ser rápido e barato ou lento e caro para sempre depois.

Formato colunar em vez de linha. Guardar dados em CSV ou JSON funciona, mas é a forma mais cara de consultar no Athena — o motor precisa ler o arquivo inteiro linha por linha. Formatos colunares como Apache Parquet e ORC comprimem por coluna, permitem que o Athena leia só as colunas necessárias (predicate pushdown) e dividem os dados para leitura paralela. O próprio blog técnico da AWS, no post "Top 10 Performance Tuning Tips for Amazon Athena", traz um exemplo concreto sobre uma mesma consulta: um arquivo texto comprimido em gzip escaneou 23,7 GB; o mesmo dado em Parquet comprimido escaneou 2,0 GB (91% mais barato); e em Parquet ordenado pela coluna filtrada, apenas 38,8 MB (99,9% mais barato). Não é uma média geral — é um teste específico da AWS —, mas ilustra por que o formato do arquivo pesa mais no custo final do que quase qualquer outra decisão de configuração.

Particionamento. Organizar os dados em pastas físicas por critério de filtro comum — ano/mês/dia, região, cliente — permite que o Athena ignore inteiramente as partições que não interessam à consulta, sem nem abrir os arquivos. Um data lake sem partição obriga o Athena a escanear tudo, toda vez; um bem particionado pode reduzir o volume lido de anos para dias em uma única cláusula WHERE.

Catalogação automatizada vs. manual. Rodar crawlers do Glue com frequência agendada mantém o catálogo sincronizado quando o esquema muda — uma coluna nova aparece, um tipo de dado é alterado. A alternativa é declarar tabelas manualmente via CREATE TABLE no Athena ou pela API do Glue, o que dá controle fino mas exige disciplina para manter atualizado. Ambientes com muitas fontes de dado tendem a usar crawlers; ambientes com poucas tabelas bem conhecidas costumam preferir declarar manualmente e evitar o custo (e a imprevisibilidade) de crawler rodando sem necessidade.

Quanto Custa de Verdade: o Modelo de Cobrança por TB Escaneado

Esta é a informação que mais frequentemente aparece errada em conversa informal — e é a que decide se o data lake compensa ou não para o volume de dados da empresa.

Athena cobra por dado escaneado, não por tempo de execução. Segundo a página oficial de preços do Amazon Athena, o preço padrão para consultas SQL é de US$ 5,00 por TB de dados escaneados, na maioria das regiões dos EUA — não há cobrança por hora de cluster nem por número de consultas, e não existe custo fixo mensal. Uma consulta que escaneia 3 TB custa US$ 15; a mesma pergunta, feita sobre os mesmos dados já convertidos para Parquet particionado, pode escanear uma fração disso.

Glue cobra por DPU-hora usado. De acordo com a página de preços do AWS Glue, jobs de ETL e crawlers são cobrados a US$ 0,44 por DPU-hora, faturado por segundo (uma DPU equivale a 4 vCPUs e 16 GB de memória). O Glue Data Catalog em si é gratuito até 1 milhão de objetos de metadados armazenados e 1 milhão de requisições por mês — o que cobre a maioria das empresas de porte médio sem gerar cobrança nenhuma pelo catálogo.

S3 cobra por armazenamento e por classe. O custo de manter os dados no S3 varia pela classe de armazenamento escolhida: S3 Standard para dados acessados com frequência, S3 Intelligent-Tiering quando o padrão de acesso é imprevisível (move automaticamente entre camadas, sem taxa de recuperação), S3 Standard-IA para dados acessados poucas vezes ao mês, e as classes S3 Glacier Instant Retrieval, Flexible Retrieval e Deep Archive para dados de retenção longa e acesso raro. Um data lake típico usa Standard para a zona processada/curada, ativamente consultada, e Intelligent-Tiering ou Glacier para a zona bruta histórica, raramente reconsultada.

A regra prática que resume os três: o custo do data lake é proporcional a quanto dado é lido, não a quanto dado existe. Isso inverte a lógica de um data warehouse provisionado, onde o cluster custa o mesmo esteja ocupado ou ocioso. É também por isso que a mesma disciplina de FinOps que se aplica ao restante da conta AWS — descrita no guia completo de FinOps na AWS — vale igualmente aqui: formato de arquivo errado e ausência de partição são desperdício silencioso, que a fatura só revela no fim do mês.

Casos de Uso por Porte de Empresa

O ponto de entrada certo para o data lake muda conforme o tamanho e a maturidade de dados da empresa.

Empresas de 30 a 100 funcionários, tipicamente sem time de dados dedicado, costumam começar pequeno: um bucket S3 recebendo exports do ERP e do CRM, um crawler do Glue rodando semanalmente, e o Athena usado sob demanda para responder perguntas pontuais de negócio ("qual foi o ticket médio por região no trimestre") sem precisar abrir uma planilha de 200 mil linhas no Excel. O investimento inicial é essencialmente zero — não há licença, não há servidor para manter.

Empresas de 100 a 300 funcionários, com mais fontes de dado e mais gente pedindo relatório, costumam formalizar as camadas (raw/processada/curada), automatizar a ingestão com jobs Glue agendados e conectar uma ferramenta de BI (Amazon QuickSight ou equivalente) direto ao Athena. É também o ponto em que particionamento e formato colunar deixam de ser otimização e passam a ser necessidade — o volume de dados já dói na fatura se ficar em CSV.

Empresas de 300 a 700 funcionários, com múltiplas áreas de negócio e requisitos de compliance mais pesados, tipicamente introduzem o Lake Formation para governança granular, combinam o data lake com um data warehouse (modelo lakehouse) para os relatórios executivos recorrentes, e tratam o catálogo de dados como ativo de governança formal — com dono, política de retenção e revisão periódica, no mesmo espírito de maturidade operacional que já se aplica ao restante da infraestrutura em nuvem.

Tendências: Lakehouse e Apache Iceberg

A linha entre data lake e data warehouse está ficando mais fina, não mais grossa. O termo "lakehouse" descreve exatamente essa convergência: armazenamento barato e flexível do data lake, com garantias transacionais (ACID), versionamento de esquema e performance de consulta que antes só um data warehouse oferecia.

O motor por trás dessa convergência, hoje, é o Apache Iceberg — um formato de tabela aberto que roda sobre arquivos Parquet no S3, mas adiciona controle transacional, evolução de esquema sem reescrever dados históricos e viagem no tempo (consultar o estado da tabela em uma data passada). O AWS Glue Data Catalog já suporta tabelas Iceberg nativamente, e o Athena consulta essas tabelas com SQL padrão, sem sintaxe especial. Na prática, isso significa que um data lake bem estruturado hoje já nasce com o caminho aberto para funcionalidades que, há poucos anos, exigiam migrar para um data warehouse fechado.

A outra tendência visível é o Lake Formation absorvendo cada vez mais fontes além do S3 — federando catálogos de Amazon Redshift, bancos relacionais e até fontes de terceiros no mesmo Data Catalog, o que aponta para um futuro em que "onde o dado mora fisicamente" importa cada vez menos do que "quem pode consultar o quê, com qual ferramenta".

Perguntas Frequentes sobre Data Lake AWS

Qual a diferença prática entre data lake e data warehouse na AWS?

O data lake (S3 + Glue + Athena) armazena dados em qualquer formato, sem exigir estrutura definida antes da ingestão, e cobra por consulta. O data warehouse (Amazon Redshift) exige modelagem prévia dos dados e é otimizado para consultas repetitivas de BI, com custo baseado em capacidade provisionada. A maioria das empresas de porte médio usa os dois: o lake para ingestão e exploração, o warehouse para relatórios recorrentes.

O Amazon Athena precisa de um cluster para funcionar?

Não. O Athena é totalmente serverless — não existe cluster para provisionar, dimensionar ou pausar. Cada consulta dispara a leitura direta dos arquivos no S3, orquestrada pela AWS, e a cobrança é por volume de dados escaneado, não por tempo de cluster ativo.

Quanto custa manter um data lake pequeno na AWS?

Depende quase inteiramente do volume de dados escaneado nas consultas do Athena (US$ 5,00 por TB) e do volume armazenado no S3 (que varia por classe de armazenamento). Para uma empresa de porte médio, com dados bem particionados em Parquet, é comum o custo mensal de consulta ficar em dezenas de dólares — o problema normalmente não é o serviço, é dado mal formatado forçando o Athena a escanear TBs desnecessários.

O que o AWS Glue Data Catalog realmente cataloga?

Metadados técnicos: nome da tabela, colunas, tipos de dado, formato do arquivo e localização no S3 — não os dados em si. É esse catálogo que permite ao Athena (e a outros serviços como Redshift Spectrum e EMR) saber onde procurar e como interpretar o que encontrar, sem que cada ferramenta precise redescobrir a estrutura sozinha.

Preciso do AWS Lake Formation desde o primeiro dia?

Não. Um data lake pequeno, com poucos usuários e tabelas, funciona bem só com políticas de IAM em buckets S3 e tabelas do Glue. O Lake Formation compensa quando o número de usuários, tabelas e níveis de sensibilidade de dado cresce a ponto de tornar inviável gerenciar permissão tabela por tabela manualmente.

Parquet é sempre melhor que CSV para um data lake?

Para consulta analítica no Athena, sim, quase sempre — Parquet reduz o volume de dados escaneado (e portanto o custo) por ser colunar e comprimido, além de acelerar a consulta. A exceção é dado que só será lido por completo raramente ou por ferramentas que exigem formato de linha; nesses casos, o ganho do formato colunar não compensa o esforço de conversão.

Data lake substitui o data warehouse que a empresa já tem?

Raramente por completo. O padrão mais comum é o data lake absorver dados brutos e variados que hoje não têm lugar nenhum — logs, exports, dados semiestruturados — e alimentar, já limpo e agregado, o data warehouse existente. É um complemento à camada de BI corporativo, não uma substituição imediata dela.

Um Data Lake Serverless na AWS Custa o Que Você Consulta, Não o Que Você Guarda

A vantagem real de S3, Glue e Athena não é nenhum recurso isolado — é a inversão do modelo de custo. Em vez de pagar por capacidade reservada, ociosa na maior parte do tempo, a empresa paga pelo volume de dados efetivamente lido em cada pergunta que faz. Isso torna viável, para uma empresa de porte médio, ter uma camada analítica real sobre dados que hoje estão espalhados e inacessíveis — sem contratar um time de dados nem assinar um contrato de licença de data warehouse antes de saber se vai usar.

O que decide se essa conta fica pequena ou explode é decisão de arquitetura, não sorte: formato colunar, particionamento correto e um catálogo bem mantido. Quem trata essas três decisões como parte do desenho inicial — e não como ajuste posterior — paga centavos pelas mesmas perguntas que, num data lake malformatado, custam dezenas de dólares por consulta.

Artigos Relacionados

• EC2, S3 e RDS para PMEs: o Guia Completo de Nuvem AWS — cobre o S3 como armazenamento de propósito geral; este artigo aprofunda o papel específico do S3 como camada de um data lake analítico.
• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — a mesma disciplina de eliminar desperdício por inércia se aplica ao custo por TB escaneado do Athena.
• Arquitetura Serverless na AWS: Lambda, Step Functions e API Gateway — o data lake é a peça analítica do mesmo modelo de pagar só pelo que roda.
• AWS Well-Architected Framework: o Guia Avançado — o pilar de segurança é a referência para decidir quando introduzir governança formal com o Lake Formation.