Antes de comenzar
Inspeccionarás una muestra real de datos de NexoRetail 360 con un motor SQL que corre en tu propio navegador, formularás una hipótesis de modelo de almacenamiento, configurarás la ruta completa del ecosistema (ingesta → almacenamiento → procesamiento → consulta → analítica) y la evaluarás frente a alternativas.
Producirás una evidencia de aprendizaje con tu hipótesis, tu arquitectura y tu decisión justificada. Tiempo orientativo: 30–40 minutos.
¿Cómo organizamos el ecosistema de datos?
- Contexto
- La Semana 1 diagnosticó que una o más fuentes de NexoRetail 360 presentan presión Big Data real: alto volumen, alta velocidad, mucha variedad o baja veracidad, según el escenario.
- Problema
- Diagnosticar la presión no basta: el equipo de arquitectura necesita, para una fuente concreta, elegir un modelo de almacenamiento y las demás capas del ecosistema (ingesta, procesamiento, consulta, analítica) que respondan a la forma real de esos datos y a cómo se van a consultar.
- Misión
- Pregunta central: ¿cómo debería NexoRetail 360 organizar su arquitectura de datos según las características de los datos y sus necesidades de acceso? No existe una única respuesta correcta: cada combinación implica un compromiso distinto.
- Decisión esperada
- Elegir una familia de almacenamiento y una ruta de ecosistema completa para una fuente de datos, y justificar el trade-off que aceptas.
Objetivos de la sesión
- Relacionar el modelo de datos y el patrón de acceso con la familia NoSQL adecuada.
- Distinguir el rol de cada capa del ecosistema Big Data (ingesta, almacenamiento, procesamiento, consulta, analítica).
- Evaluar una arquitectura en términos de compatibilidad, patrón de acceso, latencia, flexibilidad y escalabilidad, no solo de "si funciona".
- Reconocer que varias arquitecturas pueden ser defendibles con distintos trade-offs.
El ecosistema Big Data y las familias NoSQL
Un ecosistema Big Data separa responsabilidades en capas: ingesta (cómo entra el dato), almacenamiento (dónde y en qué forma vive), procesamiento (cómo se transforma), consulta (cómo se recupera) y analítica (cómo se convierte en decisión). La familia de almacenamiento correcta depende de si el dato es estructurado, semiestructurado o de relaciones (grafo), y de si predominan lecturas por clave, agregaciones o recorridos entre entidades.
Importante: en este laboratorio, DuckDB-Wasm es el motor analítico local — un motor SQL real que corre en tu navegador mediante un Web Worker y perfila la muestra de datos con consultas reales. DuckDB no simula MongoDB, Cassandra, Redis, Neo4j ni ningún otro motor específico: cuando el simulador te muestre "Documentos", "Columnas anchas" o "Grafos", es un modelo didáctico de compatibilidad, no una emulación de esos productos.
Ver las familias de almacenamiento en detalle qué son, por qué importan, qué observarás
- Relacional
- Qué es: tablas con esquema fijo y relaciones mediante joins. Por qué importa: da integridad transaccional fuerte. En el laboratorio observarás: alta compatibilidad cuando el dato es estructurado y se requieren transacciones con integridad.
- Documentos
- Qué es: entidades con esquema flexible agrupadas como documentos completos (ver diálogo "¿Qué es un modelo de documentos?"). Observarás: mayor puntaje de flexibilidad y de compatibilidad cuando el patrón de acceso es "consultar entidad completa".
- Clave-valor
- Qué es: pares clave-valor optimizados para lectura por clave. Por qué importa: ofrece la latencia más baja del laboratorio. Observarás: la barra "Latencia" subir cuando el patrón de acceso es "lectura por clave con baja latencia".
- Columnas anchas
- Qué es: almacenamiento orientado a columnas, pensado para mucha escritura y series/eventos. Observarás: mayor "Capacidad de escritura" y "Escalabilidad" cuando la carga configurada predomina en escrituras.
- Grafos
- Qué es: nodos y relaciones como ciudadanos de primera clase (ver diálogo "¿Qué es un modelo de grafos?"). Observarás: alta compatibilidad solo cuando la fuente es "Relaciones y fraude" y el patrón de acceso es "recorrer relaciones".
Pasos del laboratorio
- Inspecciona una muestra real de datos en el Laboratorio de datos (abajo).
- Identifica sus características: estructura, cardinalidad, calidad.
- Formula tu hipótesis de familia NoSQL y de cuello de botella antes de ver resultados.
- Configura la ruta completa del ecosistema para esa fuente.
- Evalúa la arquitectura resultante.
- Compara los trade-offs frente a otras familias de almacenamiento.
- Toma y justifica una decisión de ingeniería.
- Genera tu evidencia de aprendizaje.
Laboratorio de datos: explora antes de decidir
Antes de elegir una arquitectura, inspecciona datos reales de muestra. El laboratorio procesa una muestra manejable localmente y usa esa muestra para estudiar decisiones arquitectónicas aplicables a sistemas de mucha mayor escala. El perfilado (filas, tipos, nulos, cardinalidad, mínimos/máximos, promedios) lo calcula realmente DuckDB-Wasm, un motor SQL que corre en tu navegador mediante un Web Worker — no es una simulación de MongoDB, Cassandra, Redis ni Neo4j: es el motor analítico local de este laboratorio.
Los datos que selecciones aquí se procesan en este navegador y no se envían al servidor del curso ni a ninguna API externa.
Inicializando motor local de datos…
Fuente: —
Filas (consulta real): —
Esquema
Observaciones de estructura (apoyo, no reemplaza tu decisión)
Perfilar columnas (SQL real) consulta real ejecutada por DuckDB-Wasm
Distribución por columna (GROUP BY real) consulta real ejecutada por DuckDB-Wasm
Consulta ejecutada localmente mediante DuckDB-Wasm — datos reales, no inventados por JavaScript.
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 evaluación.
Antes de evaluar la arquitectura
Mientras configuras la ruta de datos, observa especialmente:
- Compatibilidad — qué tan bien encaja el modelo elegido con la forma real del dato.
- Patrón de acceso — si predominan lecturas por clave, agregaciones, joins o recorridos de relaciones.
- Latencia — qué tan rápido responde la capa de consulta elegida.
- Flexibilidad — qué tanto tolera el modelo cambios de esquema.
- Escalabilidad — cómo se comporta el modelo bajo la escala y la carga de escritura configuradas.
- Trade-offs — qué otras familias también serían defendibles y qué compromiso aceptas al no elegirlas.
Antes de evaluar: ¿qué compromiso estás dispuesto a aceptar si tu elección resulta débil en alguna dimensión?
Ruta de datos resultante
Métricas de adecuación
Modelo didáctico: cada dimensión combina las elecciones en un puntaje 0–100 para poder discutir compromisos, no para producir una única respuesta correcta.
Ver razonamiento del modelo (pesos y puntajes)
Evalúa una arquitectura para ver un resumen basado en tus resultados reales.
Aquí verás la relación entre la ruta que configuraste y el puntaje obtenido.
Aquí verás qué implicaría este resultado en una arquitectura real de NexoRetail 360.
Comparación de modelos de almacenamiento
¿Qué arquitectura recomendarías?
Responde con base en la dimensión más débil observada: ¿qué trade-off aceptas y por qué es razonable para este caso?
Cierre conceptual
Lo que descubriste: qué familia de almacenamiento y qué ruta de ecosistema encajan mejor con la forma real de una fuente de datos y su patrón de acceso, y qué trade-off implica esa elección.
Concepto para recordar: no existe una familia NoSQL universalmente mejor; cada una optimiza una combinación distinta de compatibilidad, latencia, flexibilidad y escalabilidad.
Conexión con la próxima semana: en la Semana 3 estudiarás cómo se distribuyen físicamente los datos dentro del modelo de almacenamiento elegido aquí — nodos, hashing, particionado y replicación.
Genera tu evidencia
Esta evidencia resume tu inspección de datos, tu hipótesis, tu arquitectura y tu decisión. Puedes utilizarla para discusión, entrega o reflexión posterior.
Continuidad curricular
Antes: en la Semana 1 diagnosticaste la presión Big Data del escenario (volumen, velocidad, variedad, riesgo de calidad, valor).
Después: elegiste cómo almacenar los datos. En la Semana 3 profundizarás en cómo se distribuyen físicamente esos datos dentro del modelo elegido aquí — nodos, hashing, particionado y replicación.