Os programadores devem usar o SSIS e, em caso afirmativo, por quê? [fechadas]


94

Como desenvolvedor .NET, por quais motivos devo preferir pacotes SSIS em vez de escrever código? Temos uma tonelada de pacotes em produção onde trabalho atualmente, e eles são um pesadelo para "escrever" (talvez desenhar?) E manter. Cada pacote parece uma tigela de espaguete multicolorido com scripts C # e VB.NET misturados nos pontos onde as abstrações são interrompidas. Para descobrir o que cada "Execute SQL Task" ou "Foreach Loop" faz, tenho que clicar duas vezes na maldita coisa e navegar por uma árvore de valores literais e expressões, espalhados por várias guias.

Tenho a mente aberta, então gostaria de saber se algum outro bom desenvolvedor acha o SSIS mais produtivo do que apenas escrever algum código. Se você acha o SSIS mais produtivo, diga-me por quê.


4
não sei como isso faz, mas o SSIS é muito mais rápido do que qualquer código manual que escrevi para criar um data warehouse. é uma ferramenta projetada para o trabalho - tente dividir as tarefas em pacotes filho que são executados a partir de um pacote mestre
Sr. Shoubs,

1
Link para uma pergunta semelhante: stackoverflow.com/q/690123/327165
Ilya Berdichevsky

5
Acabei de encontrar isso. Estou trabalhando para manter alguns pacotes SSIS problemáticos e escrevi um descompilador para extrair o trabalho útil deles em um programa C #. code.google.com/p/csharp-dessist
Ted Spence

5
Pela minha experiência, o SSIS pode ser doloroso se você tiver sripts "longos" e / ou "complexos" ou muitos scripts. Depurar um aplicativo de console é muito mais fácil. No SSIS, você não pode depurar seu script sozinho. As mensagens de erro produzidas devido a um script são enigmáticas e você não pode ver a linha exata que causou o erro. IMO, se as necessidades do projeto puderem ser atendidas com componentes SSIS padrão, então o SSIS pode ser o caminho a percorrer. Mas, para isso, você precisa conhecer as limitações dos componentes SSIS. Por exemplo, este vídeo mostra por que "tarefa de envio de e-mail" é quase inútil - youtube.com/watch?v=IlUzkMPYDSk
Steam

3
esta questão tem 7 respostas, portanto, não solicitou debate, argumentos, votação ou discussão extensa. Por que não mantê-lo aberto?
Michael Freidgeim

Respostas:


94

Eu uso o SSIS todos os dias para manter e gerenciar um grande data warehouse e cubo. Trabalho 100% em business intelligence e data warehouse há dois anos. Antes disso, fui desenvolvedor de aplicativos .NET por 10 anos.

O valor do SSIS é como um mecanismo de fluxo de trabalho para mover dados de um local para outro, talvez com alguma transformação limitada e ramificação condicional ao longo do caminho. Se seus pacotes contiverem muitos scripts, sua equipe está usando o SSIS para as tarefas erradas, não está confortável com SQL ou aderiu ao hype. Os pacotes SSIS são muito difíceis de depurar. Os componentes de script são um pesadelo absoluto e devem ser usados ​​apenas para formatação, loop ou como último recurso.

  1. Mantenha seus pacotes simples, tarefas sql e tarefas de fluxo de dados.
  2. Faça o máximo de trabalho possível fora do SSIS, de preferência em SQL
  3. Mantenha suas variáveis ​​em um único escopo global
  4. Mantenha seu SQL em variáveis ​​ou procedimentos de armazenamento, nunca em linha
  5. Mantenha seus valores de variáveis ​​em um armazenamento de configuração, de preferência um banco de dados SQL

1
Com os problemas que tive com o SSIS, eu teria dado uma resposta mais tendenciosa (como se você não pudesse dizer pela tonalidade da minha pergunta :)). Boa resposta, Kevin.
Charles

6
Como você trabalhou com o .NET por 10 anos se ele foi lançado em 2002?
Brady Holt

