Skip to content

JuanPF56/TP-SDI

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

615 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

TP-SDI

Trabajo Práctico Grupo 3 - Materia Sistemas Distribuidos I - FIUBA

📚 Índice

  1. 📘 Descripción General
  2. ✅ Requerimientos
  3. 🛠️ Configuración del Sistema
  4. ▶️ Correr el sistema
  5. 🧱 Comandos disponibles (Makefile)
  6. 💀 Introducción de fallas)
  7. 📊 Monitoreo de las colas (RabbitMQ)
  8. 💯 Respuestas esperadas
  9. 🛠️ Construido con
  10. ✒️ Autores
  11. 📑 Documentación

✅ Requerimientos

Funcionales

  • Se solicita un sistema distribuido que analice la información de películas y los ratings de sus espectadores en plataformas como iMDb.
  • Los ratings son un valor numérico de 1 al 5. Las películas tienen información como género, fecha de estreno, países involucrados en la producción, idioma, presupuesto e ingreso.
  • Se debe obtener:
    1. Películas y sus géneros de los años 2000 con producción Argentina y Española.
    2. Top 5 de países que más dinero han invertido en producciones sin colaborar con otros países.
    3. Película de producción Argentina estrenada a partir del 2000, con mayor y con menor promedio de rating.
    4. Top 10 de actores con mayor participación en películas de producción Argentina con fecha de estreno posterior al 2000.
    5. Promedio de la tasa ingreso/presupuesto de películas con overview de sentimiento positivo vs. negativo.

No funcionales

📈 Escalabilidad

  • El sistema debe estar optimizado para entornos multicomputadoras.
  • Debe soportar el escalado horizontal al incrementar nodos de cómputo.
  • Se requiere el desarrollo de un Middleware para abstraer la comunicación basada en grupos.
  • Debe soportar una única ejecución del procesamiento y permitir un graceful quit ante señales SIGTERM.

👥 Multi-client

  • Soporte para varias ejecuciones de las consultas por parte de un cliente, sin reinicio del servidor.
  • Ejecución con varios clientes de forma concurrente.
  • Correcta limpieza de los recursos luego de cada ejecución.

🛡️ Tolerancia a fallos

  • El sistema debe ser tolerante a fallos por caídas de procesos.
  • En caso de usar un algoritmo de consenso, el mismo tiene que ser implementado por los alumnos.
  • Está permitido utilizar docker-in-docker para levantar procesos caídos
  • No está permitido utilizar docker para verificar si un nodo está disponible.

🛠️ Configuración del Sistema

⚙️ Configurar cantidad de nodos

Antes de generar el archivo docker-compose.system.yml, podés editar el archivoglobal_config.ini para ajustar la cantidad de nodos que tendrá cada componente del sistema:

[DEFAULT]
coordinator_nodes = 3
gateway_nodes = 5
cleanup_filter_nodes = 6
production_filter_nodes = 4
year_filter_nodes = 4
sentiment_analyzer_nodes = 5
join_credits_nodes = 5
join_ratings_nodes = 5

🔧 Generar los docker-compose

Se cuenta con un script auxiliar para facilitar la generación de los archivos docker-compose.system.yml y docker-compose.clients.yml de manera dinámica, según los parámetros que se definan.


📦 Instalar dependencias

Antes de ejecutar cualquier script Python, asegurate de instalar las dependencias necesarias:

pip install -r requirements.txt

✅ Script auxiliar generate-compose.sh

./generate-compose.sh [<output_file.yml>] [-test <test_config.yaml>] [-cant_clientes N]

📌 Parámetros

  • <output_file.yml>: Opcional. Nombre base del archivo de salida. En caso de no pasarse, será: docker-compose.system.yaml para el sistema y docker-compose.clients.yml para los clientes.
  • -test <test_config.yaml>: Opcional. Monta datasets reducidos para pruebas rápidas y ejecuta automáticamente download_datasets.py -test <test_config.yaml>, con la configuración seteada en:test_config.yaml (para más información sobre como configurar el set de pruebas vaya a 📋 Preparar datasets de prueba). En caso de no pasarse, se descargaran los datasets completos.
  • -cant_clientes N: Opcional. Define cantidad de clientes (client_X) que se generan. En caso de no pasarse se generará 1 solo cliente.

📖 Ejemplos

  • Generar configuración default:
./generate-compose.sh

expected_output_default

  • Generar en modo test:
./generate-compose.sh -test test_config.yaml
  • Generar con 4 clientes:
./generate-compose.sh -cant_clientes 4
  • Combinar ambos:
./generate-compose.sh -test test_config.yaml -cant_clientes 10

expected_output_test_and_multiclient

Nota: Si ya tienes desacrgados los datasets, puedes correr el flag -skip_downloadpara saltear la descarga de los datasets

sudo ./generate-compose.sh -skip_download -cant_clientes 2

📋 Preparar datasets de prueba

Con correr el flag -testen el script anterior ya queda seteado, pero se puede correr por separado con el comando:

