Data Skew: problema de desequilíbrio na distribuição dos dados

📊 O que é Data Skew?

Data Skew é um problema de desequilíbrio na distribuição dos dados — mas o termo tem significados distintos dependendo do contexto:

➡️ Engenharia de Dados: Dados não estão distribuídos de forma uniforme entre partições ou nós em motores distribuídos (Spark, Flink, etc.). Isso gera gargalos, lentidão, falhas de tarefas e uso ineficiente de recursos.

➡️ Ciência de Dados: Refere-se ao viés estatístico das variáveis: classes desbalanceadas (fraude, eventos raros), presença de outliers ou amostras enviesadas. Isso pode distorcer padrões e prejudicar a generalização dos modelos.

⚙️ Técnicas na Engenharia de Dados

• Salting Keys → quebra concentração de chaves dominantes.

• Bucketing → pré-agrupamento fixo, reduz shuffle em joins recorrentes.

• Repartitioning → redistribui dados em partições extras (simples, mas gera overhead).

• Algoritmos customizados → tratar manualmente cargas pesadas (heavy hitters).

🤖 Técnicas na Ciência de Dados

• Oversampling/Undersampling → equilibrar classes.

• Modelos especializados → One-Class SVM, Anomaly Detection para eventos raros.

• Feature engineering + métricas adequadas → usar F1-score, AUC em vez de só acurácia.

• Quando não agir → em alguns casos o desequilíbrio é natural e deve apenas ser considerado na avaliação.

⚖️ Trade-offs Importantes

• Engenharia de dados → mais partições = mais tarefas, rede e disco.

• Ciência de dados → balanceamento artificial pode gerar overfitting ou viés.

👉 A escolha da técnica depende do objetivo: no mundo distribuído, priorizar eficiência e throughput. Na modelagem, priorizar generalização e evitar viés.

🔶 Caso 1 – Engenharia de Dados (Spark)

Contexto: Uma empresa de e-commerce processava milhões de registros de cliques dos usuários diariamente no Apache Spark. O join entre a tabela de logs (bilhões de linhas) e a tabela de usuários estava lento e muitas tasks falhavam.

Problema: 40% dos registros tinham a mesma chave de usuário (visitantes anônimos agrupados como user_id = null). Isso gerava skew em uma única partição, sobrecarregando executores específicos.

Solução:

• Aplicaram Salting Keys, adicionando um valor aleatório na chave null.

• Redistribuíram os dados com repartitioning para evitar sobrecarga em uma partição única.

Resultado: Redução de 70% no tempo total de execução dos jobs e eliminação das falhas recorrentes.

🔷 Caso 2 – Ciência de Dados (Fraude em Cartão de Crédito)

Contexto: Um time de análise de risco queria treinar um modelo para detectar transações fraudulentas em cartões de crédito.

Problema: No dataset, apenas 0,3% das transações eram fraudulentas. O modelo treinado sem tratamento aprendeu a prever sempre “não fraude” — alcançando 99,7% de acurácia, mas sem detectar os casos críticos.

Solução:

• Usaram oversampling da classe minoritária (SMOTE).

• Alteraram a métrica de avaliação de acurácia para F1-score e AUC.

• Implementaram algoritmos de Anomaly Detection para complementar a detecção.

Resultado: O modelo passou a identificar mais de 80% das fraudes reais, mesmo mantendo um número aceitável de falsos positivos.