Lista de los 13 problemas de datos de pipeline más comunes (con ejemplos)

Quizás la parte más complicada de la gestión de pipelines de datos es comprender el fantasma que se esconde en la máquina: los datos ex machina, por así decirlo.

¿Cómo se aplican correcciones a los problemas de calidad de los datos? Todo comienza por saber qué lo que distingue a los ingenieros de datos excepcionales del resto es su capacidad para encontrar la causa raíz de los problemas de datos. Cualquiera puede reiniciar el pipeline, encogerse de hombros y reanudar el trabajo. Muy pocos juegan a ser detectives para llegar al fondo del asunto, aunque eso es lo que se necesita.

Es la diferencia entre estar satisfecho con las causas proximales o las causas raíz. Las causas proximales son las cosas que parecen haber salido mal, como un error en tiempo de ejecución. La causa raíz es lo que causó la causa proximal, y es mucho más difícil de averiguar. A veces, las causas proximales son causas raíz, pero rara vez.

Piensa en las causas próximas como simples alertas. Le están diciendo que en algún punto de su pipeline hay un error raíz. Ignórelo bajo su propia responsabilidad, porque esa deuda de datos se acumula.

Cuando llueve, diluvia, y cuando se tiene un problema, se tiende a tener muchos. A continuación se muestran las posibilidades comunes de problemas de datos proximales; estos problemas no son mutuamente excluyentes y la lista está lejos de ser exhaustiva:

• El horario cambió
• Se agotó el tiempo de espera del pipeline
• Un trabajo se ha quedado atascado en una cola
• Hubo una transformación inesperada
• Una ejecución específica falló (quizás falla justo cuando comienza)
• La ejecución duró más de lo normal
• Hubo un fallo generalizado en todo el sistema
• Se ha producido un error de transformación
• Muchos trabajos fallaron la noche anterior
• Había un tamaño de entrada anómalo
• Había un tamaño de salida anómalo
• Hubo un tiempo de ejecución anómalo
• Una tarea se detuvo inesperadamente
• Se ha producido un error de tiempo de ejecución

Pero eso no es todo, ¿verdad? De nuevo, no piense en esto como problemas, sino como señales. Todas estas son cosas que pueden salir mal y que indican que ha ocurrido algo más preocupante. Muchas aparecerán simultáneamente.
Una plataforma de observabilidad puede ser muy útil para filtrarlas. Le permitirá agrupar los problemas concurrentes para darles sentido.

También puede agrupar los problemas según la dimensión de calidad de los datos a la que se agrupan, como aptitud, linaje, gobierno o estabilidad. Agrupar los problemas de datos de esta manera le muestra las dimensiones en las que tiene más problemas y puede poner en contexto lo que parecen problemas aislados.

Y, por supuesto, tampoco tiene que esperar a que un trabajo falle para intentarlo. Si tiene Databand, le permite investigar anomalías retroactivamente (captura todos esos metadatos históricos) para que pueda tener claro qué es casual y qué está meramente correlacionado.

Así es como puede detectar un problema como el estancamiento de una tarea entre una docena de errores y probar en muchos problemas que la causa raíz es probablemente un fallo de aprovisionamiento del clúster. Y así es como hay que verlo. Siempre está buscando la causa raíz del problema de datos.

Las causas raíz son el final del camino. Deben ser el evento original en la cadena causal, la primera ficha de dominó, por así decirlo, y explicar en gran medida el problema. Si esa causa raíz del problema de datos no se produce, tampoco debería ocurrir ninguna de las causas proximales. Es directamente causal para todos ellos.

Las causas raíz, por supuesto, no siempre son claras y las correlaciones no siempre son exactas. Si no se siente seguro de su respuesta, una forma probabilística de averiguar su verdadera puntuación de confianza es probar este experimento mental: imagine que su jefe le dice que su equipo va a apostar todo por su hipótesis y que nadie la va a comprobar antes de que entre en producción, y que su nombre aparecerá en todas partes. Si está mal, es toda su culpa. ¿Qué puntuación de confianza de 0 a 100 le daría a su hipótesis? Si es inferior a 70, siga investigando.

