Práctica profesional - Ingeniería de tuberías de datos

Full Time

Job expired!

Propuesta de Tesis NPX
Observabilidad
RQ1:
Problema de investigación:
Cuando se interroga a PA para extraer datos de uso de HPC, ocurren huecos. Este proceso de interrogación, a su vez, crea más huecos entre el uso actual de HPC y el uso registrado de HPC. (posiblemente porque PA no observa ni guarda datos de forma pasiva durante esta acción).
Pregunta de investigación:
¿Cómo podemos observar con precisión (ingeniería observable) las pipelines de datos e informar correctamente sobre el uso de HPC?
¿Qué es la Observabilidad?
En general, la observabilidad es el grado en el que se puede entender el estado o condición interna de un sistema complejo basándose únicamente en el conocimiento de sus salidas externas. Cuanto más observable es un sistema, más rápido y exactamente puedes navegar desde un problema de rendimiento identificado hasta su causa raíz, sin pruebas o codificación adicionales.
En este problema de investigación, la observabilidad se utilizaría para el monitoreo del uso de HPC.
Método de investigación (Posible solución):
Mejorar la observabilidad de los clusters de HPC es la clave.
•
Definir nuevas métricas y métodos de automatización para entender cuando hay un hueco.
•
Analizar la telemetría de observabilidad, p. ej., para identificar la frecuencia de un hueco significativo que necesita ser resuelto.
•
Analizar la correlación entre las métricas y los huecos para activar una solución para rectificar un hueco incluso antes de que se vuelva demasiado grande.
Basándonos en estos puntos, podemos desarrollar una herramienta que pueda resolver este problema de huecos.
La idea principal es observar de forma pasiva el cluster de HCP para recoger las métricas clave utilizadas por la herramienta de solución. Esto permite que la herramienta funcione como una cola: una vez que se capturan las métricas observadas, se ponen en cola a la herramienta que puede comprobar si el PA tiene un hueco respecto a lo que la herramienta ha observado.
Problema con la solución propuesta:
Activar continuamente la base de datos para intentar conseguir un hueco de cero significaría invocar de forma recursiva la actualización. Por lo tanto, sería necesario determinar un hueco mínimo aceptable para el caso de negocio. Lo importante es evitar un hueco al final de umbrales específicos como el fin del día/fin de la semana/fin del mes.
RQ2:
Problema de investigación:
El problema principal gira en torno al hueco entre el uso actual de HPC y el uso registrado de HPC. La solución de este problema debe ser generalizada para resolver otros problemas de huecos derivados de la observabilidad de HPC.
Pregunta de investigación:
¿Al aplicar la solución anterior en un sistema diferente, puede ser generalizable?
Método de investigación:
•
Analizar el sistema en el que queremos aumentar la observabilidad.
•
Descubrir si podemos medir algunos parámetros que pueden ser utilizados para definir las métricas del sistema.
•
Comprobar si estas nuevas métricas pueden ser utilizadas para la solución anterior.
Este enfoque debería permitirnos aplicar la lógica generalizada y configurarla teniendo en cuenta la estructura del sistema, de manera que se pueda usar una solución genérica en un sistema diferente personalizando las métricas.
Referencias:
•
https://onlinelibrary.wiley.com/doi/epdf/10.1002/spe.3116
•
https://www.ibm.com/topics/observability
•
https://grafana.com/blog/2020/03/03/the-benefits-of-observability/
Tarea de Resistencia de Backup
RQ3:
Problema de investigación:
Resiliencia de la pipeline de datos y su infraestructura.
Pregunta de investigación:
¿Cómo podemos anticipar las circunstancias medibles que pueden salir mal en el trabajo? (p. ej., fallos en la pipeline)
Método de investigación y solución propuesta:
Definir los escenarios en los que falló la pipeline:
•
Realizar un análisis de los problemas previos de la pipeline y sus informes.
•
Descubrir algunos casos particulares.
Trabajos relacionados y referencias
En la literatura de HPC se han realizado algunas investigaciones sobre sistemas de backup. Una encuesta sobre el método de resiliencia de HPC: https://link.springer.com/article/10.1007/s11704-022-2096-3
Los estudios concluyen que un "sistema de backup" aumenta la resistencia de la pipeline y debería disminuir el uso de HPC porque el trabajo no está obligado a reiniciarse:
•
https://journals.sagepub.com/doi/epub/10.1177/1094342021990433
•
https://resilienthpc.eu/sites/default/files/pdf/Blueprint2020__Towards-Resilient-EU-HPC-Systems.pdf
Hipótesis y consideraciones:
Los sistemas de microservicios tienen un mecanismo de resiliencia en el que cada microsistema se duplica en caso de fallo del principal. Además, algunas políticas garantizan un mínimo número de microservicios duplicados para aumentar la disponibilidad del sistema. El mencionado "sistema de backup" puede verse como una garantía en el cluster de HPC que extiende la disponibilidad y la ejecución continua del trabajo, de manera que el trabajo de HPC puede recuperarse o ejecutarse después de un fallo. Esto no debería necesitar reiniciar el trabajo fallido desde el principio.
RQ4:
Problema de investigación:
La pipeline de datos y la infraestructura tienen un sistema de backups que es capaz de recuperar una pipeline de datos fallida.
Pregunta de investigación:
¿Cómo podemos comprobar que el sistema de backup funciona bien?
¿Qué es la ingeniería del caos?
La ingeniería del caos es un conjunto de principios para mejorar la resiliencia del sistema. En particular:
•
Construir una hipótesis en torno al comportamiento de estado estable del sistema.
•
Variar los eventos del mundo real.
•
Realizar experimentos en producción.
•
Automatizar los experimentos para que se ejecuten de forma continua.
•
Mitigar el radio de impacto de los experimentos.
En nuestro caso, intentamos hacer esta prueba en el sistema de backup.
Método de investigación (Posible solución):
La ingeniería del caos puede ser utilizada para comprobar el estado de los backups a través de experimentos de caos:
1.
Encontrar la herramienta de caos más apropiada para producir experimentación de caos en la (potencialmente) probada infraestructura resiliente.
2.
Definir los experimentos de caos más significativos en base a los análisis post-mortem disponibles.
3.
Probar el sistema de backup resultante con experimentación de caos para detectar:
a.
El radio de impacto de los fallos imprevisibles/inmanejables.
b.
La gracia de los fallos y sus impactos medibles.
Objetivo:
Se supone que el enfoque propuesto aumentará la resiliencia del sistema de backup, de manera que en caso de fallo de la pipeline, la recuperación de esa pipeline debería ser más eficiente, sin la necesidad de reiniciar la pipeline.
Hipótesis
Ya existe un sistema de backup parcialmente implementado y está disponible para la extensión/experimentación.
Referencias:
Considerando la naturaleza técnica del sistema de backup, se deberá seleccionar una herramienta específica de ingeniería del caos.
-
https://www.ibm.com/topics/chaos-engineering
-
https://www.gremlin.com/community/tutorials/chaos-engineering-tools-comparison/