basedosdados / basedosdados/pipelines

[bug] br_ms_cnes: range de partição curto demais em 12 modelos

Open
#1,720 0 comments 0 reactions 1 assignee Claimed by @DaviMacielCavalcante View on GitHub
bug update
Dominant language
Python
Stars
49
Forks
22
Avg merge
1d 3h
Merged PRs (30d)
167

Description

Os modelos do `br_ms_cnes` declaram um fim de range de partição menor que a cobertura dos
dados: `"end": 2024` na maioria e `"end": 2026` no `profissional`, com dados indo até 2026.

O fim do range é exclusivo no particionamento por inteiro do BigQuery — linhas fora de
`[start, end)` vão para a partição `__UNPARTITIONED__`. Com `end: 2024`, três anos de dados
estão num único bucket e filtrar por `ano` não poda nada nesse intervalo. Pela convenção da
BD (`end = último ano + 5`), o valor certo é 2031.

**Alterar o config não reparticiona.** O particionamento é definido na criação da tabela,
então cada tabela precisa de `--full-refresh`. O dbt não acusa a divergência enquanto isso
não acontece: `dbt run --select br_ms_cnes__incentivos` passou normalmente com o config
novo e a tabela antiga.

O `equipamento` já foi corrigido na #1714, aproveitando o full-refresh que a coluna
`codigo_equipamento` exigia.

## Tabelas

- [x] `equipamento` — 142.401.603 linhas, 8,9 GB (feito na #1714)
- [ ] `estabelecimento_ensino` — 26.689 linhas, 3,0 MB
- [ ] `estabelecimento_filantropico` — 150.373 linhas, 15,6 MB
- [ ] `gestao_metas` — 144.344 linhas, 16,2 MB
- [ ] `incentivos` — 1.021.672 linhas, 112,6 MB
- [ ] `habilitacao` — 4.329.310 linhas, 509,6 MB
- [ ] `leito` — 11.107.871 linhas, 726,0 MB
- [ ] `dados_complementares` — 2.679.693 linhas, 1,7 GB
- [ ] `equipe` — 12.552.254 linhas, 2,4 GB
- [ ] `servico_especializado` — 135.737.934 linhas, 12,1 GB
- [ ] `estabelecimento` — 64.031.459 linhas, 85,5 GB
- [ ] `profissional` — 799.627.847 linhas, 136,3 GB

Total de 248 GB e 1,17 bilhão de linhas, dos quais `estabelecimento` e `profissional`
somam 222 GB. O processamento é maior que esses números, porque o modelo faz
`select distinct *` sobre o staging antes de gravar.

**`regra_contratual` ficou de fora.** A tabela está desativada: o crawler falha na leitura
do CSV desde pelo menos 2026-05 e a #1703 foi fechada como `NOT_PLANNED`. Não há ganho em
reparticionar dado que não cresce mais. `estabelecimento_ensino` está parada desde 2019-12
com o grupo EE descontinuado, e o ganho nela também é nulo, mas custa 3 MB e entrou junto.

## O que fazer

1. Trocar `"end"` para 2031 nos 11 `.sql` restantes.
2. Reconstruir cada tabela. Em produção, o `table-approve` não passa `--full-refresh`,
então é um disparo manual do deployment de dbt por tabela:

```bash
prefect deployment run "BD template: Executa DBT model/run_dbt_model_flow" \
-p dataset_id=br_ms_cnes -p table_id= -p dbt_command=run \
-p flags=--full-refresh -p target=prod -p dbt_alias=true
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.