Algumas dicas gerais de ETL

1. 
   Considere organizá-lo por destino (por exemplo, todo o código para produzir a dimensão Cliente reside no mesmo módulo, independentemente da origem). Isso às vezes é conhecido como ETL orientado a assunto. Isso torna a localização de coisas muito mais fácil e aumentará a capacidade de manutenção do seu código.
   
2. 
   Se o banco de dados SQL2000 estiver uma bagunça, você provavelmente descobrirá que os fluxos de dados do SSIS são uma maneira desajeitada de lidar com os dados. Como regra, as ferramentas de ETL escalam mal com a complexidade; algo como metade de todos os projetos de datawarehouse em empresas financeiras são feitos com código de procedimento armazenado como uma decisão de arquitetura explícita - exatamente por esse motivo. Se você precisar colocar uma grande quantidade de código nos procedimentos, considere colocar todos do código em sprocs.
   
   Para um sistema que envolve muitas depurações ou transformações complexas, uma abordagem 100% sproc é muito mais sustentável, pois é a única maneira viável de colocar todas as transformações e lógica de negócios em um só lugar. Com sistemas ETL/sproc mistos, você precisa procurar em vários lugares para rastrear, solucionar problemas, depurar ou alterar toda a transformação.
   
3. 
   O ponto ideal das ferramentas ETL está em sistemas onde você tem um número maior de fontes de dados com transformações relativamente simples.
   
4. 
   Torne o código testável, para que você possa separar os componentes e testar em isolamento. O código que só pode ser executado no meio de um fluxo de dados complexo em uma ferramenta ETL é muito mais difícil de testar.
   
5. 
   Torne a extração de dados burra com lógica nobusiness e copie para a área de armazenamento temporário. Se você tiver lógica de negócios espalhada pelas camadas de extração e transformação, terá transformações que não podem ser testadas isoladamente e dificultarão o rastreamento de bugs. Se a transformação estiver sendo executada a partir de uma área de teste, você reduz a dependência física do sistema de origem, aprimorando novamente a testabilidade. Esta é uma vitória particular em arquiteturas baseadas em sproc, pois permite uma base de código quase completamente homogênea.
   
6. 
   Construa um manipulador de dimensão genérico de mudança lenta ou use um de prateleira, se disponível. Isso facilita o teste de unidade dessa funcionalidade. Se isso puder ser testado de forma unitária, o teste do sistema não precisa testar todos os casos de canto, apenas se os dados apresentados a ele estão corretos. Isso não é tão complexo quanto parece - O último que escrevi foi cerca de 600 ou 700 linhas de código T-SQL. O mesmo vale para qualquer função de depuração genérica.
   
7. 
   Carregue de forma incremental, se possível.
   
8. 
   Instrumente seu código - faça com que ele faça entradas de log, possivelmente gravando diagnósticos, como verificar totais ou contagens. Sem isso, a solução de problemas é quase impossível. Além disso, a verificação de asserção é uma boa maneira de pensar no tratamento de erros para isso (a contagem de linhas em uma contagem de linhas igual em b, é o relacionamento A:B realmente 1:1).
   
9. 
   Use chaves sintéticas. O uso de chaves naturais dos sistemas de origem vincula seu sistema às origens de dados e dificulta a adição de origens extras. As chaves e relacionamentos no sistema devem sempre estar alinhados - sem nulos. Para erros, 'não registrados', faça uma entrada específica de 'erro' ou 'não registrado' na tabela de dimensões e corresponda a eles.
   
10. 
    Se você construir um Armazenamento de Dados Operacionais (o assunto de muitas guerras religiosas), não recicle as chaves ODS nos esquemas em estrela. Por todos os meios, junte-se a chaves ODS para construir dimensões, mas combine em uma chave natural. Isso permite que você descarte e recrie arbitrariamente o ODS - possivelmente alterando sua estrutura - sem perturbar os esquemas em estrela. Ter esse recurso é uma verdadeira vitória de manutenção, pois você pode alterar a estrutura do ODS ou fazer uma reimplantação de força bruta do ODS a qualquer momento.
    

Os pontos 1-2 e 4-5 significam que você pode construir um sistema onde todos do código para qualquer subsistema (por exemplo, uma única dimensão ou tabela de fatos) reside em um e apenas um lugar no sistema. Esse tipo de arquitetura também é melhor para um número maior de fontes de dados.

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

O ponto 6 torna seu sistema mais fácil de testar. Testar SCDs ou qualquer funcionalidade baseada em alterações é complicado, pois você precisa apresentar mais de uma versão dos dados de origem ao sistema. Se você mover a funcionalidade de gerenciamento de alterações para o código de infraestrutura, poderá testá-la isoladamente com conjuntos de dados de teste. Isso é uma vitória nos testes, pois reduz a complexidade dos requisitos de teste do seu sistema.

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

O ponto 8 é pertinente a qualquer processo sem cabeça. Se der errado durante a noite, você quer alguma chance de lutar para ver o que deu errado no dia seguinte. Se o código não registrar corretamente o que está acontecendo e detectar erros, você terá um trabalho muito mais difícil para solucioná-lo.

O ponto 9 dá vida própria ao data warehouse. Você pode facilmente adicionar e descartar sistemas de origem quando o warehouse tiver suas próprias chaves. As chaves de depósito também são necessárias para implementar dimensões que mudam lentamente.

O ponto 10 é uma vitória de manutenção e implantação, pois o ODS pode ser reestruturado se você precisar adicionar novos sistemas ou alterar a cardinalidade de um registro. Isso também significa que uma dimensão pode ser carregada de mais de um local no ODS (pense:adicionar ajustes contábeis manuais) sem depender das chaves ODS.