Fundamentos da Arquitetura Lakehouse: Lakes, Warehouses e o Padrão Medalhão

A AWS define o termo assim: "Um lakehouse de dados é uma arquitetura de dados unificada que combina data warehouses e data lakes, oferecendo capacidades de analítica como estruturação, governança e geração de relatórios. O lakehouse de dados pode armazenar dados brutos em uma variedade de formatos, de milhares a centenas de milhares de fontes, em um local central" (AWS What is a Data Lakehouse?, acesso em 2026-10-11). A mesma página acrescenta a frase que governa cada decisão de design deste curso: "O compute de um lakehouse de dados é separado do armazenamento. Com armazenamento e compute separados, você pode escalar essas funções de forma independente para maximizar a economia de custos."

Isso é uma definição, ainda não uma arquitetura. Entre a frase e uma plataforma em funcionamento há três perguntas que esta lição responde: qual store você realmente está construindo (lake, warehouse ou lakehouse), como os dados são estratificados dentro dele (o padrão medalhão) e como ele é processado (batch, Lambda ou Kappa): mais o mapa de serviços da AWS que implementa cada posição. Tudo da lição 02 até a lição 17 é detalhe de implementação do esqueleto que você constrói aqui.

A maioria das equipes encontra essas três palavras na ordem errada: escolhe os serviços primeiro, depois descobre que não tem nem uma fonte única de verdade nem um arquivo barato. Nós faremos ao contrário, o padrão primeiro, os serviços em segundo lugar.

Nesta lição você vai:

• separar um data lake, um data warehouse e um lakehouse usando as definições publicadas pela AWS e depois aplicar uma tabela de decisão a requisitos concretos;
• ler as seis diferenças publicadas pela AWS (timing de schema, qualidade de dados, usuários, adequação analítica, preço/desempenho, posture de custo) que decidem o store antes de qualquer serviço ser nomeado;
• entender por que Parquet no Amazon S3 ainda não é um lakehouse e que capacidades um formato de tabela aberto adiciona;
• atribuir responsabilidades às camadas medalhão bronze, silver e gold e mapear cada uma a primitivas reais da AWS (buckets, prefixos, databases do Glue, tabelas Iceberg);
• escolher entre os padrões de processamento somente batch, Lambda e Kappa, incluindo a armadilha de nomenclatura sobre a qual o próprio whitepaper da AWS avisa;
• posicionar dez serviços analíticos centrais, S3, Glue, Athena, Redshift, QuickSight, Kinesis, MSK, EMR, Lake Formation, Macie, em um único mapa de camadas;
• percorrer a arquitetura de referência ponta a ponta duas vezes: como diagrama de fluxo e como diagrama de sequência, além da visão de contêineres com múltiplas contas;
• resolver sete exemplos resolvidos com preços usando preços de lista reais (em out 2026), incluindo um esboço de dimensionamento de pipeline de 10 TB/dia;
• estudar três casos de clientes da AWS, FINRA, Easygo e BMW Group, e ler os números deles como um profissional deve ler;
• conferir a caixa de atualizações de 2026 (S3 Tables, S3 Vectors, Glue 6.0, Quick Suite) e o roadmap do curso para as dezesseis lições que se seguem.

---

1. Lake, warehouse, lakehouse: as três definições que a AWS realmente publica

Três termos, três promessas diferentes. O caminho mais rápido para usá-los mal é tratá-los como tamanhos ("somos grandes demais para um warehouse") em vez de tratá-los como contratos sobre schema, curadoria e acesso.

1.1 O data warehouse

Página de comparação da AWS: "Um data warehouse armazena dados em formato estruturado. É um repositório central de dados pré-processados para analítica e business intelligence." A página de conceitos de data lake acrescenta o mecanismo: "Um data warehouse é um banco de dados otimizado para analisar dados relacionais vindos de sistemas transacionais e de aplicativos de linha de negócio. A estrutura dos dados e o schema são definidos antecipadamente… Os dados são limpos, enriquecidos e transformados para que possam atuar como a 'fonte única de verdade' em que os usuários podem confiar."

O movimento definidor do warehouse é schema on write: o formato e o padrão de qualidade são decididos antes dos dados chegarem, e é por isso que a mesma página pode atribuir a ele "relatórios em lote, BI e visualizações" e "dados altamente curados que servem como a versão central da verdade" (página de comparação da AWS, acesso em 2026-10-11). Na AWS, a expressão gerenciada desse padrão é o Amazon Redshift (RA3 provisionado e Serverless, com Spectrum para tabelas de lake).

1.2 O data lake

AWS: "Um data lake é um repositório centralizado que permite armazenar todos os seus dados estruturados e não estruturados em qualquer escala" (AWS What is a Data Lake?, rodapé da página "Updated 2025", acesso em 2026-10-11). A página de comparação fornece o counterpart do schema-on-write: o schema é "Escrito no momento da análise (schema-on-read)", a qualidade de dados é "Quaisquer dados que podem ou não ser curados" e a lista de analítica é "Machine learning, analítica exploratória, data discovery, streaming, analítica operacional, big data e profiling".

A disciplina de carga decorre disso: "As organizações normalmente usam ferramentas de Extract, Load, Transform (ELT). Elas carregam os dados no lake primeiro e os transformam apenas quando necessário." O argumento de custo é explícito: "data lakes oferecem um custo comparativamente menor para mais volume, especialmente para grandes quantidades de imagens e vídeos". O modo de falha é igualmente explícito, e você vai encontrá-lo em todo post-mortem: "um data lake não gerenciado pode levar a data swamps. Data swamps são um estado de dados desorganizados que dificulta a extração de insights significativos" (AWS What is a Data Lakehouse?, acesso em 2026-10-11).

