Big Data Lab
Semana 4 de 8
Big Data Lab · Semana 04 · Procesamiento distribuido

Distributed Processing Lab

Ya distribuiste el almacenamiento de NexoRetail 360 (Semana 3). Ahora el reporte mensual de ventas tarda demasiado en generarse: decide cómo dividir el trabajo entre workers sin gastar cómputo en coordinación innecesaria.

Antes de comenzar

Cargarás datos reales en un motor SQL que corre en tu propio navegador, formularás una hipótesis sobre el efecto de agregar workers, ejecutarás una simulación de procesamiento distribuido y compararás escenarios para encontrar el cuello de botella.

Producirás una evidencia de aprendizaje con tu hipótesis, tus métricas y tu decisión justificada. Tiempo orientativo: 25–35 minutos.

El reto

¿Más workers siempre es mejor?

Contexto
El equipo de analítica ejecuta un trabajo por lotes sobre millones de registros de ventas. Corrido en un solo proceso tarda demasiado.
Problema
Alguien propone "simplemente agregar más workers", pero otra persona del equipo advierte que eso no siempre ayuda. Hay que comprobarlo con datos, no con intuición.
Misión
Pregunta central: ¿cómo influyen el particionado, los workers y la estrategia de procesamiento en la ejecución de un trabajo de datos?
Decisión esperada
Recomendar cuántos workers y particiones usar para este trabajo, identificando el cuello de botella observado.
Qué aprenderás

Objetivos de la sesión

  • Diferenciar almacenamiento distribuido (Semana 3) de procesamiento distribuido.
  • Relacionar particiones, workers y desbalance (skew) con el tiempo total de un trabajo.
  • Interpretar throughput, utilización, speedup y eficiencia, no solo la duración.
  • Reconocer cuándo agregar workers deja de mejorar el rendimiento proporcionalmente.
Conceptos esenciales

Particiones, workers y paralelismo

Un trabajo distribuido se divide en particiones de datos, que se asignan a workers para procesarse en paralelo. El paralelismo solo reduce el tiempo total si hay suficientes particiones para ocupar a todos los workers y la carga está razonablemente balanceada; de lo contrario aparece un cuello de botella: el worker más cargado (o los workers ociosos) determinan cuánto tarda todo el trabajo.

Importante: en la sección "Laboratorio de datos" trabajarás con DuckDB-Wasm, un motor SQL real que corre en tu navegador — las consultas ahí son reales, no simuladas. En la sección "Experimento", en cambio, el particionado/workers/tiempos son un modelo didáctico del procesamiento distribuido, no un clúster real: sirve para razonar sobre las relaciones causales (particiones, skew, E/S, coordinación), no como benchmark.

Concepto clave

¿Qué es un worker?

Qué es: un proceso (o hilo/nodo) que recibe una o varias particiones y las procesa de forma independiente.

Por qué importa: más workers pueden procesar más particiones a la vez, pero cada worker adicional también añade coordinación.

Qué observar aquí: si hay menos particiones que workers, algunos workers quedan ociosos — la sección "Rendimiento simulado" lo cuenta explícitamente.
Concepto clave

¿Qué es el paralelismo?

Qué es: procesar varias particiones de datos al mismo tiempo, en lugar de una tras otra.

Por qué importa: en teoría, duplicar los workers debería acercarse a duplicar la velocidad (speedup), pero la coordinación y el desbalance reducen esa ganancia.

Qué observar aquí: compara el "Speedup" con la "Eficiencia" (speedup / workers activos) para ver cuánta ganancia teórica realmente se aprovechó.
Concepto clave

¿Qué es un cuello de botella?

Qué es: el punto del trabajo que determina la duración total — casi siempre, el worker con más carga o el recurso más lento (E/S de disco vs. memoria).

Por qué importa: agregar workers no ayuda si el cuello de botella es otro (por ejemplo, muy pocas particiones, o E/S lenta).

Qué observar aquí: compara "Modo de procesamiento" (disco vs. memoria) y el desbalance (skew) para identificar qué está limitando el tiempo total.
Tu misión

Pasos del laboratorio

  1. Inspecciona o carga datos reales en el Laboratorio de datos.
  2. Formula tu hipótesis de rendimiento antes de ejecutar nada.
  3. Ejecuta el trabajo analítico real (consulta SQL) sobre esos datos.
  4. Configura el modelo de procesamiento distribuido (workers, particiones, skew, modo).
  5. Compara escenarios (secuencial vs. distribuido, distintos workers).
  6. Observa las métricas (duración, throughput, speedup, eficiencia).
  7. Identifica el cuello de botella.
  8. Toma y justifica una decisión de ingeniería.

Laboratorio de datos

Aquí trabajas con datos reales de muestra, procesados en tu propio navegador con DuckDB-Wasm (un motor SQL que corre localmente mediante un Web Worker). No es una simulación: las consultas de esta sección se ejecutan de verdad sobre las filas que elijas.

🔒 Procesamiento local

Los datos que selecciones aquí (el dataset incluido, uno generado o un archivo de tu equipo) se procesan en este navegador. Este laboratorio no los envía al servidor del curso ni a ninguna API externa.

Inicializando motor local de datos…

Hipótesis

Una hipótesis es tu predicción antes de observar los resultados. Regístrala ahora: una vez bloqueada, no podrás cambiarla, solo reformularla después de ver el resultado.

Completa las dos preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear la ejecución.

Qué observar

Antes de ejecutar el trabajo

Mientras configuras la simulación, observa especialmente:

  • Particiones vs. workers — si hay suficientes particiones para ocupar a todos los workers.
  • Desbalance (skew) — si algunas particiones son mucho más grandes que otras.
  • Modo de E/S — si el trabajo depende de disco o reutiliza datos en memoria.
  • Workload — cuántos registros totales debe procesar el trabajo.
  • Tiempo de ejecución — cómo cambia al variar workers, particiones o skew.
  • Cuello de botella — qué recurso (workers ociosos, worker sobrecargado, E/S) limita el resultado.
Pausa para pensar

Antes de ejecutar: si tienes 8 workers pero solo 4 particiones, ¿qué esperas que muestre la vista de workers?

Pipeline de procesamiento

Simulación arquitectónica — modelo didáctico de distribución del procesamiento, no un clúster real.

1 · Particionar
2 · Procesar
3 · Agregar

Fase actual: en espera.

Rendimiento simulado

Los tiempos son simulados para enseñar relaciones causales (particiones, skew, E/S, coordinación); no son un benchmark real.

Duración—
Throughput—
Utilización—
Speedup—
Eficiencia—speedup / workers activos
Workers ociosos—
El paralelismo reduce tiempo solo si hay suficientes particiones y el trabajo está razonablemente balanceado.
¿Qué ocurrió?

Ejecuta el trabajo para ver un resumen basado en tus resultados reales.

¿Por qué ocurrió?

Aquí verás la relación entre particiones, workers, skew y el tiempo obtenido.

¿Qué significa?

Aquí verás qué implicaría este resultado para el trabajo real de NexoRetail 360.

Distribución de carga por partición

Decisión de ingeniería

¿Cuántos workers y particiones recomendarías?

Responde con base en el speedup, la eficiencia y el cuello de botella observados.

Cierre conceptual

Lo que descubriste: agregar workers solo ayuda hasta que las particiones, el balance de carga o la E/S se vuelven el cuello de botella; después, la eficiencia cae aunque el speedup siga siendo positivo.

Concepto para recordar: throughput, utilización, speedup y eficiencia cuentan historias distintas — la duración sola no explica por qué un trabajo escala o no.

Conexión con la próxima semana: en la Semana 5 los datos dejarán de llegar en lotes fijos: veremos qué pasa cuando llegan de forma continua (streaming).

Evidencia de aprendizaje

Genera tu evidencia

Esta evidencia resume tu consulta real, tu hipótesis, tus métricas de rendimiento y tu decisión. Puedes utilizarla para discusión, entrega o reflexión posterior.

Continuidad curricular

Antes: en la Semana 3 distribuimos el almacenamiento entre nodos.

Después: ya distribuimos también el procesamiento. En la Semana 5 los datos dejarán de llegar en lotes fijos: veremos qué pasa cuando llegan de forma continua (streaming).