Escolhendo os Armazenamentos e os Formatos de Arquivo

Pergunte a dez candidatos como eles escolhem um banco de dados e você ouvirá dez versões de "depende", e no DEA-C01 essa resposta não vale ponto algum. O exame não recompensa um gosto vago de arquitetura; ele recompensa um mapeamento determinístico: um padrão de acesso no enunciado, um serviço para fora da lista no escopo, um formato em repouso, um codec de compactação. O Domínio 2 vale 26% do exame, e a tarefa 2.1 é o núcleo de seleção de armazenamento desse domínio, as habilidades 2.1.1 (implementar armazenamento para custo e desempenho), 2.1.2 (configurar armazenamento para padrões de acesso), 2.1.3 (aplicar armazenamentos a casos de uso), 2.1.7 (gerenciar formatos de tabela abertos, por exemplo o Apache Iceberg) e 2.1.8 (descrever tipos de índice vetorial, por exemplo HNSW e IVF).

Nesta lição você vai:

• ler a tarefa 2.1 habilidade por habilidade e montar a taxonomia de armazenamentos no escopo de onde o exame extrai suas respostas;
• mapear padrão de acesso → serviço com uma tabela-mestre e uma árvore de decisão que você percorre em segundos;
• dimensionar o DynamoDB com aritmética real de unidades de capacidade e seus tetos de 400 KB e 10 GB;
• posicionar RDS, Aurora, Neptune, MemoryDB e DocumentDB para nunca escolher dois serviços para um mesmo padrão;
• separar Redshift, Athena e OpenSearch pelo que a consulta realmente faz;
• escolher um formato na matriz CSV / JSON / Avro / Parquet / ORC: layout, schema, evolução e quando usar;
• escolher um codec de compactação pelo vocabulário da própria AWS (Snappy, GZIP, ZSTD, ZLIB) e pelos padrões que viram alternativas erradas;
• operar S3 como núcleo do lago: 3.500 / 5.500 requisições por prefixo particionado, nenhum limite de prefixo, consistência forte desde 1º de dezembro de 2020 e a correção do prefixo quente no 503;
• raciocinar sobre formatos de tabela de lakehouse, Iceberg, Hudi e Delta, exatamente na profundidade que a habilidade 2.1.7 exige;
• aplicar tabelas de decisão aos cenários do exame e separar Athena versus Redshift na camada de consumo;
• estudar dois estudos de caso de clientes da AWS e uma caixa de atualizações de outubro de 2026 com fonte;
• praticar com 12 questões no estilo do exame mais três verificações interativas.

---

1. O que a tarefa 2.1 realmente testa

1.1 As cinco habilidades por trás desta lição

Duas fronteiras importam mais que as próprias listas. Afinação profunda de motor está fora: os internos do Redshift pertencem à Lição 4, e a orquestração à Lição 5. O que sobra aqui é seleção: padrão entra, serviço sai, formato anexado.

1.2 A taxonomia de armazenamentos no escopo

Tudo o que você pode nomear como resposta correta vem desta tabela (listas no escopo do DEA-C01, conferidas em outubro de 2026):

• 📚 Você sabia? Amazon ElastiCache e Amazon Timestream estão nem na lista no escopo nem na lista fora do escopo (ambas conferidas em outubro de 2026), enquanto a habilidade 2.1.3 nomeia MemoryDB explicitamente. A leitura prática: quando o enunciado usa o vocabulário do próprio guia, "acesso rápido a chave/valor", o palpite no escopo é o MemoryDB, e o ElastiCache continua sendo a resposta de cache do mundo real que você encontra em diagramas de produção. Nunca gaste minutos do exame discutindo higiene de lista; responda com o serviço cujo vocabulário combina com o enunciado.

---

2. Padrão de acesso → serviço: o mapa mestre

2.1 A tabela que você deve decorar de cor

Regra didática:

• *chave + latência → DynamoDB ou MemoryDB
• joins e BI → Redshift
• SQL no lago → Athena
• texto → OpenSearch
• relações → Neptune
• OLTP → RDS ou Aurora
• escala bruta barata → S3.*

2.2 Exemplo trabalhado E1: um sistema, dois armazenamentos

Um serviço de varejo tem dois requisitos no mesmo chamado:

O enunciado sempre traz dois requisitos de propósito. Divida a carga; nunca force um armazenamento a responder um padrão para o qual ele não foi desenhado.

2.3 Verificação interativa: combine padrão com serviço

---

3. Armazenamentos chave-valor, documentais, de grafo e em memória

