TP Sistemas Distribuidos: Coffee Shop Analysis

Integrantes

• Facundo Nazareno Lescano
• Juan Pablo Bel
• Federico Letier

Dataset

El dataset a utilizar se puede encontrar en este link

Descargarlo y ubicarlo en una carpeta .data/full

En caso de querer utilizar el dataset reducido, crear una carpeta .data/reduced, copiando los datasets de users, stores y menu_items, luego agregar una carpeta transactions, pasando únicamente los archivos correspondientes a 202401 y 202501 del dataset original, lo mismo para transaction_items, solo tomar los archivos correspondientes a esos dos meses.

Para elegir dataset por cliente, editar config/compose_config.yaml usando el formato:

clients:
  - name: client-a
    dataset: reduced  # o full (o cualquier carpeta dentro de .data/)
  - name: client-b
    dataset: full

Luego generar nuevamente el docker-compose.yaml:

make generate-compose

Configuración de escalabilidad

En el archivo config/compose_config.yaml se puede configurar la cantidad de instancias que se desean para cada worker, modificando el valor de quantity en cada uno de ellos. Aquellos workers no escalables (grouppers) deben dejar ese campo en 1. Una vez hecho esto, es necesario volver a generar el docker-compose.yaml, ejecutando el comando:

make generate-compose

Generación de compose y estructura de resultados

• make generate-compose genera docker-compose.yaml, limpia .results/ y crea las carpetas de resultados para cada cliente en el formato .results/<client>-<dataset> (ej.: .results/client-a-reduced).

Ejecución

Para ejecutar el sistema, con el compose ya generado, correr el comando:

make docker-compose-up

Esto levantará el contenedor de RabbitMQ, luego el servidor y los workers, y por último los clientes definidos en config/compose_config.yaml.

Logs

Para ver los logs del sistema, correr el comando:

make docker-compose-logs

En caso de querer filtrar para ver los de un contenedor en particular, se puede hacer con:

make docker-compose-logs | grep "<nombre_del_contenedor>"

Resultados

Una vez que los clientes hayan recibido todos los resultados del servidor, los CSV se encontrarán en .results/<client>-<dataset>/ para cada cliente. Para la query 2, los archivos de salida serán 2: results_query_2_most_profit.csv y results_query_2_most_quantity.csv.

Verificación

Para verificar que los resultados sean correctos, contamos con los resultados esperados en la carpeta expected_results, tanto para el dataset completo como para el reducido. Para las primeras 3 queries, basta con ordenar y comparar los archivos. Para la query 4, el top 3 no es determinístico, por lo que múltiples resultados son correctos, y dependiendo de la cantidad de workers en cada etapa, puede obtenerse uno u otro. Para poder verificarlo, el resultado esperado contiene un top extendido, por lo que verificamos que el top 3 obtenido se encuentre dentro de ese top extendido del archivo esperado.

Tests

Para verificar los resultados, correr:

make test-results

El script detecta automáticamente el dataset por el sufijo del nombre de la carpeta (<client>-<dataset>) y compara contra expected_results/<dataset>/.

Cliente temporal

Podés ejecutar un cliente temporal (fuera del compose) montando un dataset específico y una carpeta de resultados:

make run-client NAME=<client-name> DATASET=<dataset>

Ejemplo:

make run-client NAME=temp DATASET=reduced

Esto crea .results/temp-reduced/ y ejecuta el contenedor en primer plano mostrando logs.

Cortar ejecución

Para cortar la ejecución del sistema, correr el comando:

make docker-compose-down

Con esto se frenan todos los workers, el servidor, RabbitMQ y los clientes definidos en el docker compose (que vienen del config/compose_config.yaml) que sigan corriendo

Test middleware

Para correr los tests del middleware, correr el comando:

make test-middleware

Test EOF

Para probar el sistema con un dataset pequeño y verificar el manejo de EOFs, usar:

make test-eof

Esto usa config/eof_compose_config.yaml que configura:

• Dataset testEOF (más pequeño que el reducido)
• Solo una query simplificada (un filter, dos grouppers y un joiner)
• Múltiples workers para probar coordinación de EOFs
• 2 clientes para verificar manejo de los EOFs para múltiples jobs