Azure Data Factory: como otimizar múltiplas cópias

Neste tutorial apresentarei como otimizar e aprimorar o processo de realizar múltiplas cópias ao mesmo tempo no Azure Data Factory. Então caso você possua uma situação como esta:

Apesar de funcional, o cenário acima dificulta a manutenção e cria múltiplas entidades dentro do ambiente.

Por que isso é um problema?

Existe um máximo de 40 atividades dentro de uma pipeline, embora exista um limite padrão de 5000 entidades (pipelines, datasets, triggers, etc) dentro do ADF. O arquivo json que o descreve, o ARM template, possui um limite descritivo de 800 entidades em seu deploy padrão.

Apresentado o porquê disso ser um problema vamos à otimização.

1. Usando um vetor de entrada:

Vamos parametrizar a nossa pipeline criando um array.  Cada posição do nosso parâmetro conterá toda a informação que nós precisamos. Você pode usar qualquer carácter como separador de informação. Eu gosto de usar espaços.

O default value pode ser [“<caminho-do-arquivo1> <nome-do-arquivo1> <tabela-de-destino1>” , “<caminho-do-arquivo2> <nome-do-arquivo2> <tabela-de-destino2>”,“<camin…]

Nesta cópia hipotética estamos no cenário de copiar dados de um arquivo parquet para uma tabela SQL.
Agora nos settings/configurações do ForEach usaremos o array que criamos como entrada.

Nesta etapa nós estamos informando ao ForEach quem será o vetor de entrada. É importante notar aqui que esta atividade somente trabalha com um vetor de entrada de cada vez. Por esse motivo, não podemos separar as informações com as quais trabalharemos em múltiplos vetores. Essa abordagem até é possível mas acaba por adicionar mais uma camada de complexibilidade desnecessária.

Seguindo com o nosso desenvolvimento, ao criar o nosso dataset de source/sink nós iremos parametrizá-los para que possa receber os valores do vetor.

Da mesma forma o contêiner também pode ser parametrizado, se necessário para o seu caso. Os parâmetros que criamos aparecerão nas propriedades de dataset na source/sink

O próximo passo é desmembrar a posição do vetor que o ForEach está recebendo nas informações que precisamos. Para isso, usaremos a função split utilizando o espaço como separador e o retorno desta função é um vetor que pode ser referenciado pela posição. No caso desse exemplo, a posição zero é o <caminho-do-arquivo>, a posição um é <nome-do-arquivo>, e a posição três é <tabela-de-destino>

O resultado para a source fica desta forma para o sink

E está pronto! Quando a pipeline for executada ela abrirá cada posição de vetor usando o split e processará todas as cópias paralelamente.

2. Usando uma tabela de entrada:

Você poderá usar uma tabela que guarde todas informações, caso você tenha acesso a um banco de dados. A vantagem deste método em relação ao anterior é que caso a sua pipeline de cópia seja chamada por uma pipeline pai, esta deverá necessariamente fornecer um parâmetro para a pipeline filha. Uma chamada usando uma tabela ou mesmo um arquivo como referência elimina essa necessidade e torna a manutenção mais fácil.

Para começar, vamos buscar as informações necessárias usando a atividade de LookUp nas configurações será um dataset de SQL e na caixa de query buscaremos pelos nossos dados

Uma sugestão de tabela:

CREATE TABLE schema.Table (

pipeline_name [varchar](63), → tamanho máximo de nome de pipeline na Azure

path [varchar](MAX), → caminho do arquivo

file [varchar](MAX), → nome do arquivo

table [varchar](MAX), → nome da tabela de destino

active bit → se a cópia está ativa ou não

)

Query:

SELECT * FROM schema.Table
Where pipeline = &#39;pipeline_name&#39;
AND active = 1

Nas configurações do ForEach vamos usar a saída do LookUp

A source será parametrizada de acordo com as colunas da tabela.

O mesmo vale para o sink

O que finaliza nossa pipeline.

Como pudemos ver é um processo até simples, mas que irá lhe poupar de ter que fazer inúmeras cópias individuais pois, para adicionar novas cópias, basta adicioná-las na tabela. Além disso, não há a necessidade de remoção, basta alterar o valor de active para 0. Sendo assim, fica apenas uma última ressalva: esses métodos funcionam muito bem quando o schema é trazido pela própria cópia, quando a origem é um arquivo parquet ou uma tabela em SQL.

Entretanto, para casos onde o schema é desconhecido e precisa ser mapeado será assunto de outro artigo.