Analytics em escala: Redshift, EMR, Athena, Lake Formation
- ⬜📡 Edge e híbrido: Outposts, Wavelength, Local Zones(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Arquitetura Lakehouse moderna
Ingestion:
Kinesis Data Streams / Firehose — eventos real-time
DMS — CDC de DBs transacionais
DataSync / Transfer Family — bulk batch
Storage (data lake):
S3 (parquet/iceberg, particionado por data)
S3 Lifecycle: Standard → IA → Glacier
Catalog & governança:
Glue Data Catalog — schemas e partições
Lake Formation — permissões finas + audit
Processing:
Glue ETL (Spark serverless) — batch ETL padrão
EMR Serverless / EMR on EC2 — Spark/Flink customizado
Lambda — ETL leve event-driven
Step Functions — orquestração com retry
Query/analytics:
Athena (serverless SQL) — ad-hoc em S3
Redshift + Spectrum — warehouse + leitura S3
QuickSight / Tableau / Looker — BI layer
Real-time:
Kinesis Data Analytics (Flink) — stream processing
Managed Service for Apache Kafka — event backbone- → sem pipeline
- → Glue / EMR
- → agregação
- → schema
- → filtra o que cada um vê
- → publica produto de dado
- Analytics
- Banco de dados
- Armazenamento
A pergunta que o SAP faz não é "qual serviço", é "onde o dado pousa e quem precisa vê-lo com que permissão". S3 é sempre o pouso; catálogo e Lake Formation resolvem o resto.
- Três camadas, e a bronze é sagrada. Bronze guarda o dado como chegou e nunca é alterada — é o que permite reprocessar quando a regra muda. Silver limpa e particiona; Gold agrega para consumo. Sem bronze, erro de ETL é perda permanente.
- Formato de tabela aberto muda o jogo. Iceberg em cima do Parquet dá ACID, time travel e evolução de schema no S3. É o que permite UPDATE e DELETE num data lake — antes disso, lake era append-only e por isso não substituía warehouse.
- Um catálogo, vários motores. Glue Data Catalog é o schema compartilhado: Athena, Redshift Spectrum e EMR leem a MESMA definição. Sem catálogo central, cada motor tem sua verdade e os números divergem entre relatórios.
- Lake Formation faz a permissão fina. Permissão por coluna, linha e até célula, aplicada de forma consistente em todos os motores. É a resposta de "analista pode ver a tabela mas não a coluna de salário".
- Zero-ETL e DataZone são o que há de novo. Zero-ETL replica Aurora para Redshift sem pipeline para manter. DataZone é o catálogo de negócio: domínio, produto de dado e assinatura entre times. Os dois aparecem no SAP-C03 atual.
Onde isso entra no exame
A questão dá volume, formato e consumidor, e pede o pipeline. Kinesis Data Streams quando é streaming com ordenação e múltiplos consumidores, Firehose quando o destino é S3 sem código, Glue para catálogo e ETL, Athena para consulta ad hoc sobre S3, Redshift quando há junção pesada com concorrência alta.
Decisões que caem em prova
Cenários típicos do SAP: "time precisa fazer queries ad-hoc de 50GB/dia com orçamento apertado" → Athena + S3 parquet. "Dashboards corporativos com 200 usuários simultâneos" → Redshift RA3 ou Serverless. "Pipeline batch noturno de 5TB de logs" → Glue ou EMR Serverless. "Stream de cliques em tempo quase-real pra fraud detection" → Kinesis Data Streams + Flink (KDA) + DynamoDB.
Truque de formato: parquet/iceberg comprimido + particionamento correto corta 80-95% do custo de Athena. "S3 em JSON cru" é antipattern — custa 10x mais pra queries.
Um lakehouse precisa suportar UPDATE e DELETE sobre dados no S3, com histórico de versões das tabelas. O que viabiliza isso?
Governança com Lake Formation
-- Lake Formation: fine-grained access
GRANT SELECT ON "sales"."orders"
TO DATA_LAKE_PRINCIPAL "analyst-role"
WITH GRANT OPTION;
-- Row-level filter: vendedor só vê orders dele
CREATE DATA FILTER vendor_filter
ON DATABASE sales
TABLE orders
ROW FILTER "vendor_id = current_user_vendor_id()";
-- Column masking para PII
GRANT SELECT (order_id, total, vendor_id) ON "sales"."orders"
TO "analyst-role";
-- colunas omitidas (customer_email, customer_cpf) ficam invisíveis
-- Tag-based policies
CREATE LF_TAG confidentiality = ['public', 'internal', 'restricted'];
ASSIGN LF_TAG confidentiality='restricted' ON "sales"."orders"."customer_cpf";
GRANT SELECT ON columns with LF_TAG confidentiality='public'
TO "analyst-role";Checklist de lakehouse pro SAP: ingestão Kinesis/DMS, storage S3 parquet/iceberg particionado, catalog Glue, governança Lake Formation, processing Glue/EMR Serverless, query Athena/Redshift, BI QuickSight. Cada peça tem quando aparece em prova.
Perguntas frequentes
❓ Armazém de dados ou consulta sem servidor sobre o lago?
❓ Como reduzir o custo de consulta sobre o lago?
❓ Para que serve a camada de governança do lago?
Fixando
Qual recurso replica dados do Aurora para o Redshift sem pipeline de ETL para manter?
Como garantir que analistas vejam a tabela de vendas sem a coluna de comissão, de forma consistente em Athena, Redshift Spectrum e EMR?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…