7
[quote] A Microsoft iniciou o desenvolvimento do .NET Framework no final dos anos 1990, originalmente com o nome de Next Generation Windows Services (NGWS). No final de 2000, as primeiras versões beta do .NET 1.0 foram lançadas [/ quote]. É assim que ele provavelmente estava trabalhando com o beta.
nitefrog

A pergunta foi respondida em 2010, então tire o BI de dois anos, e depois os outros 10, dá 1998, dois anos antes do lançamento beta que você mencionou. Caso contrário, boa resposta! :)
finoutlook

Sim, o escopo global faz sentido. Se você torná-lo local e quiser acessá-lo em outro lugar, terá um problema. Você não pode simplesmente mudar o escopo do local para o global. Em vez disso, você precisa de muitos cliques e exclusões. Se você tiver até 10-15 habitantes locais, isso se torna uma dor.
Steam de

52

Tentei usar o SSIS várias vezes e desisti. IMO, é muito mais fácil fazer tudo o que preciso em C #. O SSIS é muito complexo, tem muitas pegadinhas e simplesmente não vale a pena. É muito melhor gastar mais tempo melhorando as habilidades de C # do que gastando o mesmo tempo aprendendo o SSIS - você obterá muito mais retorno em seu treinamento.

Além disso, encontrar e manter a funcionalidade em uma solução VS é muito mais fácil. O teste de unidade com VS é fácil. Tudo o que preciso fazer é verificar o código-fonte no Subversion e verificar como ele foi carregado. Os pacotes de SSIS de teste de unidade são muito complicados, para dizer o mínimo.

Além disso, havia situações em que o SSIS estava silenciosamente falhando ao preencher algumas colunas em algumas linhas, apenas ignorando-as sem levantar exceções. Passamos muito tempo solucionando problemas e descobrindo o que está acontecendo. O desenvolvimento de uma solução alternativa em C # levou menos de uma hora e funciona sem problemas por dois anos.


Obrigado por seus pontos Alex. Aqui está um exemplo do que eu acho que pode ser uma pegadinha - stackoverflow.com/questions/21616435/… .
Steam de

2
Existe uma lista de todos os tópicos de programação C # / que um desenvolvedor ETL DEVE saber? Por exemplo. LINQ, SqlDataReader, DataTable etc. Também acho que o SSIS não é bom para tarefas complexas. Se você tiver um projeto / tarefa fácil de "copiar e colar", o SSIS pode ser a melhor ferramenta.
Steam de

@blasto, você experimentou Rhino ETL: ayende.com/blog/3102/rhino-etl-2-0
AK de

Alex, a resposta de Jerome também sugeriu Rhino ETL. Parece obscuro para mim. Então, eu ficaria hesitante em usá-lo por falta de documentação, suporte e tutoriais. Além disso, parece que apenas um desenvolvedor está trabalhando nisso. Isso diminui minha confiança na ferramenta. Eu tentaria isso por diversão ou por curiosidade, mas não posso usar isso para um projeto real. Obrigado.
Steam de

