Erros específicos de campo para ETL

Question

Estou criando um processo ETL no MS SQL Server e gostaria de ter erros específicos para uma coluna específica de uma linha específica. Por exemplo, os dados são carregados inicialmente a partir de arquivos do Excel em uma tabela (chamaremos a tabela inicial) onde todas as colunas estão varchar(2000) E então eu encenado os dados para outra tabela (o DatatypedTable) que contém tipos de dados mais específicos (datetime,int, etc.) ou comprimentos de varchar mais firmemente restritos. Preciso criar mensagens de erro para um campo específico, como: "13 de janeiro" não é um formato de data válido para a data de envio. Por favor, use um formato de mm/dd/yyyy

Essas mensagens de erro precisariam ser armazenadas de alguma forma de modo que, posteriormente, no processo, um processo automatizado possa criar relatórios com as mensagens de erro de modo que cada mensagem referencia uma linha e campo específicos (alguém precisará voltar e corrigir os dados no sistema de origem e reenvie o arquivo do Excel). Então, idealmente, seria inserido em algumas tabelas de falhas de algum tipo e contém a chave primária da linha falhada, o nome da coluna e a mensagem de erro.

Pergunta: Então, estou me perguntando se isso pode ser realizado com o SSIS, ou alguma ferramenta de código aberto como o Talend, e se sim, qual seria sua abordagem geral? Ou que abordagem codificada à mão você adotaria?

Casal Abordagens que pensei em usar o SQL (até que não, eu fiz o ETL manualmente no SQL Procs, mas quero considerar outras abordagens. Possível C# uniforme.):

Use um cursor para ler a tabela inicial e, para cada linha, insira um registro em branco com apenas a chave primária na tabela de dados de dados, use uma única instrução de atualização para cada coluna, de modo que, se essa atualização falhar, posso inserir uma muito específica Mensagem de erro específica para essa coluna na tabela Mensagens de erro.

Insira todos os dados como está na tabela de dados de dados, mas tenha colunas duplicadas como SubmissionDate e SubmissionDateOld. Após a inserção inicial, as colunas antigas têm dados, o restante está em branco e eu tenho uma única atualização para cada coluna que define o submissionDate com base no submissionDateold.

Além de sugerir uma abordagem, gostaria de saber se você está usando essa abordagem ou algo semelhante já no trabalho que faz.

Answer 1

Eu uso a APROach onde coloquei uma divisão condicional no fluxo de dados. Os registros que falham nas condições (data inválida, nenhum dado em um campo necessário etc.) são enviados para uma tabela de exceção que inclui o identificador de registro, os dados ruins, a razão pela qual ele falhou. Mais tarde, você pode criar uma planilha ou um arquivo de texto de erros a partir dessas informações para enviar de volta ao grupo que fornece o arquivo. É claro que bons registros vêm ao caminho e são inseridos na tabela.

Answer 2

Que tal alguma limpeza/transformação antes de carregar as tabelas de encenação (o que você chama de tabelas iniciais)? Despeje os dados do Excel em uma guia ou arquivo separado por vírgula e use algumas linguagens de programação de sua escolha para fazer a limpeza de dados que você observou. Além disso, qual o tamanho de cada carga de dados? Você pode usar o aplicativo multithread ou multipocess para lidar com grandes cargas (como carregar alguns milhões de linhas por vez). Durante esse processo, qualquer erro encontrado pode ser carregado na tabela de exceção com detalhes de identificador, erro e comentário. Essa técnica ajuda a ter melhor controle durante a fase de limpeza de dados.

Se a carga não for tão alta e você quiser fazer a maior parte do seu trabalho no banco de dados (SQL), convém fazer o máximo de perfil de dados possível e ter um bom submedimento de possíveis variações de dados que você pode esperar. Com isso, você pode usar o componente apropriado (Talend ou SSIS) para fazer a transformação ou controlar o fluxo de dados. Além disso, usando expressões regulares, você pode capturar qualquer entidade que se desvie da regra definida.