Existe uma linguagem / interface padrão para ETL programático no SQL Server?


10

Atualmente, estou no processo de criação de ETLs para nosso data warehouse. Estamos usando o SSIS 2008, mas estamos enfrentando problemas, o maior dos quais é a dificuldade em reutilizar componentes. Temos pacotes separados para cada tabela e cada pacote recebe como entrada um número de variáveis ​​de um pacote pai. À medida que fazemos alterações nessas variáveis ​​de entrada, somos obrigados a entrar em cada pacote (temos 15 ou mais agora, mas esse número vai crescer significativamente) e modificar o pacote para lidar com essas alterações. Há também outros problemas, incluindo a incapacidade de executar SQL arbitrário para nossa extração, recursos de log ruins etc.

Todo esse processo seria muito mais robusto se houvesse uma maneira de desenvolver nossos ETLs no código, permitindo a reutilização de código, bibliotecas comuns, melhores testes de unidade, etc. Existe uma linguagem / API ETL padrão de fato para SQL Server? Eu estou olhando para evitar ferramentas GUI, tanto quanto possível.

Edit: Devo mencionar o meu passado. Eu não sou um DBA e não tenho treinamento formal (ou informal), eu basicamente descobri essas coisas ao longo do caminho, então há toda a probabilidade de que eu esteja tentando fazer coisas inapropriadas com o SSIS ou abordando este ETL projeto a partir do ângulo errado. Além disso, atualmente estou empregado no governo estadual, portanto, quaisquer soluções que exijam a compra de um novo pacote de software não estão dentro do campo de possibilidade.


Aqui está uma de nossas tarefas. Estamos usando um único pacote SSIS para carregar cada tabela em nosso armazém. Cada pacote Fact e Dimension são geralmente iguais, diferem apenas em

  • Extrações do banco de dados de origem
  • Manipulações em um fluxo de dados
  • Mescla na tabela de destino

O que eu gostaria de poder fazer (que acho difícil de fazer no SSIS)

  • Carregue a consulta de extração de um arquivo de texto. Quando os desenvolvedores estão escrevendo e testando suas consultas de extração, não preciso manipular sua consulta de forma alguma antes que o SSIS a execute e não preciso recortar e colar a consulta em um objeto de origem de banco de dados.
  • Teste cada componente individualmente. Deveria poder testar o processo ETL completo para uma tabela individual isoladamente, independentemente de outras cargas de tabela.
  • Faça modificações na lógica compartilhada em um único local, não precisa editar cada pacote individual. Todo pacote carrega dados nas tabelas de auditoria da mesma maneira, se eu quiser alterar os dados carregados auditados, não quero editar todos os 15 pacotes (esse número ficará muito maior com o tempo).

Todo o processo parece que seria muito mais fácil de implementar e mais robusto se feito de maneira programática com o uso adequado do código compartilhado.


4
Eu não sou um usuário muito grande do SSIS, mas posso entender a percepção da curva de aprendizado acentuada aqui. Encorajo-vos a olhar para alguns vídeos / blogs de Andy Leonard, Jamie Thompson, Brian Knight, especialistas no campo e obter orientação. Olhada no site sqlpass.org gratuitamente vídeos de passagem cúpula & sqlblog.com, pragmaticworks.com
Sankar Reddy

Não acredito que a curva de aprendizado seja um problema. Eu sei como executar as tarefas que quero realizar no SSIS. Estou procurando um novo processo, porque as soluções que encontrei são repetitivas, frágeis e desnecessariamente complexas.
Kubi 25/05

Kubi, Se você pode adicionar detalhes sobre quais componentes você está se referindo, trarei alguém capaz de responder isso para você. Como está agora, sua pergunta é ampla demais para responder.
Sankar Reddy 25/05

4
@kubi - você mencionou um dos pequenos segredos sujos da indústria de BI. As ferramentas ETL são muito, muito pobres em abstração e lógica reutilizável. Como conseqüência, eles se dimensionam muito mal com o aumento da complexidade do domínio.
ConcernedOfTunbridgeWells

