Guía del estudiante · Big Data Lab

Esta guía te acompaña mientras realizas los ocho laboratorios. Úsala como una ruta de trabajo: no busca darte una respuesta única, sino ayudarte a formular una predicción, comparar condiciones, interpretar resultados y justificar una decisión con evidencia vigente.

A. Qué es Big Data Lab

Big Data Lab es un recorrido práctico de ocho semanas sobre decisiones de ingeniería de datos. Trabajarás con un caso común, NexoRetail 360, y avanzarás desde el diagnóstico de un problema hasta una decisión predictiva de capacidad. En cada laboratorio asumirás un rol: analizarás una situación, modificarás parámetros, observarás consecuencias y explicarás qué decisión tomarías.

La plataforma combina dos tipos de resultados:

• cálculos reales en el navegador, como consultas SQL, perfilado, agregaciones y métricas producidas por DuckDB-Wasm en las semanas que lo indican;
• modelos didácticos o simulaciones, creados para hacer visibles relaciones como presión Big Data, replicación, paralelismo, backpressure, riesgo, autoscaling o capacidad.

Una simulación didáctica no es un benchmark, una tarifa comercial, un SLA real, una auditoría de seguridad ni una garantía de producción. Su valor está en permitir comparaciones controladas. Lo importante no es obtener el número más alto, sino explicar por qué una condición produjo un resultado y qué límites tiene esa conclusión.

B. Cómo se aprende en la plataforma

Cada semana sigue un ciclo común:

1. Reto: comprende el problema y la decisión que debes tomar.
2. Conceptos: consulta solo la teoría que necesites para avanzar.
3. Hipótesis: predice qué ocurrirá antes de ejecutar.
4. Experimento: cambia una variable y conserva las demás.
5. Análisis: compara el resultado con tu predicción y con una referencia.
6. Decisión: elige una alternativa y justifica el compromiso aceptado.
7. Evidencia: genera un registro claro de lo que hiciste y aprendiste.

La secuencia no exige acertar desde el comienzo. Una hipótesis que no se cumple también produce aprendizaje si identificas qué supuesto falló. Evita ajustar tu predicción después de conocer el resultado sin dejar rastro: registra primero lo que esperabas y usa la reformulación para explicar cómo cambió tu razonamiento.

La estrategia recomendada es una comparación causal sencilla:

• configura una condición A y registra el resultado;
• cambia una sola variable para construir la condición B;
• mantén constantes el caso, los datos y las demás opciones;
• vuelve a ejecutar la acción principal;
• describe qué cambió, en qué dirección y por qué.

No necesitas probar todas las combinaciones. Dos o tres comparaciones bien controladas enseñan más que muchas ejecuciones sin propósito.

C. Cómo realizar un laboratorio

Antes de comenzar, reserva entre 30 y 45 minutos, usa un navegador moderno y abre la plataforma mediante el servidor HTTP indicado por quien orienta el curso. Algunas funciones de datos reales usan módulos, Web Workers y WebAssembly, y pueden no operar correctamente si abres los archivos con file://.

Sigue esta rutina:

1. Lee Qué aprenderás, Tu misión y Experimento guiado.
2. Identifica la pregunta de decisión: ¿qué debes recomendar al final?
3. Revisa los controles y anota una configuración inicial reproducible.
4. Completa la hipótesis antes de ejecutar.
5. Ejecuta una línea base y registra sus métricas principales.
6. Cambia solo la variable indicada en Cambia; respeta Mantén.
7. Ejecuta de nuevo. Mover un control no actualiza por sí solo un resultado anterior.
8. Compara A y B, formula una explicación causal prudente y registra una decisión.
9. Genera la evidencia únicamente cuando el resultado corresponda a la configuración visible.
10. Copia o descarga la evidencia antes de cerrar o recargar la pestaña.

Algunas misiones añaden pasos estructurados de metacognición o de lectura causal, como indicar qué tan seguro estás de tu predicción o interpretar el resultado vigente antes de generar evidencia. Cuando una semana los incluye, su apartado en el Recorrido por semanas los describe; la Semana 01 los documenta de forma explícita.

