Amazon DEA-C01: Consulta e Análise de Dados — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Faz parte do Amazon Data Engineer Associate DEA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Este domínio abrange o projeto, o ajuste e a operação de serviços da AWS que suportam consultas analíticas e BI em grandes conjuntos de dados. Ele se concentra em padrões de consulta econômicos e de alto desempenho no Athena, Redshift, OpenSearch e QuickSight, e como eles interoperam com o S3, Glue e armazenamentos transacionais. O domínio exige equilibrar o formato de armazenamento, o particionamento, o tipo de computação e o posicionamento dos dados para minimizar os bytes escaneados e o desvio de rede (network skew), ao mesmo tempo em que entrega insights de baixa latência.

Otimização de consultas no Amazon Athena

A precificação do Athena é baseada em bytes escaneados, então o layout físico dos dados e os metadados são as principais alavancas de otimização. Use formatos colunares (Parquet ou ORC) com compressão (Snappy para Parquet, opções Zlib/ORC) para reduzir o tamanho e o uso de CPU. Particione os dados por colunas de alta cardinalidade e filtradas em consultas (data, região) e registre as partições no Glue Data Catalog. Padrões típicos:

Escreva dados no S3 em caminhos como

undefined

e use crawlers do Glue ou o comando

undefined

para popular as partições.

undefined

para impor a compressão colunar.

Use projeção e poda de partição (partition pruning) por meio de cláusulas WHERE que referenciam chaves de partição para evitar o escaneamento de partições desnecessárias.

Quando as consultas exigem joins com armazenamentos transacionais, use o Athena Federated Query (conectores Lambda) para realizar joins entre diferentes fontes de dados com RDS, DynamoDB ou Redshift. Os conectores são implantados como funções Lambda e registrados como fontes de dados no Athena; fluxo de exemplo no console: Athena > Data sources > Connectors > New. Critérios de decisão:

Use o Federated Query quando os volumes de dados no RDS/DynamoDB forem modestos ou ao unir uma pequena tabela de dimensão a um grande conjunto de dados no S3.
Para joins pesados e repetidos, extraia e materialize os dados operacionais no S3 (em Parquet) para transferir o custo do join para um único ETL e use o Athena para as leituras repetidas.

Ajuste de consultas e distribuição no Amazon Redshift

O desempenho do Redshift depende do estilo de distribuição (distribution style) e das chaves de ordenação (sort keys) para minimizar a movimentação de dados e habilitar o mapeamento de zona (zone mapping). Escolha os estilos de DIST usando estes pontos de decisão:

DISTKEY (KEY): útil ao unir tabelas grandes em uma chave de join de alta cardinalidade; evita a redistribuição se ambas as tabelas compartilharem a mesma DISTKEY.
ALL: replica uma pequena tabela de dimensão para todos os nós para evitar transferências de dados na rede (network shuffles) durante os joins.
EVEN: padrão para cargas de trabalho imprevisíveis ou quando não existe uma boa chave; evita hotspots.
AUTO: permite que o Redshift escolha com base no tamanho da tabela e na carga de trabalho se você não tiver uma orientação clara.

Defina SORTKEYs em colunas usadas em filtros de intervalo ou em cláusulas ORDER BY para habilitar os zone maps e reduzir as leituras de disco. Comandos operacionais comuns:

undefined

Use VACUUM e ANALYZE periodicamente:

undefined

; monitore

undefined

para métricas de distorção (skew) e distribuição. O Redshift Spectrum permite que você consulte tabelas externas do S3 por meio do Glue Data Catalog. Crie o esquema externo com:

undefined

Critérios de decisão para Spectrum vs. Redshift nativo:

Use o Spectrum para dados frios (cold data), grandes e raramente consultados, armazenados no S3 ou para arquiteturas de dados em camadas.
Mantenha conjuntos de dados quentes (hot data) e frequentemente unidos dentro do Redshift para melhor desempenho; ao fazer join com o Spectrum, escolha DISTKEYs para colocar as chaves de join no mesmo local (colocate) ou use redistribuição para minimizar a E/S de rede.

Amazon OpenSearch Service para análise de logs

O OpenSearch é otimizado para ingestão e análise rápida e ad-hoc de logs; a configuração de seus índices e do cluster determina o throughput e o custo. Design e ciclo de vida do índice:

Use padrões de índice como

undefined

e um template de índice para definir

undefined

(índices pequenos: 1 shard; grandes: múltiplos shards com tamanho entre ~10–50 GB) e

undefined

para disponibilidade.

Configure políticas de ciclo de vida de índice (ILM) para transicionar os índices pelas camadas hot, warm, cold e UltraWarm para controle de custos; o UltraWarm reduz os custos de armazenamento em nós hot para dados históricos. Sharding e réplicas afetam o desempenho de consulta e indexação:
Mais shards aumentam o paralelismo, mas adicionam overhead; ajuste os shards por nó com base no heap e na CPU.
Réplicas melhoram o throughput de leitura e a tolerância a falhas; defina o número de réplicas com base na concorrência de consultas e no SLA. Comandos operacionais e padrões de console:
Use as Ferramentas de Desenvolvedor do OpenSearch (ou curl) para aplicar (PUT) templates de índice e políticas de ILM, e monitore com as APIs de saúde do cluster. Aloque atributos de nó e use o reconhecimento de alocação de shard (shard allocation awareness) para evitar hot-spotting. Critérios de decisão:
Escolha o UltraWarm quando os requisitos de latência de consulta em logs históricos puderem tolerar uma latência de leitura mais alta em troca de um custo de armazenamento menor.
Mantenha os índices recentes em nós hot para suportar agregações e dashboards rápidos.

