Transformação em Escala: AWS Glue, EMR Serverless e Lambda

As lições 01 até 07 deram a você um lake: layout no S3, formatos de arquivo, open table formats, ingestão em lote e streaming, e um catálogo. Nada disso é ainda curado. Esta lição é sobre a camada que faz a curadoria, os motores que leem raw e bronze, limpam, deduplicam e gravam silver e gold, e sobre as três coisas que decidem se essa camada é barata, correta, ou ambas: qual motor você roda, quanta capacidade você mantém enquanto ele roda, e se a segunda execução produz duplicatas.

Nesta lição você vai:

• modelar o job Glue ETL: anatomia, precedência de argumentos, o teto de 260 KB, triggers, cotas de concorrência e o comportamento de fila de jobs de 2024;
• separar DynamicFrame de DataFrame e dirigir resolveChoice com a ação certa antes de qualquer escrita;
• operar job bookmarks: Enable / Disable / Pause, no que as fontes S3 e JDBC realmente se baseiam, por que rewind nunca apaga os seus outputs, e como isso difere do MERGE do Iceberg;
• dimensionar workers: G.1X até G.16X, workers de memória otimizada R, o Z.2X do Ray, o streaming G.025X, tetos de --executor-cores e auto scaling;
• criar conteúdo com Glue Studio: ETL visual, notebooks e o editor de script, e ler a matriz de versões do Glue em outubro de 2026, o que cada linha custa e o que ela quebra;
• rodar EMR Serverless, aplicações, Workspaces, fixação de release, cobrança, e saber exatamente quando ele vence o Glue, mais Lambda para o plano de controle e nunca para o plano de dados;
• aplicar padrões de lakehouse com Spark: dynamic partition overwrite, AQE, skew, shuffle partitions e compactação de arquivos pequenos;
• escrever um job Glue PySpark resolvido da leitura do catálogo até o Iceberg silver, e precificar cada drill na tabela de preços de outubro de 2026;
• estudar dois casos de clientes da AWS (Transport for NSW, Vanguard) mais uma caixa de atualizações de 2026 com fontes;
• praticar com 11 questões no estilo de exame e cinco verificações interativas.

---

1. A escada de motores: cinco caminhos do raw ao silver

A AWS posiciona um número pequeno de caminhos de transformação para o trabalho em lote de lakehouse, e eles não são intercambiáveis. A escada vai do mais integrado, menos flexível para o mais flexível, mais operacional:

Duas propriedades dessa escada importam mais que qualquer lista de features. Primeiro, somente o Glue ETL tem job bookmarks ligados ao modelo de job, o processamento incremental é um argumento de primeira classe, não código que você escreve. Segundo, Glue e EMR Serverless cobram de formas diferentes: DPU-hours contra vCPU-hours mais GB-hours, então um número de manchete "por DPU" e um "por vCPU" nunca podem ser comparados sem normalizar a memória (a Seção 13 faz a aritmética).

---

2. O modelo de job do Glue ETL: anatomia, argumentos, triggers, fila

2.1 O que um job de fato é

Um job do Glue é uma definição mais execuções. A definição é: script (ou DAG visual), tipo de worker e número de workers, IAM role, connections e security settings opcionais, argumentos padrão, timeout, retries, MaxConcurrentRuns, e os triggers que o iniciam. Uma execução é uma execução limitada com um estado e um histórico retido.

MaxConcurrentRuns começa em 1, e o histórico de execuções do job é retido por 90 dias: dois números que valem a pena decorar, porque uma execução parada em WAITING está te dizendo sobre cota ou sobre a posição do trigger, não sobre o seu código.

2.2 Argumentos: três camadas, um teto rígido

Argumentos são como um script genérico se torna um pipeline específico. Três camadas se aplicam, nesta precedência:

1. NonOverridableArguments (mais alta: você não consegue burlá-las em tempo de execução)
2. Arguments da execução fornecidos no StartJobRun
3. DefaultArguments no job

