Reduz o uso de memória na geração e exportação de métricas diárias

[pitangainnovare]

O que esse PR faz?

Reduz o pico de memória da geração e da exportação das métricas diárias, especialmente para logs grandes da coleção SCL.

• torna o acumulador compacto o único caminho de acumulação;
• converte as granularidades mensal e anual sequencialmente, liberando estruturas intermediárias;
• grava o payload JSON e calcula seu SHA-256 de forma incremental, preservando exatamente o formato canônico;
• percorre o payload persistido com ijson, sem carregar o arquivo completo na memória;
• envia documentos ao OpenSearch em lotes limitados e com compressão HTTP;
• permite retomar somente a exportação quando o payload já está persistido;
• registra duração, quantidade de documentos e pico de memória das etapas;
• atualiza a versão da aplicação para 2.3.3.

Não há alteração de mappings, métricas COUNTER, identificadores, payload canônico ou regras de deduplicação.

Onde a revisão poderia começar?

A revisão pode começar por metrics/services/parsing/job_payloads.py, que coordena conversão, liberação de memória e serialização. Em seguida:

• metrics/services/daily_payloads.py: escrita e leitura incremental;
• metrics/services/export.py: exportação por granularidade;
• metrics/opensearch/client.py: lotes e compressão HTTP;
• metrics/counter/access/daily_accumulator.py: consumo progressivo do acumulador.

Como este poderia ser testado manualmente?

Executar no Docker:

docker compose -p usage -f local.yml run --rm django pytest metrics/tests -q

docker compose -p usage -f local.yml run --rm django \
  pytest \
    metrics/tests/integration/test_books_log_to_metrics.py \
    metrics/tests/integration/test_classic_log_to_metrics.py \
    metrics/tests/integration/test_bunnynet_log_to_metrics.py \
    -q

docker compose -p usage -f local.yml run --rm django \
  python manage.py makemigrations --check --dry-run

Resultados locais:

• suíte de métricas: 138 passed, 2 skipped;
• integrações Books, PRT e SCL: 17 passed, 2 skipped;
• nenhuma migration detectada;
• payload SCL completo idêntico byte a byte ao da v2.3.2, com SHA-256 1da947e9db472e08292fcac3dbd0fd9b557efd653bf47bac6dd7a0e5cbf99bc1;
• payloads PRT e Books também idênticos byte a byte aos da v2.3.2;
• pico do SCL completo reduzido de 6931,1 MiB para 5568,4 MiB, sem regressão relevante de tempo;
• compressão do lote de teste reduziu o tráfego de 1.381.500 para 13.946 bytes.

Algum cenário de contexto que queira dar?

O processamento de um log SCL com milhões de linhas chegou a pressionar o limite de memória do worker de HML. Embora o parsing já utilizasse registros compactos, a conversão, a serialização e a exportação ainda podiam manter estruturas mensais, anuais ou o payload completo simultaneamente na memória. Este PR torna essas etapas incrementais e retomáveis, reduzindo o risco de reinício do worker sem alterar os dados finais enviados ao OpenSearch.

Screenshots

Não aplicável. A alteração é interna ao pipeline de processamento.

Quais são os tickets relevantes?

Relacionado a #128.

Referências

• OpenSearch Python client: https://docs.opensearch.org/latest/clients/python-low-level/
• ijson: https://github.com/ICRAR/ijson

---

Segurança da informação (NSI.04)

Seção obrigatória. Marque as opções aplicáveis e justifique quando necessário. Referência: NSI.04 - Norma de Desenvolvimento Seguro.

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — o pipeline já processa endereços IP dos logs de acesso de forma transitória. A alteração não cria nova persistência, exposição ou registro desses dados e preserva o payload existente.
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — descreva o que mudou e por quê:
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — adiciona ijson==3.5.1 para leitura incremental dos payloads.
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa: validação pelo SBOM/Trivy do pipeline do PR.
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique): pendente dos checks executados após a abertura do PR.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)