¿Qué hace Depuración de Tuberías de Datos?
Cuándo usar
- Un trabajo de tubería falló, o los datos de salida son incorrectos/faltan/están duplicados.
- Un panel está desactualizado o una métrica no coincide con la fuente.
- Una parte interesada reporta una discrepancia y debes encontrar la causa.
- NO usar para errores específicos de herramientas que ya cubren
debugging-dbt-runs/debugging-airflow-pipelines(comienza allí, luego usa esto para incidentes de corrección de datos).
Flujo de trabajo
- [ ] Define el síntoma con precisión (qué tabla, columna, filas, ventana de tiempo)
- [ ] Rastrea el linaje ascendente para encontrar la primera etapa donde los datos son incorrectos
- [ ] Aísla: ¿es un error de código, datos de entrada incorrectos, datos tardíos o un fallo de ejecución?
- [ ] Concilia la etapa sospechosa contra su fuente (recuentos/sumas)
- [ ] Corrige la causa raíz, luego planifica una recarga histórica idempotente de las ventanas afectadas
- [ ] Agrega una comprobación para que no pueda repetirse en silencio
- Fija el síntoma. "Los ingresos para 2026-01-15 son ~30% bajos en
fct_orders" es depurable; "los números se ven mal" no lo es. Obtén la tabla, columna, filas y ventana. - Rastrea el linaje ascendente. Camina desde la salida incorrecta hacia atrás a través de modelos/ tareas para encontrar la primera etapa donde los datos ya son incorrectos. Realiza una búsqueda binaria en el DAG en lugar de leer cada etapa.
- Clasifica la causa: cambio de código, datos fuente incorrectos/tardíos, una ejecución fallida/parcial o un duplicado no idempotente.
- Concilia la etapa sospechosa vs su entrada (recuentos de filas, recuentos de claves, sumas) para confirmar dónde aparece la diferencia.
- Corrige + recarga históricamente las ventanas afectadas de forma idempotente (consulta
designing-backfills-and-replays). - Prevén la recurrencia con una comprobación de calidad de datos dirigida.
Patrones
Búsqueda binaria de linaje — verifica una etapa a mitad del DAG: si sus datos son correctos, el error está aguas abajo; si son incorrectos, sube más. Repite.
Concilia fuente vs destino para la ventana afectada:
-- ¿Coinciden los recuentos/sumas entre la etapa y su entrada para la ventana incorrecta?
SELECT 'source' AS layer, COUNT(*) n, SUM(amount) total
FROM staging.orders WHERE order_date = DATE '2026-01-15'
UNION ALL
SELECT 'target', COUNT(*), SUM(amount)
FROM marts.fct_orders WHERE order_date = DATE '2026-01-15';
Una brecha de recuento → filas eliminadas/filtradas o una carga parcial fallida. Una brecha de suma con recuentos iguales → un error de transformación/lógica. Un recuento de destino más alto → duplicación (carga no idempotente).
Verificación de línea de tiempo — correlaciona la ventana del incidente con despliegues, cambios de esquema de la fuente e historial de ejecuciones; la mayoría de los incidentes comienzan con un cambio.
Errores comunes
- Corregir síntomas aguas abajo — parchear el mart cuando el error está en staging hace que se repita; corrige la primera etapa incorrecta.
- Correcciones manuales únicas a datos de producción — no auditables e irrepetibles; corrige el código y vuelve a ejecutar de forma idempotente.
- Leer todo el DAG de forma lineal — en su lugar, realiza una búsqueda binaria del linaje.
- Saltarse la conciliación — adivinar dónde divergieron los datos pierde tiempo; mide recuentos/sumas por etapa.
- Sin comprobación preventiva después de la corrección — la misma clase de error regresa sin ser vista.