Do desenho à governança: zonas no S3, catálogo, tabelas ACID e consumo analítico.
As questões a seguir não foram feitas para “ver se você sabe clicar na AWS”. Elas simulam um momento muito específico (e muito real) da vida de uma plataforma de dados: o instante em que a empresa percebe que migrar dados “do jeito rápido” é como construir um prédio começando pelo 8º andar. Antes de mover um único arquivo, você precisa desenhar o fluxo, separar zonas, decidir padrões de tabela e, principalmente, definir quem pode tocar em quê — porque depois que o dado está no lake, qualquer bagunça vira dívida cara, e qualquer brecha vira incidente.
O primeiro desafio que você vai enfrentar é arquitetural e de linguagem: transformar um objetivo vago (“analisar vendas na nuvem”) em um desenho completo de ponta a ponta, no qual cada bloco tem função, custo e responsabilidade. Não é apenas desenhar um diagrama bonito com ícones; é conseguir defender por que o fluxo proposto é um lakehouse (e não “um monte de arquivos no S3”) e por que isso resolve limitações clássicas de um Data Warehouse tradicional para uma startup que precisa evoluir rápido, aceitar dados semi-estruturados, reprocessar histórico e ainda controlar custos. Se você conseguir fazer isso com clareza, você demonstra domínio do pensamento de arquitetura: trade-offs explícitos, escolhas justificadas e visão de longo prazo.
O segundo desafio é disciplina de organização e operação no S3. Na prática, “zona raw/clean/analytics” é um contrato operacional: define imutabilidade, qualidade esperada, formato, e o que pode (ou não) ser consumido por BI. Ao construir a estrutura de buckets e camadas e ainda aplicar uma política de lifecycle para transicionar dados antigos para Glacier, você vai praticar uma competência raríssima em iniciantes: pensar em custo, retenção e reprocessamento ao mesmo tempo. Quem domina isso não cria um lake; cria um lake que dá para manter.
O terceiro desafio é o que separa um laboratório de um ambiente corporativo: governança e segurança. Definir administrador no Lake Formation e simular políticas IAM com papéis bem recortados (escreve apenas no raw, lê apenas no analytics) força você a pensar como alguém que projeta uma plataforma para múltiplos times — com controle de acesso, rastreabilidade, menor privilégio e separação de responsabilidades. Em outras palavras: você começa a construir o “sistema imunológico” da plataforma antes de ela ganhar massa.
Se você conseguir resolver todas as questões com qualidade, você terá desenvolvido um conjunto de competências que, no mercado, aparecem como “maturidade de plataforma”:
Você será capaz de desenhar uma arquitetura lakehouse completa, explicando o fluxo de dados da origem ao consumo e justificando tecnicamente escolhas de componentes e padrões. Você entenderá por que lakehouse é mais do que S3, e como ACID, catálogo e governança mudam o jogo em evolução de schema, reprocessamento e auditoria.
Você dominará a habilidade de organizar um Data Lake para não virar pântano, definindo zonas com intenção (raw/clean/analytics), separando responsabilidades, e criando bases para qualidade e rastreabilidade. E, crucialmente, você saberá operar custo como requisito, aplicando lifecycle/Glacier de forma alinhada com retenção, auditoria e necessidades reais de reprocessamento.
Você também desenvolverá uma mentalidade de segurança e governança “by design”: não como “camada final”, mas como parte estrutural do projeto. Isso inclui entender a diferença entre acesso ao armazenamento (S3/IAM) e governança no nível de dados (Lake Formation/tabelas), desenhar perfis de acesso mínimos, e implementar segregação que reduz risco e facilita compliance.
Em termos de “qualidades”, o leitor que passa por esse conjunto sai com algo muito específico: capacidade de tomar decisões técnicas sob restrição, com método. Ele aprende a perguntar e responder como um engenheiro responsável: “onde isso vai quebrar?”, “como eu provo que está seguro?”, “como eu evito que o custo exploda?”, “como eu explico a origem desse número daqui a seis meses?”. Resolver estas questões, portanto, não é só acertar a resposta — é demonstrar que você consegue preparar o terreno certo para que a CloudMart migre dados com segurança, governança e escalabilidade, sem transformar a nuvem num caos mais caro que o datacenter antigo.
Você quer definir Uma arquitetura lakehouse na AWS, organizar o S3 por zonas antes de mover dados, e estabelecer governança + IAM (incluindo Lake Formation). Vou assumir um cenário “médio”: dados de vendas vêm de um banco relacional on-prem (ex.: PostgreSQL/MySQL), alguns eventos de e-commerce (clickstream) e arquivos CSV/JSON. O objetivo é análise de vendas (BI) e base para ML no futuro.
(Consenso) A forma “limpa” de fazer isso na AWS hoje é: S3 como storage, catálogo (Glue Data Catalog), governança (Lake Formation), processamento (Glue/EMR/Athena) e consumo (Athena/Redshift/QuickSight). Para “Lakehouse” de verdade, você precisa de um formato de tabela com ACID no lake: Apache Iceberg (ou Hudi/Delta). Vou usar Iceberg como padrão por ser amplamente suportado no ecossistema AWS.
Com isso, a CloudMart tem (1) um desenho lakehouse defensável, (2) zonas no S3 com políticas de custo, (3) um plano de controle de governança (Lake Formation) e (4) IAM mínimo para separar escrita de landing e leitura de consumo. Próximo passo natural é formalizar isso em um ADR completo e depois começar a primeira ingestão (um único domínio de vendas) com testes de qualidade e um mart simples para BI.