11
Tenho uma autoridade razoavelmente boa de que cerca de metade dos clientes de um determinado produto vertical do setor para serviços bancários e seguros (feitos por uma empresa da qual você já ouviu falar e geralmente se refere a uma cor específica) tomam uma decisão técnica explícita Processamento ETL no procedimento armazenado, exatamente por esse motivo.
ConcernedOfTunbridgeWells

Respostas:



6

Ao ler isso, pensei imediatamente em recomendar as ferramentas da Varigence. No entanto, vejo que um dos principais arquitetos da Varigence, John Welch, chegou aqui antes de mim.

As ferramentas da Varigence são uma camada de abstração acima do SSIS. A vantagem que isso oferece é a capacidade de definir "coisas" reutilizáveis, proporcionando consistência em vários pacotes. Você define como os pacotes devem ser estruturados e como eles diferem individualmente - os resultados "compilados" das ferramentas da Varigence são pacotes SSIS.

Pense nisso como SQL dinâmico para pacotes SSIS. Com uma GUI. Realmente muito legal.


3

Eu tentei usar o SSIS várias vezes e desisti. Na IMO, é muito mais fácil fazer tudo o que preciso em c #. O SSIS é muito complexo, tem muitos truques e simplesmente não vale a pena. É muito melhor gastar mais tempo aprimorando as habilidades de C # do que gastar o mesmo tempo aprendendo SSIS - você obterá muito mais retorno em seu treinamento. Não preciso entrar em muitos detalhes aqui - Ayende escreveu um ótimo resumo ao qual não tenho nada a acrescentar .

Também encontrar e manter a funcionalidade em uma solução VS é muito mais fácil. O teste de unidade com o VS é fácil. Tudo o que preciso fazer é verificar a fonte no Subversion e verificar como ele foi carregado. O teste de unidade de pacotes SSIS está muito envolvido para dizer o mínimo.

Além disso, houve situações em que o SSIS falhou silenciosamente ao preencher algumas colunas em algumas linhas, pulando-as sem gerar 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.

Também Rhino ETL parece ser muito legal.

Houve algumas discussões semelhantes sobre o stackoverflow .


2

Pessoalmente, eu manejo o máximo possível do processo ETL no SQL. Uso o SSIS para importar de fontes de dados ímpares, como sites FTP ou Excel, mas isso é apenas para obter dados brutos no banco de dados onde o SQL faz o resto.

Minha situação atual é relativamente simples, pois a maioria dos dados está em outros bancos de dados MS SQL, com os quais posso configurar servidores vinculados. Se você precisar se conectar a outras plataformas, recomendo usar OPENQUERYe BULK INSERT. Eles podem ser construídos programaticamente, se necessário, e entre os dois, eles podem se conectar à maioria dos tipos de dados.

Uso SQL porque é o que eu sei melhor, mas tem algumas vantagens objetivas. Mais notavelmente, ele já está sendo usado: não há necessidade de aprender ou pagar por uma nova ferramenta. É uma habilidade amplamente disponível, que deve ser importante para o seu chefe, se não para você. Uma vez que opera no banco de dados, o registro é fácil. Ele é baseado em código de texto simples, por isso é facilmente pesquisado e funciona bem com o controle de origem. É muito estável, com poucas chances de o fornecedor mudar as coisas e quebrar a compatibilidade com versões anteriores. Provavelmente é pelo menos tão rápido quanto qualquer idioma RBAR.

Se você precisar de mais, recomendo o .NET, apenas porque é usado no SSIS e SQLCLR. Uso aplicativos C # para gerenciar todo o processo ETL - iniciando sub-etapas, monitorando sua saída, enviando e-mails. Mas quase tudo isso pode ser feito com o SQL Agent, dbmail etc.

Existe algum motivo para você não poder usar o SQL para seu ETL? O que isso não foi capaz de fazer por você?


Na verdade, usamos o SSIS para despejar dados brutos nos Temp DBs e, em seguida, usamos o TSQL para definir como queremos utilizá-lo.
Paul
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.