Olha que bacana, agora podemos colocar no data flow um componente que quebra o fluxo de dados em diferentes fluxos de saída (potencialmente com uma distribuição homogênea), permitindo utilizar um maior paralelismo no seu pacote e melhorar o desempenho na carga dos dados.
O post do Len Wyatt já dá uma explicação legal, discutindo possíveis casos de gargalos, então não vou ficar muito na teoria. Para alimentar o espírito geek eu baixei o BDD e fiz um pequeno teste no SSIS.
Cenário: criei um raw file com 30.000 registros e disparei da minha máquina (um dual core) o pacote. Este vai pegar esses registros e fazer 30.000 lookups contra um servidor SQL Server (nada parrudo, uma máquina bbeeemmm simples), inserindo os campos originais mais um campo retornado pelo lookup em uma tabela de destino (deixei como uma heap).
Minha intenção é conseguir paralelizar os lookups e ver o ganho de desempenho, já que o lookup é uma operação cara (ainda mais com a forma padrão que o SSIS trabalha).
Abaixo temos as três figuras, mostrando o BDD trabalhando com um, dois e quatro fluxos de dados.
Figura 01 – Somente um fluxo de dados
Figura 02 – Dois fluxos de dados
Figura 03 – Quatro fluxos de dados
1 fluxo de dados
Tempo 1: Finished, 1:12:38 PM, Elapsed time: 00:01:00.123
Tempo 2: Finished, 1:15:12 PM, Elapsed time: 00:00:53.493
2 fluxo sde dados
Tempo 1: Finished, 1:17:07 PM, Elapsed time: 00:00:38.376
Tempo 2: Finished, 1:18:32 PM, Elapsed time: 00:00:33.650
4 fluxos de dados
Tempo 1: Finished, 1:21:04 PM, Elapsed time: 00:00:24.804
Tempo 2: Finished, 1:22:00 PM, Elapsed time: 00:00:23.962
Com o paralelismo do BDD e quatro fluxos o tempo caiu de quase um minuto para 24 segundos! E isso que as máquinas não são boas ou massivamente paralelas, imagine isso rodando em um servidor feroz.
Outro detalhe interessante do BDD que já dá para perceber pelos testes é a forma que ele trabalha. Ele não vai jogar uma linha para um fluxo, depois outra linha para outro fluxo e assim sucessivamente, o BDD pega o conteúdo do buffer e vai jogando para cada fluxo. Na figura 3 podemos notar que depois de já ter distribuido 28.671 registros, somente sobraram 1.329 para o quarto ramo. Uma implementação bem eficiente que nos dá indício que ainda podemos tirar vantagem de alguns ajustes do tamanho do buffer no pipeline.
Antes desse componente poderíamos tentar algo bem menos efetivo, fazendo um gatinho (mmiiaauuu) com o conditional split. Mas aí você deveria definir como são distribuídos os fluxos e a lógica teria que ser muito eficiente para não haver um desbalanceamento nos ramos… Algo como um campo que tivesse uma distribuição homogênea para os registros e estes intercalados, para garantir a distribuição igualitária durante o processamento dos buffers, senão você teria um ramo sendo usado primeiro, depois outro, etc. (sem um paralelismo efetivo). Isto é, antes do BDD a ideia é factível, mas improvável de ser implementado de forma eficiente.
E não, esse não é um componente que está no Denali, pelo menos eu ainda não vi nada a respeito sobre a inclusão dele e os CTPs não possuem esse componente… Mas bem que poderia ser incluído!
Eu me diverti, e você?
Atualização
{
A dúvida do Rodrigo é muito pertinente! A diferença do BDD para o multicast NÃO está no paralelismo, pois o multicast também pode usufruir de múltiplas thread, mas normalmente com os ramos fazendo operações diferentes entre si ou populando destinos diferentes.
Supondo que no multicast você têm 12 regsitros no pipeline, os mesmo 12 registros vão fluir em cada ramo. Então supondo 4 ramos, se você inserisse tudo na mesma tabela iria acabar com 48 registros, cada um aparecendo 4 vezes.
Com o BDD os 12 registros que entram no pipeline serão distribuídos entre os ramos, deixando 3 registros para cada ramo (exemplo hipotético, já que no fundo a divisão é feita pela quantidade de registros que cabe em um buffer do pipeline). Se inseridos em uma única tabela, como foi o meu exemplo, você teria os 12 registros sem duplicatas.
Espero ter sido claro, qualquer coisa grita!
}
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
http://www.srnimbus.com.br/
