Implementación pública sintética
Lab publicado
Data Quality Pipeline Lab
Construí este lab público para mostrar contratos de datos explícitos, cuarentena a nivel de fila, transformaciones idempotentes y reconciliación origen-destino sobre datos mayoristas B2B sintéticos, con tests automatizados y CI.
Este lab usa datos sintéticos, reglas de negocio sintéticas y una arquitectura sintética. Es una implementación pública independiente y no reproduce código, datos ni sistemas de un empleador. Es un pipeline batch local pequeño, no un despliegue Databricks, cloud, streaming ni de producción.
Qué construí
Creé Data Quality Pipeline Lab como un pipeline de referencia local en PySpark sobre fixtures mayoristas B2B totalmente sintéticos. El objetivo es hacer fáciles de inspeccionar los contratos, las decisiones de cuarentena, la reconciliación y la evidencia de CI, sin exponer sistemas privados de clientes.
Qué quería hacer inspectable
Los controles de calidad de datos son difíciles de discutir cuando los esquemas se infieren, las filas rechazadas son opacas y las diferencias origen-destino no se reconcilian. Quería un ejemplo público pequeño en el que cada fila aceptada o puesta en cuarentena pudiera contabilizarse.
Qué incluye el lab
- Cinco contratos de origen explícitos con esquemas tipados y claves primarias.
- Reglas de calidad referenciales, de dominio, temporales y aritméticas con identificadores estables.
- Registros de cuarentena a nivel de fila para entradas rechazadas.
- Ejecuciones idempotentes con salidas Parquet seguras ante sobrescritura.
- Contabilidad de filas origen-destino y reconciliación monetaria.
- Artefactos de evidencia JSON, tests automatizados y CI en GitHub Actions.
Qué dejé fuera de alcance
- Los datos, las reglas de negocio y la arquitectura son totalmente sintéticos.
- El lab no reproduce código, datos ni sistemas de empleadores.
- Es un pipeline batch local y no incluye Databricks, infraestructura cloud, streaming, orquestación, API ni interfaz de usuario.
- No atribuye escala de producción ni impacto de negocio.
Cómo funciona el pipeline
- 01
Declarar contratos en lugar de inferir esquemas
Cada origen tiene un esquema Spark explícito, una clave primaria y campos monetarios tipados, de modo que el pipeline nunca depende de la inferencia.
- 02
Aplicar reglas de calidad inspectables
Las filas rechazadas se escriben una sola vez con todos los identificadores de regla aplicables, el nombre del origen y un run ID determinista.
- 03
Mantener las ejecuciones idempotentes
El run ID se deriva de la configuración y de los bytes de entrada. Las salidas se escriben de forma segura para que las repeticiones produzcan las mismas tablas y conteos lógicos.
- 04
Reconciliar las salidas aceptadas
El pipeline comprueba que cada fila de origen se acepta o se pone en cuarentena y reconcilia los totales de líneas de pedido aceptadas frente al resumen de pedidos curado.
- 05
Empaquetar evidencia y CI
El manifiesto y los informes de calidad y reconciliación se escriben en JSON, y el repositorio valida formato, tipos, tests, build y la demo de extremo a extremo en CI.
Qué contiene el repositorio
- Un pipeline batch local en PySpark con fixtures sintéticos.
- Contratos de origen explícitos y salidas de cuarentena.
- Informes de evidencia de reconciliación y manifiesto de ejecución.
- Tests automatizados y un entorno de desarrollo bloqueado.
- CI en GitHub Actions y una release pública versionada.
Tecnologías
- Python
- PySpark
- uv
- pytest
- Ruff
- mypy
- GitHub Actions
- Parquet
Qué muestra el paquete publicado
Hecho del paquete del lab sintético
Contratos de origen explícitos
5
El lab publicado declara cinco contratos de origen con esquemas explícitos en lugar de inferencia.
Hecho del paquete del lab sintético
Tests automatizados
17
El paquete publicado incluye diecisiete tests automatizados que cubren contratos, comportamiento de calidad y evidencia del pipeline.
Hecho del paquete del lab sintético
Comprobaciones de reconciliación
2
El pipeline realiza dos comprobaciones de reconciliación: contabilidad de filas de origen y reconciliación de totales de línea aceptados frente al resumen curado.
Qué no demuestra este lab
- Se trata de un lab de referencia sintético, no de una entrega a cliente ni de un sistema de producción.
- No demuestra Databricks, operaciones cloud, streaming ni orquestación.
- Los conteos de fixtures y los totales de la demo no son KPI de negocio.
- No hay evidencia de escala, latencia o coste bajo cargas realistas.
Qué seguiría haciendo falta en un despliegue real
- Orquestación, reintentos y recuperación ante fallos.
- Control de acceso, catálogo y linaje.
- Política de evolución de esquema y procesamiento incremental.
- Métricas operativas, alertas y particionado bajo cargas reales.
Dónde puede ayudar este método
- Diseño de ETL y calidad de datos.
- Revisión de pipelines con contratos primero.
- Diseño de cuarentena y reconciliación.
- Evaluación técnica de modernización de procesos analíticos.
Evidencia del proyecto
- Ver el repositorio público
Código fuente, fixtures sintéticos, tests, informes de evidencia y CI del lab independiente. Usa datos, reglas y arquitectura sintéticos y no reproduce código, datos ni sistemas de empleadores.
- Ver la release v0.1.0
Release pública versionada del paquete del lab sintético y de las expectativas documentadas de la demo local.