e o payload inteiro de argumentos tem um tamanho máximo de 260 KB. Esse teto é a razão pela qual você nunca inlina um megabyte de SQL ou um blob base64 nos argumentos: coloque o SQL em um objeto do S3 e referencie-o com --extra-py-files, --extra-jars ou --additional-python-modules.

Os argumentos que aparecem em quase todo job de lakehouse:

• 📚 Você sabia? --executor-cores tem um teto documentado: ele "não deve exceder 2x o número de vCPUs no tipo de worker." Em um G.1X (4 vCPUs) isso significa no máximo 8; em um G.2X, 16. Sobrescrever além disso não adiciona paralelismo: atormenta memória e disco, o que então parece um problema de skew, mas não é (referência de argumentos de job do AWS Glue, acesso em out 2026).

2.3 Triggers: scheduled, conditional, on-demand

Os triggers do Glue vêm em três sabores, Scheduled (um schedule), Conditional (sobre o status de um job ou crawler anterior) e On-demand, com estados de ciclo de vida CREATED, ACTIVATED, DEACTIVATED. Duas regras rígidas mordem na prática:

• você pode anexar um máximo de 2 crawlers a um único trigger;
• uma cadeia conditional só funciona se a cadeia em si for iniciada por trigger a partir de uma raiz scheduled ou on-demand: um job lançado manualmente não dispara os triggers conditionais a jusante.

2.4 Fila em vez de falha no teto de concorrência

Antes de setembro de 2024, atingir Max concurrent job runs per account, per-job concurrency ou Max task DPUs per account falhava a chamada StartJobRun redondamente, e os times construíam loops de retry do Step Functions para absorver isso. A AWS Glue job queuing (disponibilidade geral, AWS Big Data Blog, 3 set 2024) mudou o formato: "quando as execuções do job estão em estado Waiting, o recurso de fila de jobs do AWS Glue escalona os jobs automaticamente sempre que possível." O modo de falha vira uma posição na fila, e a capacidade se libera conforme outras execuções terminam.

---

3. DynamicFrame versus DataFrame, e resolveChoice

3.1 As duas representações

Um DataFrame do Spark precisa de um schema antes que os dados possam ser carregados: esse é o seu contrato. Um DynamicFrame do Glue quebra esse contrato de propósito, porque a ingestão real pousa dados inconsistentes:

"cada registro é autodescrevível, então nenhum schema é necessário inicialmente. Em vez disso, o AWS Glue calcula um schema sob demanda quando necessário, e codifica explicitamente as inconsistências de schema usando um tipo choice (ou union)."

Esse tipo choice é poderoso e perigoso. É poderoso porque um JSON amostrado por crawler onde price é número em algumas linhas e string em outras carrega sem falhar. É perigoso porque o choice sobrevive até o seu caminho de escrita e degrada colunas silenciosamente para um tipo geral.

DynamicFrame dá a você uma caixa de ferramentas de transforms, apply_mapping, drop_fields, filter, join, map, mergeDynamicFrame, relationalize, rename_field, resolveChoice, select_fields, spigot, split_fields, split_rows, unbox, union, unnest, unnest_ddb_json, write, das quais relationalize é a que as pessoas esquecem: ele "Converte um DynamicFrame em uma forma que cabe em um banco de dados relacional" desconcolando colunas aninhadas e pivoteando colunas de array em uma lista de frames.

3.2 resolveChoice: assente o schema antes de mapear

resolveChoice recebe especificações (field_path, action). As ações são:

Você também pode converter com toDF(options), onde options é uma lista de objetos ResolveOption: mesma ideia, amarrado ao DataFrame.

3.3 Exemplo resolvido E1: uma coluna price de tipo misto

3.4 a dobradiça do Glue 5.0+ para a qual você precisa planejar

