Ingestão, organização e catalogação de dados na AWS

Batch, streaming, Glue Studio, S3 e Data Catalog na prática

Por Fábio Linhares • Instituto Infnet

Os desafios que estas questões colocam em prática

Este conjunto de questões foi construído para avaliar execução com critério técnico. O foco não é decorar nomes de serviços, e sim montar um fluxo completo: ingestão de dados de e-commerce, organização em Data Lake, escrita tratada em S3 e catalogação para consumo analítico.

Ao longo do caminho, você precisa lidar com decisões que aparecem em projetos reais de dados: quando usar batch, quando justificar streaming, por que converter para Parquet, por que particionar por data e como transformar estrutura física em metadado utilizável no Glue Data Catalog.

O diferencial está na evidência. Além de configurar o pipeline, você precisa provar resultado com prints do fluxo no Glue Studio, estrutura particionada no S3 e tabela catalogada com schema e metadados de negócio. Essa disciplina de validação é parte central da competência profissional em engenharia de dados na nuvem.

Em termos didáticos, o melhor jeito de estudar este material é pensar cada etapa em quatro perguntas: o que a questão quer, qual configuração atende ao pedido, como validar tecnicamente e qual erro comum pode comprometer a entrega.

▼

ETAPA 1.1

Criando um job visual no AWS Glue Studio

Montar um pipeline ETL visual com origem no S3, transformação mínima e destino também no S3.

Esta etapa valida se você sai da explicação abstrata e consegue estruturar um fluxo operacional no Glue Studio. O caminho esperado é um Visual ETL Job com nós de leitura, transformação e escrita, deixando o grafo legível e coerente com o objetivo da ingestão.

Para chegar na resposta correta, selecione um dataset de e-commerce, envie a origem bruta para o S3 e configure o job visual com source no S3, ao menos uma transformação simples e target também no S3. O ponto de avaliação não é apenas criar o job, mas mostrar o fluxo conectado com propósito técnico claro.

Checkpoint: o print mais forte desta etapa é o grafo completo do job, não a tela inicial do console. É isso que evidencia que o pipeline foi realmente desenhado e não apenas iniciado.

Como pensar esta etapa

1. Primeiro, pense no pipeline como três blocos: leitura, transformação e escrita.

2. Depois, escolha uma transformação mínima que mostre tratamento real do dado, e não apenas cópia.

3. Em seguida, confira se a origem e o destino estão no S3 correto.

4. Por fim, valide se o grafo visual conta a história inteira sem precisar de explicação oral longa.

Exemplo de origem bruta:
s3://raw-zone/ecommerce/sales/

Exemplo de colunas esperadas:
order_id, order_timestamp, customer_id, product_id, amount, status

Erro comum: criar um job com source e target, mas sem deixar claro onde a transformação acontece. Isso enfraquece a evidência técnica.

Antes de rodar, revise o desenho do grafo. Se leitura, transformação e escrita não estiverem claramente separadas, o pipeline ainda está confuso.

▼

ETAPA 1.2

Efetuando ingestão batch e convertendo para Parquet

Ler um conjunto finito de vendas, ajustar schema e gravar a saída em formato colunar.

Aqui, a exigência é processamento em lote: ler um recorte fechado de dados de vendas, tratar tipos e escrever saída tratada. O formato Parquet é parte importante da resposta porque melhora leitura analítica e organiza melhor o armazenamento do que arquivos crus.

Não basta trocar extensão. A validação real passa por schema coerente antes da escrita: campos temporais como timestamp, campos monetários como decimal ou double e identificadores estáveis como string.

Checkpoint: a validação é dupla: execução concluída com sucesso no job e presença de arquivos Parquet no destino do S3.

Raciocínio mínimo para acertar o batch

1. Batch significa conjunto fechado de dados, não fluxo contínuo.

2. Antes de gravar, revise se data, valor monetário e identificadores estão com tipos coerentes.

3. Só depois disso escolha Parquet como formato de saída.

4. Feche a etapa mostrando execução e arquivos gerados, não apenas configuração.

Exemplo de validação conceitual do schema:
- order_timestamp -> timestamp
- amount -> decimal/double
- order_id -> string

Saída esperada:
arquivos .parquet no bucket de destino

Erro comum: gravar em Parquet sem corrigir o schema antes. O arquivo sai, mas o catálogo e o consumo analítico ficam frágeis.

Parquet recompensa disciplina de schema. Ajustar tipos antes da escrita evita catálogo inconsistente nas etapas seguintes.

▼

ETAPA 1.3

Salvando no clean-zone com particionamento por ano, mês e dia

Organizar fisicamente os dados tratados no lake usando partições temporais defensáveis.

Esta etapa demonstra entendimento de modelagem física de Data Lake. Particionar não é detalhe estético; impacta custo de leitura, rastreabilidade operacional e desempenho em consultas por período.

A resposta esperada é gravar em uma área clean-zone, em Parquet, com partições derivadas da data do evento de venda: ano, mês e dia. Isso mostra organização do dado com critério técnico e não apenas armazenamento bruto.

Checkpoint: o print deve mostrar a hierarquia de partições no S3 e os arquivos Parquet dentro delas.

Como decidir uma partição defensável