3.1 DynamoDB: as restrições que o exame cita

A identidade de exame do DynamoDB é acesso por chave em milissegundos unitários a qualquer escala, e o seu silêncio deliberado sobre JOINs é justamente o ponto. Qualquer alternativa que proponha o DynamoDB para agregação em escala de lago leu o serviço errado.

3.2 Exemplo trabalhado E2: unidades de capacidade na mão

3.3 Exemplo trabalhado E3, o teste de folga do item de 400 KB

A versão favorita desta questão no exame coloca o número logo acima de 400 KB no enunciado. A resposta nunca é "aumentar o limite do item": não existe esse botão.

3.4 Os vizinhos: DocumentDB, MemoryDB, Neptune

• 📚 Você sabia? A fama de exame do MemoryDB vem de uma única frase na habilidade 2.1.3, "MemoryDB for fast key/value access", e é por isso que ele vence qualquer outra alternativa com cheiro de cache quando o enunciado pede estruturas Redis mais durabilidade. Um cache simples na frente de um banco é uma arquitetura real, mas o caso de uso nomeado no guia é o durável: se os dados precisam sobreviver a uma falha de nó sem reconstrução a partir da fonte da verdade, você está lendo a linha do MemoryDB.

---

4. OLTP relacional: Amazon RDS e Amazon Aurora

4.1 O RDS é o padrão documentado

O Amazon RDS apresenta a escolha relacional gerenciada padrão do exame: você escolhe um motor, Multi-AZ para failover, réplicas de leitura para escala e backups automáticos: a AWS cuida do SO e do patch do motor. A própria página de boas-vindas do serviço recomenda o RDS como escolha padrão para cargas relacionais, e é por isso que qualquer enunciado descrevendo OLTP convencional (transações, joins, chaves estrangeiras, um schema aplicado na escrita) se resolve no RDS, a menos que uma capacidade específica do Aurora seja nomeada.

4.2 Aurora: os deltas que o enunciado nomeia

A linha vetorial é a armadilha mais nova deste domínio: HNSW (hierarchical navigable small world, orientado a recall, faminto de memória) e IVF (inverted file, construção mais rápida, busca baseada em clusters) são tipos de índice, não serviços. O enunciado nomeia o índice, a alternativa nomeia Aurora PostgreSQL.

4.3 Exemplo trabalhado E4: qual sabor relacional?

Todo enunciado esconde uma palavra de forma: transação, chave estrangeira, failover = OLTP; extração, junção entre muitas tabelas, analistas = OLAP; vetor, embedding, similaridade = Aurora PostgreSQL com HNSW/IVF; chaveado por, por ID, ms unitários = DynamoDB.

---

5. Armazenamentos analíticos: Redshift, Athena e OpenSearch

5.1 Três formas analíticas, três serviços

O enquadramento da própria AWS é citável: o Athena é para "interactive ad hoc SQL queries against data on Amazon S3, without … infrastructure or clusters", enquanto o Redshift é "optimized … on complex queries that join large numbers of very large database tables".

5.2 OpenSearch: a identidade de analítica de log

A divisão que aparece nos enunciados: agregar erros 5xx por serviço e fazer busca textual dentro de um stack trace é uma forma de consulta, OpenSearch. "Juntar as contagens de erro à dimensão de cliente" é outra forma, Athena ou Redshift.

---

6. A matriz de formatos de armazenamento

6.1 CSV, JSON, Avro, Parquet, ORC, e Protobuf por completeza

Três comparações que o exame reusa sem parar:

6.2 Predicate pushdown em um quadro só

A documentação do Athena diz isso de forma direta: "predicate pushdown em Parquet e ORC permite que as consultas do Athena busquem apenas os blocos de que precisa… ele usa estatísticas dos predicados de bloco, como valores máximos/mínimos, para decidir se lê ou pula o bloco." Um arquivo de totais diários onde a consulta pede uma única data deixa o motor pular grupos de linhas inteiros: esse pulo é o modelo de custo, não uma micro-otimização.

6.3 Padrões de dimensionamento que valem a memória

6.4 Exemplo trabalhado E5: a escada de custo da própria AWS

A página de preços do Athena carrega exatamente este exemplo trabalhado (em outubro de 2026):

Lição para o exame: a compactação sozinha dá o primeiro corte; o layout colunar dá o segundo; nenhum dos dois é opcional, e nenhum dos dois muda a consulta. Quando um enunciado diz "reduzir o custo da consulta sem trocar a ferramenta de BI", a resposta é converter para colunar: não comprar um cluster maior.

---