1.3 O lakehouse

O lakehouse é a combinação, e a AWS tem o cuidado de chamá-lo de arquitetura, não de produto. O whitepaper legado da AWS o formula como um padrão: "Lake house: Uma lake house é um padrão arquitetural que combina os melhores elementos de data warehouses e data lakes. Lake houses permitem consultar dados entre o seu data warehouse, o seu data lake e bancos de dados operacionais… Com uma arquitetura lake house, você pode armazenar dados em formatos de arquivo abertos no seu data lake e consultá-los no lugar, fazendo join com dados do data warehouse" (AWS Data Warehousing on AWS, banner da página: "This whitepaper is for historical reference only", acesso em 2026-10-11).

A AWS também publica as camadas lógicas desse padrão, que se tornam a espinha dorsal de todo este curso:

1.4 A tabela de decisão

Esta é a tabela para manter aberta durante cada design review. Cada linha vem da comparação warehouse-versus-lake da página de comparação da AWS mais a página de definição de lakehouse (todas com acesso em 2026-10-11).

Como usar a tabela. Comece na última linha e leia de baixo para cima. Se a frase de requisito contém fonte única de verdade e SLAs apertados de BI, você está na coluna 1. Se contém imagens, vídeos, treino de modelo, schema desconhecido no ano que vem, você está na coluna 2. Se contém ambos, e eu me recuso a copiar os dados duas vezes, você está na coluna 3, e o FAQ do SageMaker Lakehouse declara o motivo econômico sem rodeios: "você não precisa migrar os seus dados… acesse e consulte os seus dados no lugar" (acesso em 2026-10-11).

Note que a AWS não apresenta isso como um concurso de tudo-ou-nada: "A maioria das grandes organizações usa uma combinação de data lakes, warehouses e marts em sua infraestrutura de armazenamento" (página de comparação da AWS, acesso em 2026-10-11). O lakehouse é a arquitetura que permite que essas peças compartilhem uma única cópia governada em vez de três.

• 📚 Você sabia? A página de comparação da AWS trata lake, warehouse e mart como inventário complementar, não como rivais: "A maioria das grandes organizações usa uma combinação de data lakes, warehouses e marts em sua infraestrutura de armazenamento" (acesso em 2026-10-11). A armadilha funciona nos dois sentidos: qualquer documento de design que afirme que você precisa escolher exatamente um dos três está discutindo com a própria página da AWS.

---

2. Por que Parquet no Amazon S3 ainda não é um lakehouse

Esta é a confusão mais cara do campo, por isso ganha sua própria seção. Um bucket cheio de arquivos Parquet bem particionados e bem comprimidos é um data lake. Ele vira um lakehouse apenas quando uma camada de metadados transacional se assenta sobre ele.

O AWS Prescriptive Guidance é incomumente direto sobre o que falta aos lakes comuns. Lakes de objetos tradicionais/no formato Hive "não fornecem suporte a semântica de processamento ACID (atomicidade, consistência, isolamento e durabilidade)", e não podem nativamente:

• "Realizar atualizações e exclusões eficientes em nível de registro à medida que os dados mudam no seu negócio";
• "Gerenciar o desempenho de queries à medida que as tabelas crescem até milhões de arquivos e centenas de milhares de partições";
• "Garantir consistência de dados entre múltiplos escritores e leitores concorrentes";
• "Prevenir corrupção de dados quando operações de escrita falham no meio da operação";
• "Evoluir schemas de tabela ao longo do tempo sem (parcialmente) reescrever os datasets".

(Using Apache Iceberg on AWS, Modern data lakes, acesso em 2026-10-11.) A mesma fonte observa que essas lacunas são "particularmente prevalentes" para change data capture, privacidade/exclusão e ingestão de streaming, três workloads que este curso cobre nas lições 05, 06 e 13.

O formato de tabela aberto responde com uma lista de recursos que a AWS publica literalmente:

• "Excluir, atualizar e mesclar"
• "Planejamento de scan rápido e filtragem avançada"
• "Evolução completa de schema"
• "Evolução de partição"
• "Particionamento oculto"
• "Rollback de versão"
• "Time travel"
• "Isolamento serializável"
• "Escritores concorrentes"
• "Formatos de arquivo abertos" (Parquet, Avro, ORC)

Dois fatos de apoio que você vai reutilizar em todo o curso: a AWS lista o Apache Iceberg como "suportado por serviços AWS como Amazon EMR, Amazon Athena, Amazon Redshift, AWS Glue e Amazon SageMaker", e "o Athena… usa o AWS Glue Data Catalog como o metastore do Iceberg" (Prescriptive Guidance, acesso em 2026-10-11). O catálogo e o formato de tabela são componentes diferentes que precisam ser desenhados juntos: uma distinção que a lição 07 torna operacional.

---

3. O padrão medalhão: bronze, silver e gold

Uma vez tomada a decisão de store, a próxima pergunta é que formato os dados assumem à medida que saem do cru e entram na confiança? A resposta da AWS é a arquitetura medalhão, definida no próprio workshop do Builder Center da AWS como "um padrão de design de dados que promove qualidade, consistência e governança de dados por meio de uma abordagem em camadas" (acesso em 2026-10-11).

3.1 As três camadas e suas responsabilidades

