Como abordar uma missão de ETL?

https://stackoverflow.com/questions/440346

22-07-2019
|

Pergunta

Eu estou supostamente para realizar ETL onde fonte é um grande e mal projetado banco de dados SQL 2k e 2k5 banco de dados de um sql melhor concebido. Acho SSIS é o caminho a percorrer. Alguém pode sugerir uma lista de coisas a fazer ou uma lista de verificação ou coisas para watchout por tanto que eu não esquecer de nada? Como devo abordar isso para que ele não me morder na tarde traseira diante.

Solução

Bem, eu estou desenvolvendo um ETL para a empresa onde estou.

Estamos trabalhando com SSIS. Usando a API para gerar e construir os nossos próprios pacotes dtsx.

SSIS não é amigável para o gerenciamento de erros. Às vezes você tem um "erro OleDb" que poderiam ter um monte de diferentes significados depeding do contexto.

Leia a documentação API (eles não dizem muito).

Alguns links para ajudá-lo a começar lá: http://technet.microsoft.com/de-de /library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library /ms345167.aspx

http://msdn.microsoft.com/en-us/library /ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki /ComponentErrorCodes.html

http: // www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library /ms187670.aspx

http: // MSDN .microsoft.com / ja-jp / biblioteca / microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http: // www .sqlis.com / post / Manipulação-diferentes-rOW-tipos-in-the-same-file.aspx

http://technet.microsoft.com/ en-us / library / ms135967 (SQL.90) .aspx

http://msdn.microsoft.com/ en-us / library / ms137709 (SQL.90) .aspx

http://msdn.microsoft.com/ en-us / library / ms345164 (SQL.90) .aspx

http://msdn.microsoft.com/en-us/library /ms141232.aspx

http://www.microsoft.com/technet/prodtechnol /sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http: //www.experts -exchange.com/Microsoft/Develmento / MS-SQL-Server / SSIS / Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum aspx? siteid = 1 & PostID = 1404157

http://msdn.microsoft.com/ en-us / library / aa719592 (VS.71) .aspx

http://forums.microsoft.com/MSDN/MigratedForum aspx? siteid = 1 & ForumID = 80

http : //blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http: // blogs .conchango.com / jamiethomson / Arquivo / 2007/03/13 / SSIS_3A00_ imobiliário-Caminhos-syntax.aspx

http: // pesquisa. live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008 /09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library /ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

Desculpe o "spam", mas eles são muito úteis para mim.

Outras dicas

Algumas dicas ETL geral