As release notes dizem isso explicitamente: "O controle de acesso em nível de tabela com Dynamic Frame / GlueContext e permissões do AWS Lake Formation suportado no Glue 4.0 ou anterior não é suportado no Glue 5.0." Um script que se apoia em DynamicFrame e no enforcement de Lake Formation em nível de tabela via GlueContext é, portanto, um artefato do Glue ≤4.0. No 5.1 e no 6.0 a direção é o FGAC (fine-grained access control) nativo do Spark: DataFrames puros mais row filters e column masks do Lake Formation. Migrar um script com resolveChoice + apply_mapping da era 3.0 sem adotar FGAC significa manter o código e perder o enforcement.

---

4. Job bookmarks: execuções incrementais sem reler tudo

4.1 O que é um bookmark

"O AWS Glue rastreia dados que já foram processados durante uma execução anterior de um job de ETL persistindo informações de estado da execução do job."

O estado é persistido por job e indexado por transformation_ctx, o rótulo que você anexa a cada source e sink no script. Mantenha a source e o seu transformation_ctx estáveis; troque um caminho sem trocar a chave e o estado deixa de casar com o que você acha que ele casa.

Os três modos que você define com --job-bookmark-option:

4.2 No que cada tipo de fonte se baseia

• Amazon S3: "Os job bookmarks do AWS Glue verificam o horário da última modificação dos objetos para verificar quais objetos precisam ser reprocesados." Os formatos suportados dependem da versão: v0.9 suporta JSON, CSV, Avro e XML; v1.0 e posterior adicionam Parquet e ORC.
• JDBC: "O AWS Glue usa por padrão a primary key como a chave do bookmark, desde que ela seja sequencialmente crescente ou decrescente (sem lacunas)." Chaves surrogate, não sequenciais, precisam de uma bookmark key explícita.

4.3 A lista de falhas: leia isto antes de mandar para produção

• Disable é o padrão. Esquecer --job-bookmark-option=job-bookmark-enable reproprocessa tudo silenciosamente a cada execução, e a sua conta não diz nada sobre isso.
• Não troque a propriedade da fonte de dados com o bookmark habilitado. A AWS lista isso como best practice exatamente pela razão acima: estado stale mais um caminho novo pula ou relê arquivos duas vezes.
• Rewind e reset não limpan destinos. "Quando você dá rewind ou reset em um bookmark, o AWS Glue não limpa os arquivos de destino… Apenas arquivos de fonte são rastreados com job bookmarks." Idempotência do lado da escrita é trabalho seu (Seção 11).
• Pause é para backfill, não para estado estável. Ele reproprocessa uma janela de run-IDs e não avança: perfeito para reexecutar 102 e 103, errado como modo diário.
• Listagens grandes podem esgotar o driver. Use o AWS Glue Amazon S3 file lister para datasets grandes em vez de deixar o driver enumerar milhões de chaves.

4.4 Exemplo resolvido E2, o drill de backfill

• 📚 Você sabia? O estado do bookmark não se limita a JSON e CSV: a partir do Glue 1.0, os bookmarks do S3 também persistem estado para entradas em Parquet e ORC, então o bronze parquetizado que você construiu na Lição 05 é amigável a bookmarks, o folclore da era 0.9 de "somente JSON/CSV" está desatualizado (guia de desenvolvedor do AWS Glue, monitor continuations, acesso em out 2026).

---

5. Workers, DPUs e M-DPUs: de onde vêm a conta e o OOM

5.1 A unidade

"Uma DPU é uma medida relativa de poder de processamento que consiste em 4 vCPUs de capacidade de compute e 16 GB de memória."

E a variante de memória otimizada: "DPUs de Memória Otimizada (M-DPUs): workers do tipo R usam M-DPUs, que fornecem o dobro da alocação de memória para um dado tamanho comparado a DPUs padrão": 32 GB por 4 vCPU. Tudo a jusante (preço, triagem de OOM, a comparação Glue-versus-EMR) decorre dessas duas frases.

5.2 Catálogo de workers (em out 2026)

