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

Índice

Técnicas na Engenharia de Dados
Técnicas na Ciência de Dados
Caso 1 – Engenharia de Dados (Spark)
Caso 2 – Ciência de Dados (Fraude em Cartão de Crédito)

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.