DVARINT1-14507 - Overlord - Expurgo do Conteúdo da Fila Após Processamento e Armazenamento em Bucket (Histórico)

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Eliminar a duplicidade de armazenamento do conteúdo dos dados processados no CommerceHub, liberando espaço no banco da fila após o processamento e garantindo a preservação do histórico no bucket de forma segura, eficiente e com melhor custo-benefício.

03. SOLUÇÃO

• 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 execução as seguintes:
  • 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 é 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 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.

AppSettings

• O tempo de execução do Job é definido através da variável "Hangfire:SchedulerFazerBackupDadosFilaAsync";
• O nome do bucket no qual os dados serão salvos é definido através da variável: "JobBackupFila:Bucketname". O nome utilizado é "dev-backup-dados-fila" no ambiente de DEV.
  • Deve-se solicitar a criação do bucket para os demais ambientes (QA, STG e PRD), de preferência com uma data para expurgo automático dos dados.  

Estrutura dos Arquivos

No bucket, a estrutura de pastas tem a seguinte hierarquia: ano/mês/dia/arquivo.json

Já os arquivos tem o seguinte padrão: idInquilino_{X}_yyyyMMddHHmmss_{Guid}_{PartNumber}.json
Ex: 2025/12/11/idInquilino_15_20251208091220215_596031ae7eb24d029bd7ab0b1ab3033c_001.json

Obs.: O PartNumber representa o indice do dado dentro do lote de dados. Como dito antes, arquivos maiores que 1GB são didividos em blocos menores, cada bloco de dado recebe um número que se inicia em 1,
este valor é o PartNumber.

Funcionamento e Métricas

Para direcionar o desenvolvimento, foi consutado a quantidade de dados gerados em dia na V3 em Produção. Levou-se em consideração os dados mais comuns e que geram mais volume, sendo eles:
Cliente, Preço. Produto e Venda. Chegou-se aos seguintes dados: 

Com o intuito de validar a solução, nos testes, foram utilizados valores superiores aos mostrados acima. Os testes foram feitos com Produto e Venda, que são dados mais volumosos. Seguem os resultados:

Obs.: O dados em Lote são dados que possuem mais de um item por registro no banco. Produto por exemplo, possui mil registros, 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 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.

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 fornecida pelo Google, porém, seria necessário o desenvolvimento 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. Abaixo segue um scrip shell que faz exatamente essa função, de dividir os arquivos em partes de até 100MB. 

split_json.sh 

Para utililiza-lo, basta abri-lo em um editor de texto, colocar o caminho do arquivo na variável "INPUT_FILE", abrir o Terminal/CMD e executar o script. O único 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".