1. Escolha uma coluna temporal que represente o evento de negócio, não um detalhe acidental.

2. Derive ano, mês e dia a partir dessa coluna temporal.

3. Use essas colunas como chaves de partição na escrita do Glue.

4. Depois confira no S3 se a estrutura final realmente reflete essas chaves.

Exemplo de estrutura esperada no S3:
s3://clean-zone/ecommerce/sales/ano=2026/mes=03/dia=11/part-0000.parquet

Erro comum: particionar por um campo sem significado operacional ou por uma data que não representa o evento de venda.

Partição deve representar semântica de negócio ou operação. Data do evento costuma ser mais defensável do que data de upload.

▼

ETAPA 2.1

Pensando uma ingestão streaming para cliques de usuário

Propor uma arquitetura plausível de ingestão contínua e explicar a diferença entre streaming e batch.

O objetivo aqui é mostrar raciocínio de arquitetura. A proposta mais sólida é usar Kinesis Data Streams para ingestão de eventos de clique e um job de streaming do Glue para consumir, transformar e gravar os dados no S3.

A defesa técnica precisa ir além de “streaming é mais rápido”. O ponto certo é explicar que batch processa conjuntos fechados em janelas definidas, enquanto streaming processa eventos continuamente, com menor latência.

Checkpoint: uma resposta boa conecta o tipo de evento à estratégia de processamento escolhida e deixa explícita a diferença entre fluxo contínuo e lote fechado.

Batch versus streaming sem resposta automática

1. Pergunte primeiro como o dado nasce: em eventos contínuos ou em lotes fechados.

2. Se o evento é contínuo e sensível a latência, streaming faz sentido.

3. Se o conjunto é fechado e pode esperar uma janela de processamento, batch costuma bastar.

4. Na defesa, explique o porquê da arquitetura, não apenas o nome dos serviços.

Exemplo de evento:
{
  "event_time": "2026-03-11T17:20:00Z",
  "user_id": "u123",
  "session_id": "s456",
  "page": "/produto/789",
  "action": "click_buy",
  "device": "mobile"
}

Fluxo proposto:
site/app -> Kinesis Data Streams -> Glue Streaming Job -> S3

Erro comum: dizer apenas que streaming é mais rápido. A resposta fica fraca se não falar de continuidade do fluxo e latência.

Em defesa oral, justifique streaming pelo comportamento do evento e pela necessidade de latência, não apenas pelo nome do serviço.

▼

ETAPA 3.1

Criando um Glue Crawler para descobrir a estrutura no S3

Transformar arquivos particionados em uma tabela catalogada no Glue Data Catalog.

Depois da escrita no S3, entra a etapa de catalogação. O crawler conecta o armazenamento físico do lake à representação lógica em tabela, permitindo descoberta de schema e partições no Glue Data Catalog.

A configuração esperada é apontar para a raiz lógica do dataset na clean-zone, vincular a um database do catálogo e executar a varredura. Apontar para subpastas isoladas pode gerar catálogo incompleto.

Checkpoint: a evidência correta é a tabela criada no catálogo com colunas e partições detectadas.

Como configurar o crawler sem se sabotar

1. Aponte o crawler para a raiz do dataset tratado.

2. Vincule-o ao database correto no Data Catalog.

3. Execute a varredura e abra a tabela criada.

4. Verifique se as partições apareceram como parte da estrutura descoberta.

Exemplo de database:
ecommerce_clean

Origem do crawler:
s3://clean-zone/ecommerce/sales/

Erro comum: apontar o crawler para uma pasta já particionada de um único dia e depois achar que catalogou o dataset inteiro.

Pense em raiz do dataset, não em pasta do dia. Crawler em caminho curto demais costuma esconder parte das partições.

▼

ETAPA 3.2

Revisando o schema e adicionando metadados de negócio

Validar a estrutura descoberta e enriquecer o catálogo com descrições úteis para interpretação do dado.

Esta etapa trata de significado, não apenas estrutura. O crawler descobre schema técnico, mas a camada de entendimento depende de revisão humana e de metadados de negócio bem escritos.

A resposta esperada é revisar nomes, tipos e partições da tabela no catálogo e adicionar descrições que expliquem o papel de cada coluna no processo de negócio.

Checkpoint: quando isso é feito, o dado deixa de ser apenas armazenado e passa a ser interpretável por outras pessoas do time com menos risco de erro semântico.

Como enriquecer o catálogo de forma útil

1. Revise se os tipos inferidos pelo crawler fazem sentido técnico.

2. Depois, escreva descrições que expliquem o significado da coluna para o negócio.

3. Diferencie claramente identificadores, medidas e campos de partição.

4. Considere concluída a etapa apenas quando outra pessoa conseguir entender a tabela sem depender de você.

Exemplos de descrições de negócio:
- order_id: identificador único do pedido
- order_timestamp: data e hora de registro do pedido
- amount: valor total do pedido em BRL
- status: estado do pedido no processo comercial
- ano/mes/dia: campos usados para particionamento temporal

Erro comum: achar que o crawler já resolveu o catálogo inteiro. Ele descobre estrutura; o sentido de negócio ainda precisa ser acrescentado.

Tipo de dado diz como armazenar. Metadado de negócio diz como interpretar. Sem os dois, o catálogo fica incompleto.