Pedaço¶

Introdução¶

O recurso "fragmentação de dados" multiuso do Jitterbit divide os dados de origem em vários pedaços com base no tamanho do pedaço configurado. A configuração de tamanho do bloco usada é o número de registros de origem (nós) por bloco. A transformação é então executada em cada pedaço separadamente, com cada pedaço de origem produzindo um pedaço de destino. Os pedaços de destino resultantes se combinam para produzir o destino final.

Observe que as fontes LDAP não podem ser fragmentadas e a fragmentação de dados não pode ser usada, a menos que os registros sejam independentes.

Vantagens do Chunking¶

Limitações da API¶

Muitas APIs de serviços da Web (SOAP/REST) têm limitações de tamanho. Por exemplo, um Salesforce.com O Upsert aceita apenas 200 registros por chamada. Nesse caso, você configuraria uma operação para usar um tamanho de bloco de 200. A origem será dividida em blocos de 200 registros e cada transformação chamará o serviço Web uma vez com os 200 registros. Isto é repetido até que todos os registros tenham sido processados. (Observe que o Salesforce tem um Bulk Upsert, que o Jitterbit suporta com seu Assistente de processo em massa, para evitar o uso de fragmentação de dados.)

No caso de uma operação de gravação em um arquivo de destino usando fragmentação de dados, os arquivos de destino resultantes são combinados em um único arquivo.

Processamento Paralelo¶

Se você tiver uma fonte grande e um computador com várias CPUs, o fragmentação de dados poderá ser usado para dividir a fonte para processamento paralelo. Como cada pedaço é processado isoladamente, você pode usar esta opção para processar vários pedaços em paralelo. Isso só se aplica se os registros de origem não dependerem uns dos outros no nível do nó do bloco. Os serviços da Web podem ser chamados em paralelo usando fragmentação de dados, melhorando o desempenho. No entanto, há considerações, conforme descrito abaixo em Considerações ao Chunking.

Limitar o Uso de Memória¶

Nos casos em que a transformação de streaming/ lote não pode ser usada, você pode usar a fragmentação de dados para fazer com que a transformação use menos memória. Para obter mais informações sobre streaming e transformação em lote, consulte Transformações de fluxo e lote. A transformação de streaming/ lote é preferida quando o único problema é o uso de memória. Nesse caso, use o maior tamanho possível de bloco, certificando-se de que os dados de cada bloco caibam bem na RAM disponível.

Considerações ao Fragmentar¶

Como o fragmentação de dados pode invocar multithreading (se configurado para usar mais de um thread), seu uso pode afetar o comportamento de variáveis que não são compartilhadas entre os threads.

As variáveis globais e do projeto são segregadas entre as instâncias de fragmentação de dados e, embora os dados sejam combinados, as alterações nessas variáveis não o são. Somente as alterações feitas no thread inicial são preservadas no final da transformação.

Por exemplo: se uma operação—com fragmentação de dados e múltiplos threads—tem uma transformação que altera uma variável global, o valor da variável global após o término da operação será aquele do primeiro thread. Quaisquer alterações na variável em outros threads são independentes e são descartadas quando a operação é concluída.

Essas variáveis globais são passadas para os outros threads por valor e não por referência, garantindo que quaisquer alterações nas variáveis não sejam refletidas em outros threads ou operações. Isto é semelhante ao RunOperation() função quando em modo assíncrono.

Habilitar Fragmentação¶

Como a fragmentação de dados é configurada para uma operação inteira, você pode usar a mesma transformação em modo fragmentado ou não fragmentado, dependendo da operação em que ela é usada.

Para ativar a fragmentação de dados:

• Crie uma operação e atribua uma transformação a ela.

• Clique com o botão direito na operação e selecione Opções…

• Marque a caixa de seleção Ativar Chunking e insira o tamanho do bloco.

• O tamanho do bloco depende do seu caso de uso, conforme descrito acima em Vantagens do Chunking.

• Insira o Número de registros por arquivo. 0 significa que todos os registros estarão em um arquivo.

• Insira um valor maior que 1 no campo Número máximo de threads para ativar o processamento paralelo. (Veja acima Considerações ao Chunking para saber as consequências do uso de thread obrigatório.)

• Origem e Destino pedaço nó:

  • Para origens (e destinos) simples, você não precisa especificar um nó de bloco; será exibido como "-flat-".

  • Para fontes hierárquicas, você precisa especificar um Nó de bloco de origem.

  • Para destinos hierárquicos, você precisa especificar um Nó de bloco de destino.

  • Clique no botão Selecionar… para procurar um nó de bloco adequado. O nó do bloco é o registro repetido (ou nó de loop) no qual você deseja basear o tamanho do bloco.

  • Se você não especificar nada, o padrão é usar o nó de repetição mais alto.

Opções Avançadas¶

• Se o destino for um banco de dados, os dados do destino serão primeiro gravados em vários arquivos (um por bloco). Esses arquivos serão então combinados em um arquivo de destino que será enviado ao banco de dados para inserção/atualização.

• Se você definir o elemento de dados global jitterbit.target.db.commit_chunks para 1 (ou true), cada pedaço será confirmado no banco de dados assim que estiver disponível. Isso pode melhorar significativamente o desempenho se o processamento paralelo estiver ativado, pois as inserções/atualizações do banco de dados serão executadas em paralelo.