Auto Partitioning no Copy job do Fabric Data Factory: mova tabelas gigantes em minutos, sem configurar partição

Resumo em uma linha: o Copy job do Fabric Data Factory agora particiona tabelas grandes automaticamente — escolhe a coluna, calcula as fronteiras e roda leituras em paralelo, tudo a partir de um único toggle em Advanced settings.

O gargalo que todo mundo já sentiu

Se você já montou uma ingestão de um banco relacional grande para o lakehouse, conhece a cena: a carga inicial de uma tabela de transações com centenas de milhões de linhas trava a janela de processamento por horas. O motivo é simples — por padrão, uma cópia lê a origem em uma única thread. Uma leitura sequencial de 500 milhões de linhas é lenta por natureza, não importa o quão robusto seja o destino.

A solução tradicional era particionar manualmente: escolher uma coluna com boa distribuição (um id ou uma data), calcular faixas de valores que dividissem a tabela em pedaços equilibrados e configurar quantas leituras paralelas rodar. Funciona, mas tem três problemas. Primeiro, dá trabalho e precisa ser refeito para cada tabela. Segundo, é fácil errar — uma coluna com distribuição enviesada gera partições desbalanceadas, e aí uma thread carrega 80% dos dados enquanto as outras ficam ociosas. Terceiro, quando o volume muda, a configuração que era boa vira gargalo de novo.

O que mudou: Auto Partitioning (Preview)

O Auto Partitioning no Copy job do Fabric Data Factory transfere esse trabalho para a própria plataforma. Em vez de você definir a estratégia de particionamento, a engine faz isso sozinha:

1. Analisa o schema e as características do dado na origem.
2. Seleciona a coluna de particionamento adequada.
3. Calcula fronteiras (boundaries) balanceadas entre as partições.
4. Executa múltiplas leituras concorrentes — sem nenhum input seu.

Particionar significa quebrar um conjunto grande em pedaços menores que podem ser lidos e gravados ao mesmo tempo. É essa concorrência que muda o patamar de throughput: a diferença entre uma leitura single-thread e uma leitura paralela particionada é, literalmente, a diferença entre horas e minutos.

Estratégia adaptativa: escala com o dado

O ponto mais elegante é que a estratégia se adapta ao tamanho da tabela. Tabelas maiores recebem mais partições; tabelas pequenas seguem sem o overhead de particionamento. Seja uma tabela de lookup de 100 linhas ou um log de transações de 500 milhões, o Copy job aplica a estratégia certa automaticamente. Você não precisa decidir a partir de que tamanho "vale a pena" particionar — a engine decide.

Como ativar (é um toggle)

Na prática, a configuração é mínima. No seu Copy job, em Advanced settings, você liga o toggle de Auto-partitioning. É isso.

Em termos conceituais, a definição do job fica assim:

// Copy job → Advanced settings
{
  "source": "AzureSqlDatabase",
  "table": "dbo.transactions",   // ~500M linhas
  "copyMode": "incremental",
  "watermark": "modified_at",
  "autoPartition": true          // ← o truque todo
}
// A engine escolhe a coluna e as fronteiras,
// e roda N leituras em paralelo. Sem tuning.

Repare que o Auto Partitioning é compatível com carga incremental por watermark — ou seja, funciona tanto na cópia inicial completa quanto nas cargas incrementais subsequentes. Você combina o benefício do particionamento paralelo com a lógica incremental que já usa para não reprocessar a tabela inteira todo dia.

Onde funciona

No momento (Preview), o Auto Partitioning é suportado para cenários de carga por watermark (full inicial + incremental) nos principais conectores relacionais:

• Azure SQL Database
• SQL Server / Azure SQL Managed Instance
• Amazon RDS for SQL Server
• Azure Synapse Analytics
• Oracle
• SAP HANA
• Fabric Data Warehouse
• Tabelas do Fabric Lakehouse

Por ser Preview, vale validar em ambiente de desenvolvimento antes de levar para produção e acompanhar os limites de cada conector na documentação oficial.

O que isso muda no seu dia a dia

Três ganhos concretos para o engenheiro de dados:

1. Menos tuning manual. Você deixa de escolher coluna de partição, calcular faixas e ajustar grau de paralelismo. Esse trabalho — repetitivo e sujeito a erro — some.

2. Janelas de carga menores. Tabelas que travavam a madrugada passam a caber em minutos. Isso libera espaço para mais dependências no pipeline ou para SLAs mais agressivos.

3. Configuração que não envelhece. Como a estratégia é adaptativa, ela acompanha o crescimento da tabela sem exigir revisão. O job que você configura hoje continua fazendo a coisa certa quando o volume dobrar.

Depois de quase duas décadas construindo pipelines de dados, aprendi a desconfiar de recursos que prometem "mágica". Mas particionamento adaptativo automático não é mágica — é a plataforma finalmente assumindo um trabalho pesado que nunca deveria ter sido manual. O tempo que você economiza em tuning é tempo que volta para modelagem, qualidade e governança, que é onde a engenharia de dados realmente entrega valor.

Próximos passos

Se você usa Copy job para trazer dados de bancos relacionais para o Fabric, o teste é barato: ligue o toggle em uma tabela grande de desenvolvimento e compare o tempo de execução com e sem Auto Partitioning. O ganho tende a ser mais expressivo justamente nas tabelas que mais doem hoje.