python3 download_datasets.py [-test <test_config.yaml>]
  • Por defecto descarga el dataset completo desde Kaggle.
  • Si se pasa el flag -test, los archivos se recortan según los porcentajes definidos en el YAML.
  • Los archivos se guardan en la carpeta ./data.

Ejemplo de test_config.yaml con todos los datasets al 20%:

movies_metadata.csv: 20
credits.csv: 20
ratings.csv: 20

▶️ Correr el sistema

Important

Pre-requisito: Asegurate de tener generados los archivos docker-compose.system.yaml para el sistema y docker-compose.clients.ymlpara los clientes. Para más información sobre como generarlos, consultá la sección ✅ Script auxiliar generate-compose.sh)


🖥️ Organización recomendada

Para facilitar el desarrollo y la depuración, se recomienda levantar los servicios en dos consolas separadas:

  • Una consola para todo lo relacionado con el sistema (gateway, coordinator, filtros, joins, querys, etc.).
  • Otra consola para levantar y monitorear a los clientes.

🧱 Comandos disponibles (Makefile)

🧹 Limpiar resultados anteriores

sudo rm -rf ./resultados/*./gateway/storage/*

⚙️ Build de imágenes

make build-system     # Construye las imágenes del sistema
make build-clients    # Construye las imágenes de los clientes

🚀 Levantar contenedores

make up-system        # Levanta solo los servicios del sistema
make up-clients       # Levanta solo los servicios de los clientes

💡 Recordá correr make up-system antes de make up-clients, y esperar a que todos los servicios estén saludables / healthy.

📜 Ver logs

make logs-system      # Muestra logs del sistema (gateway, coordinator, filters, joiners, querys, etc.)
make logs-clients     # Muestra logs de los clientes
make logs-all         # Muestra todos los logs combinados (sistema + clientes)

Tip: Dejá logs-system corriendo en una terminal para monitorear la actividad mientras los clientes interactúan.

comandos

🔻 Apagar o limpiar

make down             # Detiene todos los servicios (sistema + clientes)
make clean            # Elimina contenedores, redes y volúmenes
make ps               # Lista los contenedores activos relacionados

🛑 Detener con SIGTERM (graceful shutdown)

make docker-kill-system   # Detiene solo los contenedores del sistema con SIGTERM
make docker-kill-clients  # Detiene solo los contenedores de los clientes con SIGTERM

💀 Introducción de fallas

Para probar la tolerancia a fallos, se cuenta con un script para testear la resiliencia del sistema a la caída de los nodos: gateway, filter_cleanup, filter_year, filter_production, sentiment_analyzer, join_credits y join_ratings.

./fault_injector.sh

📊 Monitoreo de las colas (RabbitMQ)

Podés visualizar el estado de las queues y monitorear la actividad del sistema accediendo al panel de administración de RabbitMQ desde tu navegador:

🔗 http://localhost:15672/#/queues

  • Usuario: guest
  • Contraseña: guest

Desde este panel vas a poder inspeccionar los mensajes en las colas, ver estadísticas en tiempo real y comprobar que los workers estén procesando correctamente.


💯 Respuestas esperadas

🔍 Comparación de resultados de los clientes

El proyecto incluye un script de comparación que permite verificar que los resultados obtenidos por los clientes coincidan con los resultados esperados para los datasets del 20% o del 100%.

🚀 Cómo ejecutarlo

El script permite comparar los resultados de los clientes contra los resultados correctos de referencia. Se debe indicar mediante un flag qué conjunto de respuestas se desea usar como referencia:

Flag Referencia utilizada
-20 Respuestas correctas para el dataset recortado al 20%
-100 Respuestas correctas para el dataset completo (100%)

Además, se puede especificar la carpeta que contiene los resultados generados por los clientes (por defecto es resultados).

📌 Ejemplos de uso

✅ Comparar contra el 20% usando la carpeta default (resultados):

python comparar_resultados.py -20

✅ Comparar contra el 100% usando la carpeta default (resultados):

python comparar_resultados.py -100

✅ Comparar contra los resultados esperados del 100% en la carpeta específica (resultados_100):

python comparar_resultados.py -100 --folder resultados_100

⚠️ Importante

  • El script espera que los archivos de resultados de los clientes estén en formato .txt y que contengan objetos JSON (uno o más por archivo).
  • Los archivos de referencia se encuentran en:
    • resources/answers_datasets_20/resultados.txt
    • resources/answers_datasets_100/resultados.txt

💡 Salida

El script informa por consola si los resultados son consistentes o muestra las discrepancias encontradas (queries faltantes o con datos diferentes).

Datasets al 100 %

query_1 query_2 query_3 query_4 query_5


Datasets al 20 %

query_1 query_2 query_3 query_4 query_5


🛠️ Construido con


✒️ Autores

  • Juan Pablo Fresia - 102.396 - JuanPF56
  • Nathalia Lucia Encinoza Vilela - 106.295 - nathencinoza
  • Camila Belén Sebellin - 100.204 - camiSebe

📑 Documentación

About

Trabajo Práctico Grupo 3 - Materia Sistemas Distribuidos I - FIUBA

Resources

License

Stars

3 stars

Watchers

1 watching

Forks

Packages

 
 
 

Contributors