Si cargas un archivo propio, revisa el esquema esperado, el formato y el límite de tamaño que muestra la semana. Para una primera aproximación usa el dataset incluido o uno sintético con semilla; así podrás repetir exactamente el experimento antes de introducir variaciones de tus propios datos.

D. Cómo interpretar resultados

Lee un resultado en cuatro niveles:

1. Estado: confirma si el laboratorio está listo, ejecutando, pausado, en incidente, recuperándose, con resultado o con cambios pendientes.
2. Métrica: identifica el valor y su unidad. Un porcentaje, una latencia, un backlog y un puntaje no significan lo mismo.
3. Comparación: contrasta el valor con la línea base o con otra configuración equivalente.
4. Explicación: relaciona el cambio aplicado con el mecanismo que produjo el efecto.

Una explicación útil tiene esta forma: “Al cambiar X de ___ a ___ y mantener Y y Z, el resultado R pasó de ___ a ___. Esto es coherente con ___; sin embargo, la conclusión está limitada por ___”.

Evita estas interpretaciones:

• “es mejor porque el puntaje es mayor”, sin identificar qué dimensión mejoró;
• “la tecnología siempre funciona así”, cuando el valor proviene de un modelo didáctico;
• “X causó el resultado”, si cambiaste varios controles al mismo tiempo;
• “el resultado sigue vigente”, después de modificar la configuración sin volver a ejecutar;
• “un promedio describe todo”, cuando existe skew, variación temporal, valores extremos o restricciones.

Cuando aparezca CHANGES_PENDING, el resultado pertenece a una configuración anterior. Vuelve a ejecutar antes de decidir o generar evidencia. En actividades temporales, observa además la tendencia: que una cola sea grande en un instante no demuestra por sí solo que siga creciendo.

E. Cómo construir evidencia

La evidencia debe permitir que otra persona reconstruya tu razonamiento. Incluye, en este orden:

• pregunta e hipótesis: qué esperabas y por qué;
• condición A: datos, controles relevantes y resultado;
• condición B: única variable modificada y resultado;
• observación: diferencia cuantitativa o cualitativa entre A y B;
• explicación: mecanismo que conecta el cambio con el resultado;
• decisión: alternativa elegida y compromiso que aceptas;
• limitación: qué no demuestra el laboratorio o qué dato adicional necesitarías.

Ejemplo breve: “Predije que aumentar la replicación conservaría la lectura durante una falla. Con los mismos registros y nodos, el factor 1 perdió disponibilidad al caer el nodo propietario; el factor 2 mantuvo una copia accesible, a costa de más almacenamiento y coordinación. Recomiendo factor 2 para este caso, sujeto a validar costo y fallos correlacionados”.

Antes de entregar, comprueba:

• ¿se entiende qué cambiaste y qué mantuviste?
• ¿las métricas pertenecen a la configuración final?
• ¿distingues cálculo real de simulación didáctica?
• ¿tu decisión menciona al menos un beneficio, un costo o riesgo y una limitación?
• ¿guardaste el texto generado en el medio solicitado?

F. Cómo usar ayuda, progreso y Next Step

El botón ¿Necesitas ayuda? abre orientación específica de la semana: cómo realizar el laboratorio, qué observar, cómo recuperarte de un problema y qué debe contener la evidencia. Úsalo cuando no sepas cómo continuar; no reemplaza tu predicción ni decide por ti.

Tu progreso en este laboratorio resume cuatro logros derivados de acciones reales: registrar la hipótesis, obtener un resultado vigente, justificar una decisión y generar evidencia vigente. Al inicio lo verás dentro del flujo de lectura. En una pantalla amplia, al llegar al experimento, el mismo panel puede acompañarte a la derecha. En tablet o móvil permanece apilado para no reducir el espacio de trabajo. No son dos progresos diferentes y desplazarte por la página no marca tareas como completadas.

En la Semana 01, este panel incluye además el paso Interpretar el resultado vigente, y la misión añade una capa propia de logros de razonamiento. Esos logros no reemplazan el progreso anterior: reconocen hitos de pensamiento durante la misión.

