Azure Data Factory: guia de pipelines de dados

Alguém precisa mover o dado, no horário certo, sem susto#

Toda empresa que investe em analytics esbarra no mesmo problema antes de qualquer dashboard bonito ficar de pé: o dado está espalhado em bancos SQL locais, ERPs, APIs de terceiros, arquivos em blob storage e planilhas que alguém atualiza na mão. Ele precisa sair de todos esses lugares, chegar limpo em um destino confiável e fazer isso todo dia, no horário combinado, sem depender de ninguém rodando script manualmente às sete da manhã. O Azure Data Factory é o serviço da Microsoft criado exatamente para resolver esse buraco. Ele é a plataforma de integração e orquestração de dados do Azure, o mecanismo que puxa, move, transforma e agenda a movimentação de dados entre origens e destinos na nuvem e no ambiente local.

Neste guia eu vou direto ao que importa para quem vai colocar a mão na massa: o pipeline como unidade de orquestração, a atividade Copy que resolve a maior parte da ingestão, os mapping data flows para transformar sem escrever código, os integration runtimes que decidem onde a execução acontece, o agendamento por gatilho e, no fim, a pergunta que mais gera decisão errada em 2026: quando faz sentido continuar no Azure Data Factory e quando é hora de olhar para o Data Factory dentro do Microsoft Fabric. Vou ser honesto onde a ferramenta cobra o seu preço.

O pipeline é a unidade de orquestração, não de transformação#

O conceito central do Azure Data Factory é o pipeline. Um pipeline é um agrupamento lógico de atividades que executam uma tarefa em conjunto. Ele não guarda dado nenhum. O que ele faz é definir a sequência: o que roda primeiro, o que roda depois, o que acontece em paralelo, o que fazer quando uma atividade falha e o que fazer quando ela dá certo. É orquestração pura.

Dentro de um pipeline você combina três famílias de atividades:

• Atividades de movimentação de dados, sendo a Copy a principal delas.
• Atividades de transformação, como os mapping data flows, notebooks, procedures e chamadas a serviços externos.
• Atividades de controle de fluxo, como condicionais, loops ForEach, execução de outros pipelines, esperas e tratamento de falha.

O erro mais comum de quem começa é tentar fazer o pipeline transformar o dado por conta própria. O pipeline orquestra e move. Quando o assunto é reformatar, limpar e reprocessar coluna a coluna, o trabalho pertence a outra peça, o mapping data flow, que eu detalho mais adiante. Manter essa fronteira clara é o que separa um projeto de engenharia de dados sustentável de um emaranhado que ninguém consegue manter seis meses depois.

A atividade Copy resolve a maior parte da ingestão#

Se eu tivesse que apontar uma única atividade responsável pela maior parte do valor entregue no dia a dia, seria a Copy. Ela copia dados de uma origem para um destino, ponto. O que a torna poderosa é a largura do catálogo: o Azure Data Factory conta com dezenas de conectores nativos, cobrindo bancos relacionais como SQL Server, Oracle, PostgreSQL e MySQL, data warehouses, armazenamentos de arquivo como Blob Storage e Data Lake Storage, aplicações SaaS e APIs REST genéricas.

Na Copy você configura basicamente quatro coisas: a origem (source), o destino (sink), o mapeamento de colunas entre os dois e as configurações de desempenho, como paralelismo e tamanho de lote. Para cenários incrementais, você combina a Copy com parâmetros e uma consulta que filtra apenas o que mudou desde a última carga, evitando reprocessar a tabela inteira toda madrugada.

Um ponto honesto sobre a Copy: ela é excelente para mover, mas propositalmente limitada para transformar. Faz conversões simples de tipo e mapeamento de coluna, e só. Se você precisa juntar duas fontes, aplicar regra de negócio, agregar ou desduplicar, não force a Copy a isso. Esse é o sinal de que você precisa de um data flow.

Mapping data flows transformam sem escrever código#

Os mapping data flows são a resposta do Azure Data Factory para transformação em escala sem código. Você desenha visualmente um fluxo de transformação, arrastando componentes que fazem join, agregação, derivação de colunas, ordenação, pivot, união e limpeza. Por baixo do capô, o serviço traduz esse desenho para execução em clusters Spark gerenciados, que o próprio Azure Data Factory provisiona e desliga sozinho. Você não administra o Spark, você desenha a lógica.