Las causas raíz más comunes de los problemas de datos incluyen:

1. Error de usuario: comenzaremos con los errores de usuario porque son comunes. Tal vez alguien ingresó el esquema incorrecto o el valor incorrecto, lo que significa que el pipeline no lee los datos, o hizo lo correcto con valores incorrectos, y ahora tiene un error en la tarea.

2. Datos etiquetados incorrectamente: a veces las filas se desplazan en una tabla y las etiquetas correctas se aplican a las columnas equivocadas.

3. El socio de datos se olvidó de una entrega: también muy común. Puede crear un sistema a prueba de balas, pero no puede controlar lo que no puede ver y si los problemas de datos están en los datos de origen, provocará que los pipelines perfectamente buenas se comporten mal.

4. Hay un error en el código: esto es común cuando hay una nueva versión del pipeline. Puede averiguarlo bastante rápido con software de versionado como Git o GitLab. Compare el código de producción con una versión anterior y ejecute una prueba con esa versión anterior.

5. Error de datos OCR: su escáner óptico lee mal los datos, lo que provoca valores extraños (o faltantes).

6. Problema con los datos deteriorados: el conjunto de datos está tan desactualizado que ya no es válido.

7. Problema de datos duplicados: a menudo, un proveedor no podía entregar los datos, por lo que el pipeline se ejecutaba con los datos de la semana anterior.

8. Problema de permisos: el pipeline falló porque el sistema carecía de permiso para extraer los datos o realizar una transformación.

9. Error de infraestructura: tal vez agotó su memoria disponible o el límite de llamadas a la API, su clúster Apache Spark no se ejecutó o su almacén de datos está siendo inusualmente lento, lo que hace que la ejecución continúe sin los datos.

10. Cambios en la programación: alguien (o algo) cambió la programación y hace que el pipeline se ejecute fuera de servicio o no se ejecute.

11. Conjunto de datos sesgado: muy difícil de clasificar. No hay una buena forma de averiguarlo, excepto ejecutando algunas pruebas para ver si los datos son anómalos en comparación con un conjunto de datos reales similar, o averiguar cómo se recopilaron o generaron.

12. Error del orquestador: el programador de pipelines no ha podido programar ni ejecutar el trabajo.

13. Fantasma en la máquina (datos ex machina): es realmente incognoscible. Es difícil admitir que es así, pero es cierto para algunas cosas. Lo mejor que puede hacer es documentar y estar preparado para la próxima vez que pueda recopilar más datos y empezar a establecer correlaciones.

Y luego, por supuesto, está la realidad en la que la causa raíz no está del todo clara. Muchas cosas están correlacionadas y probablemente sean interdependientes, pero no hay una respuesta clara, y después de hacer cambios, ha solucionado el problema de los datos, aunque no está seguro de por qué.

En esos casos, como en cualquier otro, anote su hipótesis en el registro y, cuando pueda volver a ella, continúe probando los datos históricos y esté atento a nuevos problemas y causas más explicativas.

La característica que más diferencia al ingeniero de datos aficionado al experto es su capacidad para identificar las causas raíz y su comodidad con respuestas ambiguas. Las causas proximales son a veces las causas raíz, pero no siempre. Las causas raíz a veces se correlacionan con causas proximales específicas, pero no siempre. A veces no hay distinción entre lo que es sesgo de datos y lo que es error humano.

Los grandes ingenieros de datos saben que sus pipelines son volubles y, a veces, tienen personalidad. Pero están en sintonía con ellos, tienen herramientas para medirlos y siempre están a la caza de una explicación más fiable.

Vea cómo Databand de IBM proporciona una monitorización de los pipelines de datos para detectar rápidamente incidencias en los mismos, como trabajos y ejecuciones fallidos, de modo que pueda gestionar el crecimiento de dichos pipelines. Si está listo para profundizar, solicite una demostración hoy mismo.