Testar linhas de montagem de dados

1) Por que testar as linhas de montagem de dados

• Veracidade (corretness) e estabilidade (resilience).
• Previsibilidade de mudanças (schema/logic evolution).
• Cumprimento do SLO por frescura, cumplicidade, latência.
• Edição rápida (velocidade de lançamento) através de verificação automatizada.

2) Pirâmide de testes de dados

De baixo para cima: muitos testes locais rápidos → menos → de integração um pouco end-to-end.

1. Testes unit de transformação (funções, UDF, vistas SQL, modelos dbt).
2. Testes de qualidade de dados (regras de frescura/completa/exclusividade/faixa).
3. Contratos e esquemas (schema/contracto, evolução).
4. Testes de integração de pipline (DAG: ingest ↔ armazenamento ↔ ↔ marts).
5. Testes E2E (da fonte à vitrine/API), incluindo direitos (RLS/CLS) e exportação.
6. Carga/desempenho (volume, velocidade, custo-to-serve).
7. Testes de dados de caos (atrasos, duplicados, out-of-order, indisponibilidade).

3) Tipos de testes: exatamente o que verificamos

3. 1 Testes de lógica unit

Funções limpas de transformação; property-based (invariantes: idempotidade, monotonia).
SQL/DBT: comparação do resultado com a referência (golden set), proibição de 'SELECT', verificação do filtro na hora.

3. 2 Testes de Qualidade de Dados (DQ)

Frescura, atrasos nas vitrines ≤ do limite de destino.
Total: quantidade/proporção de preenchimento prevista.
Exclusividade: chaves sem duplicação.
Regras de domínio - faixas, integridade arbitral, invariantes de negócios.
Anomalias: outliers, saltos duplicados, quebras de tempo.

3. 3 Contratos e esquemas

Compatibilidade de alterações (SemVer: MAJOR/MENOR/PATCH).
Colunas, tipos, limitações obrigatórias.
Semânticos KPI fixados: fórmulas e janelas de agregação.

3. 4 Integração e E2E

Integridade DAG: desencadeadores, dependências, repetição idumpotente.
Caminho completo: origem → raw → curated → marts → BI/API; RLS/CLS.

3. 5 Produtividade e custos

p95/p99 latência de jobs, throughput (rows/s), volume/custo.
Testes de regressão de desempenho e limites de scan.

3. 6 Segurança e privacidade

Camuflagem PII/PCI (Toquenização Detectada).
Verificação RLS/CLS: Os usuários só veem o seu.
Exportação/Snepshots: não há campos pessoais crus.

4) Especificidades de streaming (Kafka/Flink/Spark Estrutured Streaming)

Watermarks e lateness: testes de janelas com eventos atrasados (T + B), repasses corretos.
Exactly-once por sentido: deadup por 'event _ id', entrada idumpotente (upsert/merge).
Out-of-order: invariantes para agregados por 'event _ time'; registramos 'ingested _ at'.
Perda/repetição: Simulamos o drop/reigra das partituras, verificamos a correção das vitrines.

5) Idempotidade e determinismo (o que e como testar)

A reativação da etapa produz o mesmo resultado (com parâmetros de janela idênticos).
Gravar - através de estaging e atomic swap.
A lógica merge com SCD1/SCD2 é coberta por testes de conflito (last-write-wins, fonte priority).
Determinação UDF/equipamentos: entradas iguais → saídas idênticas.

6) Gerenciamento de dados de teste

Golden datasets: pequenas referências com validação manual.
Sintética + fábrica de dados: revestimento de bordas de domínio (nulls, extreme values, unicode, TZ).
Os prod-sample identificados são compatíveis com a privacidade.
Ficstures camadas: eventos crus, camadas intermediárias, vitrines finais.

7) Contratos de dados: exemplo e regras

yaml dataset: orders schema:
- name: order_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: event_time; type: timestamp; tz: UTC freshness_sla: 10m dq_rules:
- "pct_null(user_id) < 0. 1%"
- "duplicates(order_id) = 0"
- "sum(amount) >= 0"
evolution:
allowed_minor_additions: true breaking_changes_require: approval: 'data-governance'
actions_on_violation:
- quarantine_partition
- replay_last_60m

8) Observabilidade e testes SLO

Exportação de métricas: Freshness, Completeness, Uniqueness, Latency para Grafana/Prometheus.
Alertas SLO como testes de unit «vermelhos» (Synthetics).
«Após o lançamento do X p95, 40% ↑».

9) CI/CD e ambientes

CI: unit + DQ + contratos de PR; schema-diff; análise estática do SQL (linter).
Banco de areia/estaging: teste de integração e e2e, testes de caos com dados seguros.
Função-flags: jobs canários/modelos/fórmulas.
Catalogação: versão de circuitos, fórmulas KPI, lineage; atualização automática da documentação.

10) Teste de dados em caos (Chaos-Data)

Injeção de duplicação/omissão, atrasos, out-of-order.
Queda do corretor/partição, arquivos «batidos», schema drivt.
Valemos: conserto automático (replay/backfill), quarantine e alertas, MTTR-data.

11) Carga e custo

Geradores de tráfego com perfil p95/pico.
Limites por scan/passo (bytes scanned, time caps).
A/B Perfilador de valor: «antigo» vs «novo» modelo/consulta.

12) Ferramentas (turmas de teste)

DQ/Contratos: dbt tests, Great Exposations, Deeqaq, Soda, Custom linters.
Orquestra: Airflow/Dagster/Argo/Preferect (operadores para testes em cada etapa).
Plataformas: BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.
Streaming: Kafka, Flink, Spark Streaming; TestContainers para ambientes locais.
Observability: Prometheus/Grafana/Otel; diretórios de DataHub/Amundsen/Collibra.

13) Antipattern

«Não há nada para testar é apenas SQL»: não há units ou DQ → as métricas quebram.
Apenas E2E: lenta, instável, as causas das avarias não estão claras.
SELECT: Quebra em uma evolução MENOR.
Leitura ao vivo do OLTP em testes: instabilidade e flocos.
Sem conjunto golden, não há como comparar os resultados.
Sem testes de Idempotação, a reativação estraga os dados.
Não é testado lateness/out-of-order/reaproveitamento.

14) Mapa de trânsito de implementação

1. Base: testes de transformação unit, kit golden, linter SQL, regras DQ top-10 vitrines.
2. Contratos: schema-diff em CI, SemVer, verificações automáticas de compatibilidade.
3. Integração: testes DAG, idempotency, e2e para fluxos críticos.
4. Streaming: testes watermarks/lateness, dedup/idempotent sinks.
5. SLO e caos: métricas de qualidade na venda, alertas, cenários de caos, objetivos MTTR.
6. Otimização: perf regressão, orçamento-guard, canários.

15) Folha de cheque antes do lançamento

• Os testes unit cobrem transformações essenciais e UDF.
• As regras DQ para frescura/completa/exclusividade/faixa passam.
• Contratos e schema-diff verdes; Não há alterações erradas sem apetrechos.
• A idempotidade foi testada; atomic sink/merge funciona.
• Streaming: watermarks/late data/out-of-order cobertos; dedup no local.
• As métricas SLO são expostas; As alertas estão configuradas; runbooks tem.
• Dados de teste são seguros; PII camuflados; RLS/CLS foram testados.
• Não há regressão perf; os limites de scan/hora foram cumpridos.
• Testes de caos de cenários básicos foram concluídos; O MTTR-alvo é alcançável.

16) Exemplos de mini-modelos

16. 1 Teste SQL unit (pseudo-dbt):

sql
-- tests/assert_positive_amount. sql select count() as c from {{ ref('fct_payments') }}
where amount < 0 having c = 0

16. 2 Regra de frescura (Great Exportations-Estilo):

yaml expect_table_row_count_to_be_between:
min_value: 1000 mostly: 0. 99 expect_column_values_to_not_be_null:
column: user_id expect_column_values_to_be_unique:
column: txn_id

16. 3 Verificação lateness em striptease (pseudo-código):

python emit(events_out_of_window <= threshold)
emit(reprocessed_events == late_events_detected)

16. 4 Contract-test (schema-diff CI):

bash schema-diff --current models/orders. yml --target prod_schema. yml --semver

17) Resultado

Testar linhas de montagem de dados é uma disciplina do sistema, não um conjunto de verificações separadas. Junte a pirâmide de testes, contratos e observabilidade com práticas de idempotação, evolução de circuitos e invariantes de streaming. Os comunicados serão rápidos, os incidentes raros e curtos, e a credibilidade dos dados, sustentáveis.