5.3 Capacidade: MaxCapacity é legado, workers são o presente

• AllocatedCapacity está depreciado: "Use MaxCapacity instead."
• Para jobs do Glue 2.0+: "você não pode especificar uma Maximum capacity. Em vez disso, você deve especificar um Worker type e o Number of workers. Não defina MaxCapacity se estiver usando WorkerType e NumberOfWorkers."
• Onde MaxCapacity ainda se aplica: pythonshell 0.0625 ou 1 DPU; glueetl/gluestreaming legado na faixa de 2 to 100 DPUs, padrão 10, sem alocação fracionária de DPU.
• Auto scaling: --enable-auto-scaling=true liga o auto scaling e a cobrança por worker, com NumberOfWorkers atuando como o máximo.

5.4 Exemplo resolvido E3: dimensionar e precificar um batch de 400 GB

5.5 Exemplo resolvido E4, o mesmo job quando a memória, não a velocidade, é a restrição

• 📚 Você sabia? O disco é a restrição silenciosa: o G.1X expõe 94 GB de disco, mas apenas cerca de 44 GB estão livres: spills de shuffle e dados intermediários locais grandes pousam lá. Se a Spark UI mostra spill pesado em um G.1X, você está limitado por disco e não por CPU, e a correção é um G.4X (256 GB, cerca de 230 GB livres) ou shuffle storage em nuvem (tipos de worker do AWS Glue, acesso em out 2026).

---

6. Glue Studio: ETL visual, notebooks e o editor de script sobre o mesmo motor

O Glue Studio não é um serviço diferente, é o plano de autoria e operações. A AWS oferece três formas de entrada: Visual ETL (uma interface visual focada no fluxo de dados), um notebook de código interativo (baseado em Jupyter) e um editor de script onde você escolhe o motor, Python shell, Ray, Spark (Python) ou Spark (Scala). O pitch visual é exato: "você pode compor visualmente workflows de transformação de dados e executá-los sem emenda no motor de ETL serverless baseado no Apache Spark do AWS Glue… usando uma interface de arrastar e soltar sem precisar aprender Spark ou escrever código."

O que faz dela mais do que uma ferramenta de diagrama:

• O grafo visual compila através de CodeGenConfigurationNodes: "A representação de um grafo acíclico dirigido no qual tanto o componente visual do AWS Glue Studio quanto a geração de código do AWS Glue Studio se baseiam." O canvas e o script gerado são duas visões de um DAG.
• Existem dois sabores de código: "a versão original, ou Classic, e uma versão mais nova e simplificada." Leia as duas antes de assumir que o script gerado é ilegível.
• O editor traz as abas Script, Job details, Runs, Data quality, Schedules e Version Control, mais schema em nível de node e dados de exemplo no diagrama.
• O preview de dados roda em sessões interativas: consumo real de DPU, não um preview grátis no hover.
• Job Notebooks dão superfícies de notebook serverless suportadas por AWS Glue Interactive Sessions, salváveis e agendáveis como jobs; jobs de exemplo incluem "Visual ETL job to join multiple sources", "Spark notebook using Pandas" e "Spark notebook using SQL".

---

7. A matriz de versões do Glue (out 2026) e o Glue for Ray

7.1 A matriz

Duas ferramentas ficam sob essa tabela: uma ferramenta de análise de upgrade que inspeciona jobs do Glue ≥2.0 e recomenda um alvo de migração, e um Spark Upgrade Agent para mover jobs existentes para o 6.0.

7.2 Glue for Ray: resumo, e o que mudou

Jobs de Ray usam "os mesmos jobs do AWS Glue e sessões interativas que você usa com o AWS Glue para Spark", rodam em workers baseados em Graviton medidos em M-DPUs (4 vCPU e 32 GB cada), e hoje têm exatamente um tipo de worker: Z.2X (2 M-DPU, 8 vCPU, 64 GB de memória, 128 GB de disco, até 8 Ray workers do autoscaler). O pitch é pandas sem reescrita: "execute os seus workflows pandas contra big data em escala empresarial: com apenas algumas linhas de código": mais auto scaling embutido no modelo de job do Glue e a relação preço-desempenho do Graviton.

