Pruebas de transportadores de datos

1) Por qué probar los transportadores de datos

• Validez (corrección) y estabilidad (resiliencia).
• Previsibilidad de los cambios (evolución schema/logic).
• Cumplimiento de SLO por frescura, plenitud, latencia.
• Liberación rápida (velocidad de lanzamiento) a través de la verificación automatizada.

2) Pirámide de prueba de datos

De abajo hacia arriba: muchas pruebas locales rápidas → menos → de integración un poco end-to-end.

1. Pruebas unitarias de transformación (funciones, UDF, vistas SQL, modelos dbt).
2. Pruebas de calidad de datos (reglas de frescura/plenitud/singularidad/rangos).
3. Contratos y esquemas (pruebas de contrato/schema, evolución).
4. Pruebas de integración de pipeline (DAG: ingest ↔ storage ↔ transformación ↔ marts).
5. Pruebas E2E (de origen a escaparate/API), incluyendo derechos (RLS/CLS) y exportación.
6. Carga/rendimiento (volumen, velocidad, costo-a-servidor).
7. Pruebas de datos de caos (retrasos, duplicados, fuera de orden, inaccesibilidad).

3) Tipos de pruebas: qué comprobamos exactamente

3. 1 Pruebas de lógica unit

Funciones puras de transformación; property-based (invariantes: idempotencia, monotonía).
SQL/DBT: comparación del resultado con la referencia (conjunto dorado), prohibición de 'SELECT', comprobación del filtro en el tiempo.

3. 2 Pruebas de calidad de datos (DQ)

Frescura: retardo de las vitrinas ≤ el umbral objetivo.
Exhaustividad: cantidad/proporción de ocupación esperada.
Singularidad: llaves sin duplicados.
Reglas de dominio: rangos, integridad referencial, invariantes de negocios.
Anomalías: outliers, ráfagas de duplicados, brechas de tiempo.

3. 3 Contratos y esquemas

Compatibilidad de cambios (SemVer: MAJOR/MINOR/PATCH).
Disponibilidad de columnas obligatorias, tipos, restricciones.
Semánticas de KPI fijas: fórmulas y ventanas de agregación.

3. 4 Integración y E2E

Integridad DAG: desencadenantes, dependencias, repetición idempotente.
Ruta completa: fuente → raw → curated → marts → BI/API; RLS/CLS.

3. 5 Rendimiento y costos

p95/p99 latencia jobs, throughput (rows/s), volumen/costo.
Pruebas de regresión de rendimiento y límites de escaneo.

3. 6 Seguridad y privacidad

Enmascaramiento PII/PCI (tokenización determinista).
Verificación de RLS/CLS: los usuarios sólo ven el suyo.
Exportación/aperitivos: ausencia de campos personales «crudos».

4) Características del streaming (Kafka/Flink/Spark Structued Streaming)

Watermarks y lateness: pruebas de ventanas con eventos atrasados (T + Δ), cálculos correctos.
Exactly-once por significado: dedoop por 'event _ id', escritura idempotente (upsert/merge).
Out-of-order: invariantes en agregados por 'event _ time'; fijamos 'ingested _ at'.
Pérdida/repetición: simulamos el drop/juego de lotes, comprobamos la corrección de las vitrinas.

5) Idempotencia y determinismo (qué y cómo probar)

Reiniciar el paso da el mismo resultado (con los mismos parámetros de la ventana).
Grabación - a través de staging y swap atómico.
La lógica merge con SCD1/SCD2 está cubierta por pruebas de conflicto (last-write-wins, source priority).
Determinismo UDF/agregados: entradas idénticas → salidas idénticas.

6) Gestión de datos de prueba

Datasets de oro: pequeñas referencias con validación manual.
Sintética + fábricas de datos: recubrimiento de bordes de dominio (nulls, valores extremos, Unicode, TZ).
De-identificados prod-samples: cumplimiento de privacidad.
Fixtures laminados: eventos crudos, capas intermedias, escaparates totales.

7) Contratos de datos: ejemplo y reglas

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) Observabilidad y pruebas de SLO

