Una 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 en la máquina: los datos ex machina, por así decirlo.

¿Cómo arregla los problemas de calidad de los datos? Comienza por saber que lo que separa a los ingenieros de datos notables del resto es su capacidad para buscar la causa principal de los problemas de datos. Cualquiera puede restablecer el pipeline, encogerse de hombros y reanudar el trabajo. Muy pocos juegan a los detectives para llegar al fondo del problema, aunque eso es lo que se necesita.

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

Piense 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, lo hace a cántaros, y cuando tiene un problema, suele tener varios. A continuación se presentan 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 atascó en una cola
• Hubo una transformación inesperada
• Una ejecución específica falló (tal vez falla justo cuando comienza)
• La ejecución duró más de lo normal.
• Hubo una falla en todo el sistema
• Hubo un error de transformación
• Muchos trabajos fallaron la noche anterior
• Hubo un tamaño de entrada anómalo
• Había un tamaño de resultado anómalo
• Hubo un tiempo de ejecución anómalo
• Una tarea se detuvo inesperadamente
• Se produjo un error de tiempo de ejecución.

Pero eso no es todo, ¿verdad? Nuevamente, piense en estos no como problemas, sino como señales. Estas son todas las cosas que pueden salir mal que significan que ha ocurrido algo más preocupante. Muchos aparecerán simultáneamente.
Una plataforma de observabilidad puede ser realmente útil para clasificarlos. Te permitirá agrupar problemas que ocurren al mismo tiempo para entenderlos mejor.

También puedes agrupar los problemas según la dimensión de calidad de los datos a la que se agrupan, como aptitud, linaje, gobernanza 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 puedes seleccionar un problema como una tarea que se está paralizando entre una docena de errores, y probar en muchos problemas que la causa principal probablemente sea una falla de provisionamiento de clúster. Y así es como debe verlo. Busque siempre la causa principal del problema con los datos.

Las causas principales son el final del camino. Deberían ser el evento original en la línea de causalidad (la primera ficha de dominó, por así decirlo) y, en su mayoría, explicar el problema. Si esa causa principal del problema de datos no ocurre, tampoco debería ocurrir ninguna de las causas proximales. Es directamente causal para todas.

Por supuesto, las causas principales no siempre están claras y las correlaciones no siempre son exactas. Si no se siente seguro con su respuesta, una forma probabilística de determinar su verdadero puntaje de confianza es probar este experimento mental: supongamos que su jefe le dice que su equipo hará todo lo posible por su hipótesis y que nadie la va a verificar antes de entrar en producción, y su nombre estará por todas partes. Si sale mal, toda la culpa será suya? ¿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 principales de los problemas de datos incluyen:

1. Error del usuario: comenzaremos con los errores del usuario porque son comunes. Quizás alguien ingresó el esquema incorrecto o el valor incorrecto, lo que significa que la canalización no lee los datos, o hizo lo correcto con valores incorrectos, y ahora tiene una falla 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 incorrectas.

3. El socio de datos perdió una entrega: también es 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 buenos se comporten mal.

4. Error en el código: esto es común cuando hay una nueva versión de la canalización. Puede resolver esto bastante rápido con un software de control de versiones 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 de OCR: su escáner óptico lee mal los datos, lo que genera valores extraños (o faltantes).

6. Problema de 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 datos, por lo que el pipeline se ejecutó para los datos de la semana pasada.

8. Problema de permisos: la canalización falló porque el sistema no tenía permiso para extraer los datos o realizar una transformación.

9. Error de infraestructura: tal vez maximizó 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 la canalización se ejecute fuera de servicio o no se ejecute.

11. Conjunto de datos con sesgo: muy difícil de resolver. No hay una buena manera de descubrir esto, excepto ejecutando algunas pruebas para ver si los datos son anómalos en comparación con un conjunto de datos verdadero similar, o averiguar cómo se recopilaron o generaron.

12. Falla del orquestador: el programador de pipelines no pudo programar o ejecutar el trabajo.

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

Y luego, por supuesto, está la realidad en la que la causa principal 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, arregló 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 separa al ingeniero de datos aficionado del experto es su capacidad para resolver las causas principales y su comodidad con las respuestas ambiguas. Las causas proximales a veces son causas principales, pero no siempre. Las causas principales 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 personalidades. 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 confiable.

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