O reality check de outubro de 2026: o AWS Glue for Ray não está mais aberto a novos clientes (fechado em 30 de abril de 2026); clientes existentes continuam rodando jobs, não há planos de novas features além de segurança e disponibilidade, e a AWS documenta um caminho de migração para Ray no Amazon Elastic Kubernetes Service com uma tabela de mapeamento de argumentos (--min-workers → workerGroupSpecs.minReplicas, --pip-install → Ray runtime-env pip) e um exemplo de ray job submit. Duas consequências para o projeto: não proponha Ray para um time que ainda não é cliente, e não construa um caminho crítico de lakehouse novo em uma faixa em modo de manutenção.

---

8. EMR Serverless: o trem de releases do EMR sem o cluster

8.1 Formato e setup

O EMR Serverless é um modelo de aplicação + runtime role + job submission. Você cria uma aplicação, concede uma job runtime role confiada por emr-serverless.amazonaws.com, aponta para o S3 e, opcionalmente, cria um EMR Studio Workspace para notebooks interativos: "você precisa especificar um bucket S3 e a service role mínima para o EMR Serverless criar um Workspace." Os Workspaces vêm com um conjunto pré-instalado útil para Python e PySpark: ggplot, matplotlib, numpy, pandas, plotly, bokeh, scikit-learn, scipy.

A seleção de release é flexível e por aplicação. "With Amazon EMR 6.6.0 and higher, deploy EMR Serverless"; a lista atual vai de EMR Serverless 7.13.0 até 6.6.0, mais o AWS runtime for Apache Spark (emr-spark-8.0.0) e sua variante de preview. Essa liberdade de fixação é a maior diferença arquitetural do Glue: você escolhe o runtime do EMR em vez da versão do Spark que o Glue acaba expondo.

A capacidade é elástica por execução, não por cluster. Você não dimensiona um cluster; a aplicação aloca workers para a execução e você é cobrado por segundo pelo que ela usa, com capacidade pré-inicializada disponível quando a latência de spin-up importa. Duas adições de 2025 encolhem tanto o custo quanto a proliferação de IAM: serverless storage (2 dez 2025, release 7.12 e superior), "No need to configure local disk or manage instances", com custo reduzido "by up to 20%", e inline runtime permissions (22 jul 2025), que "grant temporary permissions to jobs at runtime without creating separate IAM roles per job."

8.2 EMR on EKS e EMR provisionado: um parágrafo cada

EMR on EKS roda contêineres do EMR em clusters Kubernetes que você já opera. O preço é o uplift do EMR por cima do seu gasto com Kubernetes e EC2: $0.01012 por vCPU-hour mais $0.00111125 por GB-hour (sob demanda, contexto us-east-1), e "EMR on EKS cluster costs $0.10 per hour." Escolha-o quando você tem um estate de EKS, precisa de isolamento de workload por namespace de time, ou precisa misturar EMR Spark com outros serviços em contêiner.

EMR provisionado são clusters inteiros: você escolhe tipos e quantidades de instância, você é dono do comportamento de scaling, e você paga pela capacidade esteja ela ocupada ou ociosa. Ele permanece a resposta defensável para GPUs, AMIs customizadas, clusters sticky e Spark estável muito grande. Trate qualquer aritmética de markup por hora de cluster como algo que você reverifica contra a lista de preços ao vivo do EC2 para a sua Região antes de imprimi-la: as taxas verificadas para esta lição são Glue DPU e M-DPU, EMR Serverless vCPU e GB, e o uplift do EMR on EKS acima.

8.3 Quando o EMR Serverless vence o Glue (e quando não vence)

8.4 Exemplo resolvido E5, o mesmo job de 8 vCPU / 32 GB em dois medidores