Três propriedades desta tabela valem a pena memorizar. Primeiro, as camadas são progressivas: cada salto eleva a garantia e estreita o público. Segundo, a camada é um limite lógico, não um produto da AWS: bronze/silver/gold mapeiam para prefixos ou buckets S3, databases do Glue Data Catalog e tabelas Iceberg; a AWS apresenta o padrão em um workshop e em um blog, não como um serviço gerenciado. Terceiro, o caminho de quarentena faz parte do silver, não é um pensamento posterior: um registro que falha em uma regra precisa cair em algum lugar observável, em vez de desaparecer em silêncio.

3.2 O padrão medalhão na AWS, ponta a ponta

3.3 O que cada camada não é

• Bronze não é uma zona de despejar e esquecer. Ainda precisa de regras de retenção, criptografia e uma entrada no catálogo; a best practice BP 3.7 do Well-Architected Data Analytics Lens é "Implementar políticas de retenção de dados para cada classe de dados no workload de analítica", e a BP 3.5 é "Registrar classificações de dados no Data Catalog para que os workloads de analítica possam entender" (AWS Well-Architected Data Analytics Lens, data de publicação 2023-12-22, anunciado como lens em 26 de março de 2024; acesso em 2026-10-11).
• Silver não é opcional se você quer um lakehouse e não um swamp: é onde "um data lake não gerenciado pode levar a data swamps" é prevenido, uma tabela validada por vez. A Lens BP 1.1 é "Validar a qualidade de dados dos sistemas de origem antes de transferir dados para analítica", e a BP 1.2 é "Monitorar métricas operacionais dos jobs de processamento de dados e a disponibilidade dos dados de origem".
• Gold não é "o extrato de relatório". Ainda é uma tabela aberta que Athena, Redshift, SageMaker e motores de terceiros podem consultar no lugar: é isso que impede que ela vire um silo proprietário dois anos depois.

O ponto de partida prescritivo da AWS para um salto batch noturno, se você quer números em vez de opiniões: "Tamanho do arquivo: 128 MB, porque tarefas do Apache Spark processam dados em blocos de 128 MB"; "Tipo de escrita: copy-on-write"; "Variáveis de partição: year/month/day"; "Ordem de classificação: timestamp"; "Data catalog: AWS Glue Data Catalog" (AWS Prescriptive Guidance, arquiteturas de referência para Apache Iceberg na AWS, acesso em 2026-10-11).

Exemplo resolvido E1: quantos arquivos um dia de bronze realmente cria? (em out 2026)

Uma fonte entrega 10 TB por dia no bronze, e você segue o tamanho de arquivo alvo do Prescriptive Guidance de 128 MB para que tarefas do Spark mapeiem um-para-um com os arquivos.

• 1 TB = 1,024 GB = 1,048,576 MB, logo 10 TB = 10,485,760 MB
• 10,485,760 MB ÷ 128 MB = 81,920 arquivos por dia
• Com particionamento year/month/day (a recomendação da AWS), uma única partição-dia recebe cerca de 82,000 objetos, e é exatamente por isso que "tabelas crescem até milhões de arquivos" aparece na lista de problemas de lakes comuns da AWS, e por que a compactação (lição 04) e o planejamento de partições (lição 03) não são extras opcionais
• Um mês de bronze nesse ritmo: 81,920 × 30 = 2,457,600 arquivos. Gerencie esse número com metadados do Iceberg, não com ls em um bucket

Takeaway: as camadas medalhão são baratas de descrever e caras de pular. O salto bronze→silver é onde a qualidade de dados mora, o salto silver→gold é onde o significado de negócio mora, e a faixa catálogo mais Lake Formation é o que torna ambos legíveis pelas pessoas certas.

• 📚 Você sabia? A AWS publica uma versão de três frases desse padrão: com materialized views do Apache Iceberg no Amazon SageMaker, "você pode construir uma arquitetura medalhão Bronze, Silver e Gold como três statements SQL", e quando você configura o refresh agendado, "o AWS Glue Data Catalog usa compute Spark gerenciado para atualizar incrementalmente a materialized view" (AWS Big Data Blog, acesso em 2026-10-11). O padrão é portátil, o mecanismo (quem roda o refresh, em qual compute) é o que você realmente está escolhendo nas lições 08 e 11.

---

4. Batch, Lambda ou Kappa: escolhendo o padrão de processamento

As camadas medalhão dizem que formato os dados assumem. O padrão de processamento diz quantos pipelines você precisa construir, testar e operar. Existem três respostas documentadas, e a AWS publica as três.

4.1 Somente batch

Aterre arquivos ou streams no S3, processe em um agendamento (Glue ou EMR), sirva com Athena ou Redshift. A "batch layer" do whitepaper de Lambda produz "batch views" que são "armazenadas em uma camada de armazenamento persistente". Simples, o mais barato de rodar, e a latência é igual ao seu agendamento: um job noturno significa que dashboards estão, no pior caso, uma noite defasados, e cada arquivo que chega atrasado se silenciosamente no incidente da semana seguinte.

4.2 Arquitetura Lambda (o padrão)

O whitepaper da AWS a define como "um padrão de design de processamento de dados para lidar com quantidades massivas de dados e integrar processamento em lote e em tempo real dentro de um único framework". Dois caminhos rodam em paralelo:

• uma batch layer calculando batch views autoritativas: exatas, completas, recalculadas sobre o histórico inteiro;
• uma speed layer produzindo incremental views, "Kinesis Data Firehose, À medida que os dados são ingeridos em tempo real, os clientes podem usar o Kinesis Data Firehose para facilmente agregar e comprimir os dados para gerar incremental views";
• uma camada de serving onde "a query mesclada tem como objetivo unir e analisar os dados da batch view da batch layer e da incremental stream view da speed layer".

O custo operacional dessa correção é que você agora é dono de dois codepaths que precisam concordar, mais um passo de mescla que precisa reconciliar dados atrasados e fora de ordem.