Considere organizando-o por destino (por exemplo, toda a código para produzir o Cliente dimensão vive no mesmo módulo, independentemente da fonte). Isso às vezes é conhecido como ETL temática. Faz encontrar coisas muito mais fácil e vontade melhorar a manutenção do seu código.
Se o banco de dados SQL2000 é uma bagunça, você provavelmente vai achar que SSIS fluxos de dados são uma forma desajeitada de lidar com os dados. Como regra, ferramentas de ETL escala mal com complexidade; algo como a metade de todos os dados projetos de armazém em finanças empresas é feito com armazenados código de procedimento como uma explícita decisão arquitetônico - precisamente por essa razão. Se você tem colocar uma grande quantidade de código em sprocs, considere colocar todas do código em sprocs.
Para um sistema que envolve lotes do lavagem ou transformações complexas, uma abordagem sproc 100% é muito mais fácil de manter, pois é a única maneira viável de colocar todas as transformações e lógica de negócios em um só lugar. Com os sistemas de ETL / sproc mistos, você tem que olhar em vários lugares para acompanhar, solucionar problemas de depuração ou mudar toda a transformação.
O ponto doce de ferramentas de ETL é em sistemas onde você tem um número maior de fontes de dados com as transformações relativamente simples.
Faça o testável código, para que você possa detectar os componentes e teste em isolamento. Código que só pode ser executado a partir de meados de uma base de dados complexos fluir em uma ferramenta de ETL é muito mais difícil de teste.
Faça os dados extrair mudo sem lógica de negócios e cópia em um estadiamento área. Se você tem negócios lógica espalhados por todo o extrato e transformar camadas, você terá transformações que não podem ser testados em isolamento e tornam difícil rastrear bugs. Se o é transformar correndo de uma área de preparação você reduzir a dependência duro no sistema de origem, mais uma vez aumentando testability. Esta é uma vitória particular sobre arquiteturas baseadas em sproc, pois permite uma base de código quase completamente homogênea.
Criar um genérico lentamente mudando manipulador de dimensão ou uso um fora da prateleira, se disponível. Isto torna mais mais fácil a este teste de unidade funcionalidade. Se isso pode ser unidade testado, o teste do sistema não faz tem que testar todos os casos de canto, apenas se os dados apresentados ao isso está correto. Isto não é tão complexa quanto parece - O último que eu escrevi foi sobre 600 ou 700 linhas de código T-SQL. O mesmo vale para quaisquer funções de esfrega genérico.
Carga de forma incremental, se possível.
Instrumento seu código - têm que fazer as entradas de log, possivelmente gravação diagnósticos como totais de verificação ou conta. Sem isso, solução de problemas é quase impossível. Além disso, a verificação afirmação é uma boa maneira de pensar de manipulação de erro para este (faz contagem de linha em uma contagem de linhas iguais em b, é A: relação B realmente 1: 1)
Use as teclas sintéticos. Usando chaves naturais a partir dos sistemas de origem amarra seu sistema para as fontes de dados, e torna difícil para adicionar fontes extra. As chaves e os relacionamentos em que o sistema deve sempre se alinha - sem nulos. Para erros 'não registradas', fazer um 'erro' ou 'não registrados' entradas na tabela de dimensão e combinar a eles específico.
Se você construir um armazenamento de dados operacionais (o assunto de muitos uma guerra religiosa) não reciclar as chaves ODS nos esquemas estrela. Por todos os meios juntar-se em chaves ODS para a construção de dimensões, mas corresponder em uma chave natural. Isso permite que você eliminar e recriar os ODS arbitrariamente - possivelmente alterando a sua estrutura - sem perturbar os esquemas em estrela. Ter esta capacidade é uma vitória manutenção real, como você pode mudar ODS estrutura ou fazer uma força-bruta re-implantação dos ODS em qualquer ponto.

Pontos 1-2 e 4-5 significa que você pode construir um sistema onde todas do código para qualquer subsistema (por exemplo, um único dimension ou fato tabela) vive em um e somente um lugar no sistema. Este tipo de arquitetura também é melhor para o maior número de fontes de dados.

O ponto 3 é um contraponto ao ponto 2. Basicamente, a escolha entre SQL e ferramentas ETL é uma função da complexidade transformação eo número de sistemas de origem. O mais simples dos dados e maior o número de fontes de dados, mais forte o argumento para uma abordagem baseada em ferramentas. Quanto mais complexa a dados, mais forte será o caso de transição para uma arquitetura baseada em procedimentos armazenados. Geralmente é melhor exclusivamente ou quase exclusivamente usar um ou o outro, mas não ambos.

O ponto 6 torna o sistema mais fácil de teste. Teste SCD de ou qualquer funcionalidade mudança com base é trabalhosa, como você tem que ser capaz de apresentar mais do que uma versão dos dados de origem para o sistema. Se você mover a funcionalidade de gerenciamento de mudanças no código de infra-estrutura, você pode testá-lo em isolamento com conjuntos de dados de teste. Esta é uma vitória nos testes, uma vez que reduz a complexidade de suas necessidades de testes do sistema.

O ponto 7 é uma dica de desempenho geral que você precisa observar para grandes volumes de dados. Note que você pode precisar apenas de carregamento incremental para algumas partes de um sistema; para tabelas de referência menores e dimensões que você não pode precisar dele.

