Programação, IaC, CI/CD

Resuma ferramentas IaC (CloudFormation, CDK, SAM), configuração Lambda, CI/CD e conceitos de computação distribuída.

Um pipeline de dados é, em última análise, código. A função Lambda que coleta dados, o job Glue que os transforma, o bucket S3 que os armazena — tudo deve ser definido e gerenciado como código. Assim como desenvolvedores de software usam controle de versão e implantação automatizada para código de aplicações, engenheiros de dados gerenciam sua infraestrutura e pipelines como código. Isso é possibilitado por IaC (Infrastructure as Code) e pipelines CI/CD. O exame AWS DEA-C01 testa sua compreensão dessas ferramentas e quando usar cada uma corretamente.

 

Comparação de Ferramentas IaC — Formas de Definir Infraestrutura como Código

IaC significa "definir a infraestrutura como código para que possa ser criada, gerenciada e excluída automaticamente." Em vez de criar manualmente um bucket S3 no console AWS, configurar o RDS e implantar Lambda à mão, um único arquivo de código faz tudo isso em uma etapa.

| Ferramenta | Linguagem | Características | |-----------|---------|----------------| | AWS CloudFormation | YAML ou JSON | IaC nativa da AWS. Templates declarativos. Suporte a todos os recursos AWS. | | AWS CDK | Python, TypeScript, Java, etc. | Defina infraestrutura com linguagens de programação. Compila para CloudFormation internamente. | | AWS SAM | YAML (extensão do CloudFormation) | Especializado para aplicações serverless. Definição simplificada para Lambda, API Gateway, DynamoDB. |

CloudFormation — Templates Declarativos

A ideia é "declare o estado final que você quer e a AWS cria por você." Como plantas arquitetônicas, um template CloudFormation diz "construa esta infraestrutura," e a AWS cria automaticamente os recursos necessários.

Uma Stack é a unidade central do CloudFormation. Recursos AWS relacionados são agrupados em uma stack e podem ser criados, atualizados e excluídos juntos.

AWS CDK — Defina Infraestrutura com Linguagens de Programação

O CDK permite definir infraestrutura usando Python, TypeScript ou outras linguagens de programação. É muito mais flexível que YAML. Você pode usar loops, condicionais, funções e classes para definir infraestrutura dinamicamente.

Por exemplo, se você precisar criar o mesmo bucket S3 em 10 regiões, o CloudFormation exigiria 10 templates separados. O CDK resolve isso com um único loop. O código CDK é finalmente sintetizado (compilado) em templates CloudFormation antes da implantação.

AWS SAM — IaC Especializado para Serverless

SAM (Serverless Application Model) é uma extensão do CloudFormation. Define recursos serverless como Lambda, API Gateway e DynamoDB com muito menos código repetitivo. A CLI do SAM também suporta testes locais e implantação simplificada.

 

Lambda — Entendendo da Perspectiva da Engenharia de Dados

AWS Lambda executa código sem nenhum servidor. O código só executa quando um evento o aciona, e você só paga pela duração da execução. Na engenharia de dados, o Lambda atua como "pequenos componentes de automação" ao longo de um pipeline.

Principais restrições do Lambda que você deve conhecer

Concorrência: O número de instâncias Lambda em execução simultaneamente. O limite padrão no nível da conta é 1.000.

Concorrência Reservada (Reserved Concurrency): Reserva um número específico de execuções concorrentes para um Lambda específico. Impede que outros Lambdas consumam todo o limite. Concorrência Provisionada (Provisioned Concurrency): Pré-aquece instâncias para que estejam prontas para responder instantaneamente — eliminando cold starts (o atraso que ocorre quando uma função é executada pela primeira vez após um período de inatividade).

Tempo limite (Timeout): Máximo 15 minutos. Qualquer job ETL que precisar de mais de 15 minutos deve ser movido para Glue ETL ou EMR. O Lambda é mais adequado para tarefas curtas e rápidas na engenharia de dados.

Memória: Configurável de 128 MB a 10 GB. No Lambda, aumentar a memória também aumenta proporcionalmente o desempenho da CPU. Se o processamento de dados estiver lento, aumentar a memória é a primeira otimização a tentar.

