Replicação incremental de dados, mascaramento, integração (ETL) e outras operações de atualização de dados são comuns em ambientes de banco de dados de atualização frequente. Esses trabalhos exigem a detecção de adições e atualizações nas tabelas. Essas operações dinâmicas são fáceis de automatizar nos fluxos de trabalho IRI Voracity projetados e executados no IRI Workbench (WB).
Este artigo contém um exemplo de fluxo de trabalho que os usuários da edição Voracity, FieldShield, CoSort ou NextForm DBMS podem implementar para verificar regularmente as alterações em uma tabela de origem (Oracle neste caso) para decidir quando mover dados para um novo destino (MySQL). Ele também mostra como os dados podem ser mascarados condicionalmente como parte desse processo. Observe que o IRI também está trabalhando em uma abordagem baseada em log para incrementar dados em tempo real sem a necessidade de valores de coluna delta.
As alterações podem ser carregadas em diferentes bancos de dados ou arquivos usando um arquivo em lotes agendado por tarefa ou script de shell. Isso pode ser feito usando um carimbo de data/hora e campos específicos na tabela de origem. A verificação de erros também está incluída e também pode ser executada.
Este exemplo foi criado e executado em uma máquina Windows. Ele pode ser facilmente modificado para funcionar em uma plataforma 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 CREATED_DATE e UPDATED_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
- uma regra para redigir e-mails que terminam em "edu" é usada no destino
- uma regra para editar parcialmente o campo SSN é usada no destino
- os dados alterados são carregados no MySQL
- o nível de erro é verificado, o arquivo de carimbo de data/hora temporário é renomeado
Cada bloco de tarefas no fluxo de trabalho é explicado abaixo. Os dois blocos malva são blocos de mapeamento de transformação e representam scripts de trabalho CoSort SortCL. Os diagramas de mapeamento e scripts de trabalho representados por cada um dos blocos são mostrados abaixo para maior clareza. 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.
Este arquivo contém uma linha:“2008-09-10 09:39:23.5”
Timestamp.scl
Esta tarefa usa o programa SortCL 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.
O diagrama de mapeamento e o script serializado para este trabalho são os seguintes:
Alterações.scl
Este trabalho faz a extração principal, transformação, carregamento. A entrada é a tabela de origem no Oracle e a saída é uma tabela formatada de forma semelhante no MySQL:
Na seção de entrada, uma consulta é enviada à tabela de origem para todos os registros que têm um CREATED_DATE ou UPDATED_DATE maior que a variável de ambiente LASTTIME . A consulta é “SELECT * FROM SCOTT.CLIENT WHERE CREATED> TO_TIMESTAMP(\'$LASTTIME\', \'YYYY-MM-DD HH24:MI:SS.FF1\') OR (UPDATED> TO_TIMESTAMP(\'$LASTTIME\ ', \'AAAA-MM-DD HH24:MI:SS.FF1\'))”.
Além disso, uma condição é adicionada para verificar o EMAIL coluna para dados que terminam em “edu”. Isso será usado em uma função de mascaramento de dados condicional na saída. Na saída, um If-Then-Else declaração é adicionada ao EMAIL coluna. Ele usa a condição criada anteriormente para testar os dados. Se os dados terminarem em “edu”, o endereço de e-mail será editado. Caso contrário, o endereço de e-mail é copiado da entrada.
Uma segunda função de redação é usada no SSN coluna. Ele edita os três primeiros caracteres, deixa o travessão, edita os próximos dois caracteres, deixa o travessão e deixa os últimos quatro caracteres. Por exemplo ***-**-6789.
Abaixo está o script de trabalho SortCL serializado descrito acima para que você possa examinar a consulta e a sintaxe condicional envolvida nos deltas incrementais:
Erro CoClassificar
O bloco de decisão verifica a variável ERRORLEVEL para certificar-se de que retornou 0 (para sucesso) após executar o trabalho SortCL acima. Caso contrário, o trabalho continua até o END 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 Último.txt . Isso registra o carimbo de data/hora atual capturado anteriormente no arquivo a ser usado para a próxima execução de tarefa.
Arquivo em lote
O arquivo em lote e os scripts de transformação são criados quando o diagrama de fluxo (mostrado acima) é 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 serem executadas em intervalos selecionados para que você possa mover, mapear, mascarar e manipular dados alterados em um base incremental.
Entre em contato com [email protected] ou com seu representante IRI para obter mais informações ou ajuda com seu caso de uso.
