Qualidade de dados com semântica operacional
Regras de cancelamento, SLA e sequência, além de schema.
- Ingestão
- Testes
- Semântica
- Observabilidade
Competências demonstradas
- Data Quality
- SQL
- Python
- Analytics
- Python
- Pydantic
- SQL
Recorte medido
| Ingestão / schema | 23 falhas |
| Testes | 11 falhas |
| Semântica | 47 falhas |
| Freshness | 6 falhas |
Mock do case. Não é KPI de operação real.
- Alta 28
- Média 41
- Baixa 19
| Alta | 28 ocorrências |
| Média | 41 ocorrências |
| Baixa | 19 ocorrências |
Mesmo recorte da auditoria de delivery.
-
Ingestão
Schema
Por quê / trade-offs
- Por que foi escolhido
- Fail fast na origem: tipo, campo obrigatório, regra local.
- Problema que resolve
- Payload inválido na ingestão se propaga para toda a cadeia.
- Trade-offs
- Validação rígida exige política de quarentena (DLQ), não apenas exception.
-
Testes de qualidade
Regras / expectativas
Por quê / trade-offs
- Por que foi escolhido
- Completude, unicidade, validade e volume depois da carga.
- Problema que resolve
- Schema sozinho não pega duplicata tardia nem quebra de referencial.
- Trade-offs
- Suíte genérica (Great Expectations ou equivalente) cobre a camada 2; regras de negócio ficam no motor de auditoria.
-
Semântica de negócio
Motor de auditoria
Por quê / trade-offs
- Por que foi escolhido
- Flag nomeada, severidade e impacto — qualidade no vocabulário da operação.
- Problema que resolve
- Not-null não indica se o cancelamento depois do preparo gerou desperdício.
- Trade-offs
- Maior custo de desenho de regra; é o que torna o dado acionável.
-
Observabilidade
Flags + tendência
Por quê / trade-offs
- Por que foi escolhido
- Qualidade visível no tempo, por loja e por tipo de falha.
- Problema que resolve
- Dashboard de negócio quebra em silêncio quando o pipeline atrasa.
- Trade-offs
- Flags materializadas no Delivery Audit; painel meta de freshness permanece em planejamento.
Data quality — checks
- schema validation
- null checks
- uniqueness
- freshness
- referential integrity / sequência de eventos
- volume anomaly
01 — Contexto
Qualidade de dados como disciplina de pipeline — não como checklist genérico no fim do job. A implementação de referência está na Delivery Audit Platform: camadas, motor de auditoria e contrato de ocorrência.
02 — Problema
Em sistemas distribuídos o dado atravessa API, arquivo, tabela e dashboard. Cada hop degrada schema, pontualidade e significado.
Sintomas típicos:
- decisão errada porque o número estava correto no tipo e errado no negócio;
- time de operação perde confiança no KPI;
- retrabalho downstream para localizar a linha que quebrou;
- dashboards que só mostram volume.
O problema técnico é contrato. O problema de negócio é confiança.
03 — Arquitetura
Quatro camadas, da mais barata de falhar à mais cara de ignorar:
- validação na ingestão (schema, tipos);
- testes sobre o lote (completude, unicidade, validade);
- regras com semântica operacional (motor de auditoria do Delivery Audit);
- observabilidade (flags no tempo, não só log).
Great Expectations (ou equivalente) encaixa na camada 2. No Delivery Audit, a camada 3 está em regras Python versionadas no repositório.
04 — Stack
- Python — regras e transformações.
- Pydantic — contrato na borda (fail fast). No Delivery Audit o contrato equivalente vive nas camadas e no motor de auditoria.
- SQL — unicidade, integridade referencial e agregações quando o dado já está tabular.
05 — Pipeline
Qualidade acompanha o dado:
- na ingestão, rejeitar ou quarentenar o que não passa no schema;
- em Silver, unicidade e tipos;
- em Gold, grão estável;
- na auditoria, regra de negócio.
Freshness e anomalia de volume fazem parte do desenho. O painel meta dedicado está descrito em Data Health Dashboard.
06 — Modelagem
Qualidade sem grão definido não tem âncora. No Delivery Audit o grão do fato é um pedido. Flags de auditoria referenciam esse grão — unicidade e sequência de eventos passam a ser testáveis.
07 — Data Quality
Dimensões usadas como contrato:
- completude, precisão, consistência, validade, pontualidade, unicidade.
No Delivery Audit isso vira regra nomeada (SLA, cancelamento após preparo, sequência inválida), além de IS NOT NULL.
08 — Observabilidade
A falha precisa ser materializada. Sem registro de flag_type e severity, não há tendência nem priorização por loja ou turno.
09 — Trade-offs
- Regras no case operacional vs. suíte genérica isolada — expectativas sem contexto de negócio priorizam pouco. A qualidade foi aplicada no pipeline de delivery.
- Check genérico vs. regra de negócio — o primeiro é barato e insuficiente para priorizar loja e turno.
- Fail fast vs. carga permissiva — rejeitar na ingestão exige quarentena; aceitar tudo empurra o custo para o dashboard.
10 — Resultado
O Delivery Audit implementa auditoria como camada, com contrato de ocorrência e repositório público.
11 — O que deu errado
A primeira abordagem tratou qualidade como validação genérica (NOT NULL, tipos). Isso não priorizava falha operacional. A correção foi o motor de auditoria: regra nomeada, severidade e impacto estimado, amarrado ao grão do fato.
12 — Código
Implementação: Raphaeldaysc/Delivery-Projeto.