Quase toda empresa que roda na AWS já tem dados espalhados por lá: bancos no Amazon RDS, arquivos no Amazon S3, exportações do ERP, planilhas que viram CSV toda sexta-feira. O problema raramente é falta de dado. É falta de um lugar organizado, governado e confiável para consultar esse dado.
O lakehouse resolve exatamente isso: combina o custo e a flexibilidade de um data lake com a organização e o controle de um data warehouse. Neste artigo, mostramos uma arquitetura de referência na AWS e as decisões que mais pesam no resultado.
As camadas de um lakehouse
Uma forma prática de organizar o lakehouse é em três camadas, cada uma com um papel claro:
- Bronze (raw): o dado como chegou da origem, sem transformação. Serve para auditoria e para reprocessar quando algo muda.
- Prata (refinada): dado limpo, com tipos corretos, duplicados removidos e chaves padronizadas.
- Ouro (consumo): tabelas modeladas para o negócio, prontas para BI, análises e modelos de IA.
Todas as camadas ficam no Amazon S3. O que muda de uma para outra é o nível de tratamento e quem tem acesso.
Os serviços da arquitetura de referência
Armazenamento: Amazon S3 com formato de tabela aberto
O S3 é a base. Sobre ele, um formato de tabela aberto como o Apache Iceberg adiciona o que faltava aos data lakes tradicionais: transações, atualização e exclusão de registros, versionamento e evolução de esquema. Isso permite corrigir um dado na camada prata sem reescrever partições inteiras, e consultar como a tabela estava em uma data passada.
Ingestão
A escolha depende da origem:
- Bancos relacionais: AWS Database Migration Service (DMS) com captura de mudanças (CDC), para trazer só o que mudou.
- Aplicações SaaS: Amazon AppFlow, quando houver conector.
- Eventos e streaming: Amazon Kinesis Data Streams ou Amazon MSK.
- Arquivos: carga direta no S3, com eventos disparando o processamento.
Processamento
O AWS Glue cobre a maior parte dos casos: jobs em Spark para transformar bronze em prata e prata em ouro, com o catálogo de dados integrado. Para orquestrar o fluxo, o AWS Step Functions ou o Amazon MWAA (Airflow gerenciado) mantêm as dependências e as reexecuções sob controle.
Consulta e consumo
- Amazon Athena para consultas SQL sob demanda, pagando pelo volume lido.
- Amazon Redshift, quando há carga analítica constante e muitos usuários simultâneos.
- Amazon QuickSight ou a ferramenta de BI que a empresa já usa, conectada à camada ouro.
Governança: o que separa um lakehouse de um depósito de arquivos
Sem governança, o lakehouse vira um data lake caro e desorganizado. Os pontos que não podem faltar:
- Catálogo único. O AWS Glue Data Catalog registra cada tabela, esquema e localização. Se não está no catálogo, não existe.
- Controle de acesso por tabela e coluna. O AWS Lake Formation permite liberar uma tabela para um time e esconder colunas sensíveis de outro, sem duplicar dados.
- Dados pessoais identificados. O Amazon Macie ajuda a encontrar dados pessoais em buckets S3. Com isso mapeado, as exigências da LGPD (minimização, acesso restrito, descarte) deixam de ser um exercício manual.
- Qualidade medida. Regras de qualidade, como as do AWS Glue Data Quality, rodando a cada carga: campos obrigatórios, faixas válidas, unicidade. Um dado que falha não chega à camada ouro.
- Dono para cada domínio. Toda tabela da camada ouro precisa de um responsável no negócio. Tecnologia não resolve dado sem dono.
Custos: onde prestar atenção
Um lakehouse bem desenhado costuma ser mais barato que um data warehouse dimensionado para o pico, mas alguns cuidados fazem diferença:
- Formato colunar e particionamento. Parquet (usado pelo Iceberg) com partições bem escolhidas reduz drasticamente o volume lido pelo Athena, e o custo cai junto.
- Compactação de arquivos pequenos. Muitos arquivos pequenos deixam as consultas lentas e caras. Rotinas de compactação devem fazer parte da operação.
- Ciclo de vida no S3. Dados brutos antigos podem migrar para classes de armazenamento mais baratas automaticamente.
- Jobs dimensionados pelo uso real. Workers do Glue superdimensionados são um desperdício silencioso.
Por onde começar
Não é preciso construir tudo de uma vez. Um caminho que funciona:
- Escolha um caso de uso com valor claro: um relatório que hoje leva dias, uma visão consolidada que ninguém tem.
- Traga duas ou três fontes para a camada bronze e construa o fluxo até a camada ouro.
- Coloque catálogo, controle de acesso e qualidade desde o primeiro dia, mesmo que em escala pequena.
- Só então expanda para novas fontes e novos casos de uso.
Conclusão
Um lakehouse na AWS não é um projeto de ferramentas, é um projeto de organização. S3, Iceberg, Glue, Athena e Lake Formation dão a base técnica; catálogo, qualidade e donos de dados dão a confiança. Comece por um caso de uso, governe desde o início e cresça a partir daí. É essa base que, mais adiante, permite colocar IA em produção com dados em que a empresa confia.