Os dados têm um ciclo de vida. Arquivos de log criados hoje serão consultados com frequência amanhã, mas logs de três anos atrás raramente são abertos. Armazenar ambos na mesma camada de armazenamento de alto custo é um desperdício. O gerenciamento do ciclo de vida dos dados é sobre planejar por quanto tempo manter os dados e em qual formato. A evolução do esquema é o conjunto de técnicas que permitem alterar estruturas de dados sem quebrar os dados existentes. As questões do exame DEA-C01 sobre esses tópicos focam em otimização de custos e estabilidade operacional.
Políticas de ciclo de vida do S3
O S3 oferece múltiplas classes de armazenamento. Mover dados para classes mais baratas conforme a frequência de acesso diminui pode reduzir drasticamente os custos de armazenamento.
| Classe de armazenamento | Características | Melhor para | |------------------------|----------------|------------| | S3 Standard | Acesso rápido, maior custo | Dados recentes acessados com frequência | | S3 Standard-IA | Acesso ocasional, custo médio | Dados após 30 dias | | S3 Glacier Instant Retrieval | Acesso raro, baixo custo, recuperação instantânea | Dados após 90 dias | | S3 Glacier Flexible Retrieval | Acesso muito raro, custo muito baixo, recuperação em minutos a horas | Arquivamento de longo prazo | | S3 Glacier Deep Archive | Quase sem acesso, menor custo, recuperação em 12 horas | Dados de conformidade retidos por anos |
As políticas de ciclo de vida automatizam essas transições. Por exemplo:
Após 30 dias: Standard → Standard-IA automaticamente Após 90 dias: Standard-IA → Glacier Instant Retrieval Após 365 dias: Glacier Deep Archive Após 2.555 dias (7 anos): Exclusão automática
A transição move dados para uma classe mais barata. A expiração exclui dados automaticamente. As políticas de ciclo de vida podem ser aplicadas a um bucket inteiro, um prefixo específico (caminho de pasta) ou objetos com tags específicas.
DynamoDB TTL — Expiração automática de registros
O DynamoDB é um banco de dados NoSQL comumente usado para dados de sessão, tokens temporários, carrinhos de compras e outros dados que se tornam irrelevantes após certo tempo.
TTL (Time To Live) permite definir um tempo de expiração em itens individuais. Quando o tempo de expiração de um item passa, o DynamoDB o exclui automaticamente — sem necessidade de código de exclusão da sua parte.
Como funciona: Designe um atributo na sua tabela para armazenar o tempo de expiração (por exemplo, ) Armazene um timestamp Unix nesse atributo para cada item O DynamoDB verifica itens expirados em segundo plano e os exclui A exclusão normalmente ocorre dentro de 48 horas após a expiração
Notas importantes: A exclusão por TTL é gratuita (não consome capacidade de escrita) Os itens não são excluídos exatamente no momento da expiração, então sua aplicação deve verificar o campo de expiração Combine DynamoDB Streams com TTL para capturar eventos de exclusão para processamento adicional
Gerenciamento de dados no Redshift
O Redshift é um data warehouse em escala de petabytes. Carregar dados de forma eficiente e exportá-los é fundamental.
O comando COPY carrega dados em massa do S3, DynamoDB, EMR e outras fontes para o Redshift. É muito mais rápido do que instruções INSERT individuais.
O comando UNLOAD exporta dados do Redshift para o S3. Use-o para salvar resultados de análise ou transferir dados para outro sistema.
Snapshots são backups completos de um cluster Redshift. Snapshots automáticos são executados a cada 8 horas ou a cada 5 GB de alterações. Snapshots manuais são executados sob demanda. Use snapshots para restaurar um cluster em outra região para recuperação de desastres.
Princípios de design de esquema
Como você organiza os dados tem um enorme impacto no desempenho das consultas.
DISTKEY e SORTKEY do Redshift:
O Redshift distribui dados entre múltiplos nós. DISTKEY especifica qual coluna usar como chave de distribuição. Quando duas tabelas são unidas em uma coluna que é o DISTKEY para ambas, as linhas correspondentes já estão no mesmo nó — nenhuma transferência de rede é necessária, o que acelera significativamente os joins.
SORTKEY especifica a ordem em que os dados são armazenados dentro de cada bloco em disco. Se suas consultas frequentemente filtram por intervalo de datas, fazer da coluna de data o SORTKEY permite ao Redshift pular blocos inteiros fora do intervalo alvo, acelerando dramaticamente as consultas por intervalo.
Chave de partição do DynamoDB: O DynamoDB distribui dados entre partições com base na chave de partição. Se muitos dados caírem em um valor de chave de partição, essa partição se torna uma partição quente, causando gargalos de desempenho. Escolha uma chave de partição com alta cardinalidade (muitos valores únicos). ID de usuário é uma chave de partição muito melhor do que gênero.
Particionamento no S3: Decida como organizar suas pastas S3 ao escrever dados. Quando o Athena consulta dados particionados, ele pula partições irrelevantes completamente, reduzindo os dados verificados — o que reduz tanto o custo quanto o tempo de consulta.
Exemplo:
Evolução do esquema — Quando sua estrutura de dados muda
Os negócios mudam. A estrutura de dados que você projeta hoje pode não ser adequada em seis meses. A evolução do esquema é a capacidade de alterar um esquema sem quebrar os dados armazenados existentes.
Apache Iceberg: Uma camada de formato de tabela que fica sobre arquivos de dados no S3. Suporta adicionar colunas, alterar tipos de colunas e remover colunas. Também fornece consultas de viagem no tempo, permitindo consultar dados como existiam em um momento passado. Suportado nativamente pelo AWS Glue e Athena.
Apache Avro: Um formato de serialização que armazena o esquema junto com os dados. Mesmo quando o esquema muda, os dados escritos com o esquema antigo ainda podem ser lidos corretamente. Frequentemente combinado com Kafka para evolução de esquema em pipelines de streaming.
SCT (Schema Conversion Tool) e DMS (Database Migration Service): Usados para migrações entre diferentes mecanismos de banco de dados. O SCT converte esquemas do Oracle, SQL Server e outros para formatos compatíveis com Redshift ou Aurora. O DMS então migra os dados reais do banco de dados antigo para o novo.
Linhagem de dados — Rastreando a jornada dos seus dados
A linhagem de dados rastreia de onde vieram os dados, quais transformações eles passaram e para onde foram. É essencial para conformidade regulatória, auditoria e depuração.
Imagine que um relatório mostra um número errado. Sem linhagem, você deve verificar cada etapa: foi o dado de origem? A transformação ETL? A consulta de agregação? Com linhagem, você pode rastrear o caminho dos dados para trás e encontrar o problema rapidamente.
Serviços AWS que ajudam a implementar linhagem: AWS Glue: Registra automaticamente o histórico de execução de jobs e as etapas de transformação Amazon DataZone: Visualiza a linhagem em todo o catálogo de dados da organização CloudTrail: Log de auditoria no nível de chamada de API Lake Formation: Registros de acesso em todo o data lake
Pontos-chave do exame
"Mover dados antigos automaticamente para armazenamento mais barato" → Políticas de ciclo de vida S3 "Excluir automaticamente itens DynamoDB expirados" → TTL "Carregar dados em massa do S3 para o Redshift" → Comando COPY "Exportar dados do Redshift para o S3" → Comando UNLOAD "Otimizar desempenho de joins no Redshift" → DISTKEY "Otimizar consultas por intervalo no Redshift" → SORTKEY "Ler dados antigos após mudanças de esquema" → Apache Iceberg ou Avro "Migrar BD local para AWS" → SCT + DMS "Rastrear histórico de movimentação e transformação de dados" → Data Lineage