Exportar métricas: Freshness, Completeness, Uniqueness, Latency en Grafana/Prometheus.
Las alertas de SLO son como pruebas de unidades «rojas» en venta (Synthetics).
Reportes de regresión: «después del lanzamiento de X p95 ↑ en un 40%».

9) CI/CD y entornos

CI: unit + DQ + contratos de relaciones públicas; schema-diff; análisis estático de SQL (linter).
Sandbox/staging: ejecución de integración y e2e, pruebas de caos con datos seguros.
Características-flags: jobes canarios/modelos/fórmulas.
Catalogación: versión de esquemas, fórmulas KPI, lineage; actualización automática de la documentación.

10) Pruebas de datos de caos (Chaos-Data)

Inyección de duplicados/omisiones, retrasos, fuera de orden.
Caída del corredor/lote, archivos «rotos», schema drift.
Validamos: reparación automática (replay/backfill), quarantine y alertas, MTTR-data.

11) Carga y costo

Generadores de tráfico con perfil p95/pica.
Límites de escaneo/paso (bytes scanned, time caps).
A/B perfilador de valor: «viejo» vs «nuevo» modelo/solicitud.

12) Herramientas (clases aproximadas)

DQ/Contratos: Pruebas de DBT, Grandes Proyecciones, Deexa, Soda, Enlaces Personalizados.
Orquestación: Airflow/Dagster/Argo/Prefect (operadores para pruebas en cada paso).
Plataformas: BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi.
Streaming: Kafka, Flink, Spark Streaming; TestContainers para entornos locales.
Observability: Prometheus/Grafana/Otel; Catálogos DataHub/Amundsen/Collibra.

13) Antipatternas

«No hay nada que probar es simplemente SQL»: no hay unidades y DQ → las métricas se rompen.
Solo E2E: lenta, inestable, las causas de las averías no están claras.
SELECT: se rompe en la evolución MINOR.
Lectura en vivo de OLTP en pruebas: inestabilidad y flakes.
Sin conjuntos de oro: no hay nada que comparar los resultados.
No hay pruebas de idempotencia: reiniciar estropea los datos.
Streaming olvidado: no se prueban lateness/out-of-order/re-delivery.

14) Hoja de ruta para la aplicación

1. Base: pruebas de transformación unit, conjuntos de oro, linter SQL, reglas de DQ top-10 escaparates.
2. Contratos: schema-diff en CI, SemVer, comprobaciones automáticas de compatibilidad.
3. Integraciones: pruebas DAG, idempotency, e2e para hilos críticos.
4. Streaming: pruebas watermarks/lateness, dedup/idempotent sinks.
5. SLO y caos: métricas de calidad en la venta, alertas, escenarios de caos, objetivos MTTR.
6. Optimización: regresiones de perfume, guardas de presupuesto, lanzamientos canarios.

15) Lista de verificación antes del lanzamiento

• Las pruebas de Unit cubren transformaciones clave y UDF.
• Las reglas de DQ para frescura/plenitud/singularidad/rangos pasan.
• Contratos y schema-diff verde; no hay cambios rotos sin appruvio.
• Se ha verificado la idempotencia; atomic sink/merge funciona.
• Streaming: watermarks/late data/out-of-order cubierto; dedup en el lugar.
• Se exponen métricas de SLO; alertas configuradas; runbooks hay.
• Los datos de prueba son seguros; PII enmascarados; RLS/CLS verificados.
• No hay regresiones de perfume; límites de tiempo/escaneo respetados.
• Las pruebas de caos de los escenarios básicos han pasado; El objetivo MTTR es alcanzable.

16) Ejemplos de mini plantillas

16. 1 Prueba Unit SQL (pseudo-dbt):

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

16. 2 Regla de frescura (estilo Great Exhibations):

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 Comprobación lateness en stream (código pseudo):

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

La prueba de transportadores de datos es una disciplina del sistema, no un conjunto de comprobaciones dispares. Conectar la pirámide de pruebas, contratos y observabilidad con prácticas de idempotencia, evolución de circuitos e invariantes de streaming. Entonces los lanzamientos se volverán rápidos, los incidentes serán raros y cortos, y la confianza en los datos será sostenible.