• Constructor de hipótesis: registraste una predicción antes de ver resultados.
• Lector de evidencia: tu lectura causal coincide con la señal de mayor presión del resultado vigente.
• Pensador sistémico: interpretaste una comparación A/B controlada, en la que cambió una sola variable. Es un hito de profundización, no un requisito para completar la misión.
• Maestro de la evidencia: generaste evidencia vigente y completaste la misión.

Los XP de razonamiento reflejan solo estos hitos; no miden velocidad ni cantidad de clics. No hay tabla de posiciones ni competencia entre estudiantes. Un logro obtenido antes puede aparecer como Logrado antes · vuelve a demostrarlo: ese registro histórico no restaura un resultado ni una evidencia anteriores, que debes volver a obtener sobre la configuración vigente.

Próximo paso o Next Step indica la acción que corresponde al estado actual. Si cambias un control, te pedirá actualizar el resultado. Si ya tienes resultado, te conducirá a la decisión o a la evidencia. En la semana de streaming también reconocerá ejecución, pausa, incidente y recuperación.

Si algo no sale como esperabas:

• lee el mensaje de estado antes de repetir clics;
• verifica que completaste la hipótesis y los campos obligatorios;
• espera a que termine una operación en ejecución;
• usa Reiniciar laboratorio cuando necesites una línea base limpia;
• si el motor local de datos no inicia, sigue la indicación de modo conceptual disponible en la página;
• no uses una evidencia generada antes de un cambio: regenera el resultado y después la evidencia.

G. Privacidad y datos locales

Los archivos que seleccionas se procesan dentro de tu navegador y no se envían al servidor del curso ni a una API externa. DuckDB-Wasm ejecuta localmente las consultas de los laboratorios que usan datos reales. El dataset incluido sí se descarga desde el mismo sitio que sirve la plataforma; esto no implica subir tus archivos.

Trabaja, aun así, con criterio de minimización:

• prefiere datos sintéticos, anonimizados o suministrados para la actividad;
• no cargues credenciales, secretos, identificadores sensibles ni datos personales innecesarios;
• verifica el esquema y elimina columnas que no aporten al propósito;
• no confundas procesamiento local con autorización para usar cualquier conjunto de datos;
• descarga tu evidencia antes de cerrar: el trabajo del laboratorio no debe asumirse como guardado en una cuenta o backend.

H. Recorrido por semanas

Semana 01 · Big Data Triage Lab

Qué aprenderás

Aprenderás a decidir cuándo un problema presenta presión Big Data y cuándo una solución convencional puede ser suficiente. Relacionarás volumen, velocidad, variedad, veracidad y valor con el contexto operacional, sin tratar una sola V como prueba definitiva.

Tu misión

Diagnostica un escenario de NexoRetail 360 y recomienda una arquitectura convencional, híbrida o distribuida. Tu recomendación debe ser proporcional al problema y reconocer el riesgo de sobredimensionar.

Qué debes hacer

Selecciona un caso y, antes del primer análisis, registra tu predicción inicial: la clasificación que esperas, la dimensión que crees que será crítica y tu nivel de confianza (Baja, Media o Alta). Las tres respuestas son necesarias para registrar la hipótesis y desbloquear el análisis. La confianza es un dato metacognitivo: registra qué tan seguro te sientes antes de ver el resultado; no es una calificación y no modifica el resultado de la simulación.

Analiza una configuración inicial y lee el resultado vigente junto con el Tablero de señales 5V. Antes de generar evidencia, completa la lectura causal en Interpreta el resultado:

• elige la dimensión que consideras más crítica según el resultado;
• elige la señal del resultado vigente que respalda esa lectura;
• si quieres, indica si tu confianza subió, se mantuvo o bajó al ver el resultado.

Esta lectura pertenece al análisis actual. Si cambias la configuración o vuelves a analizar, interpreta de nuevo el nuevo resultado vigente antes de generar evidencia. Su propósito es guiar tu razonamiento, no calificarte como acierto o error.

Registra después tu decisión de arquitectura y su justificación. La evidencia de esta semana solo se genera cuando existe un análisis vigente, tu lectura causal corresponde a ese análisis y se cumplen los demás requisitos de evidencia. Una evidencia generada antes de cambiar la configuración o de volver a analizar deja de ser válida: regénerala.