• 📚 Você sabia? O EMR Serverless anuncia tanto um free tier de armazenamento, "O free tier é 20 GB de armazenamento padrão por mês durante 12 meses a partir do seu uso inicial", quanto "Per-second billing (rounded up, with a minimum of 1 minute)." Esse piso de 1 minuto é a razão de uma invocação de Spark de seis segundos ainda custar um minuto de vCPU e memória (preços do AWS EMR, acesso em out 2026).

---

9. Lambda para transforms leves: o bisturi do plano de controle

O Lambda pertence a esta lição porque ele continua aparecendo em arquiteturas de lakehouse: validando arquivos na chegada, registrando partições, fazendo fan-out de trabalho por tenant, promovendo um prefixo de staging. Ele não está aqui como motor de ETL, porque as cotas dizem que ele não pode ser um:

Use Lambda para: fan-out de eventos (S3 → EventBridge → Step Functions → Glue), validação de arquivos no landing, registro de partições no catálogo, correções minúsculas de S3 para S3 em um intervalo estreito de chaves, trocas de promoção em staging, e a cola de orquestração entre jobs.

NÃO use Lambda para: reescritas de tabela completas, joins que precisam de shuffle além do /tmp, qualquer coisa que se aproxime de 15 minutos de compute contínuo, pacotes que não caibam em 250 MB unzipped, ou um fan-out que exceda a concorrência da conta e dê throttle. Cada um desses é um job do Glue ou do EMR Serverless com um plano de partições, não uma função.

9.1 Exemplo resolvido E6, o teto de concorrência chega antes do timeout

---

10. Padrões de lakehouse com Spark: partições, AQE, skew, shuffle, arquivos pequenos

10.1 Dynamic partition overwrite

Quando um job reescreve um conjunto de partições em vez de fazer append, você quer os objetos antigos naquelas partições embora e todo o resto intocado. O Spark expressa isso como spark.sql.sources.partitionOverwriteMode=dynamic, definido no Glue através de --conf. Usado com cuidado é uma ferramenta limpa de idempotência: rode o job duas vezes e o output é o mesmo, porque as partições que você gravou foram substituídas em vez de duplicadas.

Dois caveats que valem enunciar: partition overwrite é escopado a partição, então não faz nada por updates em nível de linha (isso é território do MERGE do Iceberg), e a opção de algoritmo de rename que a AWS documenta para caminhos de partição aninhada duplicados (--enable-rename-algorithm-v2) está documentada como disponível somente no AWS Glue versão 1.0: não assuma que ela se aplica a um job moderno do Glue 4.x ou 5.x.

10.2 AQE, skew e shuffle partitions: os três dials do --conf

Os três vivem no --conf, e os três mudam o formato do plano em tempo de execução e não o seu código:

• AQE (adaptive query execution): deixa o Spark replanejar uma vez que os limites de shuffle são conhecidos: coalescindo partições de shuffle super-paralelas, convertendo sort-merge joins em broadcast joins quando as estatísticas permitem, e consertando joins enviesados.
• Shuffle partitions, o grau de paralelismo pós-shuffle. Poucas demais num shuffle grande significa stragglers e spill; muitas demais num job pequeno significa milhares de tarefas minúsculas cujo overhead de scheduling domina o trabalho.
• Skew handling, uma hot key faz uma única tarefa fazer todo o trabalho enquanto 200 ficam ociosas. A escada de correção: mude ou salte a chave, habilite o adaptive skew handling, ou faça repartition para longe da coluna ofensiva. Adicionar workers não ajuda skew de chave única, a mesma tarefa singular ainda é dona da chave.

10.3 Arquivos pequenos: o ciclo de vida da compactação

"Ter milhares de objetos pequenos do Amazon S3 em uma tabela de data lake aumenta o overhead de metadados e afeta o desempenho de leitura."