Se alguém quiser um tutorial sobre Rhino ETL (com C # puro), aqui está um - codeproject.com/Articles/34556/Write-ETL-jobs-in-pure-C
Steam

14

Na minha opinião - o SSIS é apenas para operações ETL e não deve conter nenhuma lógica fora desse escopo.


8
ETL = Extrair Carga de Transformação
Christoph

3
É mais ou menos assim que me sinto. Em nosso caso, estamos usando o SSIS para fazer coisas como CSVs de e-mail (ou SFTP) contendo informações de preço. A ramificação, scripts embutidos, etc. são muito horríveis. Se apenas movesse alguns dados com o SSIS, provavelmente não seria tão ruim.
Charles

1
Acho que sua resposta poderia ter um pouco mais de profundidade.
Steam de

3
OT em ETL não pode envolver alguma lógica? Apenas um pensamento ...
cs0815

Se estiver relacionado apenas a moldar / rotear os dados, com certeza. Mas eu evitaria qualquer lógica de negócios.
Christoph

11

Tive a infeliz experiência de trabalhar em um projeto em que achávamos que o SSIS seria uma solução boa o suficiente para agregar e combinar dados de várias fontes. O infeliz é que funcionou muito bem no início, mas depois os requisitos mudaram e (eventualmente) percebemos que era a ferramenta errada.

talvez o estivéssemos apenas usando incorretamente, mas teríamos muita dificuldade se mudássemos nosso esquema e eventualmente reutilizássemos nossas definições ORM do front-end para escrever uma ferramenta personalizada em C # para fazer isso. Como já tínhamos o modelo de dados, isso foi surpreendentemente fácil. Obviamente, YMMV e eu não somos de forma alguma um especialista em SSIS, mas neste caso o SSIS causou muito trabalho duplicado e dores de cabeça quando apenas arregaçar as mangas e 'codificar' foi mais fácil do que o esperado.

Portanto, eu pensaria muito sobre a flexibilidade ao considerar o SSIS.


7
Eu compartilho alguns dos mesmos sentimentos. É fácil refatorar código ... não tanto com uma DSL visual.
Charles

Luke, você pode nos dar um esboço dos requisitos do seu projeto? Obrigado.
Steam de

@blasto, estávamos tentando integrar dados de vários bancos de dados e usar alguns dos utilitários de correspondência de string probabilística integrados para mesclar dados de diferentes sistemas (essencialmente bancos de dados de CRM). Foi há mais de 5 anos, então não me lembro de todos os detalhes.
luke de

Se você for uma loja .net e estiver envolvido na movimentação de dados para fins de armazenamento de dados, o SSIS só o ajudará se você souber disso bem o suficiente. Tenho visto muitas pessoas que são gurus de .net, mas não conseguem entender completamente o SSIS (e eu não os culpo). O SSIS certamente requer uma pessoa que o conheça bem o suficiente, caso contrário, você acabará escrevendo pacotes que são ineficientes e não podem fazer a coisa certa.
rvphx

6

O SSIS tem seu lugar, e esse lugar não é uma programação geral ou uma substituição de procedimentos armazenados. Ele vem da escola ETL (Extrair, Transformar e Carregar) e é aí que está sua força.

O nome antigo (DTS, Data Transformation Services) e o novo nome (SSIS, Sql Server Integration Services) deixam claro que é um serviço (ou conjunto de serviços) projetado para manipular dados para integrar o banco de dados SQL Server em processos maiores.


Não vejo como essa resposta deveria receber tantos votos positivos. Ele não menciona porque o SSIS não pode fornecer a você o poder de uma linguagem de programação. Isso não faz sentido para mim. Um exemplo de onde o SSIS falha em corresponder a uma linguagem de programação é a depuração. Aparentemente, o SSIS 2012 muda isso. Portanto, pode ser, apenas pode ser, a ferramenta está a caminho de se tornar mais amigável para o programador.
Steam de

>> Um exemplo de onde o SSIS falha em corresponder a uma linguagem de programação ... Eu concordo - não é uma linguagem de programação. É uma ferramenta ETL decente.
DaveE

4

Se você deseja mover seus dados programaticamente, você pode querer olhar para Rhino ETL.

Também estou trabalhando em meu próprio framework, Fluent ETL , pois acho o SSIS um pouco complicado para tarefas simples de dados relacionadas ao desenvolvimento, como carregar dados de teste de unidade de um arquivo CSV.


Rhino ETL é obscuro e tem apenas 24 perguntas sobre o SO no momento - stackoverflow.com/questions/tagged/rhino-etl . Acho que C # seria bom o suficiente para ETL, se você tiver o conhecimento e a experiência.
Steam de

1
Existem alternativas populares para Rhino ETL?
Steam de

3

SSIS não é um programa. Muitas coisas são mais rápidas de fazer no SSIS, e você obtém um progresso muito bom e detalhado e informações de erro como administrador - o que pode ser muito bom nos cenários que o SSIS deve resolver, porque às vezes as coisas dão errado e o administrador precisa de muito em formação.

Dito isso, o SSIS não é realmente tão útil se você não tiver as coisas autoedxplanatórias - eles foram feitos para alguma coisa, colocar muito em programação geral os torna um lixo.


2
Você pode nos dar um exemplo de como o SSIS pode acelerar o desenvolvimento em um cenário e desacelerar em outros?
Steam de
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.