Este artefato constitui a camada inicial de dados do BuscaCNPJ: converte arquivos públicos heterogêneos em um repositório relacional verificável e adequado à exploração analítica. O fluxo emprega transferência por streaming[1], processamento em lotes[2], carga bulk com PostgreSQL COPY[3] e checkpoints por tabela[4].
A publicação periódica exige controlar falhas parciais, arquivos corrompidos, codificações legadas, pressão de memória, indisponibilidade de rede e divergências entre origem e destino. Uma falha silenciosa pode produzir um banco aparentemente disponível, porém incompleto.
Contribuição tecnológica
O pipeline transforma a atualização mensal em um processo observável e parcialmente retomável, separando aquisição, preparação, publicação e validação. Essa separação permite medir cada etapa, reproduzir falhas e comparar estratégias de implementação.
A arquitetura utiliza persistência intermediária para desacoplar a instabilidade da fonte pública da publicação na VPS. O SQLite atua como representação portátil da competência processada; o PostgreSQL recebe as tabelas por carga bulk e sustenta a aplicação analítica.
Da fonte pública ao produto analítico em produção
flowchart TB
subgraph O["Origem pública"]
W["Repositório WebDAV"]
Z["Arquivos ZIP por entidade"]
end
subgraph L["Processamento local controlado"]
D["Download por streaming"]
E["Validação e extração"]
N["Normalização em blocos"]
S[("SQLite da competência")]
end
subgraph P["Publicação na VPS"]
C["COPY em lotes"]
PG[("PostgreSQL")]
I["Índices e ANALYZE"]
end
subgraph V["Verificação e consumo"]
R["Reconciliação"]
J["Snapshot JSON"]
B["BuscaCNPJ"]
end
W --> Z --> D --> E --> N --> S
S --> C --> PG --> I --> R
R --> J
R --> B
Use “Ampliar” para abrir o diagrama em tela inteira e controlar o zoom.
Sessão HTTP com retries para falhas transitórias, timeout explícito e gravação sequencial em blocos de 1 MiB.
Leitura tabular em chunks de 200 mil linhas, tipagem conservadora como texto e persistência intermediária por entidade.
Serialização tabular em memória limitada, PostgreSQL COPY, checkpoints, índices concorrentes e atualização do otimizador.
Critérios para avanço, repetição e conclusão
stateDiagram-v2 [*] --> Descobrindo Descobrindo --> Baixando: arquivos identificados Baixando --> Validando: arquivo temporário concluído Validando --> Extraindo: ZIP íntegro Validando --> Falha: arquivo inválido Extraindo --> Consolidando Consolidando --> Publicando: SQLite concluído Publicando --> Publicando: próximo lote Publicando --> Retomável: conexão interrompida Retomável --> Publicando: reconexão Publicando --> Verificando: tabelas carregadas Verificando --> Concluído: reconciliação aceita Verificando --> Falha: divergência detectada Concluído --> [*] Falha --> [*]
A complexidade espacial é controlada pelo tamanho do lote, e não pelo volume total da base. Em termos práticos, o processo mantém apenas uma fração dos registros em memória durante cada fase.
PARA cada entidade da fonte: criar tabela intermediária PARA cada arquivo da entidade: ENQUANTO houver registros: bloco ← ler até 200.000 linhas normalizar nomes e codificação anexar bloco à tabela SQLite registrar quantidade processada
O limite do bloco estabiliza o uso de RAM e permite processar volumes maiores que a memória disponível.
PARA cada tabela intermediária: SE checkpoint válido existir: pular tabela recriar estrutura de destino ENQUANTO houver registros: lote ← buscar 20.000 linhas executar COPY(lote) confirmar transação medir vazão e estimar ETA gravar checkpoint em load_status criar índices e executar ANALYZE
A unidade atual de retomada é a tabela concluída; lotes internos ainda não são checkpoints duráveis.
O(b), sendo b o tamanho máximo do bloco em memória.
O(n) para leitura e transferência dos registros.
Percentual, linhas/s, duração e ETA por tabela.
Reexecução controlada por competência e estado de carga.
O pipeline separa término de processamento de aceitação da carga. Após a publicação, são coletadas quantidades por tabela, metadados, amostras e a competência efetivamente carregada.
| Camada | Controle Aplicado |
|---|---|
| Download | Arquivo temporário, timeout e retries HTTP. |
| Arquivo | Reconhecimento ZIP e teste de CRC. |
| Consolidação | Contagem acumulada e erro explícito por entidade. |
| Publicação | Commit por lote e estado final por tabela. |
| Banco | Contagem, esquema e amostra controlada. |
| Operação | Snapshot JSON com competência e instante da carga. |
Rastreabilidade entre origem, intermediário e destino
flowchart LR A["Arquivo de origem"] -->|"nome, tamanho, competência"| B["Tabela SQLite"] B -->|"contagem por entidade"| C["Tabela PostgreSQL"] C -->|"COUNT, esquema, amostra"| D["Relatório de validação"] D -->|"estado aceito"| E["Snapshot publicado"]
Este pipeline não é apresentado como um ETL genérico isolado. Ele constitui a infraestrutura experimental que torna possível o BuscaCNPJ e fornece um objeto empírico para pesquisas sobre ingestão reprodutível de dados públicos em larga escala.
O artefato permite testar como tamanhos de lote, mecanismos de persistência intermediária, índices e estratégias de retomada afetam tempo, memória, I/O[5], consistência e disponibilidade do dado publicado.
Existe uma faixa de tamanho de lote que maximiza vazão sem crescimento proporcional da memória.
A camada intermediária reduz o acoplamento operacional, mas acrescenta custo mensurável de I/O.
Checkpoints mais granulares reduzem retrabalho após falhas, com custo adicional de controle transacional.
Mestre em Modelagem Computacional de Sistemas
Professor do IFTO
Advogado — OAB/TO 11.673
Tecnologia e Inovação — AGU