Um job DataStage que falhou ou está lento parece opaco até você saber onde olhar. O log do Director tem a resposta, mas só se você o ler na ordem certa — e o assassino de performance mais comum, o skew de particionamento, nunca aparece como erro. Veja como engenheiros de ETL experientes depuram isso.
Comece onde está a verdade: o log do Director
Toda falha de job DataStage tem uma história no log do Director. Leia de cima para baixo e resista a corrigir a última linha vermelha primeiro — a primeira entrada fatal costuma ser a causa raiz; o resto é consequência.
- Fatal — o que de fato parou o job. Comece aqui.
- Warning — muitas vezes inofensivo (coerção de tipo, nulos), mas uma enxurrada deles esconde o que importa. Suprima os warnings sabidamente seguros para os reais se destacarem.
- Info — contagem de linhas e tempos por stage, seu mapa de gargalos.
Ache o stage lento
Num job paralelo, o stage mais lento limita o pipeline inteiro. As linhas/segundo por stage no log (ou no monitor de análise de performance) mostram onde o tempo vai. Culpados comuns:
- Um stage de banco fazendo linha a linha — garanta que array size / opções de bulk estejam configuradas, não inserts de uma linha.
- Um Sort ou Aggregator derramando em scratch disk — aumente a memória do stage ou reduza os dados antes no fluxo.
- Um Transformer com funções pesadas por linha — empurre a lógica para o SQL de origem quando possível.
Skew de particionamento: o assassino do job paralelo
O paralelismo do DataStage só ajuda se as linhas se espalharem uniformemente entre as partições. Faça hash em uma chave de baixa cardinalidade e um nó recebe a maior parte dos dados enquanto os outros ficam ociosos — o job roda à velocidade de um nó apesar dos N nós. As correções têm o mesmo instinto de uma chave de distribuição de banco:
- Faça hash-partition em uma chave de alta cardinalidade.
- Mantenha o particionamento consistente entre stages que fazem join/agregação, para evitar reparticionamento + re-sort silenciosos.
- Use Round Robin só onde ordem e agrupamento não importam.
Não deixe os rejects sumirem
-- Ligue um reject link nos stages de banco e transformer,
-- grave os rejects em uma tabela/arquivo com o código de erro e
-- falhe o job (ou alerte) se a contagem de rejects cruzar um limite.Um job que "tem sucesso" enquanto descarta silenciosamente 5% das linhas para um reject link não monitorado é pior que um que falha com barulho. Sempre capture os rejects e conte-os.
O banco por baixo do ETL
Metade dos chamados de "job DataStage lento" é, na verdade, um banco de origem ou destino lento — um índice faltando na tabela de lookup, uma tabela de destino inchada e sem vacuum. Quando o data warehouse é PostgreSQL, o PG Monitoring mostra a consulta exata que o stage de ETL está rodando, seu plano e se ela regrediu — transformando "o job está lento" em "este lookup perdeu o índice na última terça".