O ponto 8 é pertinente a qualquer processo sem cabeça. Se ele vai mamas durante a noite, você quer alguma chance de lutar de ver o que deu errado no dia seguinte. Se o código não corretamente registrar o que está acontecendo e erros de captura, você vai ter um trabalho muito mais difícil resolver esta questão.

O ponto 9 dá o data warehouse uma vida própria. Você pode facilmente adicionar e soltar sistemas de origem quando o armazém tem suas próprias chaves. chaves do armazém também são necessárias para implementar lentamente mudando dimensões.

O ponto 10 é uma manutenção e implantação de vitória, como o ODS pode ser re-estruturado, se você precisa adicionar novos sistemas ou alterar a cardinalidade de um registro. Isso também significa que uma dimensão podem ser carregadas a partir de mais de um lugar nas ODS (pense: a adição de ajustes contábeis manuais). Sem uma dependência nas teclas ODS

Eu tenho experiência com processos de ETL puxando dados de mais de 200 bancos de dados distribuídos a uma base central em uma base diária, semanal, mensal e anual. É uma enorme quantidade de dados e há muitas questões que tivemos específico para a nossa situação. Mas a meu ver, há vários itens para pensar independentemente da situação:

Certifique-se de que você tome bloqueios de arquivos em consideração, tanto do lado da fonte e destino. Certificar-se de que outros processos não têm os arquivos bloqueados (e remover esses bloqueios se necessário e faz sentido) é importante.
bloqueando os arquivos para si mesmo. Certifique-se, especialmente na fonte que você bloquear os arquivos enquanto puxa os dados para que você não obter dados a meio caminho atualizados.
Se possível, deltas de puxar, nem todos os dados. Obter uma cópia dos dados e puxe apenas as linhas que foram alteradas em vez de tudo. Os maiores seus dados definir o mais importante isso se torna. Olhada em revistas e gatilhos, se você tem, mas como ela se torna mais importante ter esses dados em uma certa base, este é provavelmente o número um conselho que eu lhe daria. Mesmo que adiciona uma quantidade significativa de tempo para o projeto.
log de execução. certifique-se de saber quando ele trabalhou e não quando o fez, e jogando erros específicos no processo pode realmente ajudar na depuração.
documento, documento, documento. Se você construir este direito, você está indo para construí-lo e depois não pensar sobre isso por um longo tempo. Mas você pode ser garantido, você ou alguém terá de voltar a ele em algum ponto para melhorá-lo ou fazer uma correção de bug. A documentação é fundamental nestas situações.

HTH, mal atualizar esta se eu pensar em mais nada.

Estamos fazendo um enorme ETL (movendo um cliente a partir de aplicativos legacy AS400 para o Oracle EBS), e nós realmente temos um processo que (com modificações) eu posso recomendar:

Identificar o alvo crítico tabelas / campos.
Identificar o crítico tabelas de origem / campos.
Trabalho com o os usuários de negócios para mapear fonte de -alvo.
Analisar os dados de origem para questões de qualidade.
Determinar quem é responsável pelas questões de qualidade de dados identificados.
Have partes responsáveis limpar os dados na fonte.
Desenvolver o ETL real com base na informações de passos. 1 - 3

As etapas mais complicadas são 2 e 3 na minha experiência - às vezes é difícil para obter os usuários de negócios para identificar corretamente todos os bits que precisam em um único passe, e pode ser ainda mais difícil para corretamente identificar exatamente onde os dados estão vindo ( no entanto, que pode ter algo a ver com nomes de arquivos e de campo enigmáticas que eu estou vendo!). No entanto, este processo deve ajudá-lo a evitar grandes acidentes.

Esta discussão é antiga, mas eu quero chamar a atenção para resposta ConcernedOfTunbridgeWells. É incrivelmente bons conselhos, em todos os pontos. Eu poderia reiterar alguns, mas que iria diminuir o resto, e todos eles merecem estudo minucioso.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow