A detecção de adições e atualizações em tabelas de banco de dados para replicação de dados, ETL, mascaramento de PII e outras atividades incrementais de movimentação e manipulação de dados pode ser automatizada em fluxos de trabalho IRI Voracity projetados e executados no IRI Workbench (WB). Este artigo explica como verificar regularmente as alterações nas tabelas de origem do Oracle para decidir quando mover dados para um destino do MongoDB.
As alterações podem ser carregadas em diferentes bancos de dados ou arquivos usando um arquivo em lote ou script de shell com tarefa agendada. Isso pode ser feito usando um carimbo de data/hora e campos específicos na tabela de origem. A verificação de erros está incluída e também pode ser respondida.
Este exemplo será criado e executado em uma máquina Windows; no entanto, ele pode ser facilmente modificado para funcionar em uma plataforma do tipo Linux ou Unix.
Criar o arquivo em lote é fácil usando um diagrama Voracity Flow no WB. Neste exemplo, a tabela de origem contém colunas chamadas CREATION_DATE e UPDATE_DATE que são importantes neste trabalho.
A imagem abaixo mostra as etapas contidas no arquivo de lote. Para resumir:
- o trabalho é executado em um diretório específico
- uma variável de ambiente é definida usando o carimbo de data/hora da última execução do trabalho
- o carimbo de data/hora atual é gravado
- as alterações atuais são capturadas
- o nível de erro é verificado e corrigido se for bem-sucedido ou não
- o carimbo de data/hora atual substitui o carimbo de data/hora da última execução
- os dados alterados são convertidos em CSV
- um travamento ocorre para aguardar a existência do último arquivo
- o arquivo CSV é importado para o MongoDB
- o nível de erro é verificado, o arquivo atual está truncado
- o arquivo de alterações é excluído
Cada bloco de tarefa no fluxo de trabalho é explicado abaixo. Para obter instruções sobre como criar fluxos de trabalho Voracity a partir da paleta, consulte este artigo.
Alterar diretório
Este bloco altera o diretório de trabalho atual para o especificado.
Definir ÚLTIMA HORA
Este bloco de linha de comando define uma variável de ambiente chamada LASTTIME . O valor definido para a variável é o conteúdo do arquivo LastTime.txt . O carimbo de data/hora neste arquivo é o carimbo de data/hora que foi registrado durante a última execução deste trabalho. Se esta for a primeira execução, este arquivo terá que ser feito manualmente com um carimbo de data/hora arbitrário datado antes da execução deste trabalho.
Timestamp.scl
Este bloco de transformação usa o programa CoSort SortCL no Voracity para consultar o banco de dados de origem para a hora atual. Esse carimbo de data/hora é salvo em um arquivo chamado LastTimeTemp.txt . O motivo pelo qual ele é armazenado em um arquivo temporário é para que os carimbos de data e hora atuais e os últimos possam ser preservados até que ocorra a verificação de erros.
É importante que o carimbo de data/hora venha do banco de dados e não da máquina local. Isso evita problemas em que o banco de dados e o ambiente de execução não estejam sincronizados.
Alterações.scl
Este bloco de transformação faz algumas coisas. Abaixo está o diagrama de mapeamento de transformação para este bloco. A entrada é a tabela de origem e a saída é o arquivo current.txt .
Na entrada Opções da Seção, uma consulta é enviada à tabela de origem para todos os registros que têm um CREATION_DATE ou UPDATE_DATE maior que a variável de ambiente LASTTIME .
Embora a saída pareça ter dois destinos , os dados estão, na verdade, sendo anexados ao mesmo arquivo usando duas condições diferentes. Na primeira seção de saída, há um Incluir instrução que encontra todos os registros que têm um CREATION_DATE maior que LASTTIME . Há também um campo de saída adicional chamado CDC_TYPE . A string “CREATE” é gravada nesse novo campo.
Na segunda seção de saída, um Incluir A instrução encontra todos os registros que têm um UPDATE_DATE maior que LASTTIME e onde CREATION_DATE não é igual a UPDATE_DATE. Isso garante que os arquivos recém-criados não sejam incluídos nesta passagem. A string “UPDATE” é registrada em CDC_TYPE.
Coordenação de erro
Este bloco de decisão verifica a variável ERRORLEVEL para certificar-se de que retornou 0 (ou sucesso) após executar o trabalho CoSort acima. Caso contrário, o trabalho continua até EXIT bloco onde o trabalho é finalizado. Se retornar verdadeiro, o trabalho continua para o próximo bloco.
Renomear LastTimeTemp
Este bloco de comando copia o conteúdo de LastTimeTemp.txt para LastTime.txt. Isso registra o carimbo de data/hora atual capturado anteriormente no arquivo a ser usado para a próxima execução de tarefa.
Converter.scl
Este bloco de transformação usa current.txt e converte para changes.csv . A conversão é do tipo de arquivo delimitado padrão para CSV. O uso do tipo de processo CSV no CoSort precede uma linha de cabeçalho no arquivo de saída usando os nomes dos campos. Este é o bloco de tarefas em que posso aplicar outras manipulações (como mascaramento de dados) aos dados, se desejar.
Arquivos de espera
Este bloco de espera paralisa o arquivo de lote por 3 segundos e então verifica a existência do changes.csv arquivo antes de prosseguir.
MongoImport
Este bloco de comando executa o comando mongoimport usando os parâmetros especificados na visualização de propriedades conforme mostrado abaixo.
Os parâmetros indicam que o banco de dados MongoDB chamado fnx deve ser carregado com o conteúdo do arquivo changes.csv que é do tipo csv e contém um título que define os campos.
Observe que o Voracity suporta outros métodos de movimentação e manipulação de dados do MongoDB. Veja este exemplo de uso de drivers Progress ODBC para mascaramento de dados usando funções “FieldShield” integradas. Voracity também pode processar dados BSON diretamente via API através do suporte /PROCESS=MongoDB no CoSort v10, agora também.
Erro ao carregar
Este bloco de decisão verifica a variável ERRORLEVEL para ter certeza de que retornou 0 (ou sucesso) após a importação para o MongoDB. Caso contrário, o trabalho continua para as Delete-Changes e SAÍDA blocos onde o trabalho é finalizado. Se retornar verdadeiro, o trabalho continua para o próximo bloco.
Truncar atual
Este bloco de comando trunca o arquivo current.txt . Isso é para limpar os registros que foram carregados no MongoDB. Se a importação falhou e o bloco acima saiu do trabalho, esses registros alterados serão anexados na próxima passagem. Então, conforme o trabalho se repetisse, eles seriam carregados no MongoDB com o próximo grupo de registros alterados.
Excluir alterações
Este bloco de comando exclui changes.csv para que a próxima passagem seja iniciada com um arquivo recém-criado para a passagem.
Arquivo em lote
O arquivo em lote e os scripts de transformação são criados quando o diagrama de fluxo é exportado. Uma cópia do arquivo em lote está abaixo. Cada bloco adiciona linhas executáveis ao arquivo de lote.
Agendador de Tarefas
Usando o Agendador de Tarefas do Windows, esse arquivo em lotes pode ser executado repetidamente para capturar as alterações no banco de dados de origem.
Conclusão
Com um pouco de planejamento e o uso de blocos de comando, as alterações em uma tabela de banco de dados podem ser detectadas automaticamente usando um arquivo em lote e, em seguida, agendadas para execução em intervalos selecionados.
Entre em contato com [email protected] ou seu representante IRI para obter mais informações ou ajuda com seu caso de uso
- Esta abordagem difere das soluções de captura de dados de alterações baseadas em log, que normalmente têm gargalos de desempenho e são limitadas a bancos de dados específicos e não permitem a transformação simultânea de dados, mascaramento de dados PII, limpeza e relatórios.