Montagem de EFS: O Lambda pode montar o Amazon EFS (Elastic File System) para acessar arquivos grandes. Embora o armazenamento temporário do Lambda (/tmp) tenha um máximo de 10 GB, o EFS é a escolha certa para arquivos compartilhados entre múltiplas funções ou conjuntos de dados maiores.

Runtime: Python é de longe o runtime Lambda mais comum para engenharia de dados. Bibliotecas como pandas, numpy e boto3 podem ser adicionadas como Lambda Layers.

 

Pipeline CI/CD — Implantação Automatizada para Pipelines de Dados Também

CI/CD (Integração Contínua / Entrega Contínua) é um sistema onde as mudanças de código são automaticamente testadas e implantadas. Como os pipelines de dados são código, os mesmos princípios CI/CD que se aplicam ao desenvolvimento de software se aplicam aqui também.

Um fluxo típico de pipeline CI/CD na AWS:

CodeCommit: Repositório Git gerenciado pela AWS, similar ao GitHub. CodeBuild: Automação de build e testes, executa em contêineres. CodeDeploy: Automatiza a implantação de código de aplicações para EC2, Lambda e ECS. CodePipeline: Conecta todas as etapas acima em um único pipeline.

Considerações para CI/CD em pipelines de dados: Mudança em script Glue ETL → testes automatizados → implantar no S3 Mudança em template CloudFormation/CDK → atualização automática da stack Mudança em código Lambda → implantação automatizada + implantação blue/green para reversão segura

 

Conceitos Fundamentais de Computação Distribuída

Para trabalhar com sistemas de processamento distribuído como Spark e EMR, você precisa entender alguns conceitos fundamentais. Esses aparecem frequentemente em perguntas do exame DEA-C01 sobre problemas de desempenho e design de sistemas.

Shuffling (Embaralhamento)

O processo de redistribuir dados entre nós. Por exemplo, uma operação GROUP BY país requer que todos os registros do mesmo país estejam no mesmo nó. Mover dados pela rede para conseguir isso é o shuffling.

O shuffling é caro porque os dados viajam pela rede entre nós. É uma das principais causas de problemas de desempenho no Spark. Minimizar o shuffling é um tema central na otimização do Spark.

Particionamento (Partitioning)

Dividir dados em unidades lógicas para processamento paralelo. Se você dividir 100 milhões de registros em 100 partições, 100 núcleos podem cada um processar uma partição simultaneamente. Poucas partições significa baixo paralelismo; muitas partições aumenta a sobrecarga de coordenação.

Distorção de Dados (Data Skew)

Quando os dados são distribuídos de forma extremamente desigual entre partições. Por exemplo, se uma partição de 100 contém 80% dos dados totais, o nó processando essa partição se torna um gargalo — todos os outros nós terminam e então esperam pelo único nó sobrecarregado. Todo o job executa na velocidade da partição mais lenta.

Como corrigir o skew: Mudar a chave de partição para uma coluna com distribuição mais uniforme Dividir artificialmente a partição distorcida em partes menores (técnica chamada salting)

Serialização (Serialization)

Para enviar dados entre nós, objetos na memória devem ser convertidos para um fluxo de bytes (serialização), e o nó receptor os converte de volta para objetos (desserialização). A serialização Kryo é mais rápida e compacta que a serialização padrão do Java e é a escolha recomendada para jobs Spark.

 

Resumo dos Pontos-Chave para o Exame

| Palavra-chave | Ferramenta/Conceito | |--------------|---------------------| | Definição declarativa de infraestrutura YAML/JSON | AWS CloudFormation | | Definir infraestrutura com linguagem de programação (Python/TypeScript) | AWS CDK | | IaC especializado em serverless (Lambda, API Gateway) | AWS SAM | | Acessar arquivos compartilhados grandes do Lambda | Montagem EFS | | Job Lambda excede 15 minutos | Mudar para Glue ETL ou EMR | | Eliminar cold starts do Lambda | Concorrência Provisionada | | Build e implantação automatizados na mudança de código | CodePipeline (CodeBuild + CodeDeploy) | | Redistribuição de dados entre nós (operação Spark cara) | Shuffling | | Dados concentrados em partições específicas | Data Skew (distorção de dados) | | Corrigir distribuição desigual de partições | Mudar chave de partição ou usar Salting |

O CDK não substitui o CloudFormation — é uma camada de abstração construída sobre o CloudFormation. O código CDK sempre compila para um template CloudFormation antes da implantação.

Voltar à lista do blog