Analytics: Athena, EMR, Kinesis e Glue
Analytics no SAA-C03 cobre escolha entre data lake (S3 + Athena + Glue) e data warehouse (Redshift), ingestão (Kinesis vs MSK), ETL (Glue vs EMR) e visualização (QuickSight). Não vira DBA — o exame testa se você sabe qual ferramenta resolve qual problema, sem combo errado.
Arquitetura típica de data lake AWS
Athena — SQL serverless sobre S3
-- Exemplo: query particionada com projection
SELECT user_id, COUNT(*) AS sessions
FROM logs.events
WHERE year = 2026 AND month = 4
GROUP BY user_id
ORDER BY sessions DESC
LIMIT 100;Redshift — data warehouse colunar
| Athena | Redshift | Redshift Spectrum |
|---|---|---|
| Serverless | Cluster provisionado (ou Serverless) | Cluster Redshift acessando S3 |
| Pay per TB scanned | Pay por node/hora | Cobra TB scanned + cluster |
| Ad-hoc queries sobre data lake | BI estruturado, dashboards pesados | Extender Redshift para S3 externo |
| Latência: segundos–minutos | ms–segundos (hot queries) | Segundos |
Glue — ETL e Data Catalog
EMR — Hadoop/Spark gerenciado
Glue vs EMR: Glue é managed sem cluster visível, escolha default para ETL Spark. EMR quando você precisa customizar bootstrap, usar frameworks fora do Glue (HBase, Presto standalone, Flink) ou ter full control sobre o cluster. Glue é mais caro por DPU mas zero admin.
Ingestão — Kinesis, DMS, MSK
| Serviço | Uso |
|---|---|
| Kinesis Data Streams | Stream ordenado por shard, retenção até 365 dias. |
| Kinesis Data Firehose | Delivery managed para S3/Redshift/OpenSearch/Splunk, buffer mínimo 60s. |
| Managed Apache Flink | Analytics em stream (ex-Kinesis Data Analytics). |
| MSK (Managed Kafka) | Kafka cluster gerenciado quando ecosystem Kafka é requisito. |
| DMS (Database Migration Service) | CDC contínuo de bancos OLTP para S3/Redshift/Kafka. Ideal para Zero-ETL-like replicação. |
| DataSync | Transferência agendada on-prem ↔ S3/EFS/FSx. |
| Snow Family | Transferência de grandes volumes (TB/PB) via hardware físico. |
OpenSearch, QuickSight, SageMaker
Cenários arquiteturais do exame
📋 Empresa quer criar data lake moderno partindo do zero, times distribuídos, custo baixo
Serverless ponta-a-ponta. Sem cluster, times podem consumir com SQL familiar. Glue cataloga, Lake Formation governa.
📋 DW relacional legado on-prem com 20TB sendo migrado; dashboards executivos com SLA <1s
Redshift otimizado para OLAP estruturado. SLA baixo exige cluster dedicado/quente. QuickSight SPICE para dashboards.
📋 Pipeline real-time de IoT: ingest 1M events/s, enriquecer com dado de RDS, gravar parquet + alertar
Streams aguenta throughput. Flink permite join com RDS e janelas temporais. Firehose converte para Parquet nativo e entrega S3.
Q&A estilo exame
❓ Como reduzir custo de queries Athena em 80%?
❓ Athena ou Redshift Spectrum para consulta ocasional em S3?
❓ Quando escolher Kinesis Firehose vs Data Streams?
❓ Glue Crawler está detectando schema errado — fix?
Armadilhas: (1) Athena não é OLTP — não tem índices, joins custosos; (2) Redshift COPY de S3 é o caminho rápido — NÃO use INSERT row-by-row; (3) Firehose tem buffer mínimo (60s ou 1MB) — não é real-time <1s; (4) EMR cluster sempre rodando desperdiça dinheiro — use transient clusters ou EMR Serverless; (5) Data Catalog é compartilhado — Athena, Spectrum, EMR veem as mesmas tabelas.
Take-aways: Data lake moderno = S3 (Parquet particionado) + Glue Catalog + Athena/Redshift Spectrum. Data warehouse clássico = Redshift. Streaming = Kinesis/MSK + Flink. ETL = Glue (serverless) ou EMR (custom). BI = QuickSight. Governança = Lake Formation.
Discussão
Carregando…