O Glue Data Catalog traz compactação gerenciada para tabelas Iceberg, que "performa compaction sem interferir em queries concorrentes e suporta compactação apenas para tabelas em formato Parquet." Ela dispara em uma regra, não em um schedule:

• mais de 100 arquivos em uma tabela ou partição, e
• arquivos menores que 75% do tamanho de arquivo alvo, onde o alvo vem de write.target-file-size-bytes (padrão 512 MB, então o threshold de gatilho é 384 MB).

Estratégias: binpack (o padrão do Iceberg: "Combina arquivos pequenos em arquivos maiores, tipicamente mirando tamanhos acima de 100MB"), sort e z-order para pruning multi-dimensional. Dois optimizers irmãos cuidam da housekeeping: snapshot retention e orphan file deletion, com deleteFileThreshold começando em 100 deletes em um arquivo de dados antes de a compactação considerá-lo.

Dois fatos surpreendem as pessoas: a compactação está desabilitada por padrão para tabelas novas, e ela cobra na taxa de DPU do Glue ETL ($0.44 por DPU-hour: compactação é sua própria linha na lista de preços, não uma feature grátis do catálogo).

10.4 Exemplo resolvido E7, o optimizer dispara, e quanto custa?

• 📚 Você sabia? Compactação é um produto, não um script que você mantém: o Data Catalog oferece três table optimizers, Compaction, Snapshot retention e Orphan file deletion, configuráveis em nível de catálogo através do console do Lake Formation ou da API UpdateCatalog, com setup via CLI usando aws glue create-table-optimizer --type compaction. O Athena adiciona OPTIMIZE e VACUUM manuais nas mesmas tabelas (table optimizers do AWS Glue, acesso em out 2026).

---

11. Idempotência: bookmarks versus MERGE versus watermarks

Correção em escala é a mesma pergunta toda vez: se esta execução acontecer duas vezes, a tabela ainda está certa? A resposta nunca é "bookmarks vão cuidar disso."

A checklist que decorre dos fatos desta lição:

1. Dê a todo source e sink um transformation_ctx estável: ele é a chave do estado.
2. Habilite bookmarks explicitamente; disable é o padrão.
3. Nunca troque uma propriedade de fonte enquanto um bookmark está vivo.
4. Pareie bookmarks com uma estratégia idempotente do lado da escrita, dynamic partition overwrite, MERGE do Iceberg, ou um prefixo de staging, porque só as fontes são rastreadas.
5. Para Iceberg, prefira MERGE sobre appends cegos; snapshot isolation dá leitores que nunca veem estado meio-gravado.
6. Para sinks de streaming, lembre-se da janela de manutenção: "AWS Glue will restart the job within 3 hours of the specified maintenance window": projete sinks para at-least-once mais um commit idempotente.

---

12. Esqueleto resolvido de um job Glue PySpark: leitura do catálogo até o Iceberg silver

Tudo até aqui, em um job. Esta é a forma de um build silver no Glue 5.1 ou 6.0: fonte de catálogo com bookmarks ligados, um passo explícito de settle de schema onde a fonte traz choice types do Glue, dedup em uma chave natural, uma quarentena de erros, e uma escrita Iceberg que é segura de repetir.

12.1 O que configurar ao lado do código

12.2 Exemplo resolvido E8: precificando este job

---

13. Aritmética de custo: DPU-hours, vCPU-seconds e o desconto Flex

13.1 A tabela de preços de outubro de 2026

Todas as taxas do Glue abaixo vêm do CSV da oferta do AWS Price List para o AWS Glue (publicação 2026-10-06, vigência 2026-10-01, us-east-1); as taxas do EMR vêm da página de preços do EMR e do mapa de preços do EMR Serverless (acesso em 2026-10).

13.2 Exemplo resolvido E9: três medidores, um job

13.3 O armazenamento do catálogo também é uma conta