Para profundizar, guarda una condición A, modifica una sola característica, vuelve a analizar y guarda la condición B. Compara el índice, la clasificación y la recomendación antes de justificar tu decisión. Si entre A y B cambió exactamente una variable de configuración, la comparación es controlada; si cambiaron varias, la diferencia observada no puede atribuirse a una sola causa. La comparación A/B enriquece tu razonamiento, pero no es un requisito oculto para completar la misión, y sus conclusiones valen dentro del modelo didáctico.

Qué cambiar

Cambia una sola V observable: por ejemplo, velocidad de llegada, volumen diario, variedad de fuentes, calidad del origen o utilidad estimada.

Qué mantener

Conserva el mismo sector, criticidad, formatos y demás controles. Si comparas velocidad, no cambies también volumen y variedad.

Qué observar

Observa el índice de presión, la clasificación, la dimensión crítica y la arquitectura sugerida. Revisa si un aumento altera solo el puntaje o también la decisión.

En el Tablero de señales 5V, el número grande de cada V es su puntaje bruto de 0 a 100 según el simulador, y la señal destacada es la dimensión con el mayor puntaje bruto. El aporte ponderado al índice aparece como información secundaria y no decide cuál V se destaca. La Veracidad expresa la confiabilidad o calidad del origen, no una presión; la presión que genera una baja veracidad se lee por separado en Riesgo de calidad.

Situaciones o casos sugeridos

• Compara un flujo de baja velocidad con otro de eventos continuos, manteniendo volumen y variedad.
• Aumenta el volumen, pero conserva un esquema estable y una respuesta no inmediata; pregunta si aún es defendible una solución convencional.
• Mantén la escala y reduce la calidad del origen; observa si el problema principal pasa a ser limpieza y gobierno.

Preguntas para pensar

• ¿Qué V explica realmente el cambio de clasificación?
• ¿Una cifra alta obliga a usar una arquitectura distribuida completa?
• ¿Qué costo o complejidad evitarías con una solución más simple?

Qué debería aparecer en tu evidencia

Hipótesis con tu nivel de confianza inicial, lectura causal del resultado vigente y, si realizaste la comparación, configuraciones A y B, única variable modificada, índice y clasificación de ambas y explicación del cambio; además, arquitectura elegida y una limitación del modelo didáctico.

Semana 02 · Big Data Ecosystem Architect

Qué aprenderás

Aprenderás a seleccionar almacenamiento y capas de arquitectura según la estructura del dato, el patrón de acceso, la consistencia y la carga de lectura o escritura. Reconocerás que acumular tecnologías no crea una mejor arquitectura.

Tu misión

Diseña una ruta de ingesta, almacenamiento, procesamiento, consulta y analítica para una fuente de NexoRetail 360. Explica qué aporta frente a una alternativa más simple y qué compromiso aceptas.

Qué debes hacer

Explora el dataset incluido, sintético o local. Perfila filas, tipos, nulos y cardinalidad; cuando sea útil, ejecuta una agregación. Registra tu hipótesis, configura la ruta, aplica la evaluación y compara al menos una alternativa de almacenamiento.

Qué cambiar

Cambia la fuente o estructura de datos, el patrón de consulta o una sola capa de la arquitectura. Una comparación recomendada es sustituir únicamente el modelo de almacenamiento.

Qué mantener

Conserva el mismo dataset, caso de uso, escala, consistencia y las demás capas mientras comparas una elección.

Qué observar

Distingue el perfil SQL real de la evaluación didáctica. Observa adecuación global, compatibilidad, dimensión débil, flexibilidad, latencia, escalabilidad y trade-off resultante.

Situaciones o casos sugeridos

• Compara datos transaccionales CSV con eventos JSON y pregunta cuándo relacional o documentos resultan más coherentes.
• Mantén eventos de alta escritura y contrasta documentos con columnas anchas.
• Usa datos de relaciones y compara una ruta de grafos con una alternativa que dificulte los recorridos.

Preguntas para pensar