4.3 Arquitetura Kappa

Um pipeline, um codebase, reprocessamento por replay. O walkthrough do Builder Center da AWS (18 de maio de 2026, acesso em 2026-10-11): "É Kappa: um único pipeline unificado de streaming que lida com tudo. Na AWS, isso significa Kinesis Data Streams, Spark Structured Streaming no EMR…": com um formato de tabela no S3 como camada durável e uma "janela de replay de 24 horas: o Kinesis retém eventos" conforme apresentado naquele artigo.

Kappa troca a exatidão da batch layer por simplicidade operacional: a correção vem da capacidade de fazer replay do mesmo código sobre o mesmo log, o que só é possível dentro da janela de retenção do stream: tudo mais antigo precisa vir do lake (veja §8.2).

4.4 A escolha, em uma tabela

Exemplo resolvido E2: um requisito, três arquiteturas, com preços (em out 2026)

Requisito: clickstream de e-commerce + pedidos + dumps noturnos de ERP; a diretoria quer dashboards em até 15 minutos após o pouso dos dados, mais um sandbox de ciência de dados. Duzentos leitores de dashboard.

• Custo compartilhado de serving: 200 leitores × $3 por usuário/mês = $600.00 por mês (QuickSight Reader, página de preços com acesso em 2026-10-11).
• Custo compartilhado de transformação batch: um job noturno bronze→silver a 10 DPU × 20 minutos = 3.333 DPU-hours × $0.44 = $1.47 por noite, ou seja, $44.00 por mês.
• Custo compartilhado de consulta: se a camada de BI escanear 1 TB por dia no agregado, são 30 TB/mês × $5.00 por TB = $150.00 por mês no Athena.
• (a) Somente batch: apenas essas três linhas, cerca de $794.00 por mês de gasto serverless diretamente atribuível, mas o frescor do dashboard é igual à cadência do job, então um SLA de 15 minutos forçaria 96 execuções por dia em vez de uma, multiplicando a linha do Glue por ~96 e ainda falhando em modelar eventos ao vivo.
• (b) Lambda: o mesmo caminho batch mais um caminho speed de Kinesis → streaming job gravando incremental views nas mesmas tabelas gold. O frescor cai para segundos em eventos recentes; agora você é dono de dois codepaths mais a mescla. O caminho de streaming adiciona cobranças de Kinesis Data Streams e de compute de streaming: orçe essas separadamente, porque esta lição só ancora preços publicados pela AWS nas páginas de Glue, Athena e QuickSight.
• (c) Kappa: um único caminho de Kinesis → Spark Structured Streaming para o formato de tabela no S3, com backfills refeitos a partir do stream dentro da janela de replay de 24 horas apresentada, e a partir do lake além dela.

Veredito para este cenário: o SLA de 15 minutos elimina o somente batch em qualquer contagem razoável de execuções, e um time de cinco pessoas não consegue confortavelmente manter dois codepaths de produção, então Kappa, com o lake (não o stream) como system of record do histórico. Isso é um juízo sustentado pela tabela do §4.4, não uma regra universal: se um requisito regulatório exigir recálculo exato em batch de cada view histórica, o Lambda continua sendo o padrão correto.

• 📚 Você sabia? O whitepaper de Lambda fecha com um fato que explica por que todo este curso pode ser serverless: "Amazon Glue, Amazon S3, Amazon Athena e Amazon Kinesis são serviços serverless." Você pode rodar as camadas batch, speed e serving de qualquer um dos três padrões sem provisionar um cluster, e é por isso que as linhas de custo do E2 são citadas por hora e por TB, e não por instância (AWS Lambda Architecture whitepaper, acesso em 2026-10-11).

---

5. O panorama de serviços analíticos da AWS: onde cada serviço se encaixa

O próprio guia de estratégia da AWS resume o mapa em uma frase: "você pode executar streaming em tempo real com o Kinesis ou o Amazon MSK, processamento de dados com o Amazon EMR ou o AWS Glue, busca com o Amazon OpenSearch, queries ad hoc com o Athena e data warehousing com o Amazon Redshift" (AWS Prescriptive Guidance, AWS modern data architecture, acesso em 2026-10-11). A governança atravessa a frase inteira: "O AWS Lake Formation ajuda a governar dados e a compartilhá-los pela empresa. Além disso, você pode criar um data catalog exclusivo no AWS Glue e um glossário de negócios usando o Amazon DataZone… para permitir que seus funcionários encontrem os dados de que precisam."

5.1 O elenco, uma linha para cada

5.2 Regras de posicionamento que sobrevivem à tabela

1. O S3 é o piso. Todo padrão da lição 01 aterra dados no S3 ou no S3 Tables primeiro; nada acima da camada de armazenamento pode virar o system of record.
2. O Glue é a espinha, não apenas um executor de jobs. Ele é dono do catálogo (camada de metadados) e da transformação serverless (bronze→silver→gold). A lição 07 é inteiramente este serviço.
3. Athena e Redshift são alternativas sobre a mesma cópia, não rivais. Ambos consultam S3/Iceberg; o Redshift adiciona concorrência gerenciada, materialized views, data sharing e uma experiência de warehouse a custo de nó/RPU, enquanto o Athena é serverless e pay-per-TB-scanned: ideal para uso ad hoc e federado (exemplo resolvido E6).
4. O Lake Formation é uma faixa, não uma caixa. Ele envolve o catálogo e as tabelas, e os seus grants valem entre motores, não para uma ferramenta.
5. O Macie classifica; o Lake Formation autoriza; o Glue cataloga. Três serviços, três empregos. Confundir os dois primeiros é uma falha de security review, não preciosismo de nomenclatura.
6. O EMR é a ferramenta de potência. Spark, Flink, Trino e Hive em escala petabyte quando o Glue serverless não basta, e o EMR Serverless quando você quer essa potência sem uma frota de clusters.