7. Codecs de compactação: Snappy, GZIP, ZSTD, ZLIB

7.1 O vocabulário da própria AWS

O princípio que rege tudo, tirado do guia de tuning do Athena: razão maior custa CPU. Compacte o lago e deixe o layout colunar mais o predicate pushdown cortarem a E/S.

7.2 Padrões que viram alternativas erradas de três vias

Aprenda-os como um trio: qualquer questão que pare "qual compactação o X usa por padrão" com três desses quatro nomes está testando a memorização exatamente desse mapeamento.

7.3 Exemplo trabalhado E6: a decisão de codec num enunciado

7.4 Exemplo trabalhado E7: aritmética de conversão

• 📚 Você sabia? O Amazon Athena infere a compactação pela extensão do arquivo nos formatos de texto e JSON, então renomear um .csv.gz para .csv não "descomprime" nada, apenas diz ao motor para esperar texto puro que ele não vai encontrar. É por isso que questões de formato e questões de codec são itens de exame separados: o formato é o que você declara, o codec é em grande parte o que o motor descobre.

---

8. O Amazon S3 como núcleo do lago de dados

8.1 Taxas de requisição: por prefixo, não por bucket

A documentação de desempenho da AWS (acesso em outubro de 2026) afirma:

"Sua aplicação pode alcançar pelo menos 3.500 requisições PUT/COPY/POST/DELETE ou 5.500 GET/HEAD por segundo por prefixo particionado do Amazon S3. Não há limites ao número de prefixos em um bucket."

8.2 Exemplo trabalhado E8: a correção do prefixo quente

8.3 Partições e prefixos são eixos diferentes

Sobre-particionar produz arquivos pequenos e sobrecarga do planejador (erros no estilo "reduce your request rate" aparecem no guia de tuning do Athena em tamanhos de split minúsculos). A regra: particione pela cláusula WHERE, distribua prefixos pela taxa de escrita, e mire divisões de cerca de 128 MB.

8.4 Consistência: a mudança de 2020 que matou duas respostas

O anúncio da AWS de 1º de dezembro de 2020:

"Com efeito imediato, todas as operações GET, PUT e LIST do S3, assim como operações que alteram tags, ACLs ou metadados de objetos, agora são fortemente consistentes."

• Grátis, vale para todas as Regiões e todos os objetos.

• Consequências: EMRFS Consistent View e S3Guard estão obsoletos: qualquer alternativa cuja correção dependa deles está desatualizada e errada.

• Uma alternativa do tipo "leitura após escrita é eventualmente consistente no S3" está falsa em qualquer exame desde 2021.

• 📚 Você sabia? A escada de classes de armazenamento do S3 é em si uma alavanca de custo para o lago: o Intelligent-Tiering move objetos intocados por 30 dias para Standard-IA (−40%), 90 dias para Glacier Instant Retrieval (−68%) e, opcionalmente, 180 dias para Deep Archive (−95%), enquanto o S3 Express One Zone troca uma Availability Zone única por latência de milissegundos unitários a até 2.000.000 requisições/s por directory bucket (em outubro de 2026). Escolher a classe é a metade de custo/desempenho da tarefa 2.1; escolher o formato é a Seção 6 desta lição.

• 📚 Você sabia? O Amazon S3 é um serviço público desde 13 de março de 2006, e a retrospectiva de 20 anos da própria AWS (2026-03-13) relata uma redução de preço de aproximadamente 85% desde o lançamento mais mais de US$ 6 bilhões economizados em conjunto por clientes que escolheram o S3 Intelligent-Tiering em vez do S3 Standard: junto do lembrete de que "o código que você escreveu para o S3 em 2006 ainda funciona hoje, sem mudanças". É por isso que o Intelligent-Tiering é o padrão do lago quando o padrão de releitura é desconhecido: a AWS move um objeto intocado por 30 dias para Standard-IA (−40%), 90 dias para Glacier Instant Retrieval (−68%) e opcionalmente 180 dias para Deep Archive (−95%), então a decisão de custo se resolve sozinha enquanto a decisão de formato (Seção 6) continua sendo sua.

---

9. A camada de lakehouse: Iceberg, Hudi e Delta

9.1 Por que existem formatos de tabela

Os formatos de arquivo "só permitem a gravação de arquivos inteiros", então captura de mudanças (CDC), exclusões e streaming contínuo criam dor de arquivos pequenos e não oferecem semântica transacional em armazenamento de objetos. Os formatos de tabela acrescentam snapshots, compactação, time travel e semântica transacional por cima dos arquivos Parquet/ORC/Avro no S3. Um lago de dados simples, observa a Prescriptive Guidance da AWS, não oferece suporte a atomicidade, consistência, isolamento e durabilidade (ACID) até que um formato de tabela como o Iceberg seja adicionado.

