Caso de estudio · Ingeniería de Datos · Forward Deployed
Casos de Incidentes de Datos
Tres incidentes de datos reproducibles, trabajados como investigaciones: síntoma, hipótesis, evidencia, causa raíz, corrección y un control que se queda.
El problema
Los peores incidentes de datos no dan error: un reporte pierde filas en silencio, un cruce deja de coincidir poco a poco, los ingresos superan al libro contable. Corregirlos es fácil una vez que sabes dónde se rompieron los datos. Encontrar ese punto es lo difícil.
Restricciones
- Sin datos de clientes: cada incidente se reconstruye con datos generados que se comportan igual
- Cada número del informe debe salir del código, para poder repetirlo y verificarlo
- Cada corrección deja un control, para que la próxima vez falle el build y no el reporte
Arquitectura y decisiones
Haz clic en una caja para ver por qué se eligió.
Por qué · Hypotheses
Primero lo más barato: ¿cambió la fuente, un paso perdió filas, cambió una clave? Las hipótesis descartadas quedan en el informe para mostrar qué se descartó.
Resultados
- incidentes: pérdida en un cruce, cambio de formato de clave, eventos duplicados
- 3
- incidentes: pérdida en un cruce, cambio de formato de clave, eventos duplicados
- tasa de coincidencia de clientes recuperada en el incidente 02
- 57% → 98%
- tasa de coincidencia de clientes recuperada en el incidente 02
- diferencia de ingresos vs el libro contable cerrada en el incidente 03
- +15% → 0%
- diferencia de ingresos vs el libro contable cerrada en el incidente 03
- controles reutilizables, 15 pruebas
- 5
- controles reutilizables, 15 pruebas
Qué haría después
- 01Incidente 04: un cambio de zona horaria que pasa pedidos de la noche al día siguiente
- 02Publicar los controles como pruebas de dbt para que corran en Snowflake y BigQuery