• 📚 Você sabia? O Amazon Macie nunca aparece sozinho na lista de segurança de modern data architecture da AWS: ele é nomeado com "AWS Key Management Service (AWS KMS), AWS Identity and Access Management (IAM), AWS Secrets Manager, AWS Audit Manager e Amazon Macie" (AWS Prescriptive Guidance, acesso em 2026-10-11). Criptografia, identidade, armazenamento de segredos, evidência de auditoria e data discovery são cinco empregos diferentes; a lição 14 atribui cada um.

Exemplo resolvido E3: a conta do Athena é uma decisão de layout, não de query (em out 2026)

A AWS publica esta escada exata na sua página de preços do Athena (acesso em 2026-10-11). Tabela: 3 TB de texto não comprimido no S3, quatro colunas iguais, a query lê uma coluna.

A própria página da AWS declara a aritmética: "O preço para 3 TB escaneados é 3 * $5/TB = $15", terminando em "$1.25" para o caminho otimizado: uma diferença de 12× para a mesma resposta. Escale: 20 queries desse tipo por dia × 30 dias = 600 queries.

• Ingênuo: 600 × 3 TB = 1,800 TB × $5.00 = $9,000.00 por mês
• Otimizado: 600 × 0.25 TB = 150 TB × $5.00 = $750.00 por mês
• Diferença mensal: $8,250.00: comprada inteiramente com formato e poda de colunas, antes de qualquer cluster ser redimensionado

Exemplo resolvido E4: precificando um job do Glue de bronze para silver (em out 2026)

A página de preços do Glue (acesso em 2026-10-11): "O preço de 1 DPU-hour é $0.44"; "Um único DPU fornece 4 vCPU e 16 GB de memória"; a cobrança é "em incrementos de 1 segundo, arredondada para o segundo mais próximo, com duração mínima de 1 minuto por execução."

• Job pequeno, 6 DPU × 15 minutos: 6 × 0.25 h = 1.5 DPU-hours × $0.44 = $0.66 por execução; 30 execuções noturnas = $19.80 por mês
• Salto mais pesado, 10 DPU × 20 minutos: 3.333 DPU-hours × $0.44 = $1.47 por execução; × 30 = $44.00 por mês
• O padrão do Interactive Session é 5 DPU (mínimo de 2 DPU); uma sessão de data preview do Glue Studio usa 2 DPUs por até 30 minutos, com parada automática: a exploração é cobrada por sessão, não por mês
• O trabalho de otimização de tabela (compactação, estatísticas, auto-refresh de materialized view, crawlers) é listado a $0.44 por DPU-hour também, então a manutenção é um item medido, não overhead de graça
• A versão importa: a AWS anunciou em 21 de agosto de 2026 que "AWS Glue 6.0 está agora geralmente disponível, com uma redução de preço de 30% e suporte completo ao Apache Iceberg v3". Use como âncora conservadora o medidor publicado de $0.44 e relia a página de preços para a sua Região e versão do Glue antes de comprometer uma previsão

Exemplo resolvido E5: quanto a camada de serving custa em assentos (em out 2026)

Página de preços do QuickSight (acesso em 2026-10-11): Author $24 por usuário/mês, Reader $3 por usuário/mês, Reader Capacity "A partir de $250 para 500 sessões/mês", mais "Uma taxa de infraestrutura de $250/mês por conta se a sua conta tiver qualquer um dos seguintes: pelo menos um usuário Pro; Q&A habilitado via tópicos; Dashboard Q&A habilitado."

• 10 authors + 200 readers: (10 × $24) + (200 ×$3) = $240.00 + $600.00 = $840.00 por mês, com nenhuma taxa de infraestrutura de $250 (sem usuário Pro, sem tópicos de Q&A)
• Some um usuário Pro e a taxa de conta de $250 por mês passa a valer: $1,090.00 por mês para as mesmas 210 pessoas: um salto de 30% por uma única mudança de papel, e é por isso que o design de papéis é um controle de custo na lição 17
• Alternativa de capacidade para leitores ocasionais: a partir de $250 para 500 sessões/mês, o que vence 84 leitores casuais a $3 cada (84 × $3 = $252.00) e passa a perder além disso, o modelo de assento vence quando os leitores viram usuários diários

Leia o gráfico em ordem: o armazenamento domina a ingestão crua (a barra mais alta), então compressão e política de lifecycle são as primeira alavancas de custo (lições 02 e 16); os custos de consulta e de BI são uma ordem de grandeza menores e são controlados pelo layout (E3) e pelo modelo de assentos (E5); o compute para a transformação agendada é a menor linha de todas (E4), e é por isso que "vamos economizar escrevendo menos jobs do Glue" quase nunca é a otimização certa.

---

6. Arquitetura de referência ponta a ponta

6.1 O fluxo: da fonte ao dashboard

Esta é a espinha à qual toda lição posterior se conecta. Leia da esquerda para a direita e observe os dois planos de controle pontilhados, catálogo e governança, que tocam cada estágio, e não um só.

Os subgrafos numerados são a ordem de camadas da AWS do §1.3 com as zonas medalhão do §3 desenhadas dentro da camada de armazenamento: uma imagem, dois vocabulários.

6.2 A mesma arquitetura como uma conversa

Diagramas de fluxo escondem ordenação e gatilhos. Este diagrama de sequência mostra o que realmente acontece em um dia de dados, e onde a conta é gerada.

