Otimização de pipelines ETL no Databricks

Problema

Pipelines ETL críticos apresentavam runtimes excessivos — chegando a quase 17 minutos por execução —, ampliando o consumo de DBU, estourando janelas de processamento e impedindo o SLA de entrega de dados.

Arquitetura

flowchart TB
  subgraph Antes
    A1[Full scan em toda a tabela] --> A2[Joins com shuffle]
    A2 --> A3[Small files acumulados]
    A3 --> A4[Runtime de ate 17 minutos]
  end
  subgraph Depois
    B1[Leitura incremental] --> B2[BroadcastJoin]
    B2 --> B3[CLUSTER BY + OPTIMIZE]
    B3 --> B4[Runtime de menos de 1 min a 4 min]
  end
  A4 -.otimizacao.-> B1
  classDef bad fill:#1a1018,stroke:#ef4444,color:#e2e8f0
  classDef good fill:#0d1525,stroke:#10b981,color:#e2e8f0
  class A1,A2,A3,A4 bad
  class B1,B2,B3,B4 good

Solução

• BroadcastJoin: broadcasts de tabelas pequenas eliminaram shuffles desnecessários em joins.
• CLUSTER BY: reorganização física dos dados para maximizar o data skipping em leituras futuras.
• OPTIMIZE: compactação de small files que degradavam a performance de leitura e escrita.
• Leitura incremental: substituição de full scans por leitura apenas das linhas novas, reduzindo o volume processado a cada execução.

Resultados

• fato_notafiscal: 20 min → 4 min (-80%)
• fato_ordemvenda: 5m 46s → menos de 1 min (-83%)
• fato_remessa: 9m 31s → menos de 1 min (-90%)
• notafiscalremessa: 4m 55s → menos de 1 min (-80%)
• fato_financeiroareceber: 10m 2s → menos de 1 min (-90%)
• fato_partidascontabeis: 16m 59s → menos de 1 min (-94%)

Stack