Execução de sincronização de fascículo para o Kernel com todos os pacotes SPS de um processamento

[patymori]

Descrição da nova funcionalidade

Eu, como Operador da nova plataforma SPF, gostaria que a execução e reexecução de sincronização de um fascículo para o Kernel com todos os pacotes SPS daquele processamento, então será possível garantir a execução e reexecução da sincronização de todos os pacotes do fascículo, caso haja falhas.

Critérios de aceitação

• A ordem da data dos pacotes deve ser preservada para evitar a regressão de conteúdos
• Deve manter a ordem cronológica dos pacotes do fascículo
• Deve reexecutar somente a sincronização de um determinado fascículo

Anexos

n/a

Referências

.

[patymori]

Proposta de Solução

A nova DAG fará a sincronização por bundle, mantendo a ordem de todos os pacotes relacionados, para garantir que não haja regressão nos dados sincronizados com o Kernel. Dessa forma, também se torna possível efetuar a sincronização dos bundles de forma paralela.

A navegação da DAG ficaria dessa forma:

1. DAG principal Ficará responsável por mover os pacotes de SPS para o diretório PROC do Airflow, organizar os pacotes por bundle e iniciar a a SubDag de sincronização

2. SubDag sync_documents Responsável por iniciar a sincronização para cada bundle

3. SubDag do Bundle Responsável por executar a sincronização de cada pacote do bundle, respeitando a ordem dos pacotes

4. SubDag do Pacote Responsável por executar as tarefas de sincronização do pacote, as mesmas executadas pela DAG sync_documents_to_kernel

Pontos a considerar

• Por se tratar de uma mudança que alterará a forma de execução das tarefas da DAG sync_documents_to_kernel, impossibilitando a reexecução da sincronização de pacotes que já ocorreram, propõe-se manté-la e criar uma nova que efetue a nova forma de sincronização dos pacotes.
• Com a reestruturação, não só a DAG de sincronização terá quebra de compatibilidade mas também é possível que ajustes no dashboard do Grafana, usado para o acompanhamento das sincronizações, sejam necessários
• A navegação tem mais camadas do que a anterior, fazendo com que a navegação entre as execuções de tarefas não sejam tão simples.

[robertatakenaka]

@patymori não estou identificando nenhum problema nesta proposta. Então, acho que pode seguir.

[joffilyfe]

@patymori eu gostei da sua proposta de solução. Você avaliou outras formas de implementação que pudessem manter a compatibilidade entre execuções e também entre o nosso ecossistema de monitoramento?

[patymori]

Conversando com @joffilyfe e @jamilatta, uma outra abordagem foi apresentada: mais simples e sem quebra de compatibilidade com as integrações. As DAGs existentes seriam preservadas e a mudança para a sincronização seria na estrutura dos dados no XCom, fazendo com que a DAG sync_documentos_to_kernel passe a fazer a sincronização de n pacotes para um mesmo bundle, e que cada uma das tarefas seria adaptada para lidar com esta estrutura, mantendo a ordem da sincronização dos pacotes como hoje.

As estruturas de dados pensadas ficariam desta forma:

sps_packages = [
    {"rba-v1n1": ["rba-1-1-1.zip", "rba-1-1-2.zip", "rba-1-1-3.zip"]},
    {"rba-v1n2": ["rba-1-2-1.zip", "rba-1-2-2.zip"]},
    {"bjb-v1n1": ["bjb-1-1-1.zip", "bjb-1-1-2.zip", "bjb-1-1-3.zip", "bjb-1-1-4.zip"]}
    {"bjb-v1n2": ["bjb-1-2-1.zip"]}
]

xmls_to_preserve = [
    {"rba-1-1-1.zip": ["document-1.xml", "document-2.xml"]},
    {"rba-1-1-2.zip": ["document-2.xml"]},
    {"rba-1-1-3.zip": ["document-1.xml", "document-2.xml", "document-3.xml"]}
]

Vantagem:

• Resolve o problema colocado, sendo mais simples de implementar e mantendo a simplicidade na visualização da interface no Airflow
• Não há quebra de compatibilidade de software, tanto internamente quanto entre integrações existentes

Desvantagens:

• Há um menor controle no Airflow na reexecução da sincronização dos pacotes para um bundle em um fluxo de publicação, tendo consumo de processamento, em alguns casos, desnecessário

Vantagens da primeira proposta:

• A organização diferente possibilita ter um maior controle na reexecução de sincronizações

Desvantagens:

• Será preciso manter as DAGs atuais para reexecuções feitas anteriormente a implantação dessa proposta
• Na visualização dos Artigos processados por pacote no dashboard do Grafana, ao clicar no pacote, seria exibido no Airflow algo como esse resultado:

Por favor, verifiquem se não esqueci de mais nada.

[joffilyfe]

@patymori eu acho que você pode seguir com a proposta. Talvez nós só tenhamos que alterar a URL no grafana para que a abertura da DAG funcione.

[patymori]

@patymori eu acho que você pode seguir com a proposta. Talvez nós só tenhamos que alterar a URL no grafana para que a abertura da DAG funcione.

@joffilyfe e sobre a quebra de compatibilidade com as sincronizações anteriores? Acha que as vantagens da proposta são maiores do que a desvantagem de ter que manter as DAGs atuais?

[joffilyfe]

@patymori eu acho que você pode seguir com a proposta. Talvez nós só tenhamos que alterar a URL no grafana para que a abertura da DAG funcione.

@joffilyfe e sobre a quebra de compatibilidade com as sincronizações anteriores? Acha que as vantagens da proposta são maiores do que a desvantagem de ter que manter as DAGs atuais?

Nós só precisaríamos manter a dag atual por algum tempo, nós temos pouco mais de um dois meses de processamento, nem é algo tão relevante assim. Portanto eu acho que as vantagens são maiores sim.

[jamilatta]

@patymori e @joffilyfe concordo com a solução e acho que ficou mais fácil a implementação

Mas em caso de falha no processamento de alguns dos XMLs toda a DAG falhará?

[patymori]

@patymori e @joffilyfe concordo com a solução e acho que ficou mais fácil a implementação

Mas em caso de falha no processamento de alguns dos XMLs toda a DAG falhará?

@jamilatta, não sei se entendi qual das soluções você concorda. Pode deixar explícito se é a primeira ou a segunda proposta?

O tratamento para a falha na sincronização dos documentos de um pacote continuaria da mesma forma que agora, isso não seria alterado.

[jamilatta]

@patymori

Irei ler novamente para te dá um parecer mais elaborado!

[patymori]

Proposta 3 de solução

• Criação de novas DAGs de sincronização:

  1. Coleta dos pacotes SPS pela scilista
  2. Extração das informações dos pacotes SPS
  3. Sincronização dos documentos para o Kernel e o MinIO

• Permanência das DAGs existentes para manter as sincronizações já realizadas

• Alteração da DAG sync_isis_to_kernel para envio do Gerapadrao ID via trigger para a DAG de coleta dos pacotes SPS

Coleta dos pacotes SPS pela scilista

Similar à pre_sync_documents_to_kernel, com a diferença de que organiza os pacotes por bundles e inicia DAGs para a extração das informações por bundles com os respectivos pacotes

Extração das informações dos pacotes SPS

Armazena as informações de todos os documentos necessárias para fazer a leitura nos pacotes, mantendo a ordenação dos pacotes, e a sincronização com o Kernel e Minio. Uma informação adicional é a operação a ser realizada: deleção ou registro/atualização.

Sincronização dos documentos para o Kernel e o MinIO

Responsável por deletar ou carregar os documentos no Kernel e no MinIO através dos dados extraídos e por documento. Realizará a operação identificada no XML e a atualização no bundle.

Vantagens

• Dessa forma, será possível paralelizar as leituras por bundles e, caso falhe um pacote, os pacotes seguintes não serão processados
• Será possível paralelizar por documentos e, caso um problema ocorra na realização de uma das operações do documento, as seguintes não serão realizadas
• Teremos um controle por fase: de extração das informações dos pacotes e de carga das informações no Kernel e MinIO, mantendo a idempotência através das informações armazenadas em banco de dados
• É possível manter compatibilidade com a integração entre a base de relatório de processamento no Grafana
• Possibilita alterar o tipo de executor das tarefas do Airflow