Três detalhes que o diagrama de fluxo não mostra. (1) O limite do commit ACID fica em cada salto medalhão, então leitores nunca veem dados meio gravados. (2) A decisão do Lake Formation acontece antes dos bytes serem escaneados, e é por isso que a governança é barata de impor cedo e cara de remendar depois. (3) O evento de cobrança do Athena é o scan, não a contagem de queries: a quantidade que você controla são os bytes lidos, e é por isso que as lições 03, 04 e 09 reenunciam a escada do E3.

6.3 A visão de contêineres: produtores, catálogo central, consumidores

A arquitetura de referência de crescimento e escala do AWS Prescriptive Guidance separa as contas deliberadamente: "Uma camada de produtores de dados em contas AWS diferentes"; "Uma camada de consumidores de dados em contas AWS diferentes"; "Um catálogo centralizado em uma conta AWS"; e "O catálogo centralizado é a interface usada pelos produtores e consumidores de dados para compartilhar e consumir dados": com a intenção declarada de "padronizar o compartilhamento e o consumo de dados, e escalar produtores e consumidores de forma independente sem aumentar a sua sobrecarga de gerenciamento."

As linhas pontilhadas são o ponto: metadados e permissões viajam pela conta de catálogo central, enquanto dados e compute ficam onde são econômicos. Essa é a disciplina de desacoplamento que o caso da FINRA concretiza no §10.

Exemplo resolvido E6: Athena ou Redshift Serverless para o mesmo dashboard? (em out 2026)

Um dashboard lê 50 GB de Parquet por dia. Preços das páginas de preços do Athena e do Redshift (acesso em 2026-10-11):

• Athena: 50 GB × 30 = 1,500 GB = 1.5 TB por mês escaneados × $5.00 por TB = $7.50 por mês, mais zero de custo ocioso, porque não há cluster
• Redshift Serverless: 64 RPU por ~2 horas por dia = 128 RPU-hours × $0.375 por RPU-hour = $48.00 por mês, mais Redshift Managed Storage a $0.024 por GB-mês, o exemplo resolvido da própria página de preços lê "40 TB x 1,024 GB per TB x $0.024"
• Razão: cerca de 6.4× mais caro para o caminho do Redshift neste workload: antes de contar o que o dinheiro extra compra: concurrency scaling (a página de preços observa "até uma hora de créditos grátis de Concurrency Scaling por dia" por cluster), materialized views, data sharing, e nenhuma ansiedade de scan por query
• Regra prática: acesso esparso, ad hoc, federado ou em rajadas → Athena; BI denso, concorrente, sempre ligado, com concorrência previsível → Redshift Serverless. Ambos leem a mesma cópia S3/Iceberg: você está escolhendo um motor de serving, não um segundo store de dados

---

7. Por que formatos de tabela abertos são inegociáveis

Um formato de tabela aberto adiciona uma camada de metadados transacional sobre formatos de arquivo abertos (Parquet, ORC, Avro) para que o lake se comporte como um banco de dados continuando neutro em fornecedor. A AWS declara a consequência prática, "o Iceberg suporta comandos SQL padrão de data warehousing para uso com tabelas de data lake", e a consequência de negócio como um verdadeiro tudo-ou-nada: uma "plataforma totalmente integrada mas proprietária" versus um "data lake autoconstruído, intensivo em recursos, mas neutro em fornecedor" (AWS Prescriptive Guidance, acesso em 2026-10-11).

O que o formato compra para você, a partir da lista de recursos do Iceberg publicada pela AWS: excluir, atualizar e mesclar; planejamento de scan rápido e filtragem avançada; evolução completa de schema; evolução de partição; particionamento oculto; rollback de versão; time travel; isolamento serializável; escritores concorrentes; e formatos de arquivo abertos.

Por que "aberto" é a palavra operante: a equipe do S3 Tables registra a consequência de interoperabilidade: APIs de gerenciamento de tabela "compatíveis com o padrão Apache Iceberg REST Catalog, permitindo que você use qualquer motor de consulta compatível com Iceberg (por exemplo, Spark, Trino, PyIceberg ou DuckDB) para acessar dados tabulares diretamente do S3 Tables" (AWS Storage Blog, 2025-05-27). A escolha de motor vira uma decisão de deployment, não um projeto de migração.

7.1 Três posições na AWS hoje

