![[ES] Defensa Contra las Artes Oscuras de los data pipelines #1: fundamentos de las caidas de un data pipeline](https://prod-assets.cosmic.aws.dev/a/3E9RPyA5UK5M36Mg0X50EAtU146/S3-F.webp)
[ES] Defensa Contra las Artes Oscuras de los data pipelines #1: fundamentos de las caidas de un data pipeline
Dando fundamentos del porque un data pipeline puede caer y como debemos entender ello para definir criterios para abordar una solución
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 1[ES] Defensa Contra las Artes Oscuras de los data pipelines #1: fundamentos de las caidas de un data pipeline This article
Un data pipeline es una solución analitica para que las empresas utilizan en sus datos con el fin de generar información y conocimiento requerido para tomar acciónes de negocio como tambien en sus actividades eficientemente. Gracias a este hecho es que el equipo de datos debe garantizar el funcionamiento correcto de los data pipeline para siempre disponibilizar la información al cliente; que puede ser un lider de equipo de marketing hasta el CEO del negocio.
Entonces esto puede verse de la siguiente forma:
Data pipeline funcionan correctamente 🟰 Información requerida disponible siempre 🟰 Cliente contento y empoderado
Como un ingeniero de datos, este siempre sera parte de los deberes cotidianos en el rol: Garantizar que el data pipeline funcione de forma correcta. Para lograr ello uno debe de proteger el data pipeline de los elementos oscuros que pueden hacerlo caer, pero la pregunta que uno podria hacerse es:
🤔💭 ¿Cuales son los elementos que hacen caer un data pipeline?
En este artículo; que es una parte de una serie; buscara dar referencias de los elementos que hacen caer un data pipeline, con el fin de aplicar ir a una solución eficiente para ello; que posiblemente sea otro artículo.
Quienes intervienen en la caida
Para responder cuales son los elementos que pueden causar su caida, hay que ver el data pipeline desde los elementos que lo componen en su día a día. En mi opinión personal; estos son los elementos más habituales que habra en un data pipeline:
- Datos: Registros de eventos importantes en un punto en el tiempo bajo una estructura especifica que el data pipeline tomará.
- Logica de procesamiento: Indica como el data pipeline debe procesar los datos y generar el resultado esperado por el cliente. Estos pueden estar dividir en tareas.
- Servicios de hardware y software: Que servicios de software y hardware se utilizan para implementar el data pipeline integramente.
- Orquestamiento: Como un grupo de tareas en un data pipeline debe ejecutarse de forma correcta la definición exacta de ello segun los comportamientos esperados.
- Integraciones: Como el data pipeline interactua con elementos externo alrededor de el como API, colas, bases de datos o otro data pipeline.
- Expectativas del cliente: Expectativas de los resultados por parte del cliente que el data pipeline debe cumplir. Esto aplica tanto a clientes de negocios pero también a proveedores y equipos con los que se colabora en el ciclo de vida del data pipeline.
- Despliegue: Como un data pipeline es pasado a producción en sincronización con el entorno de datos y operativo en el que se trabaja.
Dado que son elementos de construccion de un data pipeline; por lo que la interacción colectiva de cada elementos entre ellos puede ser la causa de la caida:
⛓️ Un data pipeline es tan fuerte como su eslabón más debil.
La caida se genera por la ausencia de un mecanismo en la solución del data pipeline que le permite gestionar la situación raiz que causa la caida que esta relaciona directamente con algun elemento anterior listado. Ejemplos de caidas asociada a cada elemento como raiz se enlistan a continuación:
| Elemento del data pipeline asociado | Ejemplo de caida |
|---|---|
| Datos | Cambios de la estructura de datos no socializada. Cambios de tipos de datos no socializados. |
| Logica de procesamiento | Funciones con comportamientos no correctos según lo esperado. |
| Servicios de hardware y software | Volumenes de datos fuera de la capacidad de hardware. Desconexión por la red. |
| Orquestamiento | Gestión de tareas incorrectas según logica. Mecanismos de reintentos no inteligentes. |
| Integraciones | Credenciales de acceso y Permisos no aceptados. |
| Expectativas del cliente | No aceptación de los resultados generados.Tiempos de entrega no aceptos. |
| Despliegue | Aplicación de versionamiento incorrecto de un data pipeline. |
De estos ejemplos podemos derivar en 2 verdades importantes que debes tener en cuenta:
1️⃣ Muchas caidas pueden ser resueltos por buenas prácticas y gestión de uno mismo.
2️⃣ Hay caidas que no dependen de ti completamente por ser dependencias.
Temas como self-hearling; o autocuración en español; y resiliencia desde diseño son formas técnicas que ayudan a implementar la primera verdad, y que dependen del equipo interno de datos en gran medida. Mientras que la segunda verdad siempre es un tema de gestión entre proveedores para garantizar que todo este en orden de acuerdo a lo que se a pactado.
Tipos de caidas y quien lo resuelve
Las caidas pueden ser categorizado según el efecto más relevante que tengan directamente sobre el data pipeline. Si bien hay muchas forma de categorizaciones, aquí comparto una lista que me ayuda en ello:
| Categorias | Comportamiento | Efecto |
|---|---|---|
| Hard failure | El data pipeline no logra completar su ejecución por fallo interno. | Los datos no son entregados o generados. |
| Silent failure | El data pipeline funciona bien pero hay errores en los datos. | Los datos son entregados pero no son correctos. |
| Partial failure | Una parte del data pipeline funciona pero otra no. | Algunos datos son generados y entregados pero otros no son entregados o generados. |
| Performance failure | Un data pipeline tiene problemas de rendimiento. | No se entregan los datos de forma oportuna. |
| Cascading failure | El data pipeline tiene fallos porque tiene una dependencia para funcionar bien. | Los datos no son entregados o generados o estan incorrectos. |
Un data pipeline puede tener uno o más categorias en una caida. Por ejemplo, un data pipeline B se ejecuto pero genera datos incorrectos pero revisando demos que tiene una dependencia con el data pipeline A que dio los datos de forma incorrecto; en este caiad vemos que hay tanto cascading failure como silent failure.
Para solucionar una caida, generalmente estan los involucrados en su creación: equipo de datos, proveedores y representante del negocio; tambien llamados cliente de negocio. Ellos en alguna forma son participantes en la creación y funcionamiento de un data pipeline, por lo que pueden participar y apoyar en entender la situación para poder encontrar una solución de ser necesario.
Cada equipo involucrado tiene una función especifica:
- El representante/cliente de negocio verifica que todo este bien con los resultados según lo esperado como también los requerimientos solicitados para el equipo de datos.
- El equipo de datos revisa que la soluciones funcionan bien y cumplen con los requerimientos soliticados por el negocio.
- El proveedor garantiza que los artefactos entregados funcionan correctamente; en los cuales el data pipelien se basa; hacia el equipo de datos y/o negocio.
la eficiencia de un equipo de datos depende del dominio de temas alrededor de la gestión de datos poco habituales: metadatos, gobierno y calidad de datos como puntos relevantes para tener entender rapidamente; en la medida de lo posible; la situación para lograr gestionar a nivel técnico los mecanismos y el entorno para dar una solución las caidas de los data pipelines. Por ejemplo, al conocer y entender que metadatos operacionales genero el data pipeline y los resultados de los mecanismo de control de calidad de los datos; podremos detectar cuales actores generaron la caida y como tienen responsabilidad en ello.
🏗️ El equipo de datos debe dominar la gestión de los datos para guiar y dar soporte a las caidas de los data pipeline eficientemente.
Coordinaciones y alineamientos de equipo con los artefactos, implementación de mejoras y buenas prácticas en soluciones como también planeamiento y abordaje de posibles incidentes y situaciones para el data pipeline son elementos que al no estar presentes en el ciclo de vida de un data pipeline pueden causar caidas por no prevenir posibles situaciones.
Conclusion
La percepción ante el cliente y la empresa cuando hay una caida puede afectar la confianza de tu data pipeline; por lo que saber quien, cuando y porque cayo ayuda a tener tranquilidad por el completo dominio de la situacion por parte del equipo de datos.
Independiente de la velocidad, veracidad, veracidad, variedad o valor que tengan los datos que tu data pipeline deba procesar; siempre habra caidas en el data pipeline por alguna falla ocurrida. Si tuviera que agregar una verdad fundamental que tengas que recordar serian estas:
✨ Siempre habra fallos inesperados en tu data pipeline; piensa y gestiona los fallos esperados y/o planeados. ✨
Como ingeniero de datos uno debe prepararse para abordar esta verdad en una forma pragmatica en la soluciones que uno implementa.
En la siguiente lección hablaremos sobre la resiliencia y como agregarla en los data pipelines.
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 1[ES] Defensa Contra las Artes Oscuras de los data pipelines #1: fundamentos de las caidas de un data pipeline This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article