Isso importa por um motivo prático: transformação distribuída normalmente exige conhecimento de Spark, particionamento e otimização de cluster. Os mapping data flows entregam esse poder para times que dominam a lógica de negócio mas não querem escrever PySpark. A contrapartida honesta é o custo. Como cada execução de data flow provisiona um cluster, ela cobra por tempo de computação, e um fluxo mal desenhado, com joins pesados sem particionamento adequado, pode ficar caro. Data flow não é para tudo. Para movimentação simples, a Copy é mais barata e mais rápida. Reserve o mapping data flow para quando a transformação realmente justifica o cluster.

Vale distinguir os dois principais recursos de fluxo dentro da ferramenta:

Recurso	Para que serve	Executa em	Quando usar
Atividade Copy	Mover dado de A para B	Integration runtime	Ingestão, cargas full e incrementais, mínima transformação
Mapping data flow	Transformar em escala sem código	Cluster Spark gerenciado	Joins, agregações, regras de negócio, limpeza pesada

Integration runtimes decidem onde a execução acontece#

Este é o conceito que mais confunde quem chega ao Azure Data Factory e, ao mesmo tempo, o mais importante de entender. O integration runtime, ou IR, é a infraestrutura de computação que o serviço usa para efetivamente executar as atividades. Escolher o IR errado gera lentidão, custo desnecessário ou, no pior caso, a impossibilidade de conectar em uma fonte de dados. Existem três tipos.

Integration runtime	Onde roda	Caso de uso típico
Azure IR	Infraestrutura gerenciada na nuvem Azure	Origens e destinos acessíveis pela internet ou em rede Azure; execução de mapping data flows
Self-hosted IR	Máquina que você instala na sua rede	Bancos e arquivos on-premises ou atrás de firewall corporativo
Azure-SSIS IR	Ambiente gerenciado no Azure	Executar pacotes SSIS existentes na nuvem, sem reescrever

O Azure IR é o padrão. Ele é totalmente gerenciado, escala sozinho e serve para conectar em fontes acessíveis pela nuvem e para rodar os mapping data flows. Não há nada para instalar.

O self-hosted IR é a peça que resolve o problema clássico do dado que mora dentro de casa. Você instala um agente em uma máquina dentro da sua rede local, e é esse agente que faz a ponte segura entre o Azure Data Factory na nuvem e o seu SQL Server local, o compartilhamento de arquivos interno ou o sistema atrás do firewall. O dado sai da sua rede pela conexão que você controla, sem abrir o banco para a internet. Em praticamente todo projeto híbrido brasileiro que envolve sistemas legados on-premises, o self-hosted IR aparece.

O Azure-SSIS IR atende quem tem um passado de investimento em SQL Server Integration Services. Ele permite executar pacotes SSIS existentes dentro do Azure, em um ambiente gerenciado, sem reescrever tudo do zero. É uma ponte de migração, não um destino final. Se você está começando um projeto novo, não comece por SSIS.

Agendamento e gatilhos tiram a mão do processo#

Um pipeline que só roda quando alguém clica em executar não resolve o problema de negócio. O valor aparece quando ele roda sozinho, no horário certo. O Azure Data Factory faz isso com triggers, os gatilhos que disparam a execução. Há três modelos principais:

• Gatilho de agendamento (schedule): dispara em horários definidos, como toda madrugada às 3h ou a cada hora útil. É o mais usado.
• Gatilho de janela em cascata (tumbling window): dispara em intervalos fixos e sequenciais, guardando estado de cada janela. Serve bem para cargas incrementais que não podem pular nem sobrepor períodos.
• Gatilho por evento (event-based): dispara quando algo acontece, tipicamente a chegada ou remoção de um arquivo em um storage. Serve para ingestão orientada a evento, quando o dado não tem hora fixa para chegar.

O gatilho por evento é o que costuma surpreender positivamente o cliente. Em vez de agendar uma verificação de hora em hora torcendo para o arquivo já estar lá, o pipeline reage no instante em que o arquivo aparece no blob. Menos espera, menos execução vazia, menos custo.

O Azure Data Factory e o Data Factory do Fabric são parentes, e isso muda a decisão#

Aqui está a parte que exige honestidade, porque é onde muita empresa toma a decisão errada em 2026. O Data Factory do Microsoft Fabric traz a mesma família de recursos do Azure Data Factory, pipelines de orquestração, atividade Copy e transformação visual, só que dentro da plataforma unificada do Fabric, gravando naturalmente no OneLake e conversando nativamente com Lakehouse, Warehouse e os modelos semânticos do Power BI. Não é um produto do zero: é a mesma linhagem de orquestração levada para dentro do ecossistema SaaS do Fabric. Se você quer entender a plataforma inteira antes de decidir, vale ler o nosso guia sobre o que é o Microsoft Fabric e se vale a pena em 2026.

A pergunta prática não é qual é melhor no abstrato, e sim qual encaixa no seu contexto. Uma comparação direta ajuda:

Critério	Azure Data Factory	Data Factory do Fabric
Modelo	Serviço PaaS independente no Azure	Workload dentro da plataforma Fabric (SaaS)
Faturamento	Cobrança própria por execução e por IR no Azure	Consome a capacidade (capacity) do Fabric
Destino natural	Qualquer storage ou banco Azure e on-premises	OneLake, Lakehouse e Warehouse do Fabric
SSIS	Suporta Azure-SSIS IR para pacotes legados	Sem suporte a pacotes SSIS
Integração com Power BI	Indireta, via storage e modelos externos	Nativa, no mesmo workspace
Melhor cenário	Integração ampla no Azure, cenários híbridos, migração de SSIS	Empresa que já vive no Fabric e centraliza tudo no OneLake

Minha recomendação de consultor, sem enrolar: se a sua empresa já apostou no Microsoft Fabric e quer centralizar armazenamento e BI no OneLake, use o Data Factory do Fabric e evite manter dois mundos de orquestração. Se o seu cenário é de integração ampla no Azure, com muitas fontes on-premises, dependência de self-hosted IR, necessidade de rodar pacotes SSIS existentes ou uma arquitetura que não é toda Fabric, o Azure Data Factory continua sendo a escolha certa e madura. Os dois convivem: não é raro ver o Azure Data Factory fazendo a ingestão pesada e híbrida enquanto o Fabric cuida da camada analítica e do Power BI. Se você quer ver como conectamos essas peças em projetos reais, vale conhecer as nossas soluções de dados e analytics.

Perguntas frequentes#

O Azure Data Factory transforma dados ou só move?

Ele faz as duas coisas, mas com ferramentas diferentes. A atividade Copy move e faz mapeamento e conversão simples de tipo. Para transformação de verdade, com joins, agregações e regras de negócio, você usa os mapping data flows, que rodam em Spark gerenciado sem exigir código. Não tente forçar a Copy a transformar; use a peça certa para cada trabalho.

Preciso saber programar para usar o Azure Data Factory?

Não para a maior parte do trabalho. Pipelines, atividade Copy e mapping data flows são construídos em interface visual, arrastando componentes. Programação entra quando você quer expressões dinâmicas mais avançadas, chamadas a APIs específicas ou integração com notebooks. Um analista técnico com boa lógica constrói pipelines úteis sem escrever Spark.

Como conecto o Azure Data Factory a um banco de dados na minha rede local?

Com o self-hosted integration runtime. Você instala um agente em uma máquina dentro da sua rede, e esse agente faz a ponte segura entre o serviço na nuvem e o banco local, sem expor o banco para a internet. É o padrão para cenários híbridos com sistemas legados on-premises, muito comuns no Brasil.

Qual a diferença entre os integration runtimes?

O Azure IR é gerenciado na nuvem e serve para fontes acessíveis pela internet ou rede Azure e para rodar data flows. O self-hosted IR roda em uma máquina sua e conecta fontes on-premises ou atrás de firewall. O Azure-SSIS IR executa pacotes SSIS existentes dentro do Azure. Escolher o IR certo é o que garante conectividade e desempenho.

Devo escolher o Azure Data Factory ou o Data Factory do Fabric?

Depende de onde a sua empresa vive. Se você já está no Microsoft Fabric e centraliza dados e BI no OneLake, use o Data Factory do Fabric. Se o cenário é integração ampla no Azure, com muitas fontes on-premises, pacotes SSIS legados ou arquitetura que não é toda Fabric, o Azure Data Factory é a escolha mais adequada. Os dois podem coexistir no mesmo projeto.

Como o custo do Azure Data Factory funciona?

Ele cobra principalmente por execução de atividades, por movimentação de dados e pelo tempo de computação dos data flows, além do custo do integration runtime. Movimentação simples com a Copy é barata. Mapping data flows provisionam clusters Spark e custam por tempo de execução, então fluxos mal desenhados pesam na fatura. Usar data flow só quando necessário mantém o custo sob controle.

Conclusão#

O Azure Data Factory continua sendo uma das peças mais sólidas do Azure para integração e orquestração de dados: pipelines que organizam a execução, a atividade Copy que resolve a maior parte da ingestão, mapping data flows que transformam sem código, integration runtimes que cobrem nuvem e ambiente local, e gatilhos que tiram a mão do processo. A decisão entre ele e o Data Factory do Fabric não é sobre qual é mais novo, e sim sobre onde a sua arquitetura de dados vai morar. Escolher errado custa retrabalho e fatura inflada. Se você quer definir a arquitetura de ingestão certa para o seu contexto, sem apostar na moda da vez, fale com a gente.