Ingestão e armazenamento: onde o dado mora decide o custo do treino
- ⬜🎓 MLA-C01 — domínios, pesos e a régua que responde metade das questões(AWS ML Engineer Associate (MLA-C01))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Onde o dado mora decide o custo de tudo o que vem depois
A primeira decisão de um sistema de ML não é o algoritmo: é onde o dado fica e em que formato. Ela parece infraestrutura e é, na verdade, a decisão que mais influencia o custo de treinamento — porque treinar significa ler o conjunto inteiro, muitas vezes, e cada leitura paga o preço do formato que você escolheu.
| Formato | Como armazena | Quando é o certo | Custo escondido |
|---|---|---|---|
| CSV | Linha, texto puro | Troca com humano, volume pequeno | Sem tipo, sem compressão; lê tudo para usar uma coluna |
| JSON / JSONL | Linha, aninhado | Estrutura irregular, evento bruto | Verboso; análise custosa em volume alto |
| Parquet | Coluna, comprimido | Praticamente todo treino tabular | Escrita mais cara; ruim para acrescentar registro a registro |
| RecordIO / protobuf | Binário sequencial | Algoritmos nativos do SageMaker | Precisa de conversão; ilegível para depuração |
A regra que resolve a maioria das questões de formato
Se o cenário tem muitas colunas e o treino usa algumas, a resposta é colunar — Parquet. O formato colunar lê só as colunas pedidas, e num conjunto de duzentas colunas onde o modelo usa doze, isso não é otimização de margem: é ler 6% do que você leria em CSV, em toda época de treinamento.
Particionamento: a otimização que a prova adora
Particionar é organizar os objetos no S3 em prefixos que refletem como você vai consultá-los — tipicamente por data. O ganho não é de armazenamento, é de leitura: uma consulta que filtra por mês lê apenas os prefixos daquele mês, e ignora o resto sem custo.
# Sem partição — toda consulta varre tudo:
s3://lago/eventos/arquivo-0001.parquet
s3://lago/eventos/arquivo-0002.parquet
# Particionado por data — a consulta de março lê só março:
s3://lago/eventos/ano=2026/mes=03/dia=01/parte-0000.parquet
s3://lago/eventos/ano=2026/mes=03/dia=02/parte-0000.parquetParticionar demais é tão ruim quanto não particionar
Partição por hora num conjunto pequeno produz milhares de arquivos minúsculos, e aí o gargalo deixa de ser o volume lido e passa a ser o número de requisições ao S3 e a sobrecarga por arquivo. O nome do problema é "muitos arquivos pequenos", e ele aparece na prova disfarçado de "o trabalho ficou mais lento depois que aumentamos a granularidade".
import awswrangler as wr
import pandas as pd
df = wr.s3.read_csv("s3://lago/bruto/eventos/", dataset=True)
df["ano"] = pd.to_datetime(df["criado_em"]).dt.year
df["mes"] = pd.to_datetime(df["criado_em"]).dt.month
# `dataset=True` + `partition_cols` escrevem o prefixo ano=/mes= que vira índice.
# `max_rows_by_file` existe para NÃO cair no problema de muitos arquivos pequenos:
# sem ele, um Spark com 400 partições escreve 400 arquivos minúsculos.
wr.s3.to_parquet(
df=df,
path="s3://lago/curado/eventos/",
dataset=True,
mode="overwrite_partitions",
partition_cols=["ano", "mes"],
compression="snappy",
max_rows_by_file=2_000_000,
)
# A prova de que valeu: leia só as colunas do modelo e compare o volume varrido.
usadas = wr.s3.read_parquet("s3://lago/curado/eventos/", columns=["valor", "categoria", "score"])
print(usadas.memory_usage(deep=True).sum())Um conjunto de treinamento tem 300 colunas, e o modelo usa 15. Os dados chegam como CSV no S3 e o treino está caro. Qual mudança tem o maior efeito?
Escolher o serviço de ingestão
| Origem | Serviço | Por quê |
|---|---|---|
| Fluxo contínuo de evento | Kinesis Data Streams ou Firehose | Firehose entrega direto no S3 com conversão de formato; Streams dá controle de consumo |
| Banco relacional operacional | AWS DMS ou Glue | DMS faz carga inicial e captura de mudança contínua sem tocar na aplicação |
| Arquivo em servidor local | DataSync ou Storage Gateway | DataSync para migração recorrente; Gateway quando o acesso precisa continuar local |
| Volume grande, rede ruim | Família Snow | Quando copiar pela rede levaria mais tempo que enviar um dispositivo |
O critério que a prova usa quase sempre é tempo e esforço, não capacidade técnica — vários desses serviços resolveriam o mesmo caso. Quando o cenário disser "sem alterar a aplicação de origem", captura de mudança com DMS ganha. Quando disser "no menor tempo, com a rede atual saturada", a família Snow ganha, por mais anacrônico que pareça enviar hardware.
Um conjunto particionado por hora acumulou 400 mil arquivos de 200 KB. As consultas ficaram mais lentas depois da mudança de granularidade. Qual é o problema?
Qual é a razão principal para converter dados de treinamento para um formato colunar?
Próximo passo
Com o dado no lugar e no formato certo, o passo seguinte é transformá-lo em algo que um modelo consiga aprender — e é onde mora o defeito mais caro de todo o domínio 1, que é o atributo que já contém a resposta.
Perguntas frequentes
❓ Qual formato de arquivo usar para treinamento de ML na AWS?
❓ Por que particionar dados no S3 deixou minhas consultas mais lentas?
❓ Quando usar DMS, DataSync ou a família Snow para trazer dados para a AWS?
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…