Os números do Iceberg gerenciado que a AWS publica: as S3 Tables são "especificamente otimizadas para workloads de analítica, resultando em vazão de query até 3x mais rápida e até 10x mais transações por segundo em comparação com tabelas auto-gerenciadas" (AWS What's New, 2024-12-03). Quotas registradas cinco meses após o lançamento: "suportando a criação de até 10,000 tabelas em cada table bucket… até 100,000 tabelas em 10 table buckets dentro de uma única Região AWS e conta AWS" (AWS Storage Blog, 2025-05-27).

• 📚 Você sabia? O suporte do Iceberg REST Catalog nas S3 Tables torna a pergunta "qual motor?" testável: se uma ferramenta fala o Iceberg REST Catalog, ela lê suas tabelas diretamente. A lista de exemplos da própria AWS é "Spark, Trino, PyIceberg ou DuckDB" (AWS Storage Blog, 2025-05-27): incluindo um laptop rodando DuckDB. É isso que "aberto" compra para você e que uma exportação de warehouse nunca comprará.

---

8. Mini-cenários resolvidos: dimensionando o que você acabou de desenhar

8.1 O esboço de dimensionamento do pipeline de 10 TB/dia

Exemplo resolvido E7: 10 TB/dia, armazenamento, consulta e transformação (em out 2026)

Âncora: a BMW Group "usa a AWS para processar 10 TB de dados diariamente de 1.2 milhões de veículos" (estudo de caso da AWS, acesso em 2026-10-11). Vamos dimensionar armazenamento, consulta e transformação para o mesmo ritmo diário, usando preços de lista lidos em 2026-10-11. Premissa de retenção: 30 dias de dados quentes.

Passo 1: armazenamento cru.

• 10 TB/dia × 30 dias = 300 TB por mês = 307,200 GB (1,024 GB por TB)
• No tier dos primeiros 50 TB do S3 Standard de $0.023 por GB-mês: 307,200 × $0.023 = $7,065.60 por mês
• Os tiers de volume publicados pela AWS (51 to 100 TB a $0.022, 500 TB+ a $0.021) e qualquer política de lifecycle reduzem isso: trate $7,065.60 como o teto conservador, não como a fatura

Passo 2: os mesmos dados depois do Parquet a 3:1 (a razão do próprio exemplo de Athena da AWS).

• 300 TB ÷ 3 = 100 TB = 102,400 GB × $0.023 = $2,355.20 por mês
• Economia: $4,710.40 por mês (−66.7%): só do formato, antes de qualquer query ser otimizada

Passo 3: consulta.

• Se analistas e dashboards escanearem 1 TB por dia no agregado: 30 TB × $5.00 por TB = $150.00 por mês no Athena
• Se eles em vez disso escanearem os 300 TB inteiros (tabela completa, sem particionamento): 300 × $5.00 = $1,500.00 por mês: dez vezes mais, pelas mesmas respostas, simplesmente porque particionamento e layout colunar foram pulados

Passo 4: transformação.

• Um job noturno bronze→silver a 10 DPU × 20 minutos (do E4): $1.47 por execução → $44.00 por mês
• Um salto silver→gold do mesmo tamanho dobra isso para $88.00 por mês

Passo 5, o esboço.

Conclusão: a 10 TB/dia a decisão de formato (linha 1) move cerca de $4,710 por mês, enquanto a decisão de compute (linha 3) move cerca de $88. Ordene o seu backlog de otimização de acordo; este é o argumento da própria AWS em miniature: conserte o layout dos dados antes de mexer no tamanho da infraestrutura. E repare no que o esboço não inclui: governança, monitoramento e as pessoas que operam a plataforma. Esses são custos reais, e é por isso que a lição 16 retorna a esta tabela com as alavancas de lifecycle e de rightsizing.

8.2 O teste de replay do Kappa

Cenário 8.2: seis meses de histórico, 24 horas de replay (em out 2026)

Um time de fraude adota a stack do walkthrough de Kappa do Builder Center da AWS: Kinesis Data Streams → Spark Structured Streaming no EMR → formato de tabela no S3. O artigo apresenta uma janela de replay de 24 horas para o stream (2026-05-18).

• Uma requisição de compliance chega pedindo reprocessamento de seis meses. 24 horas ÷ 180 dias ≈ 0.6% da janela necessária está disponível no stream.
• O movimento correto é reler o lake: a cópia durável no S3 atrás do formato de tabela, onde a retenção é governada pelas suas próprias regras de lifecycle (lições 02 e 16), não pela retenção do stream.
• Regra de design que daí sai: streams são transporte, lakes são registro. Nunca deixe o stream ser a sua única cópia de nada que você possa precisar reprocessar, e nunca dimensione um stream para armazenamento de arquivo, porque você pagaria preços de streaming para o serviço de arquivo.
• Cruzamento com o medalhão: um reprocessamento de seis meses re-executa os saltos silver e gold sobre o bronze, e é exatamente por isso que o bronze é retido cru e sem transformação, e por que os 2.4 milhões de arquivos bronze mensais do E1 são uma feature (recuperabilidade) e não apenas um custo.

8.3 O que os cenários têm em comum

Os dois mini-cenários fazem o mesmo movimento: pegar um número publicado pela AWS, aplicar uma premissa declarada abertamente e deixar a aritmética decidir o backlog. Razão de armazenamento primeiro, depois layout de consulta, depois tamanho do compute, depois assentos. Se você inverter essa ordem, dimensionar clusters antes de olhar o formato de arquivo e o particionamento, vai otimizar a linha de menor valor da tabela do E7 enquanto a conta de armazenamento, que é 95% do esboço antes da otimização, continua rodando.

---

9. Roadmap do curso: onde esta lição se encaixa

As lições 02 to 17 são a mesma arquitetura, camada por camada. Nada nas lições posteriores contradiz o esqueleto acima; elas preenchem as caixas.

Três hábitos para levar adiante: cite uma fonte e uma data para cada número (esta lição usou apenas páginas da AWS lidas em 2026-10-11); nomeie a camada antes de nomear o serviço; e leia métricas de clientes como alegações contra a própria baseline deles, nunca como garantias.

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

A AWS publica como esta arquitetura se comporta sob carga. Cada número abaixo é relatório do cliente dentro de uma página da AWS: não auditado, datado, e nunca uma garantia para o seu workload. A parte transferível é o padrão: qual camada fez o trabalho, quais serviços a sustentaram, qual número se moveu. Todas as fontes foram acessadas em 2026-10-11, a menos que uma data de publicação seja indicada.

Caso A, FINRA: desacoplando armazenamento, compute e catálogo (lição principal 01)

• Contexto. O regulador de valores mobiliários dos EUA "processa aproximadamente 6 terabytes de dados e 37 bilhões de registros em um dia médio… Em dias lotados, os mercados de ações podem gerar mais de 75 bilhões de registros" (AWS Public Sector Blog, publicado em 2017-10-03).
• Problema. A sua capacidade on-premises não conseguia acompanhar os picos do mercado; o design legado em HDFS "exigia mais de 2 PB de armazenamento no cluster com 60 instâncias hs1.8xlarge" (AWS Big Data Blog, publicado em 2016-11-21).
• Arquitetura. Um data lake em S3 com zonas crua, curada e de arquivo; Amazon EMR para compute de Hive, Spark e HBase; e o catálogo open source da própria FINRA: "Enter herd, our open source data catalog and orchestration tool… capture audit and data lineage information for our highly regulated environment" (2017-10-03).
• Resultados, como a AWS os relatou em 2016 to 2017. "Estendemos o padrão de data lake com EMR, HBase e Amazon S3 para permitir queries de acesso aleatório interativo em trilhões de registros abrangendo mais de 600 terabytes de dados" (2017-10-03); "economia de custos superior a 60%, redução drástica do tempo de recuperação ou upgrade"; um novo cluster HBase foi "capaz de lançar… e ficar pronto para aceitar queries em menos de 30 minutos porque os dados (HFiles) permanecem no S3. Isso teria levado quase dois dias no nosso cluster antigo", com "a maioria das queries retornando em menos de 3 segundos" (2016-11-21).
• Takeaway para a lição 01. Este é o §6.3 com as caixas renomeadas: armazenamento, compute e catálogo foram separados, então qualquer motor podia ler a mesma verdade do S3 e os clusters viraram descartáveis. Um lakehouse é uma disciplina de desacoplamento, não um produto que você compra. A frase da FINRA sobre reduzir "the cost of curiosity" é o business case para manter o bronze barato e aberto.

Caso B, Easygo: um lakehouse moderno com padrão streaming-first (lições principais 09 e 01)

• Contexto. Uma empresa de jogos operando analítica em tempo quase real em operações globais (estudo de caso da AWS, acesso em 2026-10-11).
• Arquitetura. "A empresa implementou um padrão streaming-first usando o Amazon Kinesis para capturar e processar eventos em tempo real, o Amazon Simple Storage Service (Amazon S3) como data lake central, e o Amazon Athena para consulta mais rápida em datasets particionados. A Easygo também incorporou o Amazon Redshift Serverless", mais a "Integração zero-ETL do Amazon Aurora com o Amazon Redshift" para que os dados "se movam do Aurora PostgreSQL para o Amazon Redshift automaticamente" (estudo de caso da AWS, acesso em 2026-10-11).
• Resultados (relatório do cliente). "Os tempos de execução de query melhoraram em 95 por cento, com workloads que anteriormente exigiam até 1 hora agora concluídos em cerca de 10 minutos"; "redução de incidentes de dados em 80 por cento"; 9 horas de manutenção economizadas semanalmente: antes "pelo menos 3 engenheiros de diferentes departamentos precisavam passar cerca de 3 horas cada semana tratando interrupções de pipeline"; o frescor do limiar de fraude melhorou de 15 to 30 minutos de atraso para tempo quase real.
• Citação. "Mudar nossa arquitetura para um lakehouse mais moderno na AWS nos ajudou a melhorar o desempenho e a estabelecer uma fundação que podemos reutilizar à medida que crescemos em outros mercados" (Carine Oliveira, Engineering Manager).
• Takeaway para a lição 01. A Easygo é a coluna inclinada para o Kappa do §4 mais o mapa de serviços do §5 em produção: ingestão de streaming → lake em S3 → consulta serverless → warehouse para o lado relacional, com zero-ETL removendo uma cópia. Note o que se moveu: frescor (1 hora → cerca de 10 minutos) e carga operacional (−80% de incidentes de ingestão, −9 engineer-hours por semana): ambos são resultados de camada e de padrão, não de hardware.

Caso C, BMW Group: estratificação a 10 TB por dia (lição principal 07, reutilizada aqui)

• Contexto. "A BMW Group usa a AWS para processar 10 TB de dados diariamente de 1.2 milhões de veículos" (estudo de caso da AWS, acesso em 2026-10-11), o mesmo ritmo diário que dimensionamos no E7.
• Arquitetura. "As camadas individuais de dados são armazenadas em buckets do Amazon S3, e seus schemas são registrados no AWS Glue Data Catalog." Os provedores ingerem e transformam "com serviços AWS como Amazon Kinesis Data Firehose, AWS Lambda, AWS Glue e Amazon EMR"; os consumidores então usam "serviços como Amazon Athena, Amazon SageMaker, AWS Glue e Amazon EMR".
• O catálogo como superfície de produto. Um Data Portal oferece um "'popularity index' baseado em padrões de uso de dados para mais de 500 usuários em toda a organização": a interface de catálogo centralizado do §6.3, tornada visível para os usuários em vez de enterrada em uma conta de infraestrutura.
• Takeaway para a lição 01. Dois pontos para guardar: (1) um lakehouse real nesse ritmo mantém camadas no S3 com schemas no Glue: exatamente o mapeamento do §3 de medalhão para primitivas da AWS; (2) o catálogo é a interface de compartilhamento, e é por isso que a lição 07 ganha uma lição inteira em vez de um parágrafo.

Mesmo padrão, indústria diferente (reutilize este frame sempre que precisar defender a arquitetura para um não engenheiro):

---

Perguntas de Prática (Practice Questions)

Doze itens em formato cenário. Cada um tem exatamente quatro alternativas com uma resposta correta, e a explicação nomeia a alternativa errada mais tentadora para que você aprenda por que ela está errada, e não apenas qual letra marcar.