O armazenamento do Data Catalog é $1.00 por 100.000 objetos por mês, primeiro 1.000.000 de objetos grátis ($0.00001 cada), mais $1.00 por milhão de requests (primeiro milhão grátis): um lake com **5.000.000** de objetos de tabela e partição custa `(5,000,000 − 1,000,000) ×$0.00001 = $40.00 per month`. Uma coluna de partição de alta cardinalidade que explode a contagem de objetos é, portanto, uma decisão de armazenamento e catálogo tanto quanto de desempenho de query (Lição 07).

---

14. A matriz de decisão

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

---

Casos Reais

Caso A, Transport for NSW: ~80% a menos em integração de dados, e um lead time medido em semanas

Transport for NSW (agência de transporte do governo de NSW, 2M+ passageiros por dia, 25.000+ funcionários). O estudo de caso da AWS descreve um estate legado no qual "CMAI used a third-party Extract, Transform, and Load (ETL) platform… to manage more than 400 ingestion workflows", uma plataforma licenciada que "Over time, this approach introduced two critical risks, cost in ongoing licensing and operating constraints." O time migrou esses workloads de ETL para o AWS Glue, com AWS Step Functions para orquestração e monitoramento, Amazon S3 como fundação do data lake, e Amazon RDS retido para compatibilidade retroativa durante a convergência.

Os resultados relatados, da faixa de benefícios do estudo de caso: "reduction in data integration costs 80%", e "to build and deploy new ingestion jobs, down from several months Less than 3 weeks", com "More team members able to manage data workflows on cloud native tools, removing dependency on legacy platform expertise." O mecanismo é nomeado diretamente: "Because AWS Glue supports Python… the team was also able to distribute expertise across several existing team members", e especialistas da AWS treinaram "over 30 team members."

O ângulo da lição: ETL serverless é tanto uma correção organizacional quanto uma técnica. A economia de ~80% é a manchete, mas as duas vitórias estruturais são as que sobrevivem à fatura: um lead time de menos de 3 semanas substituindo um tempo de fila de vários meses, e a propriedade do pipeline se espalhando para além de um único grupo com habilidade de plataforma. Nos termos desta lição, o TfNSW trocou um medidor de licença por DPU-hours (Seção 13), um scheduler sob medida por triggers e Step Functions (Seção 2), e uma dependência de pessoa-chave por habilidades de Python.

Números relatados pelo cliente em uma página de estudo de caso da AWS (sem data, acesso em 2026-10-11); não é um compromisso da AWS. Mantenha o arredondamento relatado: ~80 por cento, "Less than 3 weeks".

Caso B, Vanguard: 600+ jobs Glue ETL como escala operacional

Vanguard (gestão de ativos). No AWS Big Data Blog de 18 de março de 2026, a modernização de dois anos da Vanguard de um "fragmented 'data swamp' of Parquet files on Amazon Simple Storage Service" para um sistema estruturado publicou os números operacionais dela: "20 TB in data volume in Amazon Redshift and another 150 TB in S3 data lake", "600+ AWS Glue ETL jobs (a 30x increase)", "300+ tables (3x growth)", "250+ Amazon Redshift materialized views" e "500,000+ user queries/months." A camada de lakehouse é explícita: "Vanguard is curating data products on the data lake using Apache Iceberg format and leveraging AWS Glue for metrics computation and data lake integration."

O ângulo da lição: 600+ jobs do Glue é o que "transformação em escala" realmente parece em produção: nessa contagem as preocupações das Seções 2, 4 e 11 deixam de ser teoria: a fila de jobs substitui retries fail-fast no teto de concorrência, valores de transformation_ctx estáveis importam porque ninguém consegue auditar manualmente 600 chaves de estado, MERGE e compactação gerenciada são load-bearing, e uma mudança de $0.44 para $0.308 por DPU-hour é um line item que você sente. Números relatados pelo cliente em um AWS Big Data Blog (publicado em 2026-03-18; acesso em 2026-10-11); não é um compromisso da AWS.

Perguntas de Prática (Practice Questions)