• ¿Qué necesidad concreta resuelve cada capa?
• ¿Qué observación proviene de DuckDB y cuál del modelo didáctico?
• ¿Qué perderías al usar una arquitectura más simple?

Qué debería aparecer en tu evidencia

Fuente y estructura observadas, resultado del perfil, ruta A/B, dimensión que explica la diferencia, alternativa simple considerada, decisión y compromiso aceptado.

Semana 03 · Distributed Cluster Lab

Qué aprenderás

Aprenderás cómo particionado, replicación y consistencia afectan distribución, disponibilidad y costo ante fallos. Separarás identidad del registro, clave de partición y copia física.

Tu misión

Mantén disponibles los pedidos durante una falla controlada y recomienda una clave de partición y un factor de replicación justificables.

Qué debes hacer

Usa la muestra incluida o un archivo compatible, analiza una columna candidata como clave y envía la misma muestra al clúster simulado. Registra tu hipótesis, almacena registros, observa su distribución, falla un nodo y documenta disponibilidad. Recupera el nodo y repite con otra replicación.

Qué cambiar

Cambia el factor de replicación, la disponibilidad de un nodo o una clave candidata; haz una variación por comparación.

Qué mantener

Conserva los mismos registros, cantidad de nodos, modelo de consistencia y nodo sometido a una falla equivalente.

Qué observar

Observa skew, copias físicas, registros disponibles, almacenamiento y coordinación. Comprueba qué sucede antes, durante y después de la falla o re-replicación.

Situaciones o casos sugeridos

• Compara factor 1 y factor 2 al fallar el nodo que contiene la copia primaria.
• Contrasta una clave de baja cardinalidad, como región, con una de mayor diversidad.
• Mantén la replicación y compara consistencia fuerte con eventual, atendiendo al costo de coordinación.

Preguntas para pensar

• ¿Qué costo aumentó cuando mejoró la disponibilidad?
• ¿Una distribución equilibrada garantiza tolerancia a fallos?
• ¿Qué riesgo persiste si las copias fallan de forma correlacionada?

Qué debería aparecer en tu evidencia

Dataset y clave, registros constantes, factores comparados, nodo caído, disponibilidad antes/después, skew, costo observado y recomendación de partición/replicación.

Semana 04 · Distributed Processing Lab

Qué aprenderás

Aprenderás por qué más workers no garantizan speedup proporcional. Relacionarás particiones, skew, utilización, E/S y coordinación con el camino crítico del procesamiento.

Tu misión

Reduce el tiempo de un workload sin sobredimensionar el clúster. Recomienda una relación entre workers y particiones y explica dónde aparece el cuello de botella.

Qué debes hacer

Usa o genera un dataset, registra tu predicción y ejecuta una línea base. Compara contra el caso secuencial. Después repite cambiando workers, particiones o skew y examina la distribución de carga.

Qué cambiar

Cambia una sola variable: número de workers, número de particiones, nivel de skew o modo de procesamiento.

Qué mantener

Conserva el volumen de registros, el dataset, la semilla y todas las demás condiciones del workload.

Qué observar

Observa tiempo total, worker más lento, workers ociosos, speedup y eficiencia. Distingue consultas SQL reales de tiempos distribuidos didácticos.

Situaciones o casos sugeridos

• Mantén ocho particiones y compara cuatro, ocho y doce workers.
• Mantén workers y particiones y aumenta solo el skew.
• Compara lectura reiterada desde disco con reutilización en memoria sin modificar el volumen.

Preguntas para pensar

• ¿Qué worker determina el final de la tarea?
• ¿Cuándo agregar capacidad deja de ayudar?
• ¿Qué configuración mínima alcanza una eficiencia razonable?

Qué debería aparecer en tu evidencia

Configuraciones A y B, duración, speedup, eficiencia, distribución por worker, cuello de botella, decisión de dimensionamiento y aclaración sobre métricas simuladas.

Semana 05 · Event Stream Control Room

Qué aprenderás

Aprenderás a distinguir una cola transitoria de backpressure sostenido y a interpretar un sistema por sus estados y tendencias, no por una sola instantánea.