O Iceberg é o que o guia nomeia (habilidade 2.1.7), então é o que você precisa conhecer em profundidade:

9.2 Hudi e Delta: reconhecimento, não internos

A própria orientação da AWS diz "no single table format is a 'one size fits all'". A matriz comparativa publicada pela AWS (acesso em outubro de 2026):

Como o guia nomeia só o Iceberg, não memorize internos dos outros dois: reconheça os nomes e saiba que a AWS se recusa a coroar um vencedor.

9.3 Schema-on-read versus schema-on-write

Formulação de exame: lago = schema-on-read, armazenamento barato, computação desacoplada; warehouse = schema-on-write, curado, aplicado, afinado para BI. Dashboards fixos com muitos joins → escrita; bruto, estruturas variáveis → leitura.

9.4 Exemplo trabalhado E9: particionamento oculto e time travel

---

10. Tabelas de decisão para cenários de exame

10.1 A tabela mestre de cenários

10.2 Ciclo de vida do formato: ordenação interativa

10.3 Os dez pares de armadilha

---

11. Consumo entre serviços: Athena versus Redshift

A seleção de armazenamento não termina no armazenamento, o exame pergunta qual motor o lê. A orientação comparativa da AWS (acesso em outubro de 2026) é inequívoca: Athena = SQL ad hoc ANSI interativo no S3 sem clusters; Redshift = o warehouse; EMR = Spark/Hive completos.

Alavancas de custo que aparecem nos enunciados, em ordem de impacto:

1. Formato colunar + codec: a escada de $15 →$5 → $1,25 da própria AWS.
2. Pruning de partições: só ajuda quando o WHERE usa a chave de partição; SELECT * joga fora a economia de colunas.
3. Partição por projeção (partition projection), o Athena deriva as partições das propriedades da tabela em vez de chamar GetPartitions; a AWS relata acelerações de consulta como 137 s → 10 s (~92%).
4. Corte de bytes escaneados do workgroup: BytesScannedCutoffPerQuery tem um mínimo de 10.000.000 de bytes, limitando o pior caso de gasto por consulta.
5. Reuso de resultados de consulta: 60 minutos por padrão, máximo de 7 dias, por workgroup.

11.1 Exemplo trabalhado E10: aritmética de pruning

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

• 📚 Você sabia? O AWS Glue Schema Registry, o componente que torna o Avro em movimento seguro: é serverless e gratuito, e valida exatamente três formatos: AVRO (1.11.4), JSON e PROTOBUF. O modelo de Avro dele é a única frase que vale a memória: o schema é JSON, os dados são binário, e é por isso que um arquivo Avro só é legível com o seu schema, e por que "o schema viaja com os dados" é a explicação correta de exame para o comportamento de evolução excelente do Avro.

---

Casos Reais

A AWS publica como essas abstrações aparecem em produção. Todo número abaixo é afirmação do cliente ou da AWS e não auditado, com a fonte nomeada para que você possa conferir, o ponto examinável é o padrão (qual armazenamento, qual formato, qual número se moveu), não o marketing.

Caso A, Nasdaq: um caminho de escrita no S3 e um caminho de leitura no Redshift

"Nós conseguimos suportar com facilidade o salto de 30 bilhões para 70 bilhões de registros por dia por causa da flexibilidade e da escalabilidade do Amazon S3 e do Amazon Redshift.": Robert Hunt, VP de Engenharia de Software, Nasdaq (estudo de caso da AWS, acesso em outubro de 2026)

Leia a Nasdaq como um sistema, dois armazenamentos: o S3 absorve o pico de escrita de forma barata e durável, o Redshift serve as leituras simultâneas, e o Spectrum fecha o intervalo para que o lago de 15 TB nunca seja copiado. A frase destacada pela página da AWS é "zero contention between data loading and querying": esse é o argumento de armazenamento desacoplado da Seção 9, visível num prazo de produção.

Caso B, EMX: S3 e Athena em vez de um warehouse de backend

A EMX é a versão em funcionamento da Seção 6: manter os dados brutos no S3, converter para um layout colunar e deixar a cobrança por terabyte do Athena substituir um backend sempre ligado. O padrão examinável é a forma, armazenamento de objetos barato mais SQL por consulta vence um cluster que você paga com ou sem alguém consultando, nunca o percentual específico.