QuickSight para BI e visualização

O QuickSight oferece dashboards rápidos com dois modos principais de ingestão: SPICE (em memória) e consulta direta (direct query). O SPICE oferece desempenho abaixo de um segundo para dashboards e é adequado para leituras repetidas; consultas SQL diretas (para Athena, Redshift, RDS) são preferíveis para conjuntos de dados muito grandes ou dados que mudam com frequência. Configurações chave e melhores práticas:

Crie conjuntos de dados no console: New dataset > Choose source (Athena/Redshift/RDS/OpenSearch) > Import to SPICE ou Use direct query.
Use atualizações agendadas do SPICE para necessidades diárias ou quase em tempo real; configure a atualização incremental por particionamento de timestamp para limitar a movimentação de dados. Segurança e governança:
Implemente segurança em nível de linha (row-level security) por meio de mapeamentos de usuário/grupo do QuickSight e regras no conjunto de dados.
Para acesso a dados entre contas (cross-account), implante uma IAM role e permissões baseadas em recursos para o QuickSight assumir. Critérios de decisão:
Use o SPICE para dashboards com muitos visualizadores simultâneos e janelas de atualização previsíveis.
Use a consulta direta quando a atualidade dos dados for crítica ou a capacidade do SPICE for limitada; combine com campos calculados e parâmetros para uma UX interativa.

Armadilhas Comuns e Critérios de Decisão

O Athena cobra por dados escaneados — sempre particione pelos predicados da consulta e armazene em formatos colunares (Parquet/ORC) com compressão (Snappy/Zlib) para reduzir os bytes escaneados.
Uma DISTKEY do Redshift em uma coluna de baixa cardinalidade causa data skew — escolha chaves de join de alta cardinalidade para a DISTKEY ou use DISTSTYLE ALL para tabelas de dimensão pequenas.
As tabelas externas do Redshift Spectrum exigem o Glue Data Catalog — garanta que o Glue esteja habilitado na região de destino e que as IAM roles permitam que o Redshift acesse o catálogo.
Erros na contagem e no dimensionamento de shards do OpenSearch — evite ter muitos shards pequenos; dimensione os shards para dezenas de GB e use o ILM para mover índices mais antigos para o UltraWarm para economizar custos.
Esquecer de executar RUN ANALYZE/VACUUM no Redshift após cargas em massa — agende a execução de ANALYZE e VACUUM para atualizar as estatísticas e recuperar espaço em disco para obter planos de consulta otimizados.
Estouro de capacidade (overflow) do SPICE do QuickSight e dados desatualizados — planeje a capacidade do SPICE, use atualizações incrementais ou mude para consulta direta (direct query) para necessidades em tempo real.

Problema Prático: Cenário de Caso de Uso

A Acme Retail precisa de relatórios de BI diários combinando pedidos transacionais no Amazon RDS, eventos de clickstream no S3 e perfis de usuário do DynamoDB, com limites de custo e atualizações de dashboard abaixo de um minuto para dados recentes.

Converter os dados de clickstream do S3 para o formato Parquet particionado (baseado em data), comprimir com Snappy e registrar os metadados no AWS Glue por meio de um crawler.
Usar o Athena para consultas ad-hoc no S3 e implantar conectores de Federated Query para o RDS e o DynamoDB para realizar joins com dimensões pequenas; materializar os resultados de joins frequentes como Parquet se as consultas forem repetidas.
Provisionar o Redshift para joins analíticos pesados: carregar snapshots agregados no Redshift, definir a DISTKEY em um customer_id de alta cardinalidade e definir a SORTKEY em order_date; usar o Spectrum para dados históricos frios (cold data) no S3.
Ingerir logs de aplicação no OpenSearch com padrões de índice diários; aplicar ILM para manter os índices recentes em nós quentes (hot nodes) e mover os índices mais antigos para o UltraWarm para economizar custos.
Construir dashboards no QuickSight: importar agregados recentes para o SPICE com atualizações incrementais agendadas para uma responsividade percebida abaixo de um minuto, e usar consultas diretas (direct queries) para métricas sempre atualizadas.

Justificativa: Essa abordagem minimiza os custos de escaneamento do Athena por meio de particionamento e formatos colunares, reduz o network shuffle do Redshift com chaves de distribuição e de ordenação (sort keys) adequadas, usa o Spectrum para evitar o armazenamento de dados frios (cold data) no Redshift, aplica o ILM do OpenSearch para otimizar o custo de armazenamento e aproveita o SPICE para dashboards responsivos, enquanto mantém a atualização crítica por meio de consultas diretas (direct queries).

← Orquestração de Dados e Gerenciamento de Fluxo de Trabalho · Todos os domínios · Segurança →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →