Histórico da Página

...

• Foi criado um Job recorrente no projeto de Hangfire chamado: FazerBackupDadosFilaAsync que buscar os dados no banco, faz o upload dos mesmo para o GCS e deleta os arquivos. As regras de secução são execução as seguitnesseguintes:
  • Roda Job é executado todo dia de 1 à 5:59 da manhã, dessa forma evita a concorrência com os demais serviços que rodam durante o dia;
  • Primeiro é obitodo a obtido uma lista de Inquilinos que possuem dados com status "Enviado para MS Responsável" (5); Depois:
  • Obtem todos os dados com status igual ou superior a "Enviado para MS Responsável" (5);
  • Os dados são obtidos de forma páginada, sendo 800 registro por vez e aplicando aplicandos os filtros de status, inquilino e data de cadastro;
  • O job trabalha com um range de datas;
    • A data de início é a data de cadastro do dado mais antigo com o status citado, e a data de fim é a data anterior a data de execução do job;
  • Além de paginar os dados ao consultar o banco, o job calcula uma média de tamanho dos dados, e caso estes sejam superior a 1GB, esses dados são dividos em bloco menores;
  • O Upload é feito em stream, e primeiro salva os dados em um arquivo temporário, e realiza o stream para o GCS. Com esta abordagem, o consumo de memória é drasticamente reduzido;
• O RTS foi alterado para mudar o status dos dados para  5 após o envio com sucesso para o MS Reponsável.
  • Isso já ocorria no fluxo com Workflow, e foi replicado na fluxo comum.

...

Obs.: O dados em Lote são dados que possuem mais de um item por registro no banco. Produto por exemplo, possui mil registroregistros, logo, são 153 (ou 454) linhas no banco, mas que totalizam 153 (ou 454) mil itens que serão salvos no Dado Dinâmico.
Venda possui um lote de 146 itens, e mil linhas/registros no banco , logo foram 146 mil vendas processadas no teste.

Ao londo longo do desenvolvimento, diversas melhorias foram realizadas. No modelo final, com otimizações principalmente no uso de memória, conseguiu-se processar todos os dados do banco (4.54GB) em 12min.
Vale ressaltar que o maior ofensor da ferramenta é o uso de memória. Para processar todo o banco (4.54GB), a aplicação chegou a utilizar 7.7GB de memória RAM. Após o termino do processamento, esse número baixou para 1.1GB, sendo que parte desse 
valor, se da pelo fato da aplicação deixar a memória reservado, ou seja, ela não está sendo usada de fato, o que não onera o uso por outras aplicações que estejam rodando da máquina.

Consultados Consulta dos Dados

Os dados podem ser consultados diretamente no GCS, seguindo a estrutura estabelecida é possível via filtro da plataforma, localizar os dados de um inquilino em uma determinada data.
Também é possível consutar os dados através da Lib .Net fornecidade fornecida pelo Google, porém, seria necessário o desenvolvimento essa dessa funcionalidade. 

Com relação a análise dos dados gerados, percebe-se que pode haver algumas dificuldades, visto que os arquivos normalmente terão um grande volume de dados (até 1GB). Pensando nisso, remomenda-se criar uma ferramenta capaz de "dividir" os arquivos em arquivos menores, dessa forma, a leitura dos mesmos se torna mais fluida. Se em anexo Abaixo segue um scrip shell que faz exatamente essa função, e divido o de dividir os arquivos em partes de até 100MB. 

...

Para utililiza-lo, basta abri-lo em um editor de texto, colocar o caminho do arquivo na variável "INPUT_FILE" e , abrir o Terminal/CMD e executar o script. O único requirimento requerimento é que a máquina tenha o Python3 instalado.

Os arquivos serão salvos na mesma pasta dos arquivos originais com o sufixo: "_output_0001".