Caso C, EOS Group: DMS para S3 para Redshift, com PII mascarado no lugar

"Ao remover a necessidade de infraestrutura local, a EOS Group alcançou uma redução de 50 por cento nos custos de infraestrutura…": estudo de caso AWS EOS Group (acesso em outubro de 2026)

Leia a EOS como a sequência de migração que o exame insiste em testar: o DMS aterruga o banco de dados no S3, o Redshift carrega a partir do S3, e a mascaragem acontece dentro do warehouse contra as permissões do usuário: uma tabela, duas visões dela, nenhuma cópia mascarada secundária para manter em sincronia. Três armadilhas se escondem aqui: o DMS não é o DataSync (ele move schemas e linhas, não arquivos), o Macie não mascara nada (ele descobre dados sensíveis no Amazon S3), e os 50% são o resultado da própria EOS sobre a sua linha de base, nunca uma garantia de migração.

Caso D, GE Aerospace: modernizando um armazenamento operacional legado

"Nós estávamos vendo consultas que costumavam levar uma hora e meia rodando em 7 minutos usando o Amazon Redshift.": Bejoy John, Diretor Sênior de Análise de Dados, GE Aerospace (estudo de caso da AWS, acesso em outubro de 2026)

A GE Aerospace é a história de right-sizing por trás do RA3 e do armazenamento gerenciado: computação e armazenamento são separados, então a correção para uma consulta de uma hora é um warehouse de forma melhor, não uma cópia maior do mesmo projeto. Enquadramento seguro para o exame: 70% e >US$ 500.000/ano são estimativas da GE contra a linha de base da GE, o fato transferível é a seleção (uma carga com forma de BI e curada pertence ao Redshift), não o número.

• 📚 Você sabia? Os casos de governança leem como o mesmo número escrito duas vezes: a Integral Ad Science (IAS) usou controles de acesso baseados em tags do Lake Formation para reduzir centenas de regras de permissão a exatamente duas, enquanto o hub-and-spoke data mesh da GoDaddy agora concentra mais de 2.000 produtos de dados em vários petabytes distribuídos por centenas de contas (AWS Big Data Blog, 2021-09-23 e 2022-11-21, acesso em outubro de 2026). Nenhum dos números se generaliza para a sua carga, mas os dois enunciados colapsam numa regra de seleção só: quando o requisito é acesso centralmente governado a dados que você não pode copiar, a resposta é Lake Formation sobre o Amazon S3 com Athena ou EMR por cima, nunca um segundo banco de dados fazendo as vezes de um modelo de permissão.

---

Perguntas de Prática (Practice Questions)

Veredito Comparativo: como este tópico se compara no dia do exame

• Verso outras nuvens: o DEA-C01 testa apenas serviços da AWS: nenhuma questão pede que você compare DynamoDB ou Redshift com a oferta de um concorrente. Responda com um comportamento documentado pela AWS (itens de 400 KB, 3.500/5.500 por prefixo, $5,00/TB escaneado, snapshots do Iceberg); uma alternativa que se apoie num benchmark de terceiros não verificado está fora de escopo por construção.
• Verso autogerenciado / on-premises: rodar seu próprio Hadoop, cache ou cluster de busca significa patch, estimativa de capacidade e hardware ocioso. A preferência do exame é gerenciado e cobrado por consumo, S3 para escala bruta, DynamoDB para acesso por chave, Athena para cobrança por consulta, respeitando ainda o contrarrequisito: se o requisito declarado é um motor autogerenciado com hardware específico, esse requisito vence. Nunca afirme que gerenciado é sempre certo; afirme que é certo para o padrão declarado.
• Verso outro serviço da AWS: Redshift quando a consulta é BI repetido e simultâneo sobre tabelas curadas; Athena quando é SQL ad hoc sobre arquivos no S3; Spectrum quando os dados precisam ficar no S3 mas serem consultados com SQL de warehouse; OpenSearch para relevância e análise de log; Glue + Lake Formation para o catálogo e a governança acima deles. Respostas erradas quase sempre dimensionam o motor pelo hábito, não pela forma da consulta.
• Verso um processo manual e humano: registrar partições à mão, passagens manuais de verificação de consistência e limpeza manual de arquivos pequenos perdem para snapshots do Iceberg com particionamento oculto, S3 fortemente consistente e compactação automatizada: escolha a alternativa com menos esforço manual não gerenciado, mas não confunda "gerenciado" com "gratuito": o Athena ainda cobra bytes escaneados, e as classes de armazenamento do S3 ainda cobram pelo que você guarda.