Tu misión

Opera un flujo de eventos, detecta si producción y consumo están equilibrados, responde a un incidente y justifica una política de capacidad y recuperación.

Qué debes hacer

Predice la tendencia del backlog, inicia el flujo y observa varios intervalos. Pausa cuando necesites una fotografía estable. Ejecuta un incidente representativo y usa la recuperación controlada. Analiza con SQL real los eventos que ya fueron consumidos antes de generar evidencia.

Qué cambiar

Cambia productores, tasa por productor, consumidores, capacidad por consumidor o un incidente temporal. Para estudiar causalidad, activa solo un incidente por prueba.

Qué mantener

Conserva particiones, tasas y capacidades restantes. Si comparas un consumidor lento, no actives simultáneamente un pico y una caída.

Qué observar

Observa estado, throughput, capacidad efectiva, backlog, pendiente, latencia y tiempo de recuperación. Recuerda que broker y consumidores son simulados; DuckDB consulta realmente los eventos procesados.

Situaciones o casos sugeridos

• Configura producción menor que capacidad y verifica si una cola inicial se drena.
• Aumenta producción por encima de capacidad y observa si backlog y latencia crecen de forma sostenida.
• Compara un pico breve con un consumidor lento de ocho segundos.
• Usa más consumidores que particiones y observa recursos sin trabajo paralelo.

Preguntas para pensar

• ¿La cola crece por producción excesiva o por consumo insuficiente?
• ¿Recuperar capacidad elimina el backlog o solo cambia su pendiente?
• ¿Qué alerta distinguiría un pico breve de un incidente persistente?

Qué debería aparecer en tu evidencia

Estado al capturar, tasas de producción/consumo, particiones, evolución temporal del backlog y latencia, incidente, recuperación, consulta analítica y acción propuesta.

Semana 06 · Cloud Architecture & Security Lab

Qué aprenderás

Aprenderás a relacionar controles de arquitectura con confidencialidad, integridad y disponibilidad, y a reconocer riesgo residual y responsabilidad compartida.

Tu misión

Diseña una arquitectura cloud proporcionada al caso, inyecta un incidente y prioriza el control que reduce su impacto sin afirmar que elimina todos los riesgos.

Qué debes hacer

Registra tu hipótesis, selecciona modelo de despliegue y servicio, configura instancias y controles, y aplica la arquitectura. Ejecuta un incidente, registra el cambio en CIA y compara la misma amenaza con un control activado o desactivado.

Qué cambiar

Cambia un control: autenticación/autorización, cifrado, verificación de integridad, réplica/backup o cantidad de instancias.

Qué mantener

Conserva el mismo incidente, modelo cloud y demás controles para atribuir el efecto al cambio estudiado.

Qué observar

Observa qué propiedad CIA cae, cuál control la protege principalmente y qué riesgo no queda cubierto. Los puntajes son didácticos, no una auditoría de cumplimiento.

Situaciones o casos sugeridos

• Compara acceso no autorizado con y sin autenticación/autorización; no atribuyas esa función solo al cifrado.
• Compara mensaje alterado con y sin verificación de integridad.
• Prueba caída de una instancia con una y varias instancias.
• Contrasta pérdida de almacenamiento con y sin réplica/backup.

Preguntas para pensar

• ¿El control previene, detecta o permite recuperar?
• ¿Qué responsabilidad conserva la organización en IaaS, PaaS o SaaS?
• ¿Qué segundo control necesitarías para una defensa por capas?

Qué debería aparecer en tu evidencia

Arquitectura, incidente constante, control modificado, valores CIA antes/después, propiedad afectada, control priorizado, riesgo residual y límite del modelo.

Semana 07 · Multicloud Autoscaling Advisor

Qué aprenderás

Aprenderás a integrar demanda, capacidad, SLA, costo, cumplimiento y soporte en una decisión de autoscaling y proveedor. Diferenciarás restricciones obligatorias de pesos de preferencia.

Tu misión

Dimensiona capacidad frente a una demanda horaria y recomienda una opción elegible. Explica por qué la alternativa más barata o con mayor puntaje no siempre es aceptable.

Qué debes hacer

Usa demanda incluida, local o sintética y agrégala por hora. Registra tu hipótesis, aplica esa demanda a la simulación, configura capacidad mínima/máxima y margen, define pesos/restricciones y simula. Repite con una sola variación.

Qué cambiar

Cambia intensidad de campaña, capacidad por instancia, límite máximo, margen, una ponderación o la restricción de datos regulados.

Qué mantener

Conserva el mismo dataset y política de capacidad cuando compares proveedores; conserva los mismos pesos cuando estudies exclusivamente la demanda.

Qué observar

Observa instancias requeridas y activas, horas con incumplimiento, sobreaprovisionamiento, elegibilidad y ranking. Los costos, SLA y puntajes de proveedor son valores didácticos, no ofertas actuales.

Situaciones o casos sugeridos

• Compara demanda normal con una campaña intensa, sin cambiar la política.
• Reduce el máximo de instancias y observa si aparecen violaciones de SLA.
• Mantén demanda y activa la condición de datos regulados.
• Cambia solo el peso de costo o cumplimiento y busca el punto donde cambia la recomendación.

Preguntas para pensar

• ¿La violación se debe a demanda, capacidad por instancia o límite máximo?
• ¿Qué restricción descarta una opción antes del ranking?
• ¿Qué riesgo aceptas al reducir costo o margen?

Qué debería aparecer en tu evidencia

Origen y resumen de demanda, política de autoscaling, horas de SLA, pesos y restricciones, opciones elegibles, ranking A/B, causa del cambio y recomendación argumentada.

Semana 08 · Big Data Decision Twin

Qué aprenderás

Aprenderás a preparar datos, validar un modelo frente a líneas base y transformar una predicción incierta en una decisión de capacidad con margen y límites explícitos.

Tu misión

Entrena y valida un modelo de demanda, produce un escenario futuro y recomienda capacidad sin presentar la predicción como certeza operacional.

Qué debes hacer

Selecciona o genera datos, perfila calidad, define variable objetivo y realiza una división temporal. Registra tu hipótesis, entrena y valida, compara MAE/RMSE con una línea base y conserva el modelo. Después cambia una entrada futura o el margen, vuelve a predecir y completa la decisión.

Qué cambiar

Para estudiar la decisión, cambia una entrada futura o el margen de seguridad sin reentrenar. Para estudiar el modelo, cambia preparación, variables o división temporal y vuelve a entrenar.

Qué mantener

Conserva el mismo modelo validado cuando compares dos escenarios futuros. Conserva dataset, semilla y división cuando analices el efecto de una sola variable de modelado.

Qué observar

Observa calidad de datos, separación train/test, MAE, RMSE, error relativo, desempeño frente a línea base, predicción, margen e instancias. Distingue asociación estadística de causalidad.

Situaciones o casos sugeridos

• Compara división 70/30 con 90/10 y discute estabilidad, sin asumir que menor error siempre significa mejor generalización.
• Conserva el modelo y aumenta una entrada futura relevante.
• Mantén la predicción y compara márgenes de capacidad moderado y alto.
• Genera datos con más ruido y observa si el error justifica revisar el margen.

Preguntas para pensar

• ¿El modelo supera una referencia simple y por cuánto?
• ¿Qué significa el error en unidades del problema?
• ¿Qué costo tendría subaprovisionar frente a sobreaprovisionar?
• ¿Qué cambio de contexto invalidaría el modelo aunque sus métricas históricas fueran buenas?

Qué debería aparecer en tu evidencia

Origen y preparación, variable objetivo, división temporal, comparación con línea base, MAE/RMSE contextualizados, escenario vigente, predicción, margen, capacidad, decisión, riesgo principal y condiciones que exigirían reentrenar o revisar.

Cierre del recorrido

Al terminar las ocho semanas deberías poder conectar diagnóstico, arquitectura lógica, distribución física, procesamiento, streaming, seguridad, escalabilidad y predicción. Conserva tus evidencias: en conjunto deben mostrar no solo resultados, sino una evolución en la forma de formular hipótesis, controlar comparaciones